icoss: a two-layer object-based intelligent cell control architecture

Computer Integrated Manufacturing Systems 1994 7(2) 100-112

ICOSS: A two-layer object-based intelligent cell control architecture

Kwan H Lee and Saptarshi Sen Department of Industrial Engineering, Northern Illinois University, DeKalb, IL 60115-2854, USA

This paper reviews past cell control approaches, and addresses a cell control architecture called ICOSS (Intelligent Cell Objects/Intelligent Supporting Shell) that is applicable to an automated mannfacturing factory. The ICOSS architecture consists of two layers: the inner layer that we call the intelligent cell objects (ICO), and the outer layer that we call the intelligent supporting shell (ISS). The ICO contains cell control knowledge that can perform generic cell control functions such as scheduling, dispatching and monitoring. The ISS, on the other hand, contains cell databases that represent the specific cell environment. The two layer approach allows more efficiency in developing and implementing intelligent cell control by considering generic cell control knowledge and cell-specific databases separately. The cell control knowledge in both layers are organized using the object hierarchy. The object classes and generic methods (or procedures) defined in each object class are detailed in the paper. In addition, the objects in the ICO can be modified or added by transmitting them through an established computer network rather than being loaded at individual manufacturing cell control computers. The effectiveness of using the ICOSS two-layer architecture will be greater when it is used to update a large number of manufacturing cell controllers in an automated factory.

Keywords: cell control, cell control architectures, ICOSS

Introduction

An automated manufacturing cell typically consists of numerical control machines, industrial robots, storage devices, automatic inspection devices, tools and fixtures and control computers. The machine tools in the cell are physically interconnected by automated material handling devices such as conveyors, AGVs and robots. The information links within the cell are provided by communication networks ~. In an automated factory, each manufacturing cell contains enough components within itself to operate relatively independently of the rest of the system. A cell control system can take over much of the responsibility of running the cell from the higher level control system (e.g. shop control system), and this will lead to a highly decentralized control environment. However, the control of a manufacturing cell is a complex task that involves handling of many factors, such as different part types, different routes, small batch sizes and numerous shop floor un- certainties 2. A cell control system with the necessary intelligence and capability to orchestrate all the resources in a cell is essential for factory automation.

The ICOSS two-layer object-oriented approach offers a promising framework to this complex cell control problem. The ICOSS two-layer structure has an inner layer called an intelligent cell object (ICO) that is surrounded by an outer layer called the intelligent supporting shell (ISS). The ICO contains a generic cell

control knowledge core consisting of several functional modules such as scheduling, dispatching and monitoring. It would be ideal if a generic cell control system could be developed so that it can be applied to all different types of manufacturing cells. However, it might be quite impossible to design a completely generic cell control system which can act completely independently of the manufacturing needs of a cell. For example, the ICO modules designed for controlling machining cells may not be applicable to the control of electronic assembly cells.

The ICOSS, however, can provide a framework where the different types of cells can be accom- modated, though the current design only deals with the machining type of cells. In a machine shop, each cell has its own resources, parts and configuration, and this cell-specific information has to be well represented to control a particular manufacturing cell. The generic modules in the ICO can only perform its control functions in a specific cell by interacting with the cell environment. This portion of the cell control system we call the intelligent supporting shell (ISS), and it bears the identify of a particular cell; its constituents, capabilities and limitations.

A cell control system can be developed and enhanced more effectively by using this structure, since it provides a framework where the generic control knowledge and the cell-specific databases are stored in

100 0951-5240/94/02/0100-13 ~) 1994 Butterworth-Heinemann Ltd

two layers. This structure will be very effective where a factory requires frequent modifications or updates of the cell control program. The benefits of using such a cell control system will be significant when it is used with established networks, since the ICO update object(s) can be promptly transmitted. This paper describes the architecture and knowledge representation of the ICOSS two-layer cell control structure. The operation of ICOSS is discussed in more detail in a subsequent paper.

Cell control problems

The success of an automated factory depends on effective control of its components. Control may be at the factory level, the shop level, the cell level or at the equipment level. Higher level control tends to be complex, with slower reaction time and hence a real- time control is often difficult to achieve 3. Within an automated manufacturing facility, a cell control system monitors and controls events occurring in a manufacturing cell, and its needs to perform various functions.

The functions of a cell control system can vary depending on the size and the type of a cell, the degree of decision-making capability given to a cell, and so forth. An intelligent cell control system for the automated factory, however, needs to be designed to function in a decentralized control environment where the cell level can perform most of the decision-making regarding the operation of cell.

The major functions of a cell control system include the need to schedule and monitor cell resources, and the ability to react to abnormal conditions or exceptions. The cell control system schedules jobs, machines and other resources in the cell so as to achieve the goals/ commands from the higher control level (e.g. shop level). The scheduling function can again be broken down into several tasks such as resource and job analysis, sequencing, routing and the detailed operation scheduling. At the same time, the cell control system has to monitor the progress of jobs and the status of cell resources based on feedback from the equipment. The cell control system thereby maintains the current status of the cell. When an error or a problem occurs in the cell, the control system also need to recognize and properly correct the problem. In addition to the above functions, the cell control system has to perform several other functions such as the initialization and termina- tion of the cell operation, the communication and networking with the external systems, and the user interface 4. The cell control problem, therefore, is a complex task that involves decision-making activities while keeping up with real-time events. For this reason, the manufacturing cell control system has been a focus of study by a number of researchers -~.

