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, dominique.mery@loria.fr
(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

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.
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).
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
Atelier B is a product of ClearSy, http://www.clearsy.com.

281
2004)(Abrial et al, 2005). This study has clearly when in up position. Moreover, if the operator
shown the benefit of using B for proved code releases the hand command during the falling phase,
generation. Nevertheless, applying this approach or if emergency stop occurs, the press is stopped.
within an industrial automation engineering
framework requires the definition of a system formal Mechanical press environment
engineering rationale:
- to better detail how the safety requirements are O
p
taken into account all along the development e Clutch side
Motor
C
o
r
process and to ensure their traceability, a Brake side steering wheel n
t
t
- to enlarge software engineering to system i Mobile
Disc
r
o
engineering including software, hardware, man- n
g
l

machine interface and physical systems as S

Springs S
y
required by automation projects. y
s Crankshaft
s
t
t
e
e
This paper presents a mechanical press case study m
m

that illustrates a way to bridge the gap for using the B Clutching-braking system

method within an automation-oriented context. Our Mechanical press system

proposal is based on: Fig. 1. Mechanical press case study

- a refinement mechanism that is rather used to
progressively detail abstract safety properties Two main safety properties have to be guaranteed in
into more concrete ones related to each sub- this operating mode:
systems than to only simplify proof tasks, - S1: falling movement is enabled if and only if
- the Fusaoka’s automation assertion (Fusaoka et operator’s hands are on the two hands command
al, 1983), which postulates that the design of and emergency stop is not engaged.
automation systems consists in defining the - S2: rising movement is enabled if and only if the
control rules of the dynamics of a physical emergency stop is not engaged.
system, starting from the behavioural goals to be Note that in rising movement, no constraint about the
met: Control Rules ∧ Dynamics ⊃ Goal (1). two hands command is required.
Note that this decomposition is close to the
structure of a machine given by ISO 121002 in This set of mode specification and safety properties
terms of control and operative parts. is the foundation of the B first formalisation.
The two first sections introduce respectively the 3. THE B METHOD
mechanical press case study and the B formalism.
Third section details the refinement mechanism Introduced by Abrial, the B Method is a formal
based on the Fusaoka’s assertion. Fourth section method for the specification, design, and
discusses about the verification issues due to the implementation of software/system applications that
properties decomposition introduced by our supports invariance and safety properties proofs. The
modelling framework. Last section gives some B language is based on:
conclusions and prospects. - set theory with classical set operators (S U T, S
I T, S c T, x e S, #S), function and relationship
2. MECHANICAL PRESS CASE STUDY
(A j B Í P A x B);
In this paper, we consider a mechanical press that - first order logic with classical operators of a 2-
aims at stamping metal products with a tool in valued proposal logic (! P, P v Q, P ¶ Q, P fi
vertical movement. A crankshaft equipped with two Q, P ¤ Q) and quantifiers (A X • p, E X • p).
sensors for top and bottom dead centres gives this
vertical movement. A clutch, which is actuated by a A B model is defined by the structure shown in Fig 2.
pneumatic valve, ensures the transmission between
motor and crankshaft. Operator protection is supplied MODEL m
thanks to a two hands command. An emergency stop SETS s
enable or not the stamping action. CONSTANTS c
PROPERTIES p
We focus on the press function that is in charge of VARIABLES x
clutching and braking the press motor in the normal INVARIANT I(x)
operating mode (motor is considered as always INITIALISATION init(x)
working). In this mode, the press is initially stopped EVENTS
O1= Select P1(x) Then S1(x)
in up position and waits for a two hands command. …
Then, the tool is falling until the bottom dead centre On = Select Pn(x) Then Sn(x)
is reached, then is rising back, and finally stopped END

2 Fig. 2. B formal model

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. PRESS SPECIFICATION
4.1 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
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;
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.
Start_relax_stop = EVENTS
Select state1 = falling1 ∧ start = on …
Rising_restart =
Then state1 := stopped1 || start = off
Select state2= rising_stop2 ∧ emergency= on
End;
Then state2:= rising2 || start :∈ PIN || emergency:=off
End;
Emergency_stop = …
Select state1= falling1 ∧ emergency= off END
Then state1:= stopped1 || emergency= on
When state1= rising1 ∧ emergency= off 4.2 Press automated system specification
Then state1:= stopped1 || emergency= on
Next refinement aims at transforming the initial
When state1= stopped1 ∧ emergency= off system requirements (Goal) into software/hardware
Then state1:= stopped1 || emergency= on components (Control rules and dynamics) that
End; constrain the behaviour of a physical system
according to solicitations from the environment. This
At least, following operations describe restarting is done according to Fusaoka’s predicate and its B
conditions after abnormal stop. Two cases have to be formalisation (Pétin et al., 2006) where refinement is
taken into account: restarting from stop state to used to verify compliance between goal and
falling phase and restarting from stop to rising phase. automated system specifications.
Rising_restart = The B model Press_System_3 refines
Select state1= stopped1 ∧ emergency= on Press_System_2 by introducing a clear distinction
Then state1:= rising1 || start :∈ PIN || emergency:=off between events that produces stimuli, events that
End; model the dynamics of the physical part of the press
and events that control the behaviour of the press
Falling_restart = (Fig. 3). The control operations receive stimuli from
Select state1= stopped1 ∧ start= off ∧ emergency= on operator (start and emergency buttons) and from
Then state1:= falling1 || start= on || emergency:= off press physical position (top or bottom dead centres)
End; and decide to actuate or not the clutching system
(sending pressure to clutch makes move the
These two last events introduce an non deterministic crankshaft and the tool).
situation due to the possibility of having tdc
Falling_restart and Rising_restart guards bdc
simultaneously triggered. It can be explained by the
fact the movement direction when an abnormal stop start3
occurs is not memorised. pressure Physical
Physical
Operator’s
Operator’scontrol
control Command
Command part
part
This justifies the refinement of the first press Emergency3
specification to detail the STATES1 set by adding
stopped at the top, stopped when falling and stopped Fig. 3. System’s structural decomposition
when rising states. This replacement of variable
state1 by variable state2 is effective in all clauses of Modelling of environment changes (modification of
the B machine and provokes guard and event start and emergency variables) is very simple
modifications: when a value of state1 is equal to because they are assumed to be uncontrollable. It
stopped in a guard or in the effect of an event, we means that any operator command may occur
have to precise which kind of stop is concerned: whatever the system states are.
top_stopped, falling_stopped or rising_stopped. The
link between the variable state1 and its refinement Operator_actions =
state2 is defined within the invariant in a section Begin start3 :∈ PIN || emergency3 :∈ PIN
called gluing invariant. End;

REFINEMENT Press_System_2 The press physical system is modelled through B

REFINES Press_System_1 events that describe the crankshaft rotation
SETS STATES2 = {falling_stopped2, rising_stopped2, (α represent crankshaft position and crank is on
top_stopped2 , falling2, Rising2} when crankshaft is clutched) and the sensors
VARIABLES start, emergency, state2 associated to top and bottom dead centres (bdc, tdc).
INVARIANT
…….. ∧ Move =
/* gluing invariant */ If pressure = on
state2 ∈ {falling_stopped2, rising_stopped2, top_stopped2} Then
⇔ state1= stopped1 ∧ If α = 359 then α:= 0 || crank:=on
state2= falling2 ⇔ state1= falling1 ∧ Else α:= α+1 || crank:=on
state2= rising2 ⇔ state1= rising1 ∧ Else crank := off
….. End;

284
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:
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;
Note that state3 is an internal memory computed by
the control system, which is expected to be consistent
with the press abstract state2.
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}
∧ control and process operations have successively the
state2=falling2 ⇔ crank= on ∧ 0≤α<180 ∧ state3 = falling3
∧ stimulus, the invariant safety properties S1 and S2
state2=rising2 ⇔ crank=on ∧ 180≤α<359 ∧ state3 = rising3
∧…
Safety properties are also projected into all the sub-
component 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) ∧ (S1)
(state3 = falling3) ∧ (crank= on ∧ 0 ≤α< 180) ⇒
start= on ∧ emergency = off)
∧… (S2)
Proving this invariant is based on underlying
hypotheses that assume:
285
- 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.
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.
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.
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
token. For example, if we consider an operator’s
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.
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
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:
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. 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 well-
established 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
7. REFERENCES
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, 2-
4 October, 2002, pp. 303-308.
Shell T. (2001) Systems functions implementation and
behavioural modelling: system theoretic approach,
International Journal of Systems Engineering, 4/1.