1
Large scale simulations of Railroad Nets
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
Precise Modeling and Analysis,
Department of Informatics, University of Oslo
Summary. In this paper we will describe our experiences with modelling and simulating realistic railroad systems, based on component-oriented Petri Nets. Several
libraries of railroad components are presented, including nets permitting the train
to control the routers in the net. Petri Nets are translated into Maude in an automated way, and executed by the Maude interpreter. Since railroad models are large,
the time and space complexity of executing them are challenging. Maude is able
to execute the nets with a realistic number of trains fast enough to accommodate
industrial requirements. As a case study, the entire Oslo Subway System is modeled
including every line, turnout and track-section, and executed with as many trains
running concurrently as in the real subway.
Keywords: Railway systems, Petri Nets, simulation, Maude.
1.1 Introduction
Railway systems and subway systems in particular is getting increasingly important for the transportation infrastructure both inside cities and between
cities in Europe: Railway systems are serving growing populations with minimal pollution on communication critical areas A railway system is a large
concurrent system, a system that has a potentially complex total behavior.
The scientific litterature on railway modelling has focused on the safety aspects of railway systems like signal systems and collision detection. Although
major accidents still occur, there are other aspects of railway systems that
are unresolved or poorly supported by the current railroad software. The purpose of this paper is to investigate and solve problems that subway companies
struggle with:
•
•
The estimation of time-schedules is very expensive and time consuming.
Traffic analysis is difficult to analyse due to the large number of trains on
the rail, and the varieties of unforeseen events that might occur.
2
•
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
Train planning, that is to monitor and schedule the optimal route for trains
so that the travelling overhead every morning is minimized is reported to
be difficult.
Since the common modeling and analysis tools failed to handle (even import)
the large Petri Net models constructed for real systems, it turned out to be a
great challenge even to be able to execute railroad nets.
There are several reasons why it is beneficial to model railway systems using Petri Nets: First, since Petri Nets have a precise mathematical semantics,
the behaviour of the railroad nets can be interpreted rigorously. A railway
system is a large concurrent system, it has a potentially complex total behavior. The true concurrency paradigm of Petri Nets naturally fits the true
concurrency of railway systems. Second, since Petri Nets also might be represented graphically it is comprehensible to model railroad component and
discuss their operation with railroad engineers that are not necessarily experts in computer science. The movemement and control of the trains in a
railroad net have natural counterparts in Petri Nets: Trains are modeled as
tokens, tracks are represented by places. Transitions connect places, they move
trains on the tracks. In contrast to event-based modelling paradigms, a Petri
Net model always contain explicitly the state of the railway system, positions
of trains, direction of turnouts etc. Since the state of the total system is available directly through the current marking, Petri Net based railroad models
might be used as the basis for software for monitoring, simulating and analysig
traffic flow.
Our apprach is strictly component oriented : The Petri Net model corresponds naturally to the physical railroad components, the tracks routers, and
point machines. The component oriented approach supports reuse, refinement,
and formal analysis. Railroad systems involve multiple compositions of the
same components, in particular track components, and turnouts, hence reuse
is an inherent property of railway models. The basic railroad components
correspond to physical railroad components, like turnouts, crossings, double
slips, etc. A set of such components forms a library of components. A library
characterize a particular aspect of a system, like safety, collision detection,
routers controlled by trains, various notions of time, and sensitive nets. Petri
Nets might be analysed in an automated way or by hand. Since the railroad
nets are big, analysis using the occurence graph soon gets unfeasible. The
component oriented approach entails that components might be analysed in
isolation, and since composite nets are well-definert by strict rules of composition, properties might be proven by induction on the number of connections
between components.
In several papers ([1], [2], [3]) we have investigated the advantages of using Petri Nets as a modeling language for railway systems. We focused on
the structure of the railroad layout and how the libraries of components are
related to each other through a relation of syntactic refinement. The railroad
layout serves as a specification layer, and basic railroad-net components are
1 Large scale simulations of Railroad Nets
3
constructed using Colored Petri Nets. The composition of basic components
may form larger railroad nets. A large scale Petri Net model of the entire
Oslo Subway system is generated from the high level specification in a fully
automated way.1 The Petri nets are then automatically translated into Maude
code. Although, the entire Petri net model of a railroad system is large, the
initial investigations show that Petri Nets can be beneficial for real railroad
software. We give the first practical and large example of how the Maude
interpreter can be used to execute translated Petri Nets in a successful way.
In this paper we describe our experiences with simulating trains on a
realistic model of the Oslo Subway. We give detailed measurements by metrics
both in the size of the net and the number of trains on the line. Since Railway
systems are large concurrent systems any simulator must confront problems
related to computation time and memory usage. Feasible simulations require
careful design of the railroad models and the underlying execution structure.
The primitive railroad components are modeled as Petri Nets, and can be
units for constructing complete railroad models. We expected that when the
structural complexity of the basic railroad net increased, it would have a direct
impact on the memory needed to represent the model and the time it would
take to run simulations with several trains in the model. Surprisingly, the
requirements on time did not conform to our initial expectations, as will be
discussed in Section 1.6.
At the moment the standard Petri Net tools fail to support industrial
applications of railroad models. Editing nets becomes infeasible because
•
•
•
the size of railroad nets exceeds the allowed usage of memory,
the execution time for well known tools like Design/CPN2 and Renew3 are
are not applicable even for medium-sized railroad nets, and finally
although the most famous current CPN tool, CPN Tools has primitives
for communication, the setup is constructed in a rather inconvenient way,
since communication must be hard-coded into the arc inscriptions [4].4
Maude was chosen as the execution language for the railroad models for
several reasons. First, the translation from textually represented Petri Nets
into Maude can be done in an automated way, as we shall see in Section 1.4.
Second, Maude executes the generated specifications directly and efficiently.
Finally, Maude permits the user to search in the state space from a given initial
state, since it has a built-in model checker. Hence computerized analysis of
the behavior of the models (in Petri Nets terminology; occurrence graphs) is
a feature we get for free.
This paper is organized as follows: Section 1.2 gives some technical background by introducing the appropriate class of Petri Nets, and gives a short
1
2
3
4
This process is called saturation, the algorithm and its correctness is explained in
detail in [3].
See http://www.daimi.au.dk/designCPN/.
See http://www.renew.de.
See http://wiki.daimi.au.dk/cpntools/
4
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
introduction to Maude. The railroad components can be mapped into Petri
Nets, as exemplified by the turnout component and its various refinements
in Section 1.3. The translation from Petri Net into Maude, is illustrated in
Section 1.4 by the turnout component, in addition to a discussion of the
computational complexity of simulations. The architecture of the simulator is
presented in Section 1.5. In Section 1.6, a case study involving three parts of
the Oslo Subway is considered. Finally, we give a survey of the related work
in Section 1.7, and evaluate our approach in the conclusion, Section 1.8.
1.2 Technical preliminaries
In this section some technical preliminaries are given, a brief definition of
Petri Nets, and a short explanation of Maude. If S is a set, then |S | measures
the size of S. A multi-set Z is a pair Z xA, f y, where A is a set and f is
a function f : A ÞÝÑ . The size of a multi-set Z, denoted |Z |, is given by
aPA f paq.
°
N
1.2.1 Petri Nets
Petri Nets can be roughly classified into colored and uncolored nets. This
paper uses Colored Petri Nets [5] (CPN). Since the complete definition of
CPN is rather long we present a minimal toolbox of concepts necessary to
understand the models presented in the paper. A Petri Net N is a triple,
N xP, T, Ay, such that P is a finite set of places, T is a finite set of transitions
and A is a finite set of arcs, A „ pP T E q Y pT P E q, where E denotes
a set of expressions that can be boolean, assignments and time inscriptions.
Composite expressions are permitted only as conjunctions. The preset of the
transition t, denoted t, is the set of places with arcs pointing at t. The
postset of the transition, denoted t is the set of places with arcs starting
from t. Places may contain tokens, that have a particular color. Informally a
transition is enabled if A marking is a distribution of tokens over places. A
net N is 1-safe if the places in N contain at most one token in any reachable
marking. A transition t is enabled in a marking M if every input place p in
t contains at least one token o such that for the arc xp, t, ey, the expression e
is true for the token o. Expressions on the arcs determine the routing of the
tokens and possibly update values in tokens that moves. Enabled transition
may fire. When a transition fires, one token from each place in t is removed
and one token is added to each of the output places in t . In timed Petri nets
a global clock is introduced. The arcs may have time inscriptions. Such time
inscriptions are denoted @ x, which means that the tokens lead by the arc
will be available x time steps after the firing of the transition.
1 Large scale simulations of Railroad Nets
5
1.2.2 Maude
Maude is a functional language based on rewriting logic. In rewriting logic
the basic axioms are rewriting rules of the form l : t Ñ t1 , where t and t1 are
expressions in a given language, and l is a label. Computationally the rewrite
rule l : t Ñ t1 is interpreted as a local transition in a concurrent system; that
is, t and t1 describe patterns for fragments of the distributed state of a system,
and the rule explain how a local concurrent transition can take place in such
a system, changing the local state fragment from an instance of the pattern t
to the corresponding instance of the form t1 . The rest of the system remains
unchanged, see [6].
A typical Maude program contains functions, equations and rewriting
rules. Equations should always be confluent and terminating. In Maude functions are declared recursively by equations, for more details see [7]. Maude has
no pointers or aliasing and thereby no side-effects. Hence both local and global
properties can be proved by considering each equation or rule independently.
The static parts of a system are described by equations. Equations in
Maude are on the form:
eq t1 = t2 .
The clause means that the term t1 can be reduced to the term t2. The rules
describe the dynamic, or state changing parts of a system, and are written:
rl [label] t1 => t2 .
The sentence means that “the term t1 is rewritten to the term t2 in one rewrite
step”. The name label denotes the name of the rule.
When a Maude module is executed, all equations are applied as long as
possible. Then one rewrite rule is applied once. This is called a rewrite step.
A module may either be executed until a final state is reached or for a given
number of rewrite steps.
1.3 Mapping railroad components to Petri Nets
In this section we present a selection of the basic railroad components modeled
as Petri Nets presented in [2]. The modeling principles and the mapping of the
railroad components are illustrated by two important components: the track
segment and the turnout component. The track segment is a simple straight
or curved line as depicted in Figure 1.1. The turnout component is equipped
with movable points and makes it possible for trains to be routed to either of
two tracks whenever they enter the component from the stem. This routing is
determined by the positions of points which are often operated automatically
by a point machine [8]. The turnout is an example of a component called a
router, since there are more than two entrances into the component. Both the
track segment and the turnout are referred to as atomic components.
6
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
Guiding rail
Frog
Point machine
Fig. 1.1. The track segment (left) and the turnout component (right).
1.3.1 The basic Railroad Nets
The railroad components are equipped with an initial marking, consisting
of system tokens, such as semaphores and information carriers. In order to
perform simulations, tokens representing trains must be added to the nets (the
places). This process is called preparement. Figure 1.2 shows a prepared Petri
Net model of a track segment5 . The two places Left and Right are representing
the left and the right end of the track segment. The places are named after
their orientation on the page (up, down, left or right). A transition moves
train tokens between the two places, dependent on the direction of the train.
The direction from left to right is referred to as the positive direction, and
the opposite direction is called the negative direction.
train(+)
move +
train(+)
Left
TOKENS
Right
+
+
train(−)
move −
Train in +direction
train(−)
Fig. 1.2. A Petri Net representation of a track segment.
Figure 1.3 shows a Petri net model of a turnout component. The turnout
consists of two track segments (as in Figure 1.2), with left places merged,
and a point machine. If the point machine was omitted, it would be arbitrary
which way a train took from the left place if it was going in the positive
direction. The semaphores of the places Up and Down keeps track of the state
of the turnout. The point machine can be operated by inserting a semaphore
token to the Change place. Then either the SetUp transition or the SetDown
transition is enabled. The firing of one of these transitions will always change
the state of the turnout.
5
For convenience every atomic component in the paper is prepared with trains,
although the libraries themselves are unprepared.
1 Large scale simulations of Railroad Nets
train(−)
train(−)
move −
sem
train(+)
Upper
Right
train(+)
move +
The point machine
Up
sem
Left
sem
sem
setDown
sem
sem
+
Down
sem
train(−)
move −
sem
Change
sem
setUp
train(−)
TOKENS
Semaphore
Right
Upper
sem
train(+)
7
+ Train + dir.
move +
train(+)
Fig. 1.3. A Petri Net representation of a turnout.
There is only one enabled transition in Figure 1.3, the UpperMove transition. If this transition fires, the train token is consumed from the Left place
and the semaphore token from the Up place. Furthermore, a train token is
added to the UpperRight place and a semaphore token to the Up place. This
simulates that a train has moved to the left in a turnout segment.
The net of Figure 1.2 and Figure 1.3 are examples of the most abstract
implementation. These nets are denoted the basic atomic railroad nets. The
basic railroad nets have a relatively simple, yet unrealistic behavior. The trains
have a direction, but lack traveling plans. Two trains may pass each other on
a single track, and they may be at the same position at the same time.
A common phenomena in railroad system, is the problem whether trains
might run over turnouts the wrong way. If we consider the state of the
turnout in Figure 1.3, this situation occurs if there is a train token in the
place LowerRight travelling in the negative direction, towards the place Left.
In some turnouts it should be possible for the wheels of the train to push
train(−)
train(−)
Upper
Move −
train(+)
Intended route
Upper
Right
train(+)
Upper
Move +
sem
Train
TOKENS
Left
Up
−
Direction
sem
Change
setUp
train(−)
Lower
Move −
sem
Point machine
train(+)
sem
sem
Train (− dir.)
train(−)
setDown
sem
Down
Points
sem
Semaphore
Lower
Move +
sem
Lower
Right
−
train(+)
Fig. 1.4. A train running over a turnout
the movable point without destroying the movable points. The component in
Figure 1.3 does not permit trains to run over it. A turnout that permits trains
8
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
to run over, might be obtained by just removing the each of the arcs between
the move transition UpperMove and the place Up, and the arcs between
the move transition LowerMove and the place Down. Components with this
behaviour is denoted relaxed routing components.
1.3.2 Refining the atomic components as Petri nets
In order to give the railroad nets more realistic behavior, they can be refined.
Refinement is considered a purely syntactic transformation [3]. Informally a
net N2 is a refinement of a net N1 , if N2 contains more elements, for instance
new places, transitions, or arcs, additions of arcs inscriptions, guards or even
new tokens. All the simulations considered in this paper are carried out with
components of the particular refinement described in this section. Figure 1.3
might be considered to be a refinement of the relaxed routing turnout. The first
refinement of the basic components we consider is the safe-control refinement.
A complete survey of the atomic components used in the modeling of Oslo
Subway, as well as the Petri net mapping can be found in [3]. The net is safe,
and the trains are equipped with train routes. The railroad nets are equipped
with an initial marking where every track place is inhabited with a noTrain
token. The preparement of the safe-control refinement consists in eliminating
each noTrain in a track place where the user of the simulator puts a Train
token. The track segment in Figure 1.5 introduces noTrain tokens, which have
noTrain
train(+)
move +
noTrain
train(+)
TOKENS
Left
Right
No train
+
train(−)
noTrain
move −
train(−)
noTrain
+
Train in +direction
Fig. 1.5. The refined track segment
two effects: First, two trains are not permitted to inhabit the same place at
the same time. This is because in order to move the train from the left place
to the right, there has to be a noTrain token present in the Right place. The
only condition is that the initial marking always has exactly one token in all
train-carrying places. Second, the noTrain token ensures that two trains may
no longer pass each other on a single track.
Figure 1.6 shows a safe turnout component from the safety-library (the
track depicted in Figure 1.5). This component is built up of two track segments, and a point machine. One of the new features of this component is the
SwitchId place. This place has a token containing a unique id for this router.
The trains now have a travel plan that consists of a list of pairs of Switch ids,
and directions. If a train has the pair (3, left) in its travel plan, it means that
the train should go left in the router with id three. Note that the transition
1 Large scale simulations of Railroad Nets
noTrain
train(−)
Upper
move −
sem
[(id, left)]
Upper
move +
sem
id
train(+)
noTrain
train
setDown
Left
+
noTrain
train(−)
9
Upper
Right
train(+)
noTrain
train(−)
sem
Up
sem
sem
sem
[(id, left)]
train(+) train
setDown
id
[(id, right)]
train(+) train
setUp
id
sem
setDown
sem
sem
Change
sem
sem
sem
sem
Down
sem
setUp
sem
sem
train
setUp
noTrain
train(−)
train(−)
TOKENS
sem
Lower
move −
id
train(+)
noTrain
noTrain
train(−)
Semaphore
Switch id
No train
sem
Lower
move +
[(id, right)]
train(+)
noTrain
+
Train in +direction
Lower
Right
Switch
Id
Fig. 1.6. The train-controlled turnout
that moves a train from the left place has a guard. The guard of the place
leading a train to upper right place is: rpid, leftqs. This evaluates to true if the
pair pid, leftq is present in the travel plan of the passing train. The guard prevents the trains from going the wrong way in this turnout. The purpose of the
train setUp and train setDown transitions is to prevent trains from stopping if
they reach a router which is in the wrong position, and instead changing the
state of the turnout.
1.3.3 A livelock in the turnout
A problem with this approach is that livelocks might occur. Figure 1.7 shows
the marking in a turnout causing a possible livelock. In this marking the
UpperMove transition, and the upper trainsetDown transition are enabled.
If the move transition fires, the upper train moves to the Left place, and
the livelock is resolved. If the trainsetDown transition fires, the state of the
turnout is changed. Now the lower trainsetDown and the LowerMove are
enabled. Again the firing of the move transition solves the problem, but the
firing of the lower trainsetDown results in the marking in Figure 1.7 again.
The livelock is resolved assuming strong fairness: if a transition t is enabled
infinitely many times, t will fire infinitely many times. This ensures that one
of the move transitions eventually fires and resolves the livelock. In Maude a
notion of fairness is obtained by using the frew command, since frew ensures
that the the rule-matching of terms occurs on the whole term in a fair way.
10
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
noTrain
train(−)
Upper
move −
sem
noTrain
train(−)
Upper
Right
−
[(id, left)]
Upper
move +
sem
id
train(+)
noTrain
train
setDown
Left
train(+)
noTrain
train(−)
sem
Up
sem
sem
sem
[(id, left)]
train(+) train
setDown
id
[(id, right)]
train(+) train
setUp
id
sem
setDown
sem
sem
Change
sem
sem
sem
sem
Down
sem
setUp
sem
sem
train
setUp
noTrain
train(−)
train(−)
sem
Lower
move −
id
train(+)
noTrain
noTrain
train(−)
−
sem
Lower
move +
[(id, right)]
train(+)
noTrain
Lower
Right
Switch
Id
Fig. 1.7. The livelock situation
The livelock could be eliminated by letting the train change the state of the
turnout and move in the same operation. However, the two operations are kept
separate in the model, since the operations is separate in real systems. Note
that the existence of a livelock in a safe safe-control component corresponds
to a potential crash in a net permitting collision detection!
1.3.4 Collision detection
In history there has been many accidents on railway and subway systems.
Serious train accidents are rare but catastrophical, typically with loss of many
lifes and total damage of very expensive equipment. In the Åsta accident
occuring 13:12:35, 4 january 2000 in the central part of Norway, 19 people
where killed, due to failure in the safety system. Large train accidents still
occur throughout the world due Hence an crucial aspect in a railroad model
is collision detection. In order to examine wether trains can collide or not, the
model should be able to let trains crash. We have already demonstrated (in
Figure 1.5) the safe components, where trains cannot pass each other on the
same track.
The collision detection component can be explained as follows: Three kind
of tokens are involved in the net; Train, noTrain and alarm tokens. The directions of the trains are extended to include the state collided, (C), meaning
that the train is not moving and is malfunctioning. If two trains crash, they
are stopped and placed in the corresponding places. If the track places are
1 Large scale simulations of Railroad Nets
noTrain
move +
Left
train(+)
11
noTrain
train(+)
Right
+
train(−)
train(−)
move −
noTrain
noTrain
train(C)
No train
train(C)
crash
FF
train(+)
TOKENS
+ Train
train(−)
Alarm signal
alarm
train(C)
train(C)
crash
CR
alarm
Alarm
alarm
crash
LC
train(C)
train(C)
train(C)
train(C)
train(−)
train(+)
Fig. 1.8. The track segment with collision detection
not initially prepared with noTrain tokens, then the move transition would
compete with the crash transition, causing trains to pass each other without
any alarm signal. Collisions are of two kinds, either two trains collide front-tofront (corresponding to the transition CrashFF), or a train runs into an already
trained vehicle (corresponding to CrashCR and CrashLC). The place Alarm is
initially empty, and when a crash occurs, it gets an alarm token. Alarm is an
input/output place, that is if the model is used as the basis for a real railroad monitor, then Alarm would typically cause an event in the embedding
software.
1.3.5 Modeling time in railway systems
Time is an important aspect of railroad modeling. There are many ways of
introducing time to the system. In this paper we will explore components with
constant delays. A constant delay means that all trains will need the same
amount of time to drive the same stretch. This is a simplification of the real
world, but an important step towards lifelike behavior. Figure 1.9 shows the
track segment with constant delay. Trains that runs trough this component
will receive a delay of one time unit. The noTrain token will also receive the
same delay. This means that a place, left by a train, will be occupied until the
train has arrived at another place. A more complex time concept is explored
in [9]. Here the delays are calculated as a function of the length of the stretch,
the speed limit, the trains entry speed etc.
12
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
noTrain @ + 1
Left
move +
noTrain
train(+) @ + 1
train(+)
Right
+
train(−) @ + 1
train(−)
move −
noTrain
noTrain @ + 1
Fig. 1.9. The track segment with constant delay
1.4 Translating Petri Nets into Maude
There are several ways to translate a colored Petri net into a Maude module.
Ölveczky [10] suggests a translation where all the tokens with their position are
stored in a set. In the set-marking we delegate the control of the execution to
the built-in pattern matching of Maude. The declaration of the initial marking
of the Petri Net in Figure 1.6 will be:
eq initMarking = Left(train(+))
UpperRight(noTrain) LowerRight(noTrain)
Up(sem) SwitchId(id3) .
For instance the term Leftptrainp qq means “the place Left, contains the token
trainp q”, that is, Left contains a train-token heading in the positive direction.
Each of the transitions naturally translates into a rewrite rule. For instance
the UpperMove transition will become the rule:
rl [UpperMove -] :
UpperRight(train(-)) Left(noTrain) Up(sem)
=>
UpperRight(noTrain) Left(Train(-)) Up(sem) .
The rule above is enabled if the current marking contains at least one occurrence of each of the three tokens in the left hand side of the rule. If the rule
is executed, each of the tokens on the left hand side is replaced by the tokens
on the right hand side of the rule.
1.4.1 Computational complexity
In this section we discuss the computational cost of the Maude modules both
with respect to time and space. The file-size of a Petri net N xP, T, Ay
stored as a Maude module will be a linear function, given by
|P | |T | |A| |tokens|,
where |tokens| counts the number of tokens in the net. Since the Petri nets
are 1-safe there is never more than one arc from a place to a transition and
each arc always carry one token. Hence the transition t consumes exactly | t|
tokens when it fires.
1 Large scale simulations of Railroad Nets
13
In order to determine whether a given transition t is enabled, it is necessary
to search through the tokens of the marking for each of the tokens in t to
see if there is a matching rule. Thus as many as
|tokens| | t|
(1.1)
tokens must be examined to decide whether t is enabled or not. In the Petri
Net N , the number of tokens that must be checked in order to determine
whether any transition is enabled, is given as the sum of expression (1.1) for
all transitions t P T :
|tokens| | t|
(1.2)
¸
tPT
Note that for every t, when two railroad nets are connected to each other | t|
will not increase, hence | t| is independent of the size of the railroad.
1.5 The architecture of the simulator
In this section we outline the main design of our tool initiated by [2]. RWSEditor, as presented in[11], is an editor for fast construction of large scale railroad
models based on Petri Nets. The nets are composed in a strict componentoriented way through clearly specified interfaces. A high level specification
language permits the user to draw the complete circuit of a railroad, then
based on a library of Petri Net implementations of the atomic components as
described in Section 1.4, the entire Petri Net model is generated fully automated. We have revised the RWSEditor to also show Maude’s results of an
execution of a large scale railroad net, as described in Figure 1.10, also called
simulations: A finite railroad simulation is a finite sequence of states from a
given initial state to an end state. A finite railroad simulation is an off-line
simulation if the user of the simulator only knows explicitly the initial state
and the final state. A railroad simulation is called on-line if the simulation
provides information about each state in the simulation.
The system involves several modules as shown in Figure 1.10. Processes are
drawn as rectangles. Events of a process are drawn in the order they occur,
with the first event at the top. Files and data structures are drawn with
dotted lines. The arrows represent the saving and loading of files, and sending
and receiving data streams. Autorefine is a program that semi-automatically
refines railroad nets. Principles of refining tracks are written by hand, and
then Autorefine traverses a given library automatically in order to produce a
complete refined library [3]. RWSEditor lets the user design a specification of
the railroad layout and associate the interfaces in the specification with the
interfaces of the atomic Petri nets. The module Xml2Maude translates a Petri
net into a Maude module in an automated way. The programs are connected
by the script rws-sim.
RWSEditor is used to draw a specification such as the downtown layout
in Figure 1.12. On the basis of the specification and the refined atomic Petri
14
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
refined
atomic
CPNets as
xml files
Autorefine
save
read
refine
atomic
CPNets as
xml files
save
Design/CPN
draw
atomic
CPNets
Xml2Maude
get
RWSEditor
draw
specification
send
read
compile
composite
CPNets as
xml element
send
Saturate
rws−sim
send
sim komand
Show results
from the
simulation
send
results
get
send module &
sim komand
get
results
composite
CPNets as
maude module
Maude
simulate
Fig. 1.10. The process flow of an on-line simulation.
net components previously constructed [3], a complete Petri net of the entire
railroad is generated in a fully automated way. The process involves connecting the interfaces of the specification with places of the atomic Petri nets,
whereby RWSEditor automatically constructs a large Petri net of the entire
specification. This large net could either be saved to a file or sent directly
to Xml2Maude. In the latter case the Petri net is converted to executable
Maude. This module will be sent to Maude which executes the net, and the
result will be sent back to RWSEditor, which shows the updated position of
the trains.
1.6 Simulation of Oslo Subway
Figure 1.11 shows the current map of lines in Oslo Subway. From the point of
view of simulating the railroad, the size of the data structures and the time it
takes to run several trains may impose hard requirements on the underlying
implementation and hardware, as described in Section 1.4.1. Therefore, the
subway was initially broken into smaller pieces, to explore how memory-usage
and execution time depended on the size of the net.
The Figure 1.12 shows a typical technical drawing, a railroad engineering
specification of the subway of downtown Oslo, the track from Majorstuen to
Grønland. This part of the line is very important and safety critical, since
trains from every line drive on the same track under the ground. Traffic jams
are likely to happen, since the interval between the trains can be as low as
90 seconds. If an accident occur, there will soon be a queue of trains influencing the throughput on the complete subway system. The net in Figure 1.12
1 Large scale simulations of Railroad Nets
15
Fig. 1.11. The Oslo subway system.
consists of 93 components; ordinary track segments, turnouts, end segments,
crossings and other components (for more details see [2]).
MAJORSTUEN
STORTINGET
JERNBANETORGET
11
00
GRØNLAND
FRØEN
1
0
Fig. 1.12. The downtown fragment of Oslo Subway.
Three parts of the Oslo subway system have been constructed by Petri net
components as for instance the turnout in Figure 1.6. The smaller of the three
is the downtown part from Majorstuen to Grønland. The downtown segment
was then extended from Kolsås to Bergkrystallen, to form a complete line, line
4 in Figure 1.11. Finally the entire system was constructed. Table 1.1 shows
the sizes of the Petri nets both in components and file sizes
Segment
Places Transitions Arcs
Majorstuen 242
Grønland
Kolsås 885
Bergkrystallen
The whole
2067
system
Petri net Maude module
file size
file size
423
2966 1.2 Mbyte
82 Kbyte
1556
7710 4.3 Mbyte
311 Kbyte
3572
18286 10 Mbyte
728 Kbyte
Table 1.1. Size of the simulated segments
16
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
Maude was used to execute the nets with a variable number of trains. In all
simulations involving more than one train, the trains were evenly distributed
in the net and among the lines.
1.6.1 Off-line simulation
Initial executions in Maude was performed from a command prompt, with no
graphical output. One rewrite step corresponded to the firing of one transition
in the Petri net. In practice this means that one train moves one step ahead or
that a train changes the state of a point machine. Then Maude executed the
net until a final state was reached. The execution corresponds to a simulation
where all the trains will move as far as they can. The travel plans in the
simulated nets are defined as one journey from one end station to another end
station. The trains moved until they reached an end station or their running
track was blocked by another train. In such cases the net reaches a final
marking.
Table 1.2 shows how long time Maude used to execute the net as far as
possible. It also shows how many rewrites Maude used to reach a final marking.
The final row in Table 1.2 shows that simulating 32 trains in the complete
railroad net results in 35630 rewrites in order to reach the final marking.
number Simulation time number
of trains
(millisec.)
of rewrites
1
900
1708
Kolsås 4
910
11184
Bergkrystallen
16
920
32253
32
980
39308
1
4210
1614
4
4070
5779
The whole system
8
4030
10100
16
3960
37793
32
3620
35630
segment
Table 1.2. Experiments on off-line Simulation.
At first glance, the data received from the simulations seems to be counter
intuitive. As more trains were added, the simulations ran faster. One should
expect that an increase in the number of trains caused an increased number
of rewrites. The reason is that the number of tokens in the system is not
influenced by the number of trains. Each train token added to the net will
replace a noTrain token. If the number of trains on the line is increased, more
transitions are enabled during execution, which will decrease the time it takes
to find an enabled transition.
1 Large scale simulations of Railroad Nets
17
1.6.2 On-line simulation
Fig. 1.13. Screenshot of RWSEditor.
The three segments described above were also simulated on-line. Figure 1.13 shows a screen-shot of one of these simulations. All three nets were
executed with a various number of trains, and by the following three patterns:
piq one hundred steps, showing all intermediate steps, piiq one thousand steps,
showing every tenth step, and piiiq as long as possible, showing only the final
step. The execution times of the simulations are displayed in Table 1.3. The
values in the table are average values per shown step, measured in milliseconds. The on-line simulations considering the downtown part of the system
Average simulation time (millisec.)
number 100 steps 1000 steps all possible steps
of trains show all every 10’th
only final
Kolsås
1
2879
1
0
10
2387
1
0
Bergkrystallen
30
1264
0
0
The complete
1
13435
1614
335
Oslo Subway
10
13169
1337
40
system
30
12413
0
0
Sample of lines
Table 1.3. Simulations with untimed nets.
were so fast that the times where not measurable, and is therefore omitted
from the table. As for the off-line simulations, the simulation times decreased
as the number of trains increased.
We added a constant delay of one time step on all track transitions, as
shown in Figure 1.9. The entire Oslo Subway was simulated with these components. We simulated the net for fifty time steps. In one time step, all trains
18
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
Sample of number of number of number of simulation time
lines
trains
time steps rew. step per time step
The complete
1
50
98
141691 ms
Oslo Subway
10
50
545
22042 ms
system
30
50
1528
66089 ms
Table 1.4. On-line simulations with timed nets.
may move up to one move or change the state of a turnout once. The results
are displayed in Table 1.4. Execution time for one step decreases with the
number of trains, while the number of rewrite steps increases. The number of
rewrite steps is close to a linear function of the number of trains. Simulation
will be much faster if we display fewer intermediate states.
1.7 Related work
Our work is inspired by Wil van der Aalst’s approach to Workflow ([12], [13])
where Petri nets were used to precisely define, simulate, execute and analyze workflows. Aalst work is characterized by first breaking the application
domain workflow apart to find its minimal constituents, then defining the
constituting elements using Petri Nets, and finally he shows how the application domain might be rebuilt using particular classes of Petri Net concepts,
to form the basis for software tools for modeling, simulation, monitoring and
analysis of workflows. The long-term goal of our research is to do the same
for railway systems, decompose the application domain into its constituents
and then show how Petri Nets can be used to enrich the software engineering
of railway systems. A few papers devoted to work on modeling and analyzing
railways using Petri Nets are available ([14], [15], [16], [17], [18], [19]), but the
papers are concerned with modeling and analysis of isolated phenomena. Two
significant papers investigate the scheduling and analysis of movements on
railway stations [20], and optimal behavior on the meeting points on singletrack railways with sidings [21]. Safe control of train movements is investigated
in [22]. A deadlock prevention method is introduced by augmenting railway
network systems with monitor places. Our work differs from the other works
in two respects: The models proposed in this paper are designed bottom up,
and there is a close resemblance between the executable Petri nets and the
actual railroad system.
1.8 Conclusion and future work
One goal of our research is to address Dines Bjørner’s “Grand Challenge
of the Railway Domain”6 , by giving generic components and methods for
6
FMRail at http://www.railwaydomain.org/.
1 Large scale simulations of Railroad Nets
19
construction, analysis and standardization of notation in the railroad domain
[23]. Overall, the initial simulation proves that the approach is promising. A
simulation of the entire Oslo subway system with a realistic number of trains is
possible. Maude used about four seconds to simulate approximately one hour
of real time traffic. The subway is changing in 2006, and a new part called Tbane ringen (subway circle) is augmented to the original lines to give a second
connection between the eastern and western lines. Our initial investigations
shows that traffic jams are likely to happen in the old part of the line where
all the lines are joined on only two tracks.
A lot of potential work grows natural out of our initial investigations. In
the future we are going to explore how the simulation can be made more
realistic and upredictable by adding stochastic delays. It is no surprise that
issues related to time will be of uttermost important to reach results that are
of industrial significance.
The approach taken in the paper maight be applied to other domains, wich
a multiplicity of components of the same kind and with flows of elements in
a fixed structure. One such system is packet delivery through complex yet
wellknown network topology. Other examples include transportation systems
in general like, airport, roads and car traffic.
Acknowledgments
Thanks to Ingrid Chieh Yu, Arild B. Torjusen, Johan Dovland, Wolfgang Leister, Thor Kristoffersen, Bjarte Østvold, Atle Refsdal, Steinar Kristoffersen,
Olaf Owe, Eskil Brun, Dines Bjørner and three anonymous referees for comments on earlier versions of this paper. The authors would also like to thank
Trygve Kaasa, Willy Ulseth and Thor Georg Sælid from Oslo Subway Company, for in-depth knowledge about railroad engineering and for giving us
access to the railroad layouts for Oslo Subway.
References
1. T. Kristoffersen, A. M. Hagalisletto, and H. A. Hansen, “Extracting High-Level
Information from Petri Nets: A Railroad Case,” Proceedings of the Estonian
Academy of Physics and Mathematics, vol. 52, pp. 378 – 393, December 2003.
2. A. M. Hagalisletto and I. C. Yu, “Large scale construction of railroad models
from specifications,” in IEEE SMC’2004. Conference Proceedings 2004 Systems
Man and Cybernetics (W. Thissen, P. Wieringa, M. Pantic, and M. Ludema,
eds.), pp. 6212 – 6219, IEEE, October 2004.
3. A. M. Hagalisletto, J. Bjørk, I. C. Yu, and P. Enger, “Constructing and Refining
Large Scale Railroad Models Represented by Petri Nets,” 2006. Accepted for
publication IEEE Transactions on Systems, Man and Cybernetics, Part C.
4. G. Gallasch and L. M. Kristensen, “COMMS/CPN: A Communication Infrastructure for External Communication with Design/CPN,” in Third Workshop
20
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
Joakim Bjørk, Anders M. Hagalisletto, and Pål Enger
and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools, University of Aarhus, Denmark, 2001.
K. Jensen, Coloured Petri Nets - Basic Concepts, Analysis Methods and Practical Use, vol. 1 of EATCS, Monographs on Theoretical Computer Science.
Springer-Verlag, 1997. Basic Concepts.
N. Marti-Oliet and J. Meseguer, “Rewriting Logic: Roadmap and Bibliography.”
Obtained from http://maude.cs.uiuc.edu/papers/, June 2001.
M. Clavel, F. Durán, S. Eker, P. Lincoln, N. Martı́-Oliet, J. Meseguer, and
C. Talcott, “Maude Manual.” Obtained from http://maude.cs.uiuc.edu/.
J. Pachl, Railway Operation and Control. VTD Rail Publishing, 2002.
J. Bjørk, “Executing Large Scale Colored Petri Nets by Using Maude,” Master’s
thesis, Department of Informatics, University of Oslo, May 2006.
P. C. Ölveczky, Specification and Analysis of Real-Time and Hybrid Systems in
Rewriting Logic. PhD thesis, University of Bergen, 2000.
I. C. Yu, “A Layered Approach to Automatic Construction of Large Scale Petri
Nets,” Master’s thesis, Dept. of Comp. Science, University of Oslo, Sept. 2004.
W. van der Aalst, K. M. van Hee, and G. J. Houben, “Modelling and Analyzing Workflow using a Petrinet based Approach,” in Proceedings of the second
Workshop on Computer-Supported Cooperative Work, Petri nets and related formalisms (G. D. Michelis, C. Ellis, and G. Memmi, eds.), pp. 31–50, 1994.
W. van der Aalst, “The Application of Petri Nets to Workflow Management,”
The Journal of Circuits, Systems and Computers, vol. 8, no. 1, pp. 21–66, 1998.
L. Tang, T. Chen, and J. Xiao, “Analysis of the concurrent model of train station
based on Petri net.,” in Proc. 2000 Int. Workshop on Autonomous Decentralized
Systems, 21-23 September 2000, Chengdu, China, pp. 92–96, 2000.
W. Hielscher, L. Urbszat, C. Reinke, and W. Kluge, “On Modelling Train Traffic in a Model Train System,” in Workshop and Tutorial on Practical Use of
Coloured Petri Nets and Design/CPN, June 8-12, 1998, Aarhus Denmark, 1998.
M. M. zu Hörste, “Modelling and Simulation of Train Control Systems using
Petri Nets,” in FMRail Workshop 3, 1999.
D. Decknatel, “Modelling Train Movement with Hybrid Petri Nets,” in FMRail
Workshop 4, 1999.
G. Malavasi and S. Ricci, “Petri nets theory in the railway signalling models,”
in FMRail Workshop 5, 1999.
W. van der Aalst, K. M. van Hee, and M. Voorhoeve, “The DONS rail scheduling
system,” in 15th International Conference on Application and Theory of Petri
Nets, pp. 1–12, 1994. Case Studies Tutorial.
W. van der Aalst and M. Odijk, “Analysis of Railway Stations by Means of
Interval Timed Coloured Petri Nets,” Real Time Systems, vol. 9, pp. 1–23,
November 1995.
X. Ren and M. C. Zhou, “Scheduling of Rail Operation: A Petri Net Approach,”
in Proc. of 1995 IEEE Int. Conf. on Systems, Man, and Cybernetics, Vancouver,
Canada, Vol. 4, pp. 3087–3092, October 1995.
M. P. Fanti, A. Giua, and C. Seatzu, “A Deadlock Prevention Method for Railway Networks using Monitors for Colored Petri Nets,” in Proc. 2003 IEEE Int.
Conf. Systems, Man, and Cybernetics (Washington, D.C., USA), pp. 1866–1873,
October 2003.
D. Bjørner and M. Pěnička, “Towards a TRain book,” 2004. Technical report,
obtained from FMRail: http://www.railwaydomain.org/.