TT:operationalTrain

Documentation

Syntax

Autoexport from the XML-Schema for element TT:operationalTrain of railML® version 3.2 UML-visualization of TT
Documentation	An operational train groups one or many variants of the same operational train, so trains that run with the same basic train number but with differences between each other. Operational trains encode an operational view of the train, so a view a IM would have on a train.
Subschema	timetable
Parents*	operationalTrains
Children	name (0..*), operationalTrainVariant (1..*)
Attributes: id: unique identifier (obligatory; xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.

This element does not appear in railML^® 3.1 within the TT subschema. It is available only in railML^® 3.2. Do not hesitate to contact railML.org for further questions.

Changes 3.1→3.2

Introduced with version 3.2.

Best Practice / Examples

For this example it is assumed that the reader is familiar with the concept of <itinerary> of railML3. The conceptual difference between <itinerary> and <operationalTrain> or <commercialTrain> is a reference to the Rollingstock and further movement in time with @offset if needed.

Reusing itineraries

Below is an example of three trains based on the same <itinerary>. Analogously to the approach of railML3 in which <itinerary> is based on <baseItinerary>, <operationalTrain>s and <commercialTrain>s are based on <itinerary>.

      <operationalTrain id="ot-1">
        <operationalTrainVariant id="ov-1" itineraryRef="it-1" validityRef="va-2">
          <identifiers>
            <identifier number="OT1066" type="OperationalTrainNumber"/>
          </identifiers>
          <operationalTrainSection>
            <operationalTrainSectionPart id="os-1">
              <formationInformation formationRef="fm-1"/>
            </operationalTrainSectionPart>
          </operationalTrainSection>
        </operationalTrainVariant>
      </operationalTrain>
      <operationalTrain id="ot-2">
        <operationalTrainVariant id="ov-2" itineraryRef="it-1" offset="PT1H" validityRef="va-2">
          <identifiers>
            <identifier number="OT1067" type="OperationalTrainNumber"/>
          </identifiers>
          <operationalTrainSection>
            <operationalTrainSectionPart id="os-2">
              <formationInformation formationRef="fm-1"/>
            </operationalTrainSectionPart>
          </operationalTrainSection>
        </operationalTrainVariant>
      </operationalTrain>
      <operationalTrain id="ot-3">
        <operationalTrainVariant id="ov-3" itineraryRef="it-1" offset="PT2H" validityRef="va-2">
          <identifiers>
            <identifier number="OT1068" type="OperationalTrainNumber"/>
          </identifiers>
          <operationalTrainSection>
            <operationalTrainSectionPart id="os-3">
              <formationInformation formationRef="fm-1"/>
            </operationalTrainSectionPart>
          </operationalTrainSection>
        </operationalTrainVariant>
      </operationalTrain>

This example demonstrates that it is valid to base two or more trains on the same <itinerary>.

This way railML3 approach helps to reduce the redundancy in code. Even though users can define a set of itineraries specifically for all trains "ot-1", "ot-2" and "ot-3", the best practice of railML3 is to reuse the existing itineraries as much as possible moving them in time with @offset attribute if needed.

Additional Information

Notes

Be aware of semantic constraint TT:002.