| [railML 3.2] Modelling of Scheduling Rules [message #3388] |
Fri, 15 November 2024 14:48  |
David Lichti
Messages: 51
Registered: December 2020
|
Member |
|
|
Dear community,
In the context of a new infrastructure export with railML 3.2, we need to export a set of properties which could be summarized as scheduling rules. They are used during assisted or automatic train scheduling:
- stopping time: minimal time between arrival and departure for trains movements that stop at an operational point.
- shunting time: minimal time between arrival and departure for shunting movement at an operational point.
- headway time: minimal buffer time between two subsequent trains at an operational point.
- mandatory stops: rules for mandatory stops at an operational point depending on train type and operational context.
I could not find any suitable elements to represent this data in standard railML. Any hints or suggestions?
Best regards
[Updated on: Tue, 19 November 2024 07:22] Report message to a moderator |
|
|
|
| Re: [railML 3.2] Modelling of Scheduling Rules [message #3428 is a reply to message #3388] |
Mon, 13 January 2025 14:21  |
christian.rahmig
Messages: 505
Registered: January 2016
|
Senior Member |
|
|
Dear David,
thank you for your input.
I would consider these "scheduling rules" as a part of more generic "operating rules". Therefore, my first idea was to use the element //operationalPoint/opOperation [1] and extend it with missing information. What do you think?
[1] https://wiki3.railml.org/wiki/IS:opOperation
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
| Re: [railML 3.2] Modelling of Scheduling Rules [message #3442 is a reply to message #3433] |
Fri, 17 January 2025 10:44 |
christian.rahmig
Messages: 505
Registered: January 2016
|
Senior Member |
|
|
Dear David,
thank you for the input. Some thoughts related to the provided XML:
* values like "PT3M" seem to contain several information including time value (3) and unit (M) and something else (PT). Maybe it makes sense to separate these information in different attributes and make use of SI units like s (seconds).
* how about integrating schedulingRules into operationalRules (see #392)? Different types of rule could be distinguished using a type attribute.
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML 3.2] Modelling of Scheduling Rules [message #3443 is a reply to message #3442] |
Fri, 17 January 2025 15:10 |
David Lichti
Messages: 51
Registered: December 2020
|
Member |
|
|
Hi Christian,
The different duration values are given in xs:duration format: P[eriod]T[ime]3M[inutes]. This is a standard XML type, and it is already used in several places of the railML 3 standard.
It may be feasible to merge operational and scheduling rules into one type. However, we (TPS) would still have to produce separate elements (of that same type) to represent separate business entities with different identifiers. At least in the case of signals, this would also imply the need to be able to reference more than one rule element.
But then, there would be the possibility of contradicting rules. It would not happen in our export, since the original data behind these two rules at the same object would map to disjoint sets of attributes. But for the general case, it may be necessary to introduce semantic constraints to handle this issue.
Best regards
David
|
|
|
|
Members
Search
Help
Login
Home
