Organization and Control of Autonomous Railway Convoys

AVEC ’08employed to formally prove safety-critical properties.Systems with thousands of elements and dynamicstructural changes as in the RailCab project do not allowthe specification and verification of the whole system.Instead compositional approaches have to be employed,where parts are precisely defined. Each system part isindividually specified and verified with respect to safetyconditions. The compositional approach then guaranteesthat the whole system is safe with respect to the safetyconditions when the system is correctly assembled fromthe base parts.The Mechatronic UML [7] is a modelling languagewhich supports the compositional specification ofstructure and hybrid (continuous/discrete) behaviour.Additionally, the specifications are compositionallychecked by the Uppaal model checker [8] whether theysatisfy safety-critical properties.In addition to previous work on convoys of only 2RailCabs [9], we extended the specifications to supportconvoys consisting of (a fixed number of) N RailCabs.In a convoy, one RailCab is appointed to coordinate theconvoy by periodically distributing reference values tothe other RailCabs for convoy control and dealing withjoining and leaving RailCabs.In [10], we presented a formal specification andcompositional verification approach for collaborationswith an unknown number of participants. We build onthis foundation and derive the software models from it.Fig. 1 shows the structure of the convoy operationpart of three RailCabs, the first one is the coordinator ofthe convoy and, in addition to the coordinatorcomponent, does also contain the component for drivingin a convoy. This component does receive referencevalues. These include how to behave in case of a hazard[9]. The coordinator component of the two othercomponents is currently not active. Both RailCabs alsoreceive periodically reference values for driving in theconvoy.to the coordinator.The coordinator checks whether it is possible (andbeneficial for the convoy) that the additional RailCabjoins the convoy. If that is the case, the coordinatorcomputes new values concerning the maximal velocityand normal and maximal brake forces for each RailCabin the convoy as well as the potential convoy joinposition and velocity for the new RailCab. If the newRailCab agrees with these values, the coordinator relaysthem to all RailCabs in the convoy (including itself).Finally, the coordinator sends brake delay times to allRailCabs which enables a coordinated convoy brakingin case of a hazard.The messages are sent using data link layers whichmask value and omission faults of the employedwireless network [9].Fig. 2a convoyCommunication protocol concerning the use case: JoiningFig. 1Software structure of a convoy of three RailCabsWe identified the following use cases for theconvoy operation: (1) joining a convoy, (2) leaving aconvoy, and (3) changing the coordinator of a convoy.The communication protocols for these use cases mustbe specified for the individual RailCab as well as thecoordinator.The identified use cases are implemented bycommunication protocols between the participants. Fig.2 shows the communication between a single RailCaband an existing convoy of two RailCabs. The singleRailCab sends a request to join a convoy including itsmaximal velocity, and normal and maximal brake forcesThe components’ behaviours are specified inMatlab Stateflow. The generated code is executed onthe rapid prototyping hardware deployed on theRailCab.The negotiation of the parameters for convoy modeis done by evaluating the vehicle properties a motor,n andv max,n :Minn ∈ 1..N (1){ }{ }a motor = a motor,n , { }v = Min , { 1..N}max v max,nn ∈ (2)The defined parameters are binding for all convoyvehicles. The time delay T delay,n is different for eachRailCab. It depends on the vehicle mass m n in relationto the force of the emergency brake system F eb,n (whichis communicated as a eb,n ):T = T + T(3)delay, n+ 1 delay,n ∆ n+1,n∆Tvvn + 1 nn + 1,n = −(4)aeb,n+ 1 aeb,n