Supervisory Control (4CM30) · 3/24/2017 · Philosophy of mCRL2 I process algebra, which are algebraic formalisms for compositional speci cation of concurrent systems I extends

Supervisory Control (4CM30)Verification of supervisors

Michel Reniers

[email protected]

2016-2017

mailto:[email protected]

Properties of supervisors

I controlled system satisfies requirements used for synthesis

I many properties that are hard too express in terms ofrequirements for synthesis or for which this is even impossibleDining philosophers:

I each philosopher should be able to eat once in a whileI can we use marked states?I can we provide a requirement that achieves progress?I manually develop a supervisor that guarantees progress and

subsequently call it a supervisorI a requirement that states that philosophers eat alternatingly

I modelling of a requirement is not straightforward

I check whether or not the requirement model achieves theintended purpose

I useful to establish whether the controlled system really hasthe properties that are desired

Model checking

mCRL2

I mCRL2: micro Common Representation Language 2

I language to specify & analyse behaviour of distributed systems

I extensive theory is available for verifying processes manually

I major part of this theory has been implemented in theaccompanying tool set, allowing automatic analysis andverification of systems

Philosophy of mCRL2

I process algebra, which are algebraic formalisms forcompositional specification of concurrent systems

I extends algebra of communicating processes (ACP) with data,time, and multi-actions

I a fundamental concept in mCRL2 is the process. Processescan perform actions and can be composed to form newprocesses using algebraic operators. A system usually consistsof several processes (or components) in parallel.

I process carries data as its parameters.

I state of a process is a specific combination of parameter values

I state influences the possible next actions

I execution of an action may result in a state change

I central notion in mCRL2 is the linear process: a process fromwhich all parallelism has been removed to produce a series ofcondition - action - effect rules

I complex systems, consisting of hundreds or even thousands ofprocesses, can be translated to a single linear process

I linear process is finite and can often be obtained very easily

I tools in the mCRL2 toolset operate on linear processes ratherthan on state spaces

I specified behavior can then be simulated, visualized or verifiedagainst its requirements

I requirements are defined by using a rich logic, namely themodal mu-calculus with data and time

I an extensive tool set has been developed for mCRL2

I download from www.mcrl2.org

www.mcrl2.org

I central notion in mCRL2 is the linear process: a process fromwhich all parallelism has been removed to produce a series ofcondition - action - effect rules

I complex systems, consisting of hundreds or even thousands ofprocesses, can be translated to a single linear process

I linear process is finite and can often be obtained very easily

I tools in the mCRL2 toolset operate on linear processes ratherthan on state spaces

I specified behavior can then be simulated, visualized or verifiedagainst its requirements

I requirements are defined by using a rich logic, namely themodal mu-calculus with data and time

I an extensive tool set has been developed for mCRL2

I download from www.mcrl2.org

www.mcrl2.org

Toolset overview

Further reading ...

I S. Cranen, J.F. Groote, J.J.A. Keiren, F.P.M.Stappers, E.P. de Vink, J. W. Wesselink, T.A.C.Willemse. An Overview of the mCRL2 Toolsetand Its Recent Advances. TACAS 2013, pages199-213.

I J.F. Groote, A. Mathijssen, M.A. Reniers, Y.S.Usenko, M.J. van Weerdenburg. Analysis ofdistributed systems with mCRL2. In M.Alexander, W. Gardner (Eds.), Process Algebrafor Parallel and Distributed Processing, pages99-128. Chapman and Hall, 2008

I J.F. Groote and M.A. Reniers. Algebraic processverification. In J. A. Bergstra, A. Ponse and S. A.Smolka. Handbook of Process Algebra, pages1151-1208, Elsevier, Amsterdam, 2001.

http://mcrl2.org/web/user_manual/publications.html

http://mcrl2.org/web/user_manual/publications.html

From CIF to mCRL2

I CIF models need to be transformed into mCRL2 models thatexpress the “same” behaviour

I transformation is discussed and illustrated by means ofexamples

I single automaton without variables

I network of automata without variables

I single automaton with variable

I network of automata with variables

Single CIF automaton without variables

CIF model for lock picking:

1 event zero , one , open , alarm;

