Seamless design methodology of manufacturing cell-control software based on activity-control-condition and object diagram

Transcription

1 Seamless design methodology of manufacturing cell-control software based on activity-control-condition and object diagram TOYOAKI TOMURA, SATOSHI KANAI and TAKESHI KISHINAMI Abstract. A manufacturing cell must be changed according to the type, variations, and intended rate of production of the product. In order to shorten the period of time required for cellcontrol software development, the system designer must have the descriptions of the configuration of the cell and the sequence of activities that is required in the cell, and a comprehensive design methodology based on these descriptions. First, we propose a seamless design methodology that is comprehensive and a clear design concept. The methodology is based on the diagrammatic specification and the processes of its conversion. The diagrammatic specification represents both the configuration of the cell and the sequence of activities required in it; what kind of devices exist in the cell and how they are interconnected, and how they should work in order to complete the task. The methodology specifies the step-by-step conversion processes from the initial diagrammatic specification to the cell-control software code. The conversion is divided into three processes: refinement of the device activities, translation of the device activities into the cell-controller activities, and transformation from the cell-controller activities to the cell-control software code. Secondly, as the diagrammatic specification, we propose an object diagram and an Activity-Control-Condition (ACC) diagram. The object diagram represents a set of objects and the links among them. The ACC diagram represents the sequence of activities required in the cell as three constructs: the state transitions of objects involved in each activity, the control logic among activities, and the conditions for the control. Thirdly, we show the diagram editor to help the system designer carry out the processes in the design methodology. The system designer can use the functions of the diagram editor to modify, save, and load the object diagram and ACC diagram, and to generate the cellcontrol software code from the translated ACC diagram. Finally, we show the implementation method of the cell-control software, and verify the functionality of the software by comparing it with the sequence of activities in the ACC diagram. 1. Introduction Today, manufacturing systems must respond to rapidly level of detail in description attribute instance and link Figure 1. cell control software system interface controller form of description sequence of activities area of description Concept of cell-control software development changing market demands. A Flexible Manufacturing System (FMS) makes it possible to respond to such demands. An FMS consists of several manufacturing cells. In the design of the manufacturing cell, the system designer can deal with each cell as a discrete-event system based on the concept of activity and event. An activity can be defined as a set of state transitions of components in the manufacturing cell. We can consider that cell-control software development involves a transformation, based on two kinds of specification, from the activities of the controlled system to the activities of the controller. The system designer needs a cell-control software development methodology that is comprehensive and based on a clear concept. Figure 1 shows the concept of cell-control software development used in this study. According to this concept, the following requirements are considered important for shortening the stages of development: The specifications should be represented as follows:

