IS:opEquipment

Documentation

Syntax

Autoexport from the XML-Schema for element IS:opEquipment of railML® version 3.2 UML-visualization of IS
Documentation	child element summarizing the equipment of the operational point
Subschema	infrastructure
Parents*	operationalPoint
Children	ownsInfrastructureElement (0..*), ownsPlatform (0..*), ownsServiceSection (0..*), ownsSignal (0..*), ownsStoppingPlace (0..*), ownsTrack (0..*)
Attributes: numberOfStationTracks: number of tracks that are available for operation within the operational point (optional; xs:positiveInteger)
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.

Autoexport from the XML-Schema for element IS:opEquipment of railML® version 3.1 UML-visualization of IS
Documentation	child element summarizing the equipment of the operational point
Subschema	infrastructure
Parents*	operationalPoint
Children	ownsPlatform (0..*), ownsServiceSection (0..*), ownsSignal (0..*), ownsStoppingPlace (0..*), ownsTrack (0..*)
Attributes: numberOfStationTracks: number of tracks that are available for operation within the operational point (optional; xs:positiveInteger)
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.

Changes 3.1→3.2

The children have changed.

Semantics

Proposed Semantic Constraint "IS:018":   Any functional infrastructure element that belongs to an <operationalPoint> may be listed as its equipment. This may be done by adding it to a specific container, such as <ownsPlatform>, <ownsTrack> and <ownsSignal> or it may be added to the generic container <ownsInfrastructureElement>. Any such added infrastructure element must be added to the most specific container available. No element shall be part of two such containers. If no specific container for the functional infrastructure element exists, it shall be listed in the generic container. Example: a <signalIS> must not be added to <ownsInfrastructureElement>. It shall be added to <ownsSignal>. As there is no container for levelCrossings a <levelCrossingIS> belonging to an <operationalPoint> shall be added to <ownsInfrastructureElement>.   Proposed on August 26th 2024 FIXME: add Link to discussion! Please, recognize our guidelines on semantic constraints