Past approaches to cell control

As factory automation concepts become more widely

ICOSS: K H Lee and S Sen

implemented, the focus has been given to the improve- ment of cell controllers. In the past, this cell control function was basically taken care of by programmable logic controllers (PLC). PLCs, by using the ladder logic, have been very reliable controllers for supervising sequential events taking place in the cell. However, these PLCs cannot provide more advanced decision- making capabilities that are often needed for the control of complex automated manufacturing systems. PLCs will be continuously used in the shop floor wherever the sequential logic is required, but they will not be able to perform comprehensive cell control functions.

Specialized cell control computers with a better facility (e.g. file manipulation and status reporting) were then introduced as cell controllers. Some example systems include: VISTA 2000 by Allen Bradley, Inc., Mark Century 2000 by General Electric, TDC 3000 by Honeywell, the YEWMAC Controllers by Johnson Controls, Inc. Some systems such as the Pyramid Integrator by Allen Bradley, Inc. even use the workstation-level computers combined with the PLCs 9.

With the rapid advancement of computing technology, different types of computers have been introduced to perform the cell control function in addition to the above ones. They range from a microcomputer to a mainframe. Since the cell control system needs to function within a time constraint and often deals with very short planning horizons, most systems are concentrating on performing only monitoring functions. However, it is essential to provide decision- making capabilities at the cell control level to operate complex automated manufacturing systems. There have been many advanced cell control systems and architectures proposed, and some examples are given below:

1. Cell Control System for Automated Manufacturing Research Facility (AMRF) at National Institute of Standards and Technology (NIST).

2. Integrated Cell Control Architecture by A. Famili. 3. Cell Control Structure developed for Advanced

Factory Management System (AFMS) by Computer- Aided Manufacturing International t".

4. Cell Control System developed by Fanuc. 5. Discrete Cell Controller (DCC) to define generic

elements that can operate in an Open Systems environment tl

However, most of the above systems lack represent- ational and expressive power when building an intelligent factory controller, and artificial intelligence techniques provide some applicable methods to solve these problems 12. In the next section, some of the artificial intelligence-based systems are reviewed for further discussion.

AI-based approaches to cell control

Since the 1980s, artificial intelligence techniques have been recognized as tools with future potentials for

Computer Integrated Manufacturing Systems Volume 7 Number 2 101


planning and control of automated manufacturing systems. There has been some research done in the area of planning and scheduling that deals with the factory level or the shop level control problems. However, little research has been done in this area of AI-based cell control systems. So far, most of the related systems are at the conceptual research stage, and very few may be classified as being in the prototype stage ~3. Some of the Al-based cell control systems that have been developed are summarized below:

1. Transportable Cell (Transcell) - the system used a rulebase and a cell database model to manage machines in a heavy metal working cell 14.

2. CEMAS (Cell Management System) an expert system that used a rulebase with a knowledge acquisition module, and a cell database 15.

3. A Real-time Knowledge-based System for Robotic Work Cell - used a forward-chaining rule-based system with the least-commitment strategy, and the real-time scheduler that was able to predict the cell state a few minutes into the future by performing a faster-than-real-time emulation of the cell~6

4. Knowledge-based Supervisory Control System (KBSCS) - a prototype control system used a single blackboard framework with a rulebase and a semantic network17

5. The Knowledge-based Robotic Assembly Cell - developed at Purdue University, used frames to capture the global knowledge, but another method is also used to represent solid objects TM.

6. A Multi-pass Expert Control System (MPECS) - a conceptual system used a rulebase combined with a simulation model 19.

7. Production Logistics and Timings Organizer Intelli- gent Cell Control System (PLATO-Z ICCS) - developed at North Carolina State University, used a multiple blackboard architecture for intelligent cell control. The knowledge sources for the blackboards have taken several forms such as heuristic algorithms, optimizing procedures and sets of rules 4.

8. X-Cell - used an object-oriented approach to represent cell control functions. The three main modules considered are: scheduler, operation dispatcher and monitor 2°.

The need for a new architecture

The AI-based cell control systems generally contain three main components in their systems: the cell database (or the cell model), the knowledge base, and the reasoning method (or the problem solving method). The majority of the developed systems fall under the category of 'rule-based expert systems'. Rule-based expert systems are excellent tools, and have been successful for typically ill-defined manufacturing problems. However, since the cell control system deals with real-time events, rule-based systems with a large number of rules may not provide timely solutions to cell level problems. This calls for a knowledge representation

scheme that can represent different types of knowledge and data while still supporting the real-time environment. The ICOSS structure supports multiple knowledge representation schemes that include frames, rules and procedures under object-oriented programming paradigm.

Another problem of the early AI approaches to cell control is that they can only handle a part of the cell control functions. For example, Transcel114 only concen- trates on the operation of machines (e.g. robots and processing equipments) and lacks scheduling and error handling capabilities. Likewise, KBSCS 17 only generates operation sequences for the given job, and many other cell functions are not considered. This problem suggests a comprehensive cell control structure that can perform a variety of different types of decision-making activities in the feedforward mode of control (i.e. the scheduling of cell activities based on goals/commands from higher level systems), as well as the feedback mode of control (i.e. the response to changes occurring within the cell). The ICOSS provides a comprehensive architecture where various cell control functions can be addressed.