2 the configuration of each cell and the sequence of activities required in each cell. The development methodology should present seamless connections among the following processes: the specification; the design, which consists of refinement, translation, and transformation; and the implementation. Structured Analysis and Design Technique (SADT) and Integrated computer-aided manufacturing DEFinition 0 (IDEF0) (Vernadat 1996, Cho and Lee 1999) are wellknown modeling tools for high-level design. The IDEF0 (or SADT) representation of a manufacturing cell consists of an ordered set of boxes representing activities performed by the controlled system. Several approaches for cell-control software design using this representation have been proposed. Some researchers have proposed rules that transform the IDEF0 model to the Petri net model (Boucher and Jafari 1992, Santarek and Buseif 1997). The Petri net model can be mapped into the cell-control software, and the Petri net (Murata 1989, Silva and Valette 1989, Vernadat 1996) is a well-known modeling tool for the design of a manufacturing cell and its controller. Statechart (Harel 1988, Davis 1988) is a modeling tool similar to that of the Petri net. A sequential functional chart (SFC) is a graphical representation used for the design of a sequence control system. The SFC model can clearly represent a complex sequence of activities. In SFC representation, the control between activities can represent both the synchronous and asynchronous relationships at the start and end of activities. In the design of cell-control software shown in Figure 1, it can be seen that these representations have the following problems: Because they cannot represent the configuration of the cell, the seamlessness of the refinement process is lost. Because the IDEF0 model can not represent the state transitions of components in the cell, the seamlessness of the refinement process is lost. Because the Petri net and Statechart models cannot represent the activities as a unit, the description is not comprehensive for the system designer. In addition, because the state transitions of the controlled system and the controller are directly described, the seamlessness of the refinement and translation processes is lost. Because the SFC model only represents the sequence of activities for the controller, the seamlessness of the translation process is lost. The object-oriented modeling methodologies, such as the object-modeling technique (OMT) (Rumbaugh et al. Specification of the Cell Notations of Diagrams Diagrammatic Specification of Configuration and Sequence of Activities Diagram Editor Object Diagram ACC Diagram Steps of Each Process Seamless Design Methodology Cell Control Software Implementation Method (1) Proposing a seamless design methodology for cellcontrol software consisting of three processes: refinement, translation, and transformation, (2) Proposing an object diagram and an Activity- Controllerindependent Code Implementation of Cell Control Software Programming Tool Figure 2. The proposed development flow. 1991) and object-oriented system analysis (OOSA) (Shlaer and Mellor 1988, Shlaer and Mellor 1990) are used in the design of a manufacturing cell and cell-control software (Maione and Piscitelli 1999). In these methodologies, the configuration of the cell can be defined as a static structure in the system. The state of each of the components in the cell can also be defined as a set of values of attribute of that respective component. As a methodology developed especially for the manufacturing cell, a Petri-net and Entity-relationship diagram-based Object-Oriented Design (PEBOOD) methodology (Chen and Lu 1997) is proposed for the design of cell-control software. The PEBOOD methodology employs the following diagrams: entityrelationship diagram, Petri-net, and IDEF0. The Petri-net model of the cell controller can be implemented as the control logic. In the design of cell-control software, these methodologies have the following problems: Because most of them cannot represent the sequence of activities for both the controlled system and the controller, the seamlessness of the refinement process is lost. In PEBOOD methodology, because the activities cannot be associated with the state transitions of objects in the Petri-net, the seamlessness of the refinement process is lost. Because the state transitions are directly described, the seamlessness of the translation process is also lost. System designers require design tools that will allow them to reduce the amount of time necessary for cellcontrol software development. In order to meet these needs, we have determined the purposes of this study to be the following:

3 Control-Condition (ACC) diagram which represent the configuration of the manufacturing cell and the sequence of activities required in the cell, (3) Developing a diagram editor to help the system designer in performing each process of the seamless design methodology, (4) Showing an implementation method for the cellcontrol software designed for the cell controller, and (5) Verifying the software by comparing it with the sequence of activities in the ACC diagram. Figure 2 shows the flow of cell-control software development in this study. In this paper, we first describe the basic concept of seamless design methodology. Next, the notations and examples of diagrammatic specifications are described. Finally, the prototype of a diagram editor is introduced, and a method for implementing and verifying the cell-control software is shown. 2. Basic concept of seamless design methodology of cellcontrol software In this section, we propose the seamless design methodology of cell-control software based on the diagrammatic specification. As shown in figure 1, the methodology consists of the three processes: refinement, translation and transformation. In figure 1, first, the two kinds of specifications, i.e., representing the configuration of the cell and the sequence of activities required in the cell, respectively, are converted to the two diagrammatic specifications; to the object diagram and the Activity- Control-Condition (ACC) diagram. Next, the system designer executes the processes in the seamless design methodology by using the constructed diagrams. In the coordinate system shown in figure 1, the refinement, translation, and transformation process are recognized as follows: (1) The purpose of the refinement process is to gradually raise the level of detail in the description for the ACC diagram. The description is in the area of the controlled system. (2) The purpose of the translation process is to transit the ACC diagram from the area of the controlled system to the area of the controller through the area of the interface. (3) The purpose of the transformation process is to convert the description for the ACC diagram to the description for a text-based controller-independent code. The first process is the refinement of the ACC diagram. The next process is the translation of the refined ACC Sensor_1 Robot Buffer_1 Cell_controller Robot_ controller loading machining NC_ controller Sensor_2 Buffer_1 Start_ button Figure 3. An example of manufacturing cell. Stop_ button diagram on the system side to the one on the controller side. The final process is the transformation from the translated ACC diagram to the controller-independent code of the cell-control software. The details of each process are described herein, in later sections. 3. Object diagram and activity-control-condition diagram The cell-control software design proposed in this study is only one variation of object-oriented analysis and design. In general, object-oriented analysis and design captures a system from three points of view: static structure, dynamics, and function. In the OMT (Runbaugh et al. 1991), the object diagram, state diagram, and data flow diagram are used for the graphical representation of the three views. In this study, the object diagram and the Activity- Control-Condition (ACC) diagram are defined as the graphical representations for the configuration of the cell and the sequence of activities required in the cell. The object diagram represents the components and their interrelationships in the cell. The ACC diagram represents the sequence of activities, the control among activities, and the conditions for the control. This diagram can show the parallel / simultaneous activities in the control node. In this section, we identify the requirements of diagrams and cellcontrol software design. The diagrams should satisfy the following requirements: The notations of diagrams should be visually comprehensible and easy for the system designer to define at the initial steps of the specification. The diagrams should be refined, then translated to the functions of the controller in the design, and, finally, they should have a description that is equivalent to an executable control code on the controller and independent of the specific controller. In order to keep a strict correspondence between the object diagram and the ACC diagram, consistent diction should be used in both diagrams.