23 automaton lock_picking:

4 location L0:

5 initial

6 edge zero , one goto L1;

7 location L1:


9 location L2:

10 edge zero goto zero_on_three;

11 edge one goto one_on_three;

12 location zero_on_three:

13 edge zero goto open_door;

14 edge one goto alarm_state;

15 location one_on_three:

16 edge zero goto alarm_state;

17 edge one goto open_door;

18 location open_door:

19 edge open goto L0;

20 location alarm_state:

21 edge alarm goto L0;

22 end

mCRL2 version1 sort LocSort_lock_picking = struct loc_lock_picking_L0 | loc_lock_picking_L1 |

loc_lock_picking_L2 | loc_lock_picking_zero_on_three |

loc_lock_picking_one_on_three | loc_lock_picking_open_door |

loc_lock_picking_alarm_state;

23 proc BehProc_lock_picking(Locvar_lock_picking : LocSort_lock_picking) =

4 (Locvar_lock_picking == loc_lock_picking_L0) -> zero . BehProc_lock_picking(

loc_lock_picking_L1) +

5 (Locvar_lock_picking == loc_lock_picking_L0) -> one . BehProc_lock_picking(







loc_lock_picking_zero_on_three) +


loc_lock_picking_one_on_three) +

10 (Locvar_lock_picking == loc_lock_picking_zero_on_three) -> zero .

BehProc_lock_picking(loc_lock_picking_open_door) +

11 (Locvar_lock_picking == loc_lock_picking_zero_on_three) -> one .

BehProc_lock_picking(loc_lock_picking_alarm_state) +

12 (Locvar_lock_picking == loc_lock_picking_one_on_three) -> zero .

BehProc_lock_picking(loc_lock_picking_alarm_state) +

13 (Locvar_lock_picking == loc_lock_picking_one_on_three) -> one .

BehProc_lock_picking(loc_lock_picking_open_door) +

14 (Locvar_lock_picking == loc_lock_picking_open_door) -> open .

BehProc_lock_picking(loc_lock_picking_L0) +

15 (Locvar_lock_picking == loc_lock_picking_alarm_state) -> alarm .

BehProc_lock_picking(loc_lock_picking_L0);

1617 act zero , renamed_zero , one , renamed_one , open , renamed_open , alarm ,

renamed_alarm;

1819 init BehProc_lock_picking(loc_lock_picking_L0);

State space of the mCRL2 model

0

1

2

3

4

5

6

zeroone

zeroone

zero

one

zero

one

zero

one

open

alarm

Remarks:

I initial location is depicted in green

I same behaviour as CIF model

I original location names from the CIF model are not available

Trick for having location names

I add a self loop in every location of the CIF model with anevent that reflects the name of the location

1 event zero , one , open , alarm;

2 event loc_L0 , loc_L1 , loc_L2 , loc_zero_on_three , loc_one_on_three , loc_open_door

, loc_alarm_state;

3 automaton lock_picking:

4 location L0:

5 initial;

6 edge loc_L0;


8 location L1:

9 edge loc_L1;


11 location L2:

12 edge loc_L2;

13 ...

14 location zero_on_three:

15 edge loc_zero_on_three;

16 ...

17 location one_on_three:

18 edge loc_one_on_three;

19 ...

2021 end

Resulting adapted state space

01

2

34

5

6

loc L0

zerooneloc L1

zeroone

loc L2

zeroone

loc zero on three

zeroone

loc one on three

zeroone

open

loc open door

alarm

loc alarm state

No marked states

I in mCRL2 there is no notion of marked state

I add it ourselves in the mCRL2 model (via the CIF model)

I label every marked state in the CIF models by a new globallydeclared event

I resulting mCRL2 state space will have a loop with theintroduced label for each marked state

Network of automata (without variables)

Dining philosophers:

1 sort LocSort_philosopher1 = struct loc_philosopher1_Thinking |

loc_philosopher1_F1 | loc_philosopher1_F2 | loc_philosopher1_Eating;

23 proc BehProc_philosopher1(Locvar_philosopher1 : LocSort_philosopher1) =

4 (Locvar_philosopher1 == loc_philosopher1_Thinking) -> P1_f1 .

