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 next message
Heribert Neu is currently offline  Heribert Neu
Messages: 5
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

Re: train stablings [message #1803 is a reply to message #1795] Wed, 23 May 2018 12:30 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 239
Registered: August 2008
Senior Member
Dear Heribert,

I can state for iRFP that we regard your solution A as the more typical and practical.

With best regards,
Dirk.
Re: train stablings [message #1804 is a reply to message #1803] Wed, 23 May 2018 12:34 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 239
Registered: August 2008
Senior Member
Dear all,

the <TT> Developer Telco on 23rd May 2018 brings us to the following state of this issue:

- Solution B implies solution A.
- There has already been an agreement to support solution A at the Berlin <TT> Developer Meeting on 19th April 2018.
- Whether solution A (alone) or B (including A) is the better one depends on how detailed information shall be expressed and whether a circulation planning is affected in general. Therefore, there is the suggestion to allow both A and B and leave the final decision to the use case.
- For solution A (alone), the question has been discussed whether to provide an additional "mission" attribute at the train as part of railML. (This relates to the extension "ns4:trainPathIndicator=SOBO" in Heriberts example.) The conclusion was that no necessity for such an attribute as part of railML is seen. The <train[Part]> with one <ocpTT> explains itself alone enough. It does not matter here whether this <train[Part]> arrives or departs as a train or shunting operation. Who wants to express more, shall select solution B.
- There is the decision to allow solution B by removing the preventing restrictions (allow <rostering>s without <circulation>s and <block>s) from railML 2.4.

Best regards,
Dirk.

---
Hallo allerseits,

nach der <TT>-Entwickler-Telco vom 23.05.2018 stehen wir bezüglich dieser Anforderung an folgender Stelle:

- Lösung B setzt Lösung A voraus.
- Über die Unterstützung von Lösung A bestand bereits am 19.04.2018 in Berlin Einigkeit.
- Ob allein Lösung A zu wählen ist oder auch Lösung B, hängt vor davon ab, wie detailliert ausgedrückt werden soll und ob eine Umlaufplanung tangiert wird. Es besteht daher der Vorschlag, beides zu erlauben und die finale Entscheidung dem UseCase zu überlassen.
- Für Lösung A wird die Erweiterung um eine "mission" (des abgestellten <trainPart>s, bezieht sich auf die Erweiterung "ns4:trainPathIndicator=SOBO" in Heriberts Beispiel) als railML-Attribut nicht zwingend für notwendig erachtet. Der Ein-OCP-<TrainPart> spricht für sich; es muss nicht zwingend ausdrückbar sein, ob dieser als Zug- oder Rangierfahrt "kommt" und "fährt". Wer mehr ausdrücken will, soll zu Lösung B greifen.
- Es wird entschieden, zur Ermöglichung von Lösung B die ihr entgegenstehenden Restriktionen unter <rostering> ab railML 2.4 aufzuheben.

Viele Grüße,
Dirk.
Re: train stablings [message #1856 is a reply to message #1804] Tue, 26 June 2018 10:42 Go to previous message
Heribert Neu is currently offline  Heribert Neu
Messages: 5
Registered: January 2018
Junior Member
The necessary change on the railML 2.4 schema is as follows:
when defining the child elements of rostering the element blocks gets the specification minOccurs="0", see below:
<xs:complexType name="eRostering">
  <xs:complexContent>
    <xs:extension base="rail:tRostering">
      <xs:sequence>
        ...
        <xs:element name="blocks" type="rail:eBlocks" minOccurs="0"> <---
          <xs:annotation>
            <xs:documentation source="http://wiki.railml.org/index.php?title=TT:blocks"/>
          </xs:annotation>
        </xs:element>
        <xs:element name="circulations" type="rail:eCirculations" minOccurs="0">
          <xs:annotation>
            <xs:documentation source="http://wiki.railml.org/index.php?title=TT:circulations"/>
          </xs:annotation>
        </xs:element>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

The circulations already have the entry minOccurs="0", here no change is necessary.

Best Regards
Heribert

[Updated on: Tue, 26 June 2018 10:44]

Report message to a moderator

Previous Topic: [Request for railML3] Different station tracks in one <ocpTT> for different <operatingPeriod>s
Goto Forum:
  


Current Time: Thu Aug 16 07:58:06 CEST 2018