4 CellController PLC StorageFacility Figure 4. Figure 5. Class diagram of the manufacturing cell. Symbols of instance diagram. The design method should satisfy the following requirements: In each process, the activities of the controlled system can be translated into the activities of the controller. peach step of the refinement and translation process, as well as the notations for diagrams corresponding to these processes, should be defined. In the implementation of cell-control software, the implementation method should be able to systematically implement the software on the typical cell controller and PLC. For an efficient design, the system designer requires a software application that can manage the diagrams for the design method. Figure 3 shows an example of a manufacturing cell. In this paper, we assume that the sequence of activities required in the manufacturing cell is as follows: (1) The robot (d Robot ) loads the work (d ) stored in the input buffer (d Buffer_1 ) to the machine tool (d ). (2) The machine tool machines the loaded work. (3) The robot unloads the machined work to the output buffer (d Buffer_2 ). (4) Return to activity (1) Object diagram communicates with 1+ Interface StationController ports 1+ RobotController NCController InputDevice controls controls Operator det_flag Robot Tool act_flag act_flag Buffer Sensor Button 1+ pushes down senses moves Piece stores machines instance ( of class) of instance link of link The notation of the object diagram proposed in this study is the same as that of the OMT (Rumbaugh et al. 1991). The object diagram represents the configuration of (Buffer) Buffer_1 (Buffer) Buffer_2 Figure 6. stores stores (Tool) controls (NCController) NC_controller NC_I/F Button_I/F_1 (Button) Start_button machines (Piece) communicates with (Robot) Robot communicates with senses senses moves (Sensor) Sensor_1 (Sensor) Sensor_2 controls (CellController) Cell_controller Cell_I/F pushes pushes down (Operator) down Operator Instance diagram of the manufacturing cell. the cell as the components in the cell and the relationships among them. The object diagram is also classified into two kinds of diagrams; a class diagram and an instance diagram. First, the class diagram is constructed. The class diagram is the template for the type of the configuration of the cell. Figure 4 shows an example of a class diagram for the cell shown in figure 3. Each class several attributes and is d according to the components in the cell. By referring to the class diagram and the configuration of the cell, the instance diagram is then constructed for the configuration of the cell. Figure 5 shows the symbols for an instancediagram. These symbols are: Instance drawn by a rounded corner box, which represents an actual component in the cell. Instance also represents an object instantiated from a class in the class diagram. Link drawn by a labeled line segment represents an actual relationship between instances. Link is also an instance of an association in the class diagram. Figure 6 shows the instance diagram for the cell shown in figure 3. After the class diagram is constructed, the class diagram is used solely for constructing the instance diagram. Therefore, only the instance diagram is used in the seamless design methodology. 3.2 Activity-control-condition diagram Sensor_I/F_1 The ACC diagram represents the sequence of activities required in the manufacturing cell as three constructs: the activities, the control among activities, and the conditions for the control. Figure 7 shows the symbols for an ACC diagram. The ACC diagram is a graph constructed by using Sensor_I/F_2 (RobotController) Robot_controller Robot_I/F communicates with communicates with communicates with communicates with (Button) Stop_button Button_I/F_2