Two types of trends in the development of AI-based cell control systems are also observed: the top-down and bottom-up developments. In the top-down approach, the system focusses on the modules related to a more aggregate level of control, e.g. planning and scheduling modules. Systems such as CEMAS 1-s and MPECS 19 can be categorized under this approach. The bottom-up approach starts building the system from the detailed control modules, such as a vision system for handling the movements of workpieces ~8. At present, no system has completed its development all the way from the top to the bottom, or vice versa. A desired cell control system architecture should be able to bridge the gaps between these two approaches. One way to successfully address this problem is separating the generic control knowledge from the cell-specific databases in developing a cell control system.

In addition, a desired approach to the cell control modelling should be that of using reusable control modules which can be easily maintained and modified with changes in the environment. Such a new kind of modelling strategy leads us to the object-oriented programming paradigm. Object-oriented systems can be characterized by four major features: abstraction, encapsulation, inheritance and polymorphism 2~-23 They provide a unified, consistent and efficient method of knowledge representation, and provide many attractive features to model a manufacturing environment 24-28. There is a natural one-to-one correspondence between physical objects in a factory and software objects that represent them. Besides, the class and subclass relation- ships in an object-oriented system lead to a structured arrangement of manufacturing entities, and therefore manufacturing entities in a cell such as jobs, machines and tools can be represented in an efficient manner using the object hierarchy.

Many researchers have applied object-oriented approaches to represent the manufacturing resources;

1112 Computer Integrated Manufacturing Systems Volume 7 Number 2

however, they have rarely attempted to organize the manufacturing control knowledge using the object- oriented approach. Objects can also hold procedures in addition to data, and this provides the capability of keeping manufacturing control knowledge as a form of rules or procedures. Polymorphism also allows object- oriented systems to separate a generic function from its implementation, and this enables the structuring of control knowledge using generic methods. The control knowledge in the ICOSS is structured using these features of object-oriented programming.

Overa l l a r c h i t e c t u r e o f I C O S S

The ICOSS two-layer architecture is proposed for controlling the cell level activities, and Figure 1 schematically illustrates the cell level in the control hierarchy for an automated facility. The ICOSS-based cell control systems interact with the shop control system which operates one level above in the control hierarchy, and also interact with the equipment control systems below in the hierarchy by issuing commands, as well as receiving feedback from them.

The ICOSS structure consists of two layers: the ICO (Intelligent Cell Objects), and the ISS (Intelligent Supporting Shell). The ICO, which constitutes the inner layer of the ICOSS contains generic cell control modules that are common to all manufacturing cells. The ISS which constitutes the outer layer of tile ICOSS,


on the other hand, contains cell databases needed for a particular manufacturing cell. The functional modules in the ICO include: scheduling, dispatching, error handling, monitoring, communication and networking and a user interface. The ISS maintains the cell resource database, the cell status database, the parts database and the communications module. Figure 2 schematically illustrates the two-layer architecture of the ICOSS, with the major messages passed between the ICO modules indicated. In the ICOSS, all the modules are represented by object classes. Both the ICO and the ISS are top level object classes that consist of many lower level objects. The object classes in the ICO are hierarchically structured, and they inherit properties of the higher-level object classes. The cell databases included in the ICOSS are also represented by objects and object classes.

The control knowledge in the ICO is hierarchically structured using objects. The methods in the objects can be a set of production rules or algorithmic procedures, but they are organized under the object- oriented programming system. Polymorphism allows object-oriented systems to separate a generic function from its implementation, and this facilitates developing generic cell control knowledge in an incremental fashion. In addition, it provides efficiency in coding by having lhe standardized messages that can be responded by many different types of objects. This feature is extremely helpful, since the cell control system deals

Local Area Network

Mfg. Cell # 2

Mfg. Cell# 3

/ Cell Equipment # 1

, / ~ ~ e , , Other Cell Equipment

Cell Equipment # 2 Cell Equipment # 3

Figure 1 Control of an automated facility using the ICOSS-bascd cell control systems

Computer Integrated ManuJacturing Systems Volume 7 Number 2 103


Intelligent Cell Object (ICO)

~eorreetive_action ,.,ost

( Equipment controllers i i

Figure 2 ICOSS two-layer cell control architecture

)

with objects that represent many different cell hardware elements. For example, the same machine initialization message can be sent to the objects that represent different types of machines. Figure 3 shows the hierarchy of the ICO object classes that contain generic cell control knowledge in the area of job sequencing. The details of each object class and its generic methods are described in a later section.

The cell databases in the ISS are also represented by using a hierarchy of objects. Figure 4 shows the hierarchy of cell resource objects in the automated facility that primarily deals with machining operations. The cell status database and the parts database are all represented using the object structure. The details of each database are given in a later section.

This architecture also allows a modular development of the control system by transmitting the ICO update object(s) through the network. The related features are detailed in the next section.

Modular development of ICO

The ICOSS-based cell control system contains a generic

control knowledge (ICO) that can be applied to any cell control computer. When the cell control system needs to be updated or revised, the system is designed to transmit the update object(s) using the established network. The updated object(s) can be sent from a designated host cell control computer to all other cell control computers in the facility. Figure 5 schematically represents the transmission of the ICO update object(s)

' Figure 3 Representation of the ICO control know[edge (job sequencing cxamplc)



L Processing Equipment

I

I Material[ Handling

Equipment I

[M~hining I r~ ~ sc ~a~yl I center ] erial

Ha~ tlcr I dler

I r - i

Machining] [Machining] ]Fixed]lVariable

ICo°,oyorl i~ovl

Cell] I

I I

I Auxiliary

Equipment

