Differences between railML2 and railML3

LTCP

Implementing UC:TT:LongTermCirculationPlanning using railML^® 2 has shortcomings given below.

Referring to vehicles

In railML® 2 there is no direct way to reference a certain vehicle of a trainPart.

• 

  Provided by railML.org partner iRFP (link to the railML^® website)

Indication of midnight overruns

In railML^® 2 it is difficult to define whether a block connection (<circulation> in railML^® 2) includes none, one or more than one midnight overruns when validities with more than one operating day are used.

• 

  Provided by railML.org partner iRFP (link to the railML^® website)

Circulation element connects two blocks. Each connection is attributes with validity (Monday to Friday).

Interpretation a) assumes that block1 and block2 can be carried out on the same day, e.g. block1 in the morning and block2 in the afternoon.

Interpretation b) can assume that block1 and block2 happen at the same time i.e. block1 and block2 cannot happen on the same day with the same vehicle. If block1 happend on Monday , this vehicle can perform block2 on the next day.

Workaround (of railML^® 2): Using one block connection for each single day (one for Monday, one for Tuesday and so on):

<circulation 
	blockRef="blk_1" 
	operatingPeriodRef="opp_Mon-Fri" 
	nextBlockRef="blk_2" 
	nextOperatingPeriodRef="opp_Mon-Fri"/>

Further changes to the schema of railML^® 2

Changes:

• Reduction in the number of aggregation layers from 2 (<circulation>, <block> in railML® 2) to 1 (<blockConnection> in railML® 3)
• Optional grouping of block connections with references to the same initial block element
• New attribute ‘transitionTime’ on the <blockConnection> element: allows definition of minimal realisation time
• Better structured model for non-train run tasks (maintenance, cleaning, …)
• Option to provide a trackref for non-train run tasks