5 activity node control node condition node sentence of activity arc 1) from activity to control 1) Automatic - Automatic 5) Synchronous - Synchronous & Figure 7. Symbols of ACC diagram. & 9) Asynchronous - Asynchronous op 1 op 2 sentence of condition 2) from control to activity 2) Automatic - Synchronous 6) Synchronous - Asynchronous & Figure 9. Types of control nodes. 3) from condition to control 3) Automatic 4) Synchronous - Asynchronous - Automatic & 7) Asynchronous - Automatic these symbols. These symbols have the following roles: The activity node, indicated by a box, represents the activity performed by the components in the cell. The activity is defined as a set of state transitions of the components in the cell. The control node, indicated by an octagon, represents the control between activities, which is performed by the cell controller or PLC. The control is defined by synchronization of the start and end of the activities. The condition node, indicated by a rounded corner box, represents the conditions for the control. The conditions are defined as the state of the components in the cell. The direct arc represents either the direct connection between the activity node and the control node, or the direct connection between the control node and the condition node. & 8) Asynchronous - Synchronous & Automatic : One activity will complete or start. Synchronous : All activities will complete or start simultanously. Asynchronous : one or more activities will complete or start. Figure 8 shows the ACC diagram for the sequence of activities required in the cell shown in figure 3. In figure 8, two activity nodes labeled "start" and "stop" represent the start and stop points of the sequence of activities. Figure 9 shows the various control nodes. By using a control node, the synchronizations of the start / end of parallel / sinultaneous activities can be distinguished in the ACC diagram. The types of synchronization at the start and end of activity are classified into three types: automatic, synchronous, and asynchronous. Each sentence of the activity nodes and the condition nodes must be determined by referring to the instances and the links among them in the object diagram. In the activity node, the description of the sentence must abide by the following rules: The subject of the sentence must be an instance of either the "Tool" class or the "Robot" class. The verb of the sentence must be the of the link connecting the instance to an instance of the "piece" class. The object of the sentence must be the instance of the "piece" class. While in the condition node, The subject of the sentence must be an instance of the "Sensor" class in the class diagram. The verb of the sentence must be the of the link connecting the instance with an instance of the "piece" class. The representation of each node in the constructed ACC diagram is very simple and human readable for the system designer. 4. Design processes in seamless design methodology of cell-control software In the seamless design methodology, the system designer must perform the three processes, termed refinement, translation, and transformation. Through these processes, the system designer can extract the controllerindependent code of cell-control software from the constructed object diagram and ACC diagram. start Start_button being pushed down Sensor_1 is sensing Robot moves from Buffer_1 to machines Sensor_2 is not sensing Robot moves from to Buffer_2 Sensor_1 is sensing Stop_button is being pushed down stop Figure 8. ACC diagram of the manufacturing cell.

