Proceedings of the 1995 IEEE International Conference on Systems, Man, and Cybernetics, Vancouver, BC, Oct. 22-25, 1995, pp. 3437-3442
AN INTEGRATED APPROACH TO MODELING DISTRIBUTED MANUFACTURING CONTROL AND HUMAN OPERATORS Douglas A. Bodner, T. Govindaraj, Leon F. McGinnis, and Christine M. Mitchell School of Industrial and Systems Engineering Georgia Institute of Technology, Atlanta, GA 30332-0205, USA Tel: +1 404 894-2373 Email:
[email protected] ABSTRACT
Manufacturing systems are experiencing several trends which are increasing the importance of the control system as a component of the overall manufacturing system. Among these trends are increased levels of automation, increasing differentiation and customization of products, and increased demands on system performance. A control system must coordinate the various activities of a manufacturing operation so that requirements and performance goals are met. Most manufacturing control systems are distributed in nature and incorporate both computerized controllers and human operators. There are few generic modeling approaches, however, which represent interactions between these manufacturing control entities. This research proposes a modeling approach which synthesizes a generic architecture for modeling computerized manufacturing control and the operator function model (OFM), a methodology to model operator actions and tasks in complex systems. This approach is based on an underlying client-server representation and has the potential to facilitate design and prototyping of manufacturing control systems. I. INTRODUCTION1
Shop floor control is becoming an increasingly important function in modern discrete-parts manufacturing systems. This importance derives from several trends. These trends include increased levels of automation and integration, shorter product life cycles, and increased product differentiation and customization. Perhaps most important is the increased emphasis on system performance to justify high software development and equipment costs, and to ensure viability in today’s competitive business environment. The control system must coordinate the activities of the manufacturing system to meet production requirements in real time. Production requirements may be expressed as (i) manufacturing the desired products and (ii) meeting performance targets (e.g., in terms of throughput, quality, etc.). Research in manufacturing shop floor control has identified several major areas which need further research. In general, these areas are (i) rapid prototyping of manufacturing control systems [3], (ii) formal models of control tasks and interactions between control entities [20], (iii) increased need 1 This work was supported in part by the National Science Foundation under grant DDM-9102370.
for software engineering [7], [15], and (iv) generic control architectures and models [4], [9], [22]. However, little work in manufacturing control includes the formal representation of the human operator as an element of the control system. This is evident despite trends toward a changing role for the human operator in automated manufacturing systems. Increasingly in such automated systems, the human operator performs supervisory functions rather than manual operations [17], [18]. In the process, the operator is becoming more important in the control of the system. In many instances, systems can exhibit degraded performance if they have poorly designed automation or poorly understood technology from the operator’s perspective [17]. Thus, it is important to consider both the automated and human components of the control system in the design phase [14]. There is a need for a modeling approach which includes both, as well. This paper proposes an integrated approach to modeling the human operator within a computerized manufacturing control environment. This is achieved through a combination of a previously developed control modeling architecture [13] and the operator function model (OFM) methodology [11]. In this paper, we first survey approaches to modeling system control. We then discuss the importance of domain analysis as a prerequisite for modeling and present a domain analysis of manufacturing control. Next, we present a control modeling approach which incorporates a user-centered component and an automation-centered component. Finally, we conclude with some thoughts on future research. II. MODELING APPROACHES
Research in the area of manufacturing control has led to a variety of modeling approaches. Most of these approaches, however, neglect the role of the human operator as a decisionmaker in the system. This section discusses approaches to the modeling of manufacturing control. A. Control Modeling Approaches There are various approaches to modeling manufacturing control systems. Two major categories of approaches are reference models and traditional modeling tools. A reference model is a normative standard for a type of system based on a commonly agreed upon conception [23]. A modeling tool, on the other hand, embodies a language of building blocks, or modeling abstractions, which are used to model a system for
a specific type of analysis (either normative or descriptive). In general, reference models pertain to a specific domain, such as manufacturing, and modeling tools are somewhat domain-independent. The literature contains several different proposed reference models for aspects of manufacturing control (e.g., [4], [9], [20], [22]). These share the common purpose of serving as guidelines for the design of control systems and software. Due to the variety of reference models proposed, though, no single reference model has gained wide acceptance in practice. Furthermore, none address the role of human operators in control of manufacturing. Examples of traditional modeling tools include queueing networks, Petri nets and discrete-event simulation. Each of these tools has specific characteristics which make it useful for some problems, but limit its use in others. In manufacturing, for example, traditional approaches to discrete-event simulation are well-suited to modeling physical processes such as part flows, but are somewhat limited in their representation of control [16]. Petri nets are useful because they represent the asynchronous and concurrent behavior found in automated manufacturing systems, and because they have a firm mathematical basis [24]. However, they are difficult to use in modeling complex systems due to the size and complexity of the network representation. Gong and McGinnis [8] point out several problems with the existing set of reference models and modeling tools with respect to the manufacturing domain. The fundamental problem which they cite is the lack of a unifying conceptual model or language for manufacturing. This situation manifests itself in two other problems: proposed reference models do not have an overall view of manufacturing, and existing modeling tools lack mutually consistent data representations. Their observations hold for manufacturing control, also. They propose the concept of a meta-model for manufacturing systems. This approach combines reference models developed for different aspects of manufacturing into a common framework for data consistency. It allows a modeler to use this consistent set of data for various analysis tasks with different modeling tools (e.g., simulation) [8]. The structure used for a modeling tool to access this data is called a template. This research is concerned with integrating a reference model for manufacturing control with two modeling tools: one for automated control, and the other for human-centered control. Potentially, this approach can be incorporated into a meta-model of manufacturing systems. We now discuss the reference model and the two modeling tools. B. The OOSIM Control Modeling Architecture OOSIM is an object-oriented approach to modeling manufacturing systems. Its origins lie in the appeal of the objectoriented programming (OOP) paradigm as a modeling language for manufacturing systems [12]. OOSIM explicitly
represents the manufacturing control system through a decomposition between plant and control [13]. In fact, the explicit representation of control within manufacturing models characterizes much OOP-based manufacturing simulation research [12]. OOSIM contains a reference model for automated manufacturing control systems in its representation of controllers and their interactions with one another and with the rest of the factory. It also contains a modeling tool in the form of discrete-event simulation. The fundamental object in this reference model is the controller, which is a model of computerbased controllers on the shop floor. A controller object has knowledge about other entities in the system, communicates with various entities, and makes decisions in real-time. In this research, controllers are event-driven entities in that they respond to events (messages) by making decisions (similar to [3]). The OOSIM reference model prescribes a representation of controller knowledge and also provides a structure for decision-making scripts. Controllers interact with other objects via a client-server relationship. Thus, this reference model supports both hierarchic and heterarchic control models. Figure 1 shows a controller object’s behavior. Controller (server) Communication Decision Logic
Service requests
Knowledge
Commands and status messages Sub-system or component being controlled
Other controllers (i.e., clients) Figure 1. Controller behavior
C. The OFM Methodology The operator function model (OFM) methodology is a modeling tool which captures operator interaction with automated systems through the explicit representation of tasks and information flows [11]. A model consists of a set of nodes organized into a hierarchy. The nodes in each level represent various operator tasks and functions. As one proceeds down the hierarchy, the nodes successively represent high level operator functions, then lower level sub-functions, and finally individual operator tasks. The tasks may be cognitive
Decomposition of nodes
3
3.1
3.2 Sub-functions of a major function node
3.3
Tasks associated with a sub-function 3.3.1
3.3.2
3.3.3
Explanation of Nodes in the Model 1. Reconfigure system for new product 2. Monitor system 3. Tend machines 3.1. Adjust machine
3.2. Handle machine failure 3.3. Replace component reel 3.3.1. Remove old reel 3.3.2. Load new reel 3.3.3. Restart machine
Figure 2. Operator function model
The OFM methodology has been used successfully in several domains, ranging from manufacturing [1], [7] to automated cockpits [5], to satellite ground control systems [10], [11]. It has primarily been used to model operator control tasks, but recent work is extending it to monitoring tasks [21]. It is most appropriately used in complex and dynamic engineering systems in which operators respond to events and manage system activities. The OFM methodology is useful in this research because it can be used as a design tool for usercentered manufacturing control systems. III. DOMAIN ANALYSIS OF MANUFACTURING CONTROL
Modeling approaches depend heavily on knowledge underlying the domains in which they are applied. Domain analysis is the process of capturing and organizing knowledge about a particular domain for software modeling purposes [2]. It is an important element in developing both reference models and reusable abstractions for modeling tools. Reference models typically focus on normative knowledge (i.e., characteristics a system should have), whereas
Plant
Processing
2
Interface
Major operator functions
1
modeling tools focus on descriptive knowledge (i.e., characteristics a system actually has). This section describes a common view of domain analysis which serves to create a basis for a consistent representation of manufacturing control for automated control and human supervisory control. The domain of interest here is control of highly automated, discrete-parts manufacturing systems. The OOSIM domain analysis, described in greater detail in [13], views manufacturing from the perspectives of plant vs. control and process vs. logistics. Figure 3 shows this framework in terms of the entities, activities and interactions. In this framework, the control system has two major functions: processing material and transporting material between processing steps. The plant consists of the machines and transport devices which actually accomplish these functions; the control system consists of the set of decision-making entities which interact with one another to coordinate actions on the shop floor. The decisionmaking entities function as a distributed set of computers, programmable logic controllers, and human operators. The OOSIM control reference model derived from this framework focuses on computerized decision-making entities [13]. Here, we extend the reference model by explicitly incorporating the role of human operators into the domain analysis of manufacturing.
Transportation
or physical in nature. Each level decomposes nodes above it in the hierarchy into a heterarchic set of nodes which represent sub-functions, tasks, or information needs. Transitions between nodes represent events or shifts in operator activities. Figure 2 shows a simplified example of an OFM from an automated electronics assembly system described in [13]. It shows the decomposition of the operator function of tending assembly machines. It also shows the decomposition of the sub-function of replacing an empty reel of components.
• Machines • Operations • Storage buffers • Material processing • Setup
Interface Commands
Status updates
Material transfer through shared locations • Transporters Commands • Conveyors • Material movement • Loading/unloading Status updates
Control • Controllers and operators • Machine state information • Processing recipes • Process monitoring Information transfer through networks • Controllers and operators • Transporter state information • Material movement requests
Figure 3. Conceptual model of manufacturing for material flow control
In the processing/control view in Figure 3, computerbased controllers and human operators jointly coordinate processing of material. This involves selecting the next item of material to process, loading material onto machines, performing setup activities, initiating processing recipes, monitoring process performance, unloading material, and, perhaps, inspecting it. In the transportation/control view, controllers
and operators coordinate material movement between operations. This involves selecting the next destination according to the material’s process plan, selecting a transportation channel (e.g., a transport device), loading and unloading material, directing material to a buffer, etc. In both of these views, computer-based controllers and operators jointly make decisions and perform tasks. A controller has a control domain over which it exercises responsibility (e.g., cell, workstation, or shop). A controller responds to events as they occur in the manufacturing system, and it is informed of an event via a message from another entity. It then makes a decision, either to update its knowledge of the system, or to perform a task. Controller tasks eventually initiate actions on the shop floor. For example, a machine may send a message to a controller that it has finished processing a part. The controller then updates its knowledge of the machine’s status and initiates movement of the part by the material handling system. Similarly, a human operator exercises responsibility over a domain, and responds to events on the shop floor. Systems do not necessarily have a well-defined allocation of tasks between computerized controllers and human operators. In fact, human operators often must handle inadequacies and inconsistencies in control system design [1]. Operators perform tasks and respond to cues from the system. These cues may cause an operator to initiate, suspend, or terminate tasks and functions. They may be in the form of events or information presented to the operator through a user interface. Both computerized controllers and human operators have knowledge about the system, can access knowledge which they do not possess (e.g., from databases), communicate, and make decisions in real-time. Human operators communicate with computerized entities through an interface which contains both controls and displayed information. The chief difference from a reference model point of view is that one can and must specify the internal structure and behavior of a controller, whereas one cannot and need not do the same for an operator. One may, however, specify normative guidelines for operator behavior and actions under the assumption that operators are well-trained and motivated [10]. IV. AN APPROACH FOR REPRESENTING COMPUTER CONTROL AND HUMAN OPERATORS
Domain analysis serves as a key activity in the development of a modeling approach for manufacturing control. This section discusses how the OOSIM control modeling architecture and the OFM methodology may be combined to offer a modeling approach which facilitates the design of user-centered manufacturing control systems. A. Reference Model Based on the preceding domain analysis, we propose the following reference model of manufacturing control which
incorporates computerized controllers and human operators. This section briefly describes the model. First, the reference model structures interactions between decision-making entities through the client-server paradigm [19]. An interaction occurs as a service request from a client to a server. The server provides service by making a decision or performing a task. For instance, consider the interaction of an operator with a machine in the electronics assembly example of Figure 2. A machine signals the operator that its component reel is empty, perhaps through a visual cue (e.g., a flashing light). The operator responds to this service request by performing the sub-function of replacing the reel. A controller has (i) communication capability, (ii) knowledge about entities with which it interacts (organized into modules termed client models), (iii) knowledge about its domain (e.g., representation of valid material handling moves, or a domain map), (iv) access to global data (e.g., process plans and bills of material), (v) a set of tasks which cannot be handled due to current system state (i.e., pending work), and (vi) a collection of decision-making routines, or controller scripts. An operator has the fundamental capabilities of communication, knowledge and decision-making, as well. Additionally, operators can translate many decisions directly into actions on the shop floor beyond sending commands to automated sub-systems. Operators have a set of tasks which they perform, and associated with these tasks are (i) a set of procedures, and (ii) a set of information requirements. Figure 4 summarizes the proposed reference model. Service request
Operator
Controller
• Set of tasks • Knowledge about system • Decision heuristics • Procedures
Message In
Message Out
Decision logic (scripts) acts
on
Client Domain Pending models knowledge work 4 3
1 2
Control system (distributed set of controllers and operators)
Result of decisions
Plant (consisting of control domains)
1. Information from observation 2. Physical tasks 3. Commands sent to control system 4. Information from information system or a service request Figure 4. Proposed reference model for distributed manufacturing control
This reference model does have limitations, most notably that it does not provide any details concerning an operator’s exact internal cognitive processes or exact knowledge representation. We choose not to focus on these details since they are difficult if not impossible to determine, and since we are primarily concerned with the external behavior of the operator. However, we can focus on information and actions required for system control. B. Modeling Tools We discuss two modeling tools which may be used in relation to the reference model. The first is a discrete-event simulation modeling tool (OOSIM) which uses the controller as a fundamental abstraction in models of manufacturing control system. The second is the operator function model. OOSIM is implemented as a collection of classes in C++. These classes include abstractions which modelers may use to build models of manufacturing systems. They also include the basic functionalities of a simulation environment (e.g., event handling, simulation clock, random number generators) [12]. We focus on the representation of control. Controller objects communicate with other objects via object-oriented message-passing. The modeler defines a controller’s messages and client models. The modeler also specifies the controller’s decision-making routines as scripts in C++. A simulation environment may be used as a prototyping tool to test various scenarios in the design of manufacturing control systems. OOSIM enables user interaction with the simulation as it executes by incorporating real-time delays between events; this type of user interaction can model human operator interactions on the shop floor. OOSIM is essentially a descriptive approach to modeling and design, although it can be used for what-if analysis and selection between alternatives. The operator function model, on the other hand, is a normative approach to modeling and design. The modeler must conduct a detailed task analysis of the operator to formulate a model. At the design stage, this coincides with the design of the overall manufacturing control and information system. Figure 5 shows how the reference model supports both the OOSIM modeling environment and the OFM methodology as templates [8]. C. Design of Control Systems A designer may use modeling tools and underlying reference models as design aids in the development of a manufacturing control system. In this section, we sketch the elements which should comprise a design methodology. A manufacturing system has several requirements in the design phase, namely that it produce certain types of product in certain numbers. These requirements dictate much of the equipment to be installed, both processing and material handling equipment. In designing the configuration of the system, the designer must focus on control and the role of
Domain analysis Reference Model for Manufacturing Control
OOSIM Model Used as a prototyping tool for control system design Descriptive modeling, whatif analysis Real-time interactive simulation How to design automated control logic and interaction with human operators
Operator Function Model Used as a specification tool for design of operator role and requirements Normative modeling How to design the operator’s role in terms of tasks and information needs
Figure 5. Reference model and templates
operators in the system. Here, the modeling tools discussed in this paper come into play. An OOSIM model can specify the structure and behavior of a control system. An operator function model can specify the roles, functions, tasks and numbers of individual operators within the control system. Additionally, the OFM specifies the information needed by the operators in the performance of their tasks. Finally, the OOSIM simulation environment can serve as a prototyping tool to test a proposed control system to determine its performance before implementation. Its real-time interactive features also allow testing of the proposed operator role. It should be noted that this testing is concerned primarily with the effectiveness of the decision-making and decision support with respect to performance (e.g., throughput and resource utilization). It is not concerned with the effectiveness of various hardware platforms and operating systems in meeting real-time computing constraints. V. CONCLUSION
This research proposes a control modeling approach which integrates human operators and computerized controllers of manufacturing systems. This approach is based on a reference model for manufacturing control which provides a framework having a consistent basis for both human operator control and computerized control. It is also based on domain analysis, which provide the basis for the reference model, and a task analysis, which provides the basis for the content and structure of the modeling tools which use the. Domain analysis and task analysis are important in the design of user-centered manufacturing systems [14].
This type of approach must be validated through application in various real-world systems, especially since there does not currently exist a widely accepted reference model of manufacturing control. However, it does have the potential to test the effectiveness of various control logic specifications and allocations of decision-making tasks between operators and computerized controllers before actual implementation. Future research involves applying this approach to real-world manufacturing settings in proof-of-concept implementations.
[12] Narayanan. S., D. A. Bodner, U. Sreekanth, T. Govindaraj, L. F. McGinnis, and C. M. Mitchell, “Research in Object-Oriented Manufacturing Simulations: An Assessment of the State of the Art,” Technical Report MHRC TR-94-03, Material Handling Research Center, Georgia Institute of Technology, 1994.
REFERENCES
[14] Narayanan, S., C. M. Mitchell, T. Govindaraj, and L. F. McGinnis, “Supporting the Analysis of Automation and Operator Problem Solving in Discrete Manufacturing Systems,” Proceedings of the 1993 IEEE International Conference on Systems, Man, and Cybernetics, Le Touquet, France, 1993, Vol. 3, pp. 382-387.
[1] Ammons, J. C., T. Govindaraj, and C. M. Mitchell, “A Supervisory Control Paradigm for Real-Time Control of Flexible Manufacturing Systems,” Annals of Operations Research, Vol. 15, 1988, pp. 313-335. [2] Arango, G., and R. Prieto-Diaz, “Domain Analysis Concepts and Research Directions,” in Domain Analysis and Software Systems Modeling, R. Prieto-Diaz and G. Arango (eds.), IEEE Computer Press, 1991, pp. 9-33. [3] Behuniak, J. A., I. A. Ahmed, A. M. Courtright, Production Software That Works, Maynard, Massachusetts: Digital Press, 1992. [4] Biemans, F. P., and C. A. Vissers, “Reference Model for Manufacturing Planning and Control,” Journal of Manufacturing Systems, Vol. 8, No. 1, 1989, pp. 35-46. [5] Callantine, T. J., and C. M. Mitchell, “A Methodology for Understanding How Operators Select and Use Modes of Automation to Control Complex Dynamic Systems,” Proceedings of the 1994 IEEE International Conference on Systems, Man, and Cybernetics, San Antonio, TX, 1994, pp. 1751-1756. [6] Chaar, J. K., D. Teichroew, and R. A. Volz, “Real-Time Software Methodologies: Are They Suitable for Developing Manufacturing Control Software?” The International Journal of Flexible Manufacturing Systems, Vol. 5, 1993, pp. 95-128. [7] Cohen, S. M., C. M. Mitchell, and T. Govindaraj, “Analysis and Aiding the Human Operator in Electronics Assembly,” in Design for Manufacturing: A Systems Approach to Concurrent Engineering and Ergonomics, M. Helender and M. Nagamachi (eds.), London: Taylor & Francis, 1992. [8] Gong, D.-C., and L. F. McGinnis, “Towards a Manufacturing Metamodel,” International Journal of Computer Integrated Manufacturing Systems, to appear. [9] Jones, A. T., and C. R. McLean, “A Proposed Hierarchical Control Architecture for Automated Manufacturing Systems,” Journal of Manufacturing Systems, Vol. 5, No. 1, 1986, pp. 15-25. [10] Jones, P. M., R. W. Chu, and C. M. Mitchell, “A Methodology for Human-Machine Systems Research: Knowledge Engineering, Modeling, and Simulation,” IEEE Transactions on Systems, Man, and Cybernetics, Vol. 25, No. 7, 1995, pp. 1025-1038. [11] Mitchell, C. M., “GT-MSOCC: A Domain for Research on Human-Computer Interaction and Decision Aiding in Supervisory and Control Systems,” IEEE Transactions on Systems, Man, and Cybernetics, Vol. 17, 1987, pp. 553-572.
[13] Narayanan. S., D. A. Bodner, U. Sreekanth, T. Govindaraj, L. F. McGinnis, and C. M. Mitchell, “An Object-Based, Direct-Image Approach to the Modeling and Simulation of Manufacturing Systems,” Technical Report MHRC TR-94-04, Material Handling Research Center, Georgia Institute of Technology, 1994.
[15] Naylor, A. W., and R. A. Volz, “Design of Integrated Manufacturing System Control Software,” IEEE Transactions on Systems, Man, and Cybernetics, Vol. 17, No. 6, 1987, pp. 881-897. [16] Platzman, L. K., and S. B. Gershwin, “Simulating Computer Integrated Manufacturing Systems: How to Model What Traditional Methods Force You to Ignore,” Proceedings of the 1986 IEEE International Conference on Systems, Man, and Cybernetics, Atlanta, GA, 1986, pp. 1007-1008. [17] Rouse, W. B., “The Human Role in Advanced Manufacturing Systems,” in Design and Analysis of Integrated Manufacturing Systems, W. D. Compton (ed.), Washington, DC: National Academy Press, 1988, pp. 148-166. [18] Sheridan, T. B., and G. Johannsen (eds.), Monitoring Behavior and Supervisory Control, New York: Plenum Press, 1976. [19] Sinha, A., “Client-Server Computing,” Communications of the ACM, Vol. 35, No. 7, 1992, pp. 77-98. [20] Smith, J. S., and S. B. Joshi, “Message-Based Part State Graphs (MPSG): A Formal Model for Shop Floor Control,” IEEE Transactions on Robotics and Automation, submitted. [21] Thurman, D. A., and C. M. Mitchell, “A Methodology for the Design of Interactive Monitoring Interfaces,” Proceedings of the 1994 IEEE International Conference on Systems, Man, and Cybernetics, San Antonio, TX, 1994, pp. 1739-1744. [22] Tirpak, T. M., S. M. Daniel, J. D. LaLonde, and W. J. Davis, “A Note on a Fractal Architecture for Modelling and Controlling Flexible Manufacturing Systems,” IEEE Transactions on Systems, Man, and Cybernetics, Vol. 22, No. 3, 1992, pp. 564-567. [23] Van Haren, C. R., and T. J. Williams, “A Reference Model for Computer Integrated Manufacturing from the Point of View of Industrial Automation,” Proceedings of CIMCON 90, Gaithersburg, MD, 1990, pp. 42-62. [24] Zhou, M. C., and F. DiCesare. Petri Net Synthesis for Discrete Event Control of Manufacturing Systems, Boston: Kluwer Academic Publishers, 1993.