I

; IIc~ouscal Shuttle I

I Positions

, L

I Inspection[ Equipment]

I

Figure 4 Reprcscntation of cell resource objects

Manufacturing Cell # 1 Control System


regular cell-to-cell, cell-to-shop messages

Local Area Network



Figure 5 Schematic representation of the ICO update through the commtmication network

using the communication network. The revised objects or new objects have to be created and tested off-line. When these objects are ready, they can be loaded to the designated host computer, and can be transmitted through the network. The cell control systems at the receiving end recognize this ICO update object(s) and replace the old object by the revised one. The cell

control systems perform this task by searching the lookup table that contains the entire list of object classes and their generic methods. Some of the generic methods defined to perform this task are detailed in the section describing the communication and networking manager of the ICO.

The ICO revision using the network will save a great


1COSS: K H Lee and S Sen

deal of effort compared to installing the ICO update object(s) on each cell control computer. This feature supports reusability, maintainability and modularity of software objects, which are also consistent with the objectives of obj ect-oriented programming. The current architecture only addresses swapping or adding of the ICO update objects based on the look-up table. However , this ICO swapping can be evolved to a mechanism that incorporates an intelligent behaviour such as the negotiation metaphor shown in blackboard- based systems.

Intelligent Cell Objects

The ICO is an intelligent cell control program that contains the control modules necessary for supervising a manufacturing cell. Each control function is represented by different object class and the generic methods associated with it. The ICO consists of several classes of objects that perform cell control functions such as scheduling, dispatching, error handling, monitoring, communication and networking and user interface.

The scheduling module supervises overall cell activities by scheduling jobs and resources based on the current cell capacity. The dispatching module generates a detailed schedule of operations for the jobs released from the scheduling module, and dispatches the operation requests to the equipment level. The error handling module takes care of the abnormal cell activities such as machine breakdowns and tool breakages. The monitoring module keeps track of the status of all the resources and the parts in the cell by receiving the feedback data from the equipment level. The communication and networking module provides the communication links to the external control systems such as the shop control system and other cell control systems. The user interface module provides for the user the tools with which to perform various tasks such as modifying cell databases and manipulating cell operations. The functional details of each module and the generic methods included in each object class are described below.

Scheduler

This first determines whether a job can be processed at the cell or not. Each job comes with its process plan and the expected completion date. It assigns the cell resources such as machine tools and tooling for each incoming job. It also reassigns the cell resources when it needs to respond to the error conditions occurring in the cell. It performs tasks such as resource availability checking, job sequencing and resource assignment. This module therefore contains generic control knowledge related to supervising overall cell activities such as a variety of different priority dispatching heuristics for jobs and transporters. The scheduler needs to access the cell resource database to perform the above- mentioned functions. An object class called 'scheduling' contains several methods to accomplish the above task. The generic methods in the scheduler include: Receive-

Job, Cancel Job, AssignResource, Sequence Jobs, Build- Route and Release Job:

• Receive Job: this method receives a job and checks whether it can be processed at the cell. If it can, the job will be added to the jobs list. The job data including the process plan information is retrieved by this method.

• CancelJob: this method deletes a job from the jobs list when a specific job is no longer processable at the cell.

• Sequence Jobs: this method sorts the jobs based on the given priority dispatching rule such as Earliest- DueDate-Rule , FIFO-Rule and SPT-Rule. This method is triggered when a new job arrives at the cell or when other rescheduling needs arise.

• AssignResource: this method finds the machine tool that is needed to perform each operation in the job's process plan. It selects a machine based on its operational status. When errors occur in the cell, it assigns alternative machines for the problem job.

• BuiIdRoute: this method generates a route for each job. The route data includes the sequence of machines visited with the operations performed on each machine. More specialized methods like Build- Pr imaryRoute and BuildAlternateRoute are called, depending on the status of the machines available.

• ReleaseJob: this method releases a job to the dispatcher so that it can assign exact time windows on the resources necessary to process the job. In releasing a job, the first job in the ordered list is selected, and it also checks the availability of the raw materials and the machines.

Dispatcher

Receives a job information from the scheduler, provides a time window for each operation on a machine, and generates detailed operation requests. It also handles a calender of events that reflects the progress of the operations in the cell. Once it finalizes the schedule with specific time windows on the required resources, this detailed schedule is then passed on to the equipment controller as a form of operation requests. The operation requests are passed to the equipment controllers using the methods in the communication module. It can also respond to the corrective action requests to some extent. The corrective action here is usually limited to a small change from the original schedule that can be resolved by adjusting the time windows reserved on the resources. The dispatcher needs to access the cell status database while performing these tasks. The generic methods that perform dispatcher functions are described below:

• ReserveTimewindows: this method receives job information from the scheduler and establishes reservation on every resource that is needed for the job.

• CancelTimewindows: this method receives a job cancellation request from the scheduler and cancels the reservations made on the resources.


• AdjustTimewindows: this method receives job delay information from the error handler and adjusts the reservations made on the resources.

• DispatchOperations: this method issues operation requests to the equipment controllers.

• HandleCalendarEvents: a 'calendar' of events is maintained with each operation's identification, time and location (i.e machine number). This method uses a series of specialized methods such as Initialize- Calendar, SortCalendar, UpdateCalendar, Lookup- Calendar and HandleEvent. The method Handle- Event again uses more specialized methods to manage different kinds of events.

Some of the specialized methods used in the dispatcher while establishing a list of operations for processing a job are as follows:

• FindMaterialHandler: this method finds the material handling device for a machine.

• FindAltMaterialHandler: this method finds the alternative material handling device when the primary material handling device for a machine has problems.

• FindHandlingLinks: this method finds a list of material handling moves to be made for a job to be completed.

Monitor

Monitors the events taking place in the cell by keeping track of the current status of each individual cell resource as well as parts. It reports and displays major events, thereby constantly keeping the other ICOSS modules informed about changes in the cell and the result of such changes. The status of the cell changes as different events occur within the cell. Such events may be operation-start , operation-finish, machine- breakdown, material-handling-start and material- handling-finish. Each of these events changes the cell status, and may require some actions. The monitor constantly needs to interact with the cell status database. The monitor needs to identify the cell resources and the physical links between them to mainain an exact configuration information of the resources. It also needs the capability of updating the configuration of a cell when a machine is added or removed from the cell. The monitor initially provides for this cell configuration information by interacting with the cell resource database in the ISS. The generic methods that perform these monitoring tasks are described below:

• MonitorEquipment: this method is in charge of monitoring the status of individual equipment. Some examples of more specialized methods are: Monitor- Processing Equipment, MonitorRobot and Monitor- Conveyor. These methods report the events such as setup completions, operation completions and machine breakdowns.

• MonitorParts: this method monitors the number of workpieces entering the cell, the parts at each station, the number of scrapped workpieces and the number of finished parts. It reports the major status changes of parts to higher level objects.


• MonitorTools: this method ensures proper tooling for each operation. It identifies the current tool on each machine. Some of the related methods include monitoring the tool availability and the tool wear. MonitorToolAvailability checks the availability of tools and tool holders that are to be located at the storage magazines, at the machines or at the tool crib~ The specialized method MonitorToolWear accumulates the time spent by a tool in machining operations, and compares it with the expected tool life. When the tool reaches its life expectancy, the method asks for a tool change.

• MonitorPallets: this method monitors the locations and types of pallets for holding the workpieces.

• MonitorCommunicat ionLink: this method ensures communication links to all pieces of equipment. For example, if a machine controller does not respond to the message of this method in a certain period of time, the communication line will be reported as having an abnormal condition.

• MonitorStatistics: this method is responsible for collecting statistics on jobs and resources. It contains several specialized methods to perform this function. MonitorUtil calculates the utilization of each machine tool. MonitorQueue collects statistics of the queue length at each machine. MonitorLeadTime calculates the throughput time of each job completed at the cell.

• ListEquipment: this method identifies the different pieces of equipment in the cell, and maintains the list of cell equipment.

• Link Equipment: this method identifies the material handling link between machines. It includes the handling device, the distance between machines, the transfer speed and the direction of moves. It also specifies the buffer positions at each workstation.

• DetectNewEquipment: this method recognizes hardware changes made to the cell. It assumes a message from the new equipment controller.

Error handler

This contains the generic procedures related to correcting the abnormal cell activities due to events like machine breakdown and tool breakages. This module currently contains generic routines that can respond to different types of machine or tool errors that are already identified by the equipment controllers. It is assumed that the equipment controllers have machine-specific error detection routines that can identify the cause of errors based on the sensory data. It is also assumed that the equipment controllers have diagnosis and recovery routines for the corresponding equipment.

The generic methods in the error handler module ensure the viable operation of the cell under different types of cell errors. For example, three different types of machine tool errors have been identified: errors that only require adjustment of time windows at the assigned machine; errors that require an alternative machine to process the troubled job; and errors that cause a job to be removed from the current cell. Based



on the type of machine tool error, the error handler can recommend necessary corrective action. The generic methods currently included in the error handler are:

• lnterpretError: this method interprets and classifies the error messages reported from the equipment controllers.

• FindCorrectiveAction: this method recommends the desired corrective action to the identified error. This is a generic method that requires the development of more specialized methods which can deal with different types of errors, such as machine errors, tool errors, robot errors and workpiece errors.

• ScheduleCorrectiveAction: this method schedules the corrective actions and sends the corrective action request to the appropriate module. For example, it sends a job rescheduling request to the scheduler for a machine breakdown, and a time window adjustment request to the dispatcher for a tool breakage.

Communication and Networking Manager

The communication function is vital in establishing information links in a factory. It allows the cell control computer to interact with the shop level control computer , the other cell control computers, and the intercell transport system (e.g. AGVS). It is responsible for linking the cell control system with the external control systems. All the messages passed between the control systems must follow the standard communication protocols available in the computer network system. Some of the generic methods performing this function are:

• ReportResourceStatus: this method reports the operational status of cell resources to the shop control system. For example, the breakdown of a machine can be notified using this method.

• ReportJobStatus: this method reports the status of a job to the shop control system. Generally, this method is called when a job is completed; however, an abnormal completion of a job can be reported using this method.

• RequestTransport: this method asks for the intercell transporter to move the raw material or finished parts.

In the ICOSS-based cell control system, the ICO objects can be updated by sending the object through the network whenever a revision is made on the control system. The communication manager receives the new ICO objects, and takes care of replacing the existing objects by the new objects. The generic methods perform this task are described below:

• DetectlCO: this method recognizes a new ICO object by its name, size, the sender and a particular tag attached to it. Upon recognition, it will invoke the method PreplCOswap.

• PreplCOswap: this method looks into where the new ICO object belongs, and finds the existing object to be replaced. It ensures the swapping operation by keeping the existing one from execution until it is

