Table of Contents
Previous Chapter
Table of Contents
Previous Chapter
In a distributed manufacturing system, a set of commands must be transmitted through the complex collection of software and hardware components from where they originate to their destination. These control commands are referred to as messages and the process of transmitting commands is referred to as "message passing" in this thesis. In general, commercial IMDs come with their own device controllers and a computer with some communication interfaces is used as a host computer and a cell controller. A cell controller can be used to explain the message passing of a host computer. Therefore, in this chapter, a manufacturing cell will be used to illustrate the message passing.
The message passing capability of IMDs and the cell controller is often restricted by the available communication channels, communication support between software modules, and other vendor software. A control command may not be able to be transmitted to an IMD's controller because of these limitations. Therefore, it is important that system integrators identify the message passing capability of the cell controller and IMDs while they are selecting equipment to configure a manufacturing cell in order to achieve required control objectives as well as process objectives.
Unfortunately, the commercial manuals for IMDs and computers are not documented from this perspective. The message passing capability of these controllers can not be easily realized and understood. Therefore, several typical controllers are given in this chapter to illustrate the "message passing". Next, a survey of possible modelling techniques is provided. Finally, the reasons for the development of the new modelling technique is explained.
Since the term "message passing" is a new terminology which was defined during this research, several typical examples are used in this section to illustrate the complexities of various types of message passing in manufacturing cells. These examples include a robot controller, a CNC controller, and a cell controller computer from a manufacturing cell in the Material Handling Research Center Laboratory at Georgia Tech. The CNC controller and the cell controller are also used to explain the conditions for the connections of IMDs with respect to the "message passing".
A basic robot contains mechanical components (i.e. arms, end effector, etc.), electronic components (i.e., controller, teach pendant, CRT/KBY or a computer), and software. Not only does a robot controller provide control of the mechanical movement, it also provides communications with its environment. A SCORBOT V robot is used as an example of the message passing capability of a robot. This SCORBOT V robot has six axes: base, shoulder, elbow, pitch, roll, and linear slide base. It also has 16 binary inputs, 16 binary outputs, and one RS-232C serial port. The RS-232C port is used to connect to a programming computer, in this case a personal computer. This computer is used to edit robot programs, to control robot, etc. A schematic diagram of SCORBOT V is shown in Fig. 1.
The robot controller can send axis control commands, i.e., move arm to position 3, to the robot axes and can read inputs or write outputs according to the manipulation sequence specified in the robot program. This robot program is entered from the programing computer by an operator and is stored in the robot controller. The programming computer can also issue commands directly to control robot axis movement and to write to the binary outputs. An operator can also use the teach pendant to control the robot axis movement. The peripherals' interface in this example is a set of simple discrete I/O signals, 16 binary inputs and 16 binary outputs. The control program in the robot controller acts as an interface between the programming computer, the teach pendant and its internal components. For example, the control program knows how to deliver a binary output bit to discrete I/O board.
In order to explain the "message passing", Fig. 1 is represented by a connection diagram which is shown in Fig. 2, where each component in Fig. 1 is represented by a box (ei) and an arrow line is represented by an arrow (aj). The direction of an arrow indicates the control command(s) direction which will be called the message(s) direction from now on. Two arrow heads on a line indicates that messages can flow both directions. For example, a10 indicates that a discrete I/O board, box e6 in Fig. 2, can receive binary inputs and can send binary outputs out.
Since there may be more than one message that a component can accept or deliver, "k" is used for message index. For example, the types of messages that the programming computer can send to the control program are "control axis movement", "set binary output", etc. The index, i, is used to represent different components in the controllers. Thus, an input message k of the component i is represented as "mii,k" and an output message k of the component i is represented by "moi,k".
A black dot in a component represents one type of message the component can receive. Messages in a circle represents messages which can be transmitted through the communication channel. For example, there is only one message, mo2, 1, "move robot axis to position", can be sent from the teach pendant component to the control program. A list of messages that components in Fig. 3 can receive/transmit is shown in Table 1.
Table 1 Parameters of the Robot Controller (Continued)
------------------------------------------------------------------------------------------
Entities Input Message-In Output Message-Out
channel Channel
------------------------------------------------------------------------------------------
e1 a1 mi1,1 a3 mo1,1
(Computer) (operator) (startProgram) (RS-232c) (startProgram)
mi1,2 mo1,2
(setOutput #: value:) (setOutput #: value:)
mi1,3 mo1,3
(move axis: value:) (move axis: value:)
e2 a2 mi2,1 a4 mo2,1
(Teach Pendant) (operator) (move axis: value:) (Dedicated) (move axis: value:)
e3 a9 mi3,1 a5 mo3,1
(User Application) (Bus) (startProgram) (Bus) (setOutput #: value:)
a8 mo3,2
(Bus) (move axis: value:)
a8 mo3,3
(Bus) (readInput #:)
e4 a3 mi4,1 a6 mo4,3
(Control Program) (RS-232c) (startProgram) (Bus) (move axis: value:)
mi4,2 a7 mo4,2
(setOutput #: value:) (Bus) (setOutput #: value:)
mi4,3 a9 mo4,1
(move axis: value:) (Bus) (startProgram)
a4 mi4,3
(Dedicated) (move axis: value:)
e5 a5 mi5,1
(Motion Control) (Bus) (move axis: value:)
a6 mi5,2
(Bus) (move axis: value:)
e6 a7 mi6,1 a10 mo6,1
(Inputs & Outputs) (Bus) (setOutput #: value:) (D I/O) (Output #: value:)
a8 mi6,1
(Bus) (setOutput #: value:)
a10 mi6,2
(D I/O) (setInput #: value:)
a8 mi6,3
(Bus) (readInput #:)
------------------------------------------------------------------------------------------
A component when it sends a message out is called a "transmitter", whereas a component when it receives a message is called a "receiver". For example, a transmitter, i.e. the programming computer of the SCORBOT V, can send "MOVE 33", to move the robot to the position 33, to the control program, a receiver. However, there maybe more than one position that the programming computer will send to the control program, the message may have the same formate except with a different position number. Messages with similar format can be represented by one type of "message expression". A message expression includes a selector and possibly some arguments. A message's selector is a name for the type of interaction the sender desires with the receiver. An argument of a message is a piece of information passing along with the message selector. For example, "MOVE" is a message selector and "33" is an argument of this message. In order to explicitly express the detail information defined to the position "33", the message may be represented as "move axis: value:", where "move" is a message selector and "axis: value: " is the arguments of this message.
Some messages may have only a message selector. For example, the programming computer sends a message, "startProgram", to start the robot program. This message only contains a message selector without any arguments.
To read an input binary bit, the command in the robot program is "input[#]". The "input" of the command can be a selector and the "#" inside of the bracket can be an argument. In order to make it more readable, without loss of generality, the command can be represented as "readInput #:" as shown in the table. Eventually, this message requires the return of bit value from receiver component.
The Message-In column of Table 1 lists the possible message expressions that the component can receive as a receiver. The Message-Out column lists the possible message expressions that can be sent. As one may notice, some messages may not be able to pass through some channels. For example, the channel, a4, can't change the binary output status. It is also possible that some types of messages can be sent to a component through multiple channels. For example, both the programming computer and teach pendant can issue commands to move robot axes.
In this example, some message passing limitations of IMDs are explained. For the study of message passing, both the software and hardware components need to be considered. The control commands can be modelled as messages that are passed between components. A message can be represented by a selector and some arguments. It is also noted that some messages may require the return information from the receiver.
A simple CNC milling machine contains a X-Y table, a spindle axis (Z axis), and a CNC controller. In general, a fixture is placed on the X-Y table to hold a part. An operator can write a part program to specify the machine operations, such as cutting speed, turning the spindle on and off, etc. The CNC controller executes the machine operations in the pre-defined sequence programmed by an operator.
A simple CNC controller, which will be used to illustrate the relationships of machine executing sequence and message passing, is shown in Fig. 4. In this example, only a part program component (e1), binary inputs component (e2), and binary outputs component (e3) are used to represent this CNC controller. In the beginning, the part program will read a binary input to determine if a part is ready to be processed. After finishing the machining, the part program will send a binary output to inform a robot (or operator) to pick up the part. After it is finished unloading the part, the robot will send a binary data to inform the CNC machine that the unloading process has been completed.
The message passing between these components is shown in Fig. 5. The part program component (e1) is executed sequentially once it is started. A part program may be started by an operator from the control panel. The input interface component receives (e2) binary inputs and passes the binary input information to the part program upon request. The part program component will send binary output to the output interface component (e3).
Although there are two messages to the input interface component (e2) from the part program component (e1), these two messages are not sent to the input interface component at the same time. Therefore, for the study of message passing, it is very important to show how the part program is executed and how the sequence of messages is ordered.
A personal computer (PC) is used as a cell controller to control a robot, two CNC machines, and an AGV. For various reasons, it was developed as a knowledge-based controller to use the OS/2 Operating System. The knowledge-based controller makes decisions based on the real-time status of the machining cell. The real-time status of the machining cell is read through the discrete input board on the PC. The real-time control commands are sent to the machines via the discrete output interface. Since the knowledge-based controller was implemented using a software package (OS2XLISP), a shared memory scheme is used for passing the information between input/output interface and knowledge-based controller due to the limitation of this software package to access the input/output interface directly.
The software architecture is shown in Fig. 6.
It is converted into the connection diagram shown in Fig. 7. The shared memory scheme is used to store the real-time machining cell status and temporarily store the control commands from knowledge-based program. The shared memory in Fig. 6 is represented by two components, e6 and e7 in Fig. 7, in order to distinguish the use of shared memory for input and output data. The discrete I/O board is also represented by input and output components, e4 and e5. The shared memory components can be thought of as shared resources. Components, such as the graphic I/O transfer, can send messages to request the current status of the machining cell. In this case, the graphic I/O component is executed cyclically, reading the status of the input interface/control commands from shared memory components and displaying the current status on the screen. More than one component can access the shared memory component at the same time. For example, the knowledge-based program component, graphic I/O component, and discrete I/O program component may all access the shared memory at the same time. In general, a message buffer with a first-in-first-out (FIFO) policy is used to handle this situation by the Operating System.
A simple machining cell that contains a cell controller and a CNC milling machine is used to demonstrate the connection of the IMDs and the reuse of the representations.
The operation of this simple machining cell is: first, the part program in the CNC controller will read a binary input from the cell controller to determine if a part is ready to be processed. Then, the part is machined according to the program. After finishing the machining, the part program will send a binary output to inform the cell controller. After the part is removed from the CNC machine, the cell controller will send a binary data to inform the CNC machine that the unloading process is finished.
Instead of communicating with the robot controller directly, the CNC controller in this example will receive commands from, and send the completion signal to, the cell controller. However, the operation of this CNC controller is similar to the CNC controller described in Section 2.1.2. Therefore, the representation of the CNC controller in Section 2.1.2 can be used in this example without modification.
The cell controller in this example receives binary inputs from the CNC controller, makes decisions, and sends commands to the CNC controller via its binary outputs. Without loss of generality, the cell controller that is described in Section 2.1.3 is used to represent the cell controller in this example. The connected message diagram is shown in Fig. 8. The connections between the cell controller and the CNC machine are wires. As one may notice, in additional to the mechanical and electrical specifications, an out-going message of a sender can be connected to an in-coming message of a receiver only if these two messages have the same selector and arguments. Another condition is that there exists no time delay between connections. In this case, the time delay for a signal from one end to reach another end is negligeable and can be assumed as zero.
Commercial IMDs are commonly used in manufacturing cells. Any one cell may have identical IMDs, same type of IMDs, and/or similar IMDs in a manufacturing cell. If a new machine is added to a manufacturing cell, the representation of the system should be easy to adopt to the new configuration. Therefore, it is very important to be able to re-use existing models to configure a new system.
In this example, the importance of the use of modular components to configure a new system is explained. It also shows the conditions for a proper connection.
A discrete part manufacturing system consists of several IMDs, such as CNC machines, robots, cell controllers, and can be viewed as a discrete event system (DES). A discrete event system is generally represented by a sequence of discrete events, which occur at asynchronous time intervals. Most of the research in the area of control of a DES emphasize controlling the occurrence of the events [Kasturia et al. 1988][Ramadge 1987] [Ramadge and Wonhan 1987] [Smedinga 1987]. Ramadge and Wonham have modelled a DES as a state machine (SM), and called it a plant. A state machine can be represented as a network, where a node represents a discrete state and a directed arc represents a state transition. An event causes a state transition. The event set of the state machine is partitioned into the set of controllable and uncontrollable events. The controller, also called a supervisor, exercises closed loop control over the plant is by disabling some of the events in order that the plant may achieve a certain prescribed behavior.
For example, the states of a machine represents activities in the machine, such as "idle", "machining", "loading", and "unloading", while transitions between states, i.e., events, represents the completion of one activity and the start of another. A robot can be used to place a part into the machine. The "finished loading" event occurs once the robot finishes the loading process. The machine changes its state from "loading" to "machining" because of the event, "finished loading". The realization of the "finished loading" event can be achieved with a physical wire connection between the robot and the machine, and with the capability of part program to read this input information in the machine. However, it is possible that due to limitations, such as hardware support or, programmability of the IMDs, it may not be feasible to control some events. For example, an IMD may have just two binary inputs with both inputs used to receive commands from a cell controller. Thus, there is no available input for a robot connection. In this case, the event, "finished loading", is an uncontrollable event because of insufficient hardware support in this IMD. Therefore, it is necessary to analyze the capability of each IMD before one can investigate the controlling of the events. An event, such as "finished loading", is marked by a "message passing" between the machine and the robot in this thesis. The question then arises as to how to model a DES such that it can be used to analyze the "message passing" capability of a manufacturing cell.
Petri nets is one of the modelling techniques commonly used to represent a variety of discrete event systems, such as hardware, communication protocols, parallel programs, dynamic concurrent systems and distributed data bases. Petri nets are also used to model a variety of manufacturing systems [Freeman 1991] [Bastide and Sibertin-Blanc 1991] [Kasturia et al. 1988] [Martinez et al. 1987].
A Petri net is a graphic representation of a DES that can be used to model the interactions between concurrent processes in a system. The essential elements in any Petri net are circles, bars, and arcs. Circles represent places, or states. Bars represent transitions, or events. Arcs connect the places via transitions. The dynamic nature of the DES is modelled in a Petri net by the movement of tokens. A token, represented as a small dot, is placed in a circle to indicate that the state is active. The location and distribution of tokens in a Petri net is called its marking. The marking of the Petri net defines the state of the DES. A Petri net executes by firing its transitions. A transitions fires if all its input places contain tokens. After firing, the tokens are moved through the transition from its input places to its output places. The sequence of successive firings of the transitions in a Petri net represents the evolution of the system through its possible states.
Petri nets have been developed extensively since first introduced by Dr. Petri in 1962. A variety of versions have been developed including Condition-Event Nets, Place-Transition Nets, Individual-Token Nets (Colored Petri Nets) [Reisig 1992] [Jensen and Rozenberg 1991] [Peterson 1981].
A Condition-Event net consists of conditions and events, where conditions are represented by circles and events are presented as boxes. An directed arrow may be used to link a circle and a box. If there is an arrow from a circle to a box, the circle is the pre-circle of the box. On the contrary, if there is an arrow from a box to a circle, the circle is the post-circle of the box. Tokens can reside in circles. If there is a token in each pre-circle of a box, the event occurs and a token in each pre-circle of the event will be removed and placed into each post-circle of the event. The token removing and depositing process is called the firing of an event.
Place-Transition nets are an extension of the Condition-Event nets by associating a weight to each arrow. Places are represented by circles. Transitions are represented by bars. A transition is fired if each pre-place of the transition has the required number of tokens specified by the weight associated with the arc from the pre-circle to the box. After firing, numbers of tokens are removed from each pre-place and are placed in the post-place accordingly. The numbers of tokens removed from pre-places may not the same the number of tokens placed to the post-places.
In the above two nets, tokens can not be distinguished from each other. However, in some applications, it is necessary to use tokens to represent different types of real-world components. In order to be able to precisely indicate different types of tokens, the concept of individual-Token nets (or color Petri Nets) has been introduced. In addition to the different types of tokens which can flow through places of a net, each arc is associated with a label, which indicates what types of tokens and numbers of tokens which can flow between a place and a transition.
Two Petri net based models including time dependency have been developed in the last decade, timed Petri nets and time Petri nets [Freeman 1991] [Martinez et al. 1987]. Ramchandani's timed Petri nets are derived from Petri nets by associating a firing finite duration with each transition in the net. In his model, a transition takes time to fire and a transition must fire as soon as it is enabled. Merlin's time Petri nets are more general than timed Petri nets. In Merlin's model, a transition is associated with a time interval, a minimum time and a maximum time. A transition is fired at a random time within the interval once it is enabled.
The "message passing" in a manufacturing system can be considered as a discrete event system. Color tokens may be used to represent different types of messages which flow in a Petri net. A transition time may be used to indicate the time delay for a message passing. However, most Petri nets have been considered as a single level model. It often turned out that these net models were too low-level to cope with the real-world applications in a manageable way. It shows too many details at one time and this complexity makes it hard to recognize the structure of the system. This, particularly from a system design perspective, is due to a lack of a way of modularly modeling the control hierarchical structure and manufacturing devices by means of Petri nets. In order to deal with large scale systems, some hierarchy nets such as Channel-Agency Nets, Hierarchical Colored Petri Nets have been introduced [Jensen 1991] [Reisig 1992]. However, these nets don't take transition time delay into consideration. So, it is necessary that we find a way to model the system structurally as well as to preserve the nature of Petri nets, such as color tokens and time delay, for the message passing analysis.
Object oriented technology is a set of concepts originally developed in object-oriented programming languages. Recently, these concepts have been found to be useful in object oriented analysis and object oriented design. These object oriented techniques, such as decomposition, abstraction, and hierarchy are useful to conquer problems. The techniques provide a structured way to manage the complex problems.
Currently, many varieties of object oriented analysis and design methods appear in the literature, such as HOOD, Booch's, Rumbaugh's, Wirfs-Brock, and Coad's, each of which will be briefly described in terms of object identification and system representation if possible.
The Hierarchical Object Oriented Design (HOOD), targeted at the ADA community, is the standard European Space Agency (ESA) method for the architectural design phase of the Software Life Cycle [Drgiovanni 1991]. HOOD objects are used to represent software components and are classified into two types: active object and passive object. An active object has abilities to control the requests it receives. A passive object is simply a collection of operations, its implemented algorithm [Drgiovanni 1991]. A HOOD system is represented as a tree structure. The root of the tree is the root object, i.e., the modelled system. The leaves of the tree are terminal objects, i.e., those objects are directly described, without further splitting. The branches of the tree are derived from the include relationship. This tree is also called Design Process Tree because it is produced from the root object in an iterative manner following some design guidelines. HOOD is oriented towards ADA program developments [BOOCH 1991] [Drgiovanni 1991]. The information associated with HOOD objects is described by means of Ada pseudocode. The code associated with each HOOD object in the design phase can be reused in the final coding. However, the pseudocode is not suitable for formal verification of properties of HOOD objects.
In Booch's work, three types of objects, actors, servers, and agents, are identified. An actor is an object that can operate upon other objects but that is never operated upon by other objects. A server object is an object that never operates upon other objects: it is only operated upon by other objects. An agent object is an object that can both operate upon other objects and be operated upon by other objects; an agent is usually created to do some work on behalf of an actor or another agent. An active object is simply one that encompasses its own thread of control, whereas a passive object does not. Active objects are generally autonomous, meaning that they can exhibit some behavior without being operated upon by another object. Passive objects, on the other hand, can only undergo a state change when explicitly acted upon. In Booch's method, a system is presented from two views: logical and physical. Four types of diagrams are used to represent a logical view of a system. They are class diagrams, object diagrams, state transition diagrams, and timing diagrams. A class diagram is used to show the existence of classes and their relationships. An object diagram is used to show the existence of objects and types of message synchronization between objects. The dynamic behavior of an object is described by a state transition diagram. The collaboration of objects by the ordering of message passing is represented by timing diagrams. Two types of diagrams, module diagrams and process diagrams, are used to describe the physical view of a system. A module diagram is used to show the allocation of objects to modules in a physical system. A process diagram is used to allocate the processes to processors in a physical system.
Rambaugh's et al. method is based on entity-relationship modelling [Rumbaugh et al. 1991]. A system is represented by three models: object model, dynamic model, and function model. The object model describes the structure of objects in a system - their identity, their relationships to other objects, their attributes, and their operations. This object model provides the essential framework into which the dynamic and functional models can be placed. The dynamic model describes those aspects of a system concerned with the timing and the sequencing of operations. The dynamic model is represented graphically with state diagrams. Real-time issues, such as timing requirements on interactions, are not considered. The functional model describes those aspects of a system concerned with transformations of values. The functional model is represented with data flow diagrams.
The method of Wirfs-Brock et al is a responsibility driven technique, an operational view of object interaction [Wirfs-Brock et al. 1991]. Responsibility-driven design models an application as a collection of objects that collaborate to discharge their responsibility. Index cards are used to capture the objects (classes), responsibilities, and collaborations. A system is decomposed into subsystems. A subsystem is a set of such classes (and possibly other subsystems) collaborating to fulfill a common set of responsibilities. A collaborations graph is used to analyze paths of communications and identify potential subsystems.
Coad and Yourdon's defines object-oriented analysis as an improvement of information modelling [Coad and Yourdon 1990] [Coad and Yourdon 1991]. A system is described in terms of five layers: object, structure, subject, attribute, and service. The object layer identifies the objects in the system. The structure layer connects the relationships between objects. The subject layer divides objects into groups. The attribute layer describes the data elements of an object. The service layer identifies the processing to be performed in an object when receiving a message.
The main difference of these methods is their specific ways of representing and modeling a system. Generally speaking, these methods are developed to provide better modeling tools for the software systems. However, these methods may not be used to model the message passing appropriately. For example, text descriptions or pseudocodes are commonly used to describe implementations. Normally, the text or pseudcode is not suitable for the analysis. Also, each method does not explicitly consider message passing time delays.
PROTOB (an object oriented language and methodology based on PROT net) is an example of efforts to integrate Petri Nets with object oriented technology [Baldassari and Bruno 1991] [Bastide and Sibertin-Blanc 1991]. The purpose of PROTOB is to provide a way to represent a model which has the capability of executing or simulating. An object is a module, encapsulated executable code. Two types of objects are identified: active and passive objects. An object is active if its response to external stimuli may be delayed. Otherwise, an object is a passive object. Objects can also be classified from the application perspective: PROT objects and package objects. A PROT object is represented by a PROT nets, like Petri Nets. A PROT objects may contain other PROT objects or packages objects. However, a package object can only contain other package objects. A PROT object is always an active object. A PROT object can be represented by its associated views. For example, a workstation in a manufacturing cell can be represented as a PROT object. A workstation may be in either of two situations: working and failure, each of which is represented by a view. In each view, a PORT net is used to described the operations. A package object is represented by a textual script description, using the HOOD methodology. Time delays are not explicitly expressed in both objects.
Graphical representation is another feature of Petri nets. A graphical representation provides a means of communication during the system design process. In addition to the Petri nets, two other graphic modelling approaches, IDEF0 and Data Flow, are also reviewed. The IDEF method was developed by the U. S. Air Force's program for Integrated Computer Aided Manufacturing (ICAM) to provide a better communication and analysis method for the people involved in improving the productivity of manufacturing [IDEF0 1981]. IDEF0, a graphic modelling methodology, can be used to produce a function model. An IDEF0 model starts by representing the whole system as a single box with arrows representing interfaces to functions outside the system. Then, the box is decomposed into sub-boxes with arrows interface among them. Each box represents a functional module. Each arrow represents an interface between functions. This decomposition process continues until the required level of detail is satisfied. Text is generally used to describe the function of each box. Therefore, the model of a manufacturing system is represented by a series of diagrams composed of boxes and arrows. This decomposition requires knowledgeable humans to map the system functions and sub-functions. The Data Flow Approach maps the system into data (& control) flows, data stores, and bubbles (circles) [Coad and Yourdon 1990] [Yourdon 1989]. Bubbles are used for data (& control) transformation. Arrows are used to represent the data (& control) flow. Text-based description, minispecs, are used to describe the transformation activity. The decomposition starts by representing a system as a whole bubble with arrows representing interfaces to outside systems. Then a bubble is decomposed into sub-bubbles with arrows among them. A model of a manufacturing system using Data Flow is a series of diagrams composed of bubbles and arrows. This mapping requires the analyst to follow the flow of data whenever looking at the real world, and map that flow for subsequent analysis and specification.
The benefit of these two approaches is that they provide structured decomposition methods. A system is modelled as a collection of diagrams arranged in a hierarchy. These two approaches differ in that they decompose the system from different aspects: one from a functional perspective and the other from data (& control) flow.
In summary, the characteristics of "message passing" embedded in a distributed manufacturing systems as developed above can be listed as follows. These characteristics provide insight for selecting among existing modelling techniques and for developing new modeling techniques that are not available in the literature.
In order to analyze message passing and message reachability, a modelling technique must be able to capture all the above characteristics. In this research, a modelling technique is developed which integrates IDEF0 and color timed Petri nets using an object-oriented paradigm. The rationale for selecting this combination of modelling techniques will be discussed in the following.
An object is a basic component in the object oriented technology. An object contains data and services. An object may request a service of another object by sending a message. An object may be used to model a single independent execution module, also known as a thread of control, in a manufacturing system. A collection of objects can be used to model concurrent modules that communicate following a client-server protocol. A program or a hardware component that communicates should have at least one thread of control. The concept of a thread of control in software engineering is the root from which independent dynamic actions occur within a system. Well-formulated objects allow reusability and lead to significant reductions in the modelling effort. Furthermore, objects are convenient for modelling communicating modules because of their natural association with actual components such as machines, programs or buffers. The object oriented technique also offers containing relationships between objects that can be used to describe the system hierarchy. What is missing from the object oriented technique that is needed for modeling message passing is a structured decomposition technique specifically for manufacturing systems which provides an explicit description of time or state dependencies in its services.
IDEF0 is a structured decomposition technique that produces a graphical representation of the functions of the system. This graphical representation has been recognized as promoting a better communication vehicle in planning, developing and implementing the manufacturing systems. In IDEF0, a box is a unit representing a simple function or a composite function. One of the major advantages of IDEF0 is its classification of four types of interfaces and the association of each with a different side of a function box. This classification and designation enhance the readability of a graphical model tremendously. In the models developed, an object is represented by a box. Messages associated with each side of a box can be used to illustrate the types of message that an object can receive and send. Another advantage of IDEF0 modeling is its structured graphical decomposition scheme. This scheme can also be applied in object oriented modeling. A system can be modeled as a single aggregated object and be decomposed progressively to introduce more and more detail.
Petri nets have been widely adopted for modelling discrete event systems. Petri nets provides graphical and algebraic tools for modelling both conditions and events explicitly. The biggest concern associated with Petri nets is the complexity inherent in its explicit nature. The Petri net model of a relatively simple system can be rather large. But if a Petri net is only used to model a single message service within an object, the complexity may be acceptable. Time delays can also be associated with each transition in the timed Petri net.
The modeling technique to be developed in this thesis will be a hybrid of objects and Petri nets, organized using the concepts of IDEF0. Since there are both objects and Petri nets in the model, it is necessary to develop the interactions between the two. These will be discussed in the next chapter. In essence, a message can be modelled as a token in both object and Petri net. The messages which pass between objects may be modelled as interactions with a set of special places, input places and output places, in objects. A message can be modelled as token movement from an output place of one object to an input place of the other object. In this scheme, message passing can be described consistently with the Petri net representation of objects. In a client-server protocol, communication modules are coupled loosely. An object that requests a service does not provide a hard condition for the object that provides service. Rather, it presents a message to another object, which controls the handling of the message. The resultant Petri net of an object may be very complex. However, the message passing between objects is simple. In effect, using this hybrid offers a structured way to develop modular Petri nets for a system.
In summary, in order to model the characteristics of message passing using various modeling techniques available, it is most suitable to develop a hybrid modeling technique that utilizes objects and Petri nets as appropriate for given levels, with an IDEF0-like hierarchical representation for message passing and analysis. The model should provide a graphical representation for ease of communication, and an analytical procedure for unambiguous determination of message reachability.
Next Chapter