Using Concurrent Programming for Speci cation of Manufacturing Systems J.M. van de Mortel-Fronczak and J.E. Rooda Eindhoven University of Technology, Department of Mechanical Engineering, P.O. Box 513, 5600 MB Eindhoven, The Netherlands Phone: +40 2472892, Fax: +40 2452505 E-mail address:
[email protected]
Abstract When modelling manufacturing systems, di erent approaches can be followed giving rise to two model categories: mathematical and simulation models. Mathematical models come from two areas. Queuing networks, Markov chains, perturbation analysis, and the like, stem from operations research. Petri Nets and concurrent programming provide examples of models from computing science. An important feature of the latter ones is that except for providing a basis for formal reasoning, they can also be used for simulation purposes. Originally developed for modelling and analysis of computer hardware and software, these formalisms are also well suited to model information and control ows in manufacturing systems usually exhibiting concurrency and nondeterminism. In this paper, we discuss application of concurrent programming to speci cation of manufacturing systems.
1
1 Introduction In manufacturing systems, there is more going on than just creation of products. Organisational aspects of production are of great importance, as well. As a consequence, a lot of attention is payed to production planning methods, such as MRP and JIT ([Chas]). These methods of planning are based on an integral control of the stream of goods. In mass production, they provide good results. Other types of production systems are less easy to control in such a way. In particular, the diculty of realising an \optimal" plan is painfully apparent in exible production systems. While from the technological point of view, production in this kind of systems can be extremely exible, inadequate planning methods substantially reduce this exibility. Only with diculty is it possible to draft an appropriate plan, and it remains an open question whether the strategy to be adopted is the best possible one. It is, by the way, not so surprising that this problem is so distinctly present within exible manufacturing. In contrast to mass production, exible manufacturing is directed at short run and single item production. In exible manufacturing, the di erent production stages are not only related by the material ow but also by the technical and organisational aspects. It is clear that it would not be correct to deal with these aspects with the aid of a product-oriented approach, since they are not tied to the product but rather to the process. Attempts at describing the control of production by means of sequential methods will not help, either, since the whole production process cannot be comprehended in that way. Both men and machines operate in parallel. The continuous process of the mechanisation of labour is a characteristic of the development of technology. Machines were developed to mechanize the work process and, at the same time, control components were developed for the machines, beginning with machine-speci c controllers to eventually arrive at universal ones, such as programmable logic controllers (PLCs). With PLCs, it is possible to control very complex machines. But with increasing machine size it becomes increasingly dicult to gain an insight into the correctness of programs. The reason for this boils down to the fact that a PLC executes a completely sequential program. In the machine, however, the various sub-operations can take place simultaneously. Therefore, it seems justi able to introduce a perception within which the parallel character of the machine can be viewed. Whenever we think in greater depth about why it is so dicult to control machines and aggregates of machines and people we may conclude that this has to do with the fact that many simultaneous operations take place, both in machines and in machine/person aggregates. Most of the concepts and techniques for analysis of manufacturing systems that have been developed to date pay no attention to this simultaneous character. One viewpoint that is suitable for this purpose is the use of parallel descriptions. In this case, manufacturing systems are treated as collections of independent components that interact by exchanging information. In the past we have developed simulation packages based on parallel descriptions and embedded in programming languages, such as Sole ([Ro1]) based on Simula67 ([Dah]), S84 ([Ro2]) based on Modular Pascal ([Bro]) and ProcessTool ([Wor]) based on Smalltalk-80 ([Gol]). An alternative viewpoint is the use of Petri Nets, as elaborated 2
in [Sil] and [Dav]. The view of manufacturing systems as collections of co-operating independent components can be derived from general ideas of concurrent programming ([Bur]). The behaviour of components can be speci ed by concurrent programs. The resulting speci cations are called models in the sequel. The language we use to denote models is adopted from [Hoo] and is a CSP-derivative ([Hoa]). Such models can be validated by sequential or distributed simulation ([Mis]). Moreover, an important feature is that CSP provides a basis for formal reasoning. The underlying mathematical framework can support the veri cation of models. With we can model the material ow as well as the control ow in industrial systems. To specify data and data processing functions we use a functional notation ([Bir]). The paper is organized as follows. In Section 2, the modelling approach based on communicating sequential processes is explained. For this purpose a part of [Mo1] is used. According to this approach, in Section 4 a few components of a manufacturing system are speci ed. Section 3 shortly describes implementation aspects. Section 5 presents some concluding remarks.
2 Short description of A (manufacturing) system is modelled by a nite set of processes and a nite set of channels used for communication or synchronization among the processes. Processes model components of the system and channels model the connections among them. In the sequel, such sets of processes are called systems for short. A process is speci ed by a program in a CSPlike programming language preceded by declarations of local variables. For communication, synchronous message-passing is used. If c is a channel between two processes, by executing for instance c!e in one process and c?x in the other, a distributed assignment of the value of e to variable x is realized. Processes do not share variables | they interact exclusively by using the communication and synchronization primitives. Every process is sequential. Processes in a system can execute concurrently between synchronization points. The language used to denote programs (that specify the behaviour of components) is adopted from [Hoo] and is similar to Occam [Inm] | a CSP-like programming language. As opposed to [Hoo], multiple timeouts (an example of this is shown in [Mo1]) and besides inputs also outputs are allowed in guarded commands. Moreover, a special variable ( ) is introduced to represent the current time (of a process), which may be used in expressions. The language consists of: assignment, selection (nondeterministic choice), repetition, sequential composition, communication and synchronization primitives, time passing and selective waiting. Its syntax is given by Table 1. In the de nition, n stands for a natural number (n 0), r for a real expression, c for a channel name, b for a boolean expression, x for a variable name, and e for an expression (of the same type as x). Expressions r, b, and e may explicitly refer to . Sequences of capitals denote nonterminal symbols of the grammar. The expressions b and b ; ( belongs to the category TC ) appearing before the arrows are called guards. A guard is open if it evaluates to true or, in the case of guards with interactions, if its boolean part evaluates to true. 3
TC ::= r j c!e j c?x j c G
::= [GB ] j [GC ]
GB ::= b ?! S j GB [] GB GC ::= b ; TC ?! S j GC [] GC S
::= skip j x := e j TC j S ; S j G j G j nG Table 1: The syntax of the language
The statements (S ) have the following informal meaning.
skip terminates without in uencing the program state. x := e denotes the assignment of the value of e to the variable x. r denotes time passing: the value of is increased by the value of r if it is not
negative, otherwise, the statement terminates without in uencing the program state. Communication statements c!e and c?x are used to send the value of e along channel c and assign it to x. The communication takes place as soon as both communication partners are ready for it (the value of variable in both processes is set to the maximum of the corresponding -values before the communication). Execution of the synchronization statement c by two processes is similar to the communication except that no value is passed. S1 ; S2 denotes sequential composition of two statements: S1 is executed rst and if it terminates S2 is executed next. Guarded command [GB ] denotes nondeterministic choice. It terminates if there are no open guards. Otherwise, a statement associated with an open guard is nondeterministically chosen for execution. Guarded command [GC ] denotes selective waiting. It terminates immediately if there are no open guards. Otherwise, the execution proceeds as soon as an interaction (communication or synchronization) associated with an open guard is possible. After the execution of the (possibly nondeterministically chosen) interaction (the value of variable in both processes changes accordingly), the corresponding statement is performed. If [GC ] contains time-outs (r) in open guards and no interaction is possible within the period determined by the smallest value of all time-outs, then the value of is increased by this smallest time-out value and a statement associated with a time-out that evaluates to this value is chosen for execution. Otherwise, only the interactions 4
that are possible within the smallest time-out are considered as above. If the smallest time-out value is negative the execution of the statement associated with it starts immediately | the value of does not change. G denotes repetition: it terminates if none of the guards is open. nG denotes iteration: guarded command G is executed n times (n 0). The repetition [true ?! S ] may be abbreviated to [S ]. Commands guarded by interactions or time-outs of the form true ; ?! S may be abbreviated to ?! S . Commands guarded by interactions or time-outs of the form b ; ?! skip may be abbreviated to b ; . If b is syntactically equal to true this can be replaced by . Informally, the speci cation of a process has the following general form: proc
name (parameter list) =j[ declarations j S ]j.
All channels have to be listed as process parameters. If a channel is used for passing values of some type, this type must be associated with the channel and is in the sequel referred to as the channel type. Informally, the speci cation of a system has the following general form: syst
name (parameter list) =j[ channel declarations j P1 k P2 k : : : k P ]j, n
where n 1 and P , for 1 i n, is an instance of a process or of a (sub)system. For a system holds that channels used in only one process instance have to be listed as system parameters. The types of all channels used in two process instances have to be declared. We distinguish two types of systems: open and closed systems. A system is closed if there are no port names in its parameter list and it is open otherwise. Except for channel parameters, processes and systems can have value parameters as shown in the examples. The speci cation language is illustrated by a couple of small examples. In the sequel, the following notations are used: i
[1; 2; 3] denotes the list of three numbers: 1, 2, and 3; [ ] denotes the empty list, b ++[a] denotes the list constructed by appending element a to list b, hd b denotes the rst element of list b, tl b denotes the list that results from removing the rst element of list b.
5
Example 1 The rst example describes a model of a simple system that consists of two components: the producer (P ) and the consumer (C ). The producer produces, for instance, boxes which are subsequently used by the consumer. The production time of each box (in seconds) is drawn from a continuous uniform distribution over the interval between 5 and 10. When a box has been produced it is passed to the consumer. Passing a box is modelled by a synchronization on channel pc. The consumer needs 7.5 seconds to manipulate a box. The speci cation of P looks as follows: proc
P (pc : ) =j[ : dist j := cun 5 10 ; [ sample ; pc ] ]j,
where sample denotes drawing a number from the continuous uniform distribution between 5 and 10 (cun 5 10). The speci cation of C looks as follows: proc
C (pc : ) = j[ [ pc ; 7:5 ] ]j :
The producer-consumer system, graphically presented in Figure 1, is speci ed by: syst
PC = j[ pc : j P (pc) k C (pc) ]j : P
pc
C
Figure 1: The producer-consumer system
2
Example 2 As an illustration of the selective-waiting construct, an in nite bu er (B ) is presented. It describes a component which receives and returns objects of type T in a rst-in rst-out fashion. The type of objects is a (type) parameter of the process describing the bu er. If the bu er is empty, the only possible action is to put an object into it. If it is not empty, either an object can be put into it or an object can be retrieved from it. The contents of the bu er is modelled by a list of objects (xs of type T ), and list operations model putting and retrieving values. The bu er is speci ed by: proc
B (T : type, r : ?T; s : !T ) =
j[ x : T; xs : T j xs := [ ] ; [ r?x
?! xs := xs ++[x] 6
]j.
[] xs 6= [ ] ; s! hd xs ?! xs := tl xs ]
Bu ers are often used to eliminate unnecessary waiting in producer-consumer systems like the one described in the previous example, where the consumer is not able to keep pace with the peak rate of production but it can cope with the average rate. The bu er simply accumulates items if the production rate is too high for the consumer. If the production rate becomes lower, the consumer can proceed working on the accumulated items. The bu er is used in Section 4.
2
For the speci cation language presented above, an operational semantics has been de ned ([Mo2]). This is done by de ning for each (closed) system the possible states and state transitions that are allowed.
3 Implementation aspects In the previous sections we presented the speci cation language . Through the operational semantics and the underlying formal framework, models described in are already suited for analysis of some properties related to the static behaviour. However, to analyse the dynamic behaviour it should be possible to simulate models. To achieve that we had to make a few choices. We decided not to embed the concepts of directly in a programming language (as it was the case with ProcessTool and its predecessors) but to make this speci cation language executable. In this way the modeller can concentrate on one, small and compact, language. To make executable we decided to base its implementation on C++ ([Nau]). This choice is mainly in uenced by the considerations related to the eciency of code execution. Making executable comprises building a compiler of delivering C++ code and a tool capable of executing this code in a proper way (that is, according to the operational semantics de ned). However, the user of has no need to analyse the C++ code. Both the syntax and execution error messages relate to the code. The compiler has been built with the help of the compiler construction system Eli ([Gra]). As C++ does not provide multitasking for the PC-platform, parallel processes of models have to be executed sequentially in an order respecting the operational semantics. To this end, a scheduler has been developed that controls in a proper way three lists of active, passive, and sleeping processes. The above information refers to the implementation of behavioural descriptions. The implementation of data types comprises translating them into C++ classes. The implementation of functions is still an open end. For more information on the implementation aspects the reader is referred to [Nau].
7
4 An example In this section, a speci cation is presented of a (sub)system for processing of products characterized by very limited keeping qualities. This presentation is based on one of the examples in [Ro3]. The system, graphically exposed in Figure 2, consists of two kinds of bu ers: A and B , and two kinds of processing units: P and Q. To be more precise, we have one instance of A, three instances of B , two instances of P , and one instance of Q. B qa a
A
ap
P
pb
bq' bq
B
aq
qb
Q
pb'
B
bp
P
q
Figure 2: A system with bu ers and processing units Products are gathered in bu er A, which is the input bu er of the rst processing unit P , in sets of at least 4 and at most 8. After being processed by P , via a B -bu er they proceed to the processing unit Q. From there they continue their way to the second processing unit P , and then they return to Q (via two B -bu ers). After the completion of this cycle, they leave the system. Only when the whole set has left the system, a new one may be gathered in bu er A. Bu er B is the bu er with in nite capacity, as described in Section 2. In the sequel, we provide descriptions of the remaining system components. As already mentioned, in bu er A products are accumulated (in the list xs). The arrival of products is modelled by communications on channel a. The transfer of products to the rst processing unit P , modelled by communications on channel ap, may begin when 4 of them are available in A (p becomes true). Products that arrive before the transfer is completed (with the maximum of 8) belong to the same set. When the transfer is completed (xs becomes empty), the size of the transferred set is passed to the processing unit Q. This is modelled by sending the value of variable n, used to count the size of the set, along channel aq. The bu er may start accumulating a next set if the synchronization along qa has taken place. We specify bu er A by:
A(a : ? prod; ap : ! prod; qa : ; aq : ! nat) = j[ xs : prod; x : prod; n : nat; p : bool j xs := []; n := 0; p := false ; [ n < 8; a ? x ?! xs := xs ++ [ x ]; n := n + 1; p := p _ n = 4 [] len xs > 1 ^ p ; ap ! hd xs ?! xs := tl xs [] len xs = 1 ^ p ; ap ! hd xs ?! xs := tl xs ; aq ! n ; n := 0; p := false; qa
proc
8
]
]j : P processes received products one by one and passes them through, which is modelled by the communication along ap, time passing ( t), and the communication along pb. Processing unit P is speci ed by: proc P (ap : ? prod; pb : ! prod; t : time) = j[ x : prod j [ ap ? x ; t ; pb ! x ] ]j : After processing in the rst P -unit, the products arrive in Q via a B -bu er, which is modelled by communications along channel bq. The processing is modelled by time passing ( 3). Processed products are passed to the next P -unit, again via a B -bu er. This is modelled by communications along channel qb. When the whole set has been processed and send to P (the set size is received along aq and n = i), it returns to Q (product by product, along channel bq0) for the subsequent processing and leaves the system via channel q. Q signals then A to start accumulating the next set (qa ). We specify process Q by: proc Q(bq : ? prod; qb : ! prod; bq 0 : ? prod; q : ! prod; qa : ; aq : ? nat) = j[ x : prod; i; n : nat; p : bool j [ i := 0; n := 8 + 1; p := true ; [ p ?! [ bq ? x ?! 3; qb ! x ; i := i + 1 [] aq ? n ] ; p := n 6= i ] ; n[ bq0 ? x ; 2:5; q ! x ] ; qa ] ]j : The whole (open) system, named S , is speci ed by: syst S (a : ? prod; q : ! prod) = j[ ap; pb; bq; qb; bp; pb0; bq0 : prod; qa : ; aq : nat j A(a; ap; qa; aq) j P (ap; pb; 3) j B (pb; bq) j Q(bq; qb; bq0; q; qa; aq) j B (qb; bp) j P (bp; pb0; 5) j B (pb0; bq0) ]j : The above model has been analysed by means of simulation. The results, however, are not included in this paper.
5 Concluding remarks The modelling approach discussed in this paper was already frequently and successfully applied in the area of manufacturing systems by the Systems Engineering group of Eindhoven 9
University of Technology. Examples of models built according to this approach and validated using simulation tools implemented in various programming languages include a tyre manufacturing factory ([Are]), an IC manufacturing system ([Smi]), and a exible manufacturing cell ([Mo3]). Our experience indicates that real-time concurrent programming is well suited for modular speci cation of manufacturing systems. For this purpose, every component in the system is modelled as a (parametrized) process. The description of the component behaviour is separated from the description of the system structure, which can be presented graphically. Component descriptions are concise and comprehensible. The speci cation language itself is small, compact, and orthogonal. On the other hand, the fact that it does not support the notion of procedure may be seen as a shortcoming. Moreover, the way in which channels leading from one process to (many) instances of another one are dealt with (see, for instance, [Mo1]) is not satisfying. The formal meaning of speci cations is de ned by means of an operational semantics that respects concurrency and that is based on the notion of transition systems. The behaviour of speci ed systems can be analysed by means of sequential or distributed simulation (comparable to, for instance, the ones discussed in [Kos] or in [Mis]). For the veri cation of the communication behaviour embedded in a model, the underlying formal framework of CSP can be used. We believe that it is very important to support modelling by formal and structured methods as it is the case for software development ([Bow]). Even large and complex modelling projects can bene t from it. A compiler and a simulator have been developed as a part of the software system supporting speci cation activities based on the presented language. The project is still under continuation. This includes also the extension of the language in order to allow hybrid (combined discrete event and continuous time) descriptions and the development of a simulator for hybrid models.
References [Are] J.H.A. Arentsen. Factory Control Architecture. A Systems Approach. Ph.D. Thesis, Department of Mechanical Engineering, Eindhoven University of Technology, 1989. [Bir] R. Bird and P. Wadler. Introduction to Functional Programming. Prentice-Hall, 1988. [Bow] J.P. Bowen and M.G. Hinchey. Seven More Myths of Formal Methods. IEEE Software, July 1995, pp. 34 { 41. [Bro] C. Bron. Modular Pascal Language De nition. Memo INF 82-10, Department of Computer Science, University of Twente, 1982. [Bur] A. Burns and G. Davies. Concurrent Programming. International Computer Science Series. Addison-Wesley, 1993. [Chas] R.B. Chase and N.J. Aquilano. Production and Operations Management. Irwin, 1995. 10
[Dah] O.-J. Dahl, B. Myhrhaug and K. Nygaard. Simula-67 Common Base Language. NCC Publication S-52, Norwegian Computing Centre, 1970. [Dav] R. David and H. Alla. Petri Nets for Modeling of Dynamic Systems | A Survey. Automatica, Vol. 30 (2), 1994, pp. 175 { 202. [Gol] A. Goldberg and D. Robson. Smalltalk-80. Addison-Wesley, 1989. [Gra] R.W. Gray, V.P. Heuring, S.P. Levi, A.M. Sloane, and W.M. Waite. Eli: a Complete, Flexible Compiler Construction System. Communications of the ACM, 35, 1992, pp. 121 { 131. [Hoa] C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985. [Hoo] J. Hooman. Speci cation and Compositional Veri cation of Real-Time Systems. Springer-Verlag, 1991. [Inm] INMOS Limited. Occam 2 Reference Manual, Prentice-Hall, 1988. [Kos] J. Koster. Modelling Industrial Systems: Theory and Applications. Ph.D. Thesis, Department of Mathematics and Computing Science, Eindhoven University of Technology, 1993. [Mis] J. Misra. Distributed Discrete-Event Simulation. Computing Surveys, vol. 18 (1), 1986, pp. 39{65. [Mo1] J.M. van de Mortel-Fronczak and J.E. Rooda. Application of Concurrent Programming to Speci cation of Industrial Systems. In Proceedings of INCOM'95, Beijing, China, October 1995. To appear. [Mo2] J.M. van de Mortel-Fronczak. Operational Semantics of . Technical Report WPA 420062, Department of Mechanical Engineering, Eindhoven University of Technology, 1995. [Mo3] J.M. van de Mortel-Fronczak, J.E. Rooda, and N.J.M. van den Nieuwelaar. Speci cation of a Flexible Manufacturing System Using Concurrent Programming. The International Journal of Concurrent Engineering: Research & Applications, 3(3), 1995. To appear. [Nau] G. Naumoski and W.T.M. Alberts. The Engine: a Fast Simulator for Systems Engineering. Final Report of the Postgraduate Programme Software Technology, Eindhoven University of Technology, 1995. [Ro1] J.E. Rooda. Simulation of Logistics Elements (Sole). User Manual, Department of Mechanical Engineering, University of Twente, 1982. [Ro2] J.E. Rooda, S.M.M. Joosten, T.J. Rossingh, and R. Smedinga. Simulation in S84. User Manual, Department of Mechanical Engineering, University of Twente, 1984. 11
[Ro3] J.E. Rooda. The Modelling of Industrial Systems. Lecture Notes, Department of Mechanical Engineering, Eindhoven University of Technology, 1995. [Sil] M. Silva and R. Valette. Petri Nets and Flexible Manufacturing Systems. In G. Rozenberg (ed.), Advances in Petri Nets, LNCS, vol. 424, Springer-Verlag, 1990, pp. 374 { 417. [Smi] H. Smit. A Hierarchical Control Architecture for Job-shop Manufacturing Systems. Ph.D. Thesis, Department of Mechanical Engineering, Eindhoven University of Technology, 1992. [Wor] A.M. Wortmann and J.E. Rooda. ProcessTool. User Manual, Department of Mechanical Engineering, Eindhoven University of Technology, 1990.
12