replaced. It invokes the method ExecutelCOswap when the preparation is completed.

• ExecutelCOswap: this method deletes the existing ICO object and allows the new ICO object in commission. It uses a more specialized method, DeleteOldlCO, for deleting an ICO object.

• ICOswapCompletion: this method sends a message to the sender in acknowledgement of a successful ICO replacement at the cell.

• LoadlCO: this method loads the new ICO objects at the control computer that will act as the sender. The new ICO objects have to be developed off-line.

• SendlCO: this method sends the new ICO object(s) to the other cell control computers on the network. This method is used only at the control computer that sends out ICO update object(s).

User interface

The user interface provides many features, such as starting and stopping cell operations, and requesting information on any job or resources in the cell. It also allows the user to input or update the cell databases. The user interface function uses a window-based interface that provides user-friendly communication with the cell control computer. The generic methods contained in this class are as follows:

• CellOperations: the operation of the cell can be initiated, terminated, temporarily stopped or resumed using this method. More specialized methods such as Celllnitialize, CellTerminate,CellStop or CellResume are included in this task.

• lnterfaceCellResourceDatabase: this method provides an access to the cell resource database, and allows the user to add, list or update the resource objects in the database.

• InterfaceCellStatusDatabase: this method provides an access to the cell status database, and allows the user to add, list or update the cell status data in the database.

• InterfacePartsDatabase: this method provides an access to the parts database, and allows the user to add, list or update the parts data in the database.

• TestRunObject: this method is primarily used in the development phase to test the operation of ICOSS modules. For example, the user can test the operation of the scheduler by manually sending a new job to the scheduling object.

Intelligent Supporting Shell

The Intelligent Supporting Shell (ISS) is the outer layer of the ICOSS cell control architecture which contains the knowledge needed to set up an environment so that the ICO can operate. The ISS contains cell databases and the communication module, which provides an essential layer for the ICO to interact with the cell environment. The cell databases included in the ISS are: cell resource database, cell status database and parts database. The intelligent supporting shell is also


built on the object structure. The cell databases and communication module in the ISS are described in detail in this section.

Cell resource database

The cell resources are organized by a hierarchy of object classes and instances. At the top it has a class called 'cell', and five subclasses that represent processing equipment, auxiliary equipment, material handling equipment, storage equipment and inspection equipment, respectively. Each of these subclasses further break down into more specific classes of objects, as previously shown in Figure 4. For example, the class "processing equipment' can have subclasses 'machining centre', "turning centre', 'grinder' and 'saw'. The machining centre class can be further broken down into subclasses such as 'vertical machining centre' and 'horizontal machining centre'. Finally, each object


representing a specific cell resource such as 'KIWA-510 vertical machining centre', as shown in Figure 6, can be created as an instance of the class 'vertical machining centre'. In this process, the properties of higher level objects are inherited by the lower level objects, and at times the properties of lower level objects override the values specified by the higher level objects. THe KIWA 510 vertical machining centre instance has many attributes related to the cell configuration (e.g. list-of- material-handlers, reachable-workstations) as well as the machine specifications (e.g. x, y, z-travel, repeat- ability). The machine specification data will be utilized when the cell controller deciding on the processability of a new operation assigned to the cell. Figure 6 also shows some methods (e.g. update-material-handlers) that are applicable to all the instances belong to the vertical machining centre class.

The ICOSS modules need to access this database for

Machining Center Class

Vertical Machining Center Class

* Fmd~al~attv©~m~at~handter i i i i i i i i i i i i i i i i i i i i i ! i !

iiiiii,!iiiiiiii • H

+~ >1 + : +

ii~iiiliiiiiiii i~ iiiiiii~

i!ii~ ii~i :!:!

Configuration-related-data : : : ! , List-of-primary-material-handler 'Mini-Cam'ac ii:i:!- List-of-secondary-material-handler AGV 1

• Pm-lo~d,r 'SCOP.BOT-ER V :~:~! * Reachable-workstations '((ws#1 one-way mini-cartrac ........ • Number-of-input-buffer-positions 2 iii:i! * Number-of-output-buffc/-positions 2

Machine-specification-data : :: • List-of-capable-operations '(op#10, op#20, op#30 ....... )

List-of-tools '(end-miU-tooll end-mill-tool-2 drill-tooll ...) ii:: :::,::: :x-y-z-travel '(20 14 12)

i Horse-power '7.5 Tool-magazine-capacity '16

~!;I Maximum-spindle-speed '20000 Number-of-axes '3

• Controller-type 'Fanuc

10 ft)..)

J

Figure 6 Object-oriented representation of cell resources (vertical machining centre example)



various reasons, such as determining the processability of a part, finding an alternate machine, and finding the material handling link between two machines. The scheduler accesses this database to determine whether a particular operation can be performed on a particular machine. It also contains information about the physical links between equipment. For example, the following information is kept for each machine tool: what material handling equipment is serving it, what is the type of link between the machines (one- or two-way), the speed of the material handler, what other machines are linked to this machine, the distances between machines, etc.

Cell status database

The cell status database describes the current status of machines and parts in the cell. A machine tool object represents its status by maintaining the following attributes: machine-id, machine-status, current-part and current-operation. A part object in the cell status database represents the current status of each part, with the following attributes: job-id, part-id, part- status, current-location and current-operation. It is accessed whenever the status of a cell hardware element or the status of a part is requested. The dispatcher can determine the next operation by considering the current status of machines, robots, parts, operations in progress and time. The monitor also interacts with the cell status database constantly. Figure 7 shows the major elements represented in the cell status database.