BehProc_philosopher1(loc_philosopher1_F1) +



6 (Locvar_philosopher1 == loc_philosopher1_F1) -> P1_f2 . BehProc_philosopher1(

loc_philosopher1_Eating) +



8 (Locvar_philosopher1 == loc_philosopher1_Eating) -> P1_f .

BehProc_philosopher1(loc_philosopher1_Thinking);

910 sort LocSort_philosopher2 = struct loc_philosopher2_Thinking |

loc_philosopher2_F1 | loc_philosopher2_F2 | loc_philosopher2_Eating;

1112 proc BehProc_philosopher2(Locvar_philosopher2 : LocSort_philosopher2) =









17 (Locvar_philosopher2 == loc_philosopher2_Eating) -> P2_f .

BehProc_philosopher2(loc_philosopher2_Thinking);

1 sort LocSort_fork1 = struct loc_fork1_OnTable | loc_fork1_F1 | loc_fork1_F2;

23 proc BehProc_fork1(Locvar_fork1 : LocSort_fork1) =

4 (Locvar_fork1 == loc_fork1_OnTable) -> P1_f1 . BehProc_fork1(loc_fork1_F1) +


6 (Locvar_fork1 == loc_fork1_F1) -> P1_f . BehProc_fork1(loc_fork1_OnTable) +

7 (Locvar_fork1 == loc_fork1_F2) -> P2_f . BehProc_fork1(loc_fork1_OnTable);

89 sort LocSort_fork2 = struct loc_fork2_OnTable | loc_fork2_F1 | loc_fork2_F2;

1011 proc BehProc_fork2(Locvar_fork2 : LocSort_fork2) =



14 (Locvar_fork2 == loc_fork2_F1) -> P1_f . BehProc_fork2(loc_fork2_OnTable) +

15 (Locvar_fork2 == loc_fork2_F2) -> P2_f . BehProc_fork2(loc_fork2_OnTable);

1 act P1_f1 , renamed_P1_f1 , P1_f2 , renamed_P1_f2 , P1_f , renamed_P1_f , P2_f1 ,

renamed_P2_f1 , P2_f2 , renamed_P2_f2 , P2_f , renamed_P2_f;

23 init allow({P1_f1 ,

4 P1_f2 ,

5 P1_f ,

6 P2_f1 ,

7 P2_f2 ,

8 P2_f},

9 rename ({ renamed_P1_f2 -> P1_f2 ,

10 renamed_P1_f -> P1_f ,

11 renamed_P2_f2 -> P2_f2 ,

12 renamed_P2_f -> P2_f},

13 block({P1_f2 , P1_f , P2_f2 , P2_f},

14 comm({ P1_f2 | P1_f2 -> renamed_P1_f2 ,

15 P1_f | P1_f -> renamed_P1_f ,

16 P2_f2 | P2_f2 -> renamed_P2_f2 ,

17 P2_f | P2_f -> renamed_P2_f},

18 (

19 allow({P1_f1 ,

20 P1_f2 ,

21 P1_f ,

22 P2_f1 ,

23 P2_f2 ,

24 P2_f},

25 rename ({ renamed_P1_f1 -> P1_f1 ,

26 renamed_P1_f -> P1_f ,

27 renamed_P2_f1 -> P2_f1 ,

28 renamed_P2_f -> P2_f},

29 block({P1_f1 , P1_f , P2_f1 , P2_f},

30 comm({P1_f1 | P1_f1 -> renamed_P1_f1 ,

31 P1_f | P1_f -> renamed_P1_f ,

32 P2_f1 | P2_f1 -> renamed_P2_f1 ,

33 P2_f | P2_f -> renamed_P2_f},

34 (

1 allow({P1_f1 ,

2 P1_f2 ,

3 P1_f ,

4 P2_f1 ,

5 P2_f2 ,

6 P2_f},

7 (

8 BehProc_philosopher1(loc_philosopher1_Thinking)

9 ||

10 BehProc_philosopher2(loc_philosopher2_Thinking)

11 ))

12 ||

13 BehProc_fork1(loc_fork1_OnTable)

14 )))))

15 ||

16 BehProc_fork2(loc_fork2_OnTable)

17 )))));

