Talk:Dev:Guide on modelling of rollingstock circulations in railML 3
Definition and Requirements
Train rostering describes a sequence of train runs or tasks (maintenance, refueling, etc.), which a vehicle / group of vehicles has to perform.
One rostering plan is for one vehicle "class" (groups of vehicles) but for several "instances" of this vehicle class (the ones with specific license numbers). A rostering plan is defined by the class of a vehicle and a set of train runs that must be covered by a rostering plan. Once the rostering plan is calculated the result is a number of needed instances of this vehicle class and individual plans of train runs which each vehicle has to fulfill. Vehicle instance should not be confused with vehicle of a certain number. There is a difference between the vehicle instances that are used in this plan, e.g. vehicle1, vehicle2, vehicle5 of this rostering plan... -> What are you trying to say here?
‘Long-term’ means: typically covers train runs of one representative week of the timetable, special services or limited services due to holidays or construction works are not taken into account.
Please link the UC description here with a line, like: "For more information on the use case please see the LTCP Use Case Specification"
LTCP supports open and closed (circular) rostering plans.
Open and closed (circular) rostering plans
Closed circulation diagram. Provided by railML.org partner iRFP (link to the railML® website)
Open circulation diagram. Provided by railML.org partner iRFP (link to the railML® website)
Closed (circular) rostering plans:
- Can be repeated infinitely often -> after one execution all vehicles must return to their initial position;
- Scope is abstract placeholder week, not bound to a specific date;
- Typical time period: 1 day, 1 or multiple weeks.
Open rostering plans:
- Not intended to repeat execution;
- Has typically a specific starting and end date;
- Any time period is possible.
Basic elements of rostering plans in railML
<TT:block>: represents one train run or task (maintenance, refuelling, etc.).
- Connects two blocks and thereby defines their sequence order;
- Defines the time gap between two blocks - whether two connected blocks can happen on the same day or if block2 must happen on the next day as block1;
- Contains reference to a <validity>: Allows different follow-up blocks on different operating days.
Together they compose a network / graph:
Simple (closed) rostering plan Monday-Friday. Provided by railML.org partner iRFP (link to the railML® website)
Boxes on a figure stand for blocks. Blue blocks are train runs. Orange block is for cleaning task. Arrows are block connections. Dashed arrow represents "closed" rostering. -> doesnt it rather represent the repetition of a closed circulation, so the restart of the sequence?
Indication of midnight overruns
Day offset is used to define whether a block connection (in railML® 2 <circulation>) 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)
Interpretation a) assumes that both block can happen after each other on the same day by setting offset to 0.
Interpretation b) - block 2 is executed on the next day after the execution of block 1 by setting offset to 1. The vehicle is not planned for the whole weekend. After the block1 on Friday it continues with block2 on Monday. There is day offset is three nights. For this case there is a need of two block connections.
Referencing individual vehicles
I think this title isnt a good one. Talking about individual vehicles indicates that you are not talking about the vehicle class anylonger. But in LTCP you are. A train formation in LTCP is not built from individual vehicles (in terms of a specific vehicle that can be touched) but rather from vehicle class representations (no specific instances).
Issue: Sometimes a train part consists of more than one vehicles of the same class: Rostering plan needs to reference each vehicle of the formation separately.
Provided by railML.org partner iRFP (link to the railML® website)
Solution: Referencing a vehicle indirectly by:
- Reference to <formation> and
- Index and number of the vehicles
<block id="blk_1"> <trainSectionPartRef ref="tpt_1"> <formationRange firstVehicleIdx="2" numberOfVehicles="1"/> </trainSectionPartRef> </block>
numberOfVehicles="1" means number of consecutive vehicles to be referenced.
firstVehicleIdx="2" means index of the 1st vehicle in the formation of the referenced train part. -> I would recommend to use numberOfVehicles>1 and add an image displaying which vehicles are meant by the code example
The <vehicleRostering> root element
Following sections demonstrates how a rostering plan is transferred to the railML file. Below the structure of vehicle rostering root element and its position in the railML file tree is described.
Under <timetable> element there is a container element called <vehicleRosterings>. This is a container for all the rosterings of this file. Each individual rostering is enclosed in <vehicleRostering> element, which itself has two container elements. One for the <blocks> and other for the <blockConnections>. It provides some references to better identify the rostering. It can have the reference to a <formation> where we specify for which vehicle class this rostering is and an optionally it can reference a depot. We can have several rosterings for the same vehicle type but they are assigned to different depots. -> I dont think this is correct. We could also have multiple rosterings for vehicles of the same depot. After all we are not talking about specific vehicles. So I could have a number of different rosterings for the same vehicle class, all originating with the same depot. With this I could, as you indicated at the start, determine how many actual specific vehicles would be needed to operate the trainruns included in the various rosterings. @depotRef is a reference to a <functionalInfrastructure> operational point.
<railml> <timetable> <!-- --> <vehicleRosterings> <vehicleRostering id="vrg_1" depotRef="opp_A" formationRef="frm_1"> <blocks> <!-- --> </blocks> <blockConnections> <!-- --> </blockConnections> </vehicleRostering> </vehicleRosterings> </timetable> </railml>
Blocks
When it comes to transferring the content of a rostering plan to the railML model the first thing we have to think about are the blocks.
Below you can see the figure of the example rostering plan. We will transfer this rostering plan into the railML model. The first step is to identify all the blocks in the figure and to transfer them into the <block>s elements of the railML model. There are two train runs "Train 101" and "Train 102". In the extract below they correspond to blk_101 and blk_102. They reference a train part from TT schema so they have very few extra information. The starting and end operating point and arrival and departure times are inherited from train part that is referenced. The only thing that must be provided is the reference to the vehicle.
The orange block corresponds to blk_cleaning. This block has some extra information, since it has no counterpart in the timetable section, it lives only in the rostering section. We have to provide start and end time and optionally an operating point where this task is to be carried out.
Provided by railML.org partner iRFP (link to the railML® website)
<block> elements with reference to a <operationalTrainSectionPart>:
<block id="blk_101"> <trainSectionPartRef ref="tpt_101"> <formationRange firstVehicleIndex="1" numberOfVehicles="1"/> </trainSectionPartRef> </block>
<block id="blk_102"> <trainSectionPartRef ref="tpt_102"> <formationRange firstVehicleIndex="2" numberOfVehicles="1"/> </trainSectionPartRef> </block>
<formationRange> is a reference to a part of the formation of a <operationalTrainSectionPart>.
<block> element without reference to a <operationalTrainSectionPart>: Start and end time must be specified Additionally you could point out that the location can be provided. For other non train run blocks the start- and endo location can be provided.
<block id="blk_cleaning"> <cleaning startTime="08:00:00" endTime="09:00:00"> <locationRef> <opRef ref="opp_A"/> </locationRef> </cleaning> </block>
Block connections
For each arrow in the figure above we have to create one <blockConnection>. It's also possible to group <blockConnection>s together that have the same initial <block> to make it more human readable. This also reduces redundancy We have <blockConnection>s which have more than one <successor> element, e.g. blk_101 has two follow up blocks - on Monday till Thursday it's blk_102 and on Friday there is a cleaning task.
For the "cleaning" there is one outgoing arrow therefore only one <successor> child with validity Friday.
For the dashed line from Train 102 to Train 101 there is the last block connection. It has two successors because from Monday to Thursday there is day offset = 1 and over weekend from Friday till Monday we have to define a day offset of the to indicate that there are no tasks to be done during weekend.
Below blockRef="blk_101" is a reference to initial <block> of the connection. <successor> is a validity-dependent successors.
<blockConnection blockRef="blk_101"> <successor blockRef="blk_102" validityRef="vld_Mon-Thu"/> <successor blockRef="blk_cleaning" validityRef="vld_Fri"/> </blockConnection>
<blockConnection blockRef="blk_cleaning"> <successor blockRef="blk_102" validityRef="vld_Fri"/> </blockConnection>
Same referenced successor <block>, but different day offsets:
- Mon-Thu -> Tue-Fri
- Fri -> Mon
<blockConnection blockRef="blk_102"> <successor blockRef="blk_101" validityRef="vld_Mon-Thu" dayOffset="1"/> <successor blockRef="blk_101" validityRef="vld_Fri" dayOffset="3"/> </blockConnection>
Comparison with railML® 2
I would remove this. This is supposed to be a guide for LTCP. The comparison to railML 2 has no place here. If we want such comparison, then it should be put in its own place.
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