Parts database

The part/job database contains information about the different types of jobs visiting the cell. The parts/jobs data are represented using a hierarchy of objects. An instance representing a part contains the following information: job-id, part-id, quantity, list of required operations, alternative operations, required tools, expected arrival time, expected finish time, priority, current part location, current operation performed on the part, and part status. However, as shown in Figure

PART * • job- id

I " par t - id • p-s ta tus

I " c u r r - i o c a t i o n

I . cur r -op

TOOL • too l - id • t -s ta tus

I . locat ion I " cur r -op

• f i n ish- t ime

I TIME • cur r - t ime I

MACHINE • machine- id

I • m-status I , cur r -par t 1, cur r -op

• f in ish- t ime

BUFFER I, buffer-id 1- b - s t a t u s

I " no-o f -par ts I . c a p a c i t y

I RCSOT • robot- id • r -status • curr -par t • current-op • f in ish- t ime

OP-REQUEST • op- id • part- id

I • ass igned-resource [ , star t - t ime I , f in ish- t ime I o op-status

Figure 7 Cell status databasc

8, not all of these attributes have to be provided for creating each instance of parts. The part type class specifies the attributes that can be applied to all the jobs with the same part type, and these attributes can be accessed from the job class and the part instances. The job class specifies the attributes regarding the specific job, and these attributes can also be inherited down to the part instances. The cell control system needs to provide the following attributes when it creates every part instance: part-id, current-location, current-operation, op-start-time, op-finish-time and part-status. The other attributes, such as the list of required operations and tools, can be supplied by the higher level classes in the parts object hierarchy.

The part instances also inherit methods (or procedures) from the antecedent classes. Some of these methods include: find-the-next-operation-to-perform, find-alternative-operation, find-#-of-operations-to-be- performed, check-job-status, etc.

Communication module

This provides communication links to the controllers of the equipment belonging to the cell. When an equipment is to be initialized/terminated, or a specific operation request has to be issued to the equipment, the cell control system uses this module to communicate with the equipment. The communication module requires an equipment driver that contains the communication routine as well as the communication parameters for each individual equipment. More specialized methods need to be used for different types of equipment controllers. The generic methods defined in this module are as follows:

• OperationRequest: this method sends an operation request to a specific machine. The object representing the receiving machine for this message always has to be specified for this method. The message used by this method has the following format:

(operation request assigned-resource operation-id part-id start-time finish-time status)

• RecognizeOperationFeedback: recognizes the operation status feedback received from the equipment controllers. This method makes appropriate changes regarding the operation status in the cell status database.

• RecognizeResourceStatus: recognizes the status of individual cell resources reported from the equipment controllers, and updates the cell status database. The breakdown of machines, robots and tool problems can be recognized by this method.

• RecognizePartStatus: recognizes the status of each part while it is processed in the cell. The equipment controllers send a message whenever a major status change occurs to a part, such as the completion of an



Part Tc~e Class

.lob Class

Part Instances

• Part-type

• Required-operations & machines

• Alternative-operations & machines

• Required-tools

Job-id : ABC001 Quantity : 2 E-A-T : 11/29/93 E-F-T : 11/30/93 Job-status : in-progress Priority : 1

Job-id : ABC002 O O O 0 Quantity : 10 E-A-T : 11/29/93 E-F-T : 12/04/93 Job-status : waiting Priodty: 2

0 0 0 0 0 0 0 0

Part-id : ABC001-1 Current-location : Mill-1 Current-operation : op#10 op-start-time : 17:30_11/29/93 op-finish-time : 18:30_11/30/93 Part-status : in-process

Part-id : ABC00I-2 Current-location : Lathe-2 Current-operation : op#30 op-start-time : 17:00_11/29/93 op-finish-time : 19:30_12/01/93 Part-status : in-process

Figure 8 Representation of parts data

operat ion or the part jam at the machine. The method recognizes these changes and makes corresponding changes at the cell status database.

• InitializeResource: sends a message 'initializeresource ' to the machine tools and material handlers in the cell. It sends the same message to each object representing a different machine that has a different initialization routine. A robot will perform the home positioning, and a CNC machine will move the worktable to the home zero position by checking backlashes in x, y and z axes. But they will all respond to the same message.

• StopOperation: sends a message to temporari ly stop the operat ion of a machine.

• ResumeOperat ion: sends a message to resume the operat ion of a machine.

• TerminateOperation: sends a message to each machine to stop the operat ion, go to the home position, and disconnect the power to the machine.

C o n c l u s i o n

This paper addresses a cell control architecture that applies object-or iented programming to the problem of manufacturing cell control. The paper describes the

two-layer architecture that treats the generic cell control knowledge and the cell-specific databases separately. The ICOSS two-layer structure allows more efficiency in developing and implementing the cell control system by separating the control information into two layers. In the ICOSS, both the cell control knowledge and the cell databases were represented using the object hierarchy. The reusability and extens- ibility of objects enable a development platform where a cell control system can be developed gradually. In addition, the idea of updating the cell control knowledge object(s) through the network will provide more efficiency to an automated factory which requires frequent modifications or updates of cell control programs. The ICOSS-based cell control system can take advantage of the automated manufacturing environment where the control computers and networks are well established as the essential ingredients of the system.

R e f e r e n c e s

1 Pimentel, J R Communication Networks for Manufacturing, Prentice Hall, Englewood Cliffs. NJ (1990)

Computer Integrated ManuJacturing Systems Volume 7 Number 2 111


2 Bourne, D A and Fox, M S 'Automated manufacturing: automating the job-shop', IEEE Computer, Vol 17 No 9 (1984) pp 76-86

3 0 ' G r a d y , P J, Bao, lrl and Lee, K H 'Issues in intelligent cell control for flexible manufacturing systems', Computers in Ind. (September 1987) pp 25-36

4 0 ' G r a d y , P J and Lee, K H 'An intelligent cell control system for automated manufacturing', Int. J. Prod. Res., Vol 26 (May 1988) pp 845-861

5 DiCesare, F, Goldbogen, G, Langan, D, Rajan, S and Desrochers, A 'Functions of a manufacturing workstation controller', Proc. IEEE Int. Conf. on Robotics and Automation, San Francisco, CA (1986) pp 1470-1475

6 Famili, A 'An integrated software architecture for automated manufacturing workcells', Robots Conf. Proc., Chicago, IL (April 1986) pp 3.1-3.14

7 0 n o , Y 'Cell control system', Robotics & Comput. lnteg. Manu., Vol 3 (1987) pp 389-393

8 Franks, I T, Loftus, M and Wood, N T A 'Discrete cell control', Int. J. Prod. Res., Vol 28 (1990) pp 1623-1633

9 Larln, D J 'Cell control: what we have, what we'll need', Manuf. Eng., Vol 102 No 1 (January 1989) pp 4148

10 CAM-I, Inc. Conceptual Information Model for an Advanced Factory Management System, Factory & Jobshop Level Final Report R-84-FM-03,1 (August 1984)

I1 Franks, I T, Loftus, M and Wood, N T A 'Generic manufacturing cell control', Int. J. Operations & Prod. Manage., Vol 11 No 4 (1991) pp 20-32

12 Larner, D L 'Factories, objects, and blackboards', A1 Expert, Vol 5 No 4 (April 1990) pp 38-45

13 Steffen, M S 'A survey of artificial intelligence-based scheduling systems', Fall Ind. Eng. Conf. Proc., Boston, MA (1986) pp 395-405

14 Wright, P K, Bourne, D A, Colyer, J P, Schatz, G S and Isasl, J A E 'A flexible manufacturing cell for swaging', Mech. Eng., Vol 104 No 10 (October 1982) pp 76-83

15 Gliviak, F, Kubis, J, Micovsky, A and Karabinosova, E 'A manufacturing cell management systems (CEMAS)', in Artificial Intelligence and Information Control ,Systems of Robots (I Plander, ed.), Elsevier, Amsterdam (1984)pp. 15.3-156

16 Newman, P A and Kempf, K G 'Opportunistic scheduling for

robotic machine tending', IEEE 2nd Conf. on Artif. Intell. Applic., Miami Beach, FL (1985) pp 168-175

17 Young, R E, ttwang, J and Messimer, S A Knowledge-based Supervisory Control ,System for a Flexible Manufacturing System, Industrial Automation Laboratory, Departmcnt of Industrial Engineering, Texas A&M University, IAL-86-1a (1986)

18 Kak, A C, Boyer, K L, Chen, C tt, Safranek, R J and Yang, H S 'A knowledge-based robotic assembly cell', IEEE Expert, Vol 1 No 1 (Spring 1986) pp 63-83

19 Wysk, R A, Wu, S and Yang, N 'A multi-passd expert control system (MPECS) for flexible manufacturing systems: Real-time optimization in automated manufacturing facilitics', Proc. ,Symposium National Bureau of Standards, Gaithcrsburg, MD (January 1988) pp 251-278

20 O'Grady, P J and Ramadurai, S 'Operation of X-Cell - intelligent cell control system (Part 1I), Comput.-Integrated Manuf. Syst., Vol 5 No 1 (February 1992) pp 21-30

21 Robson, D 'Object-oriented software systems', Byte, Vol 6 No 8 (August 1981) pp 74--78

22 Cox, B J 'Message/object programming: an evolutionary change in programming technology', IEEE Software, Vol I No 1 (January 1984) pp 49-61

23 Stefik, M and Bobrow, D G 'Object-oriented programming: themes and variations', The AI Magazine, Vol 6 No 4 (Winter 1985) pp 40-62

24 Ulgen, O M and Thomasma, T 'SmartSim: an object oriented simulation program generator for manufacturing systems', lnt. J. Prod. Res., Vol 28 (1990) pp 1713-1730

25 Glassey, C R and Adiga, S 'Berkeley library of objects for control and simulations of manufacturing (BLOCS/M), in Applications of Object-Oriented Programming (L J Pinson and R S Wiener, eds.), Addison Wesley, Reading, MA (1990)

26 Mize, J, Bhuskute, H C, Pratt, D B and Kamath, M 'Modeling integrated manufacturing systems using an object-oriented approach', l ie Trans., Vol 24 (July 1992) pp 14-26

27 Weber, D and Moodle, C L 'An intelligent information system for an automated, integrated manufacturing system', J. Manuf. Syst., Vol 8 (1990) pp 99-113

28 Hekmatpour, A, Orailloglu, A and Chau, P 'Hierarchical modeling of the VLSI design process', IEEE Expert, Vol 6 No 2 (April 1991) pp 56-70


icoss: a two-layer object-based intelligent cell control architecture

Documents