martin p•eni•cka towards a theory of railways - cvut.czvdts.fd.cvut.cz/penicka_towards a theory...

1

Czech Technical University and Technical University of Denmark

Martin Penicka

Towards a Theory of RailwaysPhD Thesis

Supervisors: Dines Bjørner and Miroslav Svıtek

September 14, 2006

Contents

Preface 11

I Opening 13

1 Introduction 151.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 Requirements and Software Design . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Used Formal Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4.1 RAISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.2 Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.3 Statecharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.4 Message and Live Sequence Charts . . . . . . . . . . . . . . . . . . . . 18

1.5 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

II Domain Foundation 19

2 Railway System 212.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Railway Nets 233.1 Static . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.2 Auxiliary Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.2 Auxiliary Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Discussion of the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.1 Why No Unique Unit Identification ? . . . . . . . . . . . . . . . . . . 453.3.2 Is It the Right Model of Timing ? . . . . . . . . . . . . . . . . . . . . 463.3.3 Possible Relations to Control Theory . . . . . . . . . . . . . . . . . . . 46

3

4 CONTENTS

4 Timetables, Schedules and Traffics 494.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Passenger & Freight Train Timetables . . . . . . . . . . . . . . . . . . . . . . 49

4.2.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Traffic Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.4 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.4.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.4.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.5.1 Schedule Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.5.2 Schedule Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.5.3 Traffic Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.5.4 Traffic and Safety Conditions . . . . . . . . . . . . . . . . . . . . . . . 544.5.5 Kirschoff’s Law of Station Flow . . . . . . . . . . . . . . . . . . . . . . 54

5 Rolling Stock 555.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2 Rolling Stock Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55


5.3 Bag Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.4 Wagon Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.4.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.4.2 Formal Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 Train Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5.2 Formal Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.6 Rolling Stock Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.6.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.6.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.7 Rolling Stock Plan Modification . . . . . . . . . . . . . . . . . . . . . . . . . . 595.7.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.7.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6 Passengers and Freights 616.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2 Module of Passengers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61


6.3 Passenger Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.3.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.3.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

CONTENTS 5

6.4 Passenger Ticketing and Reservations . . . . . . . . . . . . . . . . . . . . . . 636.4.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.4.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.5 Module of Freights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.5.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.5.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.6 Client Freighting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.6.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.6.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.7 Lost & Found Freight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.7.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.7.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

III Railway Scheduling and Allocation 73

7 Issues of Scheduling & Allocation 757.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.2 Rail Net Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.3 Timetable Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.4 Scheduling and Rescheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.5 Other Resource Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.6 Maintenance Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.7 Optimum Train Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.8 Station Track Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.9 Delay Train Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.10 Hub Location Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.11 Automatic Train Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.12 Train Dispatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.13 Shunting and Marshalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.14 Passenger & Freighter Information . . . . . . . . . . . . . . . . . . . . . . . . 787.15 Line Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.16 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8 General Resource Planning 798.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.2 Passenger Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79


8.3 Generating Railway Net & Timetable . . . . . . . . . . . . . . . . . . . . . . 798.3.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.3.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

8.4 Planning Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808.4.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808.4.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

8.5 Rolling Stock and Staff Resources . . . . . . . . . . . . . . . . . . . . . . . . . 81

6 CONTENTS

8.5.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.5.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.5.3 Vehicle Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.5.4 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.5.5 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.6 Issues of Optimum Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

9 Train Maintenance 839.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839.2 Maintenance Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84


9.3 Maintenance Planning Functions . . . . . . . . . . . . . . . . . . . . . . . . . 869.3.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869.3.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9.4 Generating Plan Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909.4.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909.4.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

9.5 Applying Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919.5.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919.5.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

9.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

10 Staff Rostering 9310.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9310.2 Adding Deports to NETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93


10.3 Staff Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.3.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.3.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

10.4 Schedule, Journeys and Trips . . . . . . . . . . . . . . . . . . . . . . . . . . . 9610.4.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9610.4.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

10.5 Actions and Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9810.5.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9810.5.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

10.6 Rosters and Staff Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10210.6.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10210.6.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

10.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

CONTENTS 7

IV Railway Signalling and Interlocking 107

11 Issues of Train Monitoring and Control 10911.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10911.2 Line Direction Agreement Device . . . . . . . . . . . . . . . . . . . . . . . . . 10911.3 Station Interlocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10911.4 Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11011.5 Level Railway Crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11111.6 Interlocking Safety and Reliability . . . . . . . . . . . . . . . . . . . . . . . . 11111.7 Automatic Train Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11211.8 European Rail Traffic Management System (ERTMS) . . . . . . . . . . . . . 11211.9 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

12 Automatic Line Signalling 11312.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11312.2 Line Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11312.3 First Segment of the Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

12.3.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11412.3.2 Formal Model: Statechart . . . . . . . . . . . . . . . . . . . . . . . . . 114

12.4 General Inner Segment of the Line . . . . . . . . . . . . . . . . . . . . . . . . 11512.4.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11512.4.2 Formal Model: Statechart . . . . . . . . . . . . . . . . . . . . . . . . . 116

12.5 Last Segment of the Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.5.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.5.2 Formal Model: Statechart . . . . . . . . . . . . . . . . . . . . . . . . . 117

12.6 Overall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11712.6.1 The Line with One Segment Only . . . . . . . . . . . . . . . . . . . . 11712.6.2 The Line with Two Segments . . . . . . . . . . . . . . . . . . . . . . . 11712.6.3 The Line with Three and More Segments . . . . . . . . . . . . . . . . 117

12.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

13 Line Direction Agreement 12113.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12113.2 Line Direction Agreement System . . . . . . . . . . . . . . . . . . . . . . . . . 12113.3 Internal Behaviour of LDAS (Statechart) . . . . . . . . . . . . . . . . . . . . 12213.4 Internal Behaviour of Station A (Statechart) . . . . . . . . . . . . . . . . . . 12313.5 Internal behaviour of Station B (Statechart) . . . . . . . . . . . . . . . . . . . 12313.6 External behavior (Live Sequence Chart) . . . . . . . . . . . . . . . . . . . . 123

13.6.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12413.6.2 Line Direction Change Approvals . . . . . . . . . . . . . . . . . . . . . 12413.6.3 Line Direction Change Disapprovals . . . . . . . . . . . . . . . . . . . 12413.6.4 Change Direction Requests . . . . . . . . . . . . . . . . . . . . . . . . 12513.6.5 Failure Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

13.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8 CONTENTS

14 Station Interlocking 12714.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

14.1.1 Interlocking Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12714.2 Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

14.2.1 Petri Net for Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12814.2.2 Petri Net for Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 12814.2.3 Petri Net for Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13014.2.4 Petri Net for Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

14.3 Constructing the Petri Nets for Interlocking Tables . . . . . . . . . . . . . . . 13014.3.1 Routes and Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13014.3.2 Routes and Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13114.3.3 Routes and Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

14.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

V Towards a Holistic Future 133

15 Combining Scheduling & Interlocking 13515.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13515.2 Distributed Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

15.2.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13515.2.2 Formal Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

15.3 Control Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13715.3.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13715.3.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

15.4 Scheduling Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13815.4.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13815.4.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

15.5 Distributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13915.5.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13915.5.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14015.5.3 A scheduling example . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

15.6 Possible Traffics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14315.6.1 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14315.6.2 Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

15.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

16 Role of Formal Methods 14516.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14516.2 Proving Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14516.3 Issues of Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14516.4 Automated Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14616.5 Re–usage of Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14616.6 Techniques for Requirements Capture . . . . . . . . . . . . . . . . . . . . . . 14616.7 Methods for Building Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14716.8 Techniques for Code Verification . . . . . . . . . . . . . . . . . . . . . . . . . 14716.9 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

CONTENTS 9

VI Closing 149

17 Review of the Thesis 15117.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15117.2 Allocation & Scheduling of Resources Examples . . . . . . . . . . . . . . . . . 151

17.2.1 From Passenger Statistics to Railway Nets and Timetables . . . . . . 15117.2.2 From Nets & Timetables to Operational Planning . . . . . . . . . . . 15217.2.3 From Timetables and Rolling Stock to Vehicle Scheduling . . . . . . . 15217.2.4 From Timetables and Human Resources to Rostering . . . . . . . . . . 15217.2.5 From Timetables to Vehicle Maintenance . . . . . . . . . . . . . . . . 153

17.3 Monitoring & Control Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15317.3.1 From Timetable to Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 15417.3.2 From Traffic to Station Interlocking . . . . . . . . . . . . . . . . . . . 15417.3.3 From Traffic to Line Direction Agreement . . . . . . . . . . . . . . . . 15417.3.4 From Traffic to Automatic Line Signalling . . . . . . . . . . . . . . . . 155

17.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

18 Future Work 15718.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15718.2 TRain Consortium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15718.3 www.RailwayDomain.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15818.4 The TRain Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15818.5 Formal Methods as a Part of Education . . . . . . . . . . . . . . . . . . . . . 15818.6 Other Transportation Domains . . . . . . . . . . . . . . . . . . . . . . . . . . 158

19 Acknowledgements 161

VII Appendixes 163

A Formal Methods in Computing Systems Development 165A.1 What is ‘Formal Method’ ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

A.1.1 What is a Method ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165A.1.2 What is Meant by Formal ? . . . . . . . . . . . . . . . . . . . . . . . . 165A.1.3 What, Then, is a Formal Method ? . . . . . . . . . . . . . . . . . . . . 166

B An RSL Primer 167B.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

B.1.1 Type Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167B.1.2 Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

B.2 The RSL Predicate Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170B.2.1 Propositional Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 170B.2.2 Simple Predicate Expressions . . . . . . . . . . . . . . . . . . . . . . . 170B.2.3 Quantified Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

B.3 Concrete RSL Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170B.3.1 Set Enumerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170B.3.2 Cartesian Enumerations . . . . . . . . . . . . . . . . . . . . . . . . . . 171B.3.3 List Enumerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

10 CONTENTS

B.3.4 Map Enumerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172B.3.5 Set Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172B.3.6 Cartesian Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174B.3.7 List Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174B.3.8 Map Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

B.4 Lambda–Calculus + Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 177B.4.1 The Lambda–Calculus Syntax . . . . . . . . . . . . . . . . . . . . . . . 178B.4.2 Free and Bound Variables . . . . . . . . . . . . . . . . . . . . . . . . . 178B.4.3 Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178B.4.4 α–Renaming and β–Reduction . . . . . . . . . . . . . . . . . . . . . . 179B.4.5 Function Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179B.4.6 Function Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

B.5 Other Applicative Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 180B.5.1 Let Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180B.5.2 Conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181B.5.3 Operator/Operand Expressions . . . . . . . . . . . . . . . . . . . . . . 181

B.6 Imperative Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181B.6.1 Variables and Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 181B.6.2 Statement Sequences and skip . . . . . . . . . . . . . . . . . . . . . . 182B.6.3 Imperative Conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . 182B.6.4 Iterative Conditionals . . . . . . . . . . . . . . . . . . . . . . . . . . . 182B.6.5 Iterative Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

B.7 Process Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182B.7.1 Process Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182B.7.2 Process Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182B.7.3 Input/Output Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 183B.7.4 Process Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

B.8 Simple RSL Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Preface

This thesis is about the precise description, both informally, in English, and formally, usinga wide variety of mathematically precise notations, of a large number of aspects of railways.

We develop and analyse descriptions of such things as railway nets (lines and stations),their dynamic control (setting of switches and signals), timetables, train traffic, of thescheduling and allocation of resources (time, rolling stock, staff) for actual trains, formaintenance, for service staff (rostering), etc., and of the monitoring and control of signalsand switches: within stations, and along lines between stations.

The conjecture of this Thesis, is threefold:

• That, to successfully tackle such complex and highly interrelated matters as are in-volved in any railway system, whether small or large, one can do well in using themathematically precise specification techniques that are shown here.

• That, to understand the issues of the management of railway systems — where thismanagement interrelates events and information arising in diverse sub–systems of therailways (ie., train despatch, traffic control, scheduling and allocation planning, etc.)— one can do well in using the mathematically precise specification techniques thatare shown here, techniques that allow a uniform treatment of all these diverse issueson the basis of stable, underlying models.

• And: That informatics (the confluence of mathematics, computing science, and appli-cations — such as the one shown here) is becoming a necessary component of everyacademic education. That is, that informatics — in the form of formal specificationand computing systems development according to the TripTych paradigm illustratedin this thesis — is a necessary prerequisite for any successful engineering.

Martin Penicka

September 27, 2006

11

12 CONTENTS

Part I

Opening

13

Chapter 1

Introduction

1.1 Issues

The problem which this Thesis addresses is that of understanding the railway applicationdomain. That is: of constructing descriptions, both informal and formal, of railway domains“devoid” of any reference to computing. We wish to refer to such description as ‘domaintheory’ and to its development and investigation as ‘domain analysis’. Other names forsuch description are ‘enterprise model’ or ‘business engineering’. The next two paragraphstherefore will say a few more words on these two concepts: ‘infrastructures’ and ‘domainanalyses & theories’. The concept of ‘coordination models and languages’ perhaps derives itsbasic justification exactly from the need to provide software support for infrastructures.

In this case an infrastructure is seen as a set of distinct, professional languages sharinga common set, a base, or a core of concepts. Railway infrastructure is “large enough” towarrant a separate investigation: a theory and its analysis.

Let us illustrate the above by looking at the various kinds of professionals that populateany typical railway system: (1) There are system strategy planners, and they talk aboutincreased or decreased traffic, of lines and stations, and of specific train or other services; (2)then there are ‘plant’ development (tactical) planners and developers, and they talk aboutimplementations of the abstracted strategy concepts: specific lines, stations and services soas to realize specific traffic (etc.) goals, they also talk about acquiring new or disposingold resources: monies (i.e. capital), personnel, main and auxiliary ‘plant’ equipment (rails,buildings, switching & signaling “gear”, locomotives, wagons (cars), etc.); (3) then there areoperations planning & development staff, and they talk about timetables, resource sched-ules & allocations, quality assurance, etc.; then there are ground (or field) staff (the previous‘classes’ of staff can be thought of as sitting in office buildings not directly related to the mainrail plant), and they talk about (4) accepting seat reservations and selling passenger tickets,(5) of day-to-day freight handling, (6) train dispatch, monitoring & control, (7) signaling, (8)line management, (9) station management (including shunting and marshalling yard man-agement), etc.; and (10) then there are peoples which gather statistics for various purposes:preventive maintenance, local scheduling & allocation adjustments, and more global, mediumto long term planning (see items (1)–(2)–(3)).

The point of the above example is to try illustrate that although wide in spectrum (interms of job profiles etc.), all these people share a sufficiently interesting (large) number ofconcepts, viewed, however, with properly “intersecting” but not “identical meanings”.

15

16 CHAPTER 1. INTRODUCTION

The intersecting parts form the ‘base’ (or ‘core’), and the professional languages spokenby the various classes of staff (viz.: (1)–(10)) form ‘extensions’.

The formed ‘base’ is called domain theory and it is the main subject of the Thesis. Weare going to present as much as possible of railway domain descriptions, its development andinvestigation.

We expect that man-made systems — like railways satisfy certain laws, just like physicalsystems — like mechanics (including celestial mechanics), electricity, thermodynamics, etc.— satisfy laws such as Newton’s (Copernicus’, Gallileo’s, Kepler’s), Ohm’s, the first, second,etc. laws of thermodynamics, etc. We shall attempt to identify such laws in connection withsub-parts of railway systems. Our descriptions, whether informal or formal, must imply theselaws.

1.2 State of the Art

At this moment a research on man-made systems is starting. This Thesis addresses one ofman-made systems — Railways. There are already papers on formal description of railwaydomain, see [16, 17, 19, 20, 22, 23, 25, 27, 28]. One can also find railway domain descriptionsin PRaCoSy project [48, 163, 164, 165, 166, 167, 168, 169, 171, 180].

In the Thesis we use a basic core of them to model various application from two differentaspects of any railway system:

• Allocation & Scheduling and• Monitoring & Control

The goal of the Thesis is to show that mathematically precise specification techniques allowa uniform treatment of these two diverse issues on the basis of stable, underlying models.

Further references of each of these topics are given in separate chapters (see Chap. 7 andChap. 11 at the beginning of each part).

1.3 Requirements and Software Design

We would like to emphasize that we are going to deal with formal characterization of majorpart of railway domain — such as they are “out there”, in reality, not necessarily as we wishthem to be. On the basis of such formal domain specifications we can later express softwarerequirements, ie., such as we wish real applications for railway to be.

The actual software design of these applications relies on the identification of suitableoperation research techniques (algorithms) that can provide reasonably optimum solutionsand at reasonable computing times.

It is not the aim of this Thesis to show such operation research algorithms, neither toshow software requirements or software design. Instead we refer to [39, 40, 54, 123, 142, 146,148, 196, 207, 210].

1.4 Used Formal Techniques

All of the descriptions in this Thesis are presented in natural English language as well as inat least one of the following formal languages: Raise Specification Language (RSL) [86], Petrinets [178], Live sequence charts (LSC) [63] or Statecharts [110, 111].

1.4. USED FORMAL TECHNIQUES 17

1.4.1 RAISE

RAISE [86] stands for Rigorous Approach to Industrial Software Engineering. RAISE contains aMethod: The RAISE Method, a specification and design language RSL: The RAISE SpecificationLanguage, and The RAISE Tool Set. RAISE features both functional, axiomatic, imperative,algebraic and process algebra constructs, an implementation relation, and a proof systemand thus permits formal verification of properties and steps of refinement, model as well asproperty oriented specifications, abstract as well as concrete designs of applicative as well asconcurrent systems. RAISE thus embodies the logic and features of VDM, OBJ, ccs, CSP, andStandard ML.

In the Thesis RAISE is the major formal technique. Therefore the Thesis includes Appen-dix B where one can find a short primer of RSL language.

1.4.2 Petri Nets

Petri nets were first described by Carl Adam Petri in his doctoral thesis [178] in 1962. Petrinets are composed from graphical symbols designating states (usually shown as circles), tran-sitions (usually shown as rectangles) and arrows linking states to transitions and transitionsto states. Depending on the type of Petri net, states may be called places or conditions, whiletransitions are also referred to as as events. The description of condition event nets and placetransition nets is based on Reisig [190].

In the Thesis place transition Petri nets are used in Chap. 14. Petri nets with all theiraspects can be transformed into RAISE, see Chap. 12 in [13].

1.4.3 Statecharts

Another graphical language used in the Thesis is called Statecharts [110, 111]. Statechartsprovides a graphical notation tailored for specifying the control flow and reactive systems,i.e., event-driven systems which react to internal and external stimuli. Many electronic de-vices, such as digital clocks, radios, kitchen appliances, smoke alarms, motion sensors, etc.,are reactive systems. Computer programs, such as word processors and Internet browsers,that require some form of user actions during execution are other examples of reactive sys-tems. The ‘opposite’ to reactive systems are transformational systems. They perform somecomputation and terminate once the result has been evaluated. On closer examination, areactive system actually encompasses several transformational systems, since whenever anevent triggers a transition, the resulting change of state may be expressed as a function fromstates to states, i.e., a transformation state. There are several well-established methods forspecifying transformational systems, for example, a direct definition of a function relatinginput values to output values, assuming the inputs satisfy some pre-conditions.

Statecharts extends conventional state machines and state diagrams. It does so by provid-ing a notation for hierarchical states and ways of specifying concurrency and communication.The addition of hierarchy is intended to prevent exponential increases in the number of statesrequired to model complex systems. A variant of Harel’s Statechart language has been in-cluded in UML suite of diagram types [31, 96, 133, 194].

In the Thesis we use Statecharts for modeling in Chap. 12 and 13.Chap. 14 in [13] shows how Statecharts with all their aspects can be transformed into

RAISE.

18 CHAPTER 1. INTRODUCTION

1.4.4 Message and Live Sequence Charts

Live sequence charts (LSC) is a graphical language introduced by Damm and Harel [63] forspecifying interactions between components in a system. It is an extension of the language ofmessage sequence charts (MSC). MSCs are frequently used in the specification of telecommu-nication systems and are closely related to the sequence diagram of UML [31, 96, 133, 194].Both the graphical and textual syntax of MSCs are standardised by the ITU in Recommenda-tion Z.120 [128, 129, 130]. The standard gives an algebraic semantics of MSCs. LCS extendsMSC by promoting conditions to first-class elements and providing notations for specifyingmandatory and optional behaviour.

Chap. 13 in the Thesis shows usage of MSCs for modeling line direction agreement device.MSCs and LSCs and all their aspects can be transformed into RAISE, see Chap. 13 in [13].

1.5 Thesis Structure

The Thesis is divided into seven main parts. After this first introductory part follows thesecond part called ‘Domain Foundation’. This part in five chapters presents the underlyingformal model that is used in the remaining parts of the Thesis. This whole part has beentaken up from several different sources [16, 17, 19, 20, 22, 23, 25, 27, 28] and partially modifiedand restructured to the format of the Thesis.

The third part is called ‘Railway Scheduling and Allocation’ and consist of four chap-ters. After the introductory chapter with a short overview of optimisation tasks on railwaysthere are three chapters that provide three examples of formal models (timetabling, vehiclemaintenance and rostering) in detail.

The next part called ‘Railway Signalling and Interlocking’ has four chapters. The first isan introductory chapter that provides an overview of railway control systems with referenceto bibliography. Each of the following chapters presents a formal model of various aspects ofrailway interlocking in detail. These models are: line signaling, line direction agreement andstation interlocking.

The next part — ‘Towards a Holistic Future’ is the most important part of the Thesis.It indicates the role of formal methods in integration of railway scheduling and interlockingtasks at the domain level.

There are two appendixes in the Thesis. The first provides a short introduction to formalmethods. In the second, a very short and comprehensive manual of the major formal languageof this Thesis (RSL) is given.

Part II

Domain Foundation

19

Chapter 2

Railway System

2.1 Introduction

This chapter is the first chapter of the part called ‘Domain Foundation’. This part presentsthe underlying formal model that is used in the remaining parts of the Thesis. This wholepart have been taken up from [16, 17, 19, 20, 22, 23, 25, 27, 28] and partially modified andrestructured. The whole part is also inspired by PRaCoSy project [48, 163, 164, 165, 166,167, 168, 169, 171, 180]

We also refer to another railway terminology and bibliography [170, 172, 216].

2.2 Narrative

Each railway system is composed of four main entities:

• Railway Net (see Chap. 3),

• Timetable (see Chap. 4),

• Rolling Stock (see Chap. 5),

• Passengers and Freights (see Chap. 6).

Therefore a railway system (Ω) can be modeled as a function from time (T) to statesof a railway net (N), to states of all rolling stock (RS), to its timetable (TT), to states of allpassengers (P) and freight (F).

2.3 Formal Model

typeT, N, RS, TT, P, FΩ’ = T → (N × RS × TT × (P × F))Ω= |rw:Ω’ • wf Ω(rw)|

valuewf Ω: Ω’ → Boolwf Ω(rw) ≡ well-formedness of railway states

21

22 CHAPTER 2. RAILWAY SYSTEM

2.4 Discussion

The general model was extended with the definition of the most general abstract formulasfor a ‘railway system’. This formula as we believe is the unifying and integrating part for thenext chapters. It shows a relationship between the elementary entities in the railway world.

The very important and also very interesting aspect of the previous formula is ‘well-formedness’ function. Let us discuss a little bit more about it in detail. The well-formednessfunction describes constraints that must be always met by any railway system. They are lawsof nature, e.g. trains move monotically, net changes states accordingly, etc.

Chapter 3

Railway Nets

3.1 Static

3.1.1 Basics

We introduce the phenomena of railway nets, lines, stations, tracks, (rail) units, and connec-tors. We designate such components of the rail net which can be physically demonstrated,but we abstract from number of physical attributes at the moment – they can be always besimply “added” later on.

This description is “top-down”: most composite notions are mentioned first, and definedin terms of successively less composite quantities.

Our natural, professional railway language description proceeds as follows:

1. A railway net consists of one or more lines and two or more stations.

2. A railway net consists of rail units.

3. A line is a linear sequence of one or more linear rail units.

4. The rail units of a line must be rail units of the railway net of the line.

5. A station is a set of one or more rail units.

6. The rail units of a station must be rail units of the railway net of the station.

7. No two distinct lines and/or stations of a railway net share rail units.

8. A station consists of one or more tracks.

9. A track is a linear sequence of one or more linear rail units.

10. No two distinct tracks share rail units.

11. The rail units of a track must be rail units of the station (of that track).

12. A rail unit is either a linear unit, or is a switch, or a is simple crossover, or is a switchablecrossover.

13. A rail unit has two or more connectors.

23

24 CHAPTER 3. RAILWAY NETS

14. A linear rail unit has two distinct connectors, a switch rail unit has three distinctconnectors, crossover rail units have four distinct connectors (whether simple or switch-able), etc.

15. For every connector there are at most two distinct rail units which have that connectorin common.

16. Every line of a railway net is connected to exactly two, distinct, stations of that railwaynet.

17. A linear sequence of (linear) rail units is a non-cyclic sequence of linear units such thatneighbouring units share connectors.

18. A path, p : P , is a pair of connectors, (c, c′),

19. which are distinct,

20. and of some unit.

21. A state, σ : Σ, of a unit is the set of all possible paths of that unit (at the time observed).

22. A route is a sequence of pairs of units and paths —

23. such that the path of a unit/path pair is a possible path of some state of the unit, andsuch that “neighbouring” connectors are identical.

typeN, L, S, Tr, U, C

18. P′ = C × C19. P = | (c,c′):P′ • c6=c′ |21. Σ = P-set22. R′ = (U × P)∗

23. R =| r:R′ • wf R(r) |

value1. obs Ls: N → L-set,1. obs Ss: N → S-set,2. obs Us: N → U-set,3. obs Us: L → U-set,5. obs Us: S → U-set,8. obs Trs: S → Tr-set,

9. obs Us: Tr → U-set,12. is Linear: U → Bool,12. is Switch: U → Bool,12. is Simple Crossover: U → Bool,12. is Switchable Crossover: U → Bool,13. obs Cs: U → C-set,17. lin seq: U-set → Bool

lin seq(us) ≡∀ u:U • u ∈ us ⇒ is Linear(u) ∧∃ q:U∗ • len q = card us ∧ elems q = us ∧

∀ i:Nat • i,i+1 ⊆ inds q ⇒ ∃ c:C •obs Cs(q(i)) ∩ obs Cs(q(i+1)) = c ∧

len q > 1 ⇒obs Cs(q(i)) ∩ obs Cs(q(len q)) =

21. obs Σ: U → Σ

Some formal axioms are now given:

axiom1. ∀ n:N • card obs Ls(n) ≥ 1,

1. ∀ n:N • card obs Ss(n) ≥ 2,

3. ∀ n:N, l:L • l ∈ obs Ls(n) ⇒ lin seq(obs Us(l))

4. ∀ n:N, l:L • l ∈ obs Ls(n) ⇒ obs Us(l) ⊆ obs Us(n)

5. ∀ n:N, s:S • s ∈ obs Ss(n) ⇒ card obs Us(s) ≥ 1

3.1. STATIC 25

6. ∀ n:N, s:S • s ∈ obs Ls(n) ⇒ obs Us(s) ⊆ obs Us(n)

7. ∀ n:N, l,l′:L •l,l′ ⊆ obs Ls(n) ∧ l 6= l′

⇒ obs Us(l) ∩ obs Us(l′) =

7. ∀ n:N, l:L, s:S •l ∈ obs Ls(n) ∧ s ∈ obs Ss(n)

⇒ obs Us(l) ∩ obs Us(s) =

7. ∀ n:N, s,s′:S •s,s′ ⊆ obs Ss(n) ∧ s6=s′

⇒ obs Us(s) ∩ obs Us(s′) =

8. ∀ s:S • card obs Trs(s) ≥ 1

9. ∀ n:N, s:S, t:Tr •s ∈ obs Ss(n) ∧ t ∈ obs Trs(s) ⇒ lin seq(obs Us(t))

10. ∀ n:N, s:S, t,t′:Tr •s ∈ obs Ss(n) ∧ t,t′ ⊆ obs Trs(s) ∧ t 6= t′

⇒ obs Us(t) ∩ obs Us(t′) =

11. ∀ s:S, t:Tr, u:U • u ∈ obs Us(t) ∧ t ∈ obs Trs(s) ⇒ u ∈ obs Us(s)

13. ∀ u:U • card obs Ls(n) ≥ 2

14. ∀ u:U •is Linear(u) ⇒ card obs Cs(u) = 2,is Switch(u) ⇒ card obs Cs(u) = 3,is Simple Crossover(u) ⇒ card obs Cs(u) = 4,is Switchable Crossover(u) ⇒ card obs Cs(u) = 4

15. ∀ n:N • ∀ c:C •c ∈ ⋃ obs Cs(u) | u:U • u ∈ obs Us(n)

⇒ card u | u:U • u ∈ obs Us(n) ∧ c ∈ obs Cs(u) ≤ 2

16. ∀ n:N, l:L • l ∈ obs Ls(n) ⇒∃ s,s′:S • s,s′ ⊆ obs Ss(n) ∧ s6=s′ ⇒

let sus = obs Us(s), sus′ = obs Us(s′), lus = obs Us(l) in∃ u:U • u ∈ sus, u′:U • u′ ∈ sus′, u′′,u′′′:U • u′′,u′′′ ⊆ lus •let scs = obs Cs(u), scs′ = obs Cs(u′), lcs = obs Cs(u′′), lcs′ = obs Cs(u′′′) in

∃ ! c,c′:C • c 6= c′ ∧ scs ∩ lcs = c ∧ scs′ ∩ lcs′ = c′ end end

20. ∀ u:U • let ω = obs Ω(u), σ = obs Σ(u) inσ ∈ ω ∧ ∀ (c,c′):P • (c,c′) ∈ ⋃

ω ⇒ c,c′ ⊆ obs Cs(u) end

23. wf R: R′ → Boolwf R(r) ≡

len r > 0 ∧∀ i:Nat • i ∈ inds r let (u,(c,c′)) = r(i) in

(c,c′) ∈ ⋃obs Ω(u) ∧ i+1 ∈ inds r ⇒ let ( ,(c′′, )) = r(i+1) in c′ = c′′ end end


3.1.2 Auxiliary Attributes

Networks

A network is built from units. Not all compositions of units is, however, allowed. A connectorcan never connect more than two units. Also, two units of a network share no paths. Theserules express how one may compose units into networks. For example the unit compositionsof figure 3.1 will not be legal in any network.

c1 c2 c3

c4

c5

c6

c7

Figure 3.1: Illegal compositions of units

typeN

valueobs Us: N → U-set

axiom/∗ In a network, a connector connects no more than two units ∗/∀ n:N • ∀ c:C • c ∈ ⋃ obs Cs(u) | u:U • u ∈ obs Us(n)

⇒ cardu | u:U • u ∈ obs Us(n) ∧ c ∈ obs Cs(u) ≤ 2

/∗ In a network, two units do not contain the same path ∗//∗ Needs to bee fixed ∗/∀ n:N, u,u′:U •u,u′ ⊆ obs Us(n) ∧ u 6=u′ ⇒ obs Σ(u) ∩ obs Σ(u′) =

Lines and Stations

A network consists of lines and stations. That is, the units of a network can be decomposedinto those belonging to stations and those belonging to lines. A line is a linear sequence oflinear units. A station is any set of units, including linear units, junctions (switches), cross-overs and switchable crossovers. Two lines meeting in a junction thus form a station. Thisstation, however, may just consist of that one junction (switch). The sets of units of a stationcan be decomposed into those belonging to tracks, that is routable sequences of linear units,and the rest. Part of tracks form platforms, sidings, etc. A line always connects exactly twodistinct stations.

If it is possible to find a route from a unit u to another unit u′, possibly via other units,then u can reach u′. Reachability extends, mutually, to lines, tracks and stations. Given aline and a station (to a unit of which some [end] line [unit] is connectable) it is possible toidentify exactly which tracks of the station can be reached from the line; and when given atrack of a station it is likewise possible to identify the lines that can be reached from thetrack.

3.1. STATIC 27

Station B Station C

Station A

Line

Line

Line

Line

Line Track

Figure 3.2: A network of lines and stations

typeN, L, S, Tr

valueobs Ls: N → L-set,obs Ss: N → S-set,obs Us: L → U-set,obs Us: S → U-set,obs Us: Tr → U-set,obs Trs: S → Tr-set,

/∗ Examine if a line connects to a station ∗/LS Connection: N × L × S → BoolLS Connection(n,l,s) ≡

∃ u,u′:U • u ∈ obs Us(l) ∧ u′ ∈ obs Us(s) ∧∃ c:C • obs Cs(u) ∩ obs Cs(u′) = c

pre l ∈ obs Ls(n) ∧ s ∈ obs Ss(n)

/∗ Examine if two stations are connected via a line ∗/SLS Connection: N × S × L × S → BoolSLS Connection(n,s,l,s′) ≡

LS Connection(n,l,s) ∧ LS Connection(n,l,s′),

/∗ Examine if a line connects to a track in a station ∗/LTr Connection: N × L × S × Tr → BoolLTr Connection(n,l,s,t) ≡

∃ q:U∗ • ∀ i:Nat • i,i+1 ⊆ inds q ⇒∃ c:C • obs Cs(q(i)) ∩ obs Cs(q(i+1)) = c ∧

q(1) ∈ obs Us(l) ∧ q(len(q)) ∈ obs Us(t) ∧∀ u:U • u elems tl q ⇒ u ∈ obs Us(s)

pre l ∈ obs Ls(n) ∧ s ∈ obs Ss(n) ∧ t ∈ obs Trs(s),

/∗ All lines that can be reached directly froma given track in a given station ∗/

TrLs: N × S × Tr∼→ L-set

TrLs(n,s,t) ≡l | l:L • l ∈ obs Ls(n) ∧ LTr Connection(n,l,s,t)pre t ∈ obs Trks(s) ∧ s ∈ obs Ss(n),

/∗ All tracks in a given station that can be reacheddirectly from a given line ∗/

LTrs: N × L × S∼→ Trk-set

LTrs(n,l,s) ≡t | t:Tr • t ∈ obs Trs(s) ∧ LTr Connection(n,l,s,t)pre l ∈ obs Ls(n) ∧ s ∈ obs Ss(n),

/∗ Examine if a set of units is part of some network ∗/IsInNet: U-set → BoolIsInNet(us) ≡ ∃ n:N • us ⊆ obs Us(n),

axiom∀ n:N, l,l′:L, s,s′:S, t,t′:Tr, c:C, u:U •

/∗ Lines are part of some network ∗/IsInNet(obs Us(l)),

/∗ Lines consist only of linear units ∗/u ∈ obs Us(l) ⇒ is Linear(u),

/∗ Tracks are part of some station ∗/∃ s:S • obs Us(t) ⊆ obs Us(s),

/∗ Tracks consist of linear units ∗/u ∈ obs Us(t) ⇒ is Linear(u),

/∗ Tracks of a station do not intersect ∗/t,t′ ⊆ obs Trs(s) ∧

t6=t′ ⇒ obs Us(t) ∩ obs Us(t′) = ,


/∗ Lines in a network do not intersect ∗/l,l′ ⊆ obs Ls(n) ∧ l 6=l′ ⇒

obs Us(l) ∩ obs Us(l′) = ,

/∗ Stations are part of some network ∗/IsInNet(obs Us(s)),

/∗ Stations in a network do not intersect ∗/s,s′ ⊆ obs Ss(n) ∧ s 6=s′ ⇒

obs Us(s) ∩ obs Us(s′) = ,

/∗ Lines and stations do not intersect ∗/

l ∈ obs Ls(n) ∧ s ∈ obs Ss(n) ⇒obs L Us(l) ∩ obs S Us(s) = ,

/∗ Lines connect exactly two stations ∗/l ∈ obs Ls(n) ⇒

∃ s,s′:S •s6=s′ ∧ s,s′ ⊆ obs Ss(n) ∧SLS Connection(n,s,l,s′),

/∗ Stations do not have common connectors ∗/s,s′ ⊆ obs Ss(n) ∧ s6=s′ ⇒

Us Cs(obs Us(s)) ∩ Us Cs(obs Us(s′)) =

Later we shall see that the setting of routes that connect lines and tracks is a typical stationmanagement function (see Chap. 14) — and, under appropriate technologies, is supported bysolid state interlocking.

Stations have names (or identifiers). No two stations share the same name, though, andno station has two names. From a network, a map from station names to stations can beextracted.

typeSn

valueobs SnSm: N → (Sn →m S),

Sns: N → Sn-setSns(n) ≡ dom obs SnSm(n)

axiom∀ n:N • obs Ss(n) = rng obs SnSm(n) ∧ card obs Ss(n) = card Sns(n)

Unit Attributes

With units we can associate a large variety of attributes (types), and for each attribute arange of values. Examples are:

1. Lengths: The lengths, say in meters, of a unit, may be given as a map from paths tolengths.

2. Topology: The topology, from which we could derive the lengths, of a unit, describes —for example as a sequence of Bezier curve triples — the three dimensional layout of theunit: its co-ordinates so-to-speak. Included would also be additional information on therelative “tilting” of rails in curves, etc.

3. Context: The context of a unit tells us whether it is positioned on a bridge, in a tunnel,along a platform, along a quay, etc. Context information may determine maximum andminimum train speeds.

4. &c.

3.1. STATIC 29

Path

A path (through a unit) is a pair of connectors. A path designates a possible direction oftrain traffic through a unit.

The physical state of a unit is a set of paths. The state contains all the paths that arepossible directions of travel through the unit.

Every unit has a set of possible (physical) states, the state space. These possible statesare determined by, for instance, the shape and physical layout of the unit. The set of possiblestates may also contain states that are not intended and should never appear on the rail net.These may include situations of broken switchpoints etc. Nevertheless, these states may occurand should therefore be included in the intrinsic model.

typeP = C × C,Σ = P-set,

valueobs Σ: U → Σ,

/∗ All physically possible paths through a unit ∗/U Ps: U → P-setU Ps(u) ≡

p | p:P • ∃ σ:Σ •σ ∈ obs U Ω(u) ∧ p ∈ σ

,

/∗ All connectors of a set of units ∗/Us Cs: U-set → C-set

Us Cs(us) ≡ c | c:C •

∃ u:U • u ∈ us ∧ c ∈ obs U Cs(u)

axiom/∗ The physical state is in the set of all states ∗/∀ u:U • obs U Physical Σ(u) ∈ obs U Ω(u),

/∗ All connectors of paths in states are connectors of the unit ∗/∀ u:U, σ:Σ, (c,c′):P •

σ ∈ obs U Ω(u) ∧ (c,c′) ∈ σ ⇒c,c′ ⊆ obs U Cs(u),

A linear unit, with connectors c, c′ will usually only have one possible physical state:

(c, c′), (c′, c)

The unit gives rise to potentially four different managed states:

, (c, c′), (c′, c), (c, c′), (c′, c)

c c’ c c’ c c’ c c’

Figure 3.3: States of a linear unit

In the last state the unit is open for traffic in both directions!There are several kinds of junction units. A certain junction unit, u, with connectors c′, c′′

at one end and connector c at the other end may for instance have three possible physicalstates:

(c′, c), (c′′, c), (c, c′), (c′, c)and(c, c′′), (c′′, c)

The unit potentially has eight possible managed states:

1. σ0 : (closed),


2. σ1 : (c, c′) (open in one direction, from “tongue” to left fork),

3. σ2 : (c, c′′) (open in one direction, from “tongue” to right fork),

4. σ3 : (c′, c) (open in one direction, from left fork to “tongue”),

5. σ4 : (c′′, c) (open in one direction, from right fork to “tongue”),

6. σ5 : (c′, c), (c′′, c) (open in two directions, from either fork to “tongue”)

7. σ6 : (c, c′), (c′, c) (open in two directions, from right fork to “tongue” and from“tongue” to right fork)

8. σ7 : (c, c′′), (c′′, c) (open in two directions, from left fork to “tongue” and from“tongue” to left fork)

There are also several kinds of crossover units. A crossover unit with connectors c, c′ andc′′, c′′′ at respective ends may for instance have only one possible physical state:

(c, c′′′), (c′′′, c), (c′, c′′), (c′′, c′)

The unit will have 16 possible managed states.closed: four open in one direction:

(c, c′′′), (c′′′, c), (c′, c′′), (c′′, c′)

six open in two directions:

(c, c′′′), (c′′′, c), (c′, c′′), (c′′, c′), (c, c′′′), (c′, c′′), (c′′′, c), (c′′, c′), (c′′, c′), (c, c′′′), (c′, c′′), (c′′′, c)

four open in three directions:

(c, c′′′), (c′′′, c), (c′, c′′), (c, c′′′), (c′′′, c), (c′′, c′), (c′, c′′), (c′′, c′), (c, c′′′), (c′, c′′), (c′′, c′), (c′′′, c′)

and one open in four directions:

(c, c′′′), (c′′′, c), (c′, c′′), (c′′, c′)

Etcetera for other forms of units.Using the possible states of units, one can put further constraints on different kinds of

units. For instance, there should be a physical state of any linear unit, such that it is openfrom one end to the other. For a junction, travel should be possible from or to both forksand travel should not be possible between forks.

axiom∀ u:U •

is Linear U(u) ⇒ U Ps(u) 6=,is Junction U(u) ⇒

∃ c1,c2,c3:C • card c1,c2,c3 = 3 ∧(c1,c2),(c2,c1) ∩ U Ps(u) 6= ∧(c1,c3),(c3,c1) ∩ U Ps(u) 6= ∧

(c2,c3),(c3,c2) ∩ U Ps(u) = ,is Crossover U(u) ⇒

∃ c1,c2,c3,c4:C • card c1,c2,c3,c4 = 4 ∧(c1,c4),(c4,c1) ∩ U Ps(u) 6= ∧(c2,c3),(c3,c2) ∩ U Ps(u) 6= ∧(c1,c3),(c3,c1) ∩ U Ps(u) = ∧(c2,c4),(c4,c2) ∩ U Ps(u) =

3.1. STATIC 31

Routes

The concept of routes plays an important role in speaking about train journeys. A route is asequence of connectors. The connectors of a route designate paths in some network. That is,directions of travel.

A route is feasible in a network, if the route describes only the possible paths throughunits of the network.

The rule that two units of a network share no paths ensures that a feasible route of anetwork describes a unique sequence of unit-paths through the network. That is, given afeasible route of a network, it is possible to find the units of the route in that network.

A routable set of units is a set of units, such that there is a route through the units thatincludes all units in the set. That is, it is physically possible to travel along a route throughthe units, though it may not be allowed by the current states of the units of the route.

A route is cyclic in a network if it contains two or more paths through the same unit, suchthat these paths end in the same connector. That is an acyclic route may very well containseveral paths through the same unit, as long as the exit-connectors of these paths are distinct.

U1

U2

c1 c2

c3

U3 U4

U5

c4 c5

c6c7

c8

Units without cyclic route Units with cyclic route

Figure 3.4: Cyclic and acyclic routes

This means that in figure 3.4, the route

〈 c1,c2,c3,c1 〉

is an acyclic route, while the route

〈 c4,c5,c6,c7,c5,c8 〉

is cyclic.

typeRt′ = C∗,Rt = | rt:Rt′ • wf Rt(rt) |

value/∗ Wellformed routes have lenght at least two and

are feasible in some network ∗/wf Rt: Rt′ → Boolwf Rt(rt) ≡ len rt ≥ 2 ∧ ∃ n:N • feasible Rt(rt,n),

/∗ A route is feasible wrt a network if the route designatespossible paths in the network and the route does notdesignate two succesive paths through the same unit ∗/

feasible Rt: Rt′ × N → Boolfeasible Rt(rt,n) ≡


Rt possible paths(rt,n) ∧let ul = Rt Ul(rt,n) in

∼∃ i:Nat • i,i+1 ⊆ inds ul ∧ ul(i)=ul(i+1)end

pre len rt ≥ 2,

/∗ Route describes possible paths of units in a network ∗/Rt possible paths: Rt′ × N → BoolRt possible paths(rt,n) ≡

∀ i:Nat • i,i+1 ⊆ inds rt ⇒∃ u:U • u ∈ obs N Us(n) ∧ (rt(i),rt(i+1)) ∈ U Ps(u),

/∗ The list of units designated by a route ∗/Rt Ul: Rt × N

∼→ U∗

Rt Ul(rt,n) as ulpost

len ul = (len rt)−1 ∧elems ul ⊆ obs N Us(n) ∧∀ i:Nat • i,i+1 ⊆ inds rt ⇒ (rt(i),rt(i+1)) ∈ U Ps(ul(i))

pre Rt possible paths(rt,n) ∧ len rt ≥ 2,

/∗ The list of paths designated by a route ∗/Rt Pl: Rt → P∗

Rt Pl(rt) ≡ 〈 (rt(i),rt(i+1)) | i in 〈 1 .. (len rt)−1 〉〉,

/∗ All units of a route ∗/Rt Us: Rt × N

∼→ U-setRt Us(rt,n) ≡ elems Rt Ul(rt,n)pre feasible Rt(rt,n),

/∗ The first connector of a route ∗/Rt firstC: Rt → CRt firstC(rt) ≡ hd rt,

/∗ The last connector of a route ∗/Rt lastC: Rt → CRt lastC(rt) ≡ rt(len rt),

/∗ The first unit of a route ∗/Rt firstU: Rt × N

∼→ URt firstU(rt,n) ≡ hd Rt Ul(rt,n)pre feasible Rt(rt,n),

/∗ The last unit of a route ∗/Rt lastU: Rt × N

∼→ URt lastU(rt,n) ≡ let ul = Rt Ul(rt,n) in ul(len ul) endpre feasible Rt(rt,n),

/∗ All feasible routes of a network ∗/N Rts: N → Rt-setN Rts(n) ≡ rt | rt:Rt • feasible Rt(rt,n) ,

/∗ A route does not go through the same unit twice ∗/Rt DisjUs: Rt × N

∼→ BoolRt DisjUs(rt,n) ≡ card Rt Us(rt,n) = len Rt Ul(rt,n)pre feasible Rt(rt,n),

3.2. DYNAMICS 33

/∗ Two routes are disjoint ∗/Rt Disj: Rt × Rt × N

∼→ BoolRt Disj(rt,rt′,n) ≡ Rt Us(rt,n) ∩ Rt Us(rt′,n) = pre feasible Rt(rt,n) ∧ feasible Rt(rt′,n),

/∗ All possible routes through a set of units ∗/Us Rts: U-set

∼→ Rt-setUs Rts(us) ≡

rt | rt:Rt •∃ n:N •

us ⊆ obs N Us(n) ∧feasible Rt(rt,n) ∧Rt Us(rt,n) ⊆ us

pre net Us(us),

/∗ All possible routes that use all units in a set ∗/Us complete Rts: U-set

∼→ Rt-setUs complete Rts(us) ≡

rt | rt:Rt •∃ n:N •

rt ∈ N Rts(n) ∧feasible Rt(rt,n) ∧Rt Us(rt,n) = us

pre net Us(us),

/∗ There is a route through all units in a set ∗/is RoutableUs: U-set → Boolis RoutableUs(us) ≡ Us complete Rts(us) 6= pre net Us(us),

/∗ Route is cyclic ∗/is Cyclic Rt: Rt × N → Boolis Cyclic Rt(rt,n) ≡

∃ i,j:Nat • i,i+1,j,j+1 ⊆ inds rt ∧ i 6=j ∧(Rt Ul(rt,n)(i),rt(i+1)) = (Rt Ul(rt,n)(j),rt(j+1))

pre feasible Rt(rt,n)

3.2 Dynamics

3.2.1 Basics

We introduce defined concepts such as paths through rail units, state of rail units, rail unitstate spaces, routes through a railway network, open and closed routes, trains on the railwaynet, and train movement on the railway net.

1

1. A unit may, over its operational life, attain any of a (possibly small) number of differentstates ω, Ω.

1A path of a unit designate that a train may move across the unit in the direction from c to c′. We saythat the unit is open in the direction of the path.


2. An open route is a route such that all its paths are open.

3. A train is modelled as a route.

4. Train movement is modelled as a discrete function (ie., a map) from time to routes suchthat for any two adjacent times the two corresponding routes differ by at most one ofthe following:

(a) a unit path pair has been deleted (removed) from one end of the route;

(b) a unit path pair has been deleted (removed) from the other end of the route;

(c) a unit path pair has been added (joined) from one end of the route;

(d) a unit path pair has been added (joined) from the other end of the route;

(e) a unit path pair has been added (joined) from one end of the route, and anotherunit path par has been deleted (removed) from the other end of the route;

(f) a unit path pair has been added joined) from the other of the route, and anotherunit path par has been deleted (removed) from the one end of the route;

(g) or there have been no changes with respect to the route (yet the train may havemoved);

and such that the new route is a well–formed route.

We shall arbitrarily think of “one end” as the “left end”, and “the other end”, hence, as the“right end” — where ‘left’, in a model where elements of a list are indexed from 1 to itslength, means the index 1 position, and ‘right’ means the last index position of the list.

type1. Ω = Σ-set3. Trn = R4. Mov′ = T →m Trn4. Mov = | m:Mov′ • wf Mov(m) |

value1. obs Ω: U → Ω

axiom2. open R: R → Bool

open R(r) ≡∀ (u,p):U×P • (u,p) ∈ elems r ∧ p ∈ obs Σ(u)

4. wf Mov: Mov → Boolwf Mov(m) ≡ card dom m ≥ 2 ∧

∀ t,t′:T • t,t′ ∈ dom m ∧ t < t′∧ adjacent(t,t′) ⇒

let (r,r′) = (m(t),m(t′))(u,p):U×P • p ∈

⋃obs Ω(u) in

4a. (l d(r,r′,(u,p)) ∨4b. r d(r,r′,(u,p)) ∨4c. l a(r,r′,(u,p)) ∨4d. r a(r,r′,(u,p)) ∨4e. l d r a(r,r′,(u,p)) ∨4f. r d l a(r,r′,(u,p)) ∨4g. r=r′)

end

The last line route’s well–formedness ensures that the type of Mov is maintained.

valueadjacent: T × T → Booladjacent(t,t′) ≡ ∼∃ t′′:T • t′′ ∈ dom m ∧ t < t′′ < t′

l d,r d,l a,r a,l d r a,r d l a: R × R × P → Bool

l d(r,r′,(u,p)) ≡ r′ = tl r pre len r>1r d(r,r′,(u,p)) ≡ r′ = fst(r) pre len r>1

l a(r,r′,(u,p)) ≡ r′ = 〈(u,p)〉rr a(r,r′,(u,p)) ≡ r′ = r〈(u,p)〉l d r a(r,r′,(u,p)) ≡ r′ = tl r〈(u,p)〉r d l a(r,r′,(u,p)) ≡ r′ = 〈(u,p)〉fst(r)

fst: R∼→ R′

fst(r) ≡ 〈 r(i) | i in 〈1..len r−1〉〉

3.2. DYNAMICS 35

If r as argument to fst is of length 1 then the result is not a well–formed route, but is inR′.

3.2.2 Auxiliary Attributes

Path: Open and Closed

A path through a unit is physically open, if it is in the physical state of the unit. If not inthe state, the path is physically closed.

The managed state of a unit is a subset of the paths in the physical state of the unit.The managed state contains the paths that are intended directions of travel through the unit.That is, the rail net management allow only the traffic to use paths in the managed states ofunits. The managed state will, for instance, depend on states of light signals, laws of traffic,signs at the rail, etc.

A path through a unit is managed open if it is in the managed state of the unit. If not inthe managed state, the path is managed closed.

An empty managed state designates a closed unit. That is, no traffic is intended throughthe unit.

The managed state of a unit depends on management decisions. The position of the unitin the network will often have effect on the managed state. For instance, units before thehump of a marshalling yard are typically only open in the direction of the hump, and afterthe hump, away from the hump. The managed states of units in the network are known tothe rail net management.

typeP = C × C,Σ = P-set,Ω = Σ-set

valueobs U Ω: U → Ω,

obs U Physical Σ: U → Σ,obs U Managed Σ: U → Σ,

axiom/∗ Managed states are subsets of Physical states ∗/∀ u:U • obs U Managed Σ(u) ⊆ obs U Physical Σ(u)

Routes: Open and Closed

A route is physically open in a given network, if the connectors of the route designate physi-cally open paths in units of the network. That is, the units are open in the direction of theroute.

A route is managed open in a given network, if the connectors of the route designatemanaged open paths in units of the network.

typeRt′ = C∗,Rt = | rt:Rt′ • wf Rt(rt) |

value

/∗ Examine if a route is physically open ∗/is Physical OpenRt: Rt × N

∼→ Boolis Physical OpenRt(rt,n) ≡

∀ i:Nat • i,i+1 ⊆ inds rt ⇒

(rt(i),rt(i+1)) ∈ obs U Physical Σ(Rt Ul(rt,n)(i))pre feasible Rt(rt,n),

/∗ Examine if a route is managed open ∗/is Managed OpenRt: Rt × N

∼→ Boolis Managed OpenRt(rt,n) ≡

∀ i:Nat • i,i+1 ⊆ inds rt ⇒(rt(i),rt(i+1)) ∈ obs U Managed Σ(Rt Ul(rt,n)(i))

pre feasible Rt(rt,n),


Train Routes

A train route is a route. The intuition behind a train route is that a train occupies exactlythe units designated by its train route in some network.

A wellformed move of a train route is that of not changing the route, adding a connector tothe end of the route, removing a connector from the beginning of the route or simultaniouslyadding a connector to the end and removing a connector from the beginning of the route.Thus, a train route may only be moved in the “forward” direction.

typeTR = Rt

valuewf TR move: TR × TR → Bool

wf TR move(tr,tr′) ≡tr′=tr ∨tr′=tl tr ∨∃ c:C • tr′=tr〈c〉 ∨ tr′=(tl tr)〈c〉

It is possible to determine whether a train is in a given station or at a given track. Thiscan be done by inspecting the train route that contains the train.

valueTR at S: TR × S → BoolTR at S(tr,s) ≡ tr ∈ S Rts(s),

TR at Trk: TR × Trk → Bool

TR at Trk(tr,trk) ≡ tr ∈ Trk Rts(trk),

TR at StaTrk: TR × S → BoolTR at StaTrk(tr,s) ≡

∃ trk:Trk • trk ∈ obs S Trks(s) ∧ TR at Trk(tr,trk)

Managed Rail Nets

A managed rail net “snap shot”, i.e. a managed rail net state, is a rail net where all units arein each their own state.

We do not, in this description of the ‘intrinsics’, define what sets and changes the state.But we prepare the reader for it: it is, of course, the combined setting of junctions (switches),light signals (semaphores) and conventions, that determine the state. Take a line, as anexample. It may be subdivided into segments or blocks, each consisting, say, of one unit, andeach such segment or block being delineated by a signal. (That is: the signal is at or aboutthe point where two segments (units) are connected.) A green signal means that the segmentright after that signal is open. Etcetera!

Since rail nets are regularly being updated: new line and station units are added, oldremoved entirely, or put under repair, etc., we have that a managed rail net is a function fromtime to rail net states.

Since changes (extensions, reductions) to the rail net are incremental: most of a rail netremains unchanged while a “small” part undergoes changes, we impose some reasonable ruleof monotonicity world formation of managed rail nets. To define the monotonicity conceptfor managed rail nets we introduce the concept of a rail net change.

A simple change may remove a proper subset of (closed) units, or may insert, i.e. connecta new set of (initially closed) units:

• A simple removal involves the proper closing of all affected units: those to be removedand possibly also all immediately connected (i.e. neighbouring) units, followed by re-moval.

(After the removal, previously neighbouring units may be reopened.)

3.2. DYNAMICS 37

• A simple insertion involves a sequence of up to four rail net actions: closing of someunits, their removal, insertion of a set of new, but closed units, and the possible openingof these (new) units.

The set of units removed and the set of units inserted usually have no units in common.For a unit to be inserted it must share a number of connectors with already existingrail net units.

Given two successive managed rail net states, there is a finite, possibly empty set of railnet removal and insertion changes, each change defined in terms of rail net closing, removal,insertion and opening actions.

T,MR′ = T → N,MR = | mr:MR′ • wf MR(mr) |

valuewf MR: MR′ → Boolwf MR(mr) ≡

∀ t:T • ∃ t′:T • t′>t ∧∀ t′′:T • t≤t′′≤t′ ⇒ MoN(mr(t),mr(t′′)),

MoN: N × N → Bool,

/∗ Removed or inserted stations contain only closed units ∗/rem ins S closed: N × N → Boolrem ins S closed(n,n′) ≡

∀ s:S •s ∈ (obs N Ss(n)\obs N Ss(n′)) ∪ (obs N Ss(n′)\obs N Ss(n)) ⇒

managed closed Us(obs S Us(s)),

/∗ Removed or inserted lines contain only closed units ∗/rem ins L closed: N × N → Boolrem ins L closed(n,n′) ≡

∀ l:L •l ∈ (obs N Ls(n)\obs N Ls(n′)) ∪ (obs N Ls(n′)\obs N Ls(n)) ⇒

managed closed Us(obs L Us(l)),

managed closed Us: U-set → Boolmanaged closed Us(us) ≡

∀ u:U • u ∈ us ⇒ obs U Managed Σ(u) = axiom

∀ n,n′:N • MoN(n,n′) ⇒rem ins S closed(n,n′) ∧rem ins L closed(n,n′)

Stable, Transition and Re–organisation States

A unit is at any moment of time either in a stable state, or in a transition state, or in areconfiguration state. A rail unit event is one where a rail unit changes from one kind of stateto another. In all: Three kinds of states and four kinds of events.

We have decided to model “transitions” from stable states to stable states as not takingplace instantaneously, but having some time duration. During that time of change we saythat the rail unit is in the transition state.


Reconfiguration states are like transition states, but, in addition, the rail units changesbasic characteristics.

Time and State Durations

Units remain in stable, transition and reconfiguration states “for some time”! We decide toendow each unit with possibly different minimum stable state, and maximum transition andreconfiguration state durations: A unit, irrespective of its state, must remain in any stablestate for a minimum duration of time. A unit, irrespective of its state, at most remains inany transition state for a maximum duration of time. A unit, irrespective of its state, atmost remains in any reconfiguration state for a maximum duration of time. The stable stateminimum duration is (very much) larger than the maximum re–configuration duration, whichagain is (very much) larger than the maximum transition duration.

typeT /∗ T is some limited, dense time range ∗/∆ /∗ δ: ∆ is some time duration ∗/s∆ = ∆, t∆ = ∆, r∆ = ∆

valuelo T: U → Tobs ` T: U → Tobs s∆: U → s∆,obs t∆: U → t∆,obs r∆: U → r∆¿,<,>,À: ∆ × ∆ → Bool¿,<,>,À: T × T → Bool+,−: T × ∆ → T∗: ∆ × Real → ∆ pre δ∗r: r>0

axiom∀ u:U •

obs s∆(u)Àobs r∆(u)Àobs t∆(u),∀ 1δ,2δ:∆ •

1δ¿2δ⇒1δ<2δ ∧ 1δÀ2δ⇒1δ>2δ

Stable States

A stable state (of a unit) is a possibly empty set of pairs of connectors of that unit. At anyone time, when in a stable state, a unit is willing to be in any one of a number of states, its(current) state space. If a pair of connectors is in some stable state then that means that atrain can move across the unit in the direction implied by the pairing: from the first connectorto the second connector. A unit in a stable state has been so for a duration — which weassume can be observed.

Figure 3.5 shows the possible stable states of the switch.The arrows of Figure 3.5 shall designate possible (“open”) directions of (allowed, “free”)

movement. To be able to compare units, and to say that a unit at one time, in some state,“is the same” as a unit, at another time, in another state, we introduce a “normalisation”function: nor Σ. It behaves as if it “reset” the current state of a unit to the empty state, andas if the elapsed time “zero” — leaving everything else unchanged.

3.2. DYNAMICS 39

C C

CCC

C

C

C

C C C

Closed

C

C/

C|

C/ C/ C/

C/C/C/C/

C/ C/ C/ C/

C| C| C|

C|C|C|C|

C| C| C| C|

Figure 3.5: States of Switch Unit

typePS = P-setsΣ = PS

valueis sΣ: U → Bool

obs sΣ: U∼→ sΣ

obs sΩ: U → sΩobs ∆: U → ∆

obs s∆: U → s∆nor Σ: U → U

axiom∀ u:U •

is sΣ(u) ⇒obs sΣ(u) ∈ obs sΩ(u) ∧obs sΣ(u) ⊆ obs Ps(u) ∧obs sΣ(nor Σ(u)) =

In

Miscellaneous Sidings

Out

Misc.Misc.

Hump

Figure 3.6: Marshalling Yard

Transition States

When a unit is in a transition state it is making a transition from one stable state to another.We now make the following crucial modelling decision: Since we are dealing, throughout,

with man–made phenomena, with entities most of whose properties we “design into” thesephysical “gadgets”, we can assume the following: That we can observe from the rail units“their intention”: Namely, in this case, that they are to make a transition from one, known,


stable state to another, known, stable state, and that, at any one time of observing such atransition, we can also observe the elapsed time duration since the start of a transition.

typetΣ=|(s′σ,s′′σ):(sΣ×sΣ)•s′σ 6=s′′σ|tΩ = tΣ-set

valueis tΣ: U → Boolobs tΣ: U → tΣobs tΩ: U → tΩ

obs ∆: U → ∆obs t∆: U → t∆

axiom∀ u:U,s′σ,s′′σ:Σ •is tΣ(u) ⇒ (s′σ,s′′σ) = obs tΣ(u) ⇒

(s′σ,s′′σ) ∈ obs tΩ(u)∧s′σ,s′′σ⊆obs sΩ(u)

The dynamics of this change will be elaborated upon later. Suffice it to hint that thechange from a stable state to the “beginning” of a transition state is an event, likewise is thechange from a transition state to the stable state, and the stable state of the unit “just” beforethe transition state must be the same as the first stable state of the pair of the transitionstate, while the stable state of the unit “just” after the transition state must be the same asthe second stable state of the pair of the transition state.2

Reconfiguration States

A rail unit may be subject to reconfiguration: In a net some existing (ie., “old”) rail unitsneed to be “changed” by allowing “additional”, or dis–allowing “previously valid” paths, hencechanging the state space, or by allowing new kinds of transitions, or both. Reconfigurationadditionally permits new units to be “connected” to existing units’ “dangling” connectors.

A rail unit reconfiguration thus changes its state space — from a past to a future statespace, and therefore also by changing into a future transition state space, while possiblychanging the unit from one stable state (of the past state space) to another (of the futurestate space) — where we impose the seemingly arbitrary constraint that the transition state(ie., the pair of before and after stable states) must be in both the “old” and the “new” setof transition states.

typerΣ′ = (sΩ×sΣ×tΩ)×(tΩ×sΣ×sΩ)rΣ = | rσ:rΣ′ • wf rΣ(rσ) |

valuewf rΣ: rΣ′ → Boolwf rΣ((s′ω,s′σ,t′ω),(t′′ω,s′′σ,s′′ω)) ≡

s′σ ∈ s′ω ∧ s′′σ ∈ s′′ω ∧(s′σ,s′′σ) ∈ t′ω ∩ t′′ω ∧

⋃s′ω ∪ ⋃

s′′ω⊆obs Ps(u) ∧∀ (saσ,sbσ):tΣ •

(saσ,sbσ) ∈ t′ω ⇒ saσ,sbσ ⊆ s′ω ∧(saσ,sbσ) ∈ t′′ω ⇒ saσ,sbσ ⊆ s′′ω

is rΣ: U → Bool

obs rΣ: U∼→ rΣ

obs ∆: U → ∆obs r∆: U → r∆

We observe that a reconfiguration state consists of a pair of “reversed” triples: Thebefore and after reconfiguration stable state spaces (listed “outermost”), the before and aftertransition state spaces (listed “middle–most”), and the before and after stable states (listed“innermost” — all wrt. the “comma” that separates the two triples). For a reconfigurationstate to be well–formed the before and after stable states must be in respective (“old”, resp.“new”) stable state spaces; the transition state formed by these must be in both the beforeand in the after transition state spaces; the set of paths of both the stable state spaces beforeand after must be in the paths of the unit — which thus does not change (!); and for all

2We allow this seeming redundancy of representation in order to simplify some subsequent formalisations.

3.2. DYNAMICS 41

before [after] stable states of the transitions must be in the before [resp. after] stable statespaces. We may have to remove constraint that the total path set does not change underreconfiguration: Presently it is a refutable assertion.

We thus see that a reconfiguration state embodies also a transition state. And thus weinherit many of the constraints expressed earlier. Now they are part of the well–formedness ofany reconfiguration state. For the other state types, sorts were constrained via the axioms. Anumber of decisions have been made: We have decided, in this model, to maintain “redundant”“information”: The before and after stable state spaces, as well as transition state spaces. Andwe have decided to impose a further “commonality” constraint: The actual state transitiontaken (“undergone”) during reconfiguration must be one that was allowed before, as well asbeing allowed after, reconfiguration.

Dynamical Units

A railway net of many units, all timed to the same clock and time period, can be consideredideally a programmed, dynamic active system, less ideally, a dynamic reactive system.

These terms. ‘programmed, dynamic active system’, respectively ‘dynamic reactive sys-tem’, are, for the realm of computing science and software engineering, that is: Programmingmethodology, described in [132].

In this section we shall consider railway nets to be ‘programmed’. That is: It is us,the managers of railway nets, who control the time–wise behaviour of the net — to a firstapproximation. To a second approximation, when ordering the rail units to undergo a recon-figuration and/or a transition, such changes may involve a time duration, such as modelledabove. During those durations the rail units behave reactively: Over the time period of theduration they “switch state” in reaction to a control signal.

Although we shall thus primarily consider railway nets as programmed, active dynamicsystems, we shall bring a model which appears to model railway nets as more general dynamic,active systems. But one should understand these models appropriately: As reflecting what canbe observed from outside the system of railway nets plus their control. We shall subsequentlyreview the above distinctions.

The behaviour of a unit, as seen from outside the railway net and its control, is that itchanges from being in stable states and making transitions between these. A state transitionis from the stable state before to the stable state after the transition. The stable statecomponents of transition states must be in the current state space. A reconfiguration statetransition has its stable states being in the intersection of, ie., in both, the before and afterstable state spaces. (This constraint has already been formally expressed.)

Timed Units

We now “lift” a unit to be a timed unit: That is, a function from time, in some dense interval,to “almost the same” unit ! We assume that we can delimit time intervals so that each timedunit is described as from some lower (lo T) time upwards !

typeT /∗ T dense, with lower boun ∗/TU = T → U

valuelo T: TU → T

` T: (TU|U) → Taxiom

∀ tu:TU • unique TU(tu)value

unique TU: TU → Bool


unique TU(tu) ≡ ∀ t,t′:T • t,t′⊆D tu∧ no rΣs(tu)(t,t′)⇒same Us(tu(t),tu(t′))

no rΣs: TU → (T × T) → Boolno rΣs(tu)(t,t′) ≡ is sΣ(tu(t)) ∧ is sΣ(tu(t′))

∧ ∼∃ t′′:T • t<t′′<t′ ∧ is rΣ(tu(t′′))

same Us: U-set → Boolsame Us(us) ≡ ∀ u,u′:U • us ⊆ obs sΩ(u)∧ obs sΣ(nor U(u)) = obs sΣ(nor U(u′))assert: ∀ u′′:U•u′′ ∈ us ⇒ us ⊆ obs sΩ(u′′)

tu:TUs are continuous functions over their lower limited, although infinite definition setof times.

Operations on Timed Units

In the following we will abstract from the two operations that are implied by the transitionstate, and the reconfiguration state. That is: We think, now, of these states as having beenbrought about by controls, ie., by external events and communication between an environmentand the net (or, as in the case of timed rail units, between an environment and respectiveunits).

So an operation on a timed unit is something that takes place, at some time, say τ , andwhich involves an operator. The meaning of the operator is what we model, not the syntaxthat is eventually needed in order to concretely implement the operation. And that meaningwe take to involve the following entities: A function, φ, which is like a timed unit, exceptthat its lower time limit is like “0”. And a time duration, oδ, for the operation.

The idea is now that applying an operation φ at time τ , means that the timed unitfunction, tu, is “extended” by “ glueing” the operation function φ to tu “chopped” at τ .After the operation has completed, at time τ+oδ, the unit remains in the state it was left inby φ at the end of its completion.

valuelo δ:∆, hi δ:∆

axiom[ lo δ `behaves like zero′′ ]

typeΘΦ = Φ∆ → U

/∗ Φ∆: continuous relative time interval ∗/Φ∆ = loδ..hiδ

valueobs Φ: Θ → Φ

obs o∆: Θ → hi δ .. lo δOP: Θ → TU → T → TUOP(θ)(tu)(τ) ≡

let φ = obs Φ(θ),oδ = obs o∆(θ) assert: oδ=hi δ−lo δ,lo t = lo T(tu) in

λ t:T • if t<lo t then chaoselsif lo t≤t≤τ then tu(t)elsif τ<t<τ+oδ then φ(t−τ)elsif t≥τ+oδ then φ(oδ) end end

We express the new timed unit function as a function of the old, namely tu, and theoperation function, φ. The “new”, “updated” timed unit behaves as follows: It is not definedfor times earlier than the lowest time for which tu was defined. It behaves a tu for timesbetween that lowest time and the present time, τ . For the next time interval, namely forthe duration of the operation, it behaves as φ, and thereafter it remains stable (“until a nextoperation” is applied”). The above is expressed in the λ–Notation: λt:T•E(args) dentes thefunction which when applied to arguments vals behaves as is expressed by the expressionE(args) where vals have been substituted for args.

In the above — generalised — formulation of the effect of operations on timed units wehave abstracted from whether these “stood” for state transitions or state reconfigurations.

3.2. DYNAMICS 43

We have also made a number of general assumptions. These we now describe and formalise:The initial unit of the operation must be compatible with (for simplicity we here take it tobe: the same as) the unit of the timed unit at the time the operations is applied.

OP(θ)(tu)(τ) ≡ ...pre obs Φ(θ)(lo δ) = tu(τ)

One can think of the following constraint being already “syntactically” expressed in thespecification of transition and reconfiguration states. We refer to Section 3.2.2 and Sec-tion 3.2.2. These state change specifications (“redundantly”) specified the “before” and “af-ter” states, where specifying the “after”, ie., the final state, would have sufficed.

We leave it to another occassion to provide a proper linkage between specifying the syn-tactics of the operations and the already specified state change types.

State Sequences

In the previous section we view timed units as something that changed only as the result ofapplying operations to the (timed) units. In this section we shall revert to looking at timedunits as entities which have observable behaviour — ie., which can be observed from a vantagepoint “outside” the units and the “control machinery” that effects the operations.

Any one unit resides in a sequence of “adjacent” states: (i) For some time in a stablestate, ψ, (ii) then, perhaps for a short time in a transation state: ψ 7→ ψ′, (iii) then, as (i–ii):for some time in ψ′, then ψ′ 7→ ψ′′, etc.: (iv) ψ′′, ψ′′ 7→ ψ′′′, ψ′′′, ψ′′′ 7→ ψ′′′′, etcetera. Maybeafter a very long time compared to the time span from stable state ψ to stable state ψ′′′′· · ·′,the unit goes into a reconfiguration state. Whereupon (i–iv) is repeated, for possibly anotherstable state and transition state sequence. One constraint that rules the state changes withrespect to state transitions (and, of course, stable states) is expressed below:

axiom∀ tu:TU •

∀ t:T • t ∈ D tu ⇒is tΣ(tu(t)) ⇒

is sΣ(tu(t−obs t∆(tu(t)))) ∧is sΣ(tu(t+obs t∆(tu(t)))) ∧let (s′σ,s′′σ) = obs tΣ(tu(t)) in

s′σ = obs sΣ(t−obs t∆(tu(t))) ∧s′′σ = obs sΣ(t+obs t∆(tu(t))) ∧s′σ,s′′σ ⊆ obs Ω(tu(t))/∗ last property follows ∗//∗ from earlier axiom ∗/end

If, at some time, t, a unit is in a transition state, then it is in a stable state both before andafter that time by an amount which can be derived from, ie., is the transition state duration.And the stable states of the time unit at those times, before and after, are as prescribedby observing the transition state of the unit at that “some” time (t). Finally, as formalisedbefore, the two stable states given as poart of the transition state are indeed in the unit’scurrent staable state space.

We can formalise a similar constraint for the dynamic behaviour of units before and afterundergoing, ie., residing in, reconfiguration states. We will leave that as an exercise.

Dynamical Nets

Railway nets consist of units — and otherwise possess many other properties. We now “lift”the conglomeration of all timed units to one timed net. This has to be understood as follows:Not only does the thus timed net consist of timed units but also of other “things”.


Timed Nets

Railway nets consists of units (and possibly more). A timed net is now a continuous functionfrom time to nets. From a timed net (as from units and timed units) we can observe “its”lowest (its “begin” or “start”) time.

typeN, U, TTU = T → UTN = T → N

valuelo T: (U|TU|TN) → Tobs Us: N → U-set

For the purposes of our ensuing discussion we make the following simplifying, but notsubstantially limiting assumptions: For a given timed net, at any time after its “begin” time,it contains the same units as when first “started”.

assume: TN → T → Boolassume(tn)(τ) ≡ ∀ t:T•lo T(tn)<t≤τ

⇒ nor Us(tn(lo T(tn)))=nor Us(tn(t))

nor Us: N → U-set

nor Us(n)≡nor U(u)|u:U•u ∈ obs Us(n)

nor Us: TN → U-setnor Us(tn)≡⋃nor Us(tn(t))|t:T•lo T(tn)≤t≤τ

nor Us defines an equivalence class over any set of “different” units.

Relations between Timed Nets and Timed Units

From a timed net we can “construct” a set of timed units reflecting the timed behaviour ofall the units of the timed net.

valueTN 2 TUs: TN → TU-setTN 2 TUs(tn) ≡

λ t:T • if t<lo T(tu) then chaoselse capture U(tn)(u)(t) end

| u:U • u ∈ obs Us(tn(lo T(u))) pre ∀ t:T • t>lo T(tn) assume(tn)(t)

capture U: TN → U → T → Ucapture U(tn)(u)(t) ≡

let n′ = tn(t) inlet us′ = obs Us(n′) inlet u′:U • u′ ∈ us′ ∧ nor U(u′)=nor U(u)in u′ end end end

Each timed unit is that function of time which for times larger than or equal to the net“start” time, captures the “same” unit in the net. The function TN 2 TUs constructs fromall units of the net their timed unit.

We can not, alas, define the inverse function:

valueTUs 2 TN: TU-set → TNconjecture:

∀ tn:TN • ∀ t:T • t>lo T(tn) assume(tn)(t)⇒ TUs 2 TN(TN 2 TUs(tn)) = tn

The reason is that the net is more than the sum of all its units. Had we defined a net tojust be the set of all units, then a TUs 2 TN could be defined which satisfies the conjecture.Why is a net more than the sum total of all its units ?

The answer to that question can, for example, be found in [16]. We also wish to be ableto observe from a net: the delineations between lines and stations, the embedding, withinstations, of tracks within the units of the stations, &c.

3.3. DISCUSSION OF THE MODEL 45

Selecting Timed Units

Given a timed net and a “prototype” rail unit, that is, a normalised rail unit, we sometimeshave a need to find that unit in the net, or, rather, to find “its” timed version:

value

select TU: TN → U∼→ TU

select TU(tn)(u) ≡let tus = TN 2 TUs(tn) inif ∃ tu:TU • tu ∈ tus ∧

nor U(tu(lo T(tu)))=nor U(u)

thenlet tu:TU • tu ∈ tus ∧

nor U(tu(lo T(tu)))=nor U(u) intu end

else chaos end end

Operations on Timed Nets

We have, in Section 3.2.2, defined the general idea of operations on timed units. We now wishto examine what the meanings of these operations are in the context of timed nets. Supposewe could say: Performing an operation on a timed unit of a timed net only affects that timedunit, and not any of the other timed units of the timed net, then performing “that same”operation, somehow identifying the unit, would have to express the above, as is done below:

typeΘ

valueOP: Θ → (TN × U) → T → TNOP: Θ → TU → T → TU

OP(θ)(tn,u)(τ) as tn′

pre ∃ u′:U •u′ ∈ obs Us(tn(τ))∧nor U(u′)=nor U(u)

post let tu:U = select TU(tn)(u) intus = TN 2 TUs(tn),tus′ = TN 2 TUs(tn′) in

tus\tus′=tus′\tus=OP(θ)(tu)(τ)∧ ... end

The ∧ ... part of the above pre/post characterisation of operations on timed units of atimed net refers to the fact that the whole is more than the sum of its parts, that is: There maybe aspects of the net which are affected by an operation, but not captured by the individualrail units.

3.3 Discussion of the Model

A model of certain aspects of a railway net has been presented. We could have chosen manydifferent ways of formulating this model.

Next we shall discuss two aspects: Why we have not spoken about the unique identificationof units. And whether the model of time (and timing) is the right model.

3.3.1 Why No Unique Unit Identification ?

Perhaps most controversial is our tacit decision not to endow rail units with a unique iden-tification. It is indeed true that each rail unit is unique. It is unique simply by the choiceof its connectors. We never made that explicit. But it is indeed contained in the model ofrailway nets we referred to earlier. See [16]. We could have instead endowed each unit witha unique identifier, but then we would have to express a lot of “book–keeping” constraints tosecure that the already existing uniqueness of rail units was not being interfered with by theadditional “unique” identifier.


3.3.2 Is It the Right Model of Timing ?

When time is involved in a phenomenon, a good advice, in computing science circles, is usuallynot to introduce time explicitly in the model till the latest possible step of development — ifat all ! It is obviously not an advice we have followed. So: Why not ? For two reasons: Thefirst is, that we would otherwise have modelled timing by means of some combination [87, 119]of RSL, as we have used it, [86], and explicit timing constructs of an extended RSL [87], or,[119], of any one, or more, of the Duration Calculi [218, 50, 217]. Either approach mighthave “complicated” the presentation of the notations — which we have kept as Annotationsin footnotes. So — in anticipation of such a possible complication — we have “cowardly”refrained. The other reason for not choosing to also use the above mentioned blends of RSLand either explicit RSL extending timing constructs, or one or more of the Duration Calculi,is that we wish, in a separate publication to perform those experiments: Of using exactly such“extensions”, and then compare the two–three approaches.

In other words: It may not be the right model that we have presented in the currentpaper. “Time (!) will tell !” (Pun intended.)

3.3.3 Possible Relations to Control Theory

The whole purpose of Chap. 3 has been to present a model of a domain that is of interest toboth software engineering and control engineering. We have presented “one side of the coin”,the computing science facets of the models of such domains. It now remains to put forward,informally, some ideas that might relate to control theory, and to suggest that classical ideasof control theory, or just plain, simple calculus (ie., the differential and integral calculi) —that ideas from these disciplines — might be of use in further extending the computationalmodels that are encountered when developing software.

The crucial phenomenon that forces us, so to speak, to raise the issue of possible rela-tions — as far as the domain of transport goes — between computing science and controlengineering is that of our model of traffic: Let us take a look at the concept of train traffic:

typeTrain, Pos

TF = T → (N × (Train →m Pos))

where T is time, N is the time–varying net, Train stands for trains, and Pos is the position oftrains. The timed net follows from traffic:

valuetimed net: TF → TN

timed net(tf)≡λt:T•let (n,tps)=tf(t) in n end

In control engineering we are used to monitor and control the net and the trains. Here theyare brought together in one model. Something that can be done by means of the techniquesof computing science, but something that does not seem to be so easy, as here, to express inusual control theoretic ways.

For a given train, say of identity tn:Tn, we may wish to observe its dynamics:

typeTnTRAIN = T → (N × Train × Pos)value

obs Tn: Train → Tnmonitor Train: Tn → TF → TRAINmonitor Train(tn)(tf) ≡

λt:T•(let (n,tps) = tf(t) in

3.3. DISCUSSION OF THE MODEL 47

let (trn,pos) = select(tn)(tps(t)) in(n,trn,pos) end end)

select: Tn → (Train→m Pos) → (Train × Pos)

select(tn)(tps) ≡let trn:Train•trn ∈ dom tps∧obs Tn(trn)=tnin (trn,tps(trn)) end

Chapter 4

Timetables, Schedules and Traffics

4.1 Introduction

In this chapter general models of Timetables (TT), Schedules (SCH) and and Traffics (TF) willbe shown.

We shall in this chapter only deal with the timetables of passenger and freight trains:plans for shunting and marshalling will be covered later.

4.2 Passenger & Freight Train Timetables

A timetable lists all trains that may engage in traffic on the rail net. For each train its journeyis specified. A journey is a list of station visits. A station visit describes arrival and departuretimes — in addition to the station name!

For a station visit the departure time is always equal to or larger than the arrival time.If the two times are equal then it shall mean that the train does not stop at the designatedstation. For the first (last) station in a journey the arrival (departure) time shall designatethe time the train first (last) appears at the station. For two station visits of a journey the“latter” (i.e. “later”) station visit has an arrival time which is suitably larger (later) than thedeparture time of the “earlier” station visit.

Given a rail net and a timetable, all stations of the timetable must be stations of the net,and the train journeys must be between neighbouring stations, i.e. via lines, of the net, andcannot be circular. The “suitable” time period between timetable departure and arrival timesshall be commensurate with the rail net topology (lengths of lines, whether the lines go overbridges, through tunnels, or pass curves, etc.), allowable train speeds, etc.

A timetable is said to be feasible if the above constraints are met, and such that one canderive a schedule from it in which trains do not congest or even crash, and such that a numberof other criteria are fulfilled.

The timetables of a railway system may consist of one, two or more timetables. These maybe linked to specific calendar periods and cover low and high seasons, vacation and holidayseasons, etc. Any timetable may be concretely expressed in terms of modula: a quarterlytimetable which shows train journeys modulo working and week-end days, from Mondaythrough Sunday.

Timetable journey entries may further indicate train types, capacities and services: pas-senger or freight trains; intercity, express, regional or other trains; number of first, second,

49

50 CHAPTER 4. TIMETABLES, SCHEDULES AND TRAFFICS

etc. (smoking or no-smoking) class seats (window, aisle, etc.); sleepers (berths: upper, lower,medium), dining, snack and refreshment cars (tables, seats, menu offerings), etc.; whetherseat and berth reservations are required, etc.; whether household (domesticated) pets canaccompany passengers; etc.

4.2.1 Narrative

Timetable (TT) is a map, where for each Train name (Tn) (sometimes know as train number)there is a Journey (J).

4.2.2 Formal Model

typeN, L, STn, PRD, RST

TT′ = Tn →m JTT = |tt:TT′ • wf TT(tt)|

J = (T×S×L×S×T×K×PRD×RST)∗

valuewf TT: TT′ → Bool

4.3 Traffic Schedule

4.3.1 Narrative

A schedule is a way for the rail net managers to describe which traffics should in fact occuron the rail net. Note that it may, in some extreme cases, be necessary to schedule theotherwise not wanted states of the rail net. For instance if a light signal is not working itmay be necessary to ignore the signal and let trains pass it irrespective of the state of thesignal. In case of train crashes it may be necessary to schedule unusual movements of trains.Furthermore, note that a schedule describes the states of the rail net at all points in time.Therefore, if – for instance – a train has, at some point in time, passed a closed path, trafficsdescribing this passing of a closed path should be in the schedule, as this is what has in facthappened on the rail net.

As can be seen from the cases described above, schedules must be able to describe anytraffic. Therefore there no further axioms will be stated describing which traffics could beincluded in schedules. For any timetable it is possible to find the schedule describing thosetraffics that adhere to the timetable.

For a schedule to satisfy a timetable, any traffic allowed by the schedule must adhere tothe timetable.

A schedule is a plan for train traffic. A schedule is a (possibly infinite) set of acceptabletraffics. That is, the actual traffic on the net is intended to be in the set of traffics of theschedule.

4.4. TRAFFIC 51

4.3.2 Formal Model

typeSC = TF-infset

valueTT SC: TT → SC

SC sat TT: SC × TT → BoolSC sat TT(sc,tt) ≡ sc ⊆ TT SC(tt)

4.4 Traffic

4.4.1 Narrative

A traffic is a function from time to states of the rail net and all trains on the net. A train statecontains information on the train position, its direction of movement, velocity, acceleration,and possibly other information as needed.

Thus, a traffic gives at any point in time the entire state of the rail net and all trains.Traffic within stations may be due to shunting and marshalling.A traffic may also record other matters not covered here.Certain constraints should be met by any traffic. At any point in time, all trains are on

physically open routes of the network. These routes may be managed closed though. It isnot physically impossible to cross a red light, for instance. Furthermore, trains may not atany time “jump” from one spot to another.

These given constraints for traffics do not reflect intentions or management decisions forthe rail net. They only exclude some traffics that would never be possible, no matter how therailway net is managed.

4.4.2 Formal Model

typeTF′ = T → RS,TF = | tf:TF′ • wf TF(tf) |,RS,TP = Tn →m TS,Tn, TS

valuenet: RS → N,trns: RS → TP,

obs TS TR: TS → TR,obs TS Velocity: TS → ...obs TS Acc: TS → ...

/∗ Trains do not jump ∗/wf TF: TF′ → Boolwf TF(tf) ≡ continous movement(tf),

/∗ The trains of a TP are on units of the network ∗/TP on physical open routes: N × TP → BoolTP on physical open routes(n,tp) ≡


∀ tn:Tn • tn ∈ dom tp ⇒obs TS TR(tp(tn)) ∈ Physical Open N Rts(n),

/∗ Trains do not jump from one spot to another ∗/continous movement: TF′ → Boolcontinous movement(tf) ≡∀ t:T, tn:Tn • tn ∈ TF Tns(tf,t) ⇒

train removed(tf,tn,t) ∨train wf move(tf,tn,t),

/∗ In the traffic tf the train tn is removed at time t ∗/train removed: TF′ × Tn × T → Booltrain removed(tf,tn,t) ≡

tn ∈ TF Tns(tf,t) ∧∃ t′:T • t′>t ∧

∀ t′′:T • t<t′′≤t′ ⇒ tn 6∈ TF Tns(tf,t′′),

/∗ In the traffic tf the train tn is performing a wellformed(continuous) move at time t ∗/

train wf move: TF′ × Tn × T → Booltrain wf move(tf,tn,t) ≡

∃ t′:T • t′>t ∧∀ t′′:T • t≤t′′≤t′ ⇒

tn ∈ TF Tns(tf,t′′) ∧wf TR move(TF TR(tf,tn,t),TF TR(tf,tn,t′′)),

TF Tns: TF′ × T → Tn-setTF Tns(tf,t) ≡ RS Tns(tf(t)),

RS Tns: RS → Tn-setRS Tns(rs) ≡ dom trns(rs),

TF TR: TF′ × Tn × T → TRTF TR(tf,tn,t) ≡ RS TR(tf(t),tn)pre tn ∈ TF Tns(tf,t),

RS TR: RS × Tn → TRRS TR(rs,tn) ≡ obs TS TR(RS TS(rs,tn))pre tn ∈ RS Tns(rs),

RS TS: RS × Tn → TSRS TS(rs,tn) ≡ trns(rs)(tn)pre tn ∈ RS Tns(rs),

TF N: TF × T → NTF N(tf,t) ≡ net(tf(t)),

TF Sns: TF × T → Sn-setTF Sns(tf,t) ≡ obs N Sns(TF N(tf,t)),

TF S: TF × Sn × T → STF S(tf,sn,t) ≡ obs N SnSm(TF N(tf,t))(sn)pre Sn ∈ TF Sns(tf,t)

axiom∀ rs:RS • TP on physical open routes(net(rs),trns(rs))

One could express further constraint on traffics. For instance the acceleration, maximum

4.5. DISCUSSION 53

speed etc. of trains could be taken into account when describing wellformed moves for trains.Also the rail net topology (length of units, whether units go over bridges, through tunnels,or pass curves etc.) will have an effect on the movements of trains.

4.5 Discussion

Basically all different forms of timetables contain overlapping data and very often can betransformed from one form to another. In Sect. 4.2.1 possible data structure of timetables isgiven. One can now write several functions that from this data structure extract timetablesin different formats.

We would like to emphasize that we do provide the underlying formal model of timetablefor a planning period of any length. Therefore our model fits well either for 1–day planningperiod (like in CyberRail project) as well as for the most common one–year planning period.

4.5.1 Schedule Quality

It may be useful to compare the quality of schedules. That is, which schedule is best, insome sense. This may be done by comparing the traffics allowed by the schedules. As fortraffic quality, the schedule quality may depend, however, on many aspects, and it will notbe described in the intrinsic model.

4.5.2 Schedule Description

For planning and management of a rail net, it should be possible to describe certain constraintsto be met by a schedule. For instance, one could state that a certain train was to be at a givenstation at a given point in time. A schedule description consists of a set of such constraintsto a schedule.

A schedule description consists of predicates on the rail state that are to be true at givenpoints in time. It is possible to find the schedule containing all traffics that satisfy thepredicates of a schedule description.

4.5.3 Traffic Quality

In a set of traffics there may be some traffics that are in some sense better than others. Indescribing the intrinsics, we will not further specify how quality of a traffic is determined.This may depend on a lot of different management rules and decisions. We will howeverdescribe some functions that may be used when considering the quality of a traffic.

The quality of a traffic may depend on many different aspects. For instance if the trafficsatisfies certain time conditions, trains are not delayed etc.

Also, one would usually only want trains to use managed open routes of the network andto be within lines or stations of the network. Note that a traffic may describe situationswhere these conditions are not met. It is in fact possible for trains to be on closed routes ofthe network for instance. When talking about quality of a traffic, the conditions describedshould be taken into account however.


4.5.4 Traffic and Safety Conditions

One would also prefer certain safety conditions to be met by a traffic. Two trains shouldnever occupy intersecting units of the network and a trainroute should never run through aunit twice. This would probably mean that a crash had occurred or was about to occur.

4.5.5 Kirschoff’s Law of Station Flow

Over a suitably chosen interval, the number of trains flowing into (i.e. arriving at) a station,minus the number of trains taken out of service (i.e. ending their journey) at this station,plus the number of trains put into service (i.e. starting their journey) at this station, equalsthe number of trains flowing out of (i.e. departing from) this station.

The suitably chosen interval of time is any such where there are the same number of trainsat the station at the very beginning and at the very end of this interval.

(The law could thus be extended to include these numbers of trains at the station.)

Chapter 5

Rolling Stock

5.1 Introduction

The railway system, in addition to the rail net and timetable, consists of the rolling stock. Inthis chapter the notions of rolling stock, wagons and wagon types are shown in detail.

5.2 Rolling Stock Module

5.2.1 Narrative

The rolling stock contains information about among other things. It is possible to extractinformation about the type of each wagon in the rail net. The type of a wagon could belocomotive, passenger car, etc. This information is needed in the rolling stock when composingtrain bodies consisting of wagons of certain types.

5.2.2 Formal Model

typeRollingStock,Wtype

value/∗ Observer functions ∗/obs Wagons : RollingStock → W-set,

/∗ obs Units from Wagon and obs Train from Wagon are partial ∗//∗ since they are undefined if the wagon doesn’t exist in RollingStock ∗/obs Units from Wagon : RollingStock × W

∼→ U∗,obs Train from Wagon : RollingStock × W

∼→ TB,

obs RollingStock from Net : N → RollingStock,obs Wtype : W → Wtype,

55

56 CHAPTER 5. ROLLING STOCK

5.3 Bag Type

5.3.1 Narrative

During our work with the specification of plans for composing a certain train body from therolling stock, we found that we needed a bag-type. Instead of specifying a specific bag forour purpose, we decided to make the bag specification parameterized. By doing so we will beable to use the specification for other purposes if necessary.

In the following text we give the general specification of bags.

5.3.2 Formal Model

scheme BAG(E : class type Elem end) =classtype

bag = E.Elem →m Nat

value/∗ A list is converted to a bag ∗/List to Bag′ : E.Elem∗ → bag → bagList to Bag′(elist)(bag) ≡

case elist of〈〉 → bag,〈e〉 list →

List to Bag′(list)(if e ∈ dom bag then

bag † [ e 7→ bag(e) + 1 ]else

bag † [ e 7→ 1 ]end)

end,

List to Bag : E.Elem∗ → bagList to Bag(elist) ≡

List to Bag′(elist)([ ])

end

We use the bag specification to specify test functions. These test if a certain train bodycan be composed from the wagons in the rolling stock. As a special case, we also test if thedesired train body already exists as a train body somewhere in the rolling stock.

object WTYPE: class type Elem = Wtype endobject WTYPE BAG: BAG(WTYPE)

value/∗ Test if a certain train can be composed ∗/Train Exists : N × Wtype∗ → BoolTrain Exists(n, wtypelist) ≡let

r = obs RollingStock from Net(n),rs ws = obs Wagons(r),rs ls = Convert(rs ws),rs wtypebag = WTYPE BAG.List to Bag(rs ls),

5.4. WAGON LOCATION 57

wtypebag = WTYPE BAG.List to Bag(wtypelist)in

∀ wtype : Wtype •wtype ∈ dom wtypebag ⇒wtype ∈ dom rs wtypebag ∧ (wtypebag(wtype) ≤ rs wtypebag(wtype))

end,

/∗ Converts a W-set to a Wtype-list. Needed to convert a W-set to a Wtype-bag ∗/Convert: W-set → Wtype∗

Convert(ws) as wtypelistpost

card ws = len wtypelist ∧(∀ w:W • w ∈ ws ≡ obs Wtype(w) ∈ elems wtypelist),

/∗ Test if a certain train already exists in RollingStock ∗/Train Already Exists : N × Wtype∗ → Bool

5.4 Wagon Location

5.4.1 Narrative

We also need to be able to compose train bodies. In order to do so, we need to know wherewagons of a certain type are located. We also need to be able to find the locations of a certaintrain body if it exists.

5.4.2 Formal Method

value/∗ The locations of wagons of a certain type ∗/Wagons Locations : N × Wtype → (U∗)-setWagons Locations(n, wtype) ≡

u | u : U∗ •let r = obs RollingStock from Net(n), rs ws = obs Wagons(r)in ∀ w : W • w ∈ rs ws ∧ u = obs Units from Wagon(r,w)

∧ obs Wtype(w) = wtypeend

,

/∗ The locations of an entire trainbody of a certain type ∗/Trainbody Location : N × Wtype∗ → (U∗)-set,

/∗ The locations of a trainbody of a certain type ∗/Train Location : N × Wtype∗ → ((U∗)∗)-set

axiom∀ n : N, wtypelist : Wtype∗ •

Train Already Exists(n, wtypelist) ⇒ Train Exists(n, wtypelist),

∀ n : N, wtypelist : Wtype∗ •Train Already Exists(n, wtypelist) ≡ (Trainbody Location(n, wtypelist) 6= ),

∀ n : N, wtypelist : Wtype∗ •Train Exists(n, wtypelist) ≡ (Train Location(n, wtypelist) 6= )


5.5 Train Composition

5.5.1 Narrative

It is now possible to extract enough information from the rolling stock to make plans forcomposing a certain train body. A plan contains information about how to compose a certaintrain body which is needed at a specific place. The place is given as a unit on which eitherthe whole train body or the front of the train body (if the train body is longer than the unit)is to be located after executing the plan. From a plan, it is possible to extract informationabout which wagons the train body is to be composed of, and where they are located.

5.5.2 Formal Method

typePlan,PlanId

value/∗ Observer functions ∗/obs destinationUnit from Plan : Plan → U,obs Wagons from Plan : Plan → (W →m U∗),

/∗ Make plan for composing train ∗//∗ The function is partial; there might not exist a Plan for Wtype-list ∗/Plan for Composing Train : N × Wtype∗ × U

∼→ Plan

5.6 Rolling Stock Plans

5.6.1 Narrative

Often, it is possible to make several plans for a certain train body. In practice one often want tochoose the plan which is considered best according to some criteria, e.g. cost, environmentalissues, time, distance etc. In the following we have chosen to model this by a predicateBetter Plan which tests if one plan is better than another. We do not give any specificationof what makes one plan better than another.

5.6.2 Formal Model

value/∗ A plan is better than another ∗/Better Plan : N × Plan × Plan → Bool,

/∗ The set of best plans: A plan is in this set if no plan is better than it ∗/Make Set of Good Plans : N × Wtype∗ × U → Plan-setMake Set of Good Plans(n, wtypelist, unit) ≡

p | p : Plan •p = Plan for Composing Train(n, wtypelist, unit) ∧(∀ p′ : Plan • p′ = Plan for Composing Train(n, wtypelist, unit)≡ ∼Better Plan(n, p′, p))

,

5.7. ROLLING STOCK PLAN MODIFICATION 59

/∗ Choose one of the best plans ∗/Best Plan : N × Wtype∗ × U → PlanBest Plan(n, wtypelist, unit) as plan

post plan = Make Set of Good Plans(n, wtypelist, unit)

axiom/∗ Better Plan ∗/∀ n : N, p, p′, p′′ : Plan •

∼ Better Plan(n, p, p) ∧(Better Plan(n, p, p′) ⇒ ∼ Better Plan(n, p′, p)) ∧((Better Plan(n, p, p′) ∧ Better Plan(n, p′, p′′)) ⇒ Better Plan(n, p, p′′))

We could also model some predicates which test whether a plan is better than anotherplan e.g. with respect to cost, distance or time:

valueBetter Plan wrt Cost : N × Plan × Plan → Bool,Better Plan wrt Distance : N × Plan × Plan → Bool,Better Plan wrt Time : N × Plan × Plan → Bool

5.7 Rolling Stock Plan Modification

5.7.1 Narrative

After deciding which plan to use, we want to register this plan. This can be done by insertingit in the plan for the rolling stock. This plan, called rsPlan, contains information about all ofthe selected plans.

We also have to consider what to do with the wagons in the inserted plan. For example,what if we make a plan for composing another train body and that plan uses some of thewagons in the inserted plan. This would result in a conflict.

We have chosen to resolve this by having a reservoir which contains information aboutthe wagons already committed to a plan. Whenever a plan is inserted in rsPlan, the wagonscommitted to that plan are removed from the wagon pool in the rolling stock and inserted inthe reservoir. When a plan is executed, it is removed from the rsPlan.

5.7.2 Formal Model

typersPlan,Reservoir

value/∗ Observer functions ∗/obs rsPlan : RollingStock → rsPlan,

/∗ obs Plan from rsPlan is partial since PlanId might not exist in rsPlan ∗/obs Plan from rsPlan : rsPlan × PlanId

∼→ Plan,

obs PlanId from rsPlan : rsPlan → PlanId-set,obs Reservoir from Net : N → Reservoir,obs Wagons from Reservoir : Reservoir → W-set,


/∗ When a Plan is inserted in rsPlan, the wagons in the Plan is moved to Reservoir ∗/Insert Plan : N × Plan

∼→ N × PlanIdInsert Plan(n,p) as (n′,pid′)

postlet

wm = obs Wagons from Plan(p),ws = dom wm,r = obs RollingStock from Net(n′),rs ws = obs Wagons(r),res = obs Reservoir from Net(n′),res ws = obs Wagons from Reservoir(res),rsplan = obs rsPlan(r)

in∼(ws ⊆ rs ws) ∧ (ws ⊆ res ws) ∧obs Plan from rsPlan(rsplan, pid′) = p

endpre Test Plan(n,p),

/∗ When a Plan is cancelled, it’s removed from rsPlan ∗/Cancel Plan: N × PlanId

∼→ NCancel Plan(n,pid) as n′

postlet

r = obs RollingStock from Net(n),rsplan = obs rsPlan(r),r′ = obs RollingStock from Net(n′),rsplan′ = obs rsPlan(r′)

in∼ ( ∃ pid′ : PlanId •obs Plan from rsPlan(rsplan′, pid′) = obs Plan from rsPlan(rsplan,pid))

endpre pid ∈ obs PlanId from rsPlan(obs rsPlan(obs RollingStock from Net(n))),

/∗ Test if a Plan is legal. A Plan is legal wrt. rsPlan ∗//∗ if it doesn’t conflict with the Plans in rsPlan ∗/Test Plan : N × Plan → Bool,

/∗ Merge two plans ∗/Merge Plans : N × PlanId × PlanId → N × PlanId,

/∗ A Plan is removed from rsPlan when it is executed ∗/Exec

When the wagons in a train are no longer used, the wagons are transferred to the wagonpool in the rolling stock. This happens e.g. when a train reaches its destination and is‘unloaded’, whether it is a passenger or freight train.

/∗ A wagon is inserted in RollingStock ∗/Insert Wagon: N × W × U∗

∼→ NInsert Wagon(n,w,ulist) as n′

postlet r = obs RollingStock from Net(n′)in w ∈ obs Wagons(r) ∧ ulist = obs Units from Wagon(r,w)end

pre w 6∈ obs Wagons(obs RollingStock from Net(n))

Chapter 6

Passengers and Freights

6.1 Introduction

Trains of the rail net may carry passengers or freights. In this chapter, the journeys andstates of passengers and freights will be described.

In section 6.2 basic types for passengers and their states are shown. Section 6.3 deals withpassenger traffic. In section 6.4 the Passenger Reservation & Ticketing System will be shown.In section 6.5 basic types of freights and their states are shown. In section 6.6 we refer to thesystem which handles the booking etc. as Freight Handling. In the last section 6.7 we modelfreight losses.

6.2 Module of Passengers

6.2.1 Narrative

The module passenger contains types for passengers, their state etc. and the correspondingfunctions.

6.2.2 Formal Model

scheme passengers =class

typePn,PS,PP,PH

/∗ ... ∗/end

61

62 CHAPTER 6. PASSENGERS AND FREIGHTS

6.3 Passenger Traffic

6.3.1 Narrative

At any time there is a set of passengers in trains of the rail net system. Each passenger isidentified by, for instance, a name. The names and states of passengers can be extracted froma traffic.

6.3.2 Formal Model

typePn, PS,PP = Pn →m PS

valueobs RS PP: RS → PP

/∗ The passengers in a traffic at a given point in time ∗/TF Pns: TF × T → Pn-setTF Pns(tf,t) ≡ dom obs RS PP(tf(t))

/∗ The state of a passenger at a given point in time ∗/TF PS: TF × T × Pn

∼→ PSTF PS(tf,t,pn) ≡ obs RS PP(tf(t))(pn)pre pn ∈ TF Pns(tf,t)

The passenger information may for instance describe the position of the passenger (trainand seat), the ticket carried by the passenger etc.

valueobs PS Tn: PS → Tn

For any Rail State, passengers must always be on trains of the network.

axiom/∗ All passengers are on trains of the rail net ∗/∀ rs:RS, ps:PS •

ps ∈ rng obs RS PP(rs) ⇒ obs PS Tn(ps) ∈ dom trns(rs)

Other axioms could be included as well. For instance, in a traffic it should not be possiblefor passengers to jump from one train to another.

A passenger history gives the state of a passenger at any point in time where the passengeris in the rail net.

typePH = T →m PS

value/∗ Find the passenger history of a passenger in given traffic ∗/TF PH: TF × Pn → PHTF PH(tf,pn) ≡

[ t 7→ TF PS(tf,t,pn) | t:T • pn ∈ TF Pns(tf,t) ]

A Passenger history gives for any point in time the set of passengers in the rail net andthe state of these passengers. This state holds information about the passenger, for instancethe name of the train that carries the passenger, the seat that the passenger occupies, theticket carried by the passenger etc.

6.4. PASSENGER TICKETING AND RESERVATIONS 63

typePn,PsTF = T → PsS,PsS = Pn →m PS

valueobs PS Tn: PS → Tn,

/∗ The passengers in the rail net at a given point in time ∗/PsTF Pns: PsTF × T → Pn-setPsTF Pns(pstf,t) ≡ dom pstf(t)

/∗ The train of a passenger ∗/PsTF Tn: PsTF × Pn × T

∼→ TnPsTF Tn(pstf,pn,t) ≡ pstf(t)(pn)pre pn ∈ PsTF Pns(pstf,t)

It is possible to determine if passenger traffic is wellformed in a given traffic. For instance,passengers must be on trains of the traffic.

valuePsTF wf TF: PsTF × TF → BoolPsTF wf TF(pstf,tf) ≡

∀ t:T, pn:Pn •pn ∈ PsTF Pns(pstf,t) ⇒ PsTF Tn(pstf,pn,t) ∈ TF Tns(tf,t)

6.4 Passenger Ticketing and Reservations

6.4.1 Narrative

Any passenger or an agent acting on behalf of any group of one or more passengers may inquireabout, reserve, cancel, re-book and actually buy tickets for simple or composite journeys onscheduled trains.

In the domain model, however, we only speak about the booking and occupancy status ofpassenger trains.

A ticket can be described as the set of passenger histories allowed by the ticket.A passenger holding a number of tickets is allowed to be in any state allowed by the

tickets. A set of tickets can be described as a single ticket. That is, a ticket describingpassenger histories allowed by the set of tickets.

6.4.2 Formal Model

typeTicket = PH-infset

valuecombine Tickets: Ticket-set → Ticketcombine Tickets(ts) ≡

ph | ph:PH • ∀ t:T • ∃ tk:Ticket •tk ∈ ts ∧ Ticket PS allowed(tk,ph(t),t) ,

Ticket PS allowed: Ticket × PS × T → Bool


Ticket PS allowed(tk,ps,t) ≡∃ ph:PH • ph ∈ tk ∧ ph(t) = ps

Some of the passenger histories allowed by a set of tickets may be reserved by other pas-sengers holding seat reservations. A reservation contains information of the histories reserved.No passenger history can be reserved by two distinct reservations though.

valueobs Res PHs: Res → PH-set

axiom/∗ No passenger history is reserved more than once ∗/∀ ps:pratsState, r1,r2:Res •

r1 6=r2 ∧ r1,r2 ⊆ obs pratsState Ress(ps) ⇒obs Res PHs(r1) ∩ obs Res PHs(r2) =

From the state of the Passenger Reservation & Ticketing System, one can find the set ofall passenger histories reserved.

valuepratsState resPHs: pratsState → PH-setpratsState resPHs(ps) ≡

ph | ph:PH • ∃ r:Res •r ∈ obs pratsState Ress(ps) ∧ ph ∈ obs Res PHs(r)

It is possible to find all allowed passenger histories of a passenger holding a set of ticketsand a set of reservations. A passenger is allowed to have any history that is allowed by thetickets, except those that are reserved by other passengers.

Histories allowed for the passenger

Passengers ticketsAll reserved histories

Passengersreservations

Figure 6.1: Allowed passenger histories

value/∗ Find the allowed histories of a passenger carrying a given set

of tickets and reservations ∗/allowed PHs: Ticket-set × Res-set × pratsState → PH-setallowed PHs(ts,rs,ps) ≡

ph | ph:PH • ph ∈ combine Tickets(ts) ∧(ph 6∈ pratsState resPHs(ps) ∨∃ r:Res • r ∈ rs ∧ ph ∈ obs Res PHs(r))

pre rs ⊆ obs pratsState Ress(ps)

6.5. MODULE OF FREIGHTS 65

6.5 Module of Freights

6.5.1 Narrative

The module freight contains the some of types and functions defined later on in the sectionCustomer Services in the chapter, namely those which model Freight Handling.

6.5.2 Formal Model

scheme freight =class

typeFTn,Freight,FreightId,FreightSc,FreightInfo,FreightSystem,FreightTraffic,FreightISI,Location,Place,Pos,Freights,FT,LostFreight

/∗ ... ∗/end

6.6 Client Freighting

6.6.1 Narrative

In the domain model we similarly only speak about the booking and occupancy status offreight trains. We have chosen to model the stake holder perspective as seen from the cus-tomers. That is, we concentrate on the activities which are needed to fulfil the customersneeds and wishes.

In the following we refer to the system which handles the booking etc. as Freight Handling.

6.6.2 Formal Model

typeFTn = Tn,Freight,FreightId,FreightSc,FreightInfo,FreightSystem,FreightISI = FreightId × FreightSc × FreightInfo

value


/∗ Observer functions ∗/obs FreightId : FreightSystem → FreightId-set,

/∗ obs Freight, obs FreightInfo and obs Schedule are partial ∗//∗ since the FreightId might not exist in the FreightSystem ∗/obs Freight : FreightSystem × FreightId

∼→ Freight,

obs FreightInfo : FreightSystem × FreightId∼→ FreightInfo,

obs Schedule : FreightSystem × FreightId∼→ FreightSc,

obs FreightSystem from Net : N → FreightSystem

axiom/∗ For each FreightId in a FreightSystem exists exactly one Freight and one FreightSc ∗/∀ f:FreightSystem, fid, fid′ : FreightId •

fid,fid′ ⊆ obs FreightId(f) ⇒fid = fid′ ≡let

freight = obs Freight(f,fid),freight′ = obs Freight(f,fid′),finfo = obs FreightInfo(f,fid),finfo′ = obs FreightInfo(f,fid′),fsc = obs Schedule(f,fid),fsc′ = obs Schedule(f,fid′)

infreight = freight′ ∧finfo = finfo′ ∧fsc = fsc′

end

In the following we model the functions which directly reflect the communication with thecustomers. This involves checking if freight is delivered at the station or if it has reached itsdestination. The customers can request price etc. for a piece of freight, confirm a request ifthis is possible, and reserve a place for a piece of freight.

value/∗ Test if Freight is delivered. False if FreightId doesn’t exist in FreightSystem ∗/Is Delivered : N × FreightId → Bool,

/∗ Test if Freight is at destination. False if FreightId doesn’t exist in FreightSystem ∗/At Destination : N × FreightId → Bool,

/∗ Deliver freight ∗/Deliver Freight : N × FreightId

∼→ N,

/∗ Receive freight ∗/Receive Freight : N × FreightId

∼→ N,

/∗ Freight request - Do not make a reservation ∗/Request : N × TT × Sn × Sn × T × Freight → FreightISI,

/∗ Confirm (reserve) a request if possible ∗/Confirm : N × FreightISI → N × Bool,

/∗ Freight reservation ∗/

6.6. CLIENT FREIGHTING 67

Reservation : N × TT × Sn × Sn × T × Freight → N × FreightISI,

/∗ Cancel reservation. ∗/Cancel : N × FreightId

∼→ N

axiom/∗ Deliver ∗/∀ n : N, fid : FreightId •

Deliver Freight(n, fid) as n′post Is Delivered(n′, fid)pre fid ∈ obs FreightId(obs FreightSystem from Net(n)),

/∗ Receive ∗/∀ n : N, fid : FreightId •

Receive Freight(n, fid) as n′post fid 6∈ obs FreightId(obs FreightSystem from Net(n′))pre

fid ∈ obs FreightId(obs FreightSystem from Net(n)) ∧At Destination(n, fid),

/∗ Request ∗/∀ n : N, tt : TT, sn1, sn2 : Sn, t : T, freight : Freight •

Request(n, tt, sn1, sn2,t,freight) as (fid′, fsc′, finfo′)post fid′ 6∈ obs FreightId(obs FreightSystem from Net(n)),

/∗ Confirm Request ∗/∀ n : N, fid : FreightId, fsc : FreightSc, finfo : FreightInfo •

Confirm(n, (fid, fsc, finfo)) as (n′, b′)post b′ =

(obs Schedule(obs FreightSystem from Net(n′), fid) = fsc) ∧(obs FreightInfo(obs FreightSystem from Net(n′), fid) = finfo),

/∗ Make reservation ∗/∀ n : N, tt : TT, sn1, sn2 : Sn, t : T, freight : Freight •

Reservation(n, tt, sn1, sn2, t, freight) as (n′, (fid′, fsc′, finfo′))post freight = obs Freight(obs FreightSystem from Net(n′), fid′),

/∗ Cancel reservation ∗/∀ n : N, fid : FreightId •

Cancel(n, fid) as n′post fid 6∈ obs FreightId(obs FreightSystem from Net(n′))pre fid ∈ obs FreightId(obs FreightSystem from Net(n))

From the FreightSystem we can now extract information about the pieces of freight. Thisinformation is needed to decide which wagons are needed to fulfil the agreement with thecustomers.

value/∗ Find which wagons are needed for the freight ∗/GetTrain : N → Wtype∗

As a special treat, Freight Handling also offers the customers the ability to trace theirfreight. The customers can request where the freight is at any time and will either get a


station name or a train name and the location of that train.

typeFreightTraffic,Location,Place,Pos

value/∗ Observer functions ∗/obs FreightSet : FreightTraffic → FreightId-set,

/∗ obs Location is partial since we might not know the location of a certain freight, e.g. if it is lost ∗/obs Location : FreightTraffic × T × FreightId

∼→ Location,

obs FreightTraffic from Net : N → FreightTraffic,

/∗ Test if Place is a Station Name ∗/Is Sn : Place → Bool,

/∗ Test if Place is a Freight Train Name and a Position ∗/Is FTnPos : Place → Bool,

/∗ Test if Location is a Station Name ∗/Is Sn : Location → Bool,

/∗ Test if Location is a Train Name ∗/Is FTn : Location → Bool,

Can obs Location : FreightTraffic × T × FreightId → Bool,

/∗ Freight Tracing ∗/Freight Trace : N × TF × T × FreightId

∼→ Place

axiom/∗ A Place is either a Station Name or a Freight Train Name and a Position ∗/∀ place : Place •

∼ (Is Sn(place) ∧ Is FTnPos(place)),

/∗ A Location is either a Station Name or a Freight Train Name ∗/∀ location : Location •

∼ (Is Sn(location) ∧ Is FTn(location)),

/∗ Freight Tracing ∗/∀ n : N, tf : TF, time : T, fid : FreightId •

Freight Trace(n, tf, time, fid) as placepost

let loc = obs Location(obs FreightTraffic from Net(n), time, fid)in if Is Sn(loc) then Is Sn(place) elsif Is FTn(loc) then Is FTnPos(place) endend

preCan obs Location(obs FreightTraffic from Net(n),time,fid)

6.7. LOST & FOUND FREIGHT 69

6.7 Lost & Found Freight

6.7.1 Narrative

It may happen that freight is lost while in transit from one place to another, e.g. a wagonmight accidentally get separated from a train. Freight might also reappear, e.g. when we findany freight that was lost earlier.

We can model this by using the following functions:

6.7.2 Formal Model

typeFreights,FT

valueobs Freights from Train: FT → Freights,Load Freights: FT × Freights → FT,/∗ Merge takes two Freights and combines them ∗/Merge: Freights × Freights → Freights

Freights is a type containing pieces of freight. FT is a type representing a freight train.We now have to consider three cases:

No freight is lost :

In this case all the freight loaded on the freight train can be observed from the train.Formally, this can be formulated as:

axiom∀ ft : FT, frs, frs′ : Freights •let frs′ = obs Freights from Train(ft) inobs Freights from Train(Load Freights(ft,frs)) = merge(frs,frs′)end

Freight is lost :

In this case we cannot observe all the freight which were loaded on the train.Formally, this can be formulated as:

axiom∀ ft : FT, frs, frs′ : Freights •let frs′ = obs Freights from Train(ft) inobs Freights from Train(Load Freights(ft,frs)) ⊂ merge(frs,frs′)end


Freight is found:

In this case we can observe more freight on the train than the freight we actually loaded onthe train.

Formally, this can be formulated as:

axiom∀ ft : FT, frs, frs′ : Freights •let frs′ = obs Freights from Train(ft) inobs Freights from Train(Load Freights(ft,frs)) ⊃ merge(frs,frs′)end

When freight is lost, we want to be able to store information about it, its FreightInfo andFreightSc, etc. We also need to be able to check if freight is lost etc.

In the following we assume that we can obtain FreightId on freight found. We use this toremove the recovered freight from LostFreight.

Formally, this can be formulated as:

typeLostFreight

value/∗ Observer function ∗/obs LostFreight: FreightSystem → LostFreight,obs Freight from LostFreight: LostFreight → FreightId-set,

/∗ obs FreightInfo from LostFreight and obs FreightSc from LostFreight ∗//∗ are partial since FreightId might not exist in LostFreight ∗/obs FreightInfo from LostFreight: LostFreight × FreightId

∼→ FreightInfo,

obs FreightSc from LostFreight: LostFreight × FreightId∼→ FreightSc,

Is Freight Lost: N × FreightId → BoolIs Freight Lost(n,fid) ≡

letfs = obs FreightSystem from Net(n),lf = obs LostFreight(fs),lostfid = obs Freight from LostFreight(lf)

in fid ∈ lostfidend,

Insert LostFreight: N × FreightId∼→ N

Insert LostFreight(n,fid) as n′post

letfs = obs FreightSystem from Net(n′),lf = obs LostFreight(fs),lostfid = obs Freight from LostFreight(lf)

in fid ∈ lostfidend

pre ∼Is Freight Lost(n,fid),

Remove Freight: N × FreightId∼→ N

Remove Freight(n,fid) as n′post

6.8. DISCUSSION 71

letfs = obs FreightSystem from Net(n′),lf = obs LostFreight(fs),lostfid = obs Freight from LostFreight(lf)

in fid 6∈ lostfidendpre Is Freight Lost(n,fid)

Law of Preservation

In any time interval when no freight is delivered or received, the sum of traceable freight andlost freight is constant.

6.8 Discussion

We did not model the scheduling of freight here but let us only speculate on some of theissues. For example, if the freight is flammable or radioactive, the schedule shouldn’t take itthrough residential areas. We could model this by predicates which test freight with respectto some given criteria. The predicates could then be used to decide on the best schedulebut this is left to the Freight Traffic and Train Management which is in charge of makingschedules. More about the scheduling can be found in Chap. 8.

Part III

Railway Scheduling and Allocation

73

Chapter 7

Issues of Scheduling & Allocation

7.1 Introduction

This chapter is an introductory chapter for the part called ‘Railway Scheduling and Allo-cation’. We would like to provide a brief informal description of several issues of railwayallocation & scheduling tasks.

Each section in this chapter gives a short description of the problem and then a referenceto its solution in the Thesis or a reference to bibliography.

In the Thesis a general overview of formal models of the railway system infrastructure isgiven in Chap. 17. A slightly different view is given in [15].

7.2 Rail Net Development

The Rail Net Development System takes care of the rail net management. That is for instanceinsertion or removal of lines and stations, changing parameters (like speed) of lines, etc.

Chap. 8 shows how to generate optimum railway net layout and its timetable as an indi-visible pair.

The problem can be also solved by Petri nets, see [12]. Formal representation of tracktopologies can be found in [99, 153]. For graphical systems for the visual simulation andcontrol of railway network, see [37, 208].

7.3 Timetable Generation

Timetables belong to the most important entities in railway system from both the operator’sand passenger’s point of view. There are several different ways how to present timetable.From the operator’s point of view the most important form of timetable is called ‘runningmap’ [14, 66, 215, 181, 173].

From the passenger’s point of view timetable can be seen as a printed book, set of alldepartures/arrivers at stations, web-based travel planning application, train or lines booklets,etc.

Sect. 4.2.1 of the Thesis gives a general formal model (data structure), from which all otherforms can be easily derived. In Chap. 8 is shown how to generate nets and their timetable.Also many papers deals with timetabling from the formal point of view. We refer to some ofthem [65, 67, 98, 100, 101, 134, 161, 179, 210].

75

76 CHAPTER 7. ISSUES OF SCHEDULING & ALLOCATION

7.4 Scheduling and Rescheduling

One can talk about a traffic being on schedule or not. In particular one can talk about trafficbeing delayed. For a traffic to be on schedule, the traffic must be one of the traffics allowedby the schedule.

The whole Chap. 15 deals with the rescheduling problem. Scheduling and rescheduling oftrains from the formal point of view is also described in [24]. Usage of genetic algorithms intrain scheduling problem can be found in [40]. A duration Model for Railway scheduling isshown in [49].

7.5 Other Resource Planning

Staff, monies, and auxiliary resources need also be managed.Among auxiliary resources we include: car and wagon cleaning etc.; car and wagon main-

tenance and repair equipment; freight loading & unloading trucks; etc.Their physical and temporal availability, i.e. allocation and scheduling, subject to various

rules and regulations, is part of station management.We refer to Chap. 8 and to [38, 51] for more details about this topic.

7.6 Maintenance Planning

By maintenance we do not mean only regular check of all systems (assemblies, etc.) in thedepot, but we present maintenance in a more general sense. We understand maintenance asa set of all activities, which must be done with rolling stock, regularly according to somerules, and which should be planned in advance except for the operation of rolling stock itself.Therefore we also include outside and inside cleaning of carriages, refueling diesel engines,refilling supplies into restaurant carriages, water and oil refilling, etc.

In the Thesis whole Chap. 9 deals with this task. We also refer to [93] that deals withapplication of genetic techniques to the planning of railway track maintenance work. Fuzzyneural networks for machine maintenance in mass transit railway systems are shown in [148].

7.7 Optimum Train Length

A determination of the train composition is another optimisation problem of railway allocationand scheduling. It deals with the maximum usage of available rolling-stock. The problem tobe tackled is as follows: trains travel from station to station. Trains are composed of carriages.At stations trains may have carriages added (composed) to, or removed (decomposed) fromthe train. Station tracks may restrict train additions and removals to occur only at either thefront, or at the back of a train. Given the requirements for trains to provide suitable load(for example passenger) capacity along a journey with such demands varying, the problem isnow to plan that trains, during their journeys, have suitable assemblies added to or removedfrom the train.

The costs of coupling and decoupling have to be taken into account. There can be foundgraphical tools [56] that help dealing this task. We also refer to [74, 88, 121, 160].

7.8. STATION TRACK ASSIGNMENT 77

7.8 Station Track Assignment

Track may be blocked for several trains. The planning and actual setting (i.e. signalling)of the corresponding unit states is an essential function of station management. Stationmanagement also involves determination of train positions.

Complexity issues of routing trains through railway stations can be found in [142]. A casestudy of railway station management from the formal approach is described in [71, 195].

7.9 Delay Train Management

In the everyday operation of a railroad, it is unfortunately not uncommon for a train toarrive at a station with a delay. In such a situation, some of the trains passengers may missa connecting train, resulting in an even larger delay for them since they have to wait for thenext train. If, on the other hand, the connecting train waits, then it is delayed itself, and soare all the passengers it is carrying. Delay management consists of deciding which connectingtrains should wait for what delayed feeder trains, usually with the objective of minimizingthe overall discomfort faced by the passengers. Although railway optimization and schedulingproblems have been studied quite intensely over the past decade, the management of delayedtrains has received much less attention.

Scheduling and rescheduling of trains from the formal point of view can be found in [24,161].

7.10 Hub Location Problem

Hub location problems are likely to occur in any kind of logistic system. A hub is a specialtype of facility, which collects the flow from a set of other facilities, transfers it to other hubfacilities and distributes it to its final destination.

A hub location problem consists of a location part, in which the locations of the hub nodesare selected, and an allocation part, in which every non-hub node is assigned to one ore morehub nodes [56, 70].

The hub center problem is to locate appropriate numbers of hubs and to allocate nonhubnodes to hub nodes so that the maximum travel time (or distance) between any origin-destination pair is minimized.

7.11 Automatic Train Control

State-of-the-art information and communication technologies allow for an automated driver-less operation of insular mass transit systems. In the long term such options exist for railwayoperation in general. Energy efficiency effects can be achieved through general optimisationof driving style and traffic flows.

Finding the optimum energy-saving train run-curve is one of the issues. The optimisationis made by changing the speed-position profile with keeping the same running time. Analysisof the optimum ‘energy-saving’ train run-curve is one of the difficult research topics of trainoperation.

78 CHAPTER 7. ISSUES OF SCHEDULING & ALLOCATION

7.12 Train Dispatch

The Train Dispatch System handles the scheduling of train traffic. This includes the arrivaland departure of trains from stations and may also include information on which lines to usewhen traveling between stations. We refer to [41, 102, 142, 179] for more details on distributedtrain dispatching system and its complexity issues.

7.13 Shunting and Marshalling

Given description of the status (whereabouts, availability, etc.) of rolling stock, includingtrain bodies waiting to be decomposed, and given description of train bodies to be composed,shunting and marshalling implies both the planning for, and the execution of, plans of shuntingand marshalling.

Shunting and marshalling involves route planning and signalling: i.e. the setting of unitstates. Shunting and marshalling also involves determination of train body, car and wagonpositions.

More information about this topic can be found in [25, 71, 142].

7.14 Passenger & Freighter Information

The main subject of railway information systems is a real-time dissemination of the time andother status of all incoming, arrived or departed trains, whether passenger or freight trains,and if the latter, what freight has been received or passed on, and then to where.

Passenger & freighter information systems are not the subject of the Thesis, instead werefer to [74, 120].

7.15 Line Capacity

Improving railway line capacity (the maximum number of trains which can be moved in eachdirection over a specified line in a 24 hour period) is another optimisation problem that canbe solved with a significant help of computer calculation power.

This topic is also not a part of the Thesis, instead we refer to [1, 54, 136].

7.16 Discussion

We have tried to list several issues (not all) that need to be solved when one should takecare about scheduling and allocation problems on railways. Most of them are interestingoperation researchers’ problems. The most difficult issues are the complexity (most of shownapplication are MP-hard) and definition of appropriate optimisation function.

It is not the aim of this Thesis to solve these issues, instead we refer to [39, 40, 54, 123,142, 146, 148, 196, 207, 210].

Chapter 8

General Resource Planning

8.1 Introduction

This section considers problems faced by all train companies: How to find ‘optimum’ timetable,how to optimise rolling stock resources, how to assign staff to individual jobs, how to managethe maintenance etc. And even more, how today’s computer calculation power can be usedfor dealing with these everyday time-consuming tasks of the railway planning process.

Let us start from the very beginning, let us move many years back in time. Just imaginethere are no nets, no stations, no lines. We only have a map with geographical centersand statistics, that express numbers of predicated passengers or loads between each pair ofgeographical centers in the map. Our goal is to find the most ‘optimum’ railway net andtimetable to satisfy the given statistics.

8.2 Passenger Statistics

8.2.1 Narrative

Passenger statistics (STA) express the predicted number of passengers between pairs of geo-graphical centers (C) (urban areas where the potential passengers live) in time intervals (TxT).From a cartographical map (MAP) one can observe the geographical centers and their positions.

8.2.2 Formal Model

typeMAP, C, POSSTA′ = (C×C) →m ((T×T) →m Nat)STA = |sta:STA′ • wf sta(sta)|

valuewf sta: STA → Boolwf mapsta: MAP × STA → Boolobs Cs: MAP → C-setobs Pos: MAP × C → POS

8.3 Generating Railway Net & Timetable

8.3.1 Narrative

The notions of a railway net (N) and railway station (S) were introduced in detail in Chap. 3.In this section by railway station (S) we mean a place where trains stop to allow passengersto enter and get off a train as reflected in a timetable.

79

80 CHAPTER 8. GENERAL RESOURCE PLANNING

In Chap. 4 a notion of timetable (TT) was shown as a map, that expresses for all plannedtrains (Tn) their journeys (J). A train journey (J) is a list of line visits (departure time from astation, line, arrival time time to a station, train capacity (K), and possible periodicity (PRD)(e.g. 24hour, or 20 minutes) and restrictions (RST) on the days for which it applies (e.g.Mon-Fri only or summer season only)).

Using these basic entities now one can define a function ‘genNTT ’ which from a givengeographical map and passenger statistics, and according to a given set of predicates (P),generates all possible pairs of nets and timetables (NTT), so that these satisfy the map andthe passenger statistics.

8.3.2 Formal Model


TT′ = Tn →m JTT = |tt:TT′ • wf TT(tt)|NTT′ = N × TTNTT = |ntt:NTT′ • wf NTT(ntt)|


P: N × TT → Bool

valuep: Pwf TT: TT′ → Boolwf NTT: NTT′ → Bool

genNTT: (MAP × STA) → P → NTT-infsetgenNTT(map,sta)(p) as intts

post ∀ ntt: NTT • ntt ∈ intts ⇒satisfy(ntt,map) ∧ satisfy(ntt,sta) ∧ p(n,tt)

8.4 Planning Process

8.4.1 Narrative

The function ‘genNTT ’ shown in the previous section generates all possible pairs of railwaynet and timetable. Let us now show how to find one single solution. We define a usual heuristicoperational planning process by function called ‘Planning ’, which from a given geographicalmap and passenger statistics according to a given set of predicates (P) generates one possiblepair of nets and timetables (NTT).

8.4.2 Formal Model

Planning: (MAP × STA) × P∼→ NTT

Planning(map, sta)(p) ≡let ntts = genNTT(map,sta)(p) inif card ntts = 1 then nttselse

if ∃ p′: P • 1 ≤ card genNTT(map,sta)(p′) < card ntts inthen let p′: P • 1 ≤ card genNTT(map,sta)(p′) < card ntts in

Planning(map,sta)(p′) endelse let ntt: NTT • ntt ∈ ntts in ntt end

endendend

8.5. ROLLING STOCK AND STAFF RESOURCES 81

8.5 Rolling Stock and Staff Resources

8.5.1 Narrative

Rolling Stock

Given a net, a timetable and an available rolling stock (RS) one is interested in computingoptimum working plans (VWP) for vehicles (V) of rolling stock such that these plans honourthe timetable. A set of predicates (P) on rolling stock, nets and timetables has to be satisfied(one can operate electric powered engine only on suitable lines, etc.). We model the set ofpredicate as one “grand” predicate.

Human Resources

Given a net and a timetable one can determine the number of human resources (HR) of eachtype (drivers, conductors, etc.) needed to honour the timetable. We refer to separate Chap. 10as well as to paper [203]. Let us just show how one can generate a set of working plans (HWP)for railway employees (H). A set of predicates (P) on human resources, nets and timetableshas to be satisfied. We model the set of predicate as one “grand” predicate.

8.5.2 Formal Model

Rolling Stock

typeV, RS = V-setVWP = (V →m (Tn × J)∗) × RS

P: N × TT × RS × RS → Boolvalue

p: P

genVWP: (N×TT×RS)→P→VWP-setgenVWP(n,tt,rs)(p) as vwps

post ∀ (vwp,rs′):VWP • (vwp,rs′) ∈ vwps ⇒dom vwp ⊆ rs ∧ rs′=rs\dom vwp ∧honour(n,tt,vwp) ∧p(n,tt,rs,rs′)

Human Resources

typeH, HR = H-setHWP = (H →m (Tn × J)∗) × HR

P: N × TT × VWP × HR × HR → Bool

value

p: PgenHWP: (N×TT×VWP×HR)→P→HWP-setgenHWP(n,tt,vwp,hr)(p) as hwps

post ∀ (hwp,hr′):HWP • (hwp,hr′) ∈ hwps ⇒dom hwp ⊆ hr ∧ hr′=hr\dom hwp ∧honour(n,tt,vwp,hwp,hr) ∧p(n,tt,vwp,hr,hr′)

8.5.3 Vehicle Maintenance

8.5.4 Narrative

The earlier vehicle working plans did not specify that any vehicle has to undergo preventivemaintenance. We now define a set of functions, which modify vehicle working plans to reflecttimely maintenance. By maintenance we understand all regular activities which must be donewith rolling stock and according to some rules (R). Each vehicle, according to its type, hasassociated with it certain types of maintenance tasks to be performed with a frequency which

82 CHAPTER 8. GENERAL RESOURCE PLANNING

can be expressed by the elapsed number of kilometers or operating hours since the previousmaintenance.

Given a railway net (N), vehicle working plans (VWP), a timetable (TT) and a planningperiod (TxT) the job is to generate all the possible sets of changes (CS), necessary and sufficientto secure maintenance. Given these sets, one is selected and used for update of existing vehicleworking plans.

The detailed formal domain description of vehicle maintenance planing is given later onin separate Chap. 10 as well as in [203].

8.5.5 Formal Model

typeCS = (DayChange | NightChange | EmptyRide)-set

value

genCS: N×TT×VWP×(T×T)∼→CS-set

MPlanning: N×TT×VWP×(T×T)→(VWP×CS)MPlanning(n,tt,vwp,(tb,te)) ≡

let css = genCS(n,tt,vwp,(tb,te)) inSelect(vwp,css) end

Select: VWP×CS-set → (VWP×CS)Select(vwp,css) as (vwp′,cs)

post cs ∈ css ∧ equivalent(vwp,vwp′)

8.6 Issues of Optimum Function

We would like to emphasize that planning functions provided in previous sections of thischapter are parts of railway domain. So they express planning as it is, not as we would likeit to be.

A generation of all possible pairs of net and timetable is a NP-hard problem. Thatis why it will well be hard to talk about solutions that give ‘absolute optimum’. Lateron during requirement definitions stage we hope that together with mathematicians andoperation researches we will be able to find in reasonable time a solution that is close enoughto the ‘optimum’ solution.

8.7 Discussion

We believe that the given models are a very nice formal description of planning processes thattake place today in all railway companies.

Let us have a look at function ‘Planning ’ given in section 8.4 again. This function generatesone possible pair of net and timetable from a given geographical map statistics and a givenset of predicates. Inside this function the given set of predicates is extended more and moreas far as the function ‘Planning ’ gives one pair of net and timetable (cardinality is equal toone). And this is exactly what is done every year before a new timetable is announced. Weare not searching for the optimum solution, we are searching for sets of predicates that giveus any but one solution.

It is clear that one of the most significant predicate will be that railway infrastructure willremain the same as much as possible, because each change of railway net is very expensive.But on the other hand this approach leaves open doors for minor infrastructure changesexactly as it has been done for years of existence of railways.

There will be also other predicates which reflect number of vehicle, number of employees,strategic goals, political will, etc.

Chapter 9

Train Maintenance

9.1 Introduction

In this chapter we define notions of rolling stock rosters and of maintenance events, and weshow how maintenance events can be added into existing rolling stock rosters.

By maintenance we do not mean only regular check of all systems (assemblies, etc.) in thedepot, but we present maintenance in a more general sense. We understand maintenance as aset of all activities which must be done with rolling stock, regularly according to some rules,and which should be planned in advance except for the operation of rolling stock itself. Thatis the reason why we also include outside and inside cleaning of carriages, refueling dieselengines, refilling supplies into restaurant carriages, water and oil refilling, etc.

Each carriage, according to its type, has certain types of maintenance tasks associated.Each task has a defined frequency of necessary handling upon the carriage. The frequencycan be expressed by the elapsed number of kilometers or operation hours since previousmaintenance was done.

Basically there are two different ways of how to add maintenance to the rolling stockplans.

Rostering with Maintenance is the first possible way. Maintenance is planned alreadyin the rolling stock roster planning process (maintenance is seen just as one of the tasks in theroster). All maintenance actions for all rolling stock are planned in advance. This approachseems to be appropriate for long–distance trains and also for maintenance types that have tobe done quite often (eg., inside cleaning, diesel fuelling, etc.).

Maintenance Routing is the second possible way. In this case, the rolling stock roster hasseveral maintenance opportunities only. That means that not all carriages have maintenancein their plans. In this approach it is necessary to have on–line statistics about actuallyelapsed kilometers and operating hours for all assemblies. Later, during train operation,maintenance checks are planned for those assemblies which are close to reach a given kilometeror time limit. It is done by modifying previous plans in such a way that all assemblies arerouted to maintenance stations. These modifications are called night and day exchanges orempty rides between stations. Maintenance routing better fits short-distance trains, typicallytrains “around” big cities, and also for those types of maintenance, where irregularities canbe expected. For example, a broken engine must be routed to the maintenance station

83

84 CHAPTER 9. TRAIN MAINTENANCE

immediately, with no care about kilometer distance for which it was slated at the time of thebreakdown event.

In this chapter we deal only with the second approach — maintenance routing. Thismeans that our input is a rolling stock roster with several maintenance opportunities (notassigned to concrete assemblies yet). For all assemblies in the network we can find theirposition in the network according to the schedule at a given time, number of kilometers andhours elapsed from the most recent maintenance checks. Certain events (like breakdowns)must be recorded and taken into account as well.

Output from the maintenance routing planning is a list of changes in rolling stock rosterfor the next few days. Once a day, changes and recorded events are applied to the currentrolling stock roster plan and are used as input for the following day’s maintenance routingplanning.

Details to the this problem and full description can be found in [188].

9.2 Maintenance Routing

9.2.1 Narrative

In this section we extend the actual domain phenomena and concepts of railway nets, trains,schedules provided in Chap. 3–6 with rolling stock rosters and maintenance and we build adomain model in a ‘formal methods’ approach — step–by–step.

Maintenance Types

First we extend the general model of railway network shown in Chap. 3. We define differenttypes of maintenance (MT). Some possible maintenance types can be:

Regular operation check Each engine and carriage — according to given rules and safetyregulations — must be checked regularly. There is a limited number of stations where thismaintenance can be made (usually just one for each train type).

Inside cleaning is the most common maintenance operation for passenger carriages. Itcan be done at nearly every station, without additional shunting demands and costs.

Outside cleaning is also common maintenance, but usually not all stations in the networkhave the required equipment.

Diesel engine refuel and Water/sand/oil refill are other examples of maintenancetypes.

Maintenance Plans

We next define maintenance plans (MNTPLAN) as lists of actions (ACTION), which are tempo-rally ordered. These action could be: Working Ride (WR), Empty Ride (ER), and MaintenanceCheck (MNT).

Each assembly type has defined certain maintenance types (REQMNT) that have to be done.There are also given upper limits (MNTLIM) for each assembly and maintenance type. These

9.2. MAINTENANCE ROUTING 85

limits are given either in kilometers or in time intervals. According to the position of thegiven assembly (in a train) and of its assembly type, we can find out how difficult (EXDIF) itis to replace the assembly in the train with another assembly of the same type. Each stationin the set has the defined costs (COST) and required time (MNTDUR) for each maintenance type.

For each assembly and maintenance type one can observe where and when that assemblywas last maintained according to that type. Different topologies and shunting possibilities ofeach station allow or do not allow exchange of two assemblies within certain time limits. Thistime need not be the same for nights as for days.

Planning Functions of Maintenance

We now explain the planning functions. ‘RemDist ’ and ‘RemTime’ calculate remaining dis-tance to the maintenance of a given type either in kilometers or in time interval, for a givenassembly at a given time. ‘MStas’ yields the set of stations that are maintenance stationsfor a given assembly and maintenance type, and in a given network. ‘MTypes’ yields allmaintenance types which a given assembly can undergo at a given station. ‘isMPos’ checksif there is a maintenance opportunity in a given plan, for a given assembly and maintenancetypes. ‘isInSta’ checks if, according to a given plan, a given assembly is at a given stationand at a given time. ‘DisToMS ’ expresses the “distance” to a maintenance opportunity, ina given plan for a given assembly and maintenance type. ‘MntUrg ’ expresses the importanceof undergoing maintenance of a given type at a given time for a given assembly. ‘TMax ’expresses the total time horizon of a given traffic schedule.

9.2.2 Formal Model

extend SCHEDULE S withclass

typeIMP,DIF,COST,MT ==

regular check | out clean |in clean | diesel fuel,

ACTION == WR | ER | MNT,

WR = R,ER = R,MNT = DT × S × DT × MT,

MNTPLAN = ACTION∗,REQMNT = AT →m MT-set,MNTLIM =

(AT × MT) →m (TI | KMS)MNTIMP = (AT × MT) →m IMP,MNTDUR = AT→m (MT→m (S→m TI)),EXDIF = (AT × POS) →m DIF

valuemax imp : IMP,

req mnt : REQMNT,mnt lim : MNTLIM,mnt imp : MNTIMP,mnt dur : MNTDUR,exc dif : EXDIF,

obs LastMnt: A × MT → (TI|KMS),obs MinExDTime: S × DT→ TI,obs MinExNTime: S × DT → TI,

obs ExDCost: S × DT∼→ COST,

obs ExNCost: S × DT∼→ COST,

obs MntCost: N×AT×MT×S×DT∼→COST,

≤ : IMP × IMP → Bool,≤ : DIF × DIF → Bool,

RemDist : A × MT × DT → KMSRemDist(a, mt, t) ≡

obs LastMnt(a, mt) +mnt lim(obs AType(a), mt) −obs Km(a, t),

RemTime : A × MT × DT → TIRemTime(a, mt, t) ≡

obs LastMnt(a, mt) +


mnt lim(obs AType(a), mt) − t,

MStas : N × AT × MT → Sta-setMStas(n, at, mt) ≡

s | s : Sta •s ∈ obs Sta(n) ∧s ∈ dom mnt dur(at)(mt),

MTypes : N × S × AT → MT-setMTypes(n, s, at) ≡

mt | mt : MType •mt ∈ dom mnt dur(at) ∧s ∈ dom mnt dur(at)(mt) ∧s ∈ MStas(n, at, mt),

isMPos : N × AP × AT × MT → BoolisMPos(n, p, at, mt) ≡

∃ s : S, i : Nat •s ∈ MSta(n, at, mt) ∧i, i+1 ⊆ inds p ∧s = ArrS(p(i)) ∧ArrT(p(i)) +

mnt dur(at)(mt)(s) <DepT(p(i+1)),

isInSta: AP × S × DT → BoolisInSta(p, s, t) ≡

∃ i:Nat •i, i+1 ⊆ inds p ⇒ArrT(p(i)) ≤ t ≤DepT(p(i+1)) ∧s = ArrS(p(i)) = DepS(p(i+1)),

DisToMS:

N × AP × AT × MT∼→ (TI|KMS)

DisToMS(n, p, at, mt) ≡if DepS(hd p) ∈ MStas(n, at, mt)then 0else

RideDis(hd p) +DisToMS(n, tl p, at, mt)

end,

MntUrg : A × MT × DT → IMPMntUrg(a, mt, t) ≡

if RemDist(a, mt, t) ≤ 0then max impelse

mnt imp(obs AType(a), mt) /RemDist(a, mt, t)

end

TMax : TS → DTTMax(ts) as tmax post

∀ j : J, i : Nat •j ∈ JSet(ts) ∧ i ∈ inds j ⇒

ArrT(j(i)) < tmax

axiom(α10) ∀ i : IMP • i ≤ max imp,(α11) ∀ n : N, at:AT •

∃ s : S, mt : MT ⇒s ∈ obs S(n) ∧mt ∈ MTypes(n, s, at) ∧s ∈ MStas(n, at, mt),

(α12) ∀ at : AT, mt : MT •mt ∈ req mnt(at) ⇒0 < mnt imp(at, mt) ≤

max imp,(α13) ∀ at : AT, mt : MT •

mt 6∈ req mnt(at) ⇒mnt imp(at, mt) = 0,

(α14) ∀ at : AT •exc dif(at, sol) ≤exc dif(at, las) ≤exc dif(at, fir) ≤exc dif(at, mid),

end

9.3 Maintenance Planning Functions

9.3.1 Narrative

Every day, last-moment changes and updates must be applied to the previously planned rollingstock roster. In this section we describe two basic functions for rolling stock maintenancerouting: ‘Generation of changes to a rolling stock roster ’ and ‘application of changes to aroster.’

Generation of Rolling Stock Roster Changes

Given a rolling stock roster and a net, we can express sets of necessary rolling stock rosterchanges. An example of rolling stock roster for several consecutive days is shown in figure 9.1.

9.3. MAINTENANCE PLANNING FUNCTIONS 87

Figure 9.1: The Original Plan

Each change set is composed from three different types of changes. They are called: ‘DayChange’, ‘Night Change’ and ‘Empty Ride’.

Day Change is composed of two assemblies, of a station and a time, where and when theinterchange between these two assemblies takes place. Day change may occur when the firstassembly is an ‘urgent’ assembly (needs to undergo maintenance check in couple of days) andthe second assembly has a maintenance station in the plan, and when both assemblies are inthe same station at the same time, during a day time, and there is enough time to interchangethem.

In Figure 9.2 the assembly ‘C’ is exchanged at station 1 with the assembly ‘G’ — desig-nated, thus, to reach the maintenance station in two days.

Night Change is quite similar to the day change. The main difference is in the timewhen this change is applied. Night changes may occur when the first assembly is an ‘urgent’assembly and the second assembly has a maintenance station in the plan, and when bothassemblies are in the same depot or station during the same night. It is the least expensiveway in which to add maintenance into the assembly plan.

In Figure 9.3 the assembly ‘D’ is exchanged at station 3 with the assembly ‘G’ — desig-nated, thus, to reach the maintenance station the second night.

Empty Ride is the last possible change that can be applied to the rolling stock roster.This change must be applied, when there is no day or night change possible (ie., when thereis no such situation in the rolling stock roster where two assemblies are in the same stationand time during their operations). In that case, two additional rides have to be added intothe plan. An ‘Empty Ride’ is composed of two assemblies and two additional rides for theseassemblies. In general, an ‘Empty Ride’ is always possible, but it has the highest cost.


Figure 9.2: Example of ‘Day Change’

Figure 9.3: Example of ‘Night Change’

9.3. MAINTENANCE PLANNING FUNCTIONS 89

In Figure 9.4 the assembly ‘B’ is routed from station 2 to station 3 and the assembly ‘G’in the opposite direction.

Figure 9.4: Example of Empty Ride

9.3.2 Formal Model

scheme CHANGES S =extend MAINTENANCE Sclass

typeC == DC | NC | ERDC == mkDC(a1:A,a2:A,t:DT,s:S)NC == mkNC(a1:A,a2:A,t:DT,s:S)ER == mkER(a1:A,a2:A,r1:R,r2:R)CS = C-set

valueNPlan:

TS × C × (DT × DT) → ANPlan(ts,c,(t,t′)) ≡

APlan(ts,UAID(c),(t,CT(c)))APlan(ts,SAID(c),(CT(c),t′))

UAID: C → AIDUAID(c) ≡case c of

mkDC(a, , , ) → obs AsmID(a),mkNC(a, , , ) → obs AsmID(a),mkER(a, , , ) → obs AsmID(a)

end

SAID: C → AIDSAID(c) ≡case c of

mkDC( ,a, , ) → obs AsmID(a),mkNC( ,a, ) → obs AsmID(a),mkER( ,a, , ) → obs AsmID(a)

end

CT: C → DTCT(c) ≡case c of

mkDC( , ,t, ) → t,mkNC( , ,t, ) → t,mkER( , ,r, ) →

let (( , ),( ,t), )=rin t end

end

CS: C → SCS(c) ≡case c of

mkDC( , , ,s) → s,mkNC( , , ,s) → s,mkER( , ,r, ) →

let (( ,s),( , ), )=r


in s endend

MinExT: C → TIMinExT(c) ≡case c of

mkDC( ,t,s) →obs MinExDTime(s,t)

mkNC( , ,t,s) →obs MinExNTime(s,t)

mkER( , ,r, ) →let (( ,s),( ,t), ) = rin obs MinExDTime(s,t)end

endend

9.4 Generating Plan Changes

9.4.1 Narrative

We now present the main function of this chapter: ‘gen Changes’. This function expresses allpossible sets of changes from a given net, traffic schedule and planning period. These changesets are limited by several constraints (ie., post conditions). All changes which are in thegenerated set must be possible, necessary and sufficient.

The ‘possible’ condition checks whether two assemblies are of the same type and whetherthese two assemblies are active assemblies in a given time period. Then it is checked if it is acase that both assemblies are in the same station at the same time for a long enough periodaccording to their plans.

The change is ‘necessary’ when the remaining distance to the next planned maintenanceof an ‘urgent’ assembly is smaller than the distance to the maintenance station in the plan ofthis assembly.

The ‘sufficiency’ condition checks if an ‘urgent assembly’ can arrive at its maintenancestation before exceeding its (time or kilometer) limit according to the new plan.

9.4.2 Formal Model

scheme PLANNING S =extend CHANGES Sclass

typevalue

gen Chgs: N×TS×(DT×DT)∼→CS-set

gen Chgs(n, ts, (t, t′)) as csspre

∃ a : A, mt : MT •DisToMS(APlan(ts, obs AID(a),

(t, t′)), obs AType(a), mt)> RemDis(a, mt, t)

post∀ cs : CS, c : C • c∈ cs ∧ cs ∈ css⇒ isPossible(ts, c, (t, t′)) ∧

isNecessary(ts, c, (t, t′)) ∧isSufficient(ts, c, (t, t′))

isPossible:TS × C × (DT×DT) → Bool

isPossible(ts, c, (t, t′)) ≡obs AType(UA(c)) =

obs AType(SA(c)) ∧UA(c), SA(c) ⊆

ActAsms(ts, (t, t′)) ∧MntUrg(UA(c), mt, t′) >

MntUrg(SA(c), mt, t′) ∧isInSta(APlan(ts, UAID(c),

(t, t′)), CS(c), CT(c)) ∧isInSta(APlan(ts, UAID(c),

(t, t′)), CS(c), CT(c) +MinExTU(c)) ∧

isInSta(APlan(ts, SAID(c),(t, t′)), CS(c), CT(c)) ∧

isInSta(APlan(ts, SAID(c),(t, t′)), CS(c), CT(c) +MinExTU(c)),

isNecessary:TS × C × (DT×DT) → Bool

isNecessary(ts, c, (t, t′)) ≡∃ mt: M •

DisToMS(APlan(ts,UAID(c), (t, t′)),

9.5. APPLYING CHANGES 91

obs AType(UA(a)), mt) >RemaDist(a, mt, t),

isSufficient:TS × C × (DT×DT) → Bool

isSufficient(ts, c, (t, t′)) ≡

∀ mt: MT •mt ∈ req mnt(obs AType(a))⇒DisToMS(NPlan(ts, c, (t, t′)),obs AsmType(UA(c)), mt) ≤RemaDist(UA(c), mt, t)

end

9.5 Applying Changes

9.5.1 Narrative

Once a day, specified changes are applied to the rolling stock roster traffic schedule. We geta new traffic schedule, which is used as an input to next day’s operations. There can be onlyone difference between the old and the new traffic schedule: some trains in the new schedulecan be served by different assemblies of the same type. That means that assembly plans aremodified as shown on Figure 9.5.

Figure 9.5: Plan modification

The correct solution is when all assemblies which require maintenance in the given period,after application of calculated changes in the new traffic schedule, can reach the maintenancestation within the remaining distance.

9.5.2 Formal Model

scheme UPDATE S =extend PLANNING Sclass

valueAppChgs: TS×CS×(DT×DT)→TSAppChgs(ts, cs, (t, t′)) as ts′post

∀ c: C • c ∈ cs ⇒let aid1 = UAID(c),

aid2 = SAID(c)in

APlan(ts, aid1, (t, CT(c))) APlan(ts, aid2, (CT(c), t′)) =

APlan(ts′, aid1, (t, t′))∧APlan(ts, aid2, (t, CT(c))) APlan(ts, aid1, (CT(c), t′)) =

APlan(ts′, aid2, (t, t′))


end∧∀ a: A, mt: MT, cs: CS •

a ∈ ActAsms(ts, (t, t′)) ∧mt ∈ req mnt(obs AType(a)) ∧MntUrgency(a, mt, t) > 0 ⇒

∃ c: C •

c ∈ cs ∧ a = UA(c) ∧DisToMS(APlan(ts′,

obs AId(a), (t, t′)),obs AType(a),mt) ≤

RemDis(a, mt, t)end

9.6 Discussion

A formal model of maintenance routing has been shown. The task was divided into two basicsteps:

• Generation of possible, necessary and sufficient changes of the traffic schedule.

• Application of these changes to the traffic schedule.

We emphasize that we formally characterized schedules, assembly plans and changes inthe plan to meet maintenance demands. On the basis of such formal space software we cannow prescribe requirements and later start with software design.

Chapter 10

Staff Rostering

10.1 Introduction

This chapter has been written with the help of Albena Strupchanska and published as aseparate paper at Forms 2003 in Budapest [203].

Synopsis Staff planning is a typical problem arising in the management of large transportcompanies, including railway companies. It is concerned with building the work schedules(duties and rosters) for staff members needed to cover a planned timetable. Each workschedule is built concerning a given staff type (engine men, conductors, cater staff, etc.).

There are two types of staff planning: long-term planning and short-term planning. In thischapter, we will be interested in long term planning. Normally the long term planning task isseparated into two stages: staff scheduling and staff rostering. Staff scheduling is concernedwith building short-term working schedules, called duties, for staff members such that theysatisfy schedule demands. After this stage it is easy to determine the global number of staffmembers needed to hire such that the working schedules could be performed. Staff rosteringis concerned with ordering of duties into long-term working schedules, called base rosters,and assignment of specific staff members to them such that each staff member performs aroster. During the stage of rostering we have the assumption that we have enough hired staffmembers such that we could assign rosters to them.

In this chapter we will try to explain and analyze first informally and then formally theproblem and we will present a formal model of the domain of staff rostering.

10.2 Adding Deports to NETs

In this section we will extend the notions of nets, stations given in Chap. 3 by depots whichare related to the topology of the railway net from a staff manager point of view.

10.2.1 Narrative

We take as base concept for the railway net the topology of that net. From a railway net (Net)we can observe stations (Sta) and depots (Dep). Depots are personnel bases, i.e places wherestaff members are located. The notion of staff member will be introduced in more detail in thenext section. From a station we can observe a set of depots to which the station can belong.

93

94 CHAPTER 10. STAFF ROSTERING

From a depot we can observe a set of stations from which it is easy to reach the depot. Givena depot and a station we can observe the distance in time (TInt) between them. We will beinterested in these stations and depots which are ‘close’ to each other.

There are at least two stations in a net (α1). There is at least one depot in a net (α2).The set of depots observed from a station consists of depots of the same railway net (α3).The set of stations observed from a depot consists of stations of the same railway net (α4).

10.2.2 Formal Model

We first state some abstract types, ie. sorts, and some observer functions.

scheme NETWORK =classtype Net, Sta, Dep, TInt, StaNm, DepNmvalueobs Stas : Net → Sta-set,obs StaNm : Sta → StaNm,

obs Deps : Net → Dep-set,obs DepNm : Dep → DepNm,obs StaDeps: Sta → Dep-set,obs DepStas: Dep → Sta-set,obs StDepDistance : Sta × Dep → TInt

end

We will then illustrate some axioms:

(α1) axiom ∀ n : Net • card obs Stas(n) ≥ 2

(α2) axiom ∀ n : Net • card obs Deps(n) ≥ 1

(α3) axiom ∀ n: Net • ∀ s : Sta •s ∈ obs Stas(n) ⇒ (∀ d : Dep •

d ∈ obs StaDeps(s) ⇒ d ∈ obs Deps(n))

(α4) axiom ∀ n: Net • ∀ d : Dep •d ∈ obs Deps(n) ⇒ (∀ s : Sta •s ∈ obs DepStas(d) ⇒ s ∈ obs Stas(n))

10.3 Staff Members

We will introduce the notions of staff members and the attributes related to them accordingto a staff manager stake-holder’s perspective.

10.3.1 Narrative

We will call ‘staff’ all the people who are employed in a railway company and who couldperform some actions in order to fulfil a schedule demands.

At the first stage of staff rostering – staff scheduling we will be interested in a part ofthe characteristics that can be related to staff members. Staff members are exchangeable atstaff scheduling stage, that is why we will call them anonymous staff members (AnonStfMbr).From an anonymous staff member we could observe his/her home depot (SMDep). A homedepot of a staff member is the depot of the railway net from where he/she starts and finisheshis/her sequence of actions. There is a notion of a staff type (StfTp). Some possible staff typesare: engine men (engS), conductors (condS), cater staff (caS) etc. From an anonymous staffmember we could observe his/her staff type (SMStfTp). The set of anonymous staff memberswill be called anonymous staff (AnonStaf).

At the second stage of staff rostering we will take into account all the characteristicsthat can be related to a staff member. We assume that staff member’s personal informationmakes him distinguishable from other staff members. So we will call specific staff mem-ber (SpecStfMb) an anonymous staff member with added personal information. From a

10.3. STAFF MEMBERS 95

specific staff member we can observe his personal information as well as home depot and stafftype.

From anonymous and specific staff member we can observe staff member’s name. Itprovides the relation between two abstractions of a staff member – anonymous and specific.

Given a staff type we can observe all the depots which are home depots for staff membersof a given staff type (function ‘deps staff ’ below). Given a staff type and a depot we canobserve all anonymous staff members at this depot of this staff type and respectively theirnumber (functions ‘dstft ’ and ‘dstft num’ below).

10.3.2 Formal Model

We first state some types and some observer functions.

scheme STAFF =extend NETWORK withclasstypeAnonStfMbr, Name,SpecStfMbr, PersInfo,StfTp == engS | condS | catS,AnonStaff = Name →m AnonStfMbr,Staff = Name →m SpecStfMbr

valueobs Name: AnonStfMbr → Name,obs Name: SpecStfMbr → Name,obs SMStfTp : AnonStfMbr → StfTp,obs SMStfTp: SpecStfMbr → StfTp,obs SMDep : AnonStfMbr → Dep,obs SMDep: SpecStfMbr → Dep,obs PersInfo: SpecStfMbr → PersInfo

end

We will then illustrate some axioms and functions:

proj SpecAnonStfMbr: SpecStfMbr →AnonStfMbr

proj SpecAnonStfMbr(ssm) as asmkwpost obs SMStfTp(ssm) = obs SMStfTp(asm)∧ obs SMDep(ssm) = obs SMDep(asm),

proj AnonSpecStfMbr: AnonStfMbr × PersInfo→ SpecStfMbr

proj AnonSpecStfMbr(asm, pinf) as ssmpost obs Name(asm) = obs Name(ssm) ∧obs PersInfo(ssm) = pinf ∧obs SMStfTp(asm) = obs SMStfTp(ssm) ∧obs SMDep(asm) = obs SMDep(ssm),

axiom ∀ asm: AnonStfMbr • ∃! ssm:SpecStfMbr • obs Name(asm) =

obs Name(ssm)

axiom ∀ ssm, ssm′: SpecStfMbr • ssm 6= ssm′⇒ proj SpecAnonStfMbr(ssm) =

proj SpecAnonStfMbr(ssm′)

valuedepStfMbrs : Dep → AnonStaffdepStfMbrs(d) as astfpost (∀ asm: AnonStfMbr •

astf = [ obs Name(asm) 7→ asm ] ∧obs SMDep(asm) = d),

deps staff : StfTp → Dep-setdeps staff(stft) ≡d | d : Dep • ∃ asm : AnonStfMbr •

obs SMStfTp(asm) = stft ∧obs SMDep(asm) = d,

dstft : Dep × StfTp → AnonStaffdstft(d, stft) as astfpost (∀ asm: AnonStfMbr• astf = [ obs Name(asm) 7→ asm ] ∧obs SMDep(asm) = d∧ obs SMStfTp(asm) = stft),

dstft num : Dep × StfTp → Natdstft num(d, stft) ≡ card dom dstft(d, stft),

dsstft grs : Dep-set × StfTp →(Dep × Nat)-set

dsstft grs(ds, stft) ≡ (dep, n) | dep : Dep,n : Nat • dep ∈ ds ∧

n = dstft num(dep, stft)


10.4 Schedule, Journeys and Trips

In this section the notions of schedule, journeys provided in Chap. 4 will be extended withnotions of trips and further the notion of duties.

10.4.1 Narrative

Schedule and Exchange stations A schedule includes information about all train jour-neys such that each train journey is uniquely determined by a train number and a date andtime. A train number is a unique identifier of a train which remains the same from the firstto the last station of its journey. We don’t consider train names here as not all the trains ina railway net have names.

Some of the stations in the net are special from staff management perspective because itis possible either to exchange staff members or a staff member to start or to finish his workthere. We will call such stations exchange stations. From a station we could observe all thestaff types for which this station is an exchange station ‘obs ExchgStas’. Given a station anda staff type we could check if the station is an exchange station or not for this staff type‘is exchgst ’. Exchange stations are located near the depots in the railway net.

Journeys and Trips Staff members are responsible for performing some actions in orderto fulfil the schedule demands. Some of the actions are related to train journeys. Trainjourneys could be both actual journeys with passengers or freights or empty trains journeys.A train journey is a sequence of rides with the same train number. A ride is characterized bya departure station, a departure time, an arrival station, an arrival time and a train betweenthese two stations. Given a schedule we can extract a set of train journeys (jorn set).

There are some restrictions about the maximum working time for a staff member withouta rest. Taking into account these restrictions it is natural to divide a journey into indivisiblepieces of work for staff members. That is why we introduce the notion of a trip. A trip is asequence of rides of a train journey such that the first and the last station of a trip are exchangestations and the duration of a trip is less or equal to maximum permitted uninterrupted workingtime (maxUnIntWrkHr). Each trip is characterized by a train, a departure time, a departurestation, an arrival time, an arrival station and possibly additional attributes. From a trip wecan observe train characteristics for instance kind of the engine, staff types and their numbersneeded to perform a trip etc.

10.4.2 Formal Model

Fist we will state some types (abstract and concrete) and some observer functions.

NETWORK, STAFFscheme SCHEDULE =extend STAFF withclasstypeDate, Hour, Trn, TrnId, LongDistance,Urban, ICE, TGV, StfAttr, NoStf,TrnChar = LongDistance| Urban| ICE| TGV,DateTime = Date × Hour,Ride′ == rd(sta: Sta, dt: DateTime,

nsta: Sta, at: DateTime, trn: Trn),Ride = |rd: Ride′ • wf rd(rd)|,Journey′ = Ride∗,Journey = |j: Journey′ • wf journ(j)|,Trip = Ride∗,TrpAttr == Overnight|Other,SCH= TrnId →m (DateTime →m Journey)

value< : DateTime × DateTime → Bool,

10.4. SCHEDULE, JOURNEYS AND TRIPS 97

/∗ DateTime < DateTime∗/≤: TInt × TInt → Bool, /∗TInt< TInt∗/− : DateTime × DateTime → TInt,− : TInt × TInt → TInt,≤: DateTime × DateTime → Bool,≥: TInt × TInt → Bool,

consec intime: DateTime × DateTime →Bool,

obs TrnId: Trn → TrnId,trnchr: Ride → TrnChar,stfchr: TrnChar → StfTp →m Nat,

obs ExchgStas: Sta∼→ StfTp-set,

techTime: Sta × Trn × StfTp → TInt,maxUnIntWrkHr: StfTp → TInt,/∗ from a staff type (rules taken into accountimplicitly) we can observe the maximalpermitted working time in minutes withouta rest ∗/

maxWrkHr: StfTp → TInt,/∗ from a staff type (rules taken into accountimplicitly) we can observe

the maximal permitted working time∗/tripAttr: Trip → TrpAttr,

wf rd : Ride′ → Boolwf rd(rd) ≡ dt(rd) < at(rd),

wf journ: Journey′ → Boolwf journ(j) ≡(∀ i: Nat • i, i + 1 ⊆ inds j ⇒obs TrnId(trn(j(i))) = obs TrnId(trn(j(i+1)))∧ nsta(j(i)) = sta(j(i+1)) ∧consec intime(at(j(i)), dt(j(i+1)))),

journ set: SCH → Journey-setjourn set(sc) ≡ j| j: Journey •(∀ trnid: TrnId,timdat: DateTime • trnid ∈ dom sc ∧ timdat∈ dom sc(trnid)⇒ j=sc(trnid)(timdat)),

journ set1: SCH → Journey-setjourn set1(sc) ≡ ∪ rng tn| tn:(DateTime →m Journey) • tn ∈ rng scend

Each train journey is divided into trips with subject to a staff type. The following is afunction that divides a journey into trips.

trip list : Journey × StfTp → Trip∗

trip list(j, stft) as trplpost (∀ i : Nat • i ∈ inds trpl ⇒

wf stft trip(trpl(i), stft)) ∧check separation(trpl, stft),

A trip is well formed if it consists of consecutive rides, the first and the last stations of atrip are exchangeable stations and the train during the trip has the same characteristics froma staff member perspective.

wf stft trip: Trip × StfTp → Boolwf stft trip(trp , stft) ≡is exchgst(trip fsta(trp), stft) ∧is exchgst(trip lsta(trp), stft) ∧∼(possible exchg inside(trp, stft)) ∧trip fnT(trp) − trip stT(trp) ≤maxUnIntWrkHr(stft) ∧ same trn(trp, stft),

is exchgst: Sta × StfTp → Boolis exchgst(s, stft) ≡ stft ∈ obs ExchgStas(s),

possible exchg inside: Trip × StfTp → Boolpossible exchg inside(trp, stft) ≡(∀ i: Nat • i ∈ 1..len trp −1 ⇒if is exchgst(nsta(trp(i)), stft) thendt(trp(i + 1)) − at(trp(i)) ≥tech time(trp(i), stft) else false end),

same trn: Trip × StfTp → Boolsame trn(trp, stft) ≡

(∀ i: Nat • i, i + 1 ⊆ inds trp ⇒same trnchr(trnchr(trp(i)),

trnchr(trp(i + 1)), stft)),

same trnchr: TrnChar × TrnChar × StfTp →Bool,

/∗checks if two trains are with the samecharacteristics from the staff point of view∗/

check separation: Trip∗ × StfTp → Boolcheck separation(trpl, stft) ≡(∀ i : Nat • i, i + 1 ⊆ inds trpl ⇒coincident sta(trpl(i), trpl(i + 1)) ∧div sta(trpl(i), trpl(i + 1), stft)),

coincident sta: Trip × Trip → Boolcoincident sta(trp1, trp2) ≡trip lsta(trp1) = trip fsta(trp2),


On the station where we separate the train journey there should be enough time forexchanging the staff members or a staff member to change a train. The time interval betweendeparture and arrival time of a train at this station should be greater or equal to the technicaltime. Technical time is the smallest interval of time for which it is possible to exchange staffmembers or a staff member to change a train.

div sta: Trip × Trip × StfTp→ Booldiv sta(trp1, trp2, stft) ≡trip stT(trp2) − trip fnT(trp1) ≥tech time(last(trp1), stft),

tech time: Ride × StfTp → TInttech time(rd, stft) ≡

techTime(sta(rd), trn(rd), stft),

last: Trip∼→ Ride

last(trp) ≡ trp(len trp)pre len trp ≥ 1,

Finally given a schedule and a staff type we produce the trip set such that each journeythat can be extracted from a schedule is divided into trips.

gen tripss: SCH × StfTp → Trip-setgen tripss(sc, stft) ≡ ∪ trips| trips: Trip-set •

trips = gen trips(sc, stft),

gen trips : SCH × StfTp → Trip-setgen trips(sc, stft) as trpspost (∀ j: Journey • j ∈ journ set(sc) ⇒

trps = elems trip list(j, stft))

The following are some functions that extract some characteristics of a trip.

trip stT: Trip → DateTimetrip stT(trp) ≡ dt(hd trp),

trip fnT: Trip → DateTimetrip fnT(trp) ≡ at(last(trp)),

trip fsta: Trip → Statrip fsta(trp) ≡ sta(hd trp),

trip lsta: Trip → Statrip lsta(trp) ≡ nsta(last(trp)),

trip trn: Trip → Trntrip trn(trp) ≡ trn(hd trp),

trip trnchr: Trip → TrnChartrip trnchr(trp) ≡ trnchr(hd trp),

trip stfchr: Trip → StfTp →m Nattrip stfchr(trp) ≡ stfchr(trip trnchr(trp)),

trip WrkTm: Trip → TInttrip WrkTm(tp) ≡ trip fnT(tp) − trip stT(tp)

10.5 Actions and Duties

10.5.1 Narrative

Actions

Each staff member performs some actions. Actions could be sequences of trips, rests andsome human resource activities. Rests could be rest between trips, meal rests, rests awayfrom home depot including sleeping in dormitories (external rest) etc. By human resourceactivities we mean activities performed by a staff member in order to increase his qualification(seminars, courses etc.).

The sequence of trips is characterized with a start time, an end time and a list of rides. Arest is characterized by a start and an end time, station name and also some attributes. Wewill assume that a rest starts and ends at the same station. Human resource activities havethe same characteristics as rests.

10.5. ACTIONS AND DUTIES 99

Duties

Each staff member is related to a given depot, home depot, in a railway net, which representsstarting and ending point of his work segments. A natural constraint imposes that each staffmember must return to his home depot within a certain period of time. This leads to theintroduction of the concept of duty as a list of actions spanning L consecutive days suchthat its start and end actions are related to the same depot. A duty conforms to some rulesand satisfy some requirements like continuance, working hours per duty etc. Each duty isconcerned with members of the same staff type. From a duty we can observe duty attributesfor example: ‘duty with external rest’, ‘overnight duty’, ‘heavy overnight duty’, ‘long duty’etc. Each duty has some characteristics, such as:

• Start time: it is given explicitly when the first action of a duty is either rest or humanresource activity; in case of a trip it is defined as the departure time of its first rideminus the sum of technical departure time and briefing time,

• End time: it is given explicitly when the last action of a duty is either rest or humanresource activity; in case of a trip it is defined as the arrival time of its last ride plusthe sum of technical arrival time and debriefing time,

• Paid time: it is defined as the elapsed time from the start time to the end time of theduty,

• Working time: it is defined as the duration of the time interval between the start timeand the end time of the duty, minus the external rest, if any.

The above mentioned characteristics are common for every duty. There are other possiblecharacteristics of a duty but they strictly depend on the staff type. For instance, taking intoaccount engine men staff type, we could observe:

• Driving time: it is defined as the sum of the trip durations plus all rest periods betweenconsecutive trips which are shorter than M minutes e.g. 30 minutes,

Attributes and characteristics of duties are taken into account in the scheduling processwhile selecting feasible, efficient and acceptable duties per each depot, and in sequencingduties into rosters. This will be introduced in the next sections.

Given the schedule, staff type, set of depots and rules we can generate duty sets per eachdepot.

10.5.2 Formal Model

scheme DUTY =extend SCHEDULE withclasstypeRestAttr, HRAttr, DtChar,Ac == mk trip(st: DateTime, tripl: Trip∗,

et: DateTime)|mk rest(sr: DateTime, rsta: Sta,ratt: RestAttr, er: DateTime)|

mk hra(sh: DateTime, hsta: Sta,hatt: HRAttr, eh: DateTime),

Duty = Ac∗,

DtAttr==ExtRest|Long|Overnight|HeavyOvernight,

AcR = Ac × StfTp → Bool,AcRS = AcR-set,DuR = Duty × StfTp → Bool,DuRS = DuR -set,DepR = Dep × Duty-set × StfTp→ Bool,DepRS = DepR-set,OvDR = (Duty-set)-set × StfTp → Bool,OvDRS = OvDR-set,RS == check acr(ar: AcRS)|check dur(dur: DuRS)|


check dpr(dpr: DepRS)|check ovdsr(ovdsr: OvDRS)

value

dt maxlenght: StfTp → TInt,dt char: Duty → DtChar,dt attr: Duty → DtAttr

end

Each duty is generated taking into account some depot and some staff type. The followingis a function which generates a duty set for a depot. It generates all possible duties for thedepot.

gendep dutys : Trip-set × StfTp × Dep × RS→ Duty-set

gendep dutys(trps, stft, dep, rs) as dspost (∀ d: Duty • d ∈ ds ⇒

d = gen duty(trps, stft, dep, rs)) ∧∼(∃ d′: Duty • d′ =

gen duty(trps, stft, dep, rs) ∧ d′ 6∈ ds),

Each duty has to start and to end at the same depot and has to conform to some rules.Rules are related to the sequence of actions in a duty, maximal number of actions with agiven characteristics, rest time between actions, overall rest time, overall working time etc.These rules we will call rules at a duty level. Given a trip set, a staff type, a depot and ruleswe can generate a duty for the depot. The function below generates a duty such that its fistand its last action starts and finishes respectively at the depot, the depot is a home depot forstaff members of the given staff type and the duty satisfies the rules.

gen duty : Trip-set × StfTp × Dep × RS →Duty

gen duty(trps, stft, dep, srs) as dpost is wfd(d, stft, srs) ∧ ac dep(hd d, stft) =

dep ∧ dt endt(d) − dt startt(d) ≤dt maxlenght(stft) ∧(∃ trpl : Trip∗ •belong(trpl, d) ⇒ trip stft(trpl, stft, dep)),

is wfd: Duty × StfTp × RS → Boolis wfd(dt, stft, rs) ≡ac dep(hd dt, stft) = ac dep(dt(len dt), stft)∧ comp dtTrips(dt, stft)∧ conf dt rules(dt, stft, rs),

ac dep : Ac × StfTp∼→ Dep

ac dep(ac, stft) as deppost (∃ dep′:Dep •case ac ofmk trip(st, tripl, et) →dep ∈ st stftdep(sta(hd (hd tripl)), stft),

mk rest(sr, rsta, ratt, er) →dep ∈ st stftdep(rsta, stft),

mk hra(sh, hsta, hatt, eh) →dep ∈ st stftdep(hsta, stft)end∧ dep = dep′),

st stftdep: Sta × StfTp → Dep-setst stftdep(st, stft) ≡dep| dep: Dep • dep ∈ obs StaDeps(st)∧is exchgst(st, stft),

/∗ checks if all the trips in a duty has thesame characteristics from staff point ofview ∗/

comp dtTrips: Duty × StfTp → Boolcomp dtTrips(dt, stft) ≡(∀ i: Nat • i ∈ inds dt ⇒case dt(i) ofmk trip(sti, tripli, eti) →(∀ j: Nat • j ∈ inds dt ∧ j 6= i ⇒case dt(j) ofmk trip(stj, triplj, etj) →same trpchr(hd tripli, hd triplj, stft)end)end),

same trpchr: Trip × Trip × StfTp → Boolsame trpchr(trp1, trp2, stft) ≡same trnchr(trip trnchr(trp1),trip trnchr(trp2), stft),

conf dt rules: Duty × StfTp × RS → Boolconf dt rules(dt, stft, rs) ≡ satf(dt, stft, rs)∧(∀ i : Nat • i ∈ inds dt ⇒conf ac(dt(i), stft, rs)),

conf ac: Ac × StfTp × RS → Boolconf ac(ac, stft, rs) ≡case rs ofcheck acr(acrs) → (∀ acr: AcR • acr ∈ acrs⇒ acr(ac, stft))end,

10.5. ACTIONS AND DUTIES 101

/∗checks if the rules for sequencing actions ina duty are satisfied∗/

satf: Duty × StfTp × RS → Boolsatf(dt, stft, rs) ≡case rs ofcheck dur(durs) → (∀ dur:DuR • dur ∈ durs⇒ dur(dt, stft))end,

belong: Trip∗ × Duty → Boolbelong(tpl,dt) ≡ (∃ ac: Ac • ac ∈ elems dt ∧

case ac ofmk trip(st,tpl,et) → trueend),

trip stft: Trip∗ × StfTp × Dep → Booltrip stft(trpl, stft, dep) ≡let stfm = trip stfchr(hd trpl) instft ∈ dom stfm ∧ dstft num(dep, stft) > 0

end,

The set of all duties for a depot has to obey some rules too. The rules/restrictions could berelated to the maximum number of duties with specific characteristics per depot, maximumnumber of duties per depot etc. We will call these rules “rules on a depot level”.

The function below selects a subset of a duty set, generated at the previous stage, suchthat it satisfies the rules on the depot level and there is enough staff at the depot to performthe duty set.

seldep dutys : Trip-set × StfTp × Dep × RS→ Duty-set

seldep dutys(trps, stft, dep, rs) as dspost let ds1 = gendep dutys(trps, stft, dep, rs)

in ds ⊆ ds1 ∧conf dts deprules(dep, ds, stft, rs) ∧enough staff(ds, stft, dep) end,

conf dts deprules: Dep × Duty-set × StfTp× RS → Bool

conf dts deprules(dep,ds,stft, rs) ≡case rs ofcheck dpr(dprs) → (∀ dpr: DepR • dpr ∈dprs ⇒ dpr(dep, ds, stft))

end,

enough staff: Duty-set × StfTp × Dep →Bool

enough staff(ds, stft, dep) ≡dutys staff numb(ds, stft) ≤dstft num(dep, stft),

dutys staff numb: Duty-set × StfTp → Nat,/∗the number of people should be equal tothe number of duties, but in case of aconductor staff type the number of peoplemay be more than the number of duties as twoconductors may have the same duties∗/

Finally given a trip set, a staff type, a depot set and rules we can generate a set of dutiesper each depot.

gen dutys : Trip-set × StfTp × Dep-set × RS→ (Duty-set)-set

gen dutys(trps, stft, deps, rs) as dsspost (∀ ds: Duty-set • ds ∈ dss ⇒

(∃! dep: Dep • dep ∈ deps ∧ds = seldep dutys(trps, stft, dep, rs))) ∧card dss = card deps,

The union of generated sets of duties per each depot has to conform to some overallrules, e.g. the number of duties as a whole with a given characteristics may not exceed somedefined number, etc. Also the generated duties as a whole has to cover all the trips that canbe observed from a schedule. Finally given a schedule, a staff type, set of depots and ruleswe can generate set of duties per each depot such that the above mentioned constraints aresatisfied.

sel dutyss : SCH × StfTp × Dep-set × RS →(Duty-set)-set

sel dutyss(sc, stft, deps, rs) as dsspost let trps = gen tripss(sc, stft) in

dss = gen dutys(trps, stft, deps, rs) ∧cover(dss, trps) ∧ conf dts ovr(dss, stft, rs)end,


cover : (Duty-set)-set × Trip-set → Bool,

conf dts ovr: (Duty-set)-set × StfTp × RS →Bool

conf dts ovr(dss, stft, rs) ≡

case rs ofcheck ovdsr(ovdsrs) → (∀ ovdsr: OvDR •ovdsr ∈ ovdsrs ⇒ ovdsr(dss, stft))end,

The following are some functions concerning a duty and its characteristics.

duty dep: Duty × StfTp → Depduty dep(dt, stft) as deppost dep ∈ st stftdep(dt fsta(dt),stft),

dt fsta: Duty → Stadt fsta(dt) ≡case hd dt ofmk trip( , tripl, ) → trip fsta(hd tripl),mk rest( , rsta, , ) → rsta,mk hra( , hsta, , ) → hstaend,

dt lsta: Duty → Stadt lsta(dt) ≡case dt(len dt) ofmk trip( , tripl, ) → trip fsta(hd tripl),mk rest( , rsta, , ) → rsta,mk hra( , hsta, , ) → hstaend,

dt starttime: Duty → DateTime

dt starttime(dt) ≡case hd dt ofmk trip(st, tripl, et) → st,mk rest(sr, rsta, ratt, er) → sr,mk hra(sh, hsta, hatt, eh) → shend,

dt endtime: Duty → DateTimedt endtime(dt) ≡case dt(len dt) ofmk trip(st, tripl, et) → et,mk rest(sr, rsta, ratt, er) → er,mk hra(sh, hsta, hatt, eh) → ehend,

duty stft num: Duty → StfTp →m Natduty stft num(dt) as stfmpost (∃ trpl: Trip∗ • belong(trpl, dt) ⇒stfm = trip stfchr(hd trpl))

10.6 Rosters and Staff Members

In this section we will explain the notion of a roster and how it is related to staff members.

10.6.1 Narrative

Rosters

During the second stage of staff rostering the duties generated at the previous stage areordered in rosters which are long term working schedules assigned to specific staff members.For each depot in a depot set, a separate staff rostering problem is solved considering onlythe corresponding duties. We will introduce two help notions in order to explain the conceptof roster and its stages of generation.

A plan roster is a sequence of duties generated for anonymous staff members of the samestaff type. A base roster is a cyclic sequence of a plan roster such that it spans trough aplanning period determined by a schedule. In other words, a plan roster is that part ofthe base roster which is repeated several times and a base roster is just a cyclic sequence ofduties. Each base roster has to satisfy some rules. The rules are about the order of duties in aconsecutive days and their attributes. Also there are some constraints the concerning numberof duties in a base roster with determined attributes. These rules we will call conventionallyrules at the roster level.

10.6. ROSTERS AND STAFF MEMBERS 103

So given a schedule, staff type, depot and rules, we can generate base rosters for the givendepot. These base rosters have to cover all the duties corresponding to this depot and have toconform to some rules. The rules at this level we will call conventionally rules at the overallroster level.

All the duties in a base roster has to be performed by a specific staff member. We will callroster a cyclic sequence of duties (base roster) for a specific staff member such that he/shecould perform them. So from a base roster and a staff type we can generate rosters. Thenumber of staff members assigned to the base roster is equal to the length of the plan roster.All staff members perform the base roster but starting on a different day.

Staff Members

During the assignment of duties in a base roster to staff members we consider specific staffmembers. At this stage we are working with specific staff members as we are interested intheir personal information. From the staff member’s personal information we could observehis/her private information (obs PrInf) as date of birth, place of living, address etc. Alsowe could observe his qualification (obs Qual), special work requirements (obs SpWrkReq) andthe list of his/her previous duties (obs PrevDuty).

Given a base roster and a staff member, we can observe his roster which is considered tohis/her attributes.

10.6.2 Formal Model

scheme ROSTER =extend DUTY withclasstypeInfo, WrkReq, Qualification,PlRos = Duty∗,BRos = PlRos × Nat,RoR = PlRos × StfTp → Bool,RoRS = RoR-set,OvR = BRos × StfTp → Bool,OvRS = OvR-set,eRS == RS | check ror(rrs : RoRS) |check ovrs(ovrs : OvRS),

Ros = SpecStfMbr →m BRos

valuef : eRS → RS,obs PrInf : PersInfo → Info,obs SpWrkReq : PersInfo → WrkReq,obs PrevDuty : PersInfo → Duty∗,obs PostDuty : PersInfo → Duty∗,obs Qualf : PersInfo → Qualification,obs PlPer : SCH → Nat,

bros length : BRos → Natbros length(bros) ≡let (plros, rnumb) = bros inlen plros end

end

The following function generates all possible base rosters for a given duty set (related toa depot).

gen dep bross : SCH × StfTp × Dep × eRS→ BRos-set

gen dep bross(sc, stft, dep, rs) as brosspost (∀ bros : BRos •

bros ∈ bross ⇒bros = genbros dep(sc, stft, dep, rs)) ∧

∼(∃ bros′ : BRos •bros′ = genbros dep(sc, stft, dep, rs) ∧bros′ 6∈ bross),

genbros dep : SCH × StfTp × Dep × eRS→ BRos

genbros dep(sc, stft, dep, rs) as bros postlet ds = dep dutyset(dep, stft) incover rds(bros, ds)end ∧ wf bros(bros, sc, stft, rs),

cover rds : BRos × Duty-set → Bool,


wf bros : BRos × SCH × StfTp × eRS→ Bool

wf bros(bros, sc, stft, rs) ≡let (plros, rnumb) = bros in

same qualific(plros, stft) ∧conform cplrosrs(plros, stft, rs) ∧len plros ∗ rnumb = obs PlPer(sc)end,

same qualific : PlRos × StfTp → Boolsame qualific(plros, stft) ≡(∀ i : Nat • i, i + 1 ⊆ inds plros ⇒sm qual(plros(i), plros(i + 1))),

sm qual : Duty × Duty → Bool,

conform cplrosrs : PlRos × StfTp × eRS→ Bool

conform cplrosrs(plros, stft, rs) ≡conform plrosrs(plros, stft, rs) ∧let cycros = 〈plros(len plros)〉〈hd plros〉 in

conform plrosrs(cycros, stft, rs)end,

conform plrosrs : PlRos × StfTp × eRS→ Bool

conform plrosrs(plros, stft, rs) ≡case rs ofcheck ror(rrs) →(∀ rr : RoR • rr ∈ rrs ⇒ rr(plros, stft))

end,

The generated, at the previous stage, set of base rosters has to conform to some rules asmaximum percentage of base rosters with particular characteristics etc.

sel dep bross: SCH × StfTp × Dep × eRS→ BRos-set

sel dep bross(sc, stft, dep, rs) as brosspost let bross1 = gen dep bross(sc, stft,

dep, rs) in bross ⊆ bross1 ∧conform bros rules(bross, stft, rs)end,

conform bros rules : BRos-set × StfTp × eRS

→ Boolconform bros rules(bross, stft, rs) ≡(∀ bros: BRos • bros ∈ bross ⇒case rs ofcheck ovrs(ovrs) →(∀ ovr : OvR •

ovr ∈ ovrs ⇒ ovr(bros, stft))end),

Having a base roster and a staff type and a depot we can produce rosters for the specificstaff members of the given staff type.

gen ssmros : BRos × StfTp × Dep → Rosgen ssmros(bros, stft, dep) as rospost let sms = dstft gr(dep, stft) in

ros = assignment(bros, sms) ∧card dom ros = bros length(bros)end,

dstft gr : Dep × StfTp → Staffdstft gr(dep, stft) ≡let anstaff = dstft(dep, stft) in

get staff(anstaff)end,

get staff: AnonStaff → Staffget staff(anstaff) as staffpost (∀ asm: AnonStfMbr • asm ∈rng anstaff ⇒

(∃! ssm: SpecStfMbr • ssm ∈ rng staff ∧obs Name(asm) = obs Name(ssm)))

Given a base roster and staff we assign specific staff members to the base roster such thatwe receive a set of rosters. The number of rosters is equal to the length of the base roster.All the rosters are permutations of the base roster. So at this stage of planning we assignspecific staff members to duties in the plan roster (cyclic part of the base roster).

assignment : BRos × Staff → Rosassignment(bros, staff) as rospost (∀ dt : Duty • duty in bros(dt, bros)⇒

(∃! ssm : SpecStfMbr • ssm ∈ dom ros ∧

dt = first bros duty(ros(ssm)) ∧conform rsm(ros(ssm),ssm) ∧permutation(ros(ssm), bros)))

pre card rng staff > bros length(bros),

10.6. ROSTERS AND STAFF MEMBERS 105

duty in bros: Duty × BRos → Boolduty in bros(dt, bros) ≡let (plros, rnumb) = bros indt ∈ elems plros end,

first bros duty: BRos → Dutyfirst bros duty(bros) ≡let (plros, rnumb) = bros inhd plros end,

Each roster is assigned to a specific staff member according to his/her qualification, specialwork requirements and previous duties such that he/she could perform it.

conform rsm : BRos × SpecStfMbr → Boolconform rsm(bros, ssm) ≡satisfy qual(bros,obs Qualf(obs PersInfo(ssm))) ∧

satisfy predt(bros,obs PrevDuty(obs PersInfo(ssm))) ∧

satisfy swr(bros,

obs SpWrkReq(obs PersInfo(ssm))),

satisfy qual : BRos × Qualification → Bool,satisfy predt : BRos × Duty∗ → Bool,satisfy swr : BRos × WrkReq → Bool,

permutation: BRos × BRos → Bool,

Finally we generate the rosters for the given depot and staff type so that for each baseroster generated at the previous stage, we generate rosters.

gen sross : SCH × StfTp × Dep × eRS → Rosgen sross(sc, stft, dep, rs) as rospost let bross =

sel dep bross(sc, stft, dep, rs) in

(∀ bros : BRos • bros ∈ bross ⇒ros = gen ssmros(bros, stft, dep))

end,

All rosters are generated taking into account a staff type. So using the function abovewe can generate all rosters per depot for all staff types related to this depot. In this case togenerate rosters per depot we will need only the schedule, the depot and the rules.

dep rosters : SCH × Dep × eRS →StfTp →m Ros

dep rosters(sc, dep, rs) as stft rosspost (∃! stft : StfTp •

stft ∈ dep stftypes(dep) ⇒let rset = gen sross(sc, stft, dep, rs) instft ross = [ stft 7→ rset ] end)

∧ card dep stftypes(dep) =card dom stft ross,

dep stftypes : Dep → StfTp-setdep stftypes(dep) ≡ stft| stft: StfTp •∃ ssm: SpecStfMbr •obs SMDep(ssm) = dep,

Base rosters and respectively rosters are generated per depot and we have the assumptionthat after the staff scheduling stage all duties generated per depot are shifted to the depot.If this is not the case we could observe all the duties generated in staff scheduling stage perdepot (dep dutyset) which will help us to integrate the two stages of staff planning into one.So given a schedule, a staff type, a set of depots and rules we will produce all rosters per eachdepot in the depot set for the given staff type.

obtain ross : SCH × StfTp × Dep-set × eRS→ Ros-set

obtain ross(sc, stft, deps, rs) as rossetpost let dtss = sel dutyss(sc, stft, deps, f(rs))in (∀ ross : Ros • ross ∈ rosset ⇒

(∃! dep : Dep • dep ∈ deps ⇒ross = gen sross(sc, stft, dep, rs) ∧

dep dutyset(dep, stft) ∈ dtss)) end ∧card rosset = card deps,

dep dutyset: Dep × StfTp → Duty-setdep dutyset(dep, stft) ≡dt| dt: Duty • dep = duty dep(dt, stft)

The rest is a small part of the possible functions for operating staff members in depots.


hire sm: SpecStfMbr × Staff∼→ Staff

hire sm(ssm, stf) ≡ stf ∪[ obs Name(ssm) 7→ ssm ]pre (∀ ssm′: SpecStfMbr • ssm′ ∈ rng stf ⇒

obs Name(ssm′) 6= obs Name(ssm)) ∧ssm 6∈ rng stf,

fire sm: SpecStfMbr × Staff∼→ Staff

fire sm(ssm, stf) ≡ stf \ obs Name(ssm)pre obs Name(ssm) ∈ dom stf,

hired sm: SpecStfMbr × Staff → Boolhired sm(ssm, stf) ≡ ssm ∈ rng stf,

add specsm: AnonStfMbr × PersInfo × Name→ SpecStfMbr

add specsm(asm, pinf, nm) as ssm

post obs Name(asm) = nm ∧obs SMStfTp(asm) = obs SMStfTp(ssm) ∧obs SMDep(asm) = obs SMDep(ssm) ∧obs PersInfo(ssm) = pinf,

get specsm : AnonStfMbr × PersInfo→ SpecStfMbr

get specsm(asm, pinf) as ssmpost obs Name(asm) = obs Name(ssm) ∧obs PersInfo(ssm) = pinf,

dep staff : Dep → Staffdep staff(dep) ≡let anstaff = depStfMbrs(dep) inget staff(anstaff)end

10.7 Discussion

In this chapter the problem of rostering have been analyzed. The basic notion of railway netgiven in Chap. 3, timetables and schedules given in Chap. 4 was extended by new terms suchas trips, actions, duties, rosters.

Part IV

Railway Signalling and Interlocking

107

Chapter 11

Issues of Train Monitoring andControl

11.1 Introduction

Railway monitor and control systems are systems used on railways to control traffic safely, forexample, to prevent trains from colliding. Trains are uniquely susceptible to collision because,running on fixed rails, they are not capable of avoiding a collision by steering away, as cana road vehicle; furthermore, trains cannot decelerate rapidly, and are frequently operating atspeeds where by the time the driver/engineer can see an obstacle, the train cannot stop intime to avoid colliding with it.

Most forms of train control involve messages being passed from those in charge of the railnetwork or portions of it (e.g., a stationmaster) to the train crew; these are known as ‘signals’and from this the topic of train control is known as ‘signalling’.

This chapter shows several examples of railway monitoring and control tasks with cross–references to other places in the Thesis and to bibliography. Formal verification of safetycritical properties of railway monitoring and control issues can be found in [4, 6, 8, 57, 97,137, 176].

11.2 Line Direction Agreement Device

Each line connects exactly two stations. At any point in time, the line can be open in at mostone direction. This is a safety requirement to protect head-on train crashes on the line.

Formal models and verification of interlocking systems for railway lines can be foundin [29, 89, 199]. In the Thesis whole Chap. 13 describes line direction agreement devices indetail.

11.3 Station Interlocking

In railway signaling, an interlocking is an arrangement of signal apparatus that preventsconflicting movements through an arrangement of tracks such as junctions, crossings, andso forth. The signaling appliances and tracks are sometimes collectively referred to as aninterlocking plant. An interlocking is designed so that it is impossible to give clear signals totrains unless the route to be used is proved to be safe.

109

110 CHAPTER 11. ISSUES OF TRAIN MONITORING AND CONTROL

A typical railroad definition of interlocking is “an arrangement of signals and signal appli-ances so interconnected that their movements must succeed each other in proper sequence.”

The minimum interlocking consists of signals, but usually includes additional applianceslike switches, derails, crossings at grade and movable bridges. Some of the fundamentalprinciples of interlocking include:

• Signals may not be operated to permit conflicting train movements to take place at thesame time.

• Switches and other appliances in the route must be properly ‘set’ (in position) before asignal may allow train movements to enter that route.

• Once a route is set and a train is given a signal to proceed over that route, all switchesand other movable appliances in the route are locked in position until either the trainpasses out of the portion of the route affected, or the signal to proceed is withdrawnand sufficient time has passed to ensure that a train approaching that signal has hadopportunity to come to a stop before passing the signal.

To cover that topic formally interlocking specification languages (ExSpect, EURIS, etc.)have been introduced [7, 11, 30, 76, 77, 79, 83, 84]. We also refer to other work concerningformal specification and modeling of railway interlocking systems [42, 75, 77, 82, 85, 105, 106,107, 131, 156, 147, 191].

In the Thesis in Chap. 14 and in [209] the usage of Petri nets for modeling of stationinterlocking is shown.

11.4 Signalling

The purpose of signalling is to inform the train driver when it is safe to proceed on the lineahead. In early days the signalman was responsible for ensuring any switch was set correctlybefore allowing a train to proceed. Mistakes were made and accidents occurred, sometimeswith fatalities. The concept of interlocking of points, signals, and other appliances was intro-duced to improve safety. Interlocking prevents the signalman from operating appliances in anunsafe sequence, such as setting the signal to clear while one or more points in the route thesignal governs are improperly set. Early interlocking systems used mechanical devices bothto operate the signalling appliances and ensure their safe operation, but the contemporaryinterlocking systems operate using complex electronic circuitry.

Application of formal methods to railway signalling on lines can be found in [59, 60, 61,64, 73, 113].

Dwarf Signals Dwarf Signals are station signals and can be located almost anywhere on astation, where a signal for switching or for flank protection is required. Dwarf Signal proceedaspects are only valid for switching, not for trains proceeding outside the station area.

Formal specification of the control process for a Dwarf signal can be found in [155, 154].Dwarf signal controller was also formally specified in WDM [144], in B-method [145] and inRAISE [174]. A CSP Model of the Alcatel Dwarf signal can be found in [213].

Signalling on Lines On the lines, automatic block signals (ABS) are commonly used. ABSsystems consist of a series of signals that govern blocks of track between the signals. The

11.5. LEVEL RAILWAY CROSSING 111

signals are automatically activated by the conditions of the block beyond the signal. If a trainis currently occupying a block, that block’s signal will not allow a train in the previous blockto proceed into the block, or will only allow it to proceed at a speed which allows the trainto stop before colliding with the train or another object (also known as restricted speed).

Automatic block signals also detect the status of a following signal. If a signal is displayinga stop indication, the preceding signal will display an aspect that warns the train crew thatthe following signal may require the train to stop.

ABS systems detect track occupancy by passing a low-voltage current through the trackbetween the signals and detecting whether the circuit is closed, open, or shorted. A train’smetal wheels and axles will pass current from one rail to the other, thereby shorting the circuit.If the ABS system detects that the circuit is shorted between two signals, it understands thata train is occupying that block and will “drop” the signals (display a stop indication) oneither side of that block to prevent another train from entering. ABS system electronics arealso able to detect breaks in the rail or improperly-lined switches, which result in an opencircuit. These will also cause the signal’s aspect to drop, preventing any trains from enteringthe block and running the risk of bending, breaking, or overturning the rail and derailing orrunning through an improperly-lined switch.

In the Thesis the whole Chap. 12 shows formal statechart model for ABS system. Usageof Petri nets in the railway signalling can be found in [150].

11.5 Level Railway Crossing

The term level railway crossing is a crossing on one level (“at-grade intersection”) withoutrecourse to a bridge or tunnel of a railway line by a road, path, or another railroad.

Early level crossings had a flagman in a nearby booth who would, on the approach of atrain, wave a red flag or lantern to stop all traffic and clear the tracks. Manual or electricalclosable gates that barricaded the roadway were later introduced. With the appearance ofmotor vehicles, this barrier became less and less effective. Many countries therefore substi-tuted the gated crossings with less strong but highly visible barriers and relied upon roadusers following the associated warning signals to stop.

The consensus in contemporary railway design is to avoid the use of level crossings. Theuse of level crossings contributes the greatest potential for catastrophic risk on the railways.Bridges and tunnels are now favoured.

There are several papers that deal with the level crossing in a formal way [69, 103, 158,159, 202].

11.6 Interlocking Safety and Reliability

Railway monitoring and control system are safety-critical systems. It means that their failurecould result in loss of life, significant property damage, or damage to the environment. Thedegree of safety is hard to identify. Computers are increasingly being embedded within safetysystems [2, 4, 5, 58, 126]. That means that one has to compute probability of a failure ofsuch system.

Using Z-specification for railway interlocking safety can be found in [3]. Formal verificationprocess and proving safety can be found in [10, 52, 125, 127, 152, 177, 192, 193, 197, 198].Examples of practical usage of formal methods in interlocking safety are shown in [43, 95, 151].

112 CHAPTER 11. ISSUES OF TRAIN MONITORING AND CONTROL

11.7 Automatic Train Control

An automatic train control system (ATC) is when the train receives data at all times inorder to maintain the correct speed and prevent trains from passing stop signals if the drivershould fail to react. Modelling and Simulation of train control systems can be done with Petrinets [219]. Using Prolog for a railway control system is shown in [9]. Other papers like [17,36, 29] tackle automatic train control also formally. New generation of microcomputer-basedoperations control systems for high-speed rail TRANSRAPID can be found in [139].

11.8 European Rail Traffic Management System (ERTMS)

Over the past decade, industrial giants and European governments have strived to attain railinteroperability, so that trains can cross borders without stopping. Today, each country stillhas its own rail “language” for managing the movement of the trains on its network.

In order to redress these incompatibilities, the European Rail Traffic Management Systemproject has been set up to create unique signaling standards throughout Europe called ETCS.

The ERTMS is the new signaling and management system for Europe, enabling interop-erability throughout the European Rail network.

11.9 Discussion

We have listed several basic topics, that must be solved when one takes care about monitoringand control of railways. Not all possible railway applications were mentioned in this chapter.Several more could be covered, like breaking systems, door opening systems, train integritycontrol, telecommunications, detection of train position, etc.

Most of the issues can be covered by formal methods like Petri net, statecharts or livesequence charts. There are also works that deal with a formal specification language designedspecially for railway interlocking specification, see [94, 122].

Chapter 12

Automatic Line Signalling

12.1 Introduction

The problem with high train speed and low coefficient of friction between train wheels andtrack is that the drivers cannot stop their trains within sighting distance of another train orwithin sighting distance of a signal. This is the reason why automatic signaling is used onsome lines. If there are junctions or turnouts then ‘semi-automatic signalling’ is required.More on station interlocking systems is described in Chap. 14.

In this chapter we first narrate the principle of automatic signalling on lines. Then wegive formal description examples using statecharts [110] of what we have described.

12.2 Line Segmentation

Lines are usually divided into segments l = 〈s1, s2, ..., si−1, si, si+1, ..., sn〉. Line l connectsexactly two stations - staA and staB. A line can be in one of three possible states: ‘OpenAB ’,‘OpenBA’ and ‘Close’. These states and their possible transition are described in detail inChap. 13 on Line Direction Agreement System.

Figure 12.1: Automatic Line Signalling

Each segment can be in two states: ‘segFree’ and ‘segOccupied ’. Segment si is in ‘segFree’when no train is detected in the segment. Segment si is in ‘segOccupied ’ when a train isdetected in the segment.

113

114 CHAPTER 12. AUTOMATIC LINE SIGNALLING

12.3 First Segment of the Line

12.3.1 Narrative

For segment s1 there is only only one signal sigBA1 that is controlled automatically (seeFig. 12.1). The missing signal in the opposite direction is controlled manually and is placedin the station A. A detailed description of station interlocking is given later on in Chap. 14.

Figure 12.2: Signal state machine — possible transitions

With signal sigBA1 we associate four possible states: ‘sigOnRed ’, ‘sigOnYellow ’, ‘sigOnGreen’and ‘sigOff ’. Figure 12.2 shows possible transitions between these four states. The signalsigBA1 is always in one of these four states.

Signal sigBA1 is in‘sigOnRed ’ state, when line l is in ‘OpenBA’ state and segment s1 is in ‘segOccupied ’ state,‘sigOnGreen’ state, when line l is in ‘OpenBA’ state, segment s1 is in ‘segFree’ and station

A is open for incoming trains from direction B‘sigOnYellow ’ state, when line l is in ‘OpenBA’ state, segment si is in ‘segFree’ and station

A is closed for incoming trains from direction B‘sigOff ’ state, when line l is in ‘OpenAB ’ or ‘Closed ’ state.

12.3.2 Formal Model: Statechart

Figure 12.3: Statecharts of First Segment

12.4. GENERAL INNER SEGMENT OF THE LINE 115

Figure 12.3 presents statechart for the first segment s1 of the line. Rectangles representstates, arrows the possible transitions between them. Default states are marked with arrowswith a full black dot at the end.

12.4 General Inner Segment of the Line

12.4.1 Narrative

For each inner segment si, where i = 〈2, ..., n− 1〉, there are two signals sigABi and sigBAi

(one in each direction of travel). With each signal we associate four possible states: ‘sigOnRed ’,‘sigOnYellow ’, ‘sigOnGreen’ and ‘sigOff ’. Figure 12.2 shows possible transitions betweenthese four states.

Signal sigABi is in‘sigOnRed ’ state, when line l is in ‘OpenAB ’ state and segment si is in ‘segOccupied ’ state,‘sigOnGreen’ state, when line l is in ‘OpenAB ’ state and segments si and si+1 are in ‘segFree’

state,‘sigOnYellow ’ state, when line l is in ‘OpenAB ’ state, segment si is in ‘segFree’ and segment

si+1 are in ‘segOccupied ’ state,‘sigOff ’ state, when line l is in ‘OpenBA’ or ‘Closed ’ state.

Signal sigBAi is in‘sigOnRed ’ state, when line l is in ‘OpenBA’ state and segment si is in ‘segOccupied ’ state,‘sigOnGreen’ state, when line l is in ‘OpenBA’ state and segments si and si−1 are in ‘segFree’

state,‘sigOnYellow ’ state, when line l is in ‘OpenBA’ state, segment si is in ‘segFree’ and segment

si−1 are in ‘segOccupied ’ state,‘sigOff ’ state, when line l is in ‘OpenAB ’ or ‘Closed ’ state.

Each segment has two signals, each signal can be in four states. Therefore we have a potentialnumber of 16, but possible combinations are only:

sigABi sigBAi

‘sigOnRed ’ ‘sigOff ’‘sigOnYellow ’ ‘sigOff ’‘sigOnGreen’ ‘sigOff ’

‘sigOff ’ ‘sigOff ’‘sigOff ’ ‘sigOnRed ’‘sigOff ’ ‘sigOnYellow ’‘sigOff ’ ‘sigOnGreen’

From the above table one can see that there is no combination of signals sigABi and sigBAi

that allows entry of the train from both sides of the segment at the same time. Signal thatis in state ‘sigOnRed ’, ‘sigOnYellow ’ or ‘sigOnGreen’ is always combined with signal in state‘sigOff ’.


Figure 12.4: Statecharts of general inner segment


Figure 12.4 presents statechart for the inner segment si, where i = 〈2, ..., n − 1〉. In eachinner segment there are two signals sigABi and sigBAi (one in each direction of travel).Dotted line represents parallel behaviour. The command ‘setDirectionAB ’ sets sigABi inSIGNAL ON state and sigBAi in SIGNAL OFF. The command ‘setDirectionBA’ sets sigABi

in SIGNAL OFF state and sigBAi in SIGNAL ON.

12.5 Last Segment of the Line

12.5.1 Narrative

For segment sn there is only only one signal sigABn that is controlled automatically (seeFig. 12.1). The missing signal in the opposite direction is controlled manually and is placedin the station B. A detailed description of the station interlocking is given later on in Chap. 14.

With signal sigABn we also associate four possible states: ‘sigOnRed ’, ‘sigOnYellow ’,‘sigOnGreen’ and ‘sigOff ’. Figure 12.2 shows possible transitions between these four states.The signal sigABn is always in one of these four states.

Signal sigABn is in‘sigOnRed ’ state, when line l is in ‘OpenAB ’ state and segment sn is in ‘segOccupied ’

state,‘sigOnGreen’ state, when line l is in ‘OpenAB ’ state, segment sn is in ‘segFree’ and station

B is open for incoming trains from direction A‘sigOnYellow ’ state, when line l is in ‘OpenAB ’ state, segment sn is in ‘segFree’ and station

B is closed for incoming trains from direction A‘sigOff ’ state, when line l is in ‘OpenBA’ or ‘Closed ’ state.

12.6. OVERALL MODEL 117


Figure 12.5 presents statechart for the last segment sn of the line.

Figure 12.5: Statecharts of Last Segment

12.6 Overall Model

12.6.1 The Line with One Segment Only

There are no signals which are controlled automatically on lines with one segment only. Bothsignals at the ends are controlled by station managers. Station interlocking is solved inChap. 14 in the Thesis. The principle of line direction agreement shown in Chap. 13 mustalso be followed.

12.6.2 The Line with Two Segments

Figure 12.6 shows a statechart of lines that are composed by two segments. On such lines,there are only two signals that are controlled automatically according to the principles givenin this chapter. Therefore the final statechart will be a parallel composition of Fig. 12.3 andFig. 12.5.

12.6.3 The Line with Three and More Segments

Figure 12.7 shows overall statecharts for automatic line signalling. Vertical dotted linesrepresent parallel behaviour of the system. The total number of segments on lines influencesthe final appearance of the statechart. For each segment there will be one paralel block ofstatechart.


Figure 12.6: Two segments statecharts

12.7 Discussion

In this chapter automatic line signalling has been described. It deals with lines where treestates signals are installed. The length of the segments depends on the maximum permittedspeed of trains. The higher the speed of train on the line, the longer the breaking distanceof the train, and the longer the segment length is. Therefore the total capacity of the linegoes down when speeds of trains differ. To increase the total capacity of line it is possibleto install signals with more than tree states in a smaller distance, usually with four states.More states enable the indication of more signals ahead of trains. Therefore there is no needof having the length of a segment longer than a breaking distance of the fastest train.

12.7. DISCUSSION 119

Figure 12.7: Statechart of automatic line signalling

Chapter 13

Line Direction Agreement

13.1 Introduction

In this example we first narrate the principle of the Line Direction Agreement Device. Thenwe give formal description examples using Statecharts [110] and Live Sequence Charts [63].

Each line connects exactly two stations. At any point in time, the line can be open in nomore than one direction. This is a safety requirement to protect head-on train crashes on theline.

In the old days, a line specific sheet of paper (or a baton) was used and only that stationthat had the sheet (or the baton) could send trains to the line. The sheet (or the baton) wassent by trains between stations. Later on, the sheet of paper was replaced by abstract tokenswith electronically produced transitions (electric token block or radio electronic token block).

13.2 Line Direction Agreement System

The Line Direction Agreement System (LDAS) is a device that is responsible for fail-safecommunication (token transition) and train direction control on the line between two stations.

Consider a line l that connects two stations: stationA and stationB. The line can be ineither of three basic states: ‘OpenAB ’ (trains are allowed to travel from stationA to stationB),‘OpenBA’ (trains are allowed to travel from stationB to stationA) and ‘Close’ (trains are notallowed to travel neither direction). In each station there is one operator who is responsiblefor sending trains to the line. Agreement on the train direction, between two such stations, isthen made by pressing these buttons a following communication between stations and LDAS.(see Fig. 13.1).

The Line Direction Agreement Device is therefore composed from three parts: LDAS,STATION A and STATION B.

In both stations the operator has three buttons: YES, NO and CHANGE. From STA-TION A to LDAS there are four types of commands which can be sent: ‘ChangeA’, ‘AgreeA’,‘DisagreeA’ and ‘InitAB ’. From STATION B to LDAS there are also four types of commands:‘ChangeB ’, ‘AgreeB ’, ‘DisagreeB ’ and ‘InitBA’. LDAS can send either of three different com-mands to STATION A: ‘OpenA’, ‘CloseA’ or ‘AskChangeA,’ or three different commands:‘OpenB ’, ‘CloseB ’ or ‘AskChangeB ’ to STATION B.

The behavior of the system in response to internal and external stimuli depends on thestate(s) it is currently in. Therefore, for graphical representation of internal behavior we intro-

121

122 CHAPTER 13. LINE DIRECTION AGREEMENT

Figure 13.1: Communication with LDAS

duce statecharts. The line direction agreement problem can be described by three statechartsand eight live sequence charts.

13.3 Internal Behaviour of LDAS (Statechart)

The first statechart that represent internal behavior of LDAS is shown in Fig. 13.2. The LDAScan be any one of several states during its operation. The three basic states that correspondto the direction of the trains on the line are ‘OPEN AB ’, ‘OPEN BA’, and ‘CLOSE ’. Thesebasic states have several sub-states. All possible transmissions between these states are shownas an arrow with a label in Fig. 13.2.

Figure 13.2: LDAS statechart

The initialization process starts in a default state of the system. The default state iswhen a line is closed for both direction of train travels. The state is called DEAD state. Twoanother states INIT–AB and INIT–BA can be reached from DEAD state by receiving ‘InitAB ’or ‘InitBA’.

13.4. INTERNAL BEHAVIOUR OF STATION A (STATECHART) 123

13.4 Internal Behaviour of Station A (Statechart)

The statechart that represents the internal behavior of STATION A is shown in Fig. 13.3. Itis composed of four states: LINE CLOSED, ASKED OPEN, ASKED CLOSE and LINE OPEN.

The LINE CLOSED state is the default state of the station component. In the Statechartsdefault states are indicated by an arrow with full black dot at the end.

When the station manager presses the CHANGE button, a ‘ChangeA’ command is sent toLDAS and the state is changed to ASKED OPEN. An answer ‘CloseA’ changes the state backto LINE CLOSED, an answer ‘OpenA’ changes the state to LINE OPEN.

When the STATION A component is in LINE OPEN state and LDAS sends ‘AskChangeA’command, a replay from the station manager is expected.

Figure 13.3: Station A statechart

13.5 Internal behaviour of Station B (Statechart)

The Statechart that represents the internal behavior of STATION B is shown in Fig. 13.4.

Figure 13.4: Station B statechart

13.6 External behavior (Live Sequence Chart)

In this section we show all possible communication scenarios — there are nine such — as LiveSequence Charts. See Figs. 13.5–13.9.


Figure 13.5: Initializations to AB and BA direction

Figure 13.6: Change direction approvals

13.6.1 Initialization

First pair of scenarios in Fig. 13.5 expresses the initializations of the LDAS device. LDAS sends‘AskChange’ to one of the stations when two preconditions are fulfilled. These preconditionsare: LDAS is switched off, and one of the stations has sent initialization command. A replyfrom the station manager is expected. The reply can be either ‘YES ’ or ‘NO ’.

13.6.2 Line Direction Change Approvals

The pair of scenarios in Fig. 13.6 expresses the line direction change approvals. STATION Asends ‘AgreeA’ to LDAS when two preconditions are fulfilled. These preconditions are: STA-TION A is in ‘ASKED ’ state and its station manager has pressed YES button. LDAS thensends two commands: ‘CloseA’ to STATION A and ‘OpenB ’ to STATION B.

13.6.3 Line Direction Change Disapprovals

The pair of scenarios in Fig. 13.7 expresses the line direction change disapprovals. STATION Bsends ‘DisagreeB ’ to LDAS when two preconditions are fulfilled. These preconditions are:STATION B is in ‘ASKED ’ state and its station manager has pressed NO button. LDAS thensends ‘CloseA’ to STATION A.

Figure 13.7: Change direction disapprovals


Figure 13.8: Change direction requests

Figure 13.9: Failure detection

13.6.4 Change Direction Requests

The pair of scenarios in Fig. 13.8 expresses the line direction request change. STATION Asends ‘ChangeA’ to LDAS when preconditions are fulfilled. These preconditions are: LDAS isswitched on, direction on the line is BA, there is no train on the line and station managerin STATION A has pressed CHANGE button. LDAS then receives ‘ChangeA’ command fromSTATION A and sends ‘CloseB ’ command to STATION B.

13.6.5 Failure Detection

The last scenario in Fig. 13.9 expresses the immediate line closure when any failure is detected.LDAS then sends ‘CloseA’ command to STATION A and ‘CloseB ’ command to STATION B.This is a safety requirement.

13.7 Discussion

Models for line direction agreement device have been shown in this chapter in two formalgraphical languages (Statecharts and Live Sequence Charts). Both languages can be lateron easily transformed into RAISE, see Chap. 13 in [13]. Statecharts fit better for internalbehaviour description, live sequence charts for external behaviour description of the problem.As the reader could notice, both ways of the problem description give nice models. I havealso tried to model this problem in Petri nets, but it turned out to be much too complicated.

Chapter 14

Station Interlocking

14.1 Introduction

The subjects of this chapter is interlocking: the setting up of proper routes from stationapproach (“line departures”) signals to platform tracks, and from these to the lines connectingto other stations. We shall therefore focus on constructing, for all such “interesting” routesof a station, a Petri net that models a proper interlocking control scheme.

Routes are described in terms of Units, Switches, Signals and Interlocking tables. InChap. 3, subsection 3.2.2 defines open and close routes. Routes are sequences of pairs of unitsand paths, such that the path of a unit/path pair is a possible path of some state of the unit,and such that “neighbouring” connectors are identical. There can be many such routes in astation. We are only interested in routes which start at a signal and end either at the trackor on the line. In the example station of Fig. 14.1 you can find 16 such routes.

Figure 14.1: Example station layout

14.1.1 Interlocking Tables

Depending on the local or national traditions, there are rules and regulations which stipulatehow signals and switches are to be set (and reset) in order to facilitate the safe movementof trains within a station. One can formalise such rules (see, for example [137]). From themechanisation of such formalisation and from the specific topology of the station layout, forexample that abstracted in Fig. 14.1, one can then construct an interlocking table, such asthe one given in Table 14.1. In that table ‘S’ and ‘T’ stand for straight and turn position ofswitch and ‘R’ and ‘G’ for a red and green colour of signal.

Each row in an interlocking table corresponds to a proper route. The table expresses foreach interesting route the requirements for switches (points and switchable crossovers) andthe requirements for signal states. The table also lists all units which compose the route. If

127

128 CHAPTER 14. STATION INTERLOCKING

there are no requirements on the setting, it is marked with dash (–). We do not show how toformally construct such a table, but we refer to [106, 107, 108, 137, 201].

14.2 Petri Nets

We can now start to build up Petri nets for a partial railway net from four subparts: Petrinet for a unit, for a switch (ie., point or switchable crossover), for a signal, and Petri netfor a route. Please observe that all units have a basic Petri net. Additionally switches haveadditional basic Petri nets — as we shall soon see. And, finally, although routes are basicallysequences of units, also routes have their separate basic Petri nets. The full Petri net for aroute is then a composition of all its unit, all its switch, and all its signal Petri nets — wherethe composition is specified by the interlocking table.

14.2.1 Petri Net for Units

A Unit can be in two basic states. It is either free (a new route can be opened through theunit) or not (ie., blocked, there is an already opened route through the unit).

The Petri net for Units is shown in Fig. 14.2(a). Two places represent the two states freeand blocked. The initial marking consists of a token at the Free place.

One can notice, that Petri net for a Unit in Fig. 14.2(a) will interminably circulate (“os-cillate”). But this is not the final Petri net for a route. It is just one component. Later on,extra arcs will be added. They will prevent “oscillations”.

Figure 14.2: Petri nets for (a) Units, (b) Switches, (c) Signals, and (d) Routes

14.2.2 Petri Net for Switches

A Switch can be either a point or switchable-crossover. A typical switch has two states:Straight (S) and Turn (T). A switch may be required to be set in a certain state in two ways:as a direct part of a route, or because it must be set for side protection (to avoid trainstouching each other). In both cases, if there is an open route through switches, these switchesmust never change their states.

Thus the Petri net for a switch has two places representing the two above mentionedstates, straight and turn.

The initial marking consists of n tokens at the Straight place, where n is the total numberof routes which require settings of that switch. This number can be found from the interlockingtable (here Table 14.1) as a count of required setting in the switch column. For the example

14.2. PETRI NETS 129Req

uirem

ents→

Sw

itch

esSig

nal

sU

nits

Rou

tes↓

p1

p2

p3

p4

p5

p6

Sig

1LSig

2LSig

L1

Sig

L2

Sig

L3

Sig

RSig

R1

Sig

R2

Sig

R3

1.S

ig1L−

1S

–S

–S

–G

––

––

–R

–R

u4,7

2.S

ig1L−

3S

–S

–T

–G

––

––

–R

–R

u4,5

,8

3.S

ig2L−

1T

–T

–S

–R

G–

––

–R

RR

u3,4

,7

4.S

ig2L−

2S

–S

––

––

G–

––

––

R–

u3,6

5.S

ig2L−

3T

–T

–T

–R

G–

––

–R

RR

u3,4

,5,8

6.S

igL

1−

Y–

S–

S–

S–

–G

RR

R–

––

u10,1

3,1

4

7.S

igL

2−

Y–

T–

S–

S–

–R

GR

R–

––

u9,1

0,1

3,1

4

8.S

igL

3−

Y–

––

T–

T–

–R

RG

R–

––

u11,1

3,1

4

9.S

igR−

1–

S–

S–

S–

–R

RR

G–

––

u13,1

0,7

10.

Sig

R−

2–

T–

S–

S–

–R

RR

G–

––

u13,1

0,9

,6

11.

Sig

R−

3–

––

T–

T–

–R

RR

G–

––

u13,1

1,8

12.

Sig

R1−

X1

S–

S–

S–

R–

––

––

G–

Ru

4,2

13.

Sig

R1−

X2

T–

T–

S–

RR

––

––

GR

Ru

4,3

,1

14.

Sig

R2−

X2

S–

S–

––

–R

––

––

–G

–u

3,1

15.

Sig

R3−

X1

S–

S–

T–

R–

––

––

R–

Gu

5,4

,2

16.

Sig

R3−

X2

T–

T–

T–

RR

––

––

RR

Gu

5,4

,3,1

Tab

le14

.1:

Inte

rloc

king

tabl

efo

rro

utes

thro

ugh

the

exam

ple

stat

ion.


station in Fig. 14.1, one finds that for switchable–crossover sc1, n is 8; for point p2, n is 4;etc.

The switch can change state if and only if all n tokens are available. Later on, when thewhole Petri net will be constructed, open routes through the switch cause decreases of switchtoken numbers. This will ensure that the switch can only change its state when no route —that requires the actual state — is active. But still the switch can be part of several routes,as long as these routes require the switch to be in the same state. These requirements arecaptured by the Petri net in Fig. 14.2(b).

14.2.3 Petri Net for Signals

A signal has two states: hold and proceed1. The Petri net for a signal has two placesrepresenting the two settings hold (H) and proceed (P).

The initial marking consists of m tokens at the ‘hold’ place, where m is the numberof routes which require setting of that signal. With Table 14.1, for the example station inFig. 14.1, one finds that for signal Sig1L,m is 8, for signal Sig2L,m is 6, etc.

The signal can only change setting if all m tokens are available. This will ensure that thesignal can only change its state when no route that requires the actual state is active; butstill the signal can be part of several routes, as long as these routes require the signal to bein the same state. These requirements are captured by the Petri net in Fig. 14.2(c).

14.2.4 Petri Net for Routes

In formula 25 of Sect. 3.2.2 you can find that routes can be open or close. A route can be openonly when all of its requirements on switch settings, signal settings and units occupancies arefulfilled.

The Petri net for a route also has two places representing the two states: open (O) andclosed (C). The initial marking consists of one token at the ‘Closed’ place. The basic Petri netfor a route is shown in Figure 14.2(d). This corresponds to a route that has no requirementson switches, signals or units.

14.3 Constructing the Petri Nets for Interlocking Tables

We will now indicate how to construct the Petri net, for the interlocking table of a station,from the four components already described (unit, switch, signal and route). This Petri netwill be made by adding extra pairs of arcs for each requirement between these components.The example station of Fig. 14.1 will be composed by these components: 16 Petri nets forroutes, 14 Petri nets for units, 5 Petri nets for switches and 9 Petri nets for signals. Thestation shown has these numbers.

14.3.1 Routes and Units

A route can be open when all units, that the route is composed from, are free (not occupiedby train or blocked by another route in the station). To satisfy this requirement, a pair ofarcs needs to be added between each route Petri net and all unit Petri nets that make up theroute, see Fig. 14.3.

1This is a simplistic view – a real signal is able to indicate the speed with which it may be passed.


Figure 14.3: Arc additions for route units

14.3.2 Routes and Switches

For each switch requirement it must be ensured that the switch cannot change state whilethe route through that switch is open. To satisfy this requirement, between each route Petrinet and all switch Petri nets of that route, a pair of arcs has to be added. The particularinsertions of arcs depend on the required state of the switch (as given in the Interlockingtable). This insertion is captured in the Petri net of Fig. 14.4. Note that in the figure itis assumed that the route requires the switch to be set to the ‘Turn’ state. The case for‘Straight’ follows.

Figure 14.4: Arc additions for route switches

14.3.3 Routes and Signals

The signal can be in ‘Proceed’ state only and only if the route that starts at the signal isopen. How to add a pair of arcs for a signal is illustrated in Figure 14.5. This is clearly thepre–condition for opening the route, the same as the pre–condition for adding switches.

14.4 Discussion

The full Petri net for the example railway station and interlocking table thus contains 16 Petrinets for routes, 14 Petri nets for units, 5 Petri nets for switches, and 9 Petri nets for signals.That means 88 places and 88 transitions. The interlocking table then dictates over 200 arcs


Figure 14.5: Arc additions for route signals

to be inserted — so many that “readable” diagrams become impossible. Clearly then, this isa case for tools. These tools can create the complete control program, based on Petri nets,for a station, and can check for liveness, deadlock, etc.

Where the railway net description of Chap. 3 expresses basic domain properties of sta-tic and dynamic rail nets, this chapter expresses basic requirements properties of what amonitoring and control (computing) system must do.

We have thus, in an engineering way, shown how to relate formal textual, in this case RLSdescription, to likewise formal, but now diagrammatic prescriptions. A formal, scientificallywell-founded relationship between the Petri nets prescription and the RSL description requiremore research before it can be soundly presented. This kind of research, of “integrating formaltechniques”, is currently a rich field of study. For more details about the relationship betweenPetri nets and RSL see Chap. 12 in [13].

Part V

Towards a Holistic Future

133

Chapter 15

CombiningScheduling & Allocations andMonitoring & Control Tasks

15.1 Introduction

In this chapter we would like to show how the combination of the interlocking and schedulingsystems can be done. We also provide a proposal for overall system architecture of distributedrailway system.

The scheduling of the rail net and traffic on the net will be done by four systems: The RailNet Development System, The Train Dispatch System, The Signalling System and The TrainControl System. Before describing these individual systems, we will in this section examinethe general properties of this kind of scheduling systems.

The Rail Net Development System takes care of the rail net scheduling. That is forinstance insertion or removal of lines and stations.

The Train Dispatch System handles scheduling of train traffic. This includes the arrivaland departure of trains from stations and may also include information on which lines to usewhen traveling between stations. To do this kind of scheduling, information from the RailNet Development System will be needed. For instance future changes to the rail net may beof concern when planning train traffic.

The Signalling System schedules the setting of station routes, including setting of lightsignals and switch points. The Signalling system will need information on scheduled trainarrivals and departures. This information comes from the Train Dispatch System.

The Train Control System handles the actual control of trains on the net. To do this,schedules from the earlier mentioned systems must be known.

15.2 Distributed Scheduling

15.2.1 Narrative

The connection between systems can be done by communicating scheduling plans from onesystem to another. For instance, the Rail Net Development System produces a Rail Devel-opment Plan, rndP lan, describing the scheduled history of the rail net. This plan will be

135

136 CHAPTER 15. COMBINING SCHEDULING & INTERLOCKING

passed to the Train Dispatch System. This system will need the Development Plan, for in-stance when rescheduling of train traffic is needed. The rescheduling process will constructa new plan, the Train Dispatch Plan, tdP lan. This plan describes all decisions made by theTrain Dispatch System as well as by the Rail Net Development System. This will be passed tothe Signalling System. This system constructs the Signalling Plan, sigP lan, which is passedto the Train Control System.

Rail Net DevelopmentrndPlan

Train DispatchtdPlan

SignallingsigPlan

Train Control

Figure 15.1: System Connections

For any plan, it is possible to find the schedule containing exactly those traffics that areallowed by the plan.

15.2.2 Formal Method

typerndPlan, tdPlan, sigPlan

valuerndPlan SC: rnd Plan → SC,tdPlan SC: rdPlan → SC,sigPlan SC: sigPlan → SC

Note that any traffic allowed by the Train Dispatch Plan should always be allowed by theRail Net Development Plan. That is, the Train Dispatch System must not make plans thatallow traffics which the Rail Net Development System has excluded. This means that theschedule of the Train Dispatch Plan will always be a subset of the schedule of the Rail NetDevelopment Plan. For the same reasons, the schedule of the Signalling Plan must always bea subset of the schedule of the Train Dispatch Plan.

rndSCtdSC

sigSC

Figure 15.2: Schedules of Plans of the Rail Net Development, Train Dispatch and Signalling

The communication described assumes that there is only one instance of each system.This may not be the case however. For instance, one will usually have a number of TrainDispatch Centres, each handling train scheduling in a specific area of the rail net. Each ofthe centres will have their own Train Dispatch System.

15.3. CONTROL AREAS 137

Likewise, there will usually be a Signalling System at each station of the rail net, and aTrain Control System on each train.

This distribution of scheduling gives rise to some problems, concerning communicationbetween the systems. It will be necessary to make clear which systems are in charge of whichareas, and what information is needed by the systems for the scheduling task.

15.3 Control Areas

15.3.1 Narrative

Any system that takes part in the scheduling controls a given area. For instance, a TrainDispatch Centre will control the overall traffic of trains within a specific area of the railnetwork, a Signalling System may control the routing and setting of signals within a particularstation and a Train Control System may control the setting of speed and acceleration for aspecific train.

The area of control for a given system can be described as a binary relation betweentraffics. This relation indicates for any pair of traffics if these traffics are equal within thearea controlled. That is, the projections of the traffics onto the controlled area are equal. Forinstance, for a signalling system, the setting of a signal located at another station would beoutside the control area of the system. Two traffics, which are equal, except for the state ofthis signal, would have the same projection onto the control area of this signalling system.

15.3.2 Formal Model

type/∗ Control Area ∗/CA = TF × TF → Bool

axiom∀ ca:CA, tf,tf′,tf′′:TF •

[ reflexive ] ca(tf,tf) ∧[ symmetric ] ca(tf,tf′) ⇒ ca(tf′,tf) ∧[ transitive ] (ca(tf,tf′) ∧ ca(tf′,tf′′)) ⇒ ca(tf,tf′′)

A projection onto a control area can be described by the sets of traffics having thatprojection. From a control area it is possible to find all projections of that area.

type/∗ Projection ∗/Proj = TF-set

valueCA Projs: CA → Proj-setCA Projs(ca) ≡ TF Proj(ca,tf) | tf:TF ,

TF Proj: CA × TF → ProjTF Proj(ca,tf) ≡ tf′ | tf′:TF • ca(tf,tf′)

Note that the projections of any control area are disjoint.


15.4 Scheduling Systems

15.4.1 Narrative

A scheduling system receives from a main scheduling system a plan, inP lan. For instance, aTrain Dispatch System receives a Rail Net Development Plan from a Rail Net DevelopmentSystem. The plan, inP lan, describes the decisions made on the traffics by the main system.From inP lan, the scheduling system must construct another plan, outP lan, for the subscheduling systems. For instance, a Train Dispatch System makes a Train Dispatch Plan forits Signalling Systems.

The semantics, inSC and outSC, of the received and generated plans can be found.

inPlan

inSC

outPlan

outSC

Figure 15.3: Scheduling Plans and their semantics

Not any plan can be created by a system. For instance, the train dispatch centre generatesa plan to be used by a signalling system. This plan contains information on how to run thetrain traffic. This may include information on traffic within as well as outside the station con-trolled by the signalling system. The plan generated by the signalling system should containnot only the decisions made by the signalling system, but also the overall schedule informationfrom the dispatch centre. Note that the signalling system can never make decisions of partsof traffics which are outside its control area.

SysteminPlan outPlan

Figure 15.4: A Scheduling System

Therefore, any scheduling system must choose a set of projections. The plan generatedby the system must now describe which projections were selected as well as the informationcontained in the received plan. The schedule of the generated plan will be the intersection ofthe schedule of the received plan and the set of all traffics of the selected projections.

15.4.2 Formal Model

type/∗ Scheduling System ∗/Sys

value/∗ Semantics of the received plan ∗/Sys inSC: Sys → SC,/∗ Semantics of the generated plan ∗/Sys outSC: Sys → SC,

15.5. DISTRIBUTORS 139

/∗ Control area of the system ∗/Sys CA: Sys → CA,

/∗ All schedules that adhere to the received plan of a system ∗/Sys plannedSCs: Sys → SC-setSys plannedSCs(s) ≡ CA plannedSCs(Sys CA(s),Sys inSC(s)),

/∗ All schedules that adhere to a received plan, given a controlarea ∗/

CA plannedSCs: CA × SC → SC-setCA plannedSCs(ca,mainsc) ≡

mainsc ∩ Projs TFs(ps) | ps:Proj-set •ps ⊆ CA Projs(ca) \ empty SC ,

/∗ All traffics in a set of projections ∗/Projs TFs: Proj-set → TF-setProjs TFs(ps) ≡

tf | tf:TF • ∃ p:Proj • p ∈ ps ∧ tf ∈ p ,

/∗ The empty schedule ∗/empty SC : SC =

The system should only generate plans that have allowed schedules. This could be formu-lated as a requirement for scheduling systems:

value/∗ The generated plan of a system adheres to the received plan ∗/Sys planned outSC: Sys → BoolSys planned outSC(s) ≡ Sys outSC(s) ∈ Sys plannedSCs(s)

15.5 Distributors

15.5.1 Narrative

For the distribution of information between scheduling systems, a special kind of system willbe needed. These systems will be called Distributors. Any scheduling system has got adistributor, that handles the distribution of the generated plan to a number of subsystems.

DistributorPlan

Plan1

Plan2

Plan_n

Figure 15.5: The Distributor


15.5.2 Formal Model

type/∗ Distributor ∗/Dist

value/∗ The distributor of a system ∗/Sys Dist: Sys → Dist,/∗ The semantics of plans to be sent to the subsystems ∗/Dist SysSCs: Dist → (Sys →m SC),/∗ The semantics of the received plan ∗/Dist inSC: Dist → SC

axiom∀ s:Sys • Dist inSC(Sys Dist(s)) = Sys outSC(s)

Note that the schedules of the plans distributed may not be identical. For instance asignalling system may not need much information about the other stations on the net. Thatis, each signalling system will receive only information about its own station.

It is possible to find the control area for a system and all its subsystems. For instance,a signalling system that sends information to a number of train control systems will have atotal control area that includes the trains and the setting of routes and signals within thestation.

value/∗ Find the total control area for a system and all its subsystems ∗/Sys TotalCA: Sys → CASys TotalCA(s) ≡

CA combine( Sys CA(s) ∪ Sys TotalCA(s′) | s′:Sys • s′ ∈ dom Dist SysSCs(Sys Dist(s))

),

/∗ Combine a set of control areas ∗/CA combine: CA-set → CACA combine(cas) as capost ∀ tf,tf′:TF • ca(tf,tf′) = ∀ ca′:CA • ca′ ∈ cas ⇒ ca′(tf,tf′)

The distribution of plans can be done in many different ways. Usually the subsystemswould want as much information on the scheduling of their own control area as possible, butwould not need much information on other control areas.

System Distributor System

System

System

Plan’Plan

Plan1

Plan2

Plan3

Plan1’

Plan2’

Plan3’

Figure 15.6: The scheduling hierarchy

15.5. DISTRIBUTORS 141

Not any distribution should be allowed. The distributor must always make sure that nomatter what schedules are chosen by the subsystems, their intersection is non-empty and isa subset of the schedule of the received plan.

value/∗ Allowed total schedules for a system and all its subsystems ∗/possible TotalSC: Sys × SC → SC-setpossible TotalSC(s,mainsc) ≡ CA allowed SCs(Sys TotalCA(s),mainsc),

/∗ Possible intersections of generated subsystem schedules, giventhe schedules distributed ∗/

inter SubSCs: (Sys →m SC) → SC-setinter SubSCs(sm) ≡

SCs inter(rng sm′) | sm′:Sys →m SC •dom sm = dom sm′ ∧∀ s:Sys • s ∈ dom sm ⇒ sm′(s) ∈ possible TotalSC(s,sm(s))

,

/∗ Intersection of a set of schedules ∗/SCs inter: SC-set → SCSCs inter(scs) ≡

tf | tf:TF • ∃ sc:SC • sc ∈ scs ∧ tf ∈ sc axiom

/∗ Intersections of schedules generated by subsystems are non−emptyand are subsets of the main schedule ∗/

∀ d:Dist, sc:SC •sc ∈ inter SubSCs(Dist SysSCs(d)) ⇒

(sc 6=empty SC ∧ sc ⊆ Dist inSC(d))

15.5.3 A scheduling example

An example of a simple scheduling task may help understanding how the distributed schedul-ing works.

A simple scheduling task could be selection of a specific point in two dimensions.

typePoint :: x:Real y:RealSC = Point-set

Here, a schedule is a set of points, containing exactly those points which adhere to theschedule.

The problem of selecting points may be distributed. One system may take care of choosingthe x-coordinate while another chooses the y-coordinate.

The control areas of each system must be defined.

valuesysx,sysy : Sys

cax: Point × Point → Boolcax(p,p′) ≡ x(p) = x(p′)

cay: Point × Point → Boolcay(p,p′) ≡ y(p) = y(p′)


Distributor

X system

Y system

sc

scx

scy

Figure 15.7: Scheduling example

axiomSys TotalCA(sysx) ≡ cax,Sys TotalCA(sysy) ≡ cay

The task may for instance be to select a point within an area limited by maximum andminimum values for x and y. The main schedule will be:

valuemainsc : SC = p | p:Point • min≤x(p)≤max ∧ min≤y(p)≤max

This schedule may be distributed. For instance the following distribution could be made:

valuescx : SC = p | p:Point • min≤x(p)≤max scy : SC = p | p:Point • min≤y(p)≤max

It can be proved that the distributor axioms hold. Slightly changed, this can be expressedas:

∀ sc:SC •sc ∈ sx ∩ sy | sx,sy:SC •

sx ∈ p | p:Point • x(p) = xs | xs:Real-set • ok set(xs) ∧sy ∈ p | p:Point • y(p) = ys | ys:Real-set • ok set(ys)

⇒ (sc 6= ∧ sc ⊆ mainsc)

where ok set is defined as:

valueok set: Real-set → Boolok set(rs) ≡ rs 6= ∧ ∀ r:Real • r ∈ rs ⇒ min≤r≤max

This can be simplified as:

∀ sc:SC •(∃ xs,ys:Real-set • ok set(xs) ∧ ok set(ys) ∧

sc = p | p:Point • (x(p),y(p))=(xs,ys) ) ⇒(sc 6= ∧ sc ⊆ mainsc)

Which can be seen to hold.

15.6. POSSIBLE TRAFFICS 143

15.6 Possible Traffics

15.6.1 Narrative

When a scheduling system decides on a plan, the information from the received plan is usuallynot enough. Information will also be needed on what is actually happening on the real railnet. Schedules should always be adjusted, so that it is possible for the traffic on the real railnet to be on schedule.

The scheduling systems get information from sensors on the net and communication withthe workers, engine men, station men etc. on the rail net. The exact state of the rail netwill probably not be known to any scheduling system, but it is possible to describe a set oftraffics that contain the real traffic of the rail net. This set of possible traffics is a part of thestate of a scheduling system. The set is used when selecting schedules.

15.6.2 Formal Model

valueSys posTFs: Sys → TF-set

Sys posSCs: Sys → SC-setSys posSCs(s) ≡

sc | sc:SC • ∼disruption(Sys posTFs(s),sc) axiom

/∗ It must be possible for the real traffic to be on schedule ∗/∀ s:Sys • Sys outSC(s) ∈ Sys posSCs(s)

15.7 Discussion

As described, a number of scheduling systems take part in the scheduling of traffic. Thenetwork must be split into control areas for these systems. For instance, there will usually bea number of train dispatch centres. Each centre takes care of a specific area of the network.

Problems may arise when scheduling is done for areas which are on the border betweentwo scheduling systems. For instance, there will be areas on the border between two signallingcentres. In these areas, it should be clear which signalling centre manages which areas. Thatis, the control areas of the signalling centres should not intersect.

An area may be needed between two such systems. When, for instance, a train travelsfrom the control of one signalling system to the control of another, it may be necessary to havean area between these systems, in which the train may adjust from one schedule to another.In this area, that movement of the train may only be limited by the restrictions made on thetrain from the two control areas. For instance, the train should leave one control area at acertain time, and enter the other at another point in time.

Inside the mentioned border areas, trains may for instance be under the control of a traindispatch centre, that handles both control areas. You could instead just have a simple staticplan describing how travel should occur when not inside the control area of any signallingcentre.

The same kind of problems may occur when splitting the network into control areas forthe train dispatch centres.

Chapter 16

Role of Formal Methods

16.1 Introduction

Formal methods are intended to systematize and introduce rigor into all the phases of soft-ware development. This helps us to avoid overlooking critical issues, provides a standardmeans to record various assumptions and decisions, and forms a basis for consistency amongmany related activities. By providing precise and unambiguous description mechanisms, for-mal methods facilitate the understanding required to coalesce the various phases of softwaredevelopment into a successful endeavor.

This is exactly what we need to successfully tackle such complex and highly interrelatedmatters as goes on in any railway system [162]. Therefore advantages of mathematicallyprecise specification techniques are shown in this chapter.

16.2 Proving Correctness

Formal methods are distinguished from other specification systems by their emphasis oncorrectness and proof [32, 140]. Proof is a complement, not a substitute, for testing. Testingis an important part of guaranteeing any system’s fitness, but it is finite. Testing cannotdemonstrate that a system operates properly; it can only demonstrate that the system worksfor the tested cases. Because testing cannot demonstrate that the system should work outsidethe tested cases, formal proof is necessary.

16.3 Issues of Complexity

Proving “correctness” of entire systems is not now feasible, nor is it likely to become feasiblein the foreseeable future. Establishing that a large system satisfies a nontrivial specificationrequires a large proof. Without mechanical support, building or checking such a proof isnot practical. Even with mechanical support, designing a large proof is at least as difficultas designing a large program [39, 212]. We are barely up to the task of building large andcomplex systems that almost work; we are certainly not up to building such systems twice —once in a programming language and once in a logic — without any flaws at all. On the otherhand, the use of formal methods for determining whether small but intricate protocols satisfysubtle properties is well documented. Many large systems are constructed from such smallprotocols, so formal methods certainly have a role here. Sadly, this role has been a small

145

146 CHAPTER 16. ROLE OF FORMAL METHODS

one. It requires identifying the protocols and constructing abstractions of the environment.Both activities require time, effort, and taste. Practitioners of formal methods are rarely ina position to build the abstractions; they lack the necessary detailed knowledge about thesystem. Experts on any given system are rarely in a position to apply formal methods; theylack the knowledge about the use of these methods.

16.4 Automated Verification

Because of the costs of hand verification, formal methods can play another role in analyzinglarge systems. In fact, it is one that I find quite promising. If the property to be proved can bechecked automatically, then the size of the system being analyzed is irrelevant. Type checkingis a classical example. Establishing that a program is typecorrect is a form of theorem proving.It is a weak theorem, but nevertheless, one that is useful to have proved. More recently, wesee tools to check whether interfaces in a large system are being used properly. And, incircuit design, we see model checkers to determine if a digital circuit satisfies elements of itsspecification. The properties to be checked are “small,” the system being checked might belarge, so the leverage can be great. For large systems, though, it is unlikely that we cananticipate a priori all of the properties that might be of interest.

Railway applications of formal automated verification can be found in [33, 35, 76, 78, 90,91, 112, 116, 117, 118]

16.5 Re–usage of Components

The notion that software components can be reused is a principal motivation of object-orientedprogramming, and has virtually become a postulate of programming. To reuse a previouslywritten software component (or create a new one), a software engineer must have a precisedescription of its behavior. This precision is essential as even a minor misconception of thefunction of a component that is unapparent at the outset may cause serious errors that aredifficult and expensive to correct later in the process.

In the Thesis we illustrated several basic entities in Chap. 3–6. They all are sharing thecore concepts of rail net, trains and traffic. Each sub-language description extends this coreby ‘own’ extensions. Examples of extensions are the terms, i.e. the concepts and facilities of:(1) strategic planning & planners, (2) tactical resource allocation & scheduling planners, etc.

The needs of domain-specific formal specification languages for railway control systems isshown in [68, 80, 114, 175]

16.6 Techniques for Requirements Capture

One critical problem in current software practice is poorly understood and poorly documentedrequirements. Although some promising approaches, such as scenarios and use cases, havebeen introduced in industry to help developers understand software requirements, better tech-nology is needed to help software developers construct and analyze scenarios and transformthe requirements knowledge obtained from scenarios into precise, consistent, and completerequirements specifications.

Safety requirements of railway applications and their analysis can be found in [22, 92, 108].

16.7. METHODS FOR BUILDING CODE 147

16.7 Methods for Building Code

However, improved languages and improved specifications and models are not enough. Inthe end, what is needed is correct, efficient code. As noted above, an important benefit ofa formal specification is that it provides a solid basis for automatically generating provablycorrect, efficient code.

Generation of executable railway control components from domain-specific descriptionscan be found in [115].

16.8 Techniques for Code Verification

Although improved specifications and automatic code generation from these specificationscan help improve the quality of software, in the near future, most source code will still begenerated manually. Needed therefore are improved methods for showing that a manuallygenerated program satisfies critical properties.

Examples of code verification and model checking of railway interlocking systems withSPIN can be found in [34, 53, 200, 211].

16.9 Discussion

Building software for railways involves many individuals; sometimes, many teams! The enor-mous amount of collaboration and inherent communication requirement forces the use ofstandards and conventions. Using proven notations for example, helps us to concentrate onmore complex issues. However, standards and conventions are not sufficient.

We could consider that all system development efforts deploy methods that vary fromless formal to more formal nature. Describing what a software is supposed to do can bewritten down as natural language text. Natural Language is probably the least possibleformal representation. We could add more rigor by structuring the text. Use case is agood example for structuring the user goals. Just a well structured requirements text is notadequately analyzable. Identifying ambiguities and inconsistencies manually is a dauntingtask. To help us with analysis, we may increase the rigor of formalism in the specification byusing mathematical representation such as predicate logic. We may then use model checkersto analyze them.

148 CHAPTER 16. ROLE OF FORMAL METHODS

Part VI

Closing

149

Chapter 17

Review of the Thesis

17.1 Introduction

This chapter is a reviewing chapter of the Thesis. We would like to show overall brief previewof all elementary models provided in the Thesis. The models provided in this chapter areexamples of both main aspects (Allocation & Scheduling and Monitor & Control) of railwaydomain and their combinations. This chapter should demonstrate that the models shown inthe Thesis fit well together.

17.2 Allocation & Scheduling of Resources Examples

17.2.1 From Passenger Statistics to Railway Nets and Timetables

Passenger statistics (STA) express predicted number of passengers between pairs of geograph-ical centers (C) (urban area were potential passengers live) in time intervals (TxT). From acartographical map (MAP) one can observe the geographical centers and their positions.

typeMAP, C, POSSTA′ = (C×C) →m ((T×T) →m Nat)STA = |sta:STA′ • wf sta(sta)|

valuewf sta: STA → Boolwf mapsta: MAP × STA → Boolobs Cs: MAP → C-setobs Pos: MAP × C → POS

Now one can define a function ‘genNTT ’ which from a given geographical map and pas-senger statistics, and according to a given set of predicates (P), generates all possible pairs ofnets and timetables (NTT), such that these satisfy the map and the passenger statistics.


TT′ = Tn →m JTT = |tt:TT′ • wf TT(tt)|NTT′ = N × TTNTT = |ntt:NTT′ • wf NTT(ntt)|


P: N × TT → Bool

valuep: Pwf TT: TT′ → Boolwf NTT: NTT′ → Bool

genNTT: (MAP × STA) → P → NTT-infsetgenNTT(map,sta)(p) as intts

post ∀ ntt: NTT • ntt ∈ intts ⇒satisfy(ntt,map) ∧ satisfy(ntt,sta) ∧ p(n,tt)

151

152 CHAPTER 17. REVIEW OF THE THESIS

17.2.2 From Nets & Timetables to Operational Planning

Let us now define a usually heuristic operational planning process by function ‘Planning ’,which from a given geographical map and passenger statistics according to a given set ofpredicates (P), generates one possible pair of nets and timetables (NTT).

Planning: (MAP × STA) × P∼→ NTT

Planning(map, sta)(p) ≡let ntts = genNTT(map,sta)(p) inif card ntts = 1 then nttselse

if ∃ p′: P • 1 ≤ card genNTT(map,sta)(p′) < card ntts inthen let p′: P • 1 ≤ card genNTT(map,sta)(p′) < card ntts in

Planning(map,sta)(p′) endelse let ntt: NTT • ntt ∈ ntts in ntt end

endendend

There is a separate Chap. 8 of the Thesis that shows and discusses this problem in detail.

17.2.3 From Timetables and Rolling Stock to Vehicle Scheduling

Given a net, a timetable and an available rolling stock (RS) one is interested in computingoptimum working plans (VWP) for vehicles (V) of rolling stock such that these plans honourthe timetable. A set of predicates (P) on rolling stock, nets and timetables has to be satisfied(one can operate electric powered engine only on suitable lines, etc.). We model the set ofpredicate as one “grand” predicate.

typeV, RS = V-setVWP = (V →m (Tn × J)∗) × RS

P: N × TT × RS × RS → Boolvalue

p: P

genVWP: (N×TT×RS)→P→VWP-setgenVWP(n,tt,rs)(p) as vwps

post ∀ (vwp,rs′):VWP • (vwp,rs′) ∈ vwps ⇒dom vwp ⊆ rs ∧ rs′=rs\dom vwp ∧honour(n,tt,vwp) ∧p(n,tt,rs,rs′)

17.2.4 From Timetables and Human Resources to Rostering

Given a net and a timetable one can determine the number of human resources (HR) of eachtype (drivers, conductors, etc.) needed to honour the timetable. We refer to [203]. Let usjust show how one can generate a set of working plans (HWP) for railway employees (H). A setof predicates (P) on human resources, nets and timetables has to be satisfied. We model theset of predicate as one “grand” predicate.

typeH, HR = H-setHWP = (H →m (Tn × J)∗) × HR

P: N × TT × VWP × HR × HR → Bool

value

p: PgenHWP: (N×TT×VWP×HR)→P→HWP-setgenHWP(n,tt,vwp,hr)(p) as hwps

post ∀ (hwp,hr′):HWP • (hwp,hr′) ∈ hwps ⇒dom hwp ⊆ hr ∧ hr′=hr\dom hwp ∧honour(n,tt,vwp,hwp,hr) ∧p(n,tt,vwp,hr,hr′)

17.3. MONITORING & CONTROL EXAMPLES 153

There is a separate Chap. 10 of the Thesis that shows and discusses this problem in detail.

17.2.5 From Timetables to Vehicle Maintenance

The earlier vehicle working plans did not specify that any vehicle has to undergo preventivemaintenance. We now define a set of functions, which modify vehicle working plans to reflecttimely maintenance. By a maintenance we understand all regular activities which must bedone with rolling stock and according to some rules (R). Each vehicle, according to its type,has associated with it certain types of maintenance tasks to be performed with a frequencywhich can be expressed by elapsed number of kilometer or operating hours since a previousmaintenance.

Given a railway net (N), vehicle working plans (VWP), a timetable (TT) and a planningperiod (TxT) the job is to generate all the possible sets of changes (CS), necessary and sufficientto secure maintenance. Given these sets, one is selected and used for update of existing vehicleworking plans.

typeCS = (DayChange | NightChange | EmptyRide)-set

value

genCS: N×TT×VWP×(T×T)∼→CS-set

MPlanning: N×TT×VWP×(T×T)→(VWP×CS)MPlanning(n,tt,vwp,(tb,te)) ≡

let css = genCS(n,tt,vwp,(tb,te)) inSelect(vwp,css) end

Select: VWP×CS-set → (VWP×CS)Select(vwp,css) as (vwp′,cs)

post cs ∈ css ∧ equivalent(vwp,vwp′)

More details about this task can be found in [188] or in Chap. 9 of the Thesis.

17.3 Monitoring & Control Examples

Lines (L) and stations (S) are composed from “smallest” rail parts called units (U) (linear,points, cross-overs, switchable cross-overs). A unit define a number of connectors (linear:2,point:3, cross-overs:4). A subset of pairs of distinct connectors of a unit define paths thoughthe unit. By a unit state (Σ) we understand any such subset. A unit may change state. Thestate space of a unit is called Ψ. A unit is said to be closed, if it is in path state (σ) of nopaths.

A route (R) is a sequence of units. A route is open, if all units are in non-closed statesand if the units state paths connect see Sect. 3.2.2 and [17].

By traffic (TF) we mean a function from time to net and train states (TΠ). A train statecontains information about train position on the net, its actual and planned velocity andacceleration, etc. Our primed definition of traffic (TF’) defines values that do not respectlaws-of-nature (there are no “ghost trains”, trains do not“jump” all over the net, etc.). Alsodesired railways properties (RR) are not respected in TF’ (train movements only on openroutes, only one train on a open route, obeying interlocking rules and regulations, etc.). See[21].

typeN, TΠ, Tn, POS, RRU, C, P=C×CΣ = P-setΨ = Σ-set

TF′ = T → (N × TP)TF = |tf:TR′ • wf TF(tf)|TP = Tn →m TΠ


valueobs Cs: U → C-setobs Σ: U → Σobs Ψ: U → Ψ

wf TF: TF′ → Boolwf TF(tf) ≡ obeyLaws(tf)

obs POS: TΠ → POSregs: TF × N × RR → Bool

17.3.1 From Timetable to Traffic

The syntactic quantity of a timetable (TT) denotes the semantic quantity of a set of possibletraffics (TF) which satisfy the timetable. See [22, 25, 27, 16].

typeTR, TT, N

value

denote: TT × N → TF-infsetdenote(tt,n) as itfs

∀ tf:FT • tf ∈ itfs ⇒regulations(tf,n) ∧ obeysTT(tf,tt,n)

17.3.2 From Traffic to Station Interlocking

The above model of dynamics of units did not show how units change states. This is whatwe will now consider. We will use Petri Nets to model conditions for state changes of a unit.

Interlocking has to do with setting up proper routes from station approached signal toa track (platform) in the station and from these to the lines. We shall focus on one way ofconstructing models for proper interlocking control scheme using Place Transmission PetriNets. Petri Net for stations can be built up from four subparts: Petri Net for units, forswitches (ie., point or switchable crossover), for signals, and finally Petri Net for routes,see Fig. 14.2. The Petri Net of a route is then a composition of all its unit, switch andsignal Petri Nets — where the composition is specified by an interlocking table. The tableexpresses for each interesting route the state requirements for switches (points and switchablecrossovers) and the requirements for signal states.

So, on the one hand we have our RSL model for nets and trains states; on the other handwe have shown Petri Nets that control state spaces. In other words we have brought twodifferent specification techniques. Hence from RLS specification of a station one can build ainterlocking table and then the Petri Net. More about integration of Petri Net and RSL seein [21].

A detailed description on the topic of station interlocking was given in Chap. 14.

17.3.3 From Traffic to Line Direction Agreement

The above RSL model of traffic did not show how certain rules could be obeyed. In thissection we with to show one of the important safety properties of a railway line: that twotrains are not allowed to move in opposite directions on a line. One way of ensuring this isby a so called Line Direction Agreement System (LDAS).

The externally visible behavior of the LDAS can be illustrated using Live Sequence Charts.The three entities are: Station A (SA), the Line Direction Agreement System (LDAS), andStation B (SB). The charts in Figure 17.1 illustrate only the partial communication as seenfrom Station A. The mutual exclusive control of the LDAS can illustrated by a Statechart.For more details we refer to [21] and to a separate Chap. 13 of the Thesis.


(a) (b)

(c) (d)

Figure 17.1: (a) Initial LDAS, (b) Request Direction Reversal, (c) Request Approval, (d) Request Rejection

17.3.4 From Traffic to Automatic Line Signalling

Again the above RSL model of traffic did not show how trains on a line can be separated.Lines connect exactly two stations and can be divided into several segments (see Fig. 12.1).Each segment can be either in ‘Free’ state (when no train is detected in the segment) or in‘Occupied ’ state. For each segment there are two signals (one in each direction of travel).With each signal we associate four possible states (‘Hold ’, ‘NextHold ’, ‘Proceed ’ and ‘Off ’).

typeTR, N, L, S, SEG, SIGSegSt == Free | OccupiedSigSt == Hold | NextHold | Proceed | Off

value

obs Ss: L → S-setobs Segs: L → SEG∗

obs Sigs: SEG → SIG × SIGobs SegState: TR × SEG → SegStobs SigState: TR × SIG → SigSt

Statecharts can be used to specify requirements for pair of signals along a line including pairsincluding station interlocking. For more information on this topic we refer to Chap. 12 of theThesis.

17.4 Discussion

There are a number of railway applications which can be solved by computers these days.Unfortunately these applications are mainly being solved separately without any relations orintegrations between them. In this Thesis we have tried to focus not only on integration ofrailway application, but we have focused on some common parts of these application alreadyin early software development stage – mainly in domain engineering.

As the reader could notice all shown models in this chapter use the same notions of basicentities of railways. These entities were defined in the second part of the Thesis and theirusage in the third and fourth part.

We would like to emphasize that in the Thesis we formally characterized major part ofrailway domain — such as they are “out there”, in reality, not necessarily as we wish it tobe. On the basis of such formal domain specifications we can then later express softwarerequirements, ie., such as what we wish real applications for railway to be.


The actual software design of these applications relies on an identification of suitable op-eration research techniques (ie., algorithms), that can provide reasonably optimum solutionsand at reasonable computing times.

It was not the aim of this Thesis to show such operation research algorithms neither showsoftware requirements or software design. Instead we refer to [39, 40, 54, 123, 142, 146, 148,196, 207, 210].

Classically software has been provided piecemeal to enterprises within each of these sectors— with little (other than conventional operating and database system) support for thesediverse software packages to invoke each other and share data. In the Thesis we provideframeworks of railway application specific software that tie existing and (especially) futurerailway application packages together.

The shown modern techniques now allow developers to model very large scale infrastruc-tures of railway domain and thus to develop various railway applications.

Chapter 18

Future Work

18.1 Introduction

It appears highly plausible that one can develop major parts of a set of formal description of arailway domain. It was shown, that to successfully tackle such complex and highly interrelatedmatters as goes on in any railway system, whether itself small or large, one can do well inusing the mathematically precise specification techniques that allow a uniform treatment ofall these diverse issues on the basis of stable, underlying models.

Building up a public repository of such underlying railway models, in the same way as itwas presented in the Thesis, is the main goal for the future. Many more aspects of railwayinfrastructure not even mentioned in the Thesis can be formally described to fully cover thedomain of railway infracture. This is a work for several years for many people with differentbackgrounds. Therefore some kind of organisation of this work is needed.

18.2 TRain Consortium

The TRain Effort is a proposal put forward for the formation of worldwide, open, free con-sortium of railway people and institutions (companies, industries), academics (ie., people,researchers, scientists), and of research centres, within computer and computing science, andsoftware engineering, transportation science and engineering, reliability and safety engineer-ing, and operations research on the subject of exploring, creating, and researching A DomainTheory for the Railway Infrastructure.

The key point is the research into the domain, not requirements, not algorithms, notsoftware, of “all things” railways and building up a public repository of railway system models.

Of course it is unavoidable that research into domains, results also from research into anddevelopment of requirements and the design of algorithms and software. Hence the TRainEffort will, obviously, see research results, ie., reports, papers, etc., that contain material ondomains and requirements, or domains, requirements and algorithms, or domains, require-ments and software design.

The idea is to call for a “human genome”-like, worldwide R&D, open and free effort amonguniversity and railway industry R&D centres to achieve the above.

157

158 CHAPTER 18. FUTURE WORK

18.3 www.RailwayDomain.org

We have elsewhere, at www.RailwayDomain.org, outlined Grand Challenge [18] for computingscience, namely for developing, over the next N years, where N may be 20 or so, a compre-hensive and reasonably complete set of commensurate, ie., integrated formal models of “Allthings Railways !”.

This Thesis shall serve to make this claim plausible, shall serve to indicate what mightwe meant by such a set of comprehensive and reasonably complete set of commensurate, ie.,integrated formal models.

At the moment, the site contains shared repository of published papers connected withrailway software engineering and it is an interesting source of bibliographies. The first versionof TRain book can be also found at the site.

18.4 The TRain Book

There is a compendium called TRain book that contains an assortment of draft chaptersaround the abstract modeling of various aspect of the railway domain. The document wasissued for the first time on the occasion of the topic session TRain held as a part of IFIPWorld Computer Congress in Toulouse, France in August 2004. Subsequent editions of thisdocument are expeted.

It is hope that the mere, somewhat inofficial appearance of the compendium together withits Internet posting at www.RailwayDomain.org’s Repository entry — will help us all betterfind out what it really is we want !

18.5 Formal Methods as a Part of Education

Appropriate branch of applied mathematics is a necessary part of the education of all engi-neers. Therefore appropriate branch of Formal methods should be part of the education ofevery transportation engineer. There are several reasons for that. Formal methods

• provide the intellectual underpinnings of transportation field,• can shape our thinking and help direct our approach to problems along productive

paths,• provide notations for documenting requirements and designs, and for communicating

our thoughts to others in a precise and perspicuous manner,• provide us with analytical tools for calculating the properties and consequences of the

requirements and designs that we document.

Some of the formal method are already taught at Faculty of Transportation Sciences ofCzech Technical University in Prague (like Petri nets). But I do miss a context of mathemat-ically precise specification technique and explanation of benefits of such formal attitude.

18.6 Other Transportation Domains

This Thesis tackles railway domain only. But there are other Transportation & Logisticsdomains (like public city transport, airport, telecommunication, etc.) that would be very

18.6. OTHER TRANSPORTATION DOMAINS 159

interesting to formally describe. It will be possible to formally describe these domains in atleast the same depth as it is done for the railway domain in this Thesis.

160 CHAPTER 18. FUTURE WORK

Chapter 19

Acknowledgements

This thesis is the result of four and half years of work wherein I was accompanied andsupported by many people. It is a pleasant aspect that I have now the opportunity to expressmy gratitude to the most important ones.

The first person I would like to thank is my Danish supervisor Dines Bjørner. His kindinvitation in 2003 to Danish Technical University and work at AMORE project basicallystarted my interest in Computer Science, especially in Formal methods. In the end, thanksto him, I have returned to Denmark three times and most of the work on the Thesis wasdone and published during these stays. I have known Dines Bjørner as a sympathetic andmethodical-centered person. His overly enthusiasm and integral view on research and hisleadership capability has made a deep impression on me. I am and I always will be verygrateful for him having shown me this way and this kind of research.

My great thanks also go to my Czech supervisor Miroslav Svıtek. His major role was inthe first part of my PhD studies when he introduced me the notion of telematics and telematicapplication for railways. He has basically guided me though the first research reports andpapers on information system structures for railways.

I am also very grateful to Miroslav Vlcek for his understanding of Formal Methods as avery nice application of mathematics and thus for his generous support in my research. Iam very glad I could be a member of his department of Applied Mathematics of Faculty ofTransportation Sciences at Czech Technical University in Prague.

The work done in chapters 9 and 10 was done together with Albena Strupchanska duringour first stay at DTU. Live sequence charts in Chap. 13 were drawn together with ChristianKrog Madsen. Many thanks therefore go to Albena and Christian.

I would like to acknowledge the generous English correction of the Thesis provided byHynek Zlatnık.

Last but not least I am very grateful to my wife Hanka, for her love and patience duringmy PhD period. One of the best experiences that we lived through in this period was thebirth of our son Ondrej, who provided an additional and joyful dimension to our life mission.

161

162 CHAPTER 19. ACKNOWLEDGEMENTS

Part VII

Appendixes

163

Appendix A

Formal Methods in ComputingSystems Development

A.1 What is ‘Formal Method’ ?

A.1.1 What is a Method ?

By a method is meant a set of principles that are used in selecting and applying a numberof techniques and tools in order to identify and analyse a problem and synthesize (construct)a solution to the problem. Normally one would expect a good method to be “efficient” andresult in “efficient” solutions.

A.1.2 What is Meant by Formal ?

In the context of software (hardware) development, the term ‘Formal’ is usually consideredto imply the following:

• There is a language, a so-called formal language, for expressing problem characterisa-tions and/or problem solutions, at various levels of abstraction.

• We usually refer – interchangeably – to such a language as a specification, a design, ora programming language.

• That language must have the following three properties in order to qualify as a formalspecification (design or programming) language:

– It must have a precise, ie., a mathematically well defined syntax – something whichdefines all such sentences and/or diagrams (or other) which are members of thelanguage.

– It must have a precise, ie., a mathematically well defined semantics – somethingwhich to every syntactically well-formed sentence and/or diagrams (or other) whichare members of the language ascribes a precise meaning in terms of some mathe-matical structure.

– It must have a proof system: That is, a set of axioms and proof (ie., inferenceand/or deduction) rules by means of which one can reason over all syntacticallywell-formed sentence and/or diagrams (or other) of the language.

165

166APPENDIX A. FORMAL METHODS IN COMPUTING SYSTEMS DEVELOPMENT

– It is expected that the Language Semantics have been shown to be a Model of theProof System.

A.1.3 What, Then, is a Formal Method ?

A ‘Formal Method’, then, is a ‘Method’ some of whose main ‘Techniques’ and main ‘Tools’depend crucially upon the use of Formal Languages. In other words, ‘Formal Methods’ refersto mathematically rigorous techniques and tools for the specification, design and verificationof software and hardware systems. The phrase “mathematically rigorous” means that thespecifications used in formal methods are well-formed statements in a mathematical logic andthat the formal verifications are rigorous deductions in that logic (i.e. each step follows froma rule of inference and hence can be checked by a mechanical process.) The value of formalmethods is that they provide a means to symbolically examine the entire state space of adigital design (whether hardware or software) and establish a correctness or safety propertythat is true for all possible inputs. However, this is rarely done in practice today (exceptfor the critical components of safety critical systems) because of the enormous complexity ofreal systems. Several approaches are used to overcome the astronomically-sized state spacesassociated with real systems:

• Apply formal methods to requirements and high-level designs where most of the detailsare abstracted away

• Apply formal methods to only the most critical components• Analyze models of software and hardware where variables are discretized and ranges

drastically reduced.• Analyze system models in a hierarchical manner that enables “divide and conquer”• Automate as much of the verification as possible

Although the use of mathematical logic is a unifying theme across the discipline of formalmethods, there is no single best “formal method”. Each application domain requires differentmodeling methods and different proof approaches. Furthermore, even within a particularapplication domain, different phases of the life-cycle may be best served by different toolsand techniques. For example a theorem prover might be best used to analyze the correctnessof a RTL level description of a Fast Fourier Transform circuit, whereas algebraic derivationalmethods might best be used to analyze the correctness of the design refinements into agate-level design. Therefore there are a large number of formal methods under developmentthroughout the world. There is a growing set of success stories in applying formal methodsto real applications.

Appendix B

An RSL Primer

This is an ultra–short introduction to The RAISE Specification Language.

B.1 Types

The reader is kindly asked to study first the decomposition of this section into its subpartsand sub-subparts.

B.1.1 Type Expressions

RSL has a number of built–in types.There are the Booleans, integers, natural numbers, reals, characters, and texts.From these one can form type expressions: Finite sets, infinite sets, Cartesian products,

lists, maps, etc.Let A, B and C be any type names or type expressions, then:

type[ 1 ] Bool[ 2 ] Int[ 3 ] Nat[ 4 ] Real[ 5 ] Char[ 6 ] Text

[ 7 ] A-set[ 8 ] A-infset[ 9 ] A × B × ... × C[ 10 ] A∗

[ 11 ] Aω

[ 12 ] A →m B[ 13 ] A → B[ 14 ] A ∼→ B[ 15 ] (A)[ 16 ] A | B | ... | C

167

168 APPENDIX B. AN RSL PRIMER

[ 17 ] mk id(sel a:A,...,sel b:B)[ 18 ] sel a:A ... sel b:B

(save the [i] line numbers) are generic type expressions:

1. The Boolean type of truth values false and true.

2. The integer type on integers ..., -2, -1, 0, 1, 2, ...

3. The natural number type of positive integer values 0, 1, 2, ...

4. The real number type of real values, i.e., values whose numerals can be written as aninteger, followed by a period (“.”), followed by a natural number (the fraction).

5. The character type of character values ”a”, ”b”, ...

6. The text type of character string values ”aa”, ”aaa”, ..., ”abc”, ...

7. The set type of finite set values, see below.

8. The set type of infinite set values.

9. The Cartesian type of Cartesian values, see below.

10. The list type of finite list values, see below.

11. The list type of infinite list values.

12. The map type of finite map values, see below.

13. The function type of total function values, see below.

14. The function type of partial function values.

15. In (A) A is constrained to be:

• either a Cartesian B × C × ... × D, in which case it is identical to type expressionkind 9,

• or not to be the name of a built–in type (cf., 1–6) or of a type, in which case theparentheses serve as simple delimiters, eg: (A →m B), or (A∗)-set, or (A-set)list,or (A|B) →m (C|D|(E→m F)), etc.

16. The (postulated disjoint) union of types A, B, . . . , and C.

17. The record type of mk id–named record values mk id(av,...,bv), where av, . . . , and bv,are values of respective types. The distinct identifiers sel a, etc., designate selectorfunctions.

18. The record type of unnamed record values (av,...,bv), where av, . . . , and bv, are valuesof respective types. The distinct identifiers sel a, etc., designate selector functions.

B.1. TYPES 169

B.1.2 Type Definitions

Concrete Types:

Types can be concrete in which case the structure of the type is specified by type expressions:

typeA = Type expr

Some schematic type definitions are:

[ 1 ] Type name = Type expr /∗ without | s or sub−types ∗/[ 2 ] Type name = Type expr 1 | Type expr 2 | ... | Type expr n[ 3 ] Type name ==

mk id 1(s a1:Type name a1,...,s ai:Type name ai) |... |mk id n(s z1:Type name z1,...,s zk:Type name zk)

[ 4 ] Type name :: sel a:Type name a ... sel z:Type name z[ 5 ] Type name = | v:Type name′ • P(v) |

where a form of [2–3] is provided by combining the types:

Type name = A | B | ... | ZA == mk id 1(s a1:A 1,...,s ai:A i)B == mk id 2(s b1:B 1,...,s bj:B j)...Z == mk id n(s z1:Z 1,...,s zk:Z k)

Subtypes

In RSL, each type represents a set of values. Such a set can be delimited by means of predicates.The set of values b which has type B and which satisfy the predicate P, constitute the sub–type A:

typeA = | b:B • P(b) |

Sorts (Abstract Types)

Types can be sorts (abstract) in which case their structure is not specified:

typeA, B, ..., C


B.2 The RSL Predicate Calculus

B.2.1 Propositional Expressions

Let identifiers (or propositional expressions) a, b, ..., c designate Boolean values. Then:

false, truea, b, ..., c∼a, a∧b, a∨b, a⇒b, a=b, a6=b

are propositional expressions having Boolean values. ∼, ∧, ∨, ⇒, and = are Boolean connec-tives (i.e., operators). They are read: not, and, or, if-then (or implies), equal and not-equal.

B.2.2 Simple Predicate Expressions

Let identifiers (or propositional expressions) a, b, ..., c designate Boolean values, let x, y, ...,z (or term expressions) designate non–Boolean values, and let i, j, . . ., k designate numbervalues, then:

false, truea, b, ..., c∼a, a∧b, a∨b, a⇒b, a=b, a6=bx=y, x6=y,i<j, i≤j, i≥j, i>j, ...

are simple predicate expressions.

B.2.3 Quantified Expressions

Let X, Y, . . ., C be type names or type expressions, and let P(x), Q(y) and R(z) designatepredicate expressions in which z, y, and z are free. Then:

∀ x:X • P(x)∃ y:Y • Q(y)∃ ! z:Z • R(z)

are quantified expressions — also being predicate expressions. They are “read” as: For all x(values in type X) the predicate P(x) holds; there exists (at least) one y (value in type Y )such that the predicate Q(y) holds; and: there exists a unique z (value in type Z) such thatthe predicate R(z) holds.

B.3 Concrete RSL Types

B.3.1 Set Enumerations

Let the below as denote values of type A, then the below designate simple set enumerations:

, a, a1,a2,...,am, ... ∈ A-set, a, a1,a2,...,am, ..., a1,a2,... ∈ A-infset

B.3. CONCRETE RSL TYPES 171

The expression, last line below, to the right of the ≡, expresses set comprehension. Theexpression “builds” the set of values satisfying the given predicate. It is highly abstract inthe sense that it does not do so by following a concrete algorithm.

typeA, BP = A → BoolQ = A ∼→ B

valuecomprehend: A-infset × P × Q → B-infsetcomprehend(s,P,Q) ≡ Q(a) | a:A • a ∈ s ∧ P(a)

B.3.2 Cartesian Enumerations

Let e range over values of Cartesian types involving A, B, . . ., C (allowing indexing for solvingambiguity), then the below expressions are simple Cartesian enumerations:

typeA, B, ..., CA × B × ... × C

value... (e1,e2,...,en) ...

B.3.3 List Enumerations

Let a range over values of type A (allowing indexing for solving ambiguity), then the belowexpressions are simple list enumerations:

〈〉, 〈a〉, ..., 〈a1,a2,...,am〉, ... ∈ A∗

〈〉, 〈a〉, ..., 〈a1,a2,...,am〉, ..., 〈a1,a2,...,am,... 〉, ... ∈ Aω

〈 ei .. ej 〉

The last line above assumes ei and ej to be integer valued expressions. It then expresses theset of integers from the value of ei to and including the value of ej . If the latter is smallerthan the former then the list is empty.

The last line below expresses list comprehension.

typeA, B, P = A → Bool, Q = A ∼→ B

valuecomprehend: Aω × P × Q ∼→ Bω

comprehend(lst,P,Q) ≡〈 Q(lst(i)) | i in 〈1..len lst〉 • P(lst(i)) 〉


B.3.4 Map Enumerations

Let a and b range over values of type A and B, respectively (allowing indexing for solvingambiguity); then the below expressions are simple map enumerations:

typeA, BM = A →m B

valuea,a1,a2,...,a3:A, b,b1,b2,...,b3:B

[ ], [ a 7→b ], ..., [ a17→b1,a27→b2,...,a37→b3 ] ∀ ∈ M

The last line below expresses map comprehension:

typeA, B, C, DM = A →m BF = A ∼→ CG = B ∼→ DP = A → Bool

valuecomprehend: M×F×G×P → (C →m D)comprehend(m,F ,G,P) ≡

[ F(a) 7→ G(m(a)) | a:A • a ∈ dom m ∧ P(a) ]

B.3.5 Set Operations

value∈: A × A-infset → Bool6∈: A × A-infset → Bool∪: A-infset × A-infset → A-infset∪: (A-infset)-infset → A-infset∩: A-infset × A-infset → A-infset∩: (A-infset)-infset → A-infset\: A-infset × A-infset → A-infset⊂: A-infset × A-infset → Bool⊆: A-infset × A-infset → Bool=: A-infset × A-infset → Bool6=: A-infset × A-infset → Boolcard: A-infset ∼→ Nat

examplesa ∈ a,b,ca 6∈ , a 6∈ b,ca,b,c ∪ a,b,d,e = a,b,c,d,e


∪a,a,b,a,d = a,b,da,b,c ∩ c,d,e = c∩a,a,b,a,d = aa,b,c \ c,d = a,ba,b ⊂ a,b,ca,b,c ⊆ a,b,ca,b,c = a,b,ca,b,c 6= a,bcard = 0, card a,b,c = 3

• ∈ The membership operator expresses that an element is member of a set.

• 6∈: The non-membership operator expresses that an element is not member of a set.

• ∪ The infix union operator. When applied to two sets, the operator gives the set whosemembers are in either or both of the two operand sets

• ∩ The infix intersection operator. When applied to two sets, the operator gives the setwhose members are in both of the two operand sets.

• \ The set complement (or set subtraction) operator. When applied to two sets, theoperator gives the set whose members are those of the left operand set which are not inthe right operand set.

• ⊆ The proper subset operator expresses that all members of the left operand set arealso in the right operand set.

• ⊂ The proper subset operator expresses that all members of the left operand set arealso in the right operand set, and that the two sets are not identical.

• = The equal operator expresses that the two operand sets are identical.

• 6= The non–equal operator expresses that the two operand sets are not identical.

• card The cardinality operator gives the number of elements in a (finite) set.

The operations can be defined as follows:

values′ ∪ s′′ ≡ a | a:A • a ∈ s′ ∨ a ∈ s′′ s′ ∩ s′′ ≡ a | a:A • a ∈ s′ ∧ a ∈ s′′ s′ \ s′′ ≡ a | a:A • a ∈ s′ ∧ a 6∈ s′′ s′ ⊆ s′′ ≡ ∀ a:A • a ∈ s′ ⇒ a ∈ s′′

s′ ⊂ s′′ ≡ s′ ⊆ s′′ ∧ ∃ a:A • a ∈ s′′ ∧ a 6∈ s′

s′ = s′′ ≡ ∀ a:A • a ∈ s′ ≡ a ∈ s′′ ≡ s⊆s′ ∧ s′⊆ss′ 6= s′′ ≡ s′ ∩ s′′ 6= card s ≡

if s = then 0 elselet a:A • a ∈ s in 1 + card (s \ a) end endpre s /∗ is a finite set ∗/

card s ≡ chaos /∗ tests for infinity of s ∗/


B.3.6 Cartesian Operations

typeA, B, Cg0: G0 = A × B × Cg1: G1 = ( A × B × C )g2: G2 = ( A × B ) × Cg3: G3 = A × ( B × C )

valueva:A, vb:B, vc:C, vd:D(va,vb,vc):G0,(va,vb,vc):G1((va,vb),vc):G2(va3,(vb3,vc3)):G3

decomposition expressionslet (a1,b1,c1) = g0,

(a1′,b1′,c1′) = g1 in .. endlet ((a2,b2),c2) = g2 in .. endlet (a3,(b3,c3)) = g3 in .. end

B.3.7 List Operations

valuehd: Aω ∼→ Atl: Aω ∼→ Aω

len: Aω ∼→ Natinds: Aω → Nat-infsetelems: Aω → A-infset.(.): Aω × Nat ∼→ A: A∗ × Aω → Aω

=: Aω × Aω → Bool6=: Aω × Aω → Bool

exampleshd〈a1,a2,...,am〉=a1tl〈a1,a2,...,am〉=〈a2,...,am〉len〈a1,a2,...,am〉=minds〈a1,a2,...,am〉=1,2,...,melems〈a1,a2,...,am〉=a1,a2,...,am〈a1,a2,...,am〉(i)=ai〈a,b,c〉〈a,b,d〉 = 〈a,b,c,a,b,d〉〈a,b,c〉=〈a,b,c〉〈a,b,c〉 6= 〈a,b,d〉


• hd Head gives the first element in a non–empty list.

• tl Tail gives the remaining list of a non–empty list when Head is removed.

• len Length gives the number of elements in a finite list.

• inds Indices gives the set of indices from 1 to the length of a non–empty list. For emptylists, this set is the empty set as well.

• elems Elements gives the possibly infinite set of all distinct elements in a list.

• `(i) Indexing with a natural number, i larger than 0, into a list ` having a number ofelements larger than or equal to i, gives the i’th element of the list.

• Concatenates two operand lists into one. The elements of the left operand list arefollowed by the elements of the right. The order with respect to each list is maintained.

• = The equal operator expresses that the two operand lists are identical.

• 6= The non–equal operator expresses that the two operand lists are not identical.

The operations can also be defined as follows:

valueis finite list: Aω → Bool

len q ≡case is finite list(q) of

true → if q = 〈〉 then 0 else 1 + len tl q end,false → chaos end

inds q ≡case is finite list(q) of

true → i | i:Nat • 1 ≤ i ≤ len q ,false → i | i:Nat • i6=0 end

elems q ≡ q(i) | i:Nat • i ∈ inds q

q(i) ≡if i=1

thenif q 6=〈〉

then let a:A,q′:Q • q=〈a〉q′ in a endelse chaos end

else q(i−1) end

fq iq ≡〈 if 1 ≤ i ≤ len fq then fq(i) else iq(i − len fq) end| i:Nat • if len iq6=chaos then i ≤ len fq+len end 〉

pre is finite list(fq)


iq′ = iq′′ ≡inds iq′ = inds iq′′ ∧ ∀ i:Nat • i ∈ inds iq′ ⇒ iq′(i) = iq′′(i)

iq′ 6= iq′′ ≡ ∼(iq′ = iq′′)

B.3.8 Map Operations

valuem(a): M → A ∼→ B, m(a) = b

dom: M → A-infset [ domain of map ]dom [ a17→b1,a27→b2,...,an 7→bn ] = a1,a2,...,an

rng: M → B-infset [ range of map ]rng [ a17→b1,a27→b2,...,an7→bn ] = b1,b2,...,bn

†: M × M → M [ override extension ][ a 7→b,a′ 7→b′,a′′ 7→b′′ ] † [ a′7→b′′,a′′7→b′ ] = [ a7→b,a′7→b′′,a′′ 7→b′ ]

∪: M × M → M [ merge ∪ ][ a 7→b,a′ 7→b′,a′′ 7→b′′ ] ∪ [ a′′′7→b′′′ ] = [ a7→b,a′ 7→b′,a′′ 7→b′′,a′′′7→b′′′ ]

\: M × A-infset → M [ restriction by ][ a 7→b,a′ 7→b′,a′′ 7→b′′ ]\a = [ a′7→b′,a′′7→b′′ ]

/: M × A-infset → M [ restriction to ][ a 7→b,a′ 7→b′,a′′ 7→b′′ ]/a′,a′′ = [ a′7→b′,a′′7→b′′ ]

=, 6=: M × M → Bool

: (A →m B) × (B →m C) → (A →m C) [ composition ][ a 7→b,a′ 7→b′ ] [ b 7→c,b′7→c′,b′′7→c′′ ] = [ a7→c,a′7→c′ ]

• m(a) Application gives the element of which a maps to in the map m

• dom Domain/Definition Set gives the set of values which maps to in a map.

• rng: Range/Image Set gives the set of values which are mapped to in a map.

• † Override/Extend. When applied to two operand maps, it gives the map which is likean override of the left operand map by all or some “pairings” of the right operand map,

• ∪ Merge. When applied to two operand maps, it gives it gives a merge of these maps.

B.4. LAMBDA–CALCULUS + FUNCTIONS 177

• \: Restriction. When applied to two operand maps, it gives the map which is a re-striction of the left operand map to the elements that are not in the right operandset

• / Restriction. When applied to two operand maps, it gives the map which is a restrictionof the left operand map to the elements of the right operand set.

• = The equal operator expresses that the two operand maps are identical.

• 6= The non–equal operator expresses that the two operand maps are not identical.

• Composition. When applied to two operand maps, it gives the map from definitionset elements of the left operand map, m1, to the range elements of the right operandmap, m2, such that if a, in the definition set of m1 and maps into b, and if b is in thedefinition set of m2 and maps into c, then a, in the composition, maps into c.

The map operations can also be defined as follows:

valuerng m ≡ m(a) | a:A • a ∈ dom m

m1 † m2 ≡[ a 7→b | a:A,b:B •

a ∈ dom m1 \ dom m2 ∧ b=m1(a) ∨ a ∈ dom m2 ∧ b=m2(a) ]

m1 ∪ m2 ≡ [ a 7→b | a:A,b:B •

a ∈ dom m1 ∧ b=m1(a) ∨ a ∈ dom m2 ∧ b=m2(a) ]

m \ s ≡ [ a 7→m(a) | a:A • a ∈ dom m \ s ]m / s ≡ [ a 7→m(a) | a:A • a ∈ dom m ∩ s ]

m1 = m2 ≡dom m1 = dom m2 ∧ ∀ a:A • a ∈ dom m1 ⇒ m1(a) = m2(a)

m1 6= m2 ≡ ∼(m1 = m2)

mn ≡[ a 7→c | a:A,c:C • a ∈ dom m ∧ c = n(m(a)) ]pre rng m ⊆ dom n

B.4 Lambda–Calculus + Functions

RSL supports function expressions for λ–abstraction.


B.4.1 The Lambda–Calculus Syntax

type /∗ A BNF Syntax: ∗/〈L〉 ::= 〈V〉 | 〈F〉 | 〈A〉 | ( 〈A〉 )〈V〉 ::= /∗ variables, i.e. identifiers ∗/〈F〉 ::= λ〈V〉 • 〈L〉〈A〉 ::= ( 〈L〉〈L〉 )

value /∗ Examples ∗/〈L〉: e, f, a, ...〈V〉: x, ...〈F〉: λ x • e, ...〈A〉: f a, (f a), f(a), (f)(a), ...

B.4.2 Free and Bound Variables

Let x, y be variable names and e, f be λ-expressions.

• 〈V〉: Variable x is free in x

• 〈F〉: x is free in λy •e if x 6= y and x is free in e.

• 〈A〉: x is free in f(e) if it is free in either f or e (i.e., also in both).

B.4.3 Substitution

In RSL, the following rules for substitution apply:

• subst([N/x]x) ≡ N;

• subst([N/x]a) ≡ a,

for all variables a 6= x;

• subst([N/x](P Q)) ≡ (subst([N/x]P) subst([N/x]Q));

• subst([N/x](λx•P )) ≡ λ y•P;

• subst([N/x](λ y•P)) ≡ λy• subst([N/x]P),

if x6=y and y is not free in N or x is not free in P;

• subst([N/x](λy•P)) ≡ λz•subst([N/z]subst([z/y]P)),

if y6=x and y is free in N and x is free in P

(where z is not free in (N P)).

B.4. LAMBDA–CALCULUS + FUNCTIONS 179

B.4.4 α–Renaming and β–Reduction

• α–renaming: λx•M

If x y are distinct variables then replacing x by y in λx•M results in λy•subst([y/x]M):We can rename the formal parameter of a λ-function expression provided that no freevariables of its body M thereby become bound.

• β–reduction: (λx•M)(N)

All free occurrences of x in M are replaced by the expression N provided that no freevariables of N thereby become bound in the result.

(λx•M)(N) ≡ subst([N/x]M)

B.4.5 Function Signatures

For some functions, we want to abstract from the function body:

valueobs Pos Aircraft: Aircraft → Pos,move: Aircraft × Dir → Aircraft,

B.4.6 Function Definitions

Functions — with body — can be defined explicitly:

valuef: A × B × C → Df(a,b,c) ≡ Value Expr

g: B-infset × (D →m C-set) ∼→ A∗

g(bs,dm) ≡ Value Exprpre P(dm)

or implicitly:

valuef: A × B × C → Df(a,b,c) as dpost P1(d)

g: B-infset × (D →m C-set) ∼→ A∗

g(bs,dm) as alpre P2(dm)post P3(al)

The symbol ∼→ indicates that the function is partial and thus not defined for all arguments.Partial functions should be assisted by pre–conditions stating the criteria for arguments tobe meaningful to the function.


B.5 Other Applicative Expressions

B.5.1 Let Expressions

Simple (i.e., non–recursive) let expressions:

let a = Ed in Eb(a) end

is an “expanded” form of:

(λa.Eb(a))(Ed)

Recursive let expressions are written as:

let f = λa:A • E(f) in B(f,a) end

is “the same” as:

let f = YF in B(f,a) end

where:

F ≡ λg•λa•(E(g)) and YF = F(YF)

Predicative let expressions:

let a:A • P(a) in B(a) end

express the selection of a value a of type A which satisfies a predicate P(a) for evaluation inthe body B(a).

Patterns and Wild Cards can be used:

let a ∪ s = set in ... endlet a, ∪ s = set in ... end

let (a,b,...,c) = cart in ... endlet (a, ,...,c) = cart in ... end

let 〈a〉` = list in ... endlet 〈a, ,b〉` = list in ... end

let [ a 7→b ] ∪ m = map in ... endlet [ a 7→b, ] ∪ m = map in ... end

B.6. IMPERATIVE CONSTRUCTS 181

B.5.2 Conditionals

Various kinds of conditional expressions are offered by RSL:

if b expr then c expr else a expr end

if b expr then c expr end ≡ /∗ same as: ∗/if b expr then c expr else skip end

if b expr 1 then c expr 1elsif b expr 2 then c expr 2elsif b expr 3 then c expr 3...elsif b exprt n then c expr n end

case expr ofchoice pattern 1 → expr 1,choice pattern 2 → expr 2,...choice pattern n or wild card → expr n

end

B.5.3 Operator/Operand Expressions

〈Expr〉 ::=〈Prefix Op〉〈Expr〉| 〈Expr〉〈Infix Op〉〈Expr〉| 〈Expr〉〈Suffix Op〉| ...

〈Prefix Op〉 ::=− | ∼ | ∪ | ∩ | card | len | inds | elems | hd | tl | dom | rng

〈Infix Op〉 ::== | 6= | ≡ | + | − | ∗ | ↑ | / | < | ≤ | ≥ | > | ∧ | ∨ | ⇒| ∈ | 6∈ | ∪ | ∩ | \ | ⊂ | ⊆ | ⊇ | ⊃ | | † |

〈Suffix Op〉 ::= !

B.6 Imperative Constructs

Often, following the RAISE method, software development starts with highly abstract–applicative which, through stages of refinements, are turned into concrete and imperative.Imperative constructs are thus inevitable in RSL.

B.6.1 Variables and Assignment

0. variable v:Type := expression1. v := expr


B.6.2 Statement Sequences and skip

Sequencing is done using the ’;’ operator. skip is the empty statement having no value orside–effect.

2. skip3. stm 1;stm 2;...;stm n

B.6.3 Imperative Conditionals

4. if expr then stm c else stm a end5. case e of: p 1→S 1(p 1),...,p n→S n(p n) end

B.6.4 Iterative Conditionals

6. while expr do stm end7. do stmt until expr end

B.6.5 Iterative Sequencing

8. for b in list expr • P(b) do S(b) end

B.7 Process Constructs

B.7.1 Process Channels

Let A, B and KIdx stand for a type of (channel) messages, respectively; then:

channel c:Achannel k[ i ]:B • i:KIdx

declare a channel, c, and a set of channels, k[i], able of communicating values of the designatedtypes.

B.7.2 Process Composition

Let P and Q stand for names of process functions, i.e., of functions which express willingnessto engage in input and/or output events, thereby communicating over declared channels.

Let P() and Q(i) stand for process expressions, then:

P() ‖ Q(i) Parallel compositionP() debc Q(i) Non−deterministic External Choice (either/or)P() de Q(i) Non−deterministic Internal Choice (either/or)P() –‖ Q() Interlock Parallel composition

express the parallel (‖) of two processes, the non–deterministic choice between two processes:Either external (debc) or internal (de). The interlock (–‖) composition expresses that the twoprocesses are forced to communicate only with one another, until one of them terminates.

B.8. SIMPLE RSL SPECIFICATIONS 183

B.7.3 Input/Output Events

Let c, k[i] and e designate a channels of type A and B, respectively; then:

c ?, k[ i ] ? Inputc ! e, k[ i ] ! e Output

expresses the willingness of a process to engage in an event that “reads” an input, andrespectively “writes” an output.

B.7.4 Process Definitions

The below signatures are just examples. They emphasise that process functions must somehowexpress, in their signature via which channels they wish to engage in input and output events.

valueP: Unit → in c out k[ i ] UnitQ: i:KIdx → out c in k[ i ] Unit

P() ≡ ... c ? ... k[ i ] ! e ...Q(i) ≡ ... k[ i ] ? ... c ! e ...

The process function definitions (i.e., their bodies) express possible events.

B.8 Simple RSL Specifications

Often, we do not want to encapsulate small specifications in schemes, classes, and objects;as often done in RSL. an RSL specification is simply a sequence of one or more types, values(including functions), variables, channels and axioms:

type...

variable...

channel...

value...

axiom...

Index

action, 98automatic block signalling, 110automatic signalling, 113, 155automatic train control, 77, 112

ccs, 17conductor, 94control areas, 137control theory, 46core, 146cost, 85crossing, 111crossover

switchable, 128, 131CSP, 17

day change, 87delay, 77deport, 93depot, 76, 83description

of schedule, 53direction on lines, 121, 154distributed scheduling, 135distributor, 139domain, 132duration

state, 38time, 38

duties, 99duty, 100dwarf signal, 110dynamical rail unit, 41

empty ride, 87engine

inside cleaning, 84operation check, 84outside cleaning, 84refill, 84

refuel, 84engine men, 94ETCS, 112exchange station, 96extension, 146

failure detection, 125formal

verification, 109formal method

integration, 132freight, 49, 61, 65

client, 65handling, 65law of preservation, 71lost & found, 69

freights, 21function

maintenance planning, 86

hierarchy of scheduling system, 140home deport, 94hub, 77human resources, 81

infrastructurelanguages, 15

initialization, 122, 124inside cleaning, 84interlockig

station, 154interlocking, 109, 127

regulation, 127rules, 127table, 127

interoperability, 112

journey, 50, 96

Kirschoff’s Laws, 54

184

INDEX 185

languagesprofessional, 15

lawsof Kirschoff’s flow, 54of nature, 22of preservation, 71

level crossing, 111line

capacity, 78direction, 109, 121, 154direction change, 124

lines, 23, 26live sequence chart, 123live sequence charts, 18, 154location

hub, 77loco driver, 94locomotive, 55lost & found, 69

maintenance, 76, 81, 83, 153day change, 87empty ride, 87night change, 87rostering, 83routing, 83type, 84types, 84

maintenance plan, 84maintenance planning function, 86marshalling, 78message sequence charts, 18Method

RAISE, 17VDM, 17

ML, 17

network, 26managed, 36

night change, 87

OBJ, 17operation check, 84optimum solution, 82outside cleaning, 84

passenger, 49, 61, 78, 151history, 62

reservation, 63ticket, 63traffic, 62

passengers, 21path, 29, 35

close, 35open, 35

petri net, 154Petri nets, 17, 128plan of maintenance, 84planning, 76

resource, 79rolling stock, 58

planning process, 80point, 30, 127, 128, 131predicate, 81predicates, 80professional languages, 15

qualityof schedule, 53of traffic, 53

railcontrol, 109dynamical unit, 41infrastructure, 75lines, 23, 26monitor, 109net, 23, 26, 33, 36, 75net development system, 135network, 26path, 29, 35point, 30, 127, 128, 131route, 35, 130routes, 31schedule, 49signal, 127, 130, 131station, 23, 26switch, 30, 127, 128, 131switchable-crossover, 128, 131timed unit, 41, 42timetable, 49traffic, 49unit, 23, 28, 127, 128, 130

railwaycrossing, 111

186 INDEX

net, 21reliability, 111safety, 111schedule, 49system, 21timetable, 49traffic, 49

railway net, 23, 33, 79, 153dynamics, 33static, 23

railway units, 153railways, 21RAISE, 17, 132

Method, 17RSL, 17Tool Set, 17

re–organisation state, 37, 40reliability, 111requirements, 132rescheduling, 76reservation, 63resource planning, 79ride, 96rolling stock, 21, 55, 81, 83, 152

location, 57planning, 58roster, 83

roster, 93, 102rolling stock, 83

rostering, 93, 152rostering with maintenance, 83route, 35, 36, 127, 130

acyclic, 31close, 35cyclic, 31open, 35train, 36

routes, 31RSL, 17, 132rule, 76, 83rules, 100

safety, 54, 111schedule, 49, 50, 76, 96

description, 53quality, 53

scheduling

distributed, 135vehicle, 152

scheduling systems, 135, 138hierarchy, 140

shunting, 78signal, 127, 130, 131signalling

automatic, 113, 155in station, 110, 127, 130, 131, 154on lines, 113, 121, 155semi-automatic, 113system, 135

stable state, 37, 38staff, 81

action, 98driving time, 99duties, 99duty, 100end time, 99home deport, 94member, 94, 103paid time, 99roster, 93rostering, 93rules, 100start time, 99type, 94

Standard ML, 17state

re–organisation, 37, 40sequence, 43stable, 37, 38transition, 37, 39

state duration, 38statechart, 122, 155statecharts, 17station, 23, 26, 96, 127

exchange, 96interlocking, 109manager, 121on lines, 110signalling, 110track, 77

station interlocking, 154statistic, 79statistics, 151switch, 30, 127, 128, 131

INDEX 187

systemrail net development, 135scheduling, 135, 138signalling, 135train control, 135train dispatch, 135

technical time, 98ticket, 63time duration, 38timed rail unit, 41, 42timetable, 21, 49, 75, 79, 154

generation, 80Timetabling, 79timetabling, 152track, 23, 77traffic, 49, 50, 143, 154

quality, 53schedule, 50

traincomposition, 58control, 112control system, 135delay, 77dispatch, 78dispatch system, 135length, 76

train route, 36transition state, 37, 39trip, 96

unit, 23, 28, 127, 128, 130

VDM, 17vehicle

maintenance, 81vehicle scheduling, 152

wagon, 55composition, 58inside cleaning, 84location, 57maintenance, 153operation check, 84outside cleaning, 84

well-formedness, 22

188 INDEX

Bibliography

[1] P. Alle. Improving rail transit line capacity using computer graphics. Logist. and Transp.Rev. (Canada), 17:429–442, 1981.

[2] A. M. Amendola, L. Impagliazzo, P. Marmo, and F. Poli. Experimental evaluationof computer-based railway control systems. In Proceedings of The Twenty-Seventh An-nual International Symposium on Fault-Tolerant Computing (FTCS’97), pages 380–384,Washington - Brussels - Tokyo, June 1997. IEEE.

[3] Ales J. Anot. Using Z Specification for Railway Interlocking Safety. Periodica Polytech-nica, Transport Engineering Series vol.28, no. 1–2, pp 39–53, Department of Informationand Safety Systems Faculty of Electrical Engineering University of Zilina, Vel’ky diel,Zilina 010 26, Slovak Republic, 2000.

[4] A. Anselmi, C. Bernardeschi, A. Fantechi, S. Gnesi, S. Larosa, G. Mongardi, and F. To-rielli. An experience in formal verification of safety properties of a railway signallingcontrol system. In Gerhard Rabe, editor, SAFECOMP’95: 14th International Con-ference on Computer Safety, Reliability and Security, pages 474–488, Belgirate, Italy,1995. Springer-Verlag.

[5] G. Aprea, P. Colantuoni, P. Firpo, R.Lido, D. Pellegrino, M. Rapone, and F. Sen-esi. SIGAV, the italian high speed railway integrated management system: Safety andreliability overview. In Erwin Schoitsch, editor, SAFECOMP’96: 15th InternationalConference on Computer Safety, Reliability and Security, page 250, Vienna, Austria,1996. Springer.

[6] C. Bailey, editor. European Railway Signalling, London, England, 1995. Institution ofRailway Signalling Engineers, A&C Black.

[7] T. Basten, R.N. Bol, and M. Voorhoeve. Simulating and Analyzing Railway Interlock-ing in ExSpect. Technical Report 94-37, Department of Computing Science, EindhovenUniversity of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands, Sep-tember 1994.

[8] T. Basten, R.N. Bol, and M. Voorhoeve. Simulating and analyzing railway interlockingsin ExSpect. IEEE Parallel & Distributed Technology: Systems & Applications, 3(3):50–62, Fall 1995.

[9] A. Bechina, J. Hermle, and M. Siormanolakis. Using Prolog for a railway control system.In Fourth International Conference on the Practical Application of Prolog; London, UK,pages 19–30. Practical Application Co., Blackpool, UK, 1996.

189

190 BIBLIOGRAPHY

[10] Anders Berg. Adtranz Signal’s Formal Verification Process: Safety Verification of Inter-locking Functionality. In Dines Bjørner and Maria Fahlen, editors, FMERail Workshop#4, volume # 4 of FMERail Workshop; Stockholm, Sweden. FME: Formal MethodsEurope, Banverket, Falun, Sweden, May 12–14 1999.

[11] J. Berger, P. Middelraad, and A.J. Smith. The European railway interlocking specifi-cation. In IRSE, pages 70–82, 1993.

[12] J. Billington and C. Janczura. Removing Deadlock from a Railway Network Specifica-tion. In Australian Engineering Mathematics Conference (AEMC’96), pages 193–200,Sydney, Australia, July 1996. Australian Engineering Mathematical Society.

[13] D. Bjørner. Software Engineering, vol 2: Specification of Systems and Languages. Textsin Theoretical Computer Science. Springer, 2006.

[14] Dines Bjørner. A Architecture for Running Map Systems. Technical Report db/arch/01,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], February 1994.

[15] Dines Bjørner. Models of the Railway System Infrastructure - from nets & signallingvia time-tables and schedules to marshalling and ticketing. In FMERail Workshop #1,volume # 1. FME: Formal Methods Europe, Utrecht, The Netherlands, June 1998.

[16] Dines Bjørner. Formal Software Techniques in Railway Systems. In Eckehard Schnieder,editor, 9th IFAC Symposium on Control in Transportation Systems, pages 1–12, Techni-cal University, Braunschweig, Germany, 13–15 June 2000. VDI/VDE-Gesellschaft Mess–und Automatisieringstechnik, VDI-Gesellschaft fur Fahrzeug– und Verkehrstechnik.

[17] Dines Bjørner. Dynamics of Railway Nets: On an Interface between Automatic Con-trol and Software Engineering. In CTS2003: 10th IFAC Symposium on Control inTransportation Systems, Oxford, UK, August 4-6 2003. Elsevier Science Ltd.

[18] Dines Bjørner. Train: The railway domain — an open research consortium — web:http://www.railwaydomain.org, 2005.

[19] Dines Bjørner, Jakob Braad, and Karin S. Mogensen (Eds.). Models of Railway Systems:Domain. In Thierry Lecomte and Peter Gorm Larsen, editors, FMERail Workshop #5,volume # 5 of FMERail Workshop; Toulouse, France. FME: Formal Methods Europe,Steria, France, September 22–24 1999.

[20] Dines Bjørner, Jakob Braad, and Karin S. Mogensen (Eds.). Models of Railway Systems:Requirements. In Thierry Lecomte and Peter Gorm Larsen, editors, FMERail Workshop#5, volume # 4 of FMERail Workshop; Toulouse, France. FME: Formal MethodsEurope, Steria, France, September 22–24 1999.

[21] Dines Bjørner, Chris George, Anne E. Haxthausen, Christian Krog Madsen, SteffenHolmslykke, and Martin Penicka. “UML”–ising Formal Techniques. In INT 2004: ThirdInternational Workshop on Integration of Specification Techniques for Applications inEngineering. Institut fur Softwaretechnik und Theoretische Informatik, Sekr. FR 6-1,Techn.Univ. of Berlin, Franklinstrasse 28/29, D–10587 Berlin, Germany, 28 March 2004,ETAPS, Barcelona, Spain.

BIBLIOGRAPHY 191

[22] Dines Bjørner, Chris W. George, and Søren Prehn. Computing Systems for Railways —A Role for Domain Engineering. Relations to Requirements Engineering and Softwarefor Control Applications. In Integrated Design and Process Technology. Editors: BerndKraemer and John C. Petterson, P.O.Box 1299, Grand View, Texas 76050-1299, USA,24–28 June 2002. Society for Design and Process Science.

[23] Dines Bjørner, C.W. George, B.S. Hansen, H. Laustrup, and S. Prehn et al. A Rail-way System, Coordination ‘97: Case Study Workshop Example. Technical Report 93,UNU/IIST, P.O.Box 3058, Macau, Spring 1997 – Fall 1998.

[24] Dines Bjørner, C.W. George, and S. Prehn. Scheduling and rescheduling of trains, page24 pages. Academic Press, 1999.

[25] Dines Bjørner, Dong Yu Lin, and S. Prehn. Domain Analyses: A Case Study of StationManagement. In KICS’94: Kunming International CASE Symposium, Yunnan Province,P.R.of China. Software Engineering Association of Japan, 16–20 November 1994.

[26] Dines Bjørner, Christian Krog Madsen, and Martin Penicka. Torward a formal modelof cyberrail. In Building the Information Society., pages 657–664. Norwell, MA: KluwerAcademic Publishers, 2004.

[27] Dines Bjørner, Søren Prehn, and Chris W. George. Formal Models of Railway Systems:Domains. Technical report, Dept. of IT, Technical University of Denmark, Bldg. 344,DK–2800 Lyngby, Denmark, September 23 1999.

[28] Dines Bjørner and Dong Yulin. Railway System Characteristic. Technical Reportdyl/3/1, UNU/IIST, the UN University’s International Institute for Software Technology,P.O.Box 3058, Macau; E-Mail: [email protected], August 1993.

[29] Jurgen Bohn, Werner Damm, Jochen Klose, Adam Moik, and Hartmut Wittke. Mod-eling and Validating Train System Applications Using Statemate and Live SequenceChats. In H. Ehrig, B. J. Kramer, and A. Ertas, editors, Proceedings of IDPT2002 -Integrated Design and Process Technology. Society for Design and Process Science, 2002.

[30] R.N. Bol, J.W.C. Koorn, L.H. Oei, and S.F.M. van Vlijmen. Syntax and Static Se-mantics of the Interlocking Design and Application Language. Technical Report P9422,Programming Research Group, University of Amsterdam, Kruislaan 403, 1098 SJ Am-sterdam, The Netherlands, November 1994.

[31] Grady Booch, Jim Rumbaugh, and Ivar Jacobson. The Unified Modeling Language UserGuide. Addison-Wesley, 1998.

[32] A. Boralv. A Fully Automated Approach for Proving Safety Properties in Interlock-ing Software Using Automatic Theorem-Proving. In S. Gnesi and D. Latella, editor,Proceedings of the Second International ERCIM Workshop on Formal Methods for In-dustrial Critical Systems, pages 39–62. Consiglio Nazionale Ricerche, Pisa, July 1997.

[33] A. Boralv. Formal Methods in Computerised Railway Interlocking at ADTranz. InFMERail Workshop 1, Stockholm, Sweden, 1998. Prover Technology AB.

192 BIBLIOGRAPHY

[34] A. Boralv and Carl-Johan Block. Formal Verification Tools in Swedish Railways 1989–1999. In Dines Bjørner and Maria Fahlen, editors, FMERail Workshop #4, volume # 4of FMERail Workshop; Stockholm, Sweden. FME: Formal Methods Europe, Banverket,Falun, Sweden, May 12–14 1999.

[35] Jakob Braad, Karin S. Mogensen, and Dines Bjørner. Interlocking: Specification andTest Case Generation for the Safety Kernel of the Naples Subway. In Dines Bjørner andMaria Fahlen, editors, FMERail Workshop #4, volume # 4 of FMERail Workshop;Stockholm, Sweden. FME: Formal Methods Europe, Banverket, Falun, Sweden, May12–14 1999.

[36] Jakob Braad, Karin S. Mogensen, and Dines Bjørner. The Automatic Railway Case(Based on [81]). In Dines Bjørner and Maria Fahlen, editors, FMERail Workshop #4,volume # 4 of FMERail Workshop; Stockholm, Sweden. FME: Formal Methods Europe,Banverket, Falun, Sweden, May 12–14 1999.

[37] R. A. Brand. 3-D colour graphics for rail network simulation and control. In FirstAustralasian Conf. on Computer Graphics, pages 38–48, 1983.

[38] Ulrik Brandes and Dorothea Wagner. Using Graph Layout to Visualize Train Intercon-nection Data. Research report, konstanz, 1999.

[39] G. Bruno, G. Ghiani, and G. Improta. Models and algorithms for the design of rapidtransit networks. In Proc. 7th Int. Special Conf. IFORS, Information Systems in Lo-gistics and Transportation, June 1997.

[40] A. Bud, A. Nicholson, and B. Chandra. Scheduling trains with genetic algorithms.Technical Report 96/250, Dept. Computer Science, Monash University, Australia 3168,October 1996.

[41] Michael R. Bussieck, Peter Kreuzer, and Uwe T. Zimmermann. Optimal lines for railwaysystems. Technical Report TR-95-01, MOTUBS, 1995.

[42] E. Canver, J.T. Gayen, and A. Moik. Formal specification of the controller software onrailway switch example. Automatiserungs Praxis, 1997.

[43] L. Ceglowski and A. Lewinski. Highly reliable microcomputer systems for railway con-trol. SARSS’87: Achieving Safety and Reliability with Computer Systems, page 182,1987.

[44] CENELEC European Committee for Electro-technical Standardisation. CENELEC50127-1: Railway Applications – Guide to the specification of a guided transport system,Part 1: General.

[45] CENELEC European Committee for Electro-technical Standardisation. CENELEC50128: Railway Applications – Software for railway control and protection systems.

[46] CENELEC European Committee for Electro-technical Standardisation. CENELEC50129: Railway Applications – Safety related electronic systems for signalling.

BIBLIOGRAPHY 193

[47] CENELEC European Committee for Electro-technical Standardisation. CENELECEN 50126: Railway Applications – the specification and demonstration of Reliability,Availability, Maintainability and Safety.

[48] Ma Chao. PRaCoSy: Data Structures for Train Journeys. Technical Report mc/dstr1/1,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], May 1994.

[49] Zhou Chaochen and Yu Huiqun. A duration Model for Railway scheduling. TechnicalReport 24b, UNU/IIST, P.O.Box 3058, Macau, May 1994.

[50] Zhou Chaochen, Anders P. Ravn, and Michael R. Hansen. An Extended DurationCalculus for Real-time Systems. Research Report 9, UNU/IIST, P.O.Box 3058, Macau,January 1993. Published in: Hybrid Systems, LNCS 736, 1993.

[51] Tommy W. S. Chow and Oulian Shuai. Feedforward neural networks based input-outputmodels for railway carriage system identification. Neural Processing Letters, 5(2):57–67,1997.

[52] Tadeusz Cichocki and Janusz Gorksi. Safety Assessment of Computerised RailwaySignalling supported by Formal Methods. In Thierry Lecomte and Peter Gorm Larsen,editors, FMERail Workshop #5, volume # 5 of FMERail Workshop; Toulouse, France.FME: Formal Methods Europe, Steria, France, September 22–24 1999.

[53] Alessandro Cimatti, Fausto Giunchiglia, Giorgio Mongardi, Dario Romano, FernandoTorielli, and Paolo Traverso. Model Checking Safety Critical Software with SPIN: anApplication to a Railway Interlocking System. In SPIN NEWS Letter Nr. 16, 11 March1997.

[54] M. T. Claessens and N. M. van Dijk. A mathematical programming model to determinea set of operation lines at minimal costs. Technical report, University of Amsterdam,1994.

[55] Robin Cook. Management of dependability: A railway perspective. In Felix Redmilland Tom Anderson, editors, Safety-Critical Systems: The Convergence of High Techand Human Factors: Proceedings of the 4th Safety-critical Systems Symposium Leeds,UK 6-8 February 1996, pages 61–70, Leeds, UK, 1996. Springer.

[56] Teodor Gabriel Crainic and Jacques Roy. OR tools for tactical freight transportationplanning. EUJOR, 33:290–297, 1988.

[57] A.H. Cribbens. Solid Sate Interlocking (SSI): An integrated electronic signalling systemfor mainline railways. In IEE Proceedings, volume 134(3), pages 148–158, 1987.

[58] J. Cullyer and J. Fairclough. Safety critical systems - when computers might kill.Information Technology & Public Policy, 11(1):14–19, 1992.

[59] J. Cullyer and Wong Wai. Application of formal methods to railway signalling - a casestudy. Computing & Control Engineering Journal, 4(1):15–22, Feb. 1993.

194 BIBLIOGRAPHY

[60] W. J. Cullyer and Wong Wai. A formal approach to railway signalling. In Compass’90: 5th Annual Conference on Computer Assurance, pages 102–108, Gaithersburg,Maryland, 1990. National Institute of Standards and Technology.

[61] W.J. Cullyer and J.W. Wise. Application of formal methods to railway signalling.SARSS’89: Reliability on the Move, page 11, 1989.

[62] A. Cuppari and F. Zini. an Agent-based Prototype for Freight Traffic Management.In Thierry Lecomte and Peter Gorm Larsen, editors, FMERail Workshop #5, volume# 4 of FMERail Workshop; Toulouse, France. FME: Formal Methods Europe, Steria,France, September 22–24 1999.

[63] Werner Damm and David Harel. LSCs: Breathing life into Message Sequence Charts.Formal Methods in System Design, 19:45–80, 2001.

[64] Werner Damm and Jochen Klose. Verification of a Radio-based Signaling System Usingthe Statemate Verification Environment. Formal Methods in System Design, 19(2),2001.

[65] Jin Danhua. A First Mathematical Model of Train Time Tabling. Technical Re-port jdh/math/03, UNU/IIST, the UN University’s International Institute for SoftwareTechnology, P.O.Box 3058, Macau; E-Mail: [email protected], August 1994.

[66] Jin Danhua. Running Map Display Transformation. Technical Report jdh/trans/02,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], April 1994.

[67] Jin Danhua. A Second Math. Model of Train Time Tabling. Technical Reportjdh/math/05, UNU/IIST, the UN University’s International Institute for SoftwareTechnology, P.O.Box 3058, Macau; E-Mail: [email protected], October 1994.

[68] B. Dehbonei and L.-F. Mejia. Formal development of software in safety-critical railwaysystems. In B. T. K. S. Murthy, C. A. Mellitt, G. Brebbia, and S. Sciutto, editors, Rail-way Operations, volume 2, pages 213–219. COMPRAIL94, Computational MechanicsPublications, 1994.

[69] H. Dierks and C. Dietz. Graphical specification and reasoning: Case study generalisedrailroad crossing. In John Fitzgerald, Cliff B. Jones, and Peter Lucas, editors, FME’97:Industrial Applications and Strengthened Foundations of Formal Methods (Proc. 4thIntl. Symposium of Formal Methods Europe, Graz, Austria, September 1997), volume1313 of Lecture Notes in Computer Science, pages 20–39. Springer-Verlag, September1997. ISBN 3-540-63533-5.

[70] G. Dipoppa and R. Bove. Modelling a Railway Application in a Geographical andTextual Integrated Fashion. In FMERail Workshop 2, Via Anguillarese, 301 S.Mariadi Galeria, I–00060 Roma, Italy, 1998. ENEA C.R.-CASACCIA.

[71] YuLin Dong, Dines Bjørner, and S. Prehn. Domain Analysis: A Case Studyof Railway Station Management. Technical Report db/03/01, UNU/IIST, the UNUniversity’s International Institute for Software Technology, P.O.Box 3058, Macau; E-Mail: [email protected], November 12 1994.

BIBLIOGRAPHY 195

[72] Josef Doppelbauer. Electronic Interlocking Systems. In FMERail Workshop #3, vol-ume # 3. FME: Formal Methods Europe, February 1999.

[73] Josef Doppelbauer. Safety Considerations on Railway Signalling Systems — is therea Future for Formal Methods ? In Thierry Lecomte and Peter Gorm Larsen, editors,FMERail Workshop #5, volume # 5 of FMERail Workshop; Toulouse, France. FME:Formal Methods Europe, Steria, France, September 22–24 1999.

[74] E. Durr, N. Plat, and M. de Boer. CombiCom: Tracking and Tracing Rail Trafficusing VDM++. In Michael G. Hinchey and Jonathan P. Bowen, editors, Applicationsof Formal Methods, pages 203–225. Prentice-Hall International, 1995. ISBN 0-13-3-366949-1.

[75] L.H. Eriksson. Specifying railway interlocking requirements for practical use. In ErwinSchoitsch, editor, SAFECOMP’96: 15th International Conference on Computer Safety,Reliability and Security, page 243, Vienna, Austria, 1996. Springer.

[76] L.H. Eriksson. Formal Verification of Railway Interlockings. Technical Report 1997:4,Swedish National Rail Administration, Banverket HK, S–781 85 Borlange, Sweden,December 1 1997.

[77] L.H. Eriksson. Formalising Railway Interlocking Requirements. Technical Report1997:3, Swedish National Rail Administration, Banverket HK, S–781 85 Borlange, Swe-den, December 1 1997.

[78] L.H. Eriksson. Adtranz Signal’s Formal Verification Process: The STERNOL Specifi-cation Tool (SST) (See [77, 76]). In Dines Bjørner and Maria Fahlen, editors, FMERailWorkshop #4, volume # 4 of FMERail Workshop; Stockholm, Sweden. FME: FormalMethods Europe, Banverket, Falun, Sweden, May 12–14 1999.

[79] L.H. Eriksson. Some Technical Aspects of an Interlocking Specification language (See[77, 76]). In Dines Bjørner and Maria Fahlen, editors, FMERail Workshop #4, vol-ume # 4 of FMERail Workshop; Stockholm, Sweden. FME: Formal Methods Europe,Banverket, Falun, Sweden, May 12–14 1999.

[80] Maria Fahlen. A Unified Language for Railway Signalling Specification (Railway Op-erating Company Benefits). In Dines Bjørner and Maria Fahlen, editors, FMERailWorkshop #4, volume # 4 of FMERail Workshop; Stockholm, Sweden. FME: FormalMethods Europe, Banverket, Falun, Sweden, May 12–14 1999.

[81] L.M.G. Feijs, H.B.M. Jonkers, and C.A. Middelburg. The Automatic Railway case,chapter 2. FACIT Series. Springer–Verlag, 1994.

[82] W.J. Fokkink. Safety criteria for the vital processor interlocking at Hoorn–Kersenboogerd. In Proceedings of the 5th Conference on Computers in Railways, COM-PRAIL’96, Part I: Railway Systems and Management, pages 101–110, Berlin, 1996.Computational Mechanics Publications.

[83] W.J. Fokkink, G.P. Kolk, and S.F.M. van Vlijmen. EURIS, a specification method fordistributed interlockings. In Proceedings of SAFECOMP ’98, LNCS. Springer-Verlag,1998.

196 BIBLIOGRAPHY

[84] Daniel Fredholm. Specifying an Interlocking System: The Alister Project. In DinesBjørner and Maria Fahlen, editors, FMERail Workshop #4, volume # 4 of FMERailWorkshop; Stockholm, Sweden. FME: Formal Methods Europe, Banverket, Falun, Swe-den, May 12–14 1999.

[85] Bruno Fringuelli, Evelina Lamma, Paola Mello, and Giovanni Santocchia. Knowledge-based technology for controlling railway stations. IEEE Expert, 7(6):45–52, December1992.

[86] Chris W. George, Peter Haff, Klaus Havelund, Anne E. Haxthausen, Robert Milne,Claus Bendix Nielsen, Søren Prehn, and Kim Ritter Wagner. The RAISE SPECIFI-CATION LANGUAGE. Prentice Hall BCS Practitioners Series. Prentice Hall, EllisHorwood, Campus 400, Maylands Ave., Hemel Hampstead, Herts., HP2 7EZ, England,2nd. edition, 1992. 409 pages; ISBN 0-13-752833-7; $ 47.95.

[87] Chris W. George and Yong Xia. An Operational Semantics for Timed RAISE. InJeannette M. Wing, Jim Woodcock, and Jim Davies, editors, FM’99 — Formal Methods,pages 1008–1027. FME, Springer–Verlag, 1999.

[88] C.W. George. A Theory of Distributed Train Rescheduling. In Marie-Claude Gaudel andJim Woodcock, editors, FME’96: Industrial Benefit and Advances in Formal Methods,pages 499–517. Springer-Verlag, March 1996.

[89] T. Gjaldbaek and Haxthausen A.E. Modelling and verification of interlocking systemsfor railway lines. In IFAC-CTS, 2003.

[90] S. Gnesi, D. Latella, G. Lenzini, C. Abbaneo, A. Amendola, and P. Marmo. An au-tomatic SPIN validation of a safety critical railway control system. In InternationalConference on Dependable Systems & Networks, pages 119–124. IEEE Computer Soci-ety Press, 2000.

[91] S. Gnesi, D. Latella, and M. Massink. Model Checking UML Statechart Diagrams usingJACK. In Proc. Fourth IEEE International Symposium on High Assuarance SystemsEnginering. IEEE Press, 1999.

[92] Bogdan Godziejewski. Applying Formal Methods in a Changing Railway Environmen.In FMERail Workshop #2, volume # 2. FME: Formal Methods Europe, Formal Sys-tems (Europe) Ltd, Keble Court, 26 Temple Street, Oxford OX4 1JS, UK, Telephone:+44 1865 728460, Telefax: +44 1865 201114, October 1998.

[93] C.A. Grimes. Application of genetic techniques to the planning of railway track main-tenance work. In A.M.S. Zalzala, editor, First International Conference on GeneticAlgorithms in Engineering Systems: Innovations and Applications, GALESIA, volume414, pages 467–472, Sheffield, UK, 12-14 Sept. 1995. IEE.

[94] J.F. Groote. A Language for Railway Interlocking Specification. In FMERail Workshop1, Amsterdam, NL, 1998. CWI.

[95] J.F. Groote, S.F. van Vlijmen, and J.W.C. Koorn. The safety guaranteeing systemat station Hoorn-Kersenboogerd. In COMPASS ’95. Proceedings of the Tenth AnnualConference on Computer Assurance (Cat. No.95CH35802); Gaithersburg, MD, USA,pages 57–68. IEEE, New York, N.Y., USA, 1995.

BIBLIOGRAPHY 197

[96] Object Management Group. OMG Unified Modelling Language Specifica-tion. OMG/UML, http://www.omg.org/uml/, version 1.5 edition, March 2003.www.omg.org/cgi-bin/doc?formal/03-03-01.

[97] G. Guiho and L.-F. Mejia. Operational safety critical software methods in railways. InAnon, editor, IFIP Transactions A (Computer Science and Technology),, pages 262–9.IFIP World Congress, Hamburg, Germany, 1984.

[98] Sun Guoqin. Formal Models of Time-table Input Tool. Technical Report sgq/11/3,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], October 1994.

[99] Sun Guoqin. PRaCoSy: Data Structures for Railway Networks. Technical Reportsgq/3/1, UNU/IIST, the UN University’s International Institute for Software Technology,P.O.Box 3058, Macau; E-Mail: [email protected], June 1994.

[100] Sun Guoqin. PRaCoSy: Data Structures for Time-table Projections. Technical Reportsgq/4/1, UNU/IIST, the UN University’s International Institute for Software Technology,P.O.Box 3058, Macau; E-Mail: [email protected], July 1994.

[101] Sun Guoqin. PRaCoSy: Time-Table Preparation Tool Scriptor. Technical Re-port sgq/12/1, UNU/IIST, the UN University’s International Institute for SoftwareTechnology, P.O.Box 3058, Macau; E-Mail: [email protected], October 1994.

[102] Sun Guoqing, Liu Xin, and S. Parthasarathy. Global Data Flow Diagrams for Train Dis-patch. Technical Report sgq/1/6, UNU/IIST, the UN University’s International Institutefor Software Technology, P.O.Box 3058, Macau; E-Mail: [email protected], Au-gust 1994.

[103] Shigeru Haga. Prevention of accidents at road-rail level crossings protected with au-tomatic barriers. In Proceedings of the Human Factors Society 32nd Annual Meeting,volume 1 of Safety: Transportation Safety, pages 933–937, 1988.

[104] G. Hagelin. Safety systems for railway control. In U. Voges, editor, Software diversityin computerized control systems, pages 11–21. Springer, 1988.

[105] Kirsten Mark Hansen. Modeling Railway Interlocking Systems. In FMERail Workshop#2, volume # 2. FME: Formal Methods Europe, Formal Systems (Europe) Ltd, KebleCourt, 26 Temple Street, Oxford OX4 1JS, UK, Telephone: +44 1865 728460, Telefax:+44 1865 201114, October 1998.

[106] K.M. Hansen. Validation of a railway interlocking model. In M. Naftalin, T. Denvir,and M. Bertran, editors, FME ’94: Industrial Benefit of Formal Methods. Second Inter-national Symposium of Formal Methods Europe. Proceedings; Barcelona, Spain, pages582–601. Springer-Verlag, Berlin, Germany; Lecture Notes in Computer Science LNCS,1994.

[107] K.M. Hansen. Modelling Railway Interlocking Systems. Technical Report ID-TR: 1996-167, Department of Computer Science, Technical University of Denmark, Building 344,DK-2800 Lyngby, Denmark, September 1995.

198 BIBLIOGRAPHY

[108] K.M. Hansen. Linking Safety Analysis to Safety Requirements. PhD thesis, Departmentof Computer Science, Technical University of Denmark, Building 344, DK-2800 Lyngby,Denmark, August 1996.

[109] S. Hanzel. Electronic data interchange in railway traffic. In J. Gricar, editor, EDI:Business Strategy For 90’s The 4th Electronic Data Interchange Conference, pages 309–317, Bled, Slovenia,Yugoslavia, June 10-12 1991.

[110] David Harel. Statecharts: A visual formalism for complex systems. Science of ComputerProgramming, 8(3):231–274, 1987.

[111] David Harel. On visual formalisms. Communications of the ACM, 33(5), 514–530 1988.

[112] V. Hartonas-Garmhausen, T. Kurfess, E.M. Clarke, and D. Long. Automatic verifi-cation of industrial designs. In Workshop on Industrial-Strength Formal SpecificationTechniques (Cat. No.95TH8051); Boca Raton, FL, USA. IEEE Comput. Soc. Press,Los Alamitos, CA, USA, 1995.

[113] A. Haxthausen and T. Gjaldbæk. Modelling and Verification of Interlocking Systemsfor Railway Lines. In 10th IFAC Symposium on Control in Transportation Systems,Tokyo, Japan, August 4–6 2003.

[114] A. E. Haxthausen and J. Peleska. A Domain Specific Language for Railway ControlSystems. In Sixth Biennial World Conference on Integrated Design and Process Technol-ogy, (IDPT2002), Pasadena, California, P.O.Box 1299, Grand View, Texas 76050-1299,USA, June 23-28 2002. Society for Design and Process Science.

[115] Aanne Haxthausen and Jan Peleska. Generation of Executable Railway Control Com-ponents from Domain-Specific Descriptions. In Proceedings of the Symposium on For-mal Methods for Railway Operation and Control Systems (FORMS’2003). L’HarmattanHongrie, 2003. To appear.

[116] Anne Haxthausen and Jan Peleska. Formal Development and Verification of a Distrib-uted Railway Control System. In Proceedings of First (and Second) FMERail Workshop,1998.

[117] Anne Haxthausen and Jan Peleska. Formal Development and Verification of a Distrib-uted Railway Control System. IEEE Transaction on Software Engineering, 26(8):687–701, 2000.

[118] Anne Haxthausen and Jan Peleska. Automatic Verification, Validation and Test forRailway Control Systems based on Domain-Specific Descriptions. In 10th IFAC Sym-posium on Control in Transportation Systems, Tokyo, Japan, August 4–6 2003.

[119] Anne Haxthausen and Xia Yong. Linking DC together with TRSL. In Proceedings of 2ndInternational Conference on Integrated Formal Methods (IFM’2000), Schloss Dagstuhl,Germany, November 2000, number 1945 in Lecture Notes in Computer Science, pages25–44. Springer-Verlag, 2000.

[120] I. Hayashi, K. Itoh, and S. Suzuki. Man-machine interactive guidance for urban railwaynetworks passenger information system. Computers and Graphics, 7(1):59–72, 1983.

BIBLIOGRAPHY 199

[121] U. Heinrichs and C. Moll. On the scheduling of one-dimensional transport systems.Technical report, Mathematisches Institut, Universitat zu Koln, 1997.

[122] M. Hollenberg, J.F. Groote, and S.F.M. van Vlijmen. Laris 1.0 Language for RailwayInterlocking Specifications. Utrecht.

[123] C Horellou, C Rossi, and G Sissa. An AI/real time solution for expert scheduling ofunderground rail traffic. SARSS’89: Reliability on the Move, page 47, 1989.

[124] G. Howarth, B.C. Ashcroft, and N.R. Jenkins. Computer graphics as a tool for aconsultation (in railway projects) — Computer Applications in Railway Planning andManagement. In T.K.S. Murthy, R.E. Rivier, G.F. List, and J. Mikolaj, editors, Proceed-ings of the Second International Conference on Computer Aided Design, Manufactureand Operation in the Railway and Other Advanced Mass Transit Systems, pages 63–73.Comput. Mech. Publications, 1990.

[125] M. Ingleby. Safety properties of a control network: local and global reasoning in machineproof. In Proceedings of Real Time Systems. Paris, January 1994.

[126] M. Ingleby and D.J. Mee. A calculus of hazard for railway signalling. In Workshop onIndustrial-Strength Formal Specification Techniques (Cat. No.95TH8051); Boca Raton,FL, USA, pages 146–58. IEEE Comput. Soc. Press, Los Alamitos, CA, USA, 1995.

[127] M. Ingleby and I.H. Mitchell. Proving Safety of a Railway Signaling System Incorpo-rating Geographic Data. In H.H. Frey, editor, SAFECOM’92 Conference Proceedingsof IFAC, pages 129–134, Zurich (CH), November 1992. Pergamon Press.

[128] Internation Telecommunication Union (ITU-T). CCITT Recommendation Z.120: Mes-sage Sequence Chart (MSC), 1992.

[129] Internation Telecommunication Union (ITU-T). ITU-T Recommendation Z.120: Mes-sage Sequence Chart (MSC), 1996.

[130] Internation Telecommunication Union (ITU-T). ITU-T Recommendation Z.120: Mes-sage Sequence Chart (MSC), 1999.

[131] David Jackson. Mechanical Verification of British Rail Interlocking. In FMERail Work-shop #2, volume # 2. FME: Formal Methods Europe, Formal Systems (Europe) Ltd,Keble Court, 26 Temple Street, Oxford OX4 1JS, UK, Telephone: +44 1865 728460,Telefax: +44 1865 201114, October 1998.

[132] Michael A. Jackson. Software Requirements & Specifications: a lexicon of practice, prin-ciples and prejudices. ACM Press. Addison-Wesley Publishing Company, Wokingham,nr. Reading, England; E-mail: [email protected], 1995. ISBN 0-201-87712-0;xiv + 228 pages.

[133] Ivar Jacobson, Grady Booch, and Jim Rumbaugh. The Unified Software DevelopmentProcess. Addison-Wesley, 1999.

[134] M. Jelaska. Computer elaboration of time-table for single railway line. In Jean Cea,editor, Proceedings of the 7th IFIP Conference on Optimization Techniques: Modeling

200 BIBLIOGRAPHY

and Optimization in the Service of Man - Part 1, volume 41 of LNCS, pages 657–675,Nice, France, September 1975. Springer.

[135] Li-Min Jia and Xi-Di Zhang. Distributed intelligent railway traffic control based onfuzzy decision making. Fuzzy Sets and Systems, 62(3):255–265, 1994.

[136] R. M. J. Jose, G. vom Scheidt, and J. F. Boyce. Application of connectionist local searchto line management rail traffic control. In Proceedings of the 3rd International Confer-ence on the Practical Application of Constraint Technology, pages 193–212, Blackpool,April, 23–25 1997. The Practical Application Ltd.

[137] T. King. Formalising British Rail’s Signalling Rules. In M. Bertran M. Naftalin, T. Den-vir, editor, FME’94: Industrial Benefit of Formal Methods, pages 45–54. Springer-Verlag, October 1994.

[138] F. Kitahara, H. Katano, T. Ono, Y. Kakumoto, K. Kikuchi, and M. Shinomoto. Dis-tributed management for software maintenance in a wide-area railway system. In Pro-ceedings - ISADS 97 - Third International Symposium on Autonomous DecentralizedSystems (Cat. No. 97TB100111), pages 311–18. IEEE Comput. Soc. Press, 1997.

[139] R. Knigge, H. Eilers, and V. Freitag. New generation of microcomputer-based opera-tions control systems for high-speed rail and guided transportation as demonstrated byTRANSRAPID. In IFIP World Computer Congress, Hamburg, pages 174–179. IFIP,1994.

[140] Gea Kolk. Interlocking logic: specification and validation form a users perspective. InFMERail Workshop #1, volume # 1. FME: Formal Methods Europe, Utrecht, TheNetherlands, June 1998.

[141] Frantisek Kopecky, Miroslav Svıtek, and Martin Penicka. Telematika a zeleznicni in-frastruktura. In Nova zeleznicni technika. roc. 8, c. 4, pages 113–117. Zilina: Zilinskvzdelavaci servis, 2000.

[142] Leo G. Kroon, H. Edwin Romeijn, and Peter J. Zwanefeld. Routing Trains throughrailway stations: complexity issues. European Journal of Operational Research, ElsevierScience B.V., The Netherlands, 98:485–498, 1997.

[143] Gao Lan. Human-computer interaction system in railway management administrationnetwork. In Proceedings of the Fifth International Conference on Human-ComputerInteraction – Poster Sessions: Abridged Proceedings, volume 3 of Case Studies andApplications, page 103, 1993.

[144] Peter Gorm Larsen. A VDM-SL Specification of the Dwarf Signal Controller. InFMERail Workshop #3, volume # 3. FME: Formal Methods Europe, February 1999.

[145] Thierry Lecomte. Dwarf Signal Formalisation in B. In Thierry Lecomte and Peter GormLarsen, editors, FMERail Workshop #5, volume # 5 of FMERail Workshop; Toulouse,France. FME: Formal Methods Europe, Steria, France, September 22–24 1999.

BIBLIOGRAPHY 201

[146] Annegret Liebers, Dorothea Wagner, and Karsten Weihe. On the Hardness of Recog-nising Bundles in Time Table Graphs. International Journal of Foundations of Com-puter Science, World Scientific Publishing Company, Singapore, page 13 pages, 1999(or 2000).

[147] Morten Peter Lindegaard, Peter Viuf, and Anne Haxthausen. Modelling Railway In-terlocking Systems. In Proceedings of the 9th IFAC Symposium on Control in Trans-portation Systems 2000, June 13-15, 2000, Braunschweig, Germany, pages 211–217,2000.

[148] J. N. K. Liu and K. Y. Sin. Fuzzy neural networks for machine maintenance in masstransit railway systems. IEEE Transactions on Neural Networks, 8(4):932–941, July1997.

[149] Eugenio Roanes Lozano. An Algebraic Model for Decision Taking in a Railway In-terlocking. In FMERail Workshop #3, volume # 3. FME: Formal Methods Europe,February 1999.

[150] Gabriele Malavassi and Stefano Ricci. Petri Nets in the Railway Signalling Model. InThierry Lecomte and Peter Gorm Larsen, editors, FMERail Workshop #5, volume# 5 of FMERail Workshop; Toulouse, France. FME: Formal Methods Europe, Steria,France, September 22–24 1999.

[151] J. Meertens. Verifying the safety guaranteeing system at railway station Heerhugowaard.Master’s thesis, Utrecht University, Department of Philosophy, Faculteit Wijsbegeerte,August 1996.

[152] M.J. Morley. Safety in railway signaling data: A behavioural analysis. In J.J. Joyceand C.-J.H. Seger, editors, International Workshop on Higher Order Logic TheoremProving and its Applications, volume 780 of Lecture Notes in Computer Science, pages465–476, Vancouver, Canada, August 1993. University of British Columbia, Springer-Verlag, published 1994.

[153] Markus Montigel. Formal representation of track topologies by double vertex graphs. InProceedings of Railcomp 92 held in Washington DC, Computers in Railways 3, volume2: Technology. Computational Mechanics Publications, 1992.

[154] Markus Montigel. Formal Methods in Computer-based Safety Systems: Design of aControl Process for an Alcatel-like Dwarf Signal. In Markus Montigel, editor, FMERailWorkshop #3, volume # 3 of FMERail Workshop; St. Polten. FME: Formal MethodsEurope, February 17–19 1999.

[155] Markus Montigel. Specification of the Control Process for a Dwarf Signal (See also[154]). In Thierry Lecomte and Peter Gorm Larsen, editors, FMERail Workshop #5,volume # 5 of FMERail Workshop; Toulouse, France. FME: Formal Methods Europe,September 22–24 1999.

[156] M.J. Morley. Modelling British Rail’s Interlocking Logic: Geographic Data Correctness.Technical Report ECS-LFCS-91-186, University of Edinburgh, 1991.

202 BIBLIOGRAPHY

[157] M.J. Morley. Safety Assurance in Interlocking Design. PhD thesis, University of Edin-burgh, 1996.

[158] Rudolf G. Mortimer. Visual factors in rail-highway grade crossing accidents. In Pro-ceedings of the Human Factors Society 35th Annual Meeting, volume 1 of ForensicsProfessional: Real-World Problems and Practices in Forensics, pages 600–602, 1991.

[159] Rudolf G. Mortimer. Oh! say, can you hear that train coming to the crossing? In Pro-ceedings of the Human Factors and Ergonomics Society 38th Annual Meeting, volume 2of SAFETY: Safety Potpourri II [Lecture], pages 898–902, 1994.

[160] Kathleen Murphy, Elizabeth Ralston, David Friedlander, Rodney Swab, and PaulSteege. The scheduling of rail at Union Pacific Railroad. In Proceedings of the 14thNational Conference on Artificial Intelligence and 9th Innovative Applications of Ar-tificial Intelligence Conference (AAAI-97/IAAI-97), pages 903–912, Menlo Park, July27–31 1997. AAAI Press.

[161] J. Nievergelt. Thoughts on Traffic Scheduling and Time Table Design. Technical Reportdyl/9/2, Swiss Federal Technical University, Zurich, Informatik, ETH, CH-8092 Zurich,Switzerland, January 1994.

[162] Takahiko Ogino and Yuji Hirao. Formal methods and their applications to safety-critical systems of railways. Quarterly Report of RTRI. Ken-yusha for Railway TechnicalResearch Institute of Japan, Tokyo, 36(4), 1995.

[163] S. Parthasarathy. An Informal Definiton of the Scheduling Problem in PRaCoSy. Tech-nical Report par/5/1, UNU/IIST, the UN University’s International Institute for SoftwareTechnology, P.O.Box 3058, Macau; E-Mail: [email protected], October 1993.

[164] S. Parthasarathy. PRaCoSy: An Executive Overview. Technical Report par/02/09,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], June 1994.

[165] S. Parthasarathy. PRaCoSy: Document Roadmap. Technical Report par/roadmap/2,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], June 1994.

[166] S. Parthasarathy. PRaCoSy Project Phase i: Revised Activity Plan. Technical Re-port par/plan/01, UNU/IIST, the UN University’s International Institute for SoftwareTechnology, P.O.Box 3058, Macau; E-Mail: [email protected], April 1994.

[167] S. Parthasarathy. PRaCoSy: Software Design Description. Technical Report par/sdd/2,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], July 1994.

[168] S. Parthasarathy. Episode Analysis — A Practical Approach for Temporal Reasoningin Automated Processes. Engineering Applications of AI, 1995.

[169] S. Parthasarathy and Dines Bjørner. PRaCoSy: Document Catalogue. Technical Re-port jdh/catal/05, UNU/IIST, the UN University’s International Institute for SoftwareTechnology, P.O.Box 3058, Macau; E-Mail: [email protected], July 1994.

BIBLIOGRAPHY 203

[170] S. Parthasarathy, Søren Prehn, and Dines Bjørner. Descriptors for Running Maps.Technical Report par/desc/06, UNU/IIST, the UN University’s International Institutefor Software Technology, P.O.Box 3058, Macau; E-Mail: [email protected], April1994.

[171] S. Parthasarathy, Søren Prehn, and Dines Bjørner. PRaCoSy: Work-package Descrip-tion. Technical Report par/03/03, UNU/IIST, the UN University’s International Institutefor Software Technology, P.O.Box 3058, Macau; E-Mail: [email protected], Jan-uary 1994.

[172] S. Parthasarathy, Søren Prehn, and Dines Bjørner. Railway System Terminology. Tech-nical Report par/terms/09, UNU/IIST, the UN University’s International Institute forSoftware Technology, P.O.Box 3058, Macau; E-Mail: [email protected], June1994.

[173] S. Parthasarathy, Søren Prehn, and Dines Bjørner. Running Map Display andInteractivity. Technical Report par/disply/03, UNU/IIST, the UN University’sInternational Institute for Software Technology, P.O.Box 3058, Macau; E-Mail:[email protected], March 1994.

[174] Jan Storbank Pedersen. Specifying Aspects of a Dwarf Signal System Using RAISE.In Thierry Lecomte and Peter Gorm Larsen, editors, FMERail Workshop #5, volume# 5 of FMERail Workshop; Toulouse, France. FME: Formal Methods Europe, Steria,France, September 22–24 1999.

[175] Jan Peleska, Alexander Baer, and Aanne Haxthausen. Towards Domain-Specific For-mal Specification Languages for Railway Control Systems. In Proceedings of the 9thIFAC Symposium on Control in Transportation Systems 2000, June 13-15, 2000, Braun-schweig, Germany, pages 147–152, 2000.

[176] Jan Peleska and Anne Haxthausen. Formal Development and Verification of a Distrib-uted Railway Control System. In FMERail Workshop #1, volume # 1. FME: FormalMethods Europe, Utrecht, The Netherlands, June 1998.

[177] Jakob Lyng Petersen. Mathematical Methods for validating Railway Interlocking Sys-tems. PhD thesis, Dept. of IT, Techn. Univ. of Denmark, Bldg. 344, DK–2800 Lyngby,February, November 1998.

[178] Carl Adam Petri. Kommunikation mit Automaten. Bonn: Institut fur InstrumentelleMathematik, Schriften des IIM Nr. 2, 1962.

[179] S. Prehn. Distributed Train Time-tables and Dispatching. Technical Report SP/13/2,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], July 1994.

[180] Søren Prehn. PRaCoSy Document Standard. Technical Report sp/4/1, UNU/IIST, theUN University’s International Institute for Software Technology, P.O.Box 3058, Macau;E-Mail: [email protected], October 1993.

[181] Søren Prehn. A Railway Running Map Design. Technical Report SP/12/3, UNU/IIST,the UN University’s International Institute for Software Technology, P.O.Box 3058,Macau; E-Mail: [email protected], July 1994.

204 BIBLIOGRAPHY

[182] Martin Penicka. Dopravni telematika. In Perner’s Contact 2000, page 35. Pardubice:Univerzita Pardubice, 2000.

[183] Martin Penicka. Formalni metody tvorby softwaru v zeleznicni doprave. In Infotrans2003, page 52. Pardubice: Univerzita Pardubice, September 2003.

[184] Martin Penicka. From railway resource planning to train operation. In Formal Methods2005. Newcastle, July 2005.

[185] Martin Penicka. Variety of domain models of railway system functions. In TRainWorkshop at SEFM2005. Koblenz, Septemper 2005.

[186] Martin Penicka, Karel Baudys, and Vıt Janos. Technicka podpora tvorby obehu hnacichvozidel. In Zeleznice na prelome tretieho tisicrocia, pages 295–297. Zilina: Zilinskvzdelavaci servis, 2001.

[187] Martin Penicka and Dines Bjørner. From railway resource planning to train operation.In Building the Information Society., pages 629–636. Norwell, MA: Kluwer AcademicPublishers, 2004.

[188] Martin Penicka, Albena Kirilova Strupchanska, and Dines Bjørner. Train MaintenanceRouting. In FORMS’2003: Symposium on Formal Methods for Railway Operation andControl Systems. L’Harmattan Hongrie, 15–16 May 2003.

[189] Martin Penicka and Miroslav Svıtek. The system model for railway telematics system.In Proceedings of Workshop 2001, volume B, pages 1060–1061. Prague: CTU, 2001.

[190] Wolfgang Reisig. A Primer in Petri Net Design. Springer-Verlag, 1992.

[191] Eugenio Roanes-Lozano, Luis M. Laita, and Eugenio Roanes-Macias. An AlgebraicModel for Decision-taking in Railway Interlocking. In Markus Montigel, editor,FMERail Workshop #3, volume # 3 of FMERail Workshop; St. Polten. FME: FormalMethods Europe, February 17–19 1999.

[192] B. Ropke, W. Seibel, and A. Wozniak. Verification and function test of electronicinterlockings in the system test centre (rail traffic control). Signal und Draht, 87(4):120–2, 1995.

[193] N. Rowden. A safe, reliable control and supervisory system for railway networks. InErwin Schoitsch, editor, SAFECOMP’96: 15th International Conference on ComputerSafety, Reliability and Security, page 266, Vienna, Austria, 1996. Springer.

[194] Jim Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling LanguageReference Manual. Addison-Wesley, 1998.

[195] M. J. Savage. Junction optimisation technique. The Computer Journal, 12(3):268–272,August 1969.

[196] Frank Schulz, Dorothea Wagner, and Karsten Weihe. Dijkstra’s Algorithm On–line:An Empirical Case Study from Public Railroad Transport. Research report, konstanz,1999.

BIBLIOGRAPHY 205

[197] Andreas Sethy. Connection between reliability and signalling-safety in railway technol-ogy. In Reliability and Maintainability Symposium, pages 75–79, Las Vegas, NevadaUSA, 1992.

[198] R.C. Short. Software validation for a railway signalling system. In SAFECOMP’83,pages 183–193. Pergamon Press, 1983.

[199] A. Simpson. A formal specification of an automatic train protection system. InM. Bertran M. Naftalin, T. Denvir, editor, FME’94: Industrial Benefit of Formal Meth-ods, pages 602–617. Springer-Verlag, October 1994.

[200] A.C. Simpson. Model Checking for Interlocking Safety. In FMERail Workshop 2, ParksRoad, Oxford OX1 3QG, UK, 1998. Oxford Univ., Computing Lab.

[201] A.C. Simpson, J.C.P. Woodcock, and J.W. Davies. The mechanical verification of SolidState Interlocking geographic data. In L. Groves and S. Reeves, editors, Proceedingsof Formal Methods Pacific, pages 223–242, Wellington, New Zealand, 9–11 July 1997.Springer–Verlag.

[202] Jens Ulrik Skakkebæk. A Larger Case Study: Railway Crossing, volume I., chapter 7.Dept. of Computer Science, Techn. Univ. of Denmark, 1992.

[203] Albena Kirilova Strupchanska, Martin Penicka, and Dines Bjørner. Railway Staff Ros-tering. In FORMS2003: Symposium on Formal Methods for Railway Operation andControl Systems. L’Harmattan Hongrie, 15–16 May 2003.

[204] Miroslav Svıtek, Frantisek Kopecky, and Martin Penicka. Systemovy model inte-grovaneho zeleznicniho telematickeho systemu. In Zel 2000, pages 179–185. Zilina:Zilinska univerzita, 2000.

[205] Miroslav Svıtek, Frantisek Kopecky, and Martin Penicka. Teleinformatika na prelomustoleti. In T & P. Telekomunikace a podnikani, roc. 4, c. 9, pages 43–45. Praha, 2000.

[206] Miroslav Svıtek, Frantisek Kopecky, and Martin Penicka. Inteligentni dopravni systemyv dopravne-telekomunikacnim prostredi CD. In Zeleznice na prelome tretieho tisicrocia,pages 150–160. Zilina: Zilinsky vzdelavaci servis, 2001.

[207] Lajos Takacs. On a probability problem connected with railway traffic. Journal ofApplied Mathematics and Stochastic Analysis, 4(1):1–27, 1991.

[208] K. Tsiflakos and D. B. Owen. A graphical sytem for the interactive visual modelling ofrailway transportation layouts. In COMPUGRAPHICS ’91, volume I, pages 409–418,1991.

[209] W.M.P. van der Aalst and M.A. Odijk. Analysis of railway stations by means of intervaltimed colored Petri Nets. Real-Time Systems, 9(3):241–263, 1995.

[210] M. C. VanWezel, J. N. Kok, J. VanDenBerg, and W. VanKampen. Genetic improvementof railway timetables. In Y. Davidor and H.-P. Schwefel, editors, Parallel ProblemSolving From Nature – PPSN III, volume 866 of Lecture Notes in Computer Science,pages 566–575, Berlin, 1994. Springer Verlag.

206 BIBLIOGRAPHY

[211] Kirsten Winter. Model checking railway interlocking systems. In Proceedings ofthe twenty-fifth Austral–Asian Conference on Computer Science, pages 303–310, Dar-linghurst, Australia, 2002. Australian Computer Society, Inc.

[212] T. Wood. Living with complexity (in railway software engineering). In Living withMicroprocessor Controlled Traction Systems, IEE Colloquium (Digest No.056), pages3/1–4, 32 pages. IEE, 1990.

[213] J. Woodcock. A CSP Model of the Alcatel Dwarf Case Study. In Thierry Lecomteand Peter Gorm Larsen, editors, FMERail Workshop #5, volume # 4 of FMERailWorkshop; Toulouse, France. FME: Formal Methods Europe, Steria, France, September22–24 1999.

[214] Dong Yulin. Centralized Traffic Control. Technical Note dyl/10/1, UNU/IIST, the UNUniversity’s International Institute for Software Technology, P.O.Box 3058, Macau; E-Mail: [email protected], November 1993.Extracted from Railway Technical English.

[215] Dong Yulin. Train Running Map. Technical Note dyl/8/1, UNU/IIST, the UNUniversity’s International Institute for Software Technology, P.O.Box 3058, Macau; E-Mail: [email protected], October 1993.

[216] Dong Yulin and S. Parthasarathy. Railway Bibliography. Technical Report dyl/11/5,UNU/IIST, the UN University’s International Institute for Software Technology, P.O.Box3058, Macau; E-Mail: [email protected], March 1994.

[217] Chaochen Zhou and Michael R. Hansen. Duration Calculus: A Formal Approach toReal–time Systems. Monographs in Theoretical Computer Science. An EATCS Series.Springer–Verlag, 2004.

[218] Chaochen Zhou, C.A.R. Hoare, and A.P. Ravn. A Calculus of Durations. InformationProc. Letters, 40(5), 1992.

[219] Michael Meyer zu Horste. Modelling and Simulation of Train Control Systems withPetri Nets. In FMERail Workshop #3, volume # 3. FME: Formal Methods Europe,February 1999.

martin p•eni•cka towards a theory of railways - cvut.czvdts.fd.cvut.cz/penicka_towards a theory...

Documents