IS:infrastructureState

Documentation

Syntax

Autoexport from the XML-Schema for element IS:infrastructureState of railML® version 3.2 UML-visualization of IS
Documentation	state of (a part of) the functional infrastructure regarding its availability and usability
Subschema	infrastructure
Parents*	infrastructureStates
Children	elementState (0..*), name (0..*), validityTime (0..*)
Attributes: value: railway infrastructure functional state, e.g. "operational" (optional; xs:string; patterns: other:w{2,}) Possible values: closed: The element is no longer available, removed, dismantled, or no longer exists. Planning, construction or commissioning activities are absolutely necessary for recommissioning. conceptual: The construction or commissioning of the element is planned for the medium or long term. However, there are still no concrete (planning) activities for the construction of the element beyond the preliminary planning and cost estimation. disabled: The element is currently not usable, switched off or deactivated and therefore cannot be used regularly. However, it can be put back into operation at short notice without further construction, acceptance or approval activities. operational: The element is operational and can be used regularly. planned: The construction or commissioning of the element is planned concretely and at short notice or concrete planning activities for the construction take place, e.g. design, approval or implementation planning, cost calculation, award of contracts. It is not normally possible to use the element., id: unique identifier (obligatory; xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
*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:infrastructureState of railML® version 3.1 UML-visualization of IS
Documentation	state of (a part of) the functional infrastructure regarding its availability and usability
Subschema	infrastructure
Parents*	infrastructureStates
Children	any (0..*), elementState (0..*), name (0..*), validityTime (0..*)
Attributes: value: railway infrastructure functional state, e.g. "operational" (optional; xs:string; patterns: other:w{2,}) Possible values: disabled: The element is currently not usable, switched off or deactivated and therefore cannot be used regularly. However, it can be put back into operation at short notice without further construction, acceptance or approval activities. closed: The element is no longer available, removed, dismantled, or no longer exists. Planning, construction or commissioning activities are absolutely necessary for recommissioning. operational: The element is operational and can be used regularly. conceptual: The construction or commissioning of the element is planned for the medium or long term. However, there are still no concrete (planning) activities for the construction of the element beyond the preliminary planning and cost estimation. planned: The construction or commissioning of the element is planned concretely and at short notice or concrete planning activities for the construction take place, e.g. design, approval or implementation planning, cost calculation, award of contracts. It is not normally possible to use the element., id: unique identifier (optional; xs:ID; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
*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.

The attributes have been changed.

Semantics

Proposed Semantic Constraint "IS:019":   When calculating which <infrastructureState> of an <infrastructure> is valid on a particular day always a maximum of one active <infrastructureState> shall be the result. See examples below.   Proposed on September 3rd 2024 Discuss this semantic constraint Please, recognize our guidelines on semantic constraints

Invalid code

Reader cannot identify what is the state of the <infrastructure> in the file: "operational" or "disabled".

      <infrastructureState id="state1" value="operational">
        <elementState id="xxx" refersToElement="zzz" value="closed" />
      </infrastructureState>
      <infrastructureState id="state2" value="conceptual">
        <elementState id="yyy" refersToElement="jjj" value="disabled" />
      </infrastructureState>

Valid code

Case 1

There is only one <infrastructureState> in the file.

      <infrastructureState id="state1" value="operational">
        <elementState id="xxx" refersToElement="zzz" value="closed" />
      </infrastructureState>

Case 2

Validities do not intersect.

      <infrastructureState id="state1" value="operational">
        <validityTime>
          <period from="2002-09-24-06:00" to="2002-09-30-06:00" />
        </validityTime>
        <elementState id="xxx" refersToElement="zzz" value="closed" />
      </infrastructureState>
      <infrastructureState id="state2" value="conceptual">
        <validityTime>
          <period from="2022-09-24-06:00" to="2022-09-30-06:00" />
        </validityTime>
        <elementState id="yyy" refersToElement="jjj" value="disabled" />
      </infrastructureState>

Best Practice / Examples

<infrastructureState> "state1" refers to the whole infrastructure. Children <elementState> refer only to the elements with different state.

      <infrastructureState id="state1" value="operational">
        <elementState id="yyy" refersToElement="aaa" value="closed" />
        <elementState id="zzz" refersToElement="bbb" value="closed" />
        <elementState id="jjj" refersToElement="ccc" value="closed" />
      </infrastructureState>

Bad Practice

This is a bad practice because elementState/@value="closed" gives redundant fact. It is already know from the parent that all the IS except listed in children with different state is "closed".

      <infrastructureState id="xxx" value="closed">
        <elementState id="yyy" refersToElement="aaa" value="closed" />
        <elementState id="zzz" refersToElement="bbb" value="closed" />
        <elementState id="jjj" refersToElement="ccc" value="closed" />
      </infrastructureState>