Consiglio Nazionale delle Ricerche

Deadlock Avoidance in Train Scheduling:

a Model Checking Approach

Franco Mazzan:,
Giorgio O. Spagnolo,
Simone Della Longa,
and Alessio Ferrari

ISTI - CNR
Pisa, Italy

Formal Methods && Tools Laboratory

Istituto di Scienza e Tecnologie dellInformazione A. Faedo - Pisa

THE CONTEXT: Project TRACE-IT

Study, Design, Prototype Implementa:on and Demonstra:on of

an integrated ETCS-BL3/CBTC system.

ECM (IXL, ATC) - ISTI (ATS) - UNIFI (ATO)

Tabelle

Timetable
Orario
SST
ATS

Files diRail
Network
Configurazione
Configuration
di ImpiantoFiles

SST
IXL

Simulatore
Network
Rail
diSimulator
Impianto

SST
ATO

SST
ATC

SSB
ATO

SSB
ATC

Simulatore
Train
di
Treno
Simulator
Sperimentazione sistema ATC integrato BL3/CBTC

THE PROBLEM: Automa:c Train Supervision in a metro context

We have a metro layout.

We have an automa:c (unmanned) metro service.

Each train has its mission sta:cally dened,
provided to the ATS as sta:c congura:on data (:metable)

We have to design the logic of the ATS scheduling kernel,

to successfully dispatch all the trains, leading them to des:na:on

avoiding deadlocks (also in case of arbitrary delays)

CASE STUDY: The project demonstrator case study

Via Accademia
I

green

11
II

22

Piazza Universit
BCA01

33
re d

BCA02

44

Via Verdi
I

77

BCA03

Piazza Dante
I

9
9

10
10

II

II

II

55

88

11
11

Vicolo Corto Vicolo Stretto

I
I
yellow
31
31

II
32
32

30
30

blu

BCA04

II

III

Parco della Vittoria

15
15

>
een >

20
20

17
17

Viale dei Giardini

12
12
27
27

BCA05

29
29

We have a metro layout: 4 lines

We have a metro service: 8 trains providing circular services
[1,3,4,6,7,9,10,13,15,20,23,22,17,18,11,9,8,6,5,3,1]
[2,3,4,6,7,9,10,13,15,20,24,22,17,18,11,9,8,6,5,3,2]
[31,30,28,27,11,13,15,20,25,22,17,18,12,27,29,30,31]
[32,30,28,27,11,13,15,20,26,22,17,18,12,27,29,30,32]

(Missions are dened in terms of sequences of IXL i:nerary endpoints)

red >>

yell

I
18
18

I
23
23

gr

II
16
16

13
13

III

Viale Monterosa
I

28
28

Via Roma
Via Marco Polo

22
22

ow

blu

>>

II
24
24

III
25
25

e>

> IV
26
26

Our level of abstrac:on for the deadlock analysis

Piazza Universit
I
BCA02

BCA01

IAnerary level

II
5

Piazza Universit

Track circuit level

14020

14021

14022

14301

14012

BCA501

14011

14010
BCA502

II

14302

THE INITIAL STEPS: 1) Iden:fy the Basic Kinds of Deadlock

THE INITIAL STEPS: 2) Iden:fy the Basic Cri:cal Sec:ons

Basic Linear CriAcal SecAon

Basic Circular CriAcal SecAon (rings)

(Basic Cri:cal Sec:ons can be found by just analyzing the train missions)

THE INITIAL STEPS: 3) Associate Sec:on Counters to Cri:cal Sec:ons

Basic Linear CriAcal SecAon A (AL=0 or AR=0)
AR--

[AR =0] / AL++

[AL =0] / AR++

AL

AR

Basic Circular CriAcal SecAon B (max 2)

[B<2] / B++

B
[B<2] / B++

B--

THE INITIAL STEPS: 4) Generate Extended Missions encoding

sec:on counter ops

A
3

15

10

11

13

18

23

16

20

24

17

22

25

12
31

32

30

28

27

29

[1 ,3, 4, 6, 7, 9, 10, 13, 15, 20 ,23, 22, 17, 18, 11, 9, 8 ,6, 5, 3, 1]

[(A==1) 1, (A--, [C<3] C++) 3, 4, (C--,[D<3] D++) 6, 7, (D--) 9, 10, 13, 15, 20,
23,22,17,18,11, ([D<3] D++) 9,8, ([C<3] C++,D--) 6,5,(C--,[A<1]A++) 3,1]
The informa:on on the sec:on counters limits and sec:on counter opera:ons
for all train missions are provided to the ATS as staAc conguraAon data.

