Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Chapter 10. openETCS Model<br />
be explained in the following Subsection 10.4.2. A balise telegram always terminat<strong>es</strong> with an<br />
“End of Information” packet [85, p. 30].<br />
10.4.2. Balise Content<br />
All available ETCS packets are modelled in a gAnyPacket graph. According to the initial<br />
d<strong>es</strong>cription of the gAnyPacket graph type in Subsection 7.3.8, the model in Figure 10.29 only<br />
holds a set of oPacket objects without any bindings. The models or rather decompositions of<br />
some exemplary packets will be discussed in the following subsections.<br />
Level 1 Movement<br />
Authority<br />
Gradient Profile<br />
National Valu<strong>es</strong><br />
International Static<br />
Speed Profile<br />
Stop if in Staff<br />
R<strong>es</strong>ponsible<br />
Repositioning<br />
Information<br />
Level Transition<br />
Or<strong>der</strong><br />
Linking<br />
Figure 10.29.: Available packets as gAnyPacket graph<br />
10.4.3. Level Transition Or<strong>der</strong> Packet<br />
The “Level Transition Or<strong>der</strong>” packet [85, p. 14] is used to or<strong>der</strong> a train to switch to a<br />
new Application Level. This was d<strong>es</strong>cribed for the Unfitted Mode in Subsection 10.2.3.<br />
The three very first oVariableInstance objects define only general information of the packet.<br />
“NID_PACKET” [85, p. 47] is the unique numerical ID of each packet, “Q_DIR” [85, p. 49]<br />
defin<strong>es</strong>, which movement directions of the train the packet is valid for, and “L_PACKET” [85,<br />
p. 37] is the size of the telegram in bits.<br />
“Q_SCALE” [85, p. 54] is a scaling qualifier, which is applied by the “Scaling” relationship<br />
(see Subsection 7.3.7) to all distanc<strong>es</strong> and lengths in this packet. “D_LEVELTR” [85, p. 32]<br />
holds the distance to the level transition itself. On the one hand, “M_LEVELTR” [85, p. 41]<br />
holds the information about the new Application Level to be switched to. On the other hand,<br />
it is also a conditional iterator for the oVariableInstance object “NID_STM” [85, p. 37], which<br />
holds the identifier to the required STM. Neverthel<strong>es</strong>s, because this case study only includ<strong>es</strong><br />
Application Level 0 and 1, this oVariableInstance object is never used and is only modelled for<br />
completen<strong>es</strong>s.<br />
“L_ACKLEVELTR” [85, p. 36] repr<strong>es</strong>ents the length of the area, in which the driver has to<br />
acknowledge the level transition via the DMI.<br />
The oVariableInstance object “N_ITER” [85, p. 4] giv<strong>es</strong> the possibility to define multiple Level<br />
transitions in one packet by iterating over oVariableInstance objects of the same oVariableType<br />
objects (“M_LEVELTR_T”, “NID_STM_T”, and “L_ACKLEVELTR_T”) that were used<br />
before.<br />
206