Dev:changes/2.5

From railML 2 Wiki
Jump to navigation Jump to search
RailML Trademark RGB V2.png
XML Railway exchange format
https://railML.org
Latest release: 2.5
(September 1st, 2021)
 
Main Menu
 
Subschemas
XML tree
UML diagrams
Use cases
Versions & Changes

railML® schema changes between railML® 2.4 and railML® 2.5
 

This site is intended to collect the schema changes between railML® 2.4 and railML® 2.5.

A complete diff comparison will soon be available under Dev:changes/2.5/diff.

Changes are also marked on the element pages with (introduced with version 2.5) for introduced components and (deprecated with version 2.5) for components that became obsolete. All occurances of these tags are listed in Category:Intro/2.5 respectively Category:Depr/2.5.

For changes with other version upgrades see Dev:changes.

Common Subschema

New child <projects> of <metadata>

Fact: Describing the purpose of the model in a related project.
Reason: Requirement from the community.
Related Development Tickets: #390
New element(s): <projects>, <project>, <designator>, <alternative>, <phase>, <revision>, <objectsRevised>, <revisedBy>, <checkedBy>, <approvedBy>

<organizationalUnits> has been extended with child <vehicleOwner>

Fact: <organizationalUnits> has been extended with child <vehicleOwner>
Related Development Tickets: #435
New element(s): <vehicleOwner>, <additionalName>, <designator>
Updated element(s): <organizationalUnits>

Several elements have been extended with child <designator>

Fact: Several elements have been extended with child <designator>
Related Development Tickets: #435
New element(s): <designator>
Updated element(s): <concessionaire>, <contractor>, <customer>, <infrastructureManager>, <operationalUndertaking>, <railwayUndertaking>, <vehicleManufacturer>, <vehicleOperator>

Timetable Subschema

New @onRequest for <trainPart>

Fact: new attribute @onRequest (bool) has been added in element <trainPart> in order to allow for standardized modelling of onRequest journeys.
Reason: Required by railML® partner. Also this should help avoiding modelling of onRequest journeys using special train categories.

File:Anpassungen railML 2 -Bedarfszüge.pdf

Related Development Tickets: #372
New attribute(s): @onRequest
Updated element(s): <trainPart>

New value other:anything for <category>@trainUsage

Fact: <category>@trainUsage has been extended to allow for custom values
Reason: The demand for more distinguished categories appeared in this discussion (link to the railML® website)
Related Development Tickets: #375
Related Commits: [1039] (Note on legacy SVN commits)
Updated XSD file(s): railwayBaseTypes.xsd
Updated attribute(s): <category>@trainUsage
Updated element(s): <category>

New values conceptual and offered for <trainPartSequence>@pathStatus

Fact: <trainPartSequence>@pathStatus has been extended to allow for the values conceptual and offered to improve how to express the state of an slot order
Reason: The demand for clearer modelling of the states for slot ordering showed up in this discussion (link to the railML® website)
Related Development Tickets: #378
Related Commits: [1039] (Note on legacy SVN commits)
Updated attribute(s): <trainPartSequence>@pathStatus
Updated element(s): <trainPartSequence>@pathStatus

New child <originalTrackInfo> for <ocpTT>

Fact: New child <originalTrackInfo> for <ocpTT>
Reason: Allow for better communication of track changes
Related Development Tickets: #378
Related Commits: [1039] (Note on legacy SVN commits)
Updated XSD file(s): timetable.xsd
New element(s): <originalTrackInfo>, <trackInfo>
Updated element(s): <ocpTT>

New children <origin> and <destination> for <trainPart>

Fact: New children <origin> and <destination> for <trainPart>
Reason: allows for specifying information about the origin/destination of the train if it cannot be derived from its path (trains entering/leaving the operated area).
Related Development Tickets: #378
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <origin>, <destination> & their respective childs
Updated element(s): <trainPart>

New Child <announcementRef> for <stopDescription> and <trainPart>

Fact: New Child <announcementRef> for <stopDescription> and <trainPart>
Reason: broad revision of annotations
Related Development Tickets: #378
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <announcementRef> & childs
Updated element(s): <stopDescription>

New @type for <annotation>; changed multiplicity for <text>

Fact: New @type for <annotation>; multiplicity of <text> changed from [1..∞] to [0..∞]
Reason: broad revision of annotations: annotations should point to other content than text.
Related Development Tickets: #358
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): <annotation>@type
Updated element(s): <annotation>, <text>