26

THE INITIAL STEPS: 1) ... 4) Automa:c genera:on of ini:al ATS data

Steps 1) .. 4) can be automa:cally performed

by sta:cally analyzing the original train missions

Train1:
Train1: [[ ...,
, z,x, x,
] y, ...]
Train2:
Train2: [[ ...,
, x,y, y,
] z, ...]
Train3:
Train3: [[ ...,
, y,z, z,
] x, ...]

A
z

Train1: [ , ([A<2] A++) z, (A--) x, ]

Train2: [ , ([A<2] A++) x, (A--) y, ]
Train3: [ , ([A<2] A++) y, (A--) z, ]

Is our ATS extended missions data correct?

THE REAL PROBLEM:

More complex cases of deadlock over adjacent cri:cal sec:ons are possible !
D

A
1

15

10

11

13

18

23

16

20

24

17

22

25

12
31

32

30

28

27

29

We need to discover ALL the cases of deadlocks in order to obtain

- the exhaus:ve deni:on of necessary cri:cal sec:ons
- the introduc:on of all the needed sec:on counters, and
- the deni:on of all the needed extension of the train missions.
We build a formal model of the system and use model checking techniques
to nd all situa:ons of deadlock and removing all situa:ons of false posi:ves

26

Is our congura:on data correct?

THE REAL PROBLEM:

More complex cases of deadlock over adjacent cri:cal sec:ons are possible !
E (max 3)
C

A
1

D
6

15

10

11

13

18

23

16

20

24

17

22

25

12
31

32

30

28

27

29

We need to discover ALL the cases of deadlocks in order to obtain

- the exhaus:ve deni:on of necessary cri:cal sec:ons
- the introduc:on of all the needed sec:on counters, and
- the deni:on of all the needed extension of the train missions.
We build a formal model of the system and use model checking techniques
to nd all situa:ons of deadlock and removing all situa:ons of false posi:ves

26

Model checking the ATS data

THE APPROACH:

Train Missions

Validated
ATS
Data

No more deadlocks or
false positives

Initial model
(handling basic deadlocks)

Model Checking

New
deadlocks or
false positives
New sections, counters,
and updated missions

MODEL CHECKING:

For deadlocks and false posi:ves

DEAD == The state violates the constraints

associated to the cri:cal sec:ons

ARRIVED == Al trains have completed their mission


ARRIVED

Verifying absence of false posi:ves:
DEAD

AG (DEAD -> not EF ARRIVED)
ARRIVED


Verifying absence of undiscovered deadlocks:
ARRIVED

A[ EF ARRIVED U (DEAD or ARRIVED)]

DEAD

DEAD

THE TOOL:

UMC (UML Model Checker)

Experimental model checking framework developed at ISTI / FM&&T lab

Ac:vely maintained and con:nuously evolving
Based on UML-like state machines
Abstract reasoning on the system (seen as a doubly labelled LTS)
On-the-y model genera:on and formula evalua:on
Suppor:ng a State/Event based branching Ame temporal logic :

Directly usable online at h^p://fmt.isA.cnr.it/umc

(and freely available)

THE MODEL:

(hints)

System dened by sets of Classes, Objects , and Abstrac:on Rules

Class is
Signals

Events handled by the objects of the class
Opera:ons

Vars
Local data of the state machine

e.g. Train1_Mission: int[] = [1,3,4,6,7, .];

Train1_Progress: int = 0;

Sec:on_Counter_A : int =1;
Behavior
State transi:on rules

