Towards a Manufacturing System Specification Language

e

Copyright IFAC Intelligent Manufacturing Systems, Vienna, Austria, 1994

TOWARDS A MANUFACTURING SYSTEM SPECIFICATION LANGUAGE F. VERNADAT INRIA Rhime-Alpes. 46. avelUle Fllix Viallet. F-3803J Grenoble. France

Abstract: A specification language called MSS based on the process model of CIMOSA is introduced for modelling and specification of manufacturing business processes. The language provides declarative aspects. procedural aspects and exception handling aspects. Declarative aspects concern the structural description of manufacturing system entities (functions. resources and object views) as basic constructs. Procedural aspects concern process behaviour (i.e. control flow) and activity behaviour (i.e. functionality). They allow for sequential. conditional. iterative and parallel control structures. Exception handling aspects concern procedures to be activated in the case of exceptional situations to face real-world non-determinism and system failures. Key-words: Manufacturing system specification; enterprise modelling; process models; formal description language; ClMOSA

CIMOSA (AMICE, 1993) has been proposed as a European framework to conciliate these various viewpoints from four angles, namely, function, information, resource and organisation views, on the basis of a process model defined in terms of generic building blocks or constructs (Vemadat, 1993). Manufacturing systems are assumed to be made of a set of concurrent, cooperative business processes (be they management, operational or support processes) performed by the functional entities of the enterprise (i.e. computational, operative or human agents). A business process is a partially ordered set of activities distributed in time and space, which can be completed in days, weeks or even months, which can be interrupted and resumed. and which processes enterprise objects (information or physical entities).

1. INTRODUCTION Manufacturing system modelling and specification is an area which has been the focus of considerable attention in order to build efficient and reliable production systems. Different modelling approaches are used for different analysis purposes. They range from graphical languages for overalI system description (such as SADT and IDEF notations) suffering from weak syntax and semantics (Albright, 1991; Busby and WiIIiams, 1993), to detailed object-oriented models used to capture more of the semantics of the application and allowing sophisticated simulations (Mujtaba. 1994) but lacking of analysis properties (Nof, 1994). and to pure mathematical models (either deterministic or stochastic models) such as queueing networks and Petri nets for qualitative and quantitative system property analyses (Buzacott and Shanthikumar, 1993; Kusiak, 1990; Liu and Wu, but mostly limited to functional aspects and to some extent to resource and information aspects when high-level Petri nets are used (DiCesare et al., 1993). Currently, there is a trend to use formal techniques. and especially formal description languages, to model and specify manufacturing systems (BenArieh, 1992; Biemans and BIonk. 1986; Pathak and Krogh, 1989) and their processes (Bussler, 1993; Goossenaerts, 1993; Vernadat, 1993).

In this paper, we present the principles of a specification language named MSS for manufacturing system specification language. The language is based on the process model of CIMOSA and is defined in terms of object classes describing the underlying concepts of process. activity. event, resource. object and object view in addition to the concept of functional operations provided by functional entities. The language includes declarative aspects, procedural aspects and exception handling aspects. Declarative aspects concern the structural description of manufacturing system entities (functions, resources and object views),

121

where each entity is defined by its object class and the set of attributes of the object class. Procedural aspects concern process behaviour (i.e. control flow) and activity behaviour (i.e. functionality). They allow for sequential, conditional, iterative and parallel control structures. Exception handling aspects concern procedures to be activated in the case of abnormal situations. These situations can be detecte d either when logical conditi ons (or predicates) defined in the model are met (determinist case), or by demons such as timeouts or watch-dogs (non-determinist case). A time duration can be defined for each activity. The underlying theoretical model is a timed non-deterministic state-transition machine, the execution of which is controlled by an event-condition-action (ECA) paradigm. The aim of the MSS language is to provide an execut able formal specifi cation of models of realisti c manufa cturing system s. It mediat es betwee n require ments definit ion and actual implementation description and should serve as a basis for system specification and analysis (both for qualitative and quantitative properties) as well as for model analysis (i.e. providing a basis to verify model proper ties such as well-fo rmedne ss, completeness and consistency). This requirs the use of specialised analysis tools for syntax and semantic verific ations or timed Petri net tools for performance evaluation. The MSS language has an EXPRESS flavour (ISO, 1991) for declarative aspects and an ADA flavour (Olsen and Whitehill, 1988) for procedural and exception handling aspects. Originalities are twofold and result from the CIMOSA basic principles. First, the language covers the control flow, the information flow, the material flow and resource management aspects in one unified, non redundant, model. Second, the language differentiates between processes and activities as two semantically different concepts enforcing the principle of separation of control and functionality. This last aspect is very important for business process re-engineering, lean manuf acturin g system design and model maintenance since control can be easily modified withou t impacting functionality and vice-versa. This aspect is also very important for developing libraries of formally defined partial models and ontologies of manufacturing activities and processes for standar disatio n work, as foreseen in the CIMOSA Reference Architecture (AMICE, 1993) and discuss ed by Grunin ger and Fox (1994). Finally, the language could be used as a neutral format for model exchange between enterprise modelling tools.

objectives under some business constraints. Each domain contains a finite set of fully defined domain proces ses and has relationships with at least one other domain (which can be the system environment). Domains are also characterised by the events that they receive or generate and by object views manipUlated by their domain processes. Events are solicited or unsolicited happenings of the enterprise which trigger some action. For instance, an order arrival or a management request are solicited happenings, while machine breakdowns and fire alarms are unsolicited happenings. Actions triggered by events are organised into activities, and activities are chained into proces ses. Complete processes are called domain processes (they must be triggered by nothing else than events) while subprocesses are called business processes (business processes can be re-used in the model while domain processes must be unique). Processes represent the enterprise behaviour, i.e. they define the way activities are executed acording to the system state evolution. Activities represent the enterprise functionality, i.e. the things being done. Therefore, activities are mostly defined by their inputs and outputs , i.e. the objects used, transformed or produced, the resources they use, i.e. the agent used for processing and by their function, i.e. the way they transform inputs into outputs. This functionality is defined by means of a proced ural languag e which describ es the way functio nal operat ions are used by activities. Functional operations are atoms of functionality provided by active resources of the system and called functional entities. Each activity is characterised by its finite set of possible ending statuses. An ending status is a value (O-argument predicate) indicating the termination status of the activity. Combinations of ending statuses of activities of a system describe the possibl e states of the system. The system history can therefore be described by the trace of the processes, i.e. the sequence of activities executed along with their ending statuses over the time. This is differe nt from the trace left by objects manipulated which may be different over the time for different runs of the same process trace. Exception handling mechanisms can be specified for processes and activities if needed. They allow for the detection of exceptional situtations at run-time and to face real-world system non-determinism. For instance, if an infinite loop or a deadlock happens at run-time, this can be detected and decision to stop the process or activity (forcing its ending status) can be made. Demon s and watch- dogs can be programmed to checked for specific situations request ing specifi c correct ive actions or the gcnera tion of events to trigger mainte nance processes.

2. BASIC PRINCIPLES OF THE LANGUAGE In the MSS language, a manufacturing system is divided into a finite set of non-overlapping domains. A domain represents an area of functionality or subset of the enterpr ise fulfillin g busines s

Finally, functional entItIes can be allocated to activities (the usual way) or directly to processes. When a specific functional entity is indicated for a

122

Handling : ] Ending Statuses : ::= I , ::= I , ::= : and are defined in subsequent sections

given process or activity type, this is called early binding. If the choice of the resource is left to execution time, this is called late binding. Both modes are possible with the MSS language. 3. DECLARATIVE ASPECTS Prelimjmpy Comments: The syntax of the language is given in BNF notation, where [.) indicates an optional category, I is the alternative symbol and reserved words are in bold characters. "NIL" indicates an empty category.

Property PI: A domain process is a process whose "Triggered by" clause contains at least one event identifier; otherwise, it is a business process. Property P2: The possible ending statuses of a process are always functions of possible ending statuses of elements (business processes or activities) used in their process behaviour.

, , , , , <~V-identifier> and are identifiers of domains, processes, activities, events, objects, object views and resources, respectively. and are lists of business objectives and constraints defined as pure text, respectively. represents a varying length character string. Most constructs have an optional clause defined as: Description : .

Activities: Activities transform inputs into outputs using functional operations of installed functional entities. CIMOSA defines three types of inputs and outputs, namely function, control and resource inputs and outputs defined as object views except the control output and resource input. The function input defines the types of objects to be processed, the function output defines the types of objects processed or produced, the control input defines the types of objects used but not processed (constraints), the control output defines the types of events which can possibly be generated by the activity in the course of its execution, resource input defines the set of objects to be used as resources to execute the activity and resource output provides information about the status of resources after the execution of the activity, if this can be made available.

Domains: Domains are used to organise the model into manageable pieces, encapsulating all domain processes contributing to the same business objectives. ::= Domain [] Domain Processes : ::= I ,

Property D 1: Two domains D 1 and D2 are said to be non-overlapping if and only if there does not exist a domain process DP which belongs both to Dl and to D2.

::= Activity [constraints] Activity Behaviour {} [Exception Handling : ] End In g Statuses ::= Function Input : Control Input : Resource Input : ::= Function Output : Control Output : Resource Output : ::= <~V -identifier> I , I NIL ::= <~V -identifier> I <~V -identifier> , I NIL ::= <~V -identifier> I <~V -identifier> , I NIL ::= I , I NIL ::= I , ::= <~V -identifier> I , I NIL ::= [ ] [ ] ::= Average Duration : ::= Minimum Duration : ::= Maximum Duration:

Property D2: For each domain D, there exists at least one domain process DP such that DP E D «process-list> is not empty). Property D3: All in must be identifiers of domain processes only. Processes: A process is a partially ordered set of activities. The same construct is used to define domain processes, i.e. full processes triggered by one or more events and producing a full chain of processing, and sub-processes or business processes, i.e. a pieces of enterprise behaviour called by parent processes. When a resource input is defined for a process, this means that the resource(s) indicated is (are) used for the full duration of the process occurrence (and therefore by the activities employed requiring a resource of this type). ::= Process [constraints] [Triggered by : Resource Input : Behaviour: { }

] [ ] Process [Exception

is a positive integer value (representing time units)

123

and are defined in subsequent sections while is defined in the same way than for processes.

Property 02: The intersection of elements of <0identifiers> in the lsa clause and in the Part-of clause is empty.

Property AI: The union of elements of . and is not empty.

Object Vie w s; They represent physical manifestations of enterprise objects. They can be of two types: "information" for object embodiements made of data and "physical" for the physical object embodiement. This distinction is necessary in situations where a physical object and data about it are both used by the same activity (for instance. when a part is mounted on a machine). Information object views act like filters on object properties. extracting values from properties of one or more objects. The leading object is the object on which the object view is defined. Related objects are objects from which properties are used in the object view.

Property A2: The intersection of elements of and is empty. Property A3: The intersection of elements of and is not necessarily empty. Property A4: For each activity. there is at least one ending status. Events: Events are used to model real-world facts. occurrences of which trigger the execution of some domain process(es). An event can be used to trigger one or more domain processes. Conversely. a domain process can be triggered by means of several events. An event always happens at a given instant in time. and may carry information. To model events. we use flfst order logic predicates.