TrainState : fInit,Start, Stopping, Stopped, Pass, Halt, Slow, Errorg indicates the ..... When a train in mode Stopping crosses the middle of the current track it.
An Astral specification for a railroad controller Report 95-104
Leon Bun Jan van Katwijk
Faculteit der Technische Wiskunde en Informatica Faculty of Technical Mathematics and Informatics Technische Universiteit Delft Delft University of Technology
ISSN 0922-5641
Copyright c 1995 by the Faculty of Technical Mathematics and Informatics, Delft, The Netherlands. No part of this Journal may be reproduced in any form, by print, photoprint, microfilm, or any other means without permission from the Faculty of Technical Mathematics and Informatics, Delft University of Technology, The Netherlands. Copies of these reports may be obtained from the bureau of the Faculty of Technical Mathematics and Informatics, Julianalaan 132, 2628 BL Delft, phone +31152784568. A selection of these reports is available in PostScript form at the Faculty’s anonymous ftp-site. They are located in the directory /pub/publications/tech-reports at ftp.twi.tudelft.nl
An Astral Speci cation for a Railroad Controller Leon Bun and Jan van Katwijk Faculty of Mathematics and Informatics Delft University of Technology Julianalaan 132, 2628 BL Delft, The Netherlands
Abstract
It is generally accepted that development of requirement models for real-time systems bene ts from formal speci cations. In order to be able to evaluate notations for use in the development of real-time software systems, we are performing a comparative review of some selected speci cation notations. The study emphasizes the use of the notations in the domain of real-time (control) applications. Our review will be based on a speci cation from a simple railroad controller model. This case contains data modelling aspects, functional aspects as well as temporal aspects. A (toy) railroad with a computer interface, is available in our laboratory, used for lab assignments. Typical elements to consider are usability with regard to the speci cation in relation to the requirements, and second, usability with respect to further program development. This report discusses the problem as well as a model speci cation, written in Astral. It also discusses veri cation issues using the proof assistant PVS (Prototype Veri cation System).
1 Introduction The common software engineering paradigm contains three steps: analysis of the requirements by constructing an abstract model, designing the architecture, and implementing the system. It is generally accepted that an increased level of formalism in model speci cation contributes to a better understanding of the behaviour of a system prior to its actual construction. In our eld of interest, real-time software systems, many formal and less formal notations were developed during the last few years. We selected a 1
number of them and are improving our understanding of the di erent notations and of the usability of the notations by applying them to a simple case. The case we have chosen is a controller for a simple toy railroad system. Since such systems are visually highly attractive, they are quite popular as a target for education case studies. In our software lab, we use a simple selectrix railroad system as vehicle for assignments and exercises in software construction. The problem was felt suitable as speci cation in a comparative review, since it
contains both data modelling elements and control elements. The rail-
road itself can be considered as a graphical structure. is suciently complex to eliminate the feeling of a toy speci cation/ implementation. This report presents an Astral speci cation of this railroad control system. This speci cation is based on the AEV DM [BBKT94] speci cation of the same system. Speci cations of the problem in other notations, in particular in Mosca[BBKLT94] and Paisley[KT95] are nished. Speci cations in Lustre and TLA[L95] are underway. An additional aspect in this report is the veri cation of an important requirement, namely that two trains will not collide with each other. As the construction of a formal speci cation is dicult and time consuming it seems a waste of time not to check the speci cation on the requirements it has to meet. We use a proof assistant because manual analysis is more error prone. The next section presents a brief description of Astral. Section 3 takes a closer look at the problem we attempt to solve. The problem is partitioned in two parts in section 4 and these parts are speci ed in detail in sections 5 and 6. A re nement of one of these parts is presented in section 7. The global part of the speci cation is given in section 8. Section 9 shows with the help of the proof assistant PVS[OSR93] that the resulting speci cation ensures that no two trains ever collide. Section 10 contains conclusions and directions for future work. It also contains an evaluation of Astral based on the following criteria:
Re nement/Abstraction: Re nement adds more detail to a speci ca-
tion. This is important, because the resulting speci cation will be closer to the eventual implementation language. The smaller gap between 2
speci cation and implementation the easier it is to bridge this gap. Abstraction is the opposite of re nement. An abstraction removes detail and makes the speci cation more clear. This is useful when we attempt to prove global properties of a speci cation. Note that because of re nement and abstraction consistency between di erent levels of speci cations has to be de ned. Composition/Decomposition: Composition allows one to use speci cations of subsystems to construct speci cations of complex systems. Composition also encourages reuse of existing speci cations. Decomposition allows one to divide a complex system into a few hopefully less complex subsystems. Orthogonality(separation of concerns): Orthogonality allows one to separate the functional and timing behaviour of a real-time system. This is important, because it allows one to focus on parts of the speci cation. This could help in the analysis of the speci cation of for example safety properties and deadlock. Usability: The usability aspects of a notation can be divided in three parts. First tool support in the analysis and building of a speci cation of a real time system. Second support in the form of papers and articles on the notation, recommended speci cation method and example speci cations. Third the easiness of specifying a real-time system in a natural way, i.e. is it possible to do so without having to resort to weird or complex constructions.
2 Astral The Astral[GK91] formal speci cation language is based on Aslan[AK85] and RT-Aslan[AK86]. Astral uses a state machine process model and has types, variables, constants, transitions, invariants, and constraints as in Aslan. Like RT-Aslan, Astral uses a collection of Aslan-like state machine speci cations to represent the processes in the real-time system. The semantics of Astral have been formally de ned as a translation scheme from Astral into TRIO. TRIO is a logic language designed at the Politecnico di Milano as a formal notation for specifying and verifying timing requirements [GMM91]. TRIO is a formally de ned language, which means that its proof theory and its executability can be mathematically de ned. 3
Section 2.1 presents the syntax of Astral and some speci cs of the Astral notation. A running example of the TrainMissionControl process type (see also section 6.1) is given to clarify the syntax. The computational model of Astral is given in section 2.2.
2.1 Astral syntax and notation.
In Astral a real-time system is modelled by a collection of state machine speci cations and a single global speci cation. Each state machine speci cation is given as a process type of which there may be multiple process instances in the system. This speci cation consists of the following clauses: type, import, export, variable, constant, initial, invariant, constraint and schedule. This section reviews them one at a time and also presents a running example. Astral is a strongly typed language. Integer ([jnj in this paper), Boolean, ID (the set of of process identi cations) and Time are the only primitive types in Astral. All other simple and constructed types have to be declared in the type section of the process speci cation in which they are used or they have to be declared in the global part of the speci cation and explicitly imported by the process type. The import clause
IMPORT Now, Position, O set, AllocTable, CrashDanger, TC-ID
indicates that the type TC-ID (which has been declared in the global part of the speci cation of the railroad system) is imported to the TrainMissionControl speci cation. The declaration TC-ID : Typedef tid : ID (IDTYPE(tid) = TC)
is a subtype declaration. It declares TC-ID to be exactly those ID that are the ID's of Train processes. The Astral speci cation function IDTYPE returns the type of the process that is associated with the ID. The other importings are variables imported from di erent processes: Now from the global speci cation Position, O set and CrashDanger from the Train process type AllocTable from the ResourceManager Process types may explicitly export state variables and transitions. Exporting a state variable makes the variable readable by other processes. Any process which needs an elsewhere exported variable has to explicitly import it. The 4
TrainMissionControl process has the following exports clause: EXPORT ReqSwitchState, ReqSpeed, ReqDir, CTDist, CI, TMTrack
This exports clause indicates that these six entities are exported. In Astral, states are di erentiated from each other by the values of the state variables. These state variables are referenced to and/or modi ed by the state transitions. All of the state variables must be declared in the variable section of the formal speci cation. In the TrainMissionControl speci cation ten state variables are declared. The rst two declarations ReqSpeed : [jnj ReqDir : fBackwards, Forwardsg
indicate the required speed and direction setting of the associated train. The third TrainState : fInit,Start, Stopping, Stopped, Pass, Halt, Slow, Errorg
indicates the TrainMissionControl view of the mode of its associated train. The last WaitFor : T rackI D
represents the track TrainMissionControl is waiting for, when the TrainState equals Slow or Halt . Constants in Astral are state variables of which the value cannot change over the lifetime of the system. These constants T4, : : : T13 : Time
are used such that each of them equals the amount of time required for the execution of a particular transition within the TrainMissionControl process. The constant Own : TC-ID
indicates the id of a particular Train process that is associated with the TrainMissionControl process. The constant TMCommand : seq of fStart, Stop, Pass, Initg
represents the sequence of commands that the TrainMissionControl process tries to execute. For a real-time system there are two types of critical constraints on the behaviour of the system: behaviourial and temporal. In Astral, the behavioural constraints for a process are expressed in the initial, invariant and constraint clause, while the temporal constraints are expressed in the schedule clause. The initial clause of a process speci cation expresses the restrictions on the initial state of the process type. That is, for each state variable it is 5
necessary to express the restrictions that are to be placed on its initial value. Two of the initial constraints in the TrainMissionControl speci cation are CI = 1 ^ TrainState = Init
These constraints indicate that the variable CI (a pointer to the command to be executed next) should have '1' as its starting value and that the initial value of TrainState should be equal to Init. The invariant clause expresses the critical behaviourial requirements that have to hold in every reachable state. Note that it has to be shown that the invariant holds for every reachable state. Invariants can be used to express safety properties of the process. One of the invariant constraints in the TrainMissionControl speci cation is the following: TrainState 2 fSlow, Haltg ) WaitFor = TMTrack[CI]
This invariant constraint speci es that whenever TrainState equals Slow or Halt, i.e. the associated train is waiting for the allocation of the next track of its mission (TMTrack[CI]), this track is stored in the variable WaitFor. Note that this invariant constraint is also mentioned and proved in section 9 as property 3. Since the initial state is a reachable state it is necessary for the initial state to satisfy the invariant. Therefore, one might choose to use the invariant itself as the initial expression. A more realistic approach is to choose a degenerate case that re ects the initial introduction of an instance of the process type being speci ed into the operational environment while still satisfying the invariant. The constraint clause expresses the critical behaviourial requirements that must hold between any two consecutive states. Like the invariant it has to be shown that the constraint is correct. Constraints can be used limit the changes of variables, e.g. to set bounds on them. One of the more obvious constraints in the TrainMissionControl speci cation is the following: TrainState.old = Error ) TrainState = Error
It indicates that whenever the variable TrainState is equal to Error, i.e. something has gone terribly wrong, it will always stay equal to Error. In the schedule clause the critical constraints with respect to the temporal behaviour are speci ed. Scheduling requirements deal explicitly with the ordering of transitions and with the amount of time between occurrences of transition executions. Both the process type speci cations and the global 6
speci cation may contain scheduling constraints. Process type scheduling clauses deal with timing constraints for the processes of that type only, they can not contain variables or inquiries from other processes. The global scheduling clause, on the other hand, speci es timing constraints which involve multiple processes. The global scheduling requirements can specify restrictions on the ordering of transitions from di erent process instances and on the time between di erent transition occurrences. Note that scheduling requirements don't have to be shown to hold. They are only guidelines for an implementation of the speci cation. Examples of scheduling constraints can be found in sections 8.1 and 8.2. A global part of an Astral speci cation contains declarations for any nonprimitive types that are shared by more than one process type as well as global invariants and scheduling constraints. A process type speci cation that requires a globally declared type must explicitly import it. The global invariants represent critical functional properties of the whole system. A process may inquire about the value of any exported variable of that process type or about the start or end time for an exported transition of the type. Start(op) is used to give the start time of the last occurrence of transition op, and Start-k(op) is the start time of the k-th previous occurrence of op. Inquiries to the start time of a speci c transition can also specify speci c values for one or more of the parameters of that operation. For example, Start(op(?; y; ?)) gives the start time of the latest execution of transition op for which the value of the second parameter was 'y '. Inquiries about the end time of a transition are speci ed similarly using End(op) and End-k(op). Astral also includes a past(var; t) speci cation function, which yields the value of the exported variable var at time t. These inquiries are the only means of interprocess communication. Every instance of a process type has a unique ID. An instance can refer to its own ID by using Self. In order to disambiguate inquiries, each inquiry is denoted using a dot notation. For example, i.Start(op) results in the latest start time that transition op was executed by the process instance whose unique ID is i. If the process instance performing the inquiry is the same as the instance being queried, the preceding ID and period may be dropped. As a notational conveniance, the value of a variable in the previous state will be indicated in this paper by suxing that variable with .old instead 7
o priming that variable. This avoids confusion between primed variables that are used to indicate values of variables in the next state in other formal speci cation languages such as Lamport's TLA.
2.2 The Astral Computational Model
The computational model for Astral is a state machine model and assumes maximal parallelism, noninterruptable and nonoverlapping transitions in a single process instance, and implicit one-to-many (multicast) message passing communication. Maximal parallelism assumes that each process is associated with its own physical processor, and that other physical resources used by processes (e.g., memory and bus bandwidth) are unlimited. In addition, a processor is never idle when a transition on its associated processor is able to execute. That is, a transition is executed as soon as its precondition is satis ed (assuming no other transition is executing). The maximal parallelism approach was chosen on the basis of separating independent concerns; that is, rst demonstrate that a design is satisfactory, then, and only then, consider the scheduling problem imposed by a particular implementations limited resources. The speci cs of the implicit multicast message communication model are the following. At the start of a transition the starting time and the value of the actual parameters of the transition any are broadcast to all interested parties. At the end of a transition the ending time and the new value of variables are broadcast. These broadcasts are also assumed to be instantaneous. Note that the value of a variable returned by a process type to other process types during the execution of a transition of that process type is equal to the value of that variable at the start of the transition.
3 The problem: a railroad controller This section presents a brief informal description of the railroad system.
3.1 Informal problem description
A (toy) railroad system is built up from a variety of (connected) rail elements. Rail elements are connected and grouped into tracks. Through a computer (serial) interface the following commands can be given: Status enquiry commands (i.e. tracks being occuppied or not). 8
Switch setting/resetting commands. Commands, that set a particular speed and direction for each of the
trains. The problem is to specify a software controller with which the behaviour of the system, i.e trains and tracks, can be controlled. The controlled behaviour of the train should conform to requirements set for the train movements by a speci ed mission, one for each train. Missions specify routes which are expressed in terms of tracks and the train behaviour along the route. A track is a path over a sequence of connected rail elements. Obviously the system should obey elementary safety precautions: Trains should not collide. In line with customs of the Dutch railroads, this is implemented by forbidding that two trains ever ride on the same track simultaneously. When a train is on a track, no switch on that track should be changed. Setting a switch while a train is moving over it, causes considerable damage. The complete reference speci cation of the railroad controller is contained in [BBKT94].
3.2 The structure of the mission speci cation
For each train, the controller has been given a mission that speci es actions to be taken by that train. A mission is built up from a sequence of commands. A command consists of an action speci cation, a position speci cation and if appropiate a speci cation of temporal constraints. Command = INIT j START j STOP j PASS INIT indicates the initialization of the train. By specifying the track Track, the INIT command informs the system on the initial direction and position of the associated train. An INIT command is built up as: INIT Track START indicates a request for a train to start at Start time, and to reach the end of the track no later than Exit time. The direction of the movement is implicitly given by the track Track. A Start command is built up as: 9
START Track, Start time, Exit time STOP indicates that the train should stop, at Stop time, near the middle of the track Track. A Stop command is built up as: STOP Track, Stop time PASS indicates that a train should move over track Track, such that it reaches the end of this track no later than Exit Time. A Pass command is built up as: PASS Track, Exit time
4 Analysis of the problem This section presents a high level requirement and a rst decomposition of the railroad system into two parts and their interface. It also provides a few details about these parts and their interaction. On a high level of abstraction the requirements can be read as: At any given time, each of the trains should be as close as possible to the position dictated by the mission for that train. This speci cation can be made less abstract by looking into a requirements model for both the railroad and the controller, and by inspecting the interaction between railroad and controller. For a discussion on the informal requirements we refer to [BBKT94]. A rst step in the development is to identify the di erent elements in the requirements model. Di erent brands of trains provide di erent features, the system in our lab has some severe limitations. It therefore seems reasonable to abstract from physical details of the railroad in the speci cation. The resulting structure then becomes:
The controlled part, an abstraction of the physical railroad. The con-
trolled part (further indicated with ARM) provides information on train positions and it reacts upon the SCM by setting switches and by issuing speed setting and direction commands for the trains. The controller. The controller (further indicated with SCM) is responsible for maintaining the safety constraints on the railroad. The SCM observes the positions of the trains on the railroad and issues commands 10
to correct any observed deviation of the required position. As a side e ect the SCM will indicate the proper setting of the switches. The interface. The interface between the ARM and the SCM is used to send commands from the controller to the controlled part and to send feedback information from the controlled part to the controller. Commands regarding speed, direction and switches are sent from the controller to the controlled part. The feedback information from the ARM to SCM consists of information on the position of trains. Controller part SCM
6
Speed Dir Switch
Interface
Position
? ARM Controlled part
Figure 1: Overview of the railroad system
5 The ARM The ARM is built up from two process types: the SwitchControl and the Train process type. The SwitchControl process is responsible for the setting of switches. The Train process type is responsible for the setting of speed and direction, for the provision of information regarding the position of a train, and for the simulation of the behaviour of a real train. Because speed and direction are needed to keep the position information up to date they are included in one process type. Switch setting is related to the railroad rather 11
than the trains and therefore put in a seperate process. Section 5.1 presents the speci cation of the SwitchControl process type. The speci cation of the Train process type is presented in section 5.2. A global overview of the ARM is presented in gure 2.
6
Speed Direction
Position Info
?
SwitchSettings
?
TrainProcess
SwitchControl Controlled Part
ARM
Figure 2: ARM in more detail
5.1 Speci cation SwitchControl
It is the task of the SwitchControl process type to monitor the settings of the switches. The required settings of the switches are maintained in the variable ReqSwitchState. ReqSwitchState is imported from and set by the SCM. When ReqSwitchState di ers from the current settings of the switches, represented by the variable CurrSwitchState the current switch settings need to be adjusted. SPECIFICATION SwitchControl IMPORT ReqSwitchState EXPORT VARIABLE CurrSwitchState : seq of fBent, Straightg CONSTANT T1 : Time INITIAL INVARIANT CONSTRAINT SCHEDULE TRANSITION ChangeSwitch T1
12
Entry Exit
9 i: CurrSwitchState[i] 6= ReqSwitchState[i] 8 i: CurrSwitchState[i] = ReqSwitchState[i].old
END SwitchControl
5.2 Speci cation Train processes
The Train process type has two responsibilities. The rst one is to maintain speed and direction of a train. The settings for the required speed and direction are imported from the SCM, and are represented by the variables ReqSpeed and ReqDir. Adjusting the speed and direction, represented by the variables CurrSpeed and CurrDir, is done by execution of Transition ChangeSpeedDir. The transition is enabled when CurrSpeed and CurrDir, di er from ReqSpeed and ReqDir. The second responsibility of the Train process type is to provide the SCM with position information. This information is stored in the variables Position (which represents the track a train is on) and Offset (which represents the distance travelled on that track). In order to keep this information up to date transition UpdatePos makes a new estimate every Duration time units. Since there will be multiple instances of the Train process type it is important that the SCM and the ARM receive the appropiate information when they query each others variables. Each instance of Train will have a corresponding TrainMissionControl process in the SCM. The unique ID of this process is represented by the constant Own (e.g. queries about ReqSpeed have to be preceded by Own). SPECIFICATION Train IMPORT ReqSpeed, ReqDir, Now, TMC-ID EXPORT Position, O set VARIABLE CurrSpeed : [jnj CurrDir : fBackwards, Forwardsg Position : T rackI D O set : [jnj CONSTANT T2, T3 : Time Own : TMC-ID INITIAL O set = 0 ^ CurrSpeed = 0 ^ CurrDir = Forwards
13
INVARIANT CONSTRAINT SCHEDULE TRANSITION ChangeSpeedDir T2 Entry CurrSpeed 6= Own.ReqSpeed _ CurrDir 6= Own.ReqDir Exit CurrSpeed = Own.ReqSpeed.old ^ CurrDir = Own.ReqDir.old TRANSITION UpDatePos T3 Entry Now mod Duration = 0 Exit O set.old + Duration * CurrSpeed > Own.CTDist.old
)
O set = O set.old + Duration * CurrSpeed - Own.CTDist.old ^ Position = Con g(Position.old, CurrSwitchState.old) O set.old + Duration * CurrSpeed Own.CTDist.old
)
O set = O set.old + Duration * CurrSpeed
END Train
6 The SCM The SCM is divided into two process types: the TrainMissionControl and the TrainMissionControl. A TrainMissionControl process is responsible for the execution of a mission of a train. In order to execute a mission a TrainMissionControl process has to reserve tracks for its train. Because this reservation can cause con icts among di erent TrainMissionControl processes an arbiter is needed. The ResourceManager process is this arbiter. Besides allocating tracks the ResourceManager process also maintains the required setting of the switches. The TrainMissionControl processes also are responsible for the setting of the required speed and direction.
14
SCM TrainMissionControl
6 Speed Dir
?
Request -
Controller Resource Manager
Allocation
Position Info
Switch Settings
?
Figure 3: Overview of the controller
6.1 The TrainMissionControl process type
Processes from the TrainMissionControl process type control the execution of the mission for the corresponding train. Information concerning the mission is stored in the following six constants (all starting with TM short for TrainMission): TMCommand represents the commands of the mission. TMStartTime represents the Start time of the mission. It is only relevant when the corresponding command equals Start. TMArrivalTime represents the time at which the command has to be ful lled. It is irrelevant when the command equals Init. TMTrack represents the track on which the command has to be applied. TMDist represents the length of the corresponding track. TMSwitchState represents the required switch setting on the corresponding track. To help in the execution of the mission we have a number of variables: ReqSpeed represents the required speed setting of TrainMissionControl. ReqDir represents the required direction setting 15
CTTrack represents the current target track, i.e. the track on which the
train should ride. CTTime represents the current target time, i.e. the time at which the train has to be at its destination. CTDist represents the length of CTTrack. CI represents the position in the command sequence. It points to the command that has to be executed next. Init
?
Stopped
?
Start
?
Slow
6
-
-
Stopping
6
Halt
6
-
??? Error
666
?
Pass
Figure 4: Overview of the TrainState
TrainState represents the State of the train. Its values have the following meaning:
16
Init : The train is ready to begin. Start : The train has been given a StartTime and is waiting to start. Stopping : The train is in the process of stopping on the middle of the
track. Stopped : The train has been stopped as ordered and Reqspeed equals zero. Pass : The train is riding normally and the next track has been allocated to it. Halt : The train has stopped and is waiting for the allocation of the next track, represented by the variable WaitFor. The time at which the train was forced to stop has been stored in the variable HaltTime. Slow : The train is driving normally and is waiting for the allocation of the next track, represented by the variable WaitFor. Error : Something has gone wrong and we can't guarantee anything. In order to identify the associated train process from the ARM the unique ID of the corresponding Train process is represented by the constant Own. An overview of the TrainState and its possible changes is given in gure 4. SPECIFICATION TrainMissionControl IMPORT Now, Position, O set, AllocTable, CrashDanger, TC-ID EXPORT TMSwitchState, ReqSpeed, ReqDir, CTDist, CI, TMTrack VARIABLE ReqSpeed : [jnj ReqDir : fBackwards, Forwardsg TrainState : fInit,Start, Stopping, Stopped, Pass, Halt, Slow, Errorg CTTrack : T rackI D CTTime : Time CTDist : [jnj CI : [jnj HaltTime : Time StartTime : Time WaitFor : T rackI D CONSTANT T4, T5, T6, T7 : Time T8, T9, T10, T11a : Time T11b, T12, T13 : Time Own : ID TMCommand : seq of fStart, Stop, Pass, Initg TMStartTime : seq of Time TMArrivalTime : seq of Time TMTrack : seq of T rackI D TMDist : seq of [jnj TMSwitchState : seq of seq of fBent, Straight, NoChangeg
17
INITIAL CI = 1 ^ TrainState = Init ^ CTTrack = TMTrack[CI] 8 i,j : (TMSwitchState[i][j] 6= NoChange) (switch j 2 TMTrack[i]) INVARIANT 8 i,j : (TMSwitchState[i][j] 6= NoChange) (switch j 2 TMTrack[i]) TrainState 2 fSlow, Haltg ) WaitFor = TMTrack[CI] CONSTRAINT TrainState.old = Error ) TrainState = Error CTTrack 6= CTTrack.old ^ TrainState 6= Error ) TrainState.old = Pass ^ CTTrack = TMTrack[CI.old] SCHEDULE
6.1.1 TRANSITION InitTrain T4
On initialization of the system the variable TrainState has the value Init. If the rst command equals Init and the rst track has been allocated correctly, the TrainState is changed to Stopped and a number of administrive details are taken care of. If something was wrong the resulting TrainState will equal Error. Entry
TMCommand[CI] = Init ^ TrainState = Init
Exit AllocTable[TMTrack[CI]].old = self
)
TrainState = Stopped ^ CI = CI.old + 1 ^ ReqSpeed = 0 ^ ReqDir = Forwards ^ CTTrack = TMTrack[CI.old] AllocTable[TMTrack[CI]].old 6= self
)
TrainState = Error ^ CI = CI.old ^ CTTrack = CTTrack.old
18
6.1.2 TRANSITION StartTrain T5
For a train in mode Stopped the only valid command is a Start command. From the command a StartTime is extracted. The train will wait until its StartTime passes. The required direction is derived from the current and the previous position. A check on the AllocTable is present, because it can detect errors in the mission. Of course if the mission is correct this check shouldn't be necessary. Entry
TrainState = Stopped ^ TMCommand[CI] = Start
Exit AllocTable[TMTrack[CI.old]].old = self
)
TrainState = Start ^ CI = CI.old + 1 ^ StartTime = TMStartTime[CI.old] ^ CTTrack = TMTrack[CI.old] ^ CTTime = TMArrivalTime[CI.old] ^ CTDist = TMDist[CI.old] ^ ReqDir = Dir(CTTrack,TMTrack[CI]) AllocTable[TMTrack[CI.old]].old 6= self
)
TrainState = Error ^ CI = CI.old ^ CTTrack = CTTrack.old
6.1.3 TRANSITION StartToRun T6
A train will actually attempt to move when (i) it is in mode Start and (ii) when time StartTime has been passed. However before the train gets power to drive, the next track from the mission is to be allocated. The process stores the TrackID of that track in the variable WaitFor and starts the train if the track was free at the beginning of the StartToRun transition. This is done on the following assumption: if track was free a little while ago it will most likely be still free now. If this assumption is false, the train will be stopped by transition Waiting. If the track was not free at the beginning, the train will wait until the ResourceManager allocates the track by setting the TrainState to Halt. Entry
TrainState = Start ^ Now > StartTime
Exit
19
WaitFor = TMTrack[CI] AllocTable[TMTrack[CI]].old = Free
)
TrainState = Slow ^ ReqSpeed = (CTDist - Own.O set.old) /(CTTime - Now.old) AllocTable[TMTrack[CI]].old 6= Free
)
TrainState = Halt
6.1.4 TRANSITION Waiting T7
When a train is in mode Slow and has passed the middle of the track it will be stopped and enter mode Halt. The stop time is recorded in the variable HaltTime. Entry
Exit
TrainState = Slow ^ Own.O set CTDist/2 ^ Own.Position = CTTrack TrainState = Halt ^ HaltTime = Now
^ ReqSpeed = 0
6.1.5 TRANSITION Continue T8
When the ResourceManager has allocated the track the train was waiting for, the mode will be changed to Pass and the train will continue. Note that the entry clauses of transitions Waiting (T7) and Continue (T8) could be true at the same moment. This leads to a non-deterministic choice between the execution of transition T7 or transition T8. Also note that execution of T8 will falsify the entry condition of T7, while execution of T7 will not invalidate the entry clause of T8. Entry Exit
TrainState 2 fHalt, Slowg ^ AllocTable[WaitFor] = Self TrainState = Pass ^ ReqSpeed = (CTDist - Own.O set.old)/ (CTTime - Now.old)
20
6.1.6 TRANSITION GiveUp T9
If the train has waited too long for the allocation of a track the controller for that train will enter Error mode. Entry
TrainState = Halt ^ Now - HaltTime > MaxDelay
Exit TrainState = Error
6.1.7 TRANSITION Stopping T10
When a train in mode Stopping crosses the middle of the current track it stops and changes its mode to Stopped. Entry
Exit
TrainState = Stopping ^ Own.O set CTDist/2 TrainState = Stopped ^ ReqSpeed = 0
6.1.8 TRANSITION NewTrack T11a
A train is allowed to leave his old track and enter a new track, when its TrainState equals Pass and when the new track has been allocated to it. When a train leaves one track and enters another, administrative details have to be taken care of. If the mission requires a Stop command to be executed the mode of the train will change to Stopping . If the mission requires a Pass command to be executed the resulting mode will be Slow. However, the resulting speed will be calculated as if the ResourceManager already has allocated the next track to the train. If this assumption is not valid the train will be stopped by the transition Waiting . Entry
CTTrack 6= Own.Position ^ TrainState = Pass ^ AllocTable[Own.Position] = self
Exit TMCommand[CI.old] = Stop
)
TrainState = Stopping ^ CI = CI.old + 1 ^ CTTrack = TMTrack[CI.old] ^ CTTime = TMArrivalTime[CI.old] ^ CTDist = TMDist[CI.old]
21
^ ReqSpeed = (CTDist/2-Own.O set.old)/ (CTTime - Now.old)
TMCommand[CI.old] = Pass
)
TrainState = Slow ^ CI = CI.old + 1 ^ CTTrack = TMTrack[CI.old] ^ CTTime = TMArrivalTime[CI.old] ^ CTDist = TMDist[CI.old] ^ WaitFor = TMTrack[CI] ^ ReqSpeed = (CTDist-Own.O set.old)/(CTTime - Now.old) TMCommand[CI.old] 62 fStop, Passg
)
TrainState = Error ^ ReqSpeed = 0 ^ CI = CI.old ^ CTTrack = CTTrack.old
6.1.9 TRANSITION WrongTrack T11b
The train enters a new track, but it isn't allowed to do so. When this happens obviously something has gone wrong and the resulting TrainState will be equal to Error. The only time a train is allowed to enter another track is when its TrainState equals Pass. Entry
CTTrack 6= Own.Position ^ TrainState 6= Pass
Exit TrainState = Error
6.1.10 TRANSITION TrainSlow T12
When a train in mode Pass cannot be expected to meet its deadline within reasonable bounds its mode is changed to Error. Entry
TrainState = Pass ^ Now > CTTime ^ (CTDist - Own.O set.old)/ReqSpeed > MaxDi erence
Exit TrainState = Error
22
6.1.11 TRANSITION Error T13
When a train is in mode Error or when the position of the train is incorrect, the controller will stop the train, set its speed to zero and change the mode to Error. Entry
Exit
TrainState = Error _ Own.CrashDanger ReqSpeed = 0 ^ ReqDir = Forward ^ TrainState = Error
6.2 Resource Manager
The ResourceManager takes care of allocation of tracks (maintained in AllocTable) and it controls the required setting of the switches (maintained in ReqSwitchState). The ResourceManager is necessary in order to resolve con icts between trains and to avoid race conditions. Train controllers have to ask explicitly for the allocation of tracks. SPECIFICATION ResourceManager IMPORT CTTrack, CI, TrainState, TMTrack, TMSwitchState, WaitFor, TMC-ID EXPORT AllocTable, ReqSwitchState VARIABLE AllocTable : seq of TrainId [ fFreeg ReqSwitchState : seq of fBent, Straightg CONSTANT T14, T15, T16 : Time INITIAL INVARIANT CONSTRAINT SCHEDULE
6.2.1 TRANSITION ChangeAllocTable T14
This transition takes care of the track allocation by allocating a track t , which has been requested by TrainMissionControl process with ID i and which has to be Free. TRANSITION ChangeAllocTable(i:TMC-ID;t:TrackID) T14 Entry i.TrainState 2 fSlow, Haltg ^ AllocTable[t] = Free ^ t = i.WaitFor Exit AllocTable[t] = i
23
6.2.2 TRANSITION FreeTrack T15
A previously occuppied track t becomes Free as soon as no train either occupies or claims that track. Occuppied tracks are indicated by CTTrack. A track claimed by a train is indicated by TMTrack[CI ] when the TrainState is unequal to Error. TRANSITION FreeTrack(t:TrackID) T15 Entry AllocTable[t] 6= Free ^ t 62 fi.CTTrackj i 2 TMC-IDg ^ t 62 fi.TMTrack[i.CI]j i 2 TMC-ID ^ i.TrainState 6= Error g Exit AllocTable[t] = Free
6.2.3 TRANSITION ChangeSwitchState T16
This transition controls the required settings of switches by adjusting the switches on the tracks that are reserved by trains. From this transition and the invariant of the TrainMissionControl process type, it follows that only the settings of switches on those tracks are adjusted. TRANSITION ChangeSwitchState(i:TMC-ID) Entry ReqSwitchState 6= i.TMSwitchState[i.CI]
^
(i.TrainState 2 fHalt, Slowg ^ AllocTable[i.WaitFor] = i)
_
i.TrainState = Pass Exit ReqSwitchState = i.TMSwitchState[i.CI.old]
7 Introducing the Selectrix This section presents a re nement of the speci cation, taking a more realistic model of the selectrix railroad system into account. Since the only part that needs to be modi ed is the ARM, (the SCM is independent of any real railroad system), the speci cation in this section remains restricted to the re ned speci cation of the ARM. An overview of the resulting structure is presented in gure 5. In the adapted ARM speci cation, we identify two parts: 24
6
Speed Dir
Position Info
?
?
TrainProcess Speed Dir
Switch Settings
?
SwitchControl
6Position
?SwitchSettings
Selectrix Controlled Part
ARM
Figure 5: Structure of the ARM after re nement
A selectrix simulator, providing functionality similar to the functionality
provided by the actual selectrix. An ARM upper layer, providing the functionality ARM from section 5.
7.1 The Selectrix Speci cation
The real world Selectrix has three types of commands:
Train commands, i.e. commands to set the speed and direction of a given train. This is represented by changes to the variables PhysSpeed and PhysDir. Switch commands, i.e. commands to set switches. This is represented by changes to the variable PhysSwitches. Enquire commands, i.e. commands to enquire the state of tracks. This is represented by the variable PhysPos. Furthermore we use the variable PhysConf as representation of the physical con guration of the railroad. The variables PhysOffset and PhysPos are used for the representation of the position of each train. 25
In order to model the nasty behaviour of the trains in a more realistic way, a random component is taken into account in computing the real progress of the train. For optimization purposes, the positions of the trains are recomputed every time train or switch commands are given. The time of the last update is stored in the variable LastUpdate. We further assume the availability of a TrackLength function, which computes the length of a speci ed physical track, and a NextTrack function, which returns the following track given a physical con guration, the physical settings of the switches and an old track. Another assumption is that the tracks on the Selectrix level are the same as on the SCM level. Each time the settings of the switches (imported from SwitchControl and represented by the variable CurrSwitchState) or the settings of the speed or direction (represented by the variables CurrSpeed and CurrDir and imported from the process Train) have to be changed or when Duration time units have passed since the last update the transition Update is executed. SPECIFICATION Selectrix IMPORT Now, CurrSwitchState, CurrSpeed, CurrDir EXPORT PhysPos VARIABLE PhysConf : Unde ned PhysSwitches : seq of fBent, Straightg PhysDir : seq of fBackwards, Forwardsg PhysSpeed : seq of [jnj PhysPos : seq of T rackI D PhysO set : seq of [jnj LastUpdate : Time CONSTANT T17 : Time INITIAL LastUpdate = 0 INVARIANT CONSTRAINT PhysConf = PhysConf.old LastUpdate > LastUpdate.old SCHEDULE TRANSITION Update T17 Entry Now - LastUpdate = Duration _ 9 i : PhysSwitches[i] 6= CurrSwitchState[i] _ 9 i : PhysSpeed[i] 6= i.CurrSpeed _ 9 i : PhysDir[i] 6= i.CurrDir
26
Exit
PhysO set[i].old + Random[i] + (Now.old - LastUpdate.old) * PhysSpeed[i].old > TrackLength(PhysConf,PhysPos[i].old)
)
PhysPos[i] = NextTrack(PhysConf,PhysSwitches.old, PhysPos[i].old)
^ PhysO set[i] = PhysO set[i].old + Random[i] +
(Now.old-LastUpdate.old) * PhysSpeed[i].old TrackLength(PhysConf,PhysPos[i].old) PhysO set[i].old + Random[i] + (Now.old - LastUpdate.old) * PhysSpeed[i].old TrackLength(PhysConf,PhysPos[i].old)
)
PhysO set[i] = PhysO set[i].old + Random[i] + (Now.old-LastUpdate.old) * PhysSpeed[i].old 8 i : PhysSwitches[i] = CurrSwitchState[i].old 8 i : PhysSpeed[i] = i.CurrSpeed.old 8 i : PhysDir[i] = i.CurrDir.old LastUpdate = Now.old END Selectrix
7.2 Adapting the ARM
The ARM has to be adapted in order to take the Selectrix functionality into account. The functionality of the Selectrix is somewhat limited with respect to position information of the trains. The only information that can be obtained is whether a given track is occupied or not. The Train processes still make estimates of the positions of their train. The Selectrix provides information validating these estimates.
7.2.1 The adapted SwitchControl
The SwitchControl still reacts to di erences in the proper and actual settings of the switches. It now provides information about the switch settings to the Selectrix, who in turn changes the physical switches accordingly. SPECIFICATION SwitchControl IMPORT ReqSwitchState EXPORT CurrSwitchState VARIABLE CurrSwitchState : seq of fBent, Straightg CONSTANT T1 : Time INITIAL INVARIANT
27
CONSTRAINT SCHEDULE TRANSITION ChangeSwitch T1 Entry 9 i : CurrSwitchState[i] 6= ReqSwitchState[i] Exit 8 i : CurrentSwitchState[i] = ReqSwitchState[i].old END SwitchControl
7.2.2 The adapted Train process
Each Train process is able to validate its own estimate of the position of the train by checking the corresponding variable PhysPos from the Selectrix. If the train is lost, i.e. the train is not on an expected track the Train process sets the variable CrashDanger to true. Of course the Train process still reacts on di erences in the proper and actual values of the speed and direction settings. Changes in the actual values lead to a change in the the physical values by the Selectrix. SPECIFICATION Train IMPORT ReqSpeed, ReqDir, CTDist, CTTrack, CI, TMTrack, TrainState, PhysPos, Now EXPORT Position, O set, CurrSpeed, CurrDir, CrashDanger VARIABLE CurrSpeed : [jnj CurrDir : fBackwards, Forwardsg Position : [jnj O set : [jnj CrashDanger : Boolean CONSTANT T2, T3 : Time Own : ID INITIAL : CrashDanger ^ O set = 0 INVARIANT CONSTRAINT CrashDanger leads to TrainState = Error SCHEDULE TRANSITION ChangeSpeedDir T2 Entry
28
Exit
CurrSpeed 6= Own.ReqSpeed _ CurrDir 6= Own.ReqDir
CurrSpeed = Own.ReqSpeed.old ^ CurrDir = Own.ReqDir.old TRANSITION UpdatePos T3 Entry Now mod Duration = 0 ^ : CrashDanger Exit O set.old + Duration * CurrSpeed > Own.CTDist.old
)
Own.TMTrack[Own.CI].old = PhysPos[self].old
)
O set = O set.old + Duration * CurrSpeed - Own.CTDist.old ^ Position = Own.TMTrack[Own.CI].old Own.TMTrack[Own.CI].old 6= PhysPos[self].old
)
Own.CTTrack.old 6= PhysPos[self].old
)
CrashDanger O set.old + Duration * CurrSpeed Own.CTDist.old
)
Own.CTTrack.old = PhysPos[self].old
)
O set = O set.old + Duration * CurrSpeed Own.CTTrack.old 6= PhysPos[self].old
)
Own.TMTrack[Own.CI].old = PhysPos[self].old
)
O set = 1 ^ Position = Own.TMTrack[Own.CI].old Own.TMTrack[Own.CI].old 6= PhysPos[self].old
)
CrashDanger
END TrainControl
8 The global speci cation part Trainsystem This section presents the global part of the speci cation. Section 8.1 presents the declarations and behaviour constraints of the global part. The temporal constraints on the transitions of the TrainMissionControl and Train process types are given in subsection 8.2 and 8.3 respectively. 29
8.1 Declarations and behaviour constraints.
The global speci cation part of the system speci es the processes that play a role in the railroad control system. Furthermore non-primitive types, such as the TMC-ID and the TC-ID are introduced. The TMC-ID is a set of identi cations of TrainMissionControl processes. Finally global invariants and initial clauses are also mentioned in the global speci cation. Some of these invariants are used in the proof that no two trains ever collide in section 9. GLOBAL Speci cation TrainSystem PROCESSES TMC : seq[1..NumTrains] of TrainMissionControl RM : ResourceManager TC : seq[1..NumTrains] of TrainControl SC : SwitchControl Sel : Selectrix TYPE TMC-ID : Typedef tid : ID (IDTYPE(tid) = TMC) TC-ID : Typedef tid : ID (IDTYPE(tid) = TC) CONSTANTS Duration : Time MaxDi erence : Time MaxDelay : Time VARIABLE Now : Time INITIAL 8 i 2 TMC-ID : AllocTable[i.TMTrack[1]] = i 8 i 2 TMC-ID : 9 j 2 TC-ID : i.Own = j 8 i 2 TC-ID : i.Position = (i.Own).TMTrack[(i.Own).CI] INVARIANT 8 i 2 TMC-ID : 9 j 2 TC-ID : i.Own = j ^ j.Own = i 8 i 2 TMC-ID : i.TrainState = Pass ) AllocTable[i.TMTrack[i.CI]] = i 8 i 2 TMC-ID : AllocTable[i.CTTrack] = i CONSTRAINT SCHEDULE
30
8.2 The TrainMissionControl schedule
The following section speci es the temporal constraints of the railroad system concerning the transitions of the TrainMissionControl process type. These schedules are given in the Global speci cation part, because some variables in the entry and exit clauses of TrainMissionControl transitions are imported from other process types. Recall that the start and ending times of transitions and past values of variables are available.
8.2.1 Starting Trains
The time between two di erent starts of the same train is greater than 1000 ms and the StartTrain transition is executed within 100 ms after the entry clause is satis ed. 8 i: Start-i(StartTrain) - End-(i+1)(StartTrain) 1000 8 t 2 Time: Past(Entry(StartTrain),t): 9 i: (t Start-i(StartTrain) ^ End-i( StartTrain) t + 100) _ now - t 100 >