s1 -> s1 { - [guards] / ac:on; ac:on; }
end
(The complete code can be found at: hlp://fmtlab.is:.cnr.it/umc/examples/traceit)

THE MODEL:

(hints)

The whole system is modelled as a single state machine

(we have just one object)
Our_Model : Our_Model_Class ( local_var => ini:al_value, , )

AbstracAon rules are use to dene WHAT we want to observe,

i.e. which labels appear in the states and edges of
abstract graph (L2TS) modelling the system evolu:ons
AbstracAons {
State:
Train1Progress = Train1MissionLength and
Train2Progress =Train2MissionLength and


(for each train)

ARRIVED
State:
Sec:on_Counter_A > 1 DEAD
State:
Sec:on_Counter_B > 3 DEAD
}

(The complete code can be found at: hlp://fmtlab.is:.cnr.it/umc/examples/traceit)

THE ABSTRACT VIEWS: Abstract L2TS / Abstract traces

Abstract L2TS Abstract Minimized Traces

SAMPLE PROPERTY: AG (DEAD -> not EF ARRIVED)

HANDLING THE PROBLEM SIZE:

Parco della Vittoria

III
Via Accademia
I

BCA01
green

11
II

22

Piazza Universit

33
red

BCA02

6
6

44

Via Verdi
I

77

BCA03

Piazza Dante
I

9
9

10
10

II

II

II

55

88

11
11

Vicolo Corto Vicolo Stretto

I
I
yellow
31
31

II
32
32

30
30

blu

BCA04

III

Viale Monterosa
I

28
28
II

Via Roma
Via Marco Polo

16
16

20
20

17
17

red >>

ye l l

I
18
18

23
23

n>
gree

II
13
13

>

15
15

22
22

Viale dei Giardini

12
12
27
27

BCA05

29
29

8 trains , 13 cri:cal sec:ons, full circular missions of 20 steps

Not a surprise if the whole system is too big

for a complete formal analysis

ow

blu

>>

II
24
24

III
25
25

e>

> IV
26
26

HANDLING THE PROBLEM SIZE: Iden:fy Independent Regions

23

15

10

13

16

11

18

17

20

24

22

12
31

32

30

28

27

29

Complex deadlocks can only occur over overlapping basic cri:cal

sec:on !!

We can split the whole layout into separate independent regions

25

26

HANDLING THE PROBLEM SIZE:

Via Accademia
BCA01
I
1

Piazza Universit
BCA02
I
6
4

Via Verdi
I
7

II

II

II

decomposing the system

BCA03
9

Piazza Dante
I

10

Via Roma
Via Marco Polo

15

13

16

11

27

31

30

II

BCA04

32

28

II
29

27

17

Viale dei Giardini

12

Viale Monterosa BCA05

I

II
20

I
18

III

BCA05

23

II

II

REGION 2

Vicolo Stretto
I

Parco della Vittoria

I

III
BCA03

Vicolo Corto
I

REGION 1

REGION 3

24

III
22

25

IV
26

HANDLING THE PROBLEM SIZE:

decomposing the system

Separately ,
we can easily analyze the three regions of the full layout:

Region1 (4 trains): 10,493 states (< 1 sec.)
Region2 (8 trains): 8,878,643 states (< 5 min.)
Region3 (4 trains): 2,067states (< 0.2 sec.)

WHAT NEXT:

Further lines of work

Fully automa:c genera:on of extended missions.

Inves:gate possibility of performing model checking at run:me
as part of the ATS behavior (dealing with run:me missions changes)
Compare the performance and usability of UMC with respect to
other verica:on tools (SPIN, SMV, MCRL2, CADP...)
Generalize the results to a wider railway context,
taking into account further kinds of synchroniza:ons/ constraints

WHAT NEXT:

Further lines of work

S
S
E
R
G
Fully automa:c genera:on
o
f
e
xtended
missions.
O
R
P


IN
Inves:gate possibility of performing model checking at run:me
as part of the ATS behavior (dealing with run:me missions changes)
Compare the performance and usability of UMC with respect to
other verica:on tools (SPIN, SMV, MCRL2, CADP...)
Generalize the results to a wider railway context,
taking into account further kinds of synchroniza:ons/ constraints

WHAT NEXT:

Further lines of work

S
S
E
R
G
Fully automa:c genera:on
o
f
e
xtended
missions.
O
R
P


IN
Inves:gate possibility of performing model checking at run:me

S
S
E
as part of the ATS behavior (dealing
w
ith run:me missions changes)
R
G
O
R
IN P
Compare the performance and usability of UMC with respect to
other verica:on tools (SPIN, SMV, MCRL2, CADP...)
Generalize the results to a wider railway context,
taking into account further kinds of synchroniza:ons/ constraints

WHAT NEXT:

Further lines of work

S
S
E
R
G
Fully automa:c genera:on
o
f
e
xtended
missions.
O
R
P


IN
Inves:gate possibility of performing model checking at run:me

S
S
E
as part of the ATS behavior (dealing
w
ith run:me missions changes)
R
G
O
R
IN P

Compare the performance and usability of UMC T
with
respect
to
D
E
R
A
T
other verica:on tools (SPIN, SMV,
M
CRL2,
CADP...)
S

T
S
U
J
Generalize the results to a wider railway context,
taking into account further kinds of synchroniza:ons/ constraints

WHAT NEXT:

work s:ll in progress

Thanks!