6 Table 1. after construction Change of ACC diagram in seamless design methodology. Activity node Control node Condition node sentence sentence identifying the object instance and its state, in terms of their correspondence to each condition. The refinement process can be divided into the refinement process for the activity node and that for the condition node. First, the refinement process for the activity node can be divided into the following steps: after refinement after translation after transformation control logic Control logic Inputs Outputs Robot moves from Buffer_1 to activated_object : Robot t entry idle (act_flag=0) affected_object : on Buffer_1 affected_object : Buffer_1 full affected_object : not available loading (act_flag=1) being loading Figure 10. A result of refinement process for activity node. Table 1 shows the change of the ACC diagram as a result of performing these processes. In this section, we describe the steps of each process in the seamless design methodology. 4.1 Refinement process of ACC diagram sentence sentence idle (act_flag=0) on empty machining available In the refinement process, we assume that each object the state transitions described as finite state machine and the activities are the sets of their state transitions. The purposes of the refinement process are: identifying a set of object instances involved in each activity, defining the state transitions of each object instance in the activity, and t exit (1) Identify the object instance that is directly activated by the station controller or the cell controller. This object instance can be identified as the subject in the sentence written in the activity node. This is called the activated object. (2) Define the state transitions of the activated object. In the activity node, the activated object must have three states; an initial, an intermediate, and a final state. Each state defined for the activated object must have a specific attribute value. (3) Identify a set of object instances affected by the execution of the activity. These object instances can be identified as the nouns (without the subject) of the sentence written in the activity node. These are called the affected objects. (4) Similar to step (2), define the state transitions of each affected object. In the activity node, each affected object must have two or more states. (5) Pick up one entry event and one exit event from all the events described in the activity node. The entry event is the event which triggers the start of activity, while the exit event is the one which triggers the end of activity. (6) Define the causal relationships between the state transitions of different object instances. The causal relationship represents the propagation of the state transition from the object instance to another object instance. The refinement process for the condition node can be divided into the following steps: (7) Similar to step (1), identify the object instance which is associated with the workpiece. This object can be identified as the subject of the sentence written in the condition node. (8) Similar to step (2), define one state of the object instance. The state defined for the object instance must have a specific attribute value. Figure 10 shows the result of the refinement process for the activity node initially described "Robot moves from Buffer_1 to " in figure 8. In figure 10, each rounded corner box represents the state of the activated object and that of the affected objects. The states of the

7 activated object are written as the of the state and its attribute value. Each dotted arrow represents the causal relationship between the state transitions. The arcs labeled "tentry" and "texit" respectively represent the start and end of activity, and are called the entry event and the exit event. 4.2 Translation process of ACC diagram As a result of the refinement process, the state transitions of object instances and the entry and exit event in each activity, and the state of the object instance in each condition are identified. These are the descriptions for the activities and conditions of the controlled system. Next, the system designer must translate these descriptions into the descriptions of the controller. The translation is performed by breaking through the activity of interface. The activity of the controller can be described as the control node in the ACC diagram. In the control node, the inputs and outputs are as follows: The control input is the arc connected to the lefthand side of the control node. The control input also corresponds to the exit event of the activity node connected by the arc. The control output is the arc connected to the righthand side of the control node. The control output also corresponds to the entry event of the activity node connected by the arc. The condition input is the arc connected to the bottom of the control node. The condition input also corresponds to the state of the input device in the condition node connected by the arc. In the translation process, the activity of interface can be described as these inputs and outputs in each control node. The activity of interface consists of the state transition of each port in the interface. The purposes of the translation process are: identifying the events on the ports corresponding to the control inputs, control outputs, and condition inputs in each control node, converting these events from the controlled system to the controller, and defining the control logic among the inputs. According to the type of synchronization in the control node, the control logic can be identified. The translation process can be divided into the following steps: (1) Allocate Boolean variables i k, o k, and c k (k = 1, 2,...) to each control input, control output, and condition input. (2) From the object instance associated with each entry and exit event, identify the interface object instance associated with each control input/output. The interface object instance can be identified by tracing back links connected with the object instance in the instance diagram. Similarly, the interface object instance associated with each condition input can be identified. (3) Identify the control inputs/outputs as two states and one event, and identify the condition input as one state. Each state is described as the digital voltage of the port in the interface object instance. Each state is defined as the binary value. (4) In each control node, express the control logic according to the synchronization of both sides of lefthand and right-hand in the control node. The expression(s) of the control logic can be defined as a simple Boolean function of the control input(s) and condition input(s). (a) Refined ACC diagram machines Robot moves from to Buffer_2 (c) Controller-independent code (1) list of variables i 0, o 0, c 1 (2) variable values and changes of value i 0 = 0 -> 1 o 0 = 0 -> 1 c 1 = 0 (3) relationships between variable and port number i 0 : Cell_I/F : 0 o 0 : Cell_I/F : 1 c 1 : Cell_I/F : 2 (4) logical expressions o 0 = i 0 & c 1 Steps of translation process Translation process Steps of transformation process Transformation process (b) Translated ACC diagram (1) (1) i 0 o 0 Robot moves o 0 = i 0 & c 1 machines from to Buffer_2 (1) c Cell_I/F: 0(3) 1 (3) Cell_I/F: 1 (2) Sensor_2 (2) 0 [V] 5 [V] is not 0 [V] 5 [V] (i 0 =0) (i 0 =1) sensing (o 0 =0) (o 1 =1) Figure 11. A result of translation and transformation processes for control node. (3) Cell_I/F: 2 0 [V](2) (c 1 =0)

