railML 3 issueshttps://development.railml.org/railml/version3/-/issues2024-01-11T14:43:02+01:00https://development.railml.org/railml/version3/-/issues/528Create wiki documentation for IS:etcsArea2024-01-11T14:43:02+01:00TT CoordinationCreate wiki documentation for IS:etcsAreaThe ETCS working group has created a draft documentation that can be used to create a wiki documentation for the railML 3 element etcsArea. The existing work includes a definition as well as example information.
This ticket is to create...The ETCS working group has created a draft documentation that can be used to create a wiki documentation for the railML 3 element etcsArea. The existing work includes a definition as well as example information.
This ticket is to create the wiki page from that documentation provided by the ETCS community.
ETCS document: https://cloud.railml.org/f/89860 <br>
Wiki page: https://wiki3.railml.org/wiki/IS:etcsArea3.3TT CoordinationTT Coordinationhttps://development.railml.org/railml/version3/-/issues/459ETCS signal modeling update2023-10-26T10:58:37+02:00IS CoordinationETCS signal modeling update## Description
The attribute **`<signalIS / isEtcsSignal> @srsVersion`** seems to be not used or needed. Therefore, it is suggested to deprecate it.
Further, there are other specific types of ETCS signals, which cannot be modelled curr...## Description
The attribute **`<signalIS / isEtcsSignal> @srsVersion`** seems to be not used or needed. Therefore, it is suggested to deprecate it.
Further, there are other specific types of ETCS signals, which cannot be modelled currently.
_tbd: details to follow_
### Background
Discussion about ETCS signals was initiated at railML ETCS use case working group meeting on February 26, 2021 (see [https://www.railml.org/en/event-reader/railml-is-etcs-telco-2021-02-26.html].
### Links
* Forum discussion
* Christian Rahmig, 20.02.2022: [https://www.railml.org/forum/index.php?t=msg&th=857&goto=2913&#msg_2913]
* Trac ticket
* #459
* Wiki documentation
* IS:isEtcsSignal: [https://wiki3.railml.org/wiki/IS:isEtcsSignal]
## Proposed solution railML 3.2
It is suggested to deprecate **`<signalIS / isEtcsSignal> @srsVersion`**.3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/460TrainProtectionElement vs ETCS2023-10-26T10:50:33+02:00IS CoordinationTrainProtectionElement vs ETCS## Description
It must be clarified how ETCS based systems shall be modelled. In particular, the usage of `<trainProtectionElement>` for ETCS based systems should be questioned.
### Background
The discussion was initiated at the railM...## Description
It must be clarified how ETCS based systems shall be modelled. In particular, the usage of `<trainProtectionElement>` for ETCS based systems should be questioned.
### Background
The discussion was initiated at the railML ETCS use case working group meeting on February 26, 2021 (see [https://www.railml.org/en/event-reader/railml-is-etcs-telco-2021-02-26.html]).
### Links
* Forum discussion
* Trac ticket
* #460
* Wiki documentation
* IS:trainProtectionElement: [https://wiki3.railml.org/wiki/IS:trainProtectionElement]
## Proposed solution railML 3.2
`<trainProtectionElement>` shall only be used for national and/or legacy train protection systems. ETCS based systems must not be modelled using `<trainProtectionElement>`.
This has to be clearly documented in the element annotations.3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/112Different codes for <ocp>2023-10-05T13:50:52+02:00Deleted UserDifferent codes for <ocp>## Description
Enhance <ocp> with an attribute for UIC country codes (UIC Leaflet 920-14).
```
<xs:attribute name="uicCountry" type="rail:tTwoDigits"/>
```
With railML version 2.2 the OCP child element <designator> has been introduced...## Description
Enhance <ocp> with an attribute for UIC country codes (UIC Leaflet 920-14).
```
<xs:attribute name="uicCountry" type="rail:tTwoDigits"/>
```
With railML version 2.2 the OCP child element <designator> has been introduced solving the issue with UIC country code and reference to infrastructure manager. This concept has been documented in the railML wiki. However, what is missing so far, is a real example station as best practice of an OCP.
### Links
* Forum discussion
* Trac ticket
* Wiki documentation (railML 2.x)
* OCP: [http://wiki.railml.org/index.php?title=IS:ocp]
* Designator: [http://wiki.railml.org/index.php?title=IS:designator]
* Dev:Registers.xml (Codelist): [http://wiki.railml.org/index.php?title=Dev:Registers]
## Proposed solution for railML 2.5
The OCP wiki page shall be enhanced with an example of an OCP having several designators. This example can be taken from Simple Example together with a figure.
Basically, solved with Best practice example of Pulsnitz on OCP wiki page
## Proposed solution for railML 3.x
Same to be done in the railML 3 wiki, page "Operational Point", section "Best practices"; example still missing3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/454Stopping places and platform edges2023-10-04T09:44:33+02:00IS CoordinationStopping places and platform edges## Description
In railML 3.1, a `<stoppingPlace>` can be linked with only one `<platformEdge>` using attribute `<stoppingPlace>@platformEdgeRef`.
In the railML ITMS use case working group it has been concluded that a stopping place can...## Description
In railML 3.1, a `<stoppingPlace>` can be linked with only one `<platformEdge>` using attribute `<stoppingPlace>@platformEdgeRef`.
In the railML ITMS use case working group it has been concluded that a stopping place can be linked with more than one platform edge. Therefore, the model shall be adapted for railML 3.2.
### Background
A stopping place marks the position on the track where the train shall stop.
A platform edge is the interface between passenger train and station.
### Links
* Forum discussion:
* Christian Rahmig, 20.01.2021: [https://www.railml.org/forum/index.php?t=msg&goto=2644&#msg_2644]
* Trac tickets:
* #438
* #454
* Wiki documentation:
* Use case "Integrated Traffic Management System" (ITMS): [https://wiki3.railml.org/wiki/UC:IS:IntegratedTMS]
* IS:stoppingPlace: [https://wiki3.railml.org/wiki/IS:stoppingPlace]
## Proposed solution railML 3.2
The existing attribute `<stoppingPlace>@platformEdgeRef` shall be marked DEPRECATED.
A new repeatable child element **`<allowsUsageOfPlatformEdge>`** shall be introduced to reference a `<platformEdge>` element.3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/266Default value for application direction (de: Vorgabewert für Element-Wirkrich...2023-10-02T10:24:44+02:00IS CoordinationDefault value for application direction (de: Vorgabewert für Element-Wirkrichtung)Almost every infrastructure element has an application direction related to the orientation of the track, where it is positioned. In railML 2.x, there is no default value for this direction, but it is often anticipated. Furthermore, the ...Almost every infrastructure element has an application direction related to the orientation of the track, where it is positioned. In railML 2.x, there is no default value for this direction, but it is often anticipated. Furthermore, the direction attribute is optional in railML 2.2, which may lead to unusable data, since e.g. a speedChange requires the direction information in order to be correctly interpreted.
## de:Zusammenfassung
Jedes Infrastruktur-Element besitzt eine Wirkrichtung bezogen auf die Orientierung des Gleises, an dem es sich befindet. In railML 2.x gab es keinen Vorgabewert für diesen Parameter und auch der Parameter selbst war nicht verpflichted. In railML 3.0 soll dies anders sein, um damit die Verwendung der Daten besser zu garantieren.
### Links
* Forum discussion:
* Torben Brand, 12.09.2018: [https://www.railml.org/forum/index.php?t=msg&th=607&goto=1959&#msg_1959]
* Christian Rahmig, 17.09.2018: [https://www.railml.org/forum/index.php?t=msg&th=607&goto=1967&#msg_1967]
* Thomas Nygreen, 29.12.2018: [https://www.railml.org/forum/index.php?t=msg&th=630&start=0&]
* Trac ticket:
* Wiki documentation:
## Proposed solution railML 3.1
All infrastructure elements deriving from base class NetEntity may have several locations in the topology network. These locations can be spot locations, linear locations or area locations.
Elements <spotLocation> and <linearLocation> have a mandatory attribute @applicationDirection with enumeration values "normal", "reverse" and "both".
Since there exist infrastructure elements, which do not have an application direction or where the value is unknown, it is suggested to mark the attribute @applicationDirection as optional. For all infrastructure elements, where an application direction exists and is known, the value has to be given. There shall be no further default value for @applicationDirection.3.3IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/39Wiki page about track connections and switches in IS2023-10-02T10:24:02+02:00IL CoordinationWiki page about track connections and switches in IS## Description
some examples would be preferred
review modelling concept, extract final solution, document the solution in the wiki
### Links
* Forum discussion:
* Christian Rahmig, April 2017: [https://www.railml.org/forum/index.ph...## Description
some examples would be preferred
review modelling concept, extract final solution, document the solution in the wiki
### Links
* Forum discussion:
* Christian Rahmig, April 2017: [https://www.railml.org/forum/index.php?t=msg&th=507&start=0&]
* Claus Feyling, May 2017: [https://www.railml.org/forum/index.php?t=msg&th=516&start=0&]
* Trac ticket:
* Wiki documentation:
* Switch: [http://wiki.railml.org/index.php?title=IS:switch]
* Crossing: [http://wiki.railml.org/index.php?title=IS:crossing]
* Connection between tracks: [http://wiki.railml.org/index.php?title=Dev:Connection_between_tracks]
## Proposed solution in railML 2.4
To clarify: is current implementation and usage as described in wiki article "Connection between tracks" acceptable or not?
Based on community feeback the current implementation is considered being sufficient for railML 2.x.
## Proposed solution in railML 3.x
Uncouple attributes @course and @orientation: for defining the course at a switch, it is suggested to always look from the switch begin into the direction of the switch branches. In that case, there are two options: "left" and "right".
The solution for crossings is more difficult and requires further investigation.3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/209The platform element2023-10-02T09:33:52+02:00IS CoordinationThe platform element## Description
As discussed in the forum thread [http://www.railml.org/forum/ro/index.php?group=1&offset=0&thread=66&id=274] the element `platformEdge` is not sufficient to model the complete functionality of the "operational platform" ...## Description
As discussed in the forum thread [http://www.railml.org/forum/ro/index.php?group=1&offset=0&thread=66&id=274] the element `platformEdge` is not sufficient to model the complete functionality of the "operational platform" such as interchanges between trains at different platform edges, which belong to the same platform. Therefore, a track-independent new element `platform` needs to be defined.
### Background
### Links
* Forum discussion:
* Carsten Weber, 20.11.2012: [https://www.railml.org/forum/index.php?t=msg&th=148&goto=456&#msg_456]
* Trac ticket
* Wiki documentation
* (railML 2) IS:platformEdge: [https://wiki.railml.org/index.php?title=IS:platformEdge]
## Proposed solution in railML 3.1
Elements <platform> and <platformEdge> are modelled in separately in the same container element <platforms>.
The <platform> needs elements/attributes for:
* width of the platform: space from platform edge to wall or from platform edge to platform edge
* reference to the platform edges that belong to this platform
* reference to a parent platform (if only segment)3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/255Modelling of road and rail bridges over tracks (de: Abbildung von Straßen-/Ba...2023-10-02T09:16:08+02:00CoordinationModelling of road and rail bridges over tracks (de: Abbildung von Straßen-/Bahn-Brücken über dem track)## Description
For measurement and asset management reasons in tools like http://www.gpsinfradat.de also brigdes over a railway line shall be modelled to be exchanged via railML. At the moment <kind> as a specific attributes of a brigde...## Description
For measurement and asset management reasons in tools like http://www.gpsinfradat.de also brigdes over a railway line shall be modelled to be exchanged via railML. At the moment <kind> as a specific attributes of a brigde is used (see http://wiki.railml.org/index.php?title=IS:bridge#Specific_Attributes_of_brigde).
A better modeling with railML 3 should be achieved.
### Background
### Links
* Forum discussion:
* Alexander Wolf, 24.10.2015: [https://www.railml.org/forum/index.php?t=msg&th=408&start=0&]
* Torben Brand, 08.09.2017: [https://www.railml.org/forum/index.php?t=msg&th=533&start=0&]
* Trac tickets:
* Wiki documentation:
## Proposed solution for railML 2.x
## Proposed solution for railML 3.1
Bridge, Tunnel and Level Crossing shall have a common base data type that defines a crossing of the railway track/line with "something else" (a road, another rail, a mountain, a valley, etc.).
Some basic modelling rules:
* it shall be possible to refer to an arbitrary number of "crossed elements" from one xCrossing
* the constructional realization (bridge or tunnel) of the xCrossing shall be implemented as attribute and shall not be included in the name of the functional infrastructure element
* if "something" crosses under the railway track/line, it shall be named an **underCrossing**
* if "something" crosses over the railway track/line, it shall be named an **overCrossing**
* if "something" crosses the railway track/line at same level (usually only roads, streets and ways), it shall be named **levelCrossing**3.1IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/365Extending enumeration for track condition areas2023-09-29T14:13:46+02:00IS CoordinationExtending enumeration for track condition areas## Description
In railML Infrastructure working group "ETCS" agreed on modelling ETCS track conditions in railML. The existing railML element **`<restrictionArea>`** shall be used for this. However, current list of track condition types...## Description
In railML Infrastructure working group "ETCS" agreed on modelling ETCS track conditions in railML. The existing railML element **`<restrictionArea>`** shall be used for this. However, current list of track condition types is not complete considering ETCS specification SUBSET-026.
### Background
ETCS SUBSET-026 defines in section 3.12.1 the concept of track conditions: "Track condition funcions are used to inform the driver and/or the train of a condition in front of the train."
In SUBSET-026, section 3.12.1.3 a variety of track conditions are provided. Within railML it shall be possible to model these different track conditions.
The following track conditions are mentioned in ETCS SUBSET-026, section 3.12.1.3:
* powerless section --> lower pantograph
* powerless section --> switch off main power switch
* air tightness
* sound horn
* non-stopping area
* tunnel stopping area
* change of traction system
* change of allowed current consumption
* big metal masses
* radio hole
* switch off regenerative brake
* switch off eddy current brake for service brake
* switch off eddy current brake for emergency brake
* switch off magnetic shoe brake
* station platform
### Links
* Forum discussion:
* Christian Rahmig, 01.11.2019: [https://www.railml.org/forum/index.php?t=msg&th=688&start=0&]
* Trac tickets:
* #365
* Wiki documentation:
* Use case "ETCS": [https://wiki2.railml.org/index.php?title=UC:IS:ETCS_track_net]
* IS:restrictionArea/3.2: [https://wiki3.railml.org/wiki/IS:restrictionArea/3.2]
## Proposed solution railML 3.2
The following values shall be added for the enumeration attribute **`<restrictionArea>@type`**:
* soundHorn
* tunnelStoppingArea
* changeTractionSystem
* changeAllowedCurrentConsumption
* bigMetalMasses3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/368Definition of a track2023-09-29T12:51:42+02:00IS CoordinationDefinition of a track## Description
The current definition of a track to be used for railML 3.1 is too strict as it allows tracks only to be limited by buffer stops, switches and crossings. This strict definition shall be revised and adapted in order to all...## Description
The current definition of a track to be used for railML 3.1 is too strict as it allows tracks only to be limited by buffer stops, switches and crossings. This strict definition shall be revised and adapted in order to allow for very long and very short tracks.
### Background
In railML 2.x, the railway track network topology is based on the element `<track>`. For a functioning data exchange it is necessary that there is a common understanding of the topology. However, the definition of a track in railML 2.x is rather weak: **A `<track>` represents one of possibly multiple tracks (= "pair of rails") that make up a line.** (see railML wiki).
For railML 3.x a more strict definition of a track has been chosen: **A Track is defined by a railway section between two switches/crossings or between a switch/crossing and a buffer stop.** Since the railway network topology in railML 3.x is based on RailTopoModel elements `<netElement>` and `<netRelation>`, the `<track>` has no topologic dimension. Considering the `<track>` as a pure NetEntity derived object that is placed on top of a topology, the track does not have to be defined that strictly. It is possible to allow for a weaker definition, too.
### Links
* Forum discussion:
* Stefan Hubrig, 02.10.2019: [https://www.railml.org/forum/index.php?t=msg&th=684&goto=2252&#msg_2252]
* Trac tickets:
* #368
* Wiki documentation:
* (railML 2.x) IS:track: [https://wiki2.railml.org/index.php?title=IS:track]
* IS:track: [https://wiki3.railml.org/wiki/IS:track]
## Proposed solution railML 3.2
Weaken the definition of a track in railML 3.x. In order to group short tracks to longer tracks, the reference attribute **`<track>@belongsToParent`** can be used.
Proposal for a definition of **Track**: A track is a railway section that can be traversed by a train in a continuous motion.
Adapted documentation in model (exported to wiki and schema).3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/478New element for mileage change modelling2023-09-29T12:43:45+02:00IS CoordinationNew element for mileage change modelling## Description
The mileage cange shall be modelled explicitly with a new funtional infrastructure element. This solution shall replace / complement the approach of RTM based `<linearPositioningSystem>` and its anchor points.
### Backgr...## Description
The mileage cange shall be modelled explicitly with a new funtional infrastructure element. This solution shall replace / complement the approach of RTM based `<linearPositioningSystem>` and its anchor points.
### Background
The request resulted from discussions in the railML ETCS use case working group.
### Links
* Forum discussion:
* Karl-Friedemann Jerosch, 16.09.2021: [https://www.railml.org/forum/index.php?t=msg&th=829&start=0&](https://www.railml.org/forum/index.php?t=msg&th=829&start=0&)
* Heidrun Jost, 01.10.2021: [https://www.railml.org/forum/index.php?t=msg&th=829&goto=2834&#msg_2834](https://www.railml.org/forum/index.php?t=msg&th=829&goto=2834&#msg_2834)
* Git issues:
* #478
* Wiki documentation:
## Proposed solution railML 3.2
New container element `<mileageChanges>` shall be added inside `<functionalInfrastructure>`. It includes a list of `<mileageChange>` elements.
The `<mileageChange>` has an attribute `@type` with values "gap", "overlap".
The `<mileageChange>` references child elements `<spotLocation>` via attributes `@from` and `@to`.
The `<mileageChange>` has two child elements `<spotLocation>`. One provides the link to the "incoming" mileage and the other one provides the link to the "outgoing" mileage.3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/449Movable bridge2023-09-28T15:06:46+02:00IL CoordinationMovable bridge## Description
There are bridges (overcrossings), which do not provide enough height for ships to pass underneath. They are therefore temporarily moved out of the way of the ships. The normal position of a bascule bridge is "closed", i....## Description
There are bridges (overcrossings), which do not provide enough height for ships to pass underneath. They are therefore temporarily moved out of the way of the ships. The normal position of a bascule bridge is "closed", i.e. passable by trains. This position needs to be supervised by the interlocking system. However, the steering control of the bridge itself is outside of the interlocking.
### Links
* forum discussion:
* Jörg von Lingen, 06.12.2020: [https://www.railml.org/forum/index.php?t=msg&th=781&start=0&]
* Trac tickets
* #449
* Wiki documentation
* IS:overCrossing: [https://wiki3.railml.org/wiki/IS:overCrossing]
* IS:underCrossing: [https://wiki3.railml.org/wiki/IS:underCrossing]
## Proposed solution railML 3.2
### Required modifications in `<interlocking>`
- inherit class LogicalDevice
- `<refersTo>` will be to the undercrossing in IS
- technicalOpenTime, technicalClosingTime
- typicalNonPassableTime
### Required modifications in `<infrastructure>`
The enumeration attribute `@constructionType` in element `<*Crossing>` shall be extended with new value `"basculeBridge"` or `"movableBridge"` or `"movableUnderCrossing"`.3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/461Loading gauge profiles2023-09-28T14:00:55+02:00IS CoordinationLoading gauge profiles## Description
The current implementation of `<loadingGauge>` misses static and kinematic reference profiles.
### Background
The discussion was initiated in the railML working group dealing with the ETCS use case (see [https://wiki3.r...## Description
The current implementation of `<loadingGauge>` misses static and kinematic reference profiles.
### Background
The discussion was initiated in the railML working group dealing with the ETCS use case (see [https://wiki3.railml.org/wiki/UC:IS:ETCS_track_net]).
### Links
* Forum discussion
* Christian Rahmig, 17.01.2022: [https://www.railml.org/forum/index.php?t=msg&th=850&start=0&]
* Trac ticket
* #461
* Wiki documentation
* IS:loadingGauge: [https://wiki3.railml.org/wiki/IS:loadingGauge]
## Proposed solution railML 3.2
Two new child elements shall be added to `<loadingGauge>`:
* **`<staticProfile>`** with attributes **`@width`** (meters) and **`@height`** (meters) to describe the static loading gauge reference profile
* **`<kinematicProfile>`** with attributes **`@width`** (meters) and **`@height`** (meters) to describe the kinematic loading gauge reference profile3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/484Modelling switch crossings in infrastructure2023-09-27T15:10:30+02:00IS CoordinationModelling switch crossings in infrastructure## Description
It was suggested to provide a solution for modelling a double switch crossing as composition of two ordinary switches. However, it shall be also possible, to model a double switch crossing as a single element. Same applie...## Description
It was suggested to provide a solution for modelling a double switch crossing as composition of two ordinary switches. However, it shall be also possible, to model a double switch crossing as a single element. Same applies for the single switch crossing.
### Background
In infrastructure data base of BaneNor double switch crossings are included as component elements. ETCS use case working group suggested to transfer this composition also into the railML schema.
### Links
* Forum discussion:
* Martin Zien, 06.12.2021: [https://www.railml.org/forum/index.php?t=msg&th=839&goto=2855&#msg_2855](https://www.railml.org/forum/index.php?t=msg&th=839&goto=2855&#msg_2855)
* Development issues:
* #484
* Wiki documentation:
* (railML 3) IS:switchIS: [https://wiki3.railml.org/wiki/IS:switchIS](https://wiki3.railml.org/wiki/IS:switchIS)
* (railML 3) IL:switchIL: [https://wiki3.railml.org/wiki/IL:switchIL](https://wiki3.railml.org/wiki/IL:switchIL)
## Proposed solution in railML 3.2
Introduce new switch **`@type`** enumeration values:
* `"switchCrossingPart"` to be used for ordinary switches that are actually part of a double switch crossing or simple switch crossing
Add new attribute **`@belongsToParent`** in element `<switchIS>` to reference the aggregated switch from its parts/partitions.3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/496Reference to train from speedSection2023-08-22T15:01:44+02:00IS CoordinationReference to train from speedSection## Description
It is necessary to have a reference from a speedSection to the part of the train, for which the speed is valid.
### Background
### Links
* Forum discussion
* Karl-Friedemann Jerosch, 08.12.2021: [https://www.railml.o...## Description
It is necessary to have a reference from a speedSection to the part of the train, for which the speed is valid.
### Background
### Links
* Forum discussion
* Karl-Friedemann Jerosch, 08.12.2021: [https://www.railml.org/forum/index.php?t=msg&th=840&goto=2858&#msg_2858](https://www.railml.org/forum/index.php?t=msg&th=840&goto=2858&#msg_2858)
* Trac ticket
* #496
* Wiki documentation
* IS:isSpeedSignal: [https://wiki3.railml.org/wiki/IS:isSpeedSignal](https://wiki3.railml.org/wiki/IS:isSpeedSignal)
## Proposed solution in railML 3.2
Enumeration value `"midOfTrain"` of attribute `@trainRelation` (tTrainRelation) shall remain.
Attribute `<signalIS/isSpeedSignal>@trainRelation` shall be marked deprecated.
New attribute `<speedSection>@refersToTrain` (tTrainRelation) shall be introduced.3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/319MaxTrainCurrent (de: Oberstrombegrenzung)2022-05-09T17:41:04+02:00IS CoordinationMaxTrainCurrent (de: Oberstrombegrenzung)## Description
The electrification of a railway line is currently not completely modelled. In particular, there is missing an attribute or an element to describe the maximum allowed current and power of a train. For closing this gap, it...## Description
The electrification of a railway line is currently not completely modelled. In particular, there is missing an attribute or an element to describe the maximum allowed current and power of a train. For closing this gap, it is suggested to extend the existing element <electrificationChange>.
### Background
According to EN 50388 the maximum allowed current and power of a train on some railway line sections is limited by the electrification. This may have an influence on train acceleration, running times and energy consumptions.
### Links
* Forum discussion
* Dr. Thorsten Frenzke, January 2018: [https://www.railml.org/forum/index.php?t=msg&th=549&start=0&]
* Wiki documentation
* IS:electrification: [http://wiki.railml.org/index.php?title=IS:electrification]
* IS:electrificationChange: [http://wiki.railml.org/index.php?title=IS:electrificationChange]
## Proposed solution for railML 2.4
The <electrificationChange> element shall be extended with a new optional child element <energyCatenary>.
This new child element contains an attribute @maxPantoCurrentStandstill to describe the maximum current per pantograph in Ampere for standing vehicles.
Further, <energyCatenary> shall contain an optional, repeatable child element <maxTrainCurrentDriving>. This element has the parameter @maxCurrent to describe the maximum allowed train current in Ampere. <maxTrainCurrentDriving> further contains an "any attribute extension point" in order to allow for definition of further parameters that influence the maximum train current. One example for such a parameter: the train type.
Example based on proposed solution:
```
<electrificationChange id="ec01" pos="0">
<maxTrainCurrent maxCurrent="800" type="standstill" validFor="pantograph"/>
<maxTrainCurrent maxCurrent="3000" type="driving" validFor="train" extension:trainType="passenger"/>
<maxTrainCurrent maxCurrent="1200" type="driving" validFor="train" extension:trainType="freight"/>
</electrificationChange>
```
The <energyCatenary> child element shall be also added to the <electrification> element. Resulting example:
```
<infraAttrGroups>
<infraAttributes id="ifa01">
<electrification frequency="16.7" voltage="15000" type="overhead">
<maxTrainCurrent maxCurrent="800" type="standstill" validFor="pantograph"/>
<maxTrainCurrent maxCurrent="3000" type="driving" validFor="train" extension:trainType="passenger"/>
<maxTrainCurrent maxCurrent="1200" type="driving" validFor="train" extension:trainType="freight"/>
</electrification>
</infraAttributes>
</infraAttrGroups>
```
A first version of the solution has been implemented for railML 2.4. Still missing: documentation in Wiki.
## Proposed solution for railML 3.x
The maximum train current need to be described for railML 3.1 related use case "Network Statement". It is intended to have a similar implementation of <energyCatenary> under <electrification>3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/367Extending the <speedProfile> element2022-04-25T15:00:54+02:00IS CoordinationExtending the <speedProfile> element## Description
The current implementation of speed profiles in railML 3.1 is insufficient w.r.t. parameters required by the ETCS specification. railML use case working group "ETCS" agrees on modifying the `<speedProfile>` implementation...## Description
The current implementation of speed profiles in railML 3.1 is insufficient w.r.t. parameters required by the ETCS specification. railML use case working group "ETCS" agrees on modifying the `<speedProfile>` implementation in railML 3.x.
### Background
### Links
* Forum discussion:
* Thomas Nygreen, 24.12.2018: [https://www.railml.org/forum/index.php?t=msg&th=627&goto=2053&#msg_2053]
* Thomas Nygreen, 25.12.2018: [https://www.railml.org/forum/index.php?t=msg&th=627&goto=2054&#msg_2054]
* Christian Rahmig, 01.11.2019: [https://www.railml.org/forum/index.php?t=msg&th=686&start=0&]
* Trac tickets:
* #367
* Wiki documentation:
* use case "ETCS Track Net": [https://wiki2.railml.org/index.php?title=UC:IS:ETCS_track_net]
* CO:speedProfile: [https://wiki3.railml.org/wiki/CO:speedProfile]
## Proposed solution railML 3.2
### basic speed profile
It is suggested to define a new boolean attribute **`<speedProfile>@isBasicSpeedProfile`** in order to identify basic speed profiles. If the speed profile is not a basic one, further information has to be provided using `<speedProfile>` child elements.
### maximum cant deficiency
The maximum cant deficiency shall be modelled with a new attribute **`<speedProfile>@maxCantDeficiency`** (integer, 80..300 mm). At the same time, the existing attribute **`<speedProfile><trainType>@cantDeficiency`** shall be marked DEPRECATED.
### train type
The enumeration attribute **`<speedProfile><trainType>@type`** values shall be adapted: values `"mixed"` and `"all"` shall be added; value `"tiltingPassenger"` shall be removed.
As requested in the forum the railML model shall allow for multiple train types to be included in one `<speedProfile>` element. Thus, the multiplicity of `<trainType>` shall be changed from `0..1` to `0..*`
The ETCS train category number modelled with attribute **`<speedProfile / trainType / etcsSpeedProfile>@etcsTrainCategoryNumber`** shall not be used as "leading" information, but only as "derived" information. The parameters that define its value are:
* `<speedProfile><trainType>@type`
* `<speedProfile><braking>@airBrakeApplicationPosition`
* `<speedProfile>@maxCantDeficiency`3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/366Extending the <balise> element2022-04-25T14:41:43+02:00IS CoordinationExtending the <balise> element## Description
The current implementation of the **`<balise>`** element in railML 3 is insufficient w.r.t. parameters required by the ETCS specification. The railML use case working group "ETCS" has agreed to extend the model of the bal...## Description
The current implementation of the **`<balise>`** element in railML 3 is insufficient w.r.t. parameters required by the ETCS specification. The railML use case working group "ETCS" has agreed to extend the model of the balise.
### Background
ETCS SUBSET-026 lists a number of parameters for balises, which are currently not modelled in railML 3.1.
### Links
* Forum discussion:
* Christian Rahmig, 04.02.2013: https://www.railml.org/forum/index.php?t=msg&th=135&goto=513&#msg_513
* Christian Rahmig, 11.02.2019: https://www.railml.org/forum/index.php?t=msg&th=651&goto=2140&#msg_2140
* Christian Rahmig, 01.11.2019: https://www.railml.org/forum/index.php?t=msg&th=687&start=0&
* Davide Venturucci, 07.05.2020: https://www.railml.org/forum/index.php?t=msg&th=725&start=0&
* Jorgen Strandberg, 04.04.2022: https://www.railml.org/forum/index.php?t=msg&th=875&start=0&
* Trac tickets:
* #174: Grouping of balises and their attributes
* #366
* Wiki documentation:
* Use Case "ETCS Track Net": [https://wiki2.railml.org/index.php?title=UC:IS:ETCS_track_net]
* IS:balise: [https://wiki3.railml.org/wiki/IS:balise]
* IS:baliseGroup: [https://wiki3.railml.org/wiki/IS:baliseGroup]
## Proposed solution railML 3.2
### balise group
Balise and balise group shall be modelled using own elements. Therefore, element **`<baliseGroup>`** shall be added.
### balise parameters
#### balise type
The enumeration attribute **`<balise>@type`** currently has the values `"fixed"` and `"transparent"`. The latter value is misleading and shall be renamed to `"controlled"`.
#### Eurobalise
The Eurobalise is a specific type of balise. It shall be modelled using a child element **`<balise/isEurobalise>`** with attribute **`@mVersion`** (non-negative integer) to specify the ETCS software version implemented for this balise.
#### identification of the balise within a balise group
The following new parameters shall be implemented:
* **`<balise/isEurobalise>@positionInGroup`** is used to provide the balise number in group
* **`<balise>@distanceToPredecessorBaliseWithinGroup`** is used to describe the distance between a balise and its predecessor balise in the group
* **`<balise/isEurobalise>@duplicate`** is used to flag a Eurobalise as a duplicate Eurobalise.
* **`<balise>@belongsToBaliseGroup`** is used to refer to the balise group where the balise belongs to.
#### balise group related relicts in balise
* DEPRECATE **`<balise>@belongsToParent`**
* DEPRECATE **`<balise>@isBaliseGroup`**
* DEPRECATE **`<balise>@baliseGroupType`**
### balise group parameters
#### ETCS information
It is suggested to add a new child element **`<isEurobaliseGroup>`** with new attributes:
* **`@countryID`** (integer, 0..1023; corresponds to NID_C)
* **`@groupID`** (integer, 0..16383; corresponds to NID_BG)
* **`@usesPackage44`** (integer, 0..511; corresponds to NID_XUSER)
* **`@virtualCoverageID`** (integer, 0..63; corresponds to NID_VBCMK)
Additionally, the ETCS software version shall be modelled with a new parameter **`<baliseGroup/isEurobaliseGroup>@mVersion`** (non-negative integer).
#### balise group linking
The reaction on balise message consistency errors w.r.t. linked balises shall be modelled with two new attributes **`<baliseGroup/isEurobaliseGroup>@linkReactionNominal`** and **`<baliseGroup/isEurobaliseGroup>@linkReactionReverse`**. Both attributes shall be modelled as enumeration attribute with values `"trainTrip"`, `"applyServiceBrake"` and `"noReaction"`.
`"nominal"` corresponds to the travel direction with increasing mileage. `"reverse"` corresponds to the travel direction with decreasing mileage.
Additionally, a boolean attribute **`@isLinked`** can be used to provide basic information that the Eurobalise group is linked with a reaction. If **`@isLinked="false"`**, the link reaction attributes must not be provided.
#### location accuracy
It is suggested to introduce a new attribute **`<baliseGroup/isEurobaliseGroup>@locationAccuracy`** (decimal, -63..63 m).
#### balise group types
Two new child elements shall be used to define functional and application type of the balise group:
* **`<baliseGroup/applicationType>`** to specify the application type of the balise group
* **`@value`** with possible values (extendable list): `"ETCS"`, `"GNT"`, `"NTC"`, `"ZBS"`, `"TBL1+"` etc.
* **`<baliseGroup/functionalType>`** to specify the functional type
* **`@value`** with possible values (non-extendable list): `
* `"announcementLevelTransition"` (In relation to this balise group, at least the UNISIG Packet 41 including D_LEVELTR < 32767 will be transmitted to the train (via balise: ETCS L1 or L2 or via radio: ETCS L2 only) for the mileageDirection valid for this function.),
* `"border"` (In relation to this balise group, at least the UNISIG Packet 41 including D_LEVELTR = 32767 will be transmitted to the train (via balise: ETCS L1 or L2 or via radio: ETCS L2 only) for the mileageDirection valid for this function.),
* `"handover"` (This balise group transmits at least a UNISIG Packet 131 for the mileageDirection valid for this function.),
* `"sessionTermination"` (This balise group transmits at least a UNISIG Packet 42 including Q_RBC=0 for the mileageDirection valid for this function.),
* `"signal"` (This balise group is linked physically (in case of ETCS L1) or logical (in case of ETCS Level 2) with a main signal. In relation to this balise group, at least the UNISIG Packets MA (12: ETCS L1 or 15: ETCS L2), 21 and 27 will be transmitted to the train (via balise: ETCS L1 or via radio: ETCS L2) for the mileageDirection valid for this function.),
* `"infill"` (This balise group transmits at least a UNISIG Packet 136 for the mileageDirection valid for this function.),
* `"stopIfInShunting"` (This balise group transmits at least a UNISIG Packet 132 including Q_ASPECT=0 for the mileageDirection valid for this function.),
* `"odometryPurposeOnly"` (Each balise of this balise group transmits only UNISIG defined ETCS telegram header and UNISIG Packet 255 (End of information) for the mileageDirection valid for this function.),
* `"sessionEstablishment"` (This balise group transmits at least a UNISIG Packet 42 including Q_RBC=1 for the mileageDirection valid for this function.),
* `"networkRegistration"` (This balise group transmits at least a UNISIG Packet 45 for the mileageDirection valid for this function.)
* `"announcementTemporarySpeedRestriction"` (This balise group transmits at least a UNISIG Packet 65 for the mileageDirection valid for this function.),
* `"revocationTemporarySpeedRestriction"` (This balise group transmits at least a UNISIG Packet 66 for the mileageDirection valid for this function.)
* `"trackAheadFree"` (This balise group transmits at least a UNISIG Packet 90.)
* `"stopIfInStaffResponsible"` (This balise group transmits at least a UNISIG Packet 137 including Q_SRSTOP=0 for the mileageDirection valid for this function.)
* **`@mileageDirection`** for direction dependency (`"nominal"`, `"reverse"`)
#### balise group coverage
The new enumeration attribute **`@coverage`** with values `"physical"`, `"virtual"`, `"both"` and `"none"`.
#### reference to single balises
There is no element referencing from a balise group to its contained balises. Instead, single balises (if existent) reference the balise group they belong to.
The new attribute **`@numberOfBalisesInGroup`** (positive integer) gives a counting indication how many balises belong to the balise group.
### references
As discussed in the forum a balise may "protect" a signal. Consequently, it was suggested to create a reference from a signal to its "protecting" balise. This may be realized with a reference attribute **`<signalIS>@protectedByBaliseGroup`**.
Further, a `<baliseGroup>` can reference additional infrastructure elements using repeatable child element **`<baliseGroup/connectedWithInfrastructureElement>`** with parameters
* **`@ref`** for referencing the ID of the infrastructure
* **`@type`** for specifying the connection as `"logical"` or `"physical"`3.2IS CoordinationIS Coordinationhttps://development.railml.org/railml/version3/-/issues/488naming RadioBlockCenter vs. RadioBlockCentre2022-04-19T14:25:08+02:00IL Coordinationnaming RadioBlockCenter vs. RadioBlockCentreIn literature and standards the spelling "Radio Block **Center**" is everywhere used. However, the British spelling would be "**Centre**", which is currently used in railML-IL.
A renaming to the commonly used spelling "Center" would be ...In literature and standards the spelling "Radio Block **Center**" is everywhere used. However, the British spelling would be "**Centre**", which is currently used in railML-IL.
A renaming to the commonly used spelling "Center" would be desirable.
As decided in coordinators conf call on February 21, 2022, the British way of writing shall be used:
* RadioBlockCentre
* RadioBlockCentreBorder3.2IL CoordinationIL Coordination