The resulting state space is as follows:

0 12

3

4

5

6

7

8

P1f1P2f1

P1f2

P2f2

P1f2

P2f2

P1f2

P2f2

P1f1P2f1

P1f1P2f1

P1f

P2f

Important differences

I mCRL2 does not discriminate between controllable anduncontrollable events

I mCRL2 does not have marked states

I mCRL2 does not allow use of location names

I mCRL2 does not have variables

Solution:

I use events for displaying the values of variables

Important differences

I mCRL2 does not discriminate between controllable anduncontrollable events

I mCRL2 does not have marked states

I mCRL2 does not allow use of location names

I mCRL2 does not have variables

Solution:

I use events for displaying the values of variables

Automaton with a variablecount = 3

count < 5increment

count := count+ 1

count > 0decrement

count := count− 1

1 sort LocSort_counter = struct loc_counter_L;

23 act value_count : Int;

45 proc BehProc_counter(Locvar_counter : LocSort_counter , count : Int) =

6 value_count(count) . BehProc_counter(Locvar_counter , count) +

7 (( Locvar_counter == loc_counter_L) && (count < 5)) -> increment .

BehProc_counter(Locvar_counter , (count + 1)) +

8 (( Locvar_counter == loc_counter_L) && (count > 0)) -> decrement .

BehProc_counter(Locvar_counter , (count - 1));

910 act increment , renamed_increment , decrement , renamed_decrement;

1112 init BehProc_counter(loc_counter_L , 3);

0 12 345

decrement

increment

value count(3)

decrement

increment

value count(2)

decrement

increment

value count(4)

decrement

increment

value count(1)

decrementvalue count(5) increment

value count(0)

Networks of automata with variables

I not discussed in detail

I variables that are local to a single automaton (and not readby any other automaton) are captured as illustrated before

I variables that are used outside their defining automaton arerepresented by separate processes

Supermarket:

1 sort LocSort_queue1 = struct loc_queue1_l0 | loc_queue1_l1;

23 proc BehProc_queue1(Locvar_queue1 : LocSort_queue1) =

4 sum count : Int . (( Locvar_queue1 == loc_queue1_l0) && (count < 2)) -> q1enter

| aread_count(count) | awrite_count ((count + 1)) . BehProc_queue1(

loc_queue1_l1) +

5 sum count : Int . (( Locvar_queue1 == loc_queue1_l0) && (count > 0)) -> q1leave

| aread_count(count) | awrite_count ((count - 1)) . BehProc_queue1(

Locvar_queue1);

67 sort LocSort_queue2 = struct loc_queue2_l0;

89 proc BehProc_queue2(Locvar_queue2 : LocSort_queue2) =

10 sum count2 : Int . (( Locvar_queue2 == loc_queue2_l0) && (count2 < 2)) ->

q2enter | aread_count2(count2) | awrite_count2 (( count2 + 1)) .

BehProc_queue2(Locvar_queue2) +

11 sum count2 : Int . (( Locvar_queue2 == loc_queue2_l0) && (count2 > 0)) ->

q2leave | aread_count2(count2) | awrite_count2 (( count2 - 1)) .

BehProc_queue2(Locvar_queue2);

12 sort LocSort_customer = struct loc_customer_l0;

34 proc BehProc_customer(Locvar_customer : LocSort_customer) =

5 sum count : Int . sum count2 : Int . (( Locvar_customer == loc_customer_l0) &&

(count <= count2)) -> q1enter | aread_count(count) | aread_count2(count2)

. BehProc_customer(Locvar_customer) +

6 sum count2 : Int . sum count : Int . (( Locvar_customer == loc_customer_l0) &&

(count2 <= count)) -> q2enter | aread_count2(count2) | aread_count(count)

. BehProc_customer(Locvar_customer);

78 act value_count , vread_count , vwrite_count , aread_count , awrite_count : Int;

910 proc VarProc_count(v:Int) =

11 value_count(v) . VarProc_count(v) +

12 vread_count(v) . VarProc_count(v) +

13 sum m:Int . true -> vwrite_count(m) . VarProc_count(m) +

14 sum m:Int . true -> vread_count(v) | vwrite_count(m) . VarProc_count(m);