8 (1) Extract the list of Boolean variables for each controller. (2) For each extracted Boolean variable, extract the value or change of value of each variable. (3) For each extracted Boolean variable, extract the s of the interface object instances and the port numbers associated with the variables. (4) For each extracted Boolean output variable, extract the expressions representing the control logic. Figure 12. Relationships between variable and port number I/O map Specifying I/O addresses Variable values and changes of them List of variables Logical expressions Figure 13. Snapshot of diagram editor. I/O addresses of variables Grammer of C Coding of functions for I/O Grammer of C Coding of functions for edge detection Functions for I/O Functions for edge detection Cell control software Coding of main function Implementation method of cell-control software. Figure 11 shows the result of the translation process for a control node (figure 11 (a)) in the refined ACC diagram. In figure 11 (b), the boxes drawn with a thick line are attached to the control inputs/outputs and condition inputs, and the of the interface object instance and the port number are written in each box. 4.3 Transformation process from ACC diagram to controller-independent code As a result of the translation process, the inputs/outputs required for the controller, the changes of the inputs/outputs, and the control logic for the controller are identified. The translated ACC diagram represents the activities of the controller. The system designer must transform the diagrammatic description to text-based controller-independent code for the controller, by referring to all the control nodes. The transformation process can be divided into the following steps: Figure 11 (c) shows the result of the transformation process for the control node. The controller-independent code for the cell controller can be extracted by means of the refinement, translation, and transformation processes. 5. Diagram editor In order to shorten the period of time required for cellcontrol software development, we developed and implemented a prototype of a diagram editor on an IBM- PC. The diagram editor is implemented by using Visual C++ as a development tool and Visio Technical as a 2- dimensional CAD application. On the diagram editor, the system designer can edit, save, and load the object diagram and ACC diagram, and can design the cell-control software by following the seamless design methodology. The final output of the diagram editor is the controller-independent codes for the cell-control software. Figure 12 shows a photograph of the diagram editor. In figure 12, the system designer is designing the cell-control software by simultaneously referring to the object diagram and the ACC diagram. By dragging and dropping the icon from the left window to the diagram window, the system designer can edit the diagrams easily. 6. Implementation and verification of cell-control software We have implemented the cell-control software from an example of controller-independent code in this paper. We selected C language as the programming language for the cell controller (IBM-PC). Because the cell deals with only the low-level control of the controlled system, the code does not require the concept of object-oriented. Further, we do not use C++ language. The cell-control software is verified by using the verification system shown in this section. Figure 13 shows the implementation method of the cell-control software designed for the cell controller. By using this method, the controller-independent code is transformed into the cell-control software for the specific cell controller. In order to verify if the implemented cellcontrol software will operate in the desired manner, we