New child <announcements> of <timetable>

Fact: New child <announcements> of <timetable>
Reason: broad revision of annotations
Related Development Tickets: #358
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <announcements> & children
Updated element(s): <timetable>

@processStatus set to deprecated for <trainPart>, <train> and <trainGroup>

Fact: The attribute @processStatus was set to deprecated for <trainPart>, <train> and <trainGroup>.
Reason: existing usage of attribute turned out to be non standardized. In order disencourage further use of the attribute it was decided to deprecate it as it seemed not feasible to unify its use.
Related Development Tickets: #364
Related Commits: [1039] (Note on legacy SVN commits)
Updated attribute(s): processStatus
Updated element(s): <trainPart>, <train>, <trainGroup>

@onRequest set to deprecated for <operatingDay>

Fact: The attribute @onRequest was set to deprecated for <operatingDay>.
Reason: existing usage of attribute was deemed overly complicated and not widely used. In order disencourage further use of the attribute it was decided to deprecate it and recommend usage of the attribute @onRequest of the <trainPart>.
Related Development Tickets: #372
Related Commits: [1039] (Note on legacy SVN commits)
Updated attribute(s): onRequest
Updated element(s): <trainPart>, <operatingDay>

@shuntingTime set to deprecated for <ocpTT>

Fact: The attribute @shuntingTime was set to deprecated for <ocpTT>.
Reason: clarification of specification of shuntingTimes. There were actually 2 ways of specifying shunting times. @shuntingTime was deprecated in favor of @shuntingTime.
Related Development Tickets: #343
Related Commits: [1039] (Note on legacy SVN commits)
Updated attribute(s): @shuntingTime
Updated element(s): <ocpTT>

New attribute @parentRef added to <category>

Fact: The attribute @parentRef was added in order to allow for hierarchies of categories.
Reason: Requirement from the community.
Related Development Tickets: #437
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): @parentRef
Updated element(s): <category>

New attribute @organizationalUnitRef added to <category>

Fact: The attribute @organizationalUnitRef was added in order to differentiate between categories of the same name that are related to different organizationalUnits and thus may differ in semantics.
Reason: Requirement from the community.
Related Development Tickets: #436
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): @organizationalUnitRef
Updated element(s): <category>

New attribute @parentRef added to <trainGroup>

Fact: The attribute @parentRef was added in order to allow for hierarchical train groups. It was also decided to change the cardinalities of <trainGroup> regarding its child <trainRef> to allow for <trainGroup>s that do not refer to any <train>s but rather are referred to by other <trainGroup>s as their parent.
Reason: Requirement from the community.
Related Development Tickets: #470
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): @parentRef
Updated element(s): <trainGroup>

New attribute @lastModified added to <trainPart>

Fact: In order to allow communication of changes to certain train parts a new optional attribute was added to <trainPart>. With this it is possible to specify the last change date for a trainParts change.
Reason: Requirement from the community.
Related Development Tickets: #471
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): @lastModified
Updated element(s): <trainPart>

New element <alternativeSectionsTT> added to <ocpTT>

Fact: In order to allow specification of alternative ways to reach the next OCP in an microscopic infrastructure model a new element was added to the <ocpTT> called <alternativeSectionsTT>. It serves as a container for a number of <alternativeSectionTT> elements that can each be annotated with a priority in order to describe the priority of their use by a managing TMS. It is important to note that the arrival and departure times of the following ocpTT must not be dependent on which way actually is chosen.
Reason: Requirement from the community.
Related Development Tickets: #381
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <alternativeSectionsTT> & children
Updated element(s): <ocpTT>

New element <patternTrains>

Fact: Support for very early planning stages.
Reason: Requirement from the community.
Related Development Tickets: #432
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <patternTrains> & Children

New element <patternTrainParts>

Fact: Support for very early planning stages.
Reason: Requirement from the community.
Related Development Tickets: #432
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <patternTrainParts> & children

New element <distributions>

Fact: Support for very early planning stages.
Reason: Requirement from the community.
Related Development Tickets: #433
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <distributions> & children

New enumeration value expected for <times>/@scope

Fact: Support for forcasted arrival and departure times.
Reason: Requirement from the community.
Related Development Tickets: #472
Related Commits: [1039] (Note on legacy SVN commits)
Updated attribute(s): @scope