1516 act value_count2 , vread_count2 , vwrite_count2 , aread_count2 , awrite_count2 : Int

;

1718 proc VarProc_count2(v:Int) =

19 value_count2(v) . VarProc_count2(v) +

20 vread_count2(v) . VarProc_count2(v) +

21 sum m:Int . true -> vwrite_count2(m) . VarProc_count2(m) +

22 sum m:Int . true -> vread_count2(v) | vwrite_count2(m) . VarProc_count2(m);

1 act q1enter , renamed_q1enter , q1leave , renamed_q1leave , q2enter , renamed_q2enter

, q2leave , renamed_q2leave;

23 init allow({ value_count ,

4 value_count2 ,

5 q1enter | awrite_count | aread_count | vwrite_count2 | aread_count2 ,

6 q1leave | awrite_count | aread_count | vwrite_count2 | vread_count2 ,

7 q2enter | awrite_count2 | aread_count2 | vwrite_count | aread_count ,

8 q2leave | awrite_count2 | aread_count2 | vwrite_count | vread_count

},

9 comm({ aread_count2 | vread_count2 -> aread_count2 ,

10 awrite_count2 | vwrite_count2 -> awrite_count2},

11 (

12 allow({ value_count ,

13 q1enter | awrite_count | aread_count | aread_count2 ,

14 q1leave | awrite_count | aread_count ,

15 q2enter | awrite_count2 | aread_count2 | vwrite_count |

aread_count ,

16 q2leave | awrite_count2 | aread_count2 | vwrite_count |

vread_count},

17 comm({ aread_count | vread_count -> aread_count ,

18 awrite_count | vwrite_count -> awrite_count},

19 (

20 allow({ q1enter | awrite_count | aread_count | aread_count2 ,


22 q2enter | awrite_count2 | aread_count2 | aread_count ,

23 q2leave | awrite_count2 | aread_count2},

24 comm({ aread_count | aread_count -> aread_count ,

25 aread_count2 | aread_count2 -> aread_count2},

26 rename ({ renamed_q1enter -> q1enter ,

27 renamed_q2enter -> q2enter},

28 block({q1enter , q2enter},

29 comm({ q1enter | q1enter -> renamed_q1enter ,

30 q2enter | q2enter -> renamed_q2enter},

1 (

2 allow({ q1enter | awrite_count | aread_count ,


4 q2enter | awrite_count2 | aread_count2 ,

5 q2leave | awrite_count2 | aread_count2},

6 (

7 BehProc_queue1(loc_queue1_l0)

8 ||

9 BehProc_queue2(loc_queue2_l0)

10 ))

11 ||

12 BehProc_customer(loc_customer_l0)

13 ))))))

14 ||

15 VarProc_count (0)

16 )))

17 ||

18 VarProc_count2 (0)

19 )));

Transforming CIF model to mCRL2 state space

1. In the CIF tool set: Apply Convert CIF to mCRL2 ... onthe file with the CIF model. This results in a file withextension mcrl2.

2. In the mCRL2 tool set:

2.1 Apply mcrl22lps (in menu Transformation) on the mcrl2

file. The result is a file with extension lps (for Linear ProcessSpecification).

2.2 Apply lps2lts on the lps file to obtain a file with extensionlts (for Labelled Transition System).

2.3 Apply ltsgraph (from Analysis menu) to obtain avisualization of the state space.

Specification of behavioral properties

I property describes some aspect of the behavior of a system

I deadlock freedom / absence of deadlock

I every message that is sent will ultimately be received

Main reasons to formulate properties of systems:

I less complex than describing the complete behaviour

I desired behaviour is still unclear (e.g. use cases in UML)

I extra safeguard to guarantee the correctness of thespecification: behavioral descriptions contain mistakes

Hennessy-Milner logic

I describes a property of a transition system

I a modal formula is either valid or invalid in a state

I a modal formula is valid for a transition system iff it is valid inits initial state

φ ::= true | false | ¬φ | φ ∧ φ | φ ∨ φ | φ→ φ | 〈a〉φ | [a]φ

I true is valid in each state

I false is never valid