9 TPN of machining available T1 T2 TPN of Sensor_1 sensing Figure 14. Architecture of verification system. developed a verification system for the cell-control software. Figure 14 shows the architecture of the verification system. In figure 14, the TPNs represent Timed Petri Net (Murata 1989, Hsieh 1998). The verification system repeats the following steps: (1) The state machine of cell controller reads the inputs from the TPN of inputs, calculates the control logic of the cell-control software, and writes the outputs to the TPN of outputs. (2) In the TPNs of the and the Robot, the system lets the transition fire where firing is possible. (3) In the TPNs of the Sensor_1 and the Sensor_2, the system lets the transition fire where firing is possible. In each TPN, by monitoring the movement of tokens and comparing the movement with the sequence of activities in the ACC diagram, we confirmed that the implemented cellcontrol software operates in the desired manner. Although the cell-control software for PLC can also be implemented on the specific PLC, we do not discuss this implementation method herein. 7. Conclusions machining not available idle TPN of inputs and outputs state machine of Cell_controller cell control software (coded by C language) machining complete The results of this study led to the following conclusions: (1) To shorten the period of time required for cell-control software development, we proposed the seamless design methodology. The methodology consists of the following three processes: refining, translating, and transforming the diagrammatic specification that represents the sequence of activities required in the manufacturing cell. (2) The object diagram and the Activity-Control- T3 T4 TPN of Sensor_2 sensing Condition diagram are proposed as the diagrammatic specification which represents the configuration of the cell and the sequence of activities required in the cell. (3) A prototype of a diagram editor is developed to help the system designer in performing the seamless design methodology. (4) We present herein the implementation method of cell-control software based on the extracted controller-independent code. (5) We developed a Petri-net-based verification system of cell-control software. By monitoring the movement of tokens and comparing their movement with the sequence of activities in the ACC diagram, we confirmed that the implemented cell-control software operates in the desired manner. References SILVA, M. and VALETTE, R., 1990, Petri Nets and Flexible Manufacturing. Advances in Petri Nets 1989, Lecture Notes in Computer Science 424 (Springer-Verlag), pp BOUCHER, T. O. and JAFARI, M. A., 1992, Design of a factory floor sequence controller from a high level system specification. Journal of Manufacturing Systems, 11(6), VERNADAT, F. B., 1996, Enterprise Modeling and Integration: principles and applications (CHAPMAN & HALL). SANTAREK, K. and BUSEIF, I. M., 1997, Modelling and design of flexible manufacturing systems using SADT and Petri net tools. Proceedings of the 13th International Conference on Computer-Aided Production Engineering, pp RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY, F. and LORENSEN, W., 1991, Object-oriented modeling and design (Prentice-Hall, Englewood Cliffs, NJ). SHLAER, S. and MELLOR, S. J., 1990, Object Lifecycles- Modeling the World in Data (Prentice-Hall, Englewood Cliffs, NJ). HAREL, D., 1988, On Visual Formalisms. Communications of the ACM, 31(5), DAVIS, A. M., 1988, A Comparison of Techniques for the Specification of External Behavior. Communications of the ACM, 31(9), CHEN, K.-Y. and LU, S. S., 1997, A Petri-net and entityrelationship diagram based object-oriented design method for manufacturing systems control. International Journal of Computer Integrated Manufacturing, 10(1-4), PATHAK, D. K. and KROGH, B. H., 1989, Concurrent Operation Specification Language, COSL, for Low-

10 Level Manufacturing Control. Computers in Industry 12, LIN, L., WAKABAYASHI, M. and ADIGA, S., 1994, Object- Oriented Modeling and Implementation of Control Software for a Robotic Flexible Manufacturing Cell. Robotics & Computer-Integrated Manufacturing, 11(1), MURATA, T., 1989, Petri Nets: Properties, Analysis and Applications. Proceedings of IEEE, 77(4), MAIONE, G. and PISCITELLI, G., 1999, Object-oriented design of the control software for a flexible manufacturing system. International Journal of Computer Integrated Manufacturing, 12(1), CHO, H. and LEE, I., 1999, Integrated framework of IDEF modelling methods for structured design of shop floor control systems. International Journal of Computer Integrated Manufacturing, 12(2), HSIEH, S., 1998, Synthesis of AGVS by coloured-timed Petri nets. International Journal of Computer Integrated Manufacturing, 11(4),