<trigger>: new children <manualTrigger>, <informationAreaTrigger>

Fact: <trigger> has been extended with children <manualTrigger> and <informationAreaTrigger>
Related Development Tickets: #472
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <manualTrigger>, <informationAreaTrigger>
Updated element(s): <trigger>

Infrastructure Subschema

New @trainProtectionSystem for <trainProtectionChange> and <trainProtection>

Fact: new attribute @trainProtectionSystem (string) has been added in elements <trainProtectionChange> and <trainProtection>.

@trainProtectionSystem shall reference values from codelist TrainProtectionSystems.xml.

Reason: <trainProtectionChange> and <trainProtection> were missing a parameter to reference the train protection system – compare the forum discussion (link to the railML® website).
Related Development Tickets: #356
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): @trainProtectionSystem
Updated element(s):

@dir deprecated for many elements

Fact: For many Elements @dir gets deprecated according to the following guidelines:
  • Rule 1: @dir is usefull as application direction.
    Applies for elements without extent (without @length attribute)
    examples: balise, border, derailer, signal, stopPost... usage: @dir describes the direction of travel, for which the element applies. Possible values are "up", "down" and "both". A missing @dir attribute means that the application direction of this element is unknown.
  • Rule 2: (short) linear elements 🡪 no usage of @dir.
    Elements with extent (with @length attribute) examples: bridge, levelCrossing, platformEdge, serviceSection... By standard, the elements' orientation (not their application direction!) shall be always in direction of track orientation (from trackBegin towards trackEnd).
    E.g.: <levelCrossing>, <platformEdge>.
    The position value @pos defines the center point of the linear element.
  • Rule 3: (long) linear elements 🡪 use @dir if modelling „portals“ (usually Changes), where the elements' orientation can differ from track orientation.
    Refers to Elements that describe a change.
    Examples: axleWeightChange, clearanceGaugeChange, electrificationChange, gaugeChange, speedChange...
    By standard (except for speedChange), the change elements' orientation (not their application direction!) shall be always in direction of track orientation (from trackBegin towards trackEnd).
    E.g. <tunnel>: locate tunnel portal with @pos and point @dir towards center.
Reason: There are some elements, where the @dir attribute does not make much sense. Either, because the element is valid for both directions of travel or because the element shall be only defined for one direction. So, the task is to identify elements where the @dir attribute shall be marked DEPRECATED.
Related Development Tickets: #357
Related Commits: [1039] (Note on legacy SVN commits)
Updated attribute(s): @dir
Updated element(s): <trackCircuitBorder>, <brigde>, <levelCrossing_levelCrossings>, <platformEdge>, <serviceSection>, <tunnel>, <axleWeightChange>, <clearanceGaugeChange>, <electrificationChange>, <gaugeChange>, <ownerChange>, <powerTransmissionChange>, <radiusChange>

New Attribute <levelCrossing>@offset

Fact: New optional attribute <levelCrossing>@offset
Reason: Attributes @pos and @absPos shall describe by default the location of the (geometric) middle of the level crossing. Half the @length is before @pos and the other half is after.

In order to define a different setting, the new optional attribute <levelCrossing>@offset can be used. It describes how many metres of the @length is before @pos. If @offset is not given, the default value shall apply.

Related Development Tickets: #374
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): @offset
Updated element(s): <levelCrossing>

Updated definitions for the values of <track>@type

Fact: The definitions of the values of <track>@type have been updated
Reason: Definitions of track types in railML® 2 wiki differ from consensus in forum and best practices in wiki → to be consolidated.
Related Development Tickets: #376
Related Commits: [1039] (Note on legacy SVN commits)
Updated attribute(s): @type
Updated element(s): <track>

Value unknown of <track>@mainDir removed

Fact: The value unknown of <track>@mainDir has been removed.
Reason: unknown has the same meaning as a missing @mainDir.
Recommendation: Despite the value unknown still exists in older schemas, consider it deprecated retroactively.
Related Development Tickets: #324
Related Commits: [1039] (Note on legacy SVN commits)
Updated attribute(s): @mainDir
Updated element(s): <track>

@rampType added to <serviceSection>

Fact: @rampType added to <serviceSection>
Reason: Result of a reasoning how to model car ramps. A possibility to model the type of ramp was missing.
Recommendation: Model car ramps as described here
Related Development Tickets: #362
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): @rampType