I connectives ∧ (and), ∨ (or), ¬ (not), and → (implication)

I diamond modality 〈a〉φ is valid whenever an a-action can beperformed such that φ is valid after this a has been done

I box modality [a]φ is valid when for every action a that can bedone, φ holds after doing that a

Hennessy-Milner logic

I describes a property of a transition system

I a modal formula is either valid or invalid in a state

I a modal formula is valid for a transition system iff it is valid inits initial state

φ ::= true | false | ¬φ | φ ∧ φ | φ ∨ φ | φ→ φ | 〈a〉φ | [a]φ

I true is valid in each state

I false is never valid

I connectives ∧ (and), ∨ (or), ¬ (not), and → (implication)

I diamond modality 〈a〉φ is valid whenever an a-action can beperformed such that φ is valid after this a has been done

I box modality [a]φ is valid when for every action a that can bedone, φ holds after doing that a

Exercise

Express the following properties:

1. after doing an a action both a b and a c must be possible

〈a〉(〈b〉true ∧ 〈c〉true)

2. after an a action, no b is possible

〈a〉¬〈b〉true

What is expressed?

1. [a]〈b〉true

whenever an a can be done, a b action is possible afterwards

2. [a]false

action a is not possible

Exercise


1. after doing an a action both a b and a c must be possible〈a〉(〈b〉true ∧ 〈c〉true)

2. after an a action, no b is possible

〈a〉¬〈b〉true

What is expressed?

1. [a]〈b〉true


2. [a]false


Exercise



2. after an a action, no b is possible〈a〉¬〈b〉true

What is expressed?

1. [a]〈b〉true


2. [a]false


Exercise




What is expressed?

1. [a]〈b〉truewhenever an a can be done, a b action is possible afterwards

2. [a]false


Exercise




What is expressed?

1. [a]〈b〉truewhenever an a can be done, a b action is possible afterwards

2. [a]falseaction a is not possible

Distinguishing formulas

I Give a transition system where 〈a〉〈b〉true holds and[a]〈b〉true is invalid

aa

b

I Give a transition system where [a]〈b〉true is valid and〈a〉〈b〉true is invalid



aa

b




aa

b


Establishing validity of a formula φ for an LTS

Label each state with all subformulas of φ that hold in that state.This should be done by working from the smaller to the largersubformulas.

1. each state is labeled with true, and none with false

2. the following steps are repeatedly executed, until allsubformulas are considered:

I label a state with ¬φ, if it is not labeled with φI label a state with φ∧ψ if it is labeled with φ and ψI label a state with φ∨ψ if it is labeled with φ or ψI label a state with 〈a〉φ if there is an outgoing a transition to a

state where φ holdsI label a state with [a]φ if all outgoing a transitions go to states

where φ holds

At termination, the initial state is labeled with φ iff φ is valid inthe initial state.

Exercise

Validity of 〈a〉〈b〉true w.r.t.

aa

b

true, 〈a〉〈b〉true

true true, 〈b〉true

true

aa

b

Exercise

Validity of 〈a〉〈b〉true w.r.t.

aa

b

true, 〈a〉〈b〉true

true true, 〈b〉true

true

aa

b

Exercise

Validity of [a]〈b〉true w.r.t.

aa

b

true

true[a]〈b〉true

true, 〈b〉true, [a]〈b〉true

true, [a]〈b〉true

aa

b

Exercise

Validity of [a]〈b〉true w.r.t.

aa

b

true

true[a]〈b〉true

true, 〈b〉true, [a]〈b〉true

true, [a]〈b〉true

aa

b

Identities for Hennessy-Milner formulas

¬〈a〉φ = [a]¬φ

¬[a]φ = 〈a〉¬φ

〈a〉false = false

[a]true = true

〈a〉(φ ∨ ψ) = 〈a〉φ ∨ 〈a〉ψ

[a](φ ∧ ψ) = [a]φ ∧ [a]ψ

〈a〉φ ∧ [a]ψ ⇒ 〈a〉(φ ∧ ψ)

Documents

Supervisory Control (4CM30) · 3/24/2017 · Philosophy of mCRL2 I process algebra, which are algebraic formalisms for compositional speci cation of concurrent systems I extends