The use of Estelle to specify manufacturing systems

North-Holland Microprocessing and Microprogramming 28 (1989) 253-258

253

The use of Estelle to specify manufacturing systems M. Morisio

and

R. Sisto

Dipartiinento di Automatica e Informatica, Politecnico di Torino Corso Duca degli Abruzzi 24, 10129 Torino, Italy This paper proposes the use of Estelh (a specification language standardized by ISO) to specify Manufacturing Systems. After a review of the main features of manufacturing systems and of EsteUe, a case study is presented: the specification of a Flexible Manufacturing System. Advantages and disadvantages encountered in the use of Estelle to specify Manufacturing Systems are highlighted.

1

Introduction

A discrete part manufacturing system (MS) receives raw materials and semi-manufactured parts, works or assembles them and outputs a set of finished or semimanufactured products. Three kinds of components can be individuated in it: machines, controls (programmable logic controls, numerical controls, robot controis) and computers: the latter coordinate, command and get feedback from the former two. An MS is therefore a complex system featuring real time distributed software, large databases handling, sophisticated scheduling issues. People involved in manufacturing need to analyze the behavior of existing MSs and to specify and design new ones. In other words they need to model them with a language which should be formal in order to allow verification of the consistency of the specification, provide concurrency constructs to model the paralhl activities happening in an MS, support hierarchical decomposition/composition to mirror the different levels in which an MS is organized. EsteUe, a language standardized by ISO to describe the logic of processes in communication protocols, satisfies the listed requirements: it is formal and executable [8], describes concurrency using extended state machines that communicate with one another by the exchange of non-blocking messages, is based on a powerful and flexible programming language such as Pascal, and can be hierarchically structured. From these considerations the idea of experimenting Estelle to model MSs was born. In this paper we present a case study, the specification of a Flexible Manufacturing System (FMS), which is representative since it resumes the key issues in MSs. We also outline advantages and disadvantages encountered in the use of Estelle to specify MSs. The paper is organized as follows: section 2 describes the characteristics of MSs, section 3 introduces Estelle, section 4,is dedicated to present the case study, section 5 balances advantages and disadvantages encountered.

2

Manufacturing

systems

Discrete part manufacturing systems [1,2] are distributed, discrete event systems, in which different description levels implying different time scales, event types and decision kinds can be identified: m a c h i n e level: at this level typical hardware includes simple machines (drilling, milllng, boring machine, lathe) and programmable ones (numerical control, machining center, robot); events, the beginning and the end of an operation on a piece in a machine, happen every fraction of second or second, control decisions are very simple (operation sequencing) and are taken by programmable logic controls, numerical controls and robots according to the downloaded part programs. cell level: a cell, the first level of aggregation of an MS, is composed of machines connected by a transportation system which is made up of transfer lines or automatic guided vehides (AGV's). Events, the transfer of pieces among machines, happen every second or minute, control decisions involve the routing and priority of pieces and the tooling of machines. Hardware includes a real time minicomputer or personal computer where control decisions and monitoring happen, and a local area network. s h o p level: a shop is composed of cells and a transportation system; events are the beginning and end of the work for a lot (a collection of equal pieces to be produced), a machine, breaking down or the scheduled maintenance. Events happen every hour or day and impose decisions about scheduling of lots on the shop. A minicomputer and a local area network must be provided. p l a n t level: many shops compose a plant. Functions to be performed on a supermini or a duster are long term scheduling (every day or week), product and process design storing, inventory control, purchase order control, customer order processing.

M. Morisio, R. Sisto / Use of Estelle to Specify Manufacturing Systems

254

The timing of events can vary very much: working a piece on a machine can take from fractions of seconds to several hours; what is constant is the growing interval between the events as the machine, cell, shop or plant levels are considered.

TRANS WHEN i.p PROVIDED b FROM f

It is commonly accepted that the levels described are organized in a hierarchical architecture [3,4,5], in which every level of aggregation is slave with respect to the higher one and masters the immediately lower levels. This architecture, suggested from the system theory, has emerged as a powerful means to approach complexity and to achieve decentralization and reliability.

3

Estelle

Estelle [6] describes a distributed system as a number of hierarchically organized processes called tasks. At the top hierarchical level, the specification can be structured into a number of system tasks, that is to say independent, asynchronously running processes, otherwise it is organized as a single system task. Every system task can be structured into several synchronous subtasks and these tasks may themselves be structured. Two tasks communicate with each other by exchanging information units (interactions) through bidirectional channels whose ending points (called interaction points) are provided with unbounded FIFO queues, preventing message losses. Each task is described as an extended finite state machine, the main extension being a piece of a Pascal program that can be associated to each transition and executed at the firing time. Particular statements are provided also to create or destroy sub-tasks and channels so that dynamic evolution of the system's structure can be described. Each transition has a number of firing clauses that, when satisfied, enable its firing. Fig. 1 shows the typical form of a transition definition having the following meaning: WHEN an interaction of type i is on the top of the queue associated to the interaction point p, PROVIDED that the boolean expression b is true, a transition is enabled FROM state f TO state t after a DELAY of n time units has expired. If more transitions are enabled at the same time, one of them is selected according to their respective priorities. Only if a task does not have any enabled transition, transitions of its sub-tasks can be executed. So, a father's transition has always implicit priority over the children ones. Within every task, according to the task's class, two execution policies may take place for the transitions of the children. In a process task, at each computation step, all the selected transitions (one for each sub-task) are executed in parallel, while in an activit!l task only one transition is non-deterministically chosen out of the previously selected ones and executed. From a syntactic viewpoint, an Estelle specification is composed of nested definitions of static entities called modules. Tasks are the run-time instances of modules.

TO t

DELAY n

PRIORITY x BEGIN

END

Figure 1: The structure of a transition in Estelle The specification of a module is composed of a module header definition, where the external interaction points and the exported variables of the module are defined, and a module body definition, composed of three parts. The first is the declaration part, containing Pascal declarations, specifications of the types of channels that can be used within that module (defining what are the interactions that can be sent and received) and submodule definitions (corresponding to the sub-tasks that can be created within that module's instances). The second part is the initialization part that is a set of statements executed at the beginning, establishing the initial configuration of tasks and channels. The last part is the transition part which defines the transitions of the state machine associated to the module and the corresponding actions. Fig. 2 summarizes the structure of an EsteUe specification. The interested reader is addressed to [6,7] for further detMls about Estelle.

SPECIFICATION [] [] [] body-definition END

.

where

body-definition= declaration-part initialization-part transition-declaration-part

Figure 2: The structure of an Estelle specification

4

A case study

The model of a FMS for machining mechavAcal cylindricai parts is presented. The cell we consider is composed of three lathes, each of which is configured to execute a different set of operations by mounting on it the proper set of tools. A lathe has place for a single piece.

255

M. Morisio, R. Sisto / Use of Estelle to Specify Manufacturing Systems

An automatic transportation system routes the carts with parts to be worked to and from the lathes and an automatic device loads and unloads the parts on/down the lathes. A warehouse contains raw materials, semiworked and finished pieces. The lathes send to a dispatcher the requests of being loaded a n d / o r unloaded. The dispatcher receives from a higher level of the MS (which will not be considered in this example) a set of lots to be simultaneously produced, starts them and, during the manufacturing, tracks the state of each piece and the number of pieces produced for each lot. It also assigns each piece on which a manufacturing phase has been completed to a new lathe that is capable of performing the next operation required for tkat piece. As a piece is usually processed on more than one lathe, the dispatcher tries to transfer a piece directly from one lathe to another but if this is not possible the piece is temporarily stored in the warehouse. The Estelie model of the FMS will be presented topdown: the tasks and their interconnections (channels) first, the implementation of the tasks (the corresponding extended state machines) later. The b o l d face notation will be used to indicate Estelle entities or constructs. 4.1

Structure

of the

The declaration part of the specification also contains the module definitions listed in Fig. 5. They formally state the class of each module, what are its interaction points and, for each of them, what is the type of channel that can be connected to it.

request dispatche~

I

J

mission

transF~'rt

~

lathe2

fiowings Z[lathe3

~twarehoLIsel reauest_piece

system

]?he system is made up of 4 modules: l a t h e _ t y p e (with 3 instances named lathel,lathe2, lathe3), dispatcher _type, t r a n s p o r t _ t y p e and warehouse_type (see Fig. 3, 5). They have been defined as system tasks, i.e. they are executed asynchronously and in parallel. We have chosen an asynchronous model because it matches the real features of the components of an FMS better. In fact, the EsteUe tasks represent physically separated and independent parts. On the contrary, the internal behavior of each of the system tasks is described by a synchronous model: a single state machine for the lathes, the dispatcher and the warehouse and a set of dynamically created, synchronous, parallel subtasks for the transport process. Fig. 3 shows how the tasks are interconnected. There are 4 kinds of channels ( r e q u e s t , m i s s i o n , r e q u e s t _ p i e c e , f l o w i n g s ) whose formal definitions (included in the declaration part of the specification) are presented in Fig. 4. In particular, the r e q u e s t channel is used by a lathe to send the dispatcher a request (to be loaded a n d / o r unloaded), the m i s s i o n channel is used by the dispatcher to command the transport process to move a cart from a source (source) to a destination ( d e s t ) (m_uame is the identifier of the mission while re_type states the action(s) to be performed, such as load or unload), t r a n s p o r t is linked by a channel of type f l o w i n g s to each s e r v e r (a l a t h e or a warehouse). The messages empty_cart and ~ u l l _ c a r t represent the flow of carts (which can carry a piece or not) in the FMS. The r e q u e s t _ p i e c e channel is used by d i s p a t c h e r to ask warehouse how many pieces of the specified type it contains (message req_type). Using the same channel warehouse answers by sending a q u a n t i t y message.

lathe 1

Figure 3: the model of the FMS channel r e q u e s t ( l a t h e , by l a t h e load

dispatcher)

unload(piece) load_unload(piece) channel mission( dispatcher, transport) by dispatcher m i s s i o n _ r e q ( m_name, m_type, s o u r c e , d e s t ,

piece)

channel request_piece( dispatcher, warehouse) by dispatcher

req_type(piece_type) by warehouse

quantity(n_pieces) channel flowings( transport, server) by transport full_cart( cart_name, piece) empty_cart (cart_name) by server full_cart( cart_name, piece) empty_cart (cart_name) Figure 4: definition of channels

M. Morisio, R. Sisto / Use of Estelle to Specify Manufacturing Systems

256

i

Em ~:'ty _~

module d i s p a t c h _ t y p e systemprocess

i p 1: a r r a y [ 1 . . l O ] of r e q u e s t ( d i s p a t c h e r ) ; m: m i s s i o n ( d i s p a t c h e r ) ; w: r e q u e s t _ p i e c e ( d i s p a t c h e r )

Em pt:~ Jau Ity

.¢,.,

( s)

end; module t r a n s p _ t y p e systemprocess

~_._Fu ll_w,:::,r k i n ,:j

i p m: m i s s i o n ( t r a n s p o r t ) ; 1: a r r a y [ 1 . . l O ] of f l o w i n g s ( t r a n s p o r t ) ; w: f l o w i n g s ( t r a n s p o r t )

end; module l a t h e _ t y p e systemprocess

ip r: r e q u e s t ( l a t h e ) ; t: flowings(server)

......... '"

Full_faulty

end;

Fu!Lfi his bed

module ware_type systemprocess

Figure 6: lathe, the state machine

i p d: r e q u e s t _ p i e c e ( w a r e h o u s e ) ; t: flowings(server)

• F u l l _ f i n i s h e d ---* Full_working: a cart loading a piece arrives; it is unloaded, loaded with the worked piece and sent back.

end;

Figure 5: specification of modules

4.2

Behavior

of tasks

The complete formal specification of the bodies (state machines) of the various tasks can not be shown here for lack of space. Therefore we give the complete specification only for the lathe task (Fig. 7). A lathe can contain a piece or not, can be operative or broken; the resulting states are: • Empty when it does not contain a piece and waits

to be loaded; • Full_working when it works a piece;

• F u l l _ f i n i s h e d when it has finished to work a piece and wails to be unloaded; • F u l l _ f a n l t y when a breakdown has happened while it was working a piece; • Empty_faulty when it is broken and it does not contain any piece. Fig. 6 shows the state machine of the lathe graphically, while Fig. 7 contains the detailed description of the transitions, p is a local variable of the lathe representing the piece which it contains. Predicates and actions associated to the transitions are the following (see Fig. 7): • Empty --* Full_working: a cart loading a piece arrives; it is unloaded and sent back. • Full_working --+ Full_finished: the time to work the piece is passed; a load/unload request is sent to t r a n s p o r t .

• F u l l _ f i n i s h e d --+ Empty: an empty cart arrives; it is loaded with the worked piece and sent back. •

Full_finished

-* Full_faulty, Full_working

--* F u l l _ f a u l t y : a breakdown occurs according to a stochastic law; an unload request is issued. • F u l l _ f a u l t y --* Empty_faulty: an empty cart arrives; it is loaded with the piece and sent back. • Empty_faulty --+ Empty: the lathe has been repaired; a load request is issued. The dispatcher is a function more than a process, so it can be implemented by only two states: • Wait_req in which it waits for requests from the

lathes • Dispatch in which it assigns a piece to a lathe In addition, the dispatcher needs the following data, that can be stored in local variables: the still unprocessed requests from the lathes, the tools mounted on the lathes, the states of the pieces, the lots to be produced and, for each of them, the number of pieces produced. It is worth to note that the number of lathes the dispatcher can control is at most N (N being the number of interaction points of type r e q u e s t defined for the d i s p a t c h e r module). The module t r a n s p o r t receives a request for a mission and computes the actual paths which a cart must follow (shop-missions) to execute it; every shop-mission is represented by an Estelle subtask which is created and connected to the proper interaction points. The state is defined by the number of idle carts contained and the running shop-missions.

M. Morisio, Ro Sisto / Use of Estelle to Specify Manufacturing Systems

BODY l a t h e _ b o d y f o r l a t h e _ t y p e v a r p: piece_type;

STATE Empty,Empty_faulty,Full_working, Full_finished,Full_faulty

TO Full_faulty DELAY x b e g i n output r.unload(p) end; Figure 7: body definition for module lathe_type

INITIALIZE TO Empty

257

~initial state}

begin p := nil {lathe initially empty}; end;

The module warehouse contains initially a number of raw pieces of different types. It gives them to the requesting carts and receives and stores semi-worked or finished pieces from the carts. The state is the number and type of pieces contained in it.

TRANS

FROM Empty TO Full_working WHEN t.full_car~ begin compute(x); p :ffi piece; output t.empty_cext(cart_name) end;

FROM Empty_faulty TO Empty DELAY repair_time begin output r.load; end;

FROM Full_working TO Full_finished DELAY work_time(p) begin

work(p);

output r.load_unload(p) end; TO Full_faulty DELAY x

begin

output r.unload(p)

end;

FROM Full_faulty TO Empty_faulty WHEN t.empty_cart begin end;

output t . f u l l _ c a x t ( c a r t _ n a m e , p )

FROM Full_finished TO Full_working WHEN t.full_cart begin output t.full_cart(cart_name,p); p:= piece end; TO Empty WHEN t.empty_cart

begin end;

output t.full_cart(cart_name,p)

5

Remarks

The Estelle organization of tasks matches very well the hierarchical architecture by which manufacturing systems are so advantageously described. In fact the priority of a parent task over any of its children tasks puts the former in a master-slave relationship with the latter. Therefore, it is obvious that, when specifying an MS in Estelle, the same levels of aggregation by which the MS is defined be reproduced in the organization of tasks. However, Estelle constraints the user to have asynchronously running modules only at the top hierarchical level, since synchronization among sub-tasks is implicit inside of each system task. This can be considered as a limitation if multiple levels of nested asynchronous components must be described, as it is the case with manufacturing systems. Finite state machines are a very clear way to model entities which can be found at the lower levels of MSs, (such as the lathe of the example) since the states have physical meaning and contain the essence of the entity. On the other hand entities charged of decision taking (such as the dispatcher and the transport module of the example), of data handling (such as databases), of coordination (such as the higher levels of MSs) are mainly described by algorithms (embedded in Pascal code ) and by the structure and handling of local variables. As regards communication among processes, it should be noted that only non-blocking messages are provided: blocking messages can be obtained as well by letting the sender wait for an answer, but the cost is one more state to be added and one more message to be defined. Other drawbacks are the absence of broadcast channels and the strict FIFO structure of the input queues. The first item makes it difficult to represent open modular structures based on broadcast communication, and requires that the maximum number of tasks that can be connected to another common task be fixed (in the example discussed above, the number of lathes controlled by the dispatcher and accessed by the transport facility can not exceed a predetermined number). The second item makes it necessary to split a communication link into more links with separate queues if there are par-

258

M. Mofisio, R. Sisto / Use of Estelle to Specify Manufacturing Systems

titular classes of messages that must be read in immediately. In our example, the dispatcher process could be made more efficient if it had the possibility to access immediately the whole set of input requests from the lathes, instead of reading them in the arrival order. Anyhow these drawbacks are not overwhelming compared with the pros, among which it should be added that Estelle is a standard language: this is a great advantage when different organizations need to communicate (e.g. contracting the building of MSs, partitioning the design of the MS among different teams, documenting the MS).

6

Conclusions

Estelle has been shown to satisfy the main requirements needed for the specification of manufacturing systems, since it is formal, provides concurrency constructs and supports hierarchical structuring. A case study has helped in demonstrating how the specification of an MS can be organized in Estelle. The use of Este]le to specify MSs is advantageous mainly because Estelle is executable, enables the user to define explicitly the states of the system and is standard. The main drawbacks encountered are the inability to define more levels of nested asynchronous tasks, the non-blocking characteristic of messages, the absence of broadcast channels and the strict F I F O structure of the input queues.

References [1] P. G. Ranky. Computer Integrated Manufacturing. Prentice Hall, Englewood Cliffs N J, 1986. [2] J. Harrington Jr. Understanding the Manufacturing Process. Marcel Dekker Inc., New York, 1984. [3] H. Van Dyke Parunak and J.F. White. A synthesis of factory reference models. In IEEE 1987 Conference on Languages for automation, pages 109-112, 1987. [4] R. Conterno, G. Menga, and A. Villa. Hierarchical and decentralized control for batch and repetitive manufacturing. In IEEE 1987 Int. Conf. on Robotics and Automation, pages 1855-1860, 1987. [5] C. McLean, M. Mitchell, and E. Barkmeyer. A computer architecture for smaU-batch manufacturing. IEEE Spectrum, 20(5):59-64, 1983. [6] IS 9074 Estelle: a Formal Description technique based onEztended State Transition Model. 1989. [7] S. Budkowski and P. Dembinski. An introduction to Estelle: a specification language for distributed systems. Computer Networks and ISDN systems, March 1987. [8] S. Vuong, A. Lau, and R. Chan. Semi-automatic implementation of protocols using an Estelle-C compiler. IEEE Trans. on Software Engineering, SE-14:384-393, March 1988.