Home » railML newsgroups » railml.timetable » train stablings (Representing train stablings and other track occupancies with trainParts)
train stablings [message #1795] Wed, 16 May 2018 08:23 Go to previous message
Heribert Neu is currently offline  Heribert Neu
Messages: 7
Registered: January 2018
Junior Member
Dear railML Timetable Community,

We want to supply a system which is used by SBB/CFF/FFS for the planning and control of construction sites and for capacity management. For this purpose, this system also requires information concerning which tracks are occupied by train stablings or for other reasons.

The following constraints must be considered:
1. the track used for train stabling is important for capacity management and must be delivered in the export.
2 in the source-system the rostering of trains is not reliably captured and represented. To this end the system provides two non-validated text fields: one describing the arrival and the other for departure.
3. in the source-system the rollingstock is also weakly managed. Here only the length of the train is recorded.
4. in addition to train stablings, other track occupancies such as track closures, construction sites and occupancies by construction trains are also recorded in the manner described above.

For the representing of such train stablings and track occupancies there are two alternative solutions, which I would like to present and discuss in the forum.

A. Solution with one trainPart- and train-element
Our solution for the transfer of such train stablings and track occupancies in railML uses a single trainPart together with a single ocpTT. Here as an example of an all-day train stabling occurring every Sunday (only the timetable part):
<timetable infrastructureRef="is123" name="BnFriB" id="tt2018-123">
   ...
      <trainParts>
         <trainPart timetablePeriodRef="ttPeriod2018" id="trainPart123" debitcode="1119">
            <formationTT formationRef="formation123"/>
            <operatingPeriodRef ref="operatingPeriod123"/>
	    <ocpsTT>
		<ocpTT sequence="1" ocpType="stop" ocpRef="ocp_BS" trackRef="ctrack123" trackInfo="A24"                     
                                            ns4:textArrival="Reserve-DPZ" ns4:textDeparture="Q18877/Mo">
		   <times scope="scheduled" arrival="00:00:00" arrivalDay="0" departure="24:00:00" 
                                                                                  departureDay="0"/>
		</ocpTT>
	    </ocpsTT>
         </trainPart>
      </trainParts>
   <trains>
	<train type="operational" id="train123" code="BS_212" processStatus="other:active" 
                                                             ns4:trainPathIndicator="SOBO">
	   <trainPartSequence sequence="1">
	      <trainPartRef ref="trainPart123"/>
		  <topologyReference register="UNO" entry="2017-12-10"/>
	   </trainPartSequence>
	</train>
    </trains>
</timetable>

Remarks on Solution A:
1. The purpose of the train stabling is shown in the text fields for arrival and departure, which are mapped in the following two extension attributes:
ns4:textArrival="Reserve-DPZ", which means: the train section comes out of reserve
ns4:textDeparture="Q18877/Mo", which means: the train section is linked on Monday to the end of train 18877
2.The fact that it is not a train with a train path, but a train stabling, is defined in the extension attribute
ns4:trainPathIndicator="SOBO", (SOBO=Special Occupancy Object).
3. this solution would not require any changes to railML 2.4 schema. However, arrival, arrivalDay, departure and departureDay are set on the first, last and only ocpTT-element.

B. Alternative solution: Implementation using a blockPart-element instead of a train-element
Andreas Thanner (IVU) has proposed the following alternative solution: instead of the train-element in the example from variant A, he uses a single blockPart-element that references the trainPart:
<rosterings>
	<rostering>
       	    <blockParts>
		<blockPart id="bp01" trainPartRef="trainPart123" mission="standBy" formationRef="formation123"/>
	    </blockParts>
	</rostering>
</rosterings>

Remarks on solution B:
1. The attribute mission expresses the purpose of the special occupancy.
2. the following changes to the railML 2.4 schema would be necessary:
• Rostering without circulation and blocks
• If necessary, further elements at <blockPart> such as processStatus, topologyReference
3. The advantage of this modeling would be
• Appropriate use of the mission attribute
• Clear expression of "special occupancy" as isolated occupancy without travel movement


Best regards
Heribert Neu

SBB AG
Informatik
Haslerstrasse 30, CH-3000 Bern 65
Mobil +41 76 2451887
heribertneu(at)sbbch / www.sbb.ch

[Updated on: Wed, 16 May 2018 08:53]

Report message to a moderator

 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: values 'earliest' and 'latest' of <ocpTT>.<times>.@scope
Next Topic: TrainPart:tProcessStatus semantic
Goto Forum:
  


Current Time: Fri Apr 26 17:16:43 CEST 2024