<ocpVis> replaced with <objectVis>

Fact: <ocpVis> has been replaced with <objectVis>.
Reason: Makes the purpose of the element clearer and allowes for mor general modelling.
Recommendation: Use <objectVis> in place of <ocpVis>
Related Development Tickets: #373
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <objectVis>
Updated element(s): <ocpVis>

<genericAreas> has been introduced

Fact: Element <genericAreas> and its recursive Children have been introduced
Reason: This element is a new high-level grouping element. The element describes several different types of areas, e.g. specification of specially controlled areas within the network.
Recommendation: Employ <genericAreas>><genericArea>><limitedBy>@ref to reference any infrastructure-elements that limit the respective <genericArea>.
Related Development Tickets: #373
Related Commits: #393, #396
New element(s):
Updated element(s): <infrastructure>, <controller> and others

<track> extended by child <impairmentSections>

Fact: <track> has been extended by child <impairmentSections> (container) and childs.
Reason: Element <impairmentSection> is designed to address sections with impaired railway operations.
Recommendation: Employ <impairmentSection>@areaRef to reference a <genericArea> and <impairmentSection>><additionalRunningTime>@value to indicate the delay.
Related Development Tickets: #395
Related Commits: #393, #396
New element(s): <impairmentSections> & recursive childs
Updated element(s): <track>

@startDateTime and @endDateTime have been added to <state>

Fact: @startDateTime and @endDateTime have been added to <state>
Reason: The time aspect of <state> was previously not modelled properly, e.g. missing a clear start and end time of a certain state (independent from timetable)
Recommendation:
Related Development Tickets: #394
Related Commits: #393, #396
New attribute(s): @startDateTime, @endDateTime
Updated element(s): <state>

Turning restistances added to <ocp>

Fact: <ocp> > <propOther> has been extended by child <relation>
Reason: In purely mesoscopic or macroscopic railway network descriptions a detailed description of operational routing (e.g. change of driving direction) was not possible; especially within OCP. Therefore <ocp> has been extended with an „inner topology description“ related to possible train runs.
Related Development Tickets: #413
Related Commits: #393, #396
New element(s): <relation> & recursive childs
Updated element(s): <propOther>

<line>@belongsToParent has been added

Fact: <line> has been extended by @belongsToParent and the definition of <line> has been generalized.
Reason: This change allows to segment lines and address the complete line and single segments simultaneously.
Related Development Tickets: #414
Related Commits: #393, #396
New attribute(s): @belongsToParent
Updated element(s): <line>

<propOperational> extended by @remoteControlled and @simultaneousEntry

Fact: <propOperational> has been extended by @remoteControlled and @simultaneousEntry
Reason: Provides additional operational attributes for an <ocp>.
Related Development Tickets: #416
Related Commits: #393, #396
New attribute(s): @remoteControlled, @simultaneousEntry
Updated element(s): <propOperational>

<border>@type extended by value project

Fact: <border>@type has been extended by value project.
Reason: Allows to employ <border> to clarify borders of/between projects.
Related Development Tickets: #418
Related Commits: #393, #396
Updated attribute(s): @type
Updated element(s): <border>

<state>@status has been extended by the value unknown

Fact: <state>@status has been extended by the value unknown
Reason: Allows to mark the respective element as explicitely unknown.
Related Development Tickets: #421
Related Commits: #393, #396
Updated attribute(s): <state>@status

<speedProfile> has been extended

Fact: @basicSpeedProfile, @etcsTrainCategory and two semantic constraints have been added. <speedChange>@etcsTrainCategory has in turn been deprecated.
Reason: Usage of overlapping speed profiles used to be unclear
Related Development Tickets: #424
Related Commits: #393, #396
New attribute(s): @basicSpeedProfile, @etcsTrainCategory
Updated attribute(s): <speedChange>@etcsTrainCategory
Updated element(s): <speedProfile>, <speedChange>
New semantic constraint(s): Semcon IS:012, Semcon IS:012

<speedChange> has been extenden with a second semantic constraint.

Fact: A second semantic constraint has been introduced referring to @pos and @dir.
Reason: Supposed guarantee gap-less coverage of the track network.
Related Development Tickets: #425
Related Commits: #393, #396
Updated attribute(s): @pos, @dir
Updated element(s): <speedChange>
New semantic constraint(s): Semcon IS:011

<tunnel> has been extended with resistance factors

