- Email: [email protected]
FORMAL SPECIFICATION OF SAFE MANUFACTURING MACHINES USING THE B METHOD: APPLICATION TO A MECHANICAL PRESS
INCOM'2006: 12th IFAC/IFIP/IFORS/IEEE/IMS Symposium Information Control Problems in Manufacturing May 17-19 2006, Saint-Etienne, France
FORMAL SPECIFICATION OF SAFE MANUFACTURING MACHINES USING THE B METHOD: APPLICATION TO A MECHANICAL PRESS Dominique EVROT1+3, Jean-François PETIN1, Dominique MERY2 (1) Université Henri Poincaré, CRAN, UMR 7039 CNRS-INPL-UHP (2) Université Henri Poincaré, LORIA, UMR 7503 CNRS-INPL-UHP-INRIA-Nancy II Campus Scientifique, BP 239, 54506 Vandoeuvre lès Nancy {dominique.evrot}{jean-francois.petin}@cran.uhp-nancy.fr, [email protected] (3) INRS, BP 27 54501 Vandoeuvre lès Nancy cedex
Abstract: This paper deals with the development of manufacturing machinery subjected to strong dependability and safety properties. In this context, IEC 61508 standard recommends the use of formal methods to control the complexity of software intensive applications. This paper focuses on model refinement to ensure safety requirements traceability. A mechanical press case study illustrates a way to bridge the gap for using the B method within such an automation-oriented context. Copyright © 2006 IFAC Keywords: Formal specification, safety analysis, requirements refinement, machinery control design
1.
INTRODUCTION
In this context, INRS is waging a study about the conceptual and practical approaches related to safety/reliability, computer sciences and automatic control. More precisely, verification using model checking (Clarke et al, 2000)(Craigen et al, 1995)(Feldman et al, 1999) or theorem proving (Abrial et al, 1991)(Roussel and Faure, 2002) have been tackled. However, in spite of the consensus that early phases of a system definition are the most important ones to ensure that the system will satisfy the user’s requirements, most of these models and tools address the design and implementation phases. Over these later stages, many systems engineering and automation engineering practitioners (Shell, 2001)(Johnson, 2004) are considering that time is ripe to formalise the earlier stages of specification. This means providing a set of guidelines, generic constructs, and formal verification tools to establish a non-ambiguous, correct, consistent and complete model of understanding of what a system has to do according to the users’ requirements before designing its behaviour according to the multiple engineers’ practices and techniques (Lhote et al, 1999).
Manufacturing machines are increasingly being equipped with programmable logic controllers (PLCs) which ensure not only their strictly functional part but also operator safety functions. They have long been ensured by electromechanical technology, the application of which is relatively well mastered both from the design and production points of view. Integration of safety functions into the software parts of programmable systems can be envisaged only if the safety level of “PLC and software” set is at least equal to the electromechanical circuit’s one. One role of Institut National de Recherche et de Sécurité (INRS) in France is to study methods for the development of safety machines and to deliver safety certification for some equipments (presses, wood machines and electro-sensitive protective devices) listed in the annex IV of the machinery directive (Blaise et al., 2003). It could be based on normative recommendations such as the IEC 61508 standard defining four Safety Integrity Levels (SILs) according to an estimation of the risk for the operator, the probability of failure of each component, and the method used to develop the system. In particular, the higher level SIL 4 recommends the use of formal methods to control the quality of software intensive applications.
Among candidate formalisms, INRS has studied on the B method (Abrial, 1996) and ordered a case study development using this method1 (Lamy and Bello, 1
281
Atelier B is a product of ClearSy, http://www.clearsy.com.
2004)(Abrial et al, 2005). This study has clearly shown the benefit of using B for proved code generation. Nevertheless, applying this approach within an industrial automation engineering framework requires the definition of a system formal engineering rationale: - to better detail how the safety requirements are taken into account all along the development process and to ensure their traceability, - to enlarge software engineering to system engineering including software, hardware, manmachine interface and physical systems as required by automation projects.
when in up position. Moreover, if the operator releases the hand command during the falling phase, or if emergency stop occurs, the press is stopped. Mechanical press environment
O p e r a t i n g S y s t e m
This paper presents a mechanical press case study that illustrates a way to bridge the gap for using the B method within an automation-oriented context. Our proposal is based on: - a refinement mechanism that is rather used to progressively detail abstract safety properties into more concrete ones related to each subsystems than to only simplify proof tasks, - the Fusaoka’s automation assertion (Fusaoka et al, 1983), which postulates that the design of automation systems consists in defining the control rules of the dynamics of a physical system, starting from the behavioural goals to be met: Control Rules ∧ Dynamics ⊃ Goal (1). Note that this decomposition is close to the structure of a machine given by ISO 121002 in terms of control and operative parts.
Motor steering wheel
Mobile Disc Springs
C o n t r o l S y s t e m
Crankshaft
Clutching-braking system
Mechanical press system
Fig. 1. Mechanical press case study Two main safety properties have to be guaranteed in this operating mode: - S1: falling movement is enabled if and only if operator’s hands are on the two hands command and emergency stop is not engaged. - S2: rising movement is enabled if and only if the emergency stop is not engaged. Note that in rising movement, no constraint about the two hands command is required. This set of mode specification and safety properties is the foundation of the B first formalisation.
The two first sections introduce respectively the mechanical press case study and the B formalism. Third section details the refinement mechanism based on the Fusaoka’s assertion. Fourth section discusses about the verification issues due to the properties decomposition introduced by our modelling framework. Last section gives some conclusions and prospects. 2.
Clutch side Brake side
3.
THE B METHOD
Introduced by Abrial, the B Method is a formal method for the specification, design, and implementation of software/system applications that supports invariance and safety properties proofs. The B language is based on: - set theory with classical set operators (S U T, S I T, S c T, x e S, #S), function and relationship (A j B Í P A x B); - first order logic with classical operators of a 2valued proposal logic (! P, P v Q, P ¶ Q, P fi Q, P ¤ Q) and quantifiers (A X • p, E X • p).
MECHANICAL PRESS CASE STUDY
In this paper, we consider a mechanical press that aims at stamping metal products with a tool in vertical movement. A crankshaft equipped with two sensors for top and bottom dead centres gives this vertical movement. A clutch, which is actuated by a pneumatic valve, ensures the transmission between motor and crankshaft. Operator protection is supplied thanks to a two hands command. An emergency stop enable or not the stamping action.
A B model is defined by the structure shown in Fig 2. MODEL m SETS s CONSTANTS c PROPERTIES p VARIABLES x INVARIANT I(x) INITIALISATION init(x) EVENTS O1= Select P1(x) Then S1(x) … On = Select Pn(x) Then Sn(x) END
We focus on the press function that is in charge of clutching and braking the press motor in the normal operating mode (motor is considered as always working). In this mode, the press is initially stopped in up position and waits for a two hands command. Then, the tool is falling until the bottom dead centre is reached, then is rising back, and finally stopped
Fig. 2. B formal model
2
ISO 12100, Safety of machinery – basic concept, general principles for design, January 2004
282
A model has a name m; the clause SETS contains definitions of sets of the problem; the clause CONSTANTS allows the designer to introduce information related to the mathematical structure of the problem to be solved; and the clause PROPERTIES contains the effective definitions of the constants. The second section of the model defines the dynamic aspects of the state variables and properties of variables using the invariant. Events O1…On are used to describe state variable modifications due to generalized substitutions; Si(x) contains the new value of variable x after the occurrence of Oi. The substitution of a variable is feasible with respect to its guard. The invariant I(x) states that variable x is always in a given set of possible values, which is assumed to be initialized with respect to the initial conditions and which is preserved by any event of the list of events. Conditions of verification, called proof obligations are generated from the text of the model, and they express underlying hypotheses required for the preservation of invariant properties: (INV1) Init(x) fi I(x) (INV2) I(x) ¶ P(x) fi I( S(x)) (INV1) states the initial condition that should establish the invariant. (INV2) should be checked for every event Oi of the model; it states that starting from a situation where the guard of event Oi and the invariant are verified, the variable transformation leads to a new value of x where the invariant is still preserved. The B proof mechanism is founded on rule-bases using an inference engine supported by the Atelier B tool. The refinement calculus is used to relate models at varying levels of abstraction by enriching variables and event descriptions while preserving the already proven invariants. We summarize the approach as follows: (M1,G1) refined by (M2,G2) refined by … (Mn,Gn) Mi is the ith model iteration that satisfies the goal Gi and the goals of lower iteration number. The refined by relationship ensures the preservation of goals, but the proof of refinement must be given. This means that if a new model is derived from (Mn, Gn), we should prove that the new model refines the previous model and preserves the new properties. Consider a refinement of the machine shown in Fig.2 given by variable y, invariant J(x,y), event Oi(y) Í Select Qi(y) then Ti(y), where J represents the formal link between the abstract variable x and the refined variable y and some local properties over y. 4. 4.1
physical variables). It means that specification does not differentiate cause (such as input action by human operator) from consequence (such as press movement). As an example, a first situation of the press can be characterised by two system variables: press stopped and no operator’s action. These two variables are observed in a next situation as following: the press is now moving and the two hand command is pushed. Consequently, variables of the first specification level are the following: state1 represent the press abstract state which is considered as stopped1, falling1, rising1; start and emergency model the Boolean operator’s actions. This gives rise to the declaration section of the first B machine: MODEL Press_System 1 SETS STATES1= {stopped1, falling1, rising1}; PIN= {on, off} VARIABLES state1, start, emergency INITIALISATION state1= stopped1 || start = off || emergency = off
Invariant is related to the type of each variable and express also S1 and S2 properties. INVARIANT start ∈ PIN ∧ emergency ∈ PIN ∧ state1 ∈ STATES1 ∧ (state1= rising1 ⇒ emergency= off) ∧ (S1) (state1= falling1 ⇒ start= on ∧ emergency= off) (S2)
The press behaviour is described using three events that define a cyclic sequence: - when the operator pushes the start button, the press is going down, - when the press reaches its bottom point, the movement direction is changing and the press begins to rise, - when the press reaches its top point, it is stopped. EVENTS Starting = Select state1= stopped1 ∧ start= off Then state1:= falling1 || start:= on || emergency:= off End; Direction_shift = Select state1= falling1 Then state1:= rising1 End; Stop_up = Select state1= rising1 Then state1:= stopped1 || start ∈ PIN End;
PRESS SPECIFICATION
After that, comes the specification of degraded behaviour. We begin by the description of abnormal stops. The press is stopped when the start button is relaxed during the falling phase and when the emergency button is pushed whatever the press movement is.
Goal specification
This first model describes an external view of the system behaviour. Each model evolution characterises a before/after transition between two machine situations defined by all the system observable variables (operator’s two hand command,
283
Start_relax_stop = Select state1 = falling1 ∧ start = on Then state1 := stopped1 || start = off End;
EVENTS … Rising_restart = Select state2= rising_stop2 ∧ emergency= on Then state2:= rising2 || start :∈ PIN || emergency:=off End;
Emergency_stop = Select state1= falling1 ∧ emergency= off Then state1:= stopped1 || emergency= on When Then
state1= rising1 ∧ emergency= off state1:= stopped1 || emergency= on
When Then End;
state1= stopped1 ∧ emergency= off state1:= stopped1 || emergency= on
…
END
4.2
Press automated system specification
Next refinement aims at transforming the initial system requirements (Goal) into software/hardware components (Control rules and dynamics) that constrain the behaviour of a physical system according to solicitations from the environment. This is done according to Fusaoka’s predicate and its B formalisation (Pétin et al., 2006) where refinement is used to verify compliance between goal and automated system specifications. The B model Press_System_3 refines Press_System_2 by introducing a clear distinction between events that produces stimuli, events that model the dynamics of the physical part of the press and events that control the behaviour of the press (Fig. 3). The control operations receive stimuli from operator (start and emergency buttons) and from press physical position (top or bottom dead centres) and decide to actuate or not the clutching system (sending pressure to clutch makes move the crankshaft and the tool).
At least, following operations describe restarting conditions after abnormal stop. Two cases have to be taken into account: restarting from stop state to falling phase and restarting from stop to rising phase. Rising_restart = Select state1= stopped1 ∧ emergency= on Then state1:= rising1 || start :∈ PIN || emergency:=off End; Falling_restart = Select state1= stopped1 ∧ start= off ∧ emergency= on Then state1:= falling1 || start= on || emergency:= off End;
These two last events introduce an non deterministic situation due to the possibility of having Falling_restart and Rising_restart guards simultaneously triggered. It can be explained by the fact the movement direction when an abnormal stop occurs is not memorised.
tdc bdc start3 Operator’s Operator’scontrol control
Command Command Emergency3
This justifies the refinement of the first press specification to detail the STATES1 set by adding stopped at the top, stopped when falling and stopped when rising states. This replacement of variable state1 by variable state2 is effective in all clauses of the B machine and provokes guard and event modifications: when a value of state1 is equal to stopped in a guard or in the effect of an event, we have to precise which kind of stop is concerned: top_stopped, falling_stopped or rising_stopped. The link between the variable state1 and its refinement state2 is defined within the invariant in a section called gluing invariant.
pressure Physical Physical part part
Fig. 3. System’s structural decomposition Modelling of environment changes (modification of start and emergency variables) is very simple because they are assumed to be uncontrollable. It means that any operator command may occur whatever the system states are. Operator_actions = Begin start3 :∈ PIN || emergency3 :∈ PIN End;
The press physical system is modelled through B events that describe the crankshaft rotation (α represent crankshaft position and crank is on when crankshaft is clutched) and the sensors associated to top and bottom dead centres (bdc, tdc).
REFINEMENT Press_System_2 REFINES Press_System_1 SETS STATES2 = {falling_stopped2, rising_stopped2, top_stopped2 , falling2, Rising2} VARIABLES start, emergency, state2 INVARIANT …….. ∧ /* gluing invariant */ state2 ∈ {falling_stopped2, rising_stopped2, top_stopped2} ⇔ state1= stopped1 ∧ state2= falling2 ⇔ state1= falling1 ∧ state2= rising2 ⇔ state1= rising1 ∧ …..
Move = If pressure = on Then Else crank := off End;
284
If α = 359 then α:= 0 || crank:=on Else α:= α+1 || crank:=on
-
Dead_centres = if α = 0 then bdc := off || tdc = on else if α = 180 then bdc=on || tdc= off else bdc=off|| tdc=off End;
-
Introducing environment and physical part events modify the guard of control events of press_system_3, in order to include rising and falling edges of the operator’s stimuli. To this end, two memory variables are created: old_emergency3 and old_start3. After each control events, these variables are updated by respectively the emergency3 and start3 values. For example, the guard of starting event requires now the rising edge of start button when the press is stopped as following:
These proof obligations constitute actually the intrinsic invariant properties: - of the control -
state = rising 3 ⇒ pressure = on ∧ 180 ≤α< 359 ⇔ state3∈ {rising3, rising_stopped3}
of the physical subsystems
pressure = on ⇔ crank = on
If the specification of control and process verify these underlying hypotheses, then it proves that the control and physical system events safely behave according to the initial requirements S1 and S2.
Starting = Select state3= top_stopped3 ∧ start3= on ∧ oldstart3= off /* Start rising edge */ Then state3:= falling3 || start3:= on || emergency3:= off || oldemergency3:=emergency3 || oldstart3:=start3 || pressure:= on End;
5.
VERIFICATION ISSUES
A B model is composed of a list of events. Verification of a B model consists in proving that any event preserves the invariant. This is well adapted for describing software operations that always maintain safety invariant properties.
Note that state3 is an internal memory computed by the control system, which is expected to be consistent with the press abstract state2.
However, B model does contain any operation scheduler that could sequence the execution of the B operations. Consequently, if analysis of a safety property is needed at the beginning of the sequence and at the end of the sequence, the concept of B invariant must be handled carefully. This ability to model invariant properties with the concept of action/reaction is very important when modelling reactive systems where B model describes control part and its environment. Indeed, proving invariant within such a machine requires playing a game where control and process operations have successively the token. For example, if we consider an operator’s stimulus, the invariant safety properties S1 and S2 cannot be checked before having observed the associated reaction by control and process subsystems. It means that starting from a situation where S1 and S2 invariants are true, execution of a stimuli operation leads to a temporary situation where S1 and S2 are false until the control and process operations are executed.
This structural decomposition into basic components (control software, user interface, and physical system) guides designer into progressive specification of properties. A gluing invariant links the abstract state2 to the properties of control and physical variables as following: INVARIANT State2 ∈{falling_stopped2, rising_stopped2, top_stopped2} ⇔ crank = off ∧ state3 ∈{falling_stopped3, rising_stopped3, top_stopped3} ∧ state2=falling2 ⇔ crank= on ∧ 0≤α<180 ∧ state3 = falling3 ∧ state2=rising2 ⇔ crank=on ∧ 180≤α<359 ∧ state3 = rising3 ∧…
Safety properties are also projected into all the subcomponent of the press. The term state2 = rising2 of the predicate S1 becomes state3= rising3 (control point of view) and crank = on ∧ 180 ≤α< 359 (physical system point of view). Same rational is applied for predicate S2. It completes the previous invariant by: (state3= rising3) ∧ (crank= on ∧ 180 ≤α< 359) ⇒ emergency3 = off) ∧ (state3 = falling3) ∧ (crank= on ∧ 0 ≤α< 180) ⇒ start= on ∧ emergency = off) ∧…
control system is able to correctly evaluate the physical state of the press using top and bottom dead centres information and to compute an appropriate pressure order, physical system behaviour is compliant with the control stimuli.
The way of modelling proposed to cope with this verification problem is based on the definition of flags that model the operation scheduler. Flags are evaluated by the guard of operations and valued by theirs substitutions in order to define an ordered list of operation. In this case, invariant can be specified true for only a subset of flag value. For reactive system modelling, we propose the set of flag value to be divided into three parts, related to stimuli, control and process operations, noted Fij where i denotes the type of operation (1 for stimuli, 2 for control and 3 for process) and j the number of operation within the sub-lists. The legal sequence of
(S1)
(S2)
Proving this invariant is based on underlying hypotheses that assume:
285
operation execution is composed of three operations: one stimuli operation followed by one control operation and then one process operation. This can be noted as following:
7.
Abrial J.R., Borger E., Langmaack editors (1991). Formal methods for industrial applications : specifying and programming the steam boiler control, Lecture Notes in Computer Science, Springer Verlag. Abrial J.R. (1996). The B Book: Assigning Programs to Meanings. Cambridge Univ. Press Abrial J.R (2005), Case study of a complete reactive system in Event-B: a mechanical press controller, tutorial 3 of ZB’2005, Guildford, UK, 13-15/04/2005 Blaise, J. C., Lhoste, P., Ciccotelli, J.(2003). Formalisation of normative knowledge for safe design. In : Safety Science, 41, 241-261. Clarke E.M., Grunberg O., Peled D.A. (2000) Model Checking. The MIT Press Craigen D., Gerhart S., Ralston T. (1995). Formal methods technology transfer: implements and innovation. Formal Methods by Hinchey M.G., Bowen J.P., pp. 399-419, Prentice Hall International Diallo D., Vailly A., (1998) Paraphrasing of specification written in B, Networking and Information Systems Journal (NISJ), Vol. 1 n°2-3/1998. Feldmann K., Colombo A.W., Schnur C., Stöckel T. (1999). Specification, Design, and Implementation of Logic Controllers based on Coloured Petri Net Models and the Standard IEC 1131. In : IEEE Trans. on Control Systems Technology. Volume 7, N°6. Fusaoka A., Seki H., Takahashi K. (1983). A description and reasoning of plant controllers in temporal logic. International Joint Conference on Artificial Intelligence. pp 405-408. Karlsruhe, 8-12 aug. 1983. Johnson T. L. (2004). Improving automation software dependability: a role for formal methods? In proc. of 11th IFAC/INCOM, Salvador-Bahia, Brazil,4-7/04/04 Laleau R., Pollack F., (2002) Coming and going from UML to B: a proposal to support traceability in rigorous IS development. In Proc of ZB’2002, LNCS vol. 2272, pp 517–534, Grenoble, France. Lamy P., Bello J.P., (2004). Realization of a control software of a mechanical press using B method, in proc. of the 15th International Symposium on Software Reliability Engineering, St Malo, France. Ledang H., (2002). Automatic translation from UML specifications to B, in proceedings of the Int. Workshop on Refinement of Critical Systems: Methods, Tools and Experience, 2nd Conf. on B and Z, 23-25/01/2002, Grenoble, France. Lhote F., Chazelet Ph., Dulmet M. (1999). The extension of principles of cybernetics towards engineering and manufacturing. IFAC Annual Reviews in Control. Volume 23 (1), pp 1-11. Pétin J.F., Morel G., Panetto H., (2006), Formal specification method for systems automation, European Journal of Control, to be published Roussel J.-M., Faure J.-M. (2002). An algebraic approach for PLC programs verification, in proceedings of IFAC WODES'02, Zaragoza, Spain, 24 October, 2002, pp. 303-308. Shell T. (2001) Systems functions implementation and behavioural modelling: system theoretic approach, International Journal of Systems Engineering, 4/1.
Event ij = Select Flag=Fi(j-1) Then If Gij Then Sij || Flag:=F(i+1)1 Else Flag:=Fi(j-1) End; where Gij and Sij denotes respectively the guard and substitution of the operation ij.
In this case, invariant will only be considered when Flag = F10, i.e. when the flag has just been valued by one process operation (sequence stimuli/control reaction/physical effect has been ended). 6.
REFERENCES
CONCLUSION & PROSPECTS
There is a growing interest in methods and tools that facilitate the validation of software-intensive automation systems. This interest is reinforced by the IEC 61508 safety-related standard that strongly recommends the use of formal methods, but without defining how they can be applied. Main contribution of this paper is a system engineering methodology based on the use of the B method to ensure a safer automation by checking a priori proved properties from the earlier phases of specification. Major added value of our approach is related to: - the use of a system engineering rationale based on the Fusaoka’s predicate to identify system safety requirements and to ensure their traceability all along the development process, - the definition of consistent relations between the components safety properties and the way they are aggregated to satisfy the system properties, - the extension of B modelling to cope with the verification of tightly coupled hardware and software components in system engineering. Although these interdisciplinary experiences between computer and automation sciences demonstrate that the proposed approach may allow one to verify the highest levels of safety integrity of automation systems, the lab-scale case study emphasizes the efforts which should still be deployed in order to make the proposed engineering framework effective in practice. An important limitation for the acceptance of the proposed approach into a wellestablished automation engineering process is the mathematically oriented notation of the B language. A means of bridging this gap at the specification level is to propose equivalent representations of a B specification using more accepted formalisms. To this end, translations of UML diagrams into B machines have been proposed (Ledang, 2002)(Laleau and Pollack, 2002), as well as paraphrasing of the B model into a natural language text to facilitate its understanding (Diallo and Vailly, 98).
286
FORMAL SPECIFICATION OF SAFE MANUFACTURING MACHINES USING THE B METHOD: APPLICATION TO A MECHANICAL PRESS Dominique EVROT1+3, Jean-François PETIN1, Dominique MERY2 (1) Université Henri Poincaré, CRAN, UMR 7039 CNRS-INPL-UHP (2) Université Henri Poincaré, LORIA, UMR 7503 CNRS-INPL-UHP-INRIA-Nancy II Campus Scientifique, BP 239, 54506 Vandoeuvre lès Nancy {dominique.evrot}{jean-francois.petin}@cran.uhp-nancy.fr, [email protected] (3) INRS, BP 27 54501 Vandoeuvre lès Nancy cedex
Abstract: This paper deals with the development of manufacturing machinery subjected to strong dependability and safety properties. In this context, IEC 61508 standard recommends the use of formal methods to control the complexity of software intensive applications. This paper focuses on model refinement to ensure safety requirements traceability. A mechanical press case study illustrates a way to bridge the gap for using the B method within such an automation-oriented context. Copyright © 2006 IFAC Keywords: Formal specification, safety analysis, requirements refinement, machinery control design
1.
INTRODUCTION
In this context, INRS is waging a study about the conceptual and practical approaches related to safety/reliability, computer sciences and automatic control. More precisely, verification using model checking (Clarke et al, 2000)(Craigen et al, 1995)(Feldman et al, 1999) or theorem proving (Abrial et al, 1991)(Roussel and Faure, 2002) have been tackled. However, in spite of the consensus that early phases of a system definition are the most important ones to ensure that the system will satisfy the user’s requirements, most of these models and tools address the design and implementation phases. Over these later stages, many systems engineering and automation engineering practitioners (Shell, 2001)(Johnson, 2004) are considering that time is ripe to formalise the earlier stages of specification. This means providing a set of guidelines, generic constructs, and formal verification tools to establish a non-ambiguous, correct, consistent and complete model of understanding of what a system has to do according to the users’ requirements before designing its behaviour according to the multiple engineers’ practices and techniques (Lhote et al, 1999).
Manufacturing machines are increasingly being equipped with programmable logic controllers (PLCs) which ensure not only their strictly functional part but also operator safety functions. They have long been ensured by electromechanical technology, the application of which is relatively well mastered both from the design and production points of view. Integration of safety functions into the software parts of programmable systems can be envisaged only if the safety level of “PLC and software” set is at least equal to the electromechanical circuit’s one. One role of Institut National de Recherche et de Sécurité (INRS) in France is to study methods for the development of safety machines and to deliver safety certification for some equipments (presses, wood machines and electro-sensitive protective devices) listed in the annex IV of the machinery directive (Blaise et al., 2003). It could be based on normative recommendations such as the IEC 61508 standard defining four Safety Integrity Levels (SILs) according to an estimation of the risk for the operator, the probability of failure of each component, and the method used to develop the system. In particular, the higher level SIL 4 recommends the use of formal methods to control the quality of software intensive applications.
Among candidate formalisms, INRS has studied on the B method (Abrial, 1996) and ordered a case study development using this method1 (Lamy and Bello, 1
281
Atelier B is a product of ClearSy, http://www.clearsy.com.
2004)(Abrial et al, 2005). This study has clearly shown the benefit of using B for proved code generation. Nevertheless, applying this approach within an industrial automation engineering framework requires the definition of a system formal engineering rationale: - to better detail how the safety requirements are taken into account all along the development process and to ensure their traceability, - to enlarge software engineering to system engineering including software, hardware, manmachine interface and physical systems as required by automation projects.
when in up position. Moreover, if the operator releases the hand command during the falling phase, or if emergency stop occurs, the press is stopped. Mechanical press environment
O p e r a t i n g S y s t e m
This paper presents a mechanical press case study that illustrates a way to bridge the gap for using the B method within an automation-oriented context. Our proposal is based on: - a refinement mechanism that is rather used to progressively detail abstract safety properties into more concrete ones related to each subsystems than to only simplify proof tasks, - the Fusaoka’s automation assertion (Fusaoka et al, 1983), which postulates that the design of automation systems consists in defining the control rules of the dynamics of a physical system, starting from the behavioural goals to be met: Control Rules ∧ Dynamics ⊃ Goal (1). Note that this decomposition is close to the structure of a machine given by ISO 121002 in terms of control and operative parts.
Motor steering wheel
Mobile Disc Springs
C o n t r o l S y s t e m
Crankshaft
Clutching-braking system
Mechanical press system
Fig. 1. Mechanical press case study Two main safety properties have to be guaranteed in this operating mode: - S1: falling movement is enabled if and only if operator’s hands are on the two hands command and emergency stop is not engaged. - S2: rising movement is enabled if and only if the emergency stop is not engaged. Note that in rising movement, no constraint about the two hands command is required. This set of mode specification and safety properties is the foundation of the B first formalisation.
The two first sections introduce respectively the mechanical press case study and the B formalism. Third section details the refinement mechanism based on the Fusaoka’s assertion. Fourth section discusses about the verification issues due to the properties decomposition introduced by our modelling framework. Last section gives some conclusions and prospects. 2.
Clutch side Brake side
3.
THE B METHOD
Introduced by Abrial, the B Method is a formal method for the specification, design, and implementation of software/system applications that supports invariance and safety properties proofs. The B language is based on: - set theory with classical set operators (S U T, S I T, S c T, x e S, #S), function and relationship (A j B Í P A x B); - first order logic with classical operators of a 2valued proposal logic (! P, P v Q, P ¶ Q, P fi Q, P ¤ Q) and quantifiers (A X • p, E X • p).
MECHANICAL PRESS CASE STUDY
In this paper, we consider a mechanical press that aims at stamping metal products with a tool in vertical movement. A crankshaft equipped with two sensors for top and bottom dead centres gives this vertical movement. A clutch, which is actuated by a pneumatic valve, ensures the transmission between motor and crankshaft. Operator protection is supplied thanks to a two hands command. An emergency stop enable or not the stamping action.
A B model is defined by the structure shown in Fig 2. MODEL m SETS s CONSTANTS c PROPERTIES p VARIABLES x INVARIANT I(x) INITIALISATION init(x) EVENTS O1= Select P1(x) Then S1(x) … On = Select Pn(x) Then Sn(x) END
We focus on the press function that is in charge of clutching and braking the press motor in the normal operating mode (motor is considered as always working). In this mode, the press is initially stopped in up position and waits for a two hands command. Then, the tool is falling until the bottom dead centre is reached, then is rising back, and finally stopped
Fig. 2. B formal model
2
ISO 12100, Safety of machinery – basic concept, general principles for design, January 2004
282
A model has a name m; the clause SETS contains definitions of sets of the problem; the clause CONSTANTS allows the designer to introduce information related to the mathematical structure of the problem to be solved; and the clause PROPERTIES contains the effective definitions of the constants. The second section of the model defines the dynamic aspects of the state variables and properties of variables using the invariant. Events O1…On are used to describe state variable modifications due to generalized substitutions; Si(x) contains the new value of variable x after the occurrence of Oi. The substitution of a variable is feasible with respect to its guard. The invariant I(x) states that variable x is always in a given set of possible values, which is assumed to be initialized with respect to the initial conditions and which is preserved by any event of the list of events. Conditions of verification, called proof obligations are generated from the text of the model, and they express underlying hypotheses required for the preservation of invariant properties: (INV1) Init(x) fi I(x) (INV2) I(x) ¶ P(x) fi I( S(x)) (INV1) states the initial condition that should establish the invariant. (INV2) should be checked for every event Oi of the model; it states that starting from a situation where the guard of event Oi and the invariant are verified, the variable transformation leads to a new value of x where the invariant is still preserved. The B proof mechanism is founded on rule-bases using an inference engine supported by the Atelier B tool. The refinement calculus is used to relate models at varying levels of abstraction by enriching variables and event descriptions while preserving the already proven invariants. We summarize the approach as follows: (M1,G1) refined by (M2,G2) refined by … (Mn,Gn) Mi is the ith model iteration that satisfies the goal Gi and the goals of lower iteration number. The refined by relationship ensures the preservation of goals, but the proof of refinement must be given. This means that if a new model is derived from (Mn, Gn), we should prove that the new model refines the previous model and preserves the new properties. Consider a refinement of the machine shown in Fig.2 given by variable y, invariant J(x,y), event Oi(y) Í Select Qi(y) then Ti(y), where J represents the formal link between the abstract variable x and the refined variable y and some local properties over y. 4. 4.1
physical variables). It means that specification does not differentiate cause (such as input action by human operator) from consequence (such as press movement). As an example, a first situation of the press can be characterised by two system variables: press stopped and no operator’s action. These two variables are observed in a next situation as following: the press is now moving and the two hand command is pushed. Consequently, variables of the first specification level are the following: state1 represent the press abstract state which is considered as stopped1, falling1, rising1; start and emergency model the Boolean operator’s actions. This gives rise to the declaration section of the first B machine: MODEL Press_System 1 SETS STATES1= {stopped1, falling1, rising1}; PIN= {on, off} VARIABLES state1, start, emergency INITIALISATION state1= stopped1 || start = off || emergency = off
Invariant is related to the type of each variable and express also S1 and S2 properties. INVARIANT start ∈ PIN ∧ emergency ∈ PIN ∧ state1 ∈ STATES1 ∧ (state1= rising1 ⇒ emergency= off) ∧ (S1) (state1= falling1 ⇒ start= on ∧ emergency= off) (S2)
The press behaviour is described using three events that define a cyclic sequence: - when the operator pushes the start button, the press is going down, - when the press reaches its bottom point, the movement direction is changing and the press begins to rise, - when the press reaches its top point, it is stopped. EVENTS Starting = Select state1= stopped1 ∧ start= off Then state1:= falling1 || start:= on || emergency:= off End; Direction_shift = Select state1= falling1 Then state1:= rising1 End; Stop_up = Select state1= rising1 Then state1:= stopped1 || start ∈ PIN End;
PRESS SPECIFICATION
After that, comes the specification of degraded behaviour. We begin by the description of abnormal stops. The press is stopped when the start button is relaxed during the falling phase and when the emergency button is pushed whatever the press movement is.
Goal specification
This first model describes an external view of the system behaviour. Each model evolution characterises a before/after transition between two machine situations defined by all the system observable variables (operator’s two hand command,
283
Start_relax_stop = Select state1 = falling1 ∧ start = on Then state1 := stopped1 || start = off End;
EVENTS … Rising_restart = Select state2= rising_stop2 ∧ emergency= on Then state2:= rising2 || start :∈ PIN || emergency:=off End;
Emergency_stop = Select state1= falling1 ∧ emergency= off Then state1:= stopped1 || emergency= on When Then
state1= rising1 ∧ emergency= off state1:= stopped1 || emergency= on
When Then End;
state1= stopped1 ∧ emergency= off state1:= stopped1 || emergency= on
…
END
4.2
Press automated system specification
Next refinement aims at transforming the initial system requirements (Goal) into software/hardware components (Control rules and dynamics) that constrain the behaviour of a physical system according to solicitations from the environment. This is done according to Fusaoka’s predicate and its B formalisation (Pétin et al., 2006) where refinement is used to verify compliance between goal and automated system specifications. The B model Press_System_3 refines Press_System_2 by introducing a clear distinction between events that produces stimuli, events that model the dynamics of the physical part of the press and events that control the behaviour of the press (Fig. 3). The control operations receive stimuli from operator (start and emergency buttons) and from press physical position (top or bottom dead centres) and decide to actuate or not the clutching system (sending pressure to clutch makes move the crankshaft and the tool).
At least, following operations describe restarting conditions after abnormal stop. Two cases have to be taken into account: restarting from stop state to falling phase and restarting from stop to rising phase. Rising_restart = Select state1= stopped1 ∧ emergency= on Then state1:= rising1 || start :∈ PIN || emergency:=off End; Falling_restart = Select state1= stopped1 ∧ start= off ∧ emergency= on Then state1:= falling1 || start= on || emergency:= off End;
These two last events introduce an non deterministic situation due to the possibility of having Falling_restart and Rising_restart guards simultaneously triggered. It can be explained by the fact the movement direction when an abnormal stop occurs is not memorised.
tdc bdc start3 Operator’s Operator’scontrol control
Command Command Emergency3
This justifies the refinement of the first press specification to detail the STATES1 set by adding stopped at the top, stopped when falling and stopped when rising states. This replacement of variable state1 by variable state2 is effective in all clauses of the B machine and provokes guard and event modifications: when a value of state1 is equal to stopped in a guard or in the effect of an event, we have to precise which kind of stop is concerned: top_stopped, falling_stopped or rising_stopped. The link between the variable state1 and its refinement state2 is defined within the invariant in a section called gluing invariant.
pressure Physical Physical part part
Fig. 3. System’s structural decomposition Modelling of environment changes (modification of start and emergency variables) is very simple because they are assumed to be uncontrollable. It means that any operator command may occur whatever the system states are. Operator_actions = Begin start3 :∈ PIN || emergency3 :∈ PIN End;
The press physical system is modelled through B events that describe the crankshaft rotation (α represent crankshaft position and crank is on when crankshaft is clutched) and the sensors associated to top and bottom dead centres (bdc, tdc).
REFINEMENT Press_System_2 REFINES Press_System_1 SETS STATES2 = {falling_stopped2, rising_stopped2, top_stopped2 , falling2, Rising2} VARIABLES start, emergency, state2 INVARIANT …….. ∧ /* gluing invariant */ state2 ∈ {falling_stopped2, rising_stopped2, top_stopped2} ⇔ state1= stopped1 ∧ state2= falling2 ⇔ state1= falling1 ∧ state2= rising2 ⇔ state1= rising1 ∧ …..
Move = If pressure = on Then Else crank := off End;
284
If α = 359 then α:= 0 || crank:=on Else α:= α+1 || crank:=on
-
Dead_centres = if α = 0 then bdc := off || tdc = on else if α = 180 then bdc=on || tdc= off else bdc=off|| tdc=off End;
-
Introducing environment and physical part events modify the guard of control events of press_system_3, in order to include rising and falling edges of the operator’s stimuli. To this end, two memory variables are created: old_emergency3 and old_start3. After each control events, these variables are updated by respectively the emergency3 and start3 values. For example, the guard of starting event requires now the rising edge of start button when the press is stopped as following:
These proof obligations constitute actually the intrinsic invariant properties: - of the control -
state = rising 3 ⇒ pressure = on ∧ 180 ≤α< 359 ⇔ state3∈ {rising3, rising_stopped3}
of the physical subsystems
pressure = on ⇔ crank = on
If the specification of control and process verify these underlying hypotheses, then it proves that the control and physical system events safely behave according to the initial requirements S1 and S2.
Starting = Select state3= top_stopped3 ∧ start3= on ∧ oldstart3= off /* Start rising edge */ Then state3:= falling3 || start3:= on || emergency3:= off || oldemergency3:=emergency3 || oldstart3:=start3 || pressure:= on End;
5.
VERIFICATION ISSUES
A B model is composed of a list of events. Verification of a B model consists in proving that any event preserves the invariant. This is well adapted for describing software operations that always maintain safety invariant properties.
Note that state3 is an internal memory computed by the control system, which is expected to be consistent with the press abstract state2.
However, B model does contain any operation scheduler that could sequence the execution of the B operations. Consequently, if analysis of a safety property is needed at the beginning of the sequence and at the end of the sequence, the concept of B invariant must be handled carefully. This ability to model invariant properties with the concept of action/reaction is very important when modelling reactive systems where B model describes control part and its environment. Indeed, proving invariant within such a machine requires playing a game where control and process operations have successively the token. For example, if we consider an operator’s stimulus, the invariant safety properties S1 and S2 cannot be checked before having observed the associated reaction by control and process subsystems. It means that starting from a situation where S1 and S2 invariants are true, execution of a stimuli operation leads to a temporary situation where S1 and S2 are false until the control and process operations are executed.
This structural decomposition into basic components (control software, user interface, and physical system) guides designer into progressive specification of properties. A gluing invariant links the abstract state2 to the properties of control and physical variables as following: INVARIANT State2 ∈{falling_stopped2, rising_stopped2, top_stopped2} ⇔ crank = off ∧ state3 ∈{falling_stopped3, rising_stopped3, top_stopped3} ∧ state2=falling2 ⇔ crank= on ∧ 0≤α<180 ∧ state3 = falling3 ∧ state2=rising2 ⇔ crank=on ∧ 180≤α<359 ∧ state3 = rising3 ∧…
Safety properties are also projected into all the subcomponent of the press. The term state2 = rising2 of the predicate S1 becomes state3= rising3 (control point of view) and crank = on ∧ 180 ≤α< 359 (physical system point of view). Same rational is applied for predicate S2. It completes the previous invariant by: (state3= rising3) ∧ (crank= on ∧ 180 ≤α< 359) ⇒ emergency3 = off) ∧ (state3 = falling3) ∧ (crank= on ∧ 0 ≤α< 180) ⇒ start= on ∧ emergency = off) ∧…
control system is able to correctly evaluate the physical state of the press using top and bottom dead centres information and to compute an appropriate pressure order, physical system behaviour is compliant with the control stimuli.
The way of modelling proposed to cope with this verification problem is based on the definition of flags that model the operation scheduler. Flags are evaluated by the guard of operations and valued by theirs substitutions in order to define an ordered list of operation. In this case, invariant can be specified true for only a subset of flag value. For reactive system modelling, we propose the set of flag value to be divided into three parts, related to stimuli, control and process operations, noted Fij where i denotes the type of operation (1 for stimuli, 2 for control and 3 for process) and j the number of operation within the sub-lists. The legal sequence of
(S1)
(S2)
Proving this invariant is based on underlying hypotheses that assume:
285
operation execution is composed of three operations: one stimuli operation followed by one control operation and then one process operation. This can be noted as following:
7.
Abrial J.R., Borger E., Langmaack editors (1991). Formal methods for industrial applications : specifying and programming the steam boiler control, Lecture Notes in Computer Science, Springer Verlag. Abrial J.R. (1996). The B Book: Assigning Programs to Meanings. Cambridge Univ. Press Abrial J.R (2005), Case study of a complete reactive system in Event-B: a mechanical press controller, tutorial 3 of ZB’2005, Guildford, UK, 13-15/04/2005 Blaise, J. C., Lhoste, P., Ciccotelli, J.(2003). Formalisation of normative knowledge for safe design. In : Safety Science, 41, 241-261. Clarke E.M., Grunberg O., Peled D.A. (2000) Model Checking. The MIT Press Craigen D., Gerhart S., Ralston T. (1995). Formal methods technology transfer: implements and innovation. Formal Methods by Hinchey M.G., Bowen J.P., pp. 399-419, Prentice Hall International Diallo D., Vailly A., (1998) Paraphrasing of specification written in B, Networking and Information Systems Journal (NISJ), Vol. 1 n°2-3/1998. Feldmann K., Colombo A.W., Schnur C., Stöckel T. (1999). Specification, Design, and Implementation of Logic Controllers based on Coloured Petri Net Models and the Standard IEC 1131. In : IEEE Trans. on Control Systems Technology. Volume 7, N°6. Fusaoka A., Seki H., Takahashi K. (1983). A description and reasoning of plant controllers in temporal logic. International Joint Conference on Artificial Intelligence. pp 405-408. Karlsruhe, 8-12 aug. 1983. Johnson T. L. (2004). Improving automation software dependability: a role for formal methods? In proc. of 11th IFAC/INCOM, Salvador-Bahia, Brazil,4-7/04/04 Laleau R., Pollack F., (2002) Coming and going from UML to B: a proposal to support traceability in rigorous IS development. In Proc of ZB’2002, LNCS vol. 2272, pp 517–534, Grenoble, France. Lamy P., Bello J.P., (2004). Realization of a control software of a mechanical press using B method, in proc. of the 15th International Symposium on Software Reliability Engineering, St Malo, France. Ledang H., (2002). Automatic translation from UML specifications to B, in proceedings of the Int. Workshop on Refinement of Critical Systems: Methods, Tools and Experience, 2nd Conf. on B and Z, 23-25/01/2002, Grenoble, France. Lhote F., Chazelet Ph., Dulmet M. (1999). The extension of principles of cybernetics towards engineering and manufacturing. IFAC Annual Reviews in Control. Volume 23 (1), pp 1-11. Pétin J.F., Morel G., Panetto H., (2006), Formal specification method for systems automation, European Journal of Control, to be published Roussel J.-M., Faure J.-M. (2002). An algebraic approach for PLC programs verification, in proceedings of IFAC WODES'02, Zaragoza, Spain, 24 October, 2002, pp. 303-308. Shell T. (2001) Systems functions implementation and behavioural modelling: system theoretic approach, International Journal of Systems Engineering, 4/1.
Event ij = Select Flag=Fi(j-1) Then If Gij Then Sij || Flag:=F(i+1)1 Else Flag:=Fi(j-1) End; where Gij and Sij denotes respectively the guard and substitution of the operation ij.
In this case, invariant will only be considered when Flag = F10, i.e. when the flag has just been valued by one process operation (sequence stimuli/control reaction/physical effect has been ended). 6.
REFERENCES
CONCLUSION & PROSPECTS
There is a growing interest in methods and tools that facilitate the validation of software-intensive automation systems. This interest is reinforced by the IEC 61508 safety-related standard that strongly recommends the use of formal methods, but without defining how they can be applied. Main contribution of this paper is a system engineering methodology based on the use of the B method to ensure a safer automation by checking a priori proved properties from the earlier phases of specification. Major added value of our approach is related to: - the use of a system engineering rationale based on the Fusaoka’s predicate to identify system safety requirements and to ensure their traceability all along the development process, - the definition of consistent relations between the components safety properties and the way they are aggregated to satisfy the system properties, - the extension of B modelling to cope with the verification of tightly coupled hardware and software components in system engineering. Although these interdisciplinary experiences between computer and automation sciences demonstrate that the proposed approach may allow one to verify the highest levels of safety integrity of automation systems, the lab-scale case study emphasizes the efforts which should still be deployed in order to make the proposed engineering framework effective in practice. An important limitation for the acceptance of the proposed approach into a wellestablished automation engineering process is the mathematically oriented notation of the B language. A means of bridging this gap at the specification level is to propose equivalent representations of a B specification using more accepted formalisms. To this end, translations of UML diagrams into B machines have been proposed (Ledang, 2002)(Laleau and Pollack, 2002), as well as paraphrasing of the B model into a natural language text to facilitate its understanding (Diallo and Vailly, 98).
286