- Email: [email protected]
Verification and validation of a SSM model dedicated to mode handling of flexible manufacturing systems
Computers in Industry 60 (2009) 77–85
Contents lists available at ScienceDirect
Computers in Industry journal homepage: www.elsevier.com/locate/compind
Verification and validation of a SSM model dedicated to mode handling of flexible manufacturing systems Nadia Hamani a,*, Nathalie Dangoumau b, Etienne Craye b a b
Laboratoire Universitaire de Recherche en Production Automatise´e (LURPA), 61 avenue du Pre´sident Wilson, 94235 Cachan Cedex, France Laboratoire d’Automatique, Ge´nie Informatique et Signal (LAGIS), CNRS UMR 8146, Ecole Centrale de Lille BP 48, 59651 Villeneuve d’Ascq cedex, France
A R T I C L E I N F O
A B S T R A C T
Article history: Received 27 August 2006 Received in revised form 25 March 2008 Accepted 2 April 2008 Available online 6 December 2008
This paper focuses on verification and validation of a model dedicated to mode handling of flexible manufacturing systems (FMSs). This model is specified using the synchronous formalism safe state machines (SSMs). The rigorous semantics that characterize such formalism enable to provide formal verification mechanisms ensuring determinism and dependability. A structured framework for verification and validation of the model dedicated to mode handling is proposed. The main properties being verified within this framework and the corresponding verification methods are presented. The approach is illustrated using an example of a manufacturing production cell. The formal analysis tools integrated into the development environment Esterel Studio are used within the design process. ß 2008 Elsevier B.V. All rights reserved.
Keywords: Flexible manufacturing systems Control system Supervision Mode handling Functional and behavioral modeling Safe state machines Verification Validation
1. Introduction This work deals with the problems of supervision in fault tolerant control systems of flexible manufacturing systems (FMSs). In view of a disturbance, the supervision takes necessary decisions to return to normal or accepted operation. According to the design approach [1,2], the supervision is made up of three functions: decision, piloting, and mode handling. The role of mode handling function is to carry out the decisions about mode and configuration changing. In order to achieve this role, a model representing the operating modes of the whole system and its subsystems should be provided. To this aim, it is important to use an adequate modeling method and powerful specification formalisms. The modeling method should be well adapted to the production system characteristics. In addition, the specification formalism should support hierarchy and represent several forms of preemption. It should also be sufficiently formal to allow carrying out formal verification.
* Corresponding author. Tel.: +33 1 47 40 29 97; fax: +33 1 47 40 22 20. E-mail addresses: [email protected], [email protected] (N. Hamani), [email protected] (N. Dangoumau), [email protected] (E. Craye). 0166-3615/$ – see front matter ß 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2008.04.002
The modeling methods and the specification formalisms, which characterize the existing approaches, are compared in Ref. [3]. The main conclusions of this comparative study show that the mutual benefit of a functional modeling approach [4] and a powerful specification using the graphical synchronous language safe state machines (SSMs) [5,6] is very convenient for mode handling. A new modeling method for mode handling was presented in previous works [7,8]. It is based on a functional approach and on a synchronous reactive approach using SSM. The mode handler is using the FMS model; the aim is to handle concurrently the information flows downwards to transmit high-level control and reconfiguration orders and upwards to follow up the reports and the failures detected by the monitoring function. The reactivity needed for this bi-directional exchange of information in addition with the characteristics of concurrency and preemption, require a synchronous approach. Due to increasing complexity and flexibility of FMS, some problems appear during mode and configuration changing if coherence and safety constraints are not taken into account in the specification/modeling stages. So it is necessary to verify and validate the proposed models at the early stages of the design process. Running simulation is not exhaustive; a greater interest has been allocated for few years to formal verification methods,
78
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
which guarantee that for all possible evolutions of a model, several properties are satisfied. Thus, the purpose of this paper is to extend the modeling method by carrying out verification and validation (V&V) on the obtained model dedicated to mode handling. The paper is organized as follows. Section 1 focus on the context of this work. The main characteristics of the modeling method are reminded in Section 2: functional and behavioral specifications of the system and its subsystems. Section 3 introduces a structured framework for carrying out V&V on mode handling model. Basic concepts of V&V are presented then the stages of the design process including V&V are detailed. Section 4 presents mandatory and some optional properties being checked within this process. The specification and V&V process are illustrated through an example of a flexible manufacturing cell. 2. A modeling approach for mode handling As mentioned above, the modeling method is based on a functional decomposition and on a synchronous reactive approach using SSM. Functional approaches [9–11] are well suited for efficient reconfiguration procedures instead of structural approaches [12–14]. Besides, the required characteristics of hierarchy, parallelism, and preemption are well represented using synchronous languages compared with common models such as sequential functional charts (SFC) and Petri Nets (PN). The interests of using synchronous formalisms rely also on their strong semantics. They are compiled efficiently and it is possible, using formal techniques, to prove that the behavior of the system respects some properties. In the following subsection, the method leading to the functional subsystems is presented. Then the behavior of the obtained subsystems and the logical relations between them are specified using the synchronous formalism SSM. A modular approach is used for representing the resulting model. The design process is illustrated in Section 3.2. 2.1. The FMS subsystems A FMS produces simultaneously a subset of parts. Each part is characterized by an operating sequence (OS) [8]. The FMS usually changes its production goals. That is why the mission concept was introduced. It corresponds to a set of operating sequences that the system should carry out simultaneously. The specification method of FMS subsystems was described in Ref. [8]. The idea is to decompose and determine the functional subsystems, which take part in the realization of its missions. The FMS functional model is obtained by a hierarchical decomposition leading to the elementary machining and transfer operations. This functional specification is completed by associating resources with the elementary operations they perform. The obtained subsystems are organized in six layers as shown in Fig. 1. The functional representation is a graph composed of functional subsystems (called entities) linked by logical relationships (AND, OR and XOR). According to the constraints given in the functional requirements, the exclusive logical relation (XOR) is necessary for safety reasons, like two machining operations which are performed by the same resource for instance.
Fig. 1. The FMS functional model and information flows.
benefits of more strict semantics fully compatible with that of Esterel synchronous language [16]. SSM supports also, with a very rigorous semantics, hierarchy, communication, concurrency, and various forms of preemption, which characterize the proposed modeling approach. In addition, SSM take advantage of an industrial development environment [17], which provides necessary tools to the development stages of systems from specification to implementation. The presentation of the syntax of SSM is beyond the scope of this paper (see [5,6]). Behavioral specifications are summarized in the following. 2.2.1. Specification of the behavior of FMS subsystems Once the mission and the operating parameters are selected by the operator, the entities of the FMS functional model (Fig. 1) which take part in the selected mission can be activated if they are available. For behavioral specification, it is necessary to represent the activation/deactivation mechanisms at all the hierarchy levels as well as the availability of the subsystems. Fig. 2 summarizes the states of an entity. The activation/deactivation of an entity is represented by the working mode. The functioning mode represents the availability/ unavailability of an entity. The behavior of each entity of the model, whatever its level, is represented by a SSM including these two modes (Fig. 3). This model allows knowing, at any time, if an entity belonging to the current mode of the FMS is in normal state e_N, degraded state e_D or out of order state e_OUT according to the functioning mode point of view; and if it is activated e_Active or inactive (in stopping state) e_OFF according to the working mode point of view. The initial states are the stopping state e_OFF for the working mode and the normal state e_N for the functioning mode. The activation of an entity e using start_e can be made only if the entity is available (i.e. it should not enter the out of order state). This is represented using ‘start e and not e_OUT’. As soon as the entity is active, it enters the working state e_ON if the conditions of its activation are appropriate. Such conditions depend on the logical relation between the entities. The stopping state is effectively reached when the entity ends its activity. Indeed, when the entity reaches the final state (see the state End distinguished by its double outline), the macro-state e_Active is exited through the normal termination (whose tail is a small triangle). According to the previous specification, the input and the output signals represented in Fig. 3 are the following: for working
2.2. Behavior specification The graphical synchronous formalism SSM [5] (or SyncCharts (Synchronous Charts) [6]) is used to specify the behavior of the entities of the functional model. SSM inherits many features from Statecharts [15] but offers several forms of preemption and
Fig. 2. The states of an entity.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
79
They are a representation in SSM which is similar to procedures (or functions) used in programming languages. Reference models are instantiated for each entity. An iterative approach of specification is proposed in order to improve this process. At first the models of level i are specified, then the SSM of level i is encapsulated in the SSM of level i + 1 until completing the specification of the model (Fig. 4). The hierarchy is represented by the encapsulation of successive levels whereas the entities belonging to the same level are separated by dashed lines; these are used to represent concurrency in SSM syntax. 2.3. Using the behavioral model for reactive mode handling
Fig. 3. The SSM representing the modes and states of an entity.
mode, the input signals start_e and stop_e correspond, respectively to the activation/deactivation orders. They lead entering the states e_ON and e_OFF, respectively. For functioning mode, the input signals e_n, e_d and e_out provoke, respectively entering the normal state e_N, degraded state e_D, and out of order state e_OUT. Local signals are also needed for specification. They are signals which are neither controllable nor directly observable. 2.2.2. Specification of the logical relations Let us define a relation between a parent entity of level i and a set of child entities of level i 1. The child entities are related either using a logical AND or a logical OR. For working mode, the activation/deactivation request is a downward information flow from a parent entity to its child entities. The reports of such requests are propagated upwards. For functioning mode, failure events involve the change-of-state of FMS resources, i.e. the entities at the lower level of the model. This information flow is propagated upwards from the child entities towards their parent entity. The change-of-state of the entities of the model belonging to successive levels is carried out according to precise rules which depend on the kind of the logical relation and the number of child entities. Several cases are studied in Ref. [7]. 2.2.3. Modular representation using reference models The specification of any entity of the model differs according to whether it has one or more child entities or it has no child entity (the leaves of the graph). It depends also on the logical relation between the child entities. Thus, reference models are defined.
Fig. 4. The representation of the model.
As shown in Fig. 1, the behavioral model should handle the information flows downwards to transmit the orders from Human Machine Interface and upwards to propagate the information provided by the monitoring function. The downward flow of highlevel control and reconfiguration orders is propagated through the operations sequences corresponding to the selected mission. The flow is then propagated through the operations and the resources which take part in the realization of the selected mission. As for the downward flow, the upward flow transmits the results obtained by the execution of high-level control and reconfiguration orders and process the information about the availability of the resources and the operations. The mode handler is a reactive system [18] which continuously reacts to stimuli (inputs) of the environment by sending back other stimuli (outputs). Consider the reactions of a SSM associated with an entity of the model. Each entity e at level i may receive either a request from level i + 1 indicating a mission or a working mode change or a mode changing of one or more child entities of level i 1. Within the specification stage, it is necessary to respect some rules for a coherent integration within the control system framework. These rules are detailed in Ref. [7]. In the next section, a framework for carrying out V&V of the obtained model is presented. 3. A framework for carrying V&V 3.1. V&V within a design process A design process should involve many intermediary stages of V&V. The aim is to eliminate as soon as possible the specifications errors. Indeed, V&V characterize any correct development process. According to Ref. [19] verification is the proof that the internal semantics of a model is correct independently of the modeled system whereas validation determines if the model corresponds to the attempts of the designer given in the functional requirements. The required properties are either generic, they depend on the used formalism, or specific to the modeled system. V&V consists of analyzing the properties that should be satisfied by the final model. Two complementary methods are used; simulation and formal verification. This work deals only with formal methods for V&V. Three steps are needed: building the model representing the behavior of the system, formalizing the properties, and the analysis of the formal model. The searched properties as well as the methods used for their verification depend on the formalism. The rigorous semantics of synchronous languages, SSM included; enable to provide formal verification mechanisms ensuring determinism and dependability. Within a design process, V&V of mode handling model specified using SSM is shown in Fig. 5.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
80
Fig. 6. Illustration example. Fig. 5. V&V within the design process.
The formal specification as well as the structured modeling process presented in the previous section, ensures a correct development and no errors propagation. V&V of the obtained model is an iterative stage which requires reconsidering the specification/modeling stage as needed. Based on the verified and validated model the implementation is ensured through automatic code generation. 3.2. The specification/modeling stage The functional requirements provide informal specifications about the intended behavior of the FMS and the properties that should be respected. The designer provides formal specifications of the model and the required properties. The formal model representing the behavior of the system: the specifications of the model dedicated to FMS mode handling are presented in the previous section. The cell of Fig. 6 is an illustration example. It consists of two machines M1, M2 and input/output buffers (I/O). The transport system is composed of two robots R1 and R2. M1 is loaded by R1 and M2 is loaded by R2, this latter will be used to load the two machines
when R1 is failing. The performed machining functions are turning (t) and milling (f). Turning (t) is carried out by M1, milling (f) by M1 or M2. The cell has three missions, M 1 , M2 and M3 . The corresponding operating sequences are, respectively OS1 (t), OS2 (f) and then OS1 and OS2 simultaneously. The obtained model is presented in Fig. 7. A reduced size cell enables to illustrate the proposed approach without facing the problem of increasing number of states. The model of this cell is specified using four reference models and 29 instances for 809 lines of Esterel code generated from SSM models. This model needs 34 input signals and 145 output signals. At first some scenarios are simulated in order to eliminate the specification errors so that the intended behavior respects the functional requirements. The interactive simulator XEtented Simulator (XES) [17] is used. The model must handle correctly the activation/deactivation of the missions and the corresponding entities. The propagation of the failures is also tested. The tests carried out for all the configurations of the cell allow to validate in an informal way the intended behavior. This example is also used below to illustrate the study of the properties in V&V stage. The formal specification of the properties that should be satisfied: in this paper, only the properties of logical behavior such as determinism and safety properties are considered. As a
Fig. 7. The model of mode handling.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
reactive synchronous approach [20] based on SSM formalism is used, generic properties of reactivity and determinism should be checked. Several specific properties to mode handling function should also be checked. Such properties are about the coherence of the modes and the missions of the FMS. The main properties are introduced and detailed in Section 4. The SSM tool editor integrated into Esterel Studio environment is used for the specification of the model. Specific properties are represented either by observers specified in SSM or using Esterel language. 3.3. The V&V stage In the verification stage (see Fig. 8), one checks if the model respects the generic properties. SSM specifications are automatically translated into Esterel program which is compiled in a system of Boolean equations (logical circuits) an implicit form of finite state machines (FSM). The properties of logical correctness of Esterel programs can then be checked on this system. The analysis technique used to this aim is the constructive causality analysis carried out by Esterel compiler v5_x. Causality analysis is a semantic analysis which allows accepting or rejecting Esterel programs according to whether they are constructive or not [21]. The processor which implements the algorithms of constructive analysis builds the reachable state space using symbolic techniques based on binary decision diagrams (BDD). In the validation stage, one checks if the model respects the specific properties formalized in the specification stage. The
81
analysis techniques used are model-checking and/or theorem proving. Several model-checking tools were developed for Esterel language. For instance Built-in verifier tool an evolution of XEsterel VErifier (XEVE) [22] is currently integrated into Esterel Studio. XEVE takes as input the system of Boolean equations and built the reachable state space using BDD (symbolic model-checking [23]). XEVE tests the statutes of output signals by analysis of the reachable states. Thus, safety properties of simple type stating that ‘a dangerous state will never be reachable’ can be checked. XEVE tests also the statutes of output signals of the observers [24,25] representing safety properties of combinatorial type, sequential type or of bounded time. Liveness properties can also be checked using XEVE but they are not considered in this study. The modular and hierarchical specification shown in Fig. 4 is completed by introducing an iterative method of V&V (see [26]). The aim is to reduce the specification/modeling errors and enable an early correction by introducing intermediate stages of V&V into the multi-level specification stage. Failing of the verification stage implies that there is a specification or a modeling error. It is then necessary to go back over the model, as needed until completing the verification of all the properties. Also failing of the verification of a property carried out by the model-checker needs to revise the specification/ modeling stage. Within the formal specification of the model and its properties, some errors may be caused by no perfect experience with the formalism for instance. The errors in the formal specifications are related to the following reasons [7]: The specification of the model is incorrect. The specification of the property is incorrect. The correspondence between the model and the property is incorrect: the error may be in the correspondence between signals appearing in the property and those of the model. The assumptions related to the environment: the model does not respect the property in the general case but only under some assertions or constraints [17] of the environment. If the specification/modeling stages are considered to be correct, the validation failing is due to an earlier stage, which leads to reconsider informal requirements. Indeed the errors in the formal specification of the model or its properties are caused by the ambiguity or the incompleteness of the informal requirements. In this case, they should be improved and reconsidered again. In addition, in the validation stage, if the model is modified a verification step is necessary before a new validation. Indeed, generic properties of a modified model must be checked again to allow its validation. Once the model is verified and validated, the implementation is ensured through automatic code generation. Here, also one of the advantages of synchronous languages is to ensure the preservation of the properties between the specification and implementation stages (What You Prove Is What You Execute, WYPIWYE [27]). Fig. 8 shows also the intended use of the generated code. In the following, a detailed study of the properties being checked in V&V stage is presented. 4. Properties study
Fig. 8. V&V within the design process.
At first generic properties that depend on the synchronous formalism SSM are introduced. Then some specific properties being checked in the validation stage are proposed. These properties ensure mode coherence. For each property the corresponding expression, the verification method and an illustration example are given. The last paragraph is dedicated to some specific properties that could also be checked.
82
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
4.1. Generic properties Semantic analysis is carried out on the system of Boolean equations resulting from Esterel program compilation. Semantic analysis also called causality analysis allows checking generic properties (deadlock freeness, reactivity, determinism). These are presented in the following. 4.1.1. Semantic analysis of Esterel programs The analyzed Esterel programs correspond to the semantic model of FSM. Indeed, the compilation of a synchronous program generates a state machine in the form of a finite state automata or a system of equations (circuit). The difference between a finite state automata and a system of equations is that the first represents the reachable state space in an explicit way whereas the second represents it in an implicit way. The translation of Esterel programs in logical circuits is rigorously formalized in Ref. [21]. In addition, the preservation of constructivity (i.e. constructive causality) of a program when it is translated into a circuit is proved. Thus, any constructive circuit implies that the corresponding program is also constructive. This formal relation is very important because causality analysis is rather carried out on Esterel circuits. In addition, if a circuit or the corresponding program is correct from the constructive point of view then it is correct from the logical point of view, this means that there is a solution and this one is unique. The existence of a solution corresponds to the reactivity of the program and the uniqueness of the solution corresponds to the determinism. These two properties are very important in the context of reactive systems. The causality of Esterel programs is a stronger requirement compared with reactivity and determinism. Indeed, any causal program (or circuit) is reactive and deterministic, however the reverse is not true [21]. Generic properties are presented in the following. 4.1.2. Deadlock freeness Causality analysis proves that a program is causal according to the constructive causality defined by Berry [21]. Constructive causality of Esterel programs ensures deadlock freeness, which characterizes synchronous languages. Deadlocks are due to the synchronism assumption (see causality problems in Ref. [28]). Property 1 (Deadlock freeness (mandatory)). The specification model should be deadlock free. Verification: constructivity analysis of Esterel programs is carried out with Esterel compiler v5_x. If an Esterel program is constructive then it is reactive and deterministic. A program is said to be reactive if it provides a welldefined solution for each input. It is deterministic if this solution is unique [21].
properties are presented, two properties are of simple type (reachability and mission uniqueness) and the third one is of combinatorial type (incompatible modes). 4.2.1. States reachability According to the specifications, an output signal is associated with each control state of the model. To check the reachability, the statutes of output signals that correspond to control states are tested. Property 3 (Reachability of the modes (optional)). All the states within a mode must be reachable. When building the reachable state space of the model, if there is at least a reachable state in which an output signal (for example e_ON the working state of the entity e) is present then the corresponding state (i.e. e_ON) is reachable. Verification: the statutes of output signals of the model are tested using XEVE tool. Example. One tests if the output signal is possibly emitted. The answer is possibly emitted if there is a reachable state from which the signal is emitted. The control state is then reachable. If the answer is never emitted the state is then unreachable. As shown on Fig. 9, the reachability of the states of the model of Fig. 7 is checked by testing the statutes of the corresponding output signals. For each signal, XEVE tool has found a sequence of inputs that leads to the emission of this signal. XEVE answers by possibly emitted, the property is then verified. The sequence of inputs (on the right of Fig. 9) can be visualized using XES simulator. 4.2.2. The mission uniqueness This property ensures operation safety of the FMS according to the selected mission. Indeed, selecting a mission implies performing some operations and activating the resources, which take part in this mission. Thus, the operations and the resources, which do not take part in the current mission, should not be activated for safety and coherence reasons. The property is guaranteed by construction of the model. According to the concept of current mode uniqueness recommended by the GEMMA [29], a property ensuring the mission uniqueness of a FMS is introduced. Property 4 (The mission uniqueness (mandatory)). Each entity e of the model, which does not take part in the current mission M, cannot be in working state. The signal e_ON is never emitted if the FMS mission M is activated and the entity e does not take part in this mission.
Property 2 (Reactivity and determinism (mandatory)). The specification model should be reactive and deterministic. Verification: constructivity analysis of Esterel programs (Property 1) involves consequently Property 2. Example. Causality analysis is realized successfully on the model of the illustration example. The compiler accepts the Esterel program generated from the SSM model. It is thus causal (Property 1) and verify necessarily reactivity and determinism properties (Property 2). 4.2. Specific properties The aim here is to ensure coherence and safety constraints of mode handling specifications. In this section three kinds of safety
Fig. 9. Reachability of the states of the model.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
83
Fig. 11. The observer specifying mutual exclusion.
Fig. 10. Example of verification of Property 4.
Verification: the statutes of the output signals of the model are tested modulo a restriction on a set of input signals. Example. In the example of Fig. 6, the mission M1 of the cell is using only the machine M1. If this mission is activated M2 cannot be in working state. The input signals, which allow choosing and activating a mission and selecting the configurations of the redundant entities, are declared as always present. Then the signal M2_ON is tested if it is possibly emitted? The response of XEVE should be: the signal M2_ON is never emitted to conclude that the property is satisfied. If the answer is: the signal M2_ON is possibly emitted then the property is not satisfied and the specification must be revised. Fig. 10 shows that the machine M2 cannot be in working state for a configuration of the cell corresponding to the mission M1 . The answer given by XEVE is never emitted, i.e. the property is verified. 4.2.3. Incompatible modes In order to ensure mode coherence, the proposed specifications in Section 2 guarantee mutual exclusion of incompatible states of the entities of the model (each state is belonging to a distinct mode). It is about mutual exclusion of working states of the entities related with the logical relation XOR (for example redundant resources). One checks if mutual exclusion properties are satisfied. Property 5 (Incompatibility of the modes (mandatory)). Independently of the selected mission, incompatible working modes are never reached simultaneously.
R1_ON and R2_ON is checked in the following way: independently of the selected mission, the question is if the output signal Violated is possibly emitted? The response should be: the signal Violated is never emitted so that the property is satisfied. If the answer is: the signal Violated is possibly emitted then the property is not satisfied and the specification must be revised. The mutual exclusion property of R1_ON and R2_ON is verified because XEVE answers by never emitted (Fig. 12). 4.2.4. Other properties 1. In addition to the previous properties, other properties of the model can be checked. According to [7,19] the properties deal with mode changing conditions and respecting mode sequence: The conditions of mode changing correspond to safety properties of simple type. For example, an entity e of the model cannot reach a well-defined state, for example the state e_OUT, only if the condition e_out is present. For checking this property, the status of the output signal corresponding to the state e_OUT is tested with a restriction on the input signal representing the evoked condition. Thus, if the condition is always absent, the output signal is never emitted. The respect of mode sequence corresponds to safety properties of sequential type which states that a sequence of actions must occur (or will never occur in the case of a dangerous sequence). The property is specified using an observer, which represents the sequences of events that lead to the error. The status of the output signal of this observer is tested. 2. V&V within the control system: according to the design approach of FMS control system, low level control, monitoring and
For any couple of entities e1 and e2 with incompatible working modes, there is not a reachable state of the model in which the signal ‘e1_ON and e2_ON’ is present. It means that the signals e1_ON and e2_ON are never emitted simultaneously (mutual exclusion). Verification: the status of the output signal of an observer is tested modulo a restriction on a set of input signals. An observer is a model specified in SSM and represents the property being verified. The observer (Fig. 11) has an input signal ‘e1_ON and e2_ON’ and an output signal indicating that the property is violated: Violated (the signal Error is often used too). The observer is put in parallel with the model and it receives as inputs all input signals and output signals of the model and as outputs only one signal ‘Violated’. If ‘e1_ON and e2_ON’ is present then the signal Violated is possibly emitted. Example. In the example of Fig. 6, it is assumed that the redundancy of the robots R1 and R2 (that are used for loading/unloading the machine M1) is passive (XOR). The mutual exclusion property of
Fig. 12. Example of verification of a mutual exclusion property.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
84 Table 1 Summary table. Stages
Properties
Verification
P1 P2 P3 P4 P5
Validation
Deadlock freeness Reactivity and determinism States reachability Uniqueness of the mission Mutual exclusion of incompatible modes
supervision are specified and designed simultaneously [7]. It is necessary to verify and validate the corresponding models within the design process. The properties being verified in the validation stage are formalized according to the intended behavior of each model. For the integration within the control system, the properties being verified are related to the problems of synchronization and coherence of the communications (information exchanges) between those models. 4.3. Summary Both specification and V&V stages are carried out using an adequate method, which takes into account the strong hierarchy and concurrency of the model. The main properties being verified are presented and illustrated using an example of a manufacturing production cell. Esterel Studio V4.0 is used for all the experiments including the model-checker Built-in verifier, an evolution of XEVE. All the tests were carried out on a PC AMD Duron 1 Ghz with 1,3 Go of memory and the operating system Windows 2000. When using the model-checker, the response time and the memory used are reasonable. Table 1 recapitulates the studied properties. The studied cell can be extended with addition of machining resources (simple or polyvalent) and redundancies of the transport system (robots and conveyor). This allows studying the problem with increasing complexity. For the specification stage, adding or removing reference or instantiated models enable integrating easily the changes on the model thanks to the modularity and the hierarchy of the approach. However, due to increasing complexity of the cell some tests performed by the model-checker could not be concluded (out of memory problem). This problem will be solved in a future work. 5. Conclusion This paper deals with V&V within the design process of a model dedicated to mode handling of FMS. This model is based on a synchronous approach which guarantees the properties of determinism and reactivity and allows carrying out formal proofs. The first contribution of this study is a structured framework for carrying out V&V. It is an extension of the control system design approach in order to take into account V&V stage. An iterative method is used for specification and V&V stages of the design process. The aim is to refine the model construction using intermediate steps of V&V for an early correction of errors. Within the proposed framework the required properties (determinism, reachability and mutual exclusion of incompatible modes) are introduced and the corresponding verification methods are presented and illustrated. The analysis tools integrated into Esterel Studio are used in this process. Further applications will be performed using examples of manufacturing cells with increasing complexity. The proposed approach can be extended to deal with environment constraints in the specification and the V&V stages. Further work aims also at studying the properties related to the integration of mode handling model into the control system framework.
Analysis technique
Tool support
Compilation
Esterel compiler v5_x
Test of the statutes of output signals of the model
XEVE (Built-in verifier)
Test of output signal of an observer
References [1] P. Berruet, A.K.A. Toguye´ni, E. Craye, Towards implementation of recovery procedures for FMS supervision, Computers in Industry 43 (2000) 227–236. [2] R. Tawegoum, E. Castelain, J.C. Gentina, Real-time piloting of flexible manufacturing systems, European Journal of Operational Research 78 (1994) 252–261. [3] N. Hamani, N. Dangoumau, E. Craye, A comparative study of mode handling approaches, in: Proceedings of the 35th International Conference on Computers & Industrial Engineering (CIE 05), Istanbul, Turkey, 2005. [4] A.K.A. Toguye´ni, S. Elkhattabi, E. Craye, Functional and/or structural approach for the supervision of flexible manufacturing systems, in: Proceedings of IMACS-IEEE Multiconference on Computational Engineering in Systems Applications (CESA 96), Lille, France, (1996), pp. 716–721. [5] C. Andre´, Semantics of SSM (Safe State Machines). Guyancourt, France, April 2003, Available online: http://www.esterel-technologies.com. [6] C. Andre´, Representation and analysis of reactive behaviors: a synchronous approach, in: Proceedings of IMACS-IEEE Multiconference on Computational Engineering in Systems Applications (CESA 96), Lille, France, (1996), pp. 19–29. [7] N. Hamani, Contribution a` la mode´lisation et a` la ve´rification et validation pour la gestion des modes des syste`mes de production. PhD thesis, Ecole Centrale de Lille, France, 2005. [8] N. Hamani, N. Dangoumau, E. Craye, Reactive mode handling of flexible manufacturing systems, Mathematics and Computers in Simulation 79 (2009) 1421– 1439. [9] P. Biland, A.M. Deplanche´, J.P. Elloy, A model for operating modes of computer integrated manufacturing systems, in: Proceedings of the European Workshop on Integrated Manufacturing Systems Engineering (IMSE 94), Grenoble, France, 1994. [10] S. Bois, E. Craye, J.C. Gentina, Manager of working modes, CIM Integrated Design in Manufacturing 21 (3) (1992) 201–207. [11] T. Parayre, Y. Sallez, R. Soenen, Model of the state of operation of automated systems, in: Proceedings of the 8th International PROLAMAT conference (PROLAMAT 92), Tokyo, Japan, (1992), pp. 553–575. [12] C. Ausfelder, J.P. Maik, L. Kermad, J.C. Gentina, D. Delfieu, R. Moisand, A.E.K. Sahraoui, Integration of operating modes in the control of flexible manufacturing systems combining synchronous and asynchronous approaches, in: Proceedings of the IEEE International conference on Systems Man and Cybernetics (SMC 93), Le Touquet, France, (1993), pp. 234–239. [13] N. Dangoumau, E. Craye, Modes management for safe production systems, in: Proceedings of the 10th IFAC Symposium on Information Control Problems in Manufacturing (INCOM 01), Vienna, Austria, 2001. [14] L. Kermad, E. Craye, J.P. Bourey, J.C. Gentina, The exploitation modes of flexible manufacturing systems, in: Proceedings of the IEEE International conference on Systems Man and Cybernetics (SMC 94), San Francisco, USA, (1994), pp. 1521–1526. [15] D. Harel, StateCharts: a visual approach for complex systems, Science of Computer Programming 8 (3) (1987) 231–275. [16] G. Berry, G. Gonthier, The Esterel synchronous programming language: design, semantics, implementation, Science of Computer Programming 19 (2) (1992) 87– 152. [17] Esterel StudioTM, Available online: http://www.esterel-technologies.com. [18] D. Harel, On the development of reactive systems, in: Proceeding of the NATO Advanced Study Institute on Logics and Models for Verification and Specification of Concurrent Systems, NATO ASI series F, Vol. 13, Springer-Verlag, 1985, pp. 477–498. [19] J.M. Roussel, J.J. Lesage, Validation and verification of Grafcet using finite state machines, in: Proceedings of the IMACS-IEEE Multiconference on Computational Engineering in Systems Applications (CESA 96), Lille, France, (1996), pp. 758–764. [20] N. Halbawachs, Synchronous Programming of Reactive Systems, Kluwer Academic Publishers, Amsterdam, 1993. [21] G. Berry, The constructive semantics of pure Esterel Draft Version 3, 1999. Available: http://www.esterel-technologies.com. [22] G. Bouali, XEVE, an Esterel verification environment, in: Proceedings of the 14th International Conference on Computer Aided Verification (CAV 98), Vol. 1427 of LNCS, Springer-Verlag, 1998, pp. 500–504. [23] K.L. McMillan, Symbolic Model Checking, Kluwer Academic Publishers, 1993. [24] N. Halbawachs, F. Lagnier, P. Raymond, Synchronous observers and the verification of reactive systems, in: Proceedings of the 3rd International Conference on Algebraic Methodology and Software Technology (AMAST’93), Workshops in Computing, Springer-Verlag, 1993, pp. 83–96. [25] G. Berry, The foundations of Esterel, in: G. Plot kin, C. Stirling, M. Tote (Eds.), Proof, Language and Interaction: Essays in Honor of Robin Milner, MIT Press, 2002, pp. 425–454. [26] N. Hamani, N. Dangoumau, E. Craye, An iterative method for the design process of mode handling model, in: Proceedings of the IMACS-IEEE Multiconference on
N. Hamani et al. / Computers in Industry 60 (2009) 77–85 Computational Engineering in Systems Applications (CESA 06), Beijing, China, 2006. [27] G. Berry, Real-time programming: general purpose or special purpose languages, Information Processing 89 (1989) 11–17. [28] A. Benveniste, P. Caspi, S. Edwards, N. Halbwachs, P. Le Guernic, R. de Simone, The synchronous languages 12 years later, in: Proceedings of the IEEE, 1991(1), special issue on Embedded Systems, 2003, pp. 64–83. [29] Adepa, Le GEMMA: Guide d’Etude des Modes de Marches et d’Arreˆts. Production Automatise´e. ADEPA; 1981. Nadia Hamani received a PhD in automatic control for Manufacturing and Discrete Events systems from Ecole Centrale de Lille, France, in 2005. She is currently in a post doc position. Her research interests include supervision, monitoring, and control of discrete events systems. Nathalie Dangoumau is an Associate Professor of Computer Sciences and Discrete Events Systems (DES) at the Ecole Centrale de Lille (France). She obtained a Ph.D. in
85
Automatic control for Manufacturing and Discrete Events systems in 2000. Her research is about reconfiguration and modes management for Flexible Manufacturing Systems (FMS).
Etienne Craye was born in Roubaix (France) in 1961; he obtained in 1984 the Engineer Diploma of the ‘‘Institut Industriel du Nord’’ (French ‘‘Grande Ecole’’) and the same year his Master Degree in Computer Sciences. He obtained a PhD in Automatic control for Manufacturing and Discrete Events systems in 1989 and his ‘‘Habilitation a` Diriger des Recherches’’ in 1994. He is, since 1995, Professor at the Ecole Centrale de Lille and in the same time the Director of this institution. Pr. Craye is currently working on Monitoring and Supervision of Fault Tolerant Systems. Specially, reconfiguration and working mode management are today studied taking into account on one-hand failures and on the other hand the flexibilities of the system architecture. The objective is to be able to go on with the production and not to reconsider the objectives.
Contents lists available at ScienceDirect
Computers in Industry journal homepage: www.elsevier.com/locate/compind
Verification and validation of a SSM model dedicated to mode handling of flexible manufacturing systems Nadia Hamani a,*, Nathalie Dangoumau b, Etienne Craye b a b
Laboratoire Universitaire de Recherche en Production Automatise´e (LURPA), 61 avenue du Pre´sident Wilson, 94235 Cachan Cedex, France Laboratoire d’Automatique, Ge´nie Informatique et Signal (LAGIS), CNRS UMR 8146, Ecole Centrale de Lille BP 48, 59651 Villeneuve d’Ascq cedex, France
A R T I C L E I N F O
A B S T R A C T
Article history: Received 27 August 2006 Received in revised form 25 March 2008 Accepted 2 April 2008 Available online 6 December 2008
This paper focuses on verification and validation of a model dedicated to mode handling of flexible manufacturing systems (FMSs). This model is specified using the synchronous formalism safe state machines (SSMs). The rigorous semantics that characterize such formalism enable to provide formal verification mechanisms ensuring determinism and dependability. A structured framework for verification and validation of the model dedicated to mode handling is proposed. The main properties being verified within this framework and the corresponding verification methods are presented. The approach is illustrated using an example of a manufacturing production cell. The formal analysis tools integrated into the development environment Esterel Studio are used within the design process. ß 2008 Elsevier B.V. All rights reserved.
Keywords: Flexible manufacturing systems Control system Supervision Mode handling Functional and behavioral modeling Safe state machines Verification Validation
1. Introduction This work deals with the problems of supervision in fault tolerant control systems of flexible manufacturing systems (FMSs). In view of a disturbance, the supervision takes necessary decisions to return to normal or accepted operation. According to the design approach [1,2], the supervision is made up of three functions: decision, piloting, and mode handling. The role of mode handling function is to carry out the decisions about mode and configuration changing. In order to achieve this role, a model representing the operating modes of the whole system and its subsystems should be provided. To this aim, it is important to use an adequate modeling method and powerful specification formalisms. The modeling method should be well adapted to the production system characteristics. In addition, the specification formalism should support hierarchy and represent several forms of preemption. It should also be sufficiently formal to allow carrying out formal verification.
* Corresponding author. Tel.: +33 1 47 40 29 97; fax: +33 1 47 40 22 20. E-mail addresses: [email protected], [email protected] (N. Hamani), [email protected] (N. Dangoumau), [email protected] (E. Craye). 0166-3615/$ – see front matter ß 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2008.04.002
The modeling methods and the specification formalisms, which characterize the existing approaches, are compared in Ref. [3]. The main conclusions of this comparative study show that the mutual benefit of a functional modeling approach [4] and a powerful specification using the graphical synchronous language safe state machines (SSMs) [5,6] is very convenient for mode handling. A new modeling method for mode handling was presented in previous works [7,8]. It is based on a functional approach and on a synchronous reactive approach using SSM. The mode handler is using the FMS model; the aim is to handle concurrently the information flows downwards to transmit high-level control and reconfiguration orders and upwards to follow up the reports and the failures detected by the monitoring function. The reactivity needed for this bi-directional exchange of information in addition with the characteristics of concurrency and preemption, require a synchronous approach. Due to increasing complexity and flexibility of FMS, some problems appear during mode and configuration changing if coherence and safety constraints are not taken into account in the specification/modeling stages. So it is necessary to verify and validate the proposed models at the early stages of the design process. Running simulation is not exhaustive; a greater interest has been allocated for few years to formal verification methods,
78
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
which guarantee that for all possible evolutions of a model, several properties are satisfied. Thus, the purpose of this paper is to extend the modeling method by carrying out verification and validation (V&V) on the obtained model dedicated to mode handling. The paper is organized as follows. Section 1 focus on the context of this work. The main characteristics of the modeling method are reminded in Section 2: functional and behavioral specifications of the system and its subsystems. Section 3 introduces a structured framework for carrying out V&V on mode handling model. Basic concepts of V&V are presented then the stages of the design process including V&V are detailed. Section 4 presents mandatory and some optional properties being checked within this process. The specification and V&V process are illustrated through an example of a flexible manufacturing cell. 2. A modeling approach for mode handling As mentioned above, the modeling method is based on a functional decomposition and on a synchronous reactive approach using SSM. Functional approaches [9–11] are well suited for efficient reconfiguration procedures instead of structural approaches [12–14]. Besides, the required characteristics of hierarchy, parallelism, and preemption are well represented using synchronous languages compared with common models such as sequential functional charts (SFC) and Petri Nets (PN). The interests of using synchronous formalisms rely also on their strong semantics. They are compiled efficiently and it is possible, using formal techniques, to prove that the behavior of the system respects some properties. In the following subsection, the method leading to the functional subsystems is presented. Then the behavior of the obtained subsystems and the logical relations between them are specified using the synchronous formalism SSM. A modular approach is used for representing the resulting model. The design process is illustrated in Section 3.2. 2.1. The FMS subsystems A FMS produces simultaneously a subset of parts. Each part is characterized by an operating sequence (OS) [8]. The FMS usually changes its production goals. That is why the mission concept was introduced. It corresponds to a set of operating sequences that the system should carry out simultaneously. The specification method of FMS subsystems was described in Ref. [8]. The idea is to decompose and determine the functional subsystems, which take part in the realization of its missions. The FMS functional model is obtained by a hierarchical decomposition leading to the elementary machining and transfer operations. This functional specification is completed by associating resources with the elementary operations they perform. The obtained subsystems are organized in six layers as shown in Fig. 1. The functional representation is a graph composed of functional subsystems (called entities) linked by logical relationships (AND, OR and XOR). According to the constraints given in the functional requirements, the exclusive logical relation (XOR) is necessary for safety reasons, like two machining operations which are performed by the same resource for instance.
Fig. 1. The FMS functional model and information flows.
benefits of more strict semantics fully compatible with that of Esterel synchronous language [16]. SSM supports also, with a very rigorous semantics, hierarchy, communication, concurrency, and various forms of preemption, which characterize the proposed modeling approach. In addition, SSM take advantage of an industrial development environment [17], which provides necessary tools to the development stages of systems from specification to implementation. The presentation of the syntax of SSM is beyond the scope of this paper (see [5,6]). Behavioral specifications are summarized in the following. 2.2.1. Specification of the behavior of FMS subsystems Once the mission and the operating parameters are selected by the operator, the entities of the FMS functional model (Fig. 1) which take part in the selected mission can be activated if they are available. For behavioral specification, it is necessary to represent the activation/deactivation mechanisms at all the hierarchy levels as well as the availability of the subsystems. Fig. 2 summarizes the states of an entity. The activation/deactivation of an entity is represented by the working mode. The functioning mode represents the availability/ unavailability of an entity. The behavior of each entity of the model, whatever its level, is represented by a SSM including these two modes (Fig. 3). This model allows knowing, at any time, if an entity belonging to the current mode of the FMS is in normal state e_N, degraded state e_D or out of order state e_OUT according to the functioning mode point of view; and if it is activated e_Active or inactive (in stopping state) e_OFF according to the working mode point of view. The initial states are the stopping state e_OFF for the working mode and the normal state e_N for the functioning mode. The activation of an entity e using start_e can be made only if the entity is available (i.e. it should not enter the out of order state). This is represented using ‘start e and not e_OUT’. As soon as the entity is active, it enters the working state e_ON if the conditions of its activation are appropriate. Such conditions depend on the logical relation between the entities. The stopping state is effectively reached when the entity ends its activity. Indeed, when the entity reaches the final state (see the state End distinguished by its double outline), the macro-state e_Active is exited through the normal termination (whose tail is a small triangle). According to the previous specification, the input and the output signals represented in Fig. 3 are the following: for working
2.2. Behavior specification The graphical synchronous formalism SSM [5] (or SyncCharts (Synchronous Charts) [6]) is used to specify the behavior of the entities of the functional model. SSM inherits many features from Statecharts [15] but offers several forms of preemption and
Fig. 2. The states of an entity.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
79
They are a representation in SSM which is similar to procedures (or functions) used in programming languages. Reference models are instantiated for each entity. An iterative approach of specification is proposed in order to improve this process. At first the models of level i are specified, then the SSM of level i is encapsulated in the SSM of level i + 1 until completing the specification of the model (Fig. 4). The hierarchy is represented by the encapsulation of successive levels whereas the entities belonging to the same level are separated by dashed lines; these are used to represent concurrency in SSM syntax. 2.3. Using the behavioral model for reactive mode handling
Fig. 3. The SSM representing the modes and states of an entity.
mode, the input signals start_e and stop_e correspond, respectively to the activation/deactivation orders. They lead entering the states e_ON and e_OFF, respectively. For functioning mode, the input signals e_n, e_d and e_out provoke, respectively entering the normal state e_N, degraded state e_D, and out of order state e_OUT. Local signals are also needed for specification. They are signals which are neither controllable nor directly observable. 2.2.2. Specification of the logical relations Let us define a relation between a parent entity of level i and a set of child entities of level i 1. The child entities are related either using a logical AND or a logical OR. For working mode, the activation/deactivation request is a downward information flow from a parent entity to its child entities. The reports of such requests are propagated upwards. For functioning mode, failure events involve the change-of-state of FMS resources, i.e. the entities at the lower level of the model. This information flow is propagated upwards from the child entities towards their parent entity. The change-of-state of the entities of the model belonging to successive levels is carried out according to precise rules which depend on the kind of the logical relation and the number of child entities. Several cases are studied in Ref. [7]. 2.2.3. Modular representation using reference models The specification of any entity of the model differs according to whether it has one or more child entities or it has no child entity (the leaves of the graph). It depends also on the logical relation between the child entities. Thus, reference models are defined.
Fig. 4. The representation of the model.
As shown in Fig. 1, the behavioral model should handle the information flows downwards to transmit the orders from Human Machine Interface and upwards to propagate the information provided by the monitoring function. The downward flow of highlevel control and reconfiguration orders is propagated through the operations sequences corresponding to the selected mission. The flow is then propagated through the operations and the resources which take part in the realization of the selected mission. As for the downward flow, the upward flow transmits the results obtained by the execution of high-level control and reconfiguration orders and process the information about the availability of the resources and the operations. The mode handler is a reactive system [18] which continuously reacts to stimuli (inputs) of the environment by sending back other stimuli (outputs). Consider the reactions of a SSM associated with an entity of the model. Each entity e at level i may receive either a request from level i + 1 indicating a mission or a working mode change or a mode changing of one or more child entities of level i 1. Within the specification stage, it is necessary to respect some rules for a coherent integration within the control system framework. These rules are detailed in Ref. [7]. In the next section, a framework for carrying out V&V of the obtained model is presented. 3. A framework for carrying V&V 3.1. V&V within a design process A design process should involve many intermediary stages of V&V. The aim is to eliminate as soon as possible the specifications errors. Indeed, V&V characterize any correct development process. According to Ref. [19] verification is the proof that the internal semantics of a model is correct independently of the modeled system whereas validation determines if the model corresponds to the attempts of the designer given in the functional requirements. The required properties are either generic, they depend on the used formalism, or specific to the modeled system. V&V consists of analyzing the properties that should be satisfied by the final model. Two complementary methods are used; simulation and formal verification. This work deals only with formal methods for V&V. Three steps are needed: building the model representing the behavior of the system, formalizing the properties, and the analysis of the formal model. The searched properties as well as the methods used for their verification depend on the formalism. The rigorous semantics of synchronous languages, SSM included; enable to provide formal verification mechanisms ensuring determinism and dependability. Within a design process, V&V of mode handling model specified using SSM is shown in Fig. 5.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
80
Fig. 6. Illustration example. Fig. 5. V&V within the design process.
The formal specification as well as the structured modeling process presented in the previous section, ensures a correct development and no errors propagation. V&V of the obtained model is an iterative stage which requires reconsidering the specification/modeling stage as needed. Based on the verified and validated model the implementation is ensured through automatic code generation. 3.2. The specification/modeling stage The functional requirements provide informal specifications about the intended behavior of the FMS and the properties that should be respected. The designer provides formal specifications of the model and the required properties. The formal model representing the behavior of the system: the specifications of the model dedicated to FMS mode handling are presented in the previous section. The cell of Fig. 6 is an illustration example. It consists of two machines M1, M2 and input/output buffers (I/O). The transport system is composed of two robots R1 and R2. M1 is loaded by R1 and M2 is loaded by R2, this latter will be used to load the two machines
when R1 is failing. The performed machining functions are turning (t) and milling (f). Turning (t) is carried out by M1, milling (f) by M1 or M2. The cell has three missions, M 1 , M2 and M3 . The corresponding operating sequences are, respectively OS1 (t), OS2 (f) and then OS1 and OS2 simultaneously. The obtained model is presented in Fig. 7. A reduced size cell enables to illustrate the proposed approach without facing the problem of increasing number of states. The model of this cell is specified using four reference models and 29 instances for 809 lines of Esterel code generated from SSM models. This model needs 34 input signals and 145 output signals. At first some scenarios are simulated in order to eliminate the specification errors so that the intended behavior respects the functional requirements. The interactive simulator XEtented Simulator (XES) [17] is used. The model must handle correctly the activation/deactivation of the missions and the corresponding entities. The propagation of the failures is also tested. The tests carried out for all the configurations of the cell allow to validate in an informal way the intended behavior. This example is also used below to illustrate the study of the properties in V&V stage. The formal specification of the properties that should be satisfied: in this paper, only the properties of logical behavior such as determinism and safety properties are considered. As a
Fig. 7. The model of mode handling.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
reactive synchronous approach [20] based on SSM formalism is used, generic properties of reactivity and determinism should be checked. Several specific properties to mode handling function should also be checked. Such properties are about the coherence of the modes and the missions of the FMS. The main properties are introduced and detailed in Section 4. The SSM tool editor integrated into Esterel Studio environment is used for the specification of the model. Specific properties are represented either by observers specified in SSM or using Esterel language. 3.3. The V&V stage In the verification stage (see Fig. 8), one checks if the model respects the generic properties. SSM specifications are automatically translated into Esterel program which is compiled in a system of Boolean equations (logical circuits) an implicit form of finite state machines (FSM). The properties of logical correctness of Esterel programs can then be checked on this system. The analysis technique used to this aim is the constructive causality analysis carried out by Esterel compiler v5_x. Causality analysis is a semantic analysis which allows accepting or rejecting Esterel programs according to whether they are constructive or not [21]. The processor which implements the algorithms of constructive analysis builds the reachable state space using symbolic techniques based on binary decision diagrams (BDD). In the validation stage, one checks if the model respects the specific properties formalized in the specification stage. The
81
analysis techniques used are model-checking and/or theorem proving. Several model-checking tools were developed for Esterel language. For instance Built-in verifier tool an evolution of XEsterel VErifier (XEVE) [22] is currently integrated into Esterel Studio. XEVE takes as input the system of Boolean equations and built the reachable state space using BDD (symbolic model-checking [23]). XEVE tests the statutes of output signals by analysis of the reachable states. Thus, safety properties of simple type stating that ‘a dangerous state will never be reachable’ can be checked. XEVE tests also the statutes of output signals of the observers [24,25] representing safety properties of combinatorial type, sequential type or of bounded time. Liveness properties can also be checked using XEVE but they are not considered in this study. The modular and hierarchical specification shown in Fig. 4 is completed by introducing an iterative method of V&V (see [26]). The aim is to reduce the specification/modeling errors and enable an early correction by introducing intermediate stages of V&V into the multi-level specification stage. Failing of the verification stage implies that there is a specification or a modeling error. It is then necessary to go back over the model, as needed until completing the verification of all the properties. Also failing of the verification of a property carried out by the model-checker needs to revise the specification/ modeling stage. Within the formal specification of the model and its properties, some errors may be caused by no perfect experience with the formalism for instance. The errors in the formal specifications are related to the following reasons [7]: The specification of the model is incorrect. The specification of the property is incorrect. The correspondence between the model and the property is incorrect: the error may be in the correspondence between signals appearing in the property and those of the model. The assumptions related to the environment: the model does not respect the property in the general case but only under some assertions or constraints [17] of the environment. If the specification/modeling stages are considered to be correct, the validation failing is due to an earlier stage, which leads to reconsider informal requirements. Indeed the errors in the formal specification of the model or its properties are caused by the ambiguity or the incompleteness of the informal requirements. In this case, they should be improved and reconsidered again. In addition, in the validation stage, if the model is modified a verification step is necessary before a new validation. Indeed, generic properties of a modified model must be checked again to allow its validation. Once the model is verified and validated, the implementation is ensured through automatic code generation. Here, also one of the advantages of synchronous languages is to ensure the preservation of the properties between the specification and implementation stages (What You Prove Is What You Execute, WYPIWYE [27]). Fig. 8 shows also the intended use of the generated code. In the following, a detailed study of the properties being checked in V&V stage is presented. 4. Properties study
Fig. 8. V&V within the design process.
At first generic properties that depend on the synchronous formalism SSM are introduced. Then some specific properties being checked in the validation stage are proposed. These properties ensure mode coherence. For each property the corresponding expression, the verification method and an illustration example are given. The last paragraph is dedicated to some specific properties that could also be checked.
82
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
4.1. Generic properties Semantic analysis is carried out on the system of Boolean equations resulting from Esterel program compilation. Semantic analysis also called causality analysis allows checking generic properties (deadlock freeness, reactivity, determinism). These are presented in the following. 4.1.1. Semantic analysis of Esterel programs The analyzed Esterel programs correspond to the semantic model of FSM. Indeed, the compilation of a synchronous program generates a state machine in the form of a finite state automata or a system of equations (circuit). The difference between a finite state automata and a system of equations is that the first represents the reachable state space in an explicit way whereas the second represents it in an implicit way. The translation of Esterel programs in logical circuits is rigorously formalized in Ref. [21]. In addition, the preservation of constructivity (i.e. constructive causality) of a program when it is translated into a circuit is proved. Thus, any constructive circuit implies that the corresponding program is also constructive. This formal relation is very important because causality analysis is rather carried out on Esterel circuits. In addition, if a circuit or the corresponding program is correct from the constructive point of view then it is correct from the logical point of view, this means that there is a solution and this one is unique. The existence of a solution corresponds to the reactivity of the program and the uniqueness of the solution corresponds to the determinism. These two properties are very important in the context of reactive systems. The causality of Esterel programs is a stronger requirement compared with reactivity and determinism. Indeed, any causal program (or circuit) is reactive and deterministic, however the reverse is not true [21]. Generic properties are presented in the following. 4.1.2. Deadlock freeness Causality analysis proves that a program is causal according to the constructive causality defined by Berry [21]. Constructive causality of Esterel programs ensures deadlock freeness, which characterizes synchronous languages. Deadlocks are due to the synchronism assumption (see causality problems in Ref. [28]). Property 1 (Deadlock freeness (mandatory)). The specification model should be deadlock free. Verification: constructivity analysis of Esterel programs is carried out with Esterel compiler v5_x. If an Esterel program is constructive then it is reactive and deterministic. A program is said to be reactive if it provides a welldefined solution for each input. It is deterministic if this solution is unique [21].
properties are presented, two properties are of simple type (reachability and mission uniqueness) and the third one is of combinatorial type (incompatible modes). 4.2.1. States reachability According to the specifications, an output signal is associated with each control state of the model. To check the reachability, the statutes of output signals that correspond to control states are tested. Property 3 (Reachability of the modes (optional)). All the states within a mode must be reachable. When building the reachable state space of the model, if there is at least a reachable state in which an output signal (for example e_ON the working state of the entity e) is present then the corresponding state (i.e. e_ON) is reachable. Verification: the statutes of output signals of the model are tested using XEVE tool. Example. One tests if the output signal is possibly emitted. The answer is possibly emitted if there is a reachable state from which the signal is emitted. The control state is then reachable. If the answer is never emitted the state is then unreachable. As shown on Fig. 9, the reachability of the states of the model of Fig. 7 is checked by testing the statutes of the corresponding output signals. For each signal, XEVE tool has found a sequence of inputs that leads to the emission of this signal. XEVE answers by possibly emitted, the property is then verified. The sequence of inputs (on the right of Fig. 9) can be visualized using XES simulator. 4.2.2. The mission uniqueness This property ensures operation safety of the FMS according to the selected mission. Indeed, selecting a mission implies performing some operations and activating the resources, which take part in this mission. Thus, the operations and the resources, which do not take part in the current mission, should not be activated for safety and coherence reasons. The property is guaranteed by construction of the model. According to the concept of current mode uniqueness recommended by the GEMMA [29], a property ensuring the mission uniqueness of a FMS is introduced. Property 4 (The mission uniqueness (mandatory)). Each entity e of the model, which does not take part in the current mission M, cannot be in working state. The signal e_ON is never emitted if the FMS mission M is activated and the entity e does not take part in this mission.
Property 2 (Reactivity and determinism (mandatory)). The specification model should be reactive and deterministic. Verification: constructivity analysis of Esterel programs (Property 1) involves consequently Property 2. Example. Causality analysis is realized successfully on the model of the illustration example. The compiler accepts the Esterel program generated from the SSM model. It is thus causal (Property 1) and verify necessarily reactivity and determinism properties (Property 2). 4.2. Specific properties The aim here is to ensure coherence and safety constraints of mode handling specifications. In this section three kinds of safety
Fig. 9. Reachability of the states of the model.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
83
Fig. 11. The observer specifying mutual exclusion.
Fig. 10. Example of verification of Property 4.
Verification: the statutes of the output signals of the model are tested modulo a restriction on a set of input signals. Example. In the example of Fig. 6, the mission M1 of the cell is using only the machine M1. If this mission is activated M2 cannot be in working state. The input signals, which allow choosing and activating a mission and selecting the configurations of the redundant entities, are declared as always present. Then the signal M2_ON is tested if it is possibly emitted? The response of XEVE should be: the signal M2_ON is never emitted to conclude that the property is satisfied. If the answer is: the signal M2_ON is possibly emitted then the property is not satisfied and the specification must be revised. Fig. 10 shows that the machine M2 cannot be in working state for a configuration of the cell corresponding to the mission M1 . The answer given by XEVE is never emitted, i.e. the property is verified. 4.2.3. Incompatible modes In order to ensure mode coherence, the proposed specifications in Section 2 guarantee mutual exclusion of incompatible states of the entities of the model (each state is belonging to a distinct mode). It is about mutual exclusion of working states of the entities related with the logical relation XOR (for example redundant resources). One checks if mutual exclusion properties are satisfied. Property 5 (Incompatibility of the modes (mandatory)). Independently of the selected mission, incompatible working modes are never reached simultaneously.
R1_ON and R2_ON is checked in the following way: independently of the selected mission, the question is if the output signal Violated is possibly emitted? The response should be: the signal Violated is never emitted so that the property is satisfied. If the answer is: the signal Violated is possibly emitted then the property is not satisfied and the specification must be revised. The mutual exclusion property of R1_ON and R2_ON is verified because XEVE answers by never emitted (Fig. 12). 4.2.4. Other properties 1. In addition to the previous properties, other properties of the model can be checked. According to [7,19] the properties deal with mode changing conditions and respecting mode sequence: The conditions of mode changing correspond to safety properties of simple type. For example, an entity e of the model cannot reach a well-defined state, for example the state e_OUT, only if the condition e_out is present. For checking this property, the status of the output signal corresponding to the state e_OUT is tested with a restriction on the input signal representing the evoked condition. Thus, if the condition is always absent, the output signal is never emitted. The respect of mode sequence corresponds to safety properties of sequential type which states that a sequence of actions must occur (or will never occur in the case of a dangerous sequence). The property is specified using an observer, which represents the sequences of events that lead to the error. The status of the output signal of this observer is tested. 2. V&V within the control system: according to the design approach of FMS control system, low level control, monitoring and
For any couple of entities e1 and e2 with incompatible working modes, there is not a reachable state of the model in which the signal ‘e1_ON and e2_ON’ is present. It means that the signals e1_ON and e2_ON are never emitted simultaneously (mutual exclusion). Verification: the status of the output signal of an observer is tested modulo a restriction on a set of input signals. An observer is a model specified in SSM and represents the property being verified. The observer (Fig. 11) has an input signal ‘e1_ON and e2_ON’ and an output signal indicating that the property is violated: Violated (the signal Error is often used too). The observer is put in parallel with the model and it receives as inputs all input signals and output signals of the model and as outputs only one signal ‘Violated’. If ‘e1_ON and e2_ON’ is present then the signal Violated is possibly emitted. Example. In the example of Fig. 6, it is assumed that the redundancy of the robots R1 and R2 (that are used for loading/unloading the machine M1) is passive (XOR). The mutual exclusion property of
Fig. 12. Example of verification of a mutual exclusion property.
N. Hamani et al. / Computers in Industry 60 (2009) 77–85
84 Table 1 Summary table. Stages
Properties
Verification
P1 P2 P3 P4 P5
Validation
Deadlock freeness Reactivity and determinism States reachability Uniqueness of the mission Mutual exclusion of incompatible modes
supervision are specified and designed simultaneously [7]. It is necessary to verify and validate the corresponding models within the design process. The properties being verified in the validation stage are formalized according to the intended behavior of each model. For the integration within the control system, the properties being verified are related to the problems of synchronization and coherence of the communications (information exchanges) between those models. 4.3. Summary Both specification and V&V stages are carried out using an adequate method, which takes into account the strong hierarchy and concurrency of the model. The main properties being verified are presented and illustrated using an example of a manufacturing production cell. Esterel Studio V4.0 is used for all the experiments including the model-checker Built-in verifier, an evolution of XEVE. All the tests were carried out on a PC AMD Duron 1 Ghz with 1,3 Go of memory and the operating system Windows 2000. When using the model-checker, the response time and the memory used are reasonable. Table 1 recapitulates the studied properties. The studied cell can be extended with addition of machining resources (simple or polyvalent) and redundancies of the transport system (robots and conveyor). This allows studying the problem with increasing complexity. For the specification stage, adding or removing reference or instantiated models enable integrating easily the changes on the model thanks to the modularity and the hierarchy of the approach. However, due to increasing complexity of the cell some tests performed by the model-checker could not be concluded (out of memory problem). This problem will be solved in a future work. 5. Conclusion This paper deals with V&V within the design process of a model dedicated to mode handling of FMS. This model is based on a synchronous approach which guarantees the properties of determinism and reactivity and allows carrying out formal proofs. The first contribution of this study is a structured framework for carrying out V&V. It is an extension of the control system design approach in order to take into account V&V stage. An iterative method is used for specification and V&V stages of the design process. The aim is to refine the model construction using intermediate steps of V&V for an early correction of errors. Within the proposed framework the required properties (determinism, reachability and mutual exclusion of incompatible modes) are introduced and the corresponding verification methods are presented and illustrated. The analysis tools integrated into Esterel Studio are used in this process. Further applications will be performed using examples of manufacturing cells with increasing complexity. The proposed approach can be extended to deal with environment constraints in the specification and the V&V stages. Further work aims also at studying the properties related to the integration of mode handling model into the control system framework.
Analysis technique
Tool support
Compilation
Esterel compiler v5_x
Test of the statutes of output signals of the model
XEVE (Built-in verifier)
Test of output signal of an observer
References [1] P. Berruet, A.K.A. Toguye´ni, E. Craye, Towards implementation of recovery procedures for FMS supervision, Computers in Industry 43 (2000) 227–236. [2] R. Tawegoum, E. Castelain, J.C. Gentina, Real-time piloting of flexible manufacturing systems, European Journal of Operational Research 78 (1994) 252–261. [3] N. Hamani, N. Dangoumau, E. Craye, A comparative study of mode handling approaches, in: Proceedings of the 35th International Conference on Computers & Industrial Engineering (CIE 05), Istanbul, Turkey, 2005. [4] A.K.A. Toguye´ni, S. Elkhattabi, E. Craye, Functional and/or structural approach for the supervision of flexible manufacturing systems, in: Proceedings of IMACS-IEEE Multiconference on Computational Engineering in Systems Applications (CESA 96), Lille, France, (1996), pp. 716–721. [5] C. Andre´, Semantics of SSM (Safe State Machines). Guyancourt, France, April 2003, Available online: http://www.esterel-technologies.com. [6] C. Andre´, Representation and analysis of reactive behaviors: a synchronous approach, in: Proceedings of IMACS-IEEE Multiconference on Computational Engineering in Systems Applications (CESA 96), Lille, France, (1996), pp. 19–29. [7] N. Hamani, Contribution a` la mode´lisation et a` la ve´rification et validation pour la gestion des modes des syste`mes de production. PhD thesis, Ecole Centrale de Lille, France, 2005. [8] N. Hamani, N. Dangoumau, E. Craye, Reactive mode handling of flexible manufacturing systems, Mathematics and Computers in Simulation 79 (2009) 1421– 1439. [9] P. Biland, A.M. Deplanche´, J.P. Elloy, A model for operating modes of computer integrated manufacturing systems, in: Proceedings of the European Workshop on Integrated Manufacturing Systems Engineering (IMSE 94), Grenoble, France, 1994. [10] S. Bois, E. Craye, J.C. Gentina, Manager of working modes, CIM Integrated Design in Manufacturing 21 (3) (1992) 201–207. [11] T. Parayre, Y. Sallez, R. Soenen, Model of the state of operation of automated systems, in: Proceedings of the 8th International PROLAMAT conference (PROLAMAT 92), Tokyo, Japan, (1992), pp. 553–575. [12] C. Ausfelder, J.P. Maik, L. Kermad, J.C. Gentina, D. Delfieu, R. Moisand, A.E.K. Sahraoui, Integration of operating modes in the control of flexible manufacturing systems combining synchronous and asynchronous approaches, in: Proceedings of the IEEE International conference on Systems Man and Cybernetics (SMC 93), Le Touquet, France, (1993), pp. 234–239. [13] N. Dangoumau, E. Craye, Modes management for safe production systems, in: Proceedings of the 10th IFAC Symposium on Information Control Problems in Manufacturing (INCOM 01), Vienna, Austria, 2001. [14] L. Kermad, E. Craye, J.P. Bourey, J.C. Gentina, The exploitation modes of flexible manufacturing systems, in: Proceedings of the IEEE International conference on Systems Man and Cybernetics (SMC 94), San Francisco, USA, (1994), pp. 1521–1526. [15] D. Harel, StateCharts: a visual approach for complex systems, Science of Computer Programming 8 (3) (1987) 231–275. [16] G. Berry, G. Gonthier, The Esterel synchronous programming language: design, semantics, implementation, Science of Computer Programming 19 (2) (1992) 87– 152. [17] Esterel StudioTM, Available online: http://www.esterel-technologies.com. [18] D. Harel, On the development of reactive systems, in: Proceeding of the NATO Advanced Study Institute on Logics and Models for Verification and Specification of Concurrent Systems, NATO ASI series F, Vol. 13, Springer-Verlag, 1985, pp. 477–498. [19] J.M. Roussel, J.J. Lesage, Validation and verification of Grafcet using finite state machines, in: Proceedings of the IMACS-IEEE Multiconference on Computational Engineering in Systems Applications (CESA 96), Lille, France, (1996), pp. 758–764. [20] N. Halbawachs, Synchronous Programming of Reactive Systems, Kluwer Academic Publishers, Amsterdam, 1993. [21] G. Berry, The constructive semantics of pure Esterel Draft Version 3, 1999. Available: http://www.esterel-technologies.com. [22] G. Bouali, XEVE, an Esterel verification environment, in: Proceedings of the 14th International Conference on Computer Aided Verification (CAV 98), Vol. 1427 of LNCS, Springer-Verlag, 1998, pp. 500–504. [23] K.L. McMillan, Symbolic Model Checking, Kluwer Academic Publishers, 1993. [24] N. Halbawachs, F. Lagnier, P. Raymond, Synchronous observers and the verification of reactive systems, in: Proceedings of the 3rd International Conference on Algebraic Methodology and Software Technology (AMAST’93), Workshops in Computing, Springer-Verlag, 1993, pp. 83–96. [25] G. Berry, The foundations of Esterel, in: G. Plot kin, C. Stirling, M. Tote (Eds.), Proof, Language and Interaction: Essays in Honor of Robin Milner, MIT Press, 2002, pp. 425–454. [26] N. Hamani, N. Dangoumau, E. Craye, An iterative method for the design process of mode handling model, in: Proceedings of the IMACS-IEEE Multiconference on
N. Hamani et al. / Computers in Industry 60 (2009) 77–85 Computational Engineering in Systems Applications (CESA 06), Beijing, China, 2006. [27] G. Berry, Real-time programming: general purpose or special purpose languages, Information Processing 89 (1989) 11–17. [28] A. Benveniste, P. Caspi, S. Edwards, N. Halbwachs, P. Le Guernic, R. de Simone, The synchronous languages 12 years later, in: Proceedings of the IEEE, 1991(1), special issue on Embedded Systems, 2003, pp. 64–83. [29] Adepa, Le GEMMA: Guide d’Etude des Modes de Marches et d’Arreˆts. Production Automatise´e. ADEPA; 1981. Nadia Hamani received a PhD in automatic control for Manufacturing and Discrete Events systems from Ecole Centrale de Lille, France, in 2005. She is currently in a post doc position. Her research interests include supervision, monitoring, and control of discrete events systems. Nathalie Dangoumau is an Associate Professor of Computer Sciences and Discrete Events Systems (DES) at the Ecole Centrale de Lille (France). She obtained a Ph.D. in
85
Automatic control for Manufacturing and Discrete Events systems in 2000. Her research is about reconfiguration and modes management for Flexible Manufacturing Systems (FMS).
Etienne Craye was born in Roubaix (France) in 1961; he obtained in 1984 the Engineer Diploma of the ‘‘Institut Industriel du Nord’’ (French ‘‘Grande Ecole’’) and the same year his Master Degree in Computer Sciences. He obtained a PhD in Automatic control for Manufacturing and Discrete Events systems in 1989 and his ‘‘Habilitation a` Diriger des Recherches’’ in 1994. He is, since 1995, Professor at the Ecole Centrale de Lille and in the same time the Director of this institution. Pr. Craye is currently working on Monitoring and Supervision of Fault Tolerant Systems. Specially, reconfiguration and working mode management are today studied taking into account on one-hand failures and on the other hand the flexibilities of the system architecture. The objective is to be able to go on with the production and not to reconsider the objectives.