Fact: <tunnel> has been extended with resistance factors @resistanceFactorPassenger and @resistanceFactorFreight
Reason: Explicit modelling of tunnel resistance factors f_tunnel compliant with the model: R(tunnel) = f_tunnel * speed*speed
Related Development Tickets: #426
Related Commits: #393, #396
New attribute(s): @resistanceFactorPassenger, @resistanceFactorFreight
Updated element(s): <tunnel>
New semantic constraint(s): Semcon IS:014

<signal> has been extended

Fact:
Reason: <signal> misses information required by some use cases.
Related Development Tickets: #429
Related Commits: #393, #396
New attribute(s): @numberOfLamps, @mountedOn, @positionAtTrack
Updated attribute(s): @switchable
Updated element(s): <signal>

<uptime> has been extended by @operatingPeriodRef and @endDayOffset

Fact: <uptime> has been extended by @operatingPeriodRef and @endDayOffset
Reason: Operational uptime of an OCP is missing a link to the timetable period as well as an attribute to define uptimes lasting longer than midnight
Related Development Tickets: #467
Related Commits: #393, #396
New attribute(s): @operatingPeriodRef, @endDayOffset
Updated element(s): <uptime>

<trainDetector> has been extended

Fact: @virtual and value manual of @medium have been introduced
Reason: model "manual" (visual) end of train detection by a local dispatcher in a manually operated station
Related Development Tickets: #469
Related Commits: #393, #396
New attribute(s): @virtual
Updated attribute(s): @medium
Updated element(s): <trainDetector>

<ocp> has been extended with child <propPassengerInfo> > <informationArea>

Fact: <ocp> has been extended with child <propPassengerInfo> > <informationArea>
Reason: Provide OCP specific information when entering vicinity of the OCP. OCP shall be linked with an information area surrounding the OCP
Related Development Tickets: #473
Related Commits: #393, #396
New element(s): <propPassengerInfo> & children
Updated element(s): <ocp>

<ocp>, <track> and <platformEdge> have been extended with child <propPassengerInfo> > <mediaResources>

Fact: <ocp>, <track> and <platformEdge> have been extended with child <propPassengerInfo> > <mediaResources>
Reason: Add language-specific text fragments and audio fragments directly to the infrastructure elements they refer to
Related Development Tickets: #477
Related Commits: #393, #396
New element(s): <propPassengerInfo>, <informationArea> & children
Updated element(s): <ocp>, <track> and <platformEdge>

<derailer>@derailSide has been extended with valie above

Fact: <derailer>@derailSide has been extended with valie above
Related Development Tickets: #477
Related Commits: #393, #396
Updated attribute(s): @derailSide
Updated element(s): <derailer>

Rollingstock Subschema

<segmentTable> introduced

Fact: Several instances of <segmentTable> have been introduced.
Reason: There was demand for an alternative to <valueTable>
Related Development Tickets: #385
Related Commits: #393, #396
New element(s): Several instances of <segmentTable>
Updated element(s): The respective parents, comp. <segmentTable>

<state>@status has been extended by the value unknown

Fact: <state>@status has been extended by the value unknown
Reason: Allows to mark the respective element as explicitely unknown.
Related Development Tickets: #421
Related Commits: #393, #396
Updated attribute(s): <state>@status

<classification> has been extended by the child <owner>

Fact: <classification> has been extended by the child <owner>
Related Development Tickets: #421
Related Commits: #393, #396
New element(s): <owner>
Updated element(s): <classification>

<formation> has been extended by @load

Fact: <formation> has been extended by @load
Reason: See https://www.railml.org/forum/index.php?t=msg&goto=2597 (link to the railML® website)
Related Development Tickets: #421
Related Commits: #393, #396
New attribute(s): @load
Updated element(s): <formation>

<vehicleBrake> and <trainBrakes> have been extended by @regularBrakePercentage and @emergencyBrakePercentage

Fact: <vehicleBrake> and <trainBrakes> have been extended by @regularBrakePercentage and @emergencyBrakePercentage
Reason: See https://www.railml.org/forum/index.php?t=msg&goto=2571 (link to the railML® website)
Related Development Tickets: #421
Related Commits: #393, #396
New attribute(s): @emergencyBrakePercentage, @regularBrakePercentage, @emergencyBrakePercentage, @regularBrakePercentage
Updated element(s): <vehicleBrake> and <trainBrakes>