++ :TRAFFIC--MANAGEMENT--SYSTEM_lexForm_5
++ :A--LOCATION--MARKER--IS--A--MARKER--BORDER--ON--THE--TRACKSIDE--TO--INDICATE--A--POTENTIAL--EN_lexConcept_2
++ :A--MISSION--IS--A--TRAIN--MOVEMENT--FOR--A--CERTAIN--PURPOSE--WITHOUT--CHANGING--THE--TRAIN--C_lexConcept_2
++ :A--PERCEPTION--THAT--HAS--A--DIRECT--INFLUENCE--ON--THE--STAFF--MEMBER---THE--PERCEPTION--CAN_lexConcept_2
++ :A--SEGMENTS--IS--AN--AREA--OF--THE--INFRASTRUCTURE--ON--WHICH--MISSIONS--ARE--PERFORMED---RO_lexConcept_2
++ :AN--ETCS--STOP--MARKER--IS--A--TRACKSIDE--MARKER--BOARD--THAT--SIGNALS_lexConcept_2
-- :FIS-----FUNCTIONAL--INTERFACE--SPECIFICATION_lexConcept_3
++ :IN--THE--STAFF--RESPONSIBLE--MODE--SR--THE--MISSION--IS--PERFORMED--ON--SIGHT--AND--WITH--OU_lexConcept_2
++ :SAFETY--PRINCIPLES--ARE--BINDING--GUIDELINES--AND--CONDITIONS--TO--RESPECT--FOR--SAFE--TRAI_lexConcept_2
++ :THE--DESTINATION--IS--A--LOCATION--WHERE_lexConcept_2
-- :THE--DRIVER--IS--AN--OPERATIONAL--ACTOR---HE--IS--IN--CHARGE--OF--UN--PREPARING--AND--DRIVING_lexConcept_2
++ :THE--START--OF--MISSION--SOM--IS--THE--ETCS-START---THE--DRIVER--PREPARES--WITH--THE--SOM--T_lexConcept_2
++ :THE--TRAIN--CHARACTERISTICS--INCLUDE--THE--MANDATORY--INFORMATION--ON--THE--TECHNICAL--CHA_lexConcept_2
++ :TRACK--ELEMENTS--ARE--MOVABLE--ELEMENTS--TRACK--SECTIONS--LEVEL--CROSSINGS_lexConcept_2
++ :TRAFFIC--MANAGEMENT--SYSTEM_lexConcept_4
++ "A perception that has a direct influence on the staff member. The perception can be: * acoustic (image: 1-4-screenshot-20250930-144931-19.png) * visual (image: 2-5-screenshot-20250930-144931-20.png) * olfactory (image: 3-6-screenshot-20250930-144931-21.png) * gustatory (image: 4-7-screenshot-20250930-144931-22.png) * haptic (image: 5-8-screenshot-20250930-144931-23.png)"
-- "A perception that has a direct influence on the staff member. The perception can be: * acoustic (image: 4-screenshot-20250930-144931-19.png) * visual (image: 5-screenshot-20250930-144931-20.png) * olfactory (image: 6-screenshot-20250930-144931-21.png) * gustatory (image: 7-screenshot-20250930-144931-22.png) * haptic (image: 8-screenshot-20250930-144931-23.png)"
++ "This is the adaptation of the existing concept of Automatic Route Setting (ARS) as defined in (SPLI-1455 - Automatic route setting system) irrespective of how the routes/paths are set.{comment:294} Concept is being currently developed under topic 72 (2 subtopics planned, one for manual and another one for automatic activation/deactivation of routes/paths) and will need support and advice from Traffic CS to see how it matches the new concept of routes defined by Traffic CS.{comment:293}"
-- "This is the adaptation of the existing concept of Automatic Route Setting (ARS) as defined in (SPLI-1455 - Automatic route setting system) irrespective of how the routes/paths are set. Concept is being currently developed under topic 72 (2 subtopics planned, one for manual and another one for automatic activation/deactivation of routes/paths) and will need support and advice from Traffic CS to see how it matches the new concept of routes defined by Traffic CS."
++ "Commands from Signaller (and in some situations also from Maintainer) to set or remove inhibition of the following track elements among others: * occupation of a track section (that could be disturbed/failed){comment:237} * sending of MA from a specific signal/SMB * movement of a movable element (points, derailers, LXs, bascule bridges, etc) * route setting (that could include track sections, movable elements and signals/SMBs within the route){comment:300}"
-- "Commands from Signaller (and in some situations also from Maintainer) to set or remove inhibition of the following track elements among others: * occupation of a track section (that could be disturbed/failed) * sending of MA from a specific signal/SMB * movement of a movable element (points, derailers, LXs, bascule bridges, etc) * route setting (that could include track sections, movable elements and signals/SMBs within the route){comment:147}"
++ "Co-operative Shortening of MA is a special procedure between Traffic CS and Train CS to shorten a given Movement Authority.{comment:249}"
-- "Co-operative Shortening of MA is a special procedure between Traffic CS and Train CS to shorten a given Movement Authority."
-- "‘common safety method for Risk evaluation and Assessement’ {comment:95} means the methods describing the assessment of safety levels and achievement of safety targets and compliance with other safety requirements; SPPRAMSS-619 - [CSM RA + (EU) No 1136/2015]"
++ "The process of initiating and terminating an dialogue{comment:240} between Trackside (RBC) and On-board via data radio. This communication session is maintained a maximum time of 5 minutes in case of failed re-connection attempts.{comment:309} Note that it is a different concept to SPP-28485 - Missing cross-reference.{comment:320}"
-- "The process of initiating and terminating an dialogue between Trackside (RBC) and On-board via data radio.{comment:155} This communication session is maintained a maximum time of 5 minutes in case of failed re-connection attempts. Note that it is a different concept to SPP-28485 - Missing cross-reference."
++ "Coupling speed is appropriated{comment:247} speed for a successful coupling. It is determined by the vehicle manufacturer in cooperation with the Railway Undertaking to avoid damages during coupling as well as an unnecessary slow approach."
-- "Coupling speed is appropriated speed for a successful coupling. It is determined by the vehicle manufacturer in cooperation with the Railway Undertaking to avoid damages during coupling as well as an unnecessary slow approach.{comment:3}"
++ "The display associated to this system is called TRD (Train Radio Display) in UIC-612. The ergonomics of this system is{comment:207} also defined in UIC-612-4.The TRD is located on the left side of the cab according to UIC-612-0, EN 16186-2 (chapter 7.21).The SIL{comment:208} is SIL0 (Basic Integrity). Information is{comment:209} presented on demand when triggered by the driver or when external actors (passenger, traffic agent,etc.) call the driver. Current communication between CVR and TRD is supplier-specific?{comment:210} To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered."
-- "The display associated to this system is called TRD (Train Radio Display) in UIC-612. The ergonomics of this system is also defined in UIC-612-4.The TRD is located on the left side of the cab according to UIC-612-0, EN 16186-2 (chapter 7.21).The SIL is SIL0 (Basic Integrity).Information is presented on demand when triggered by the driver or when external actors (passenger, traffic agent,etc.) call the driver. Current communication between CVR and TRD is supplier-specific? To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered."
++ "Definition of Pass Position Constraint for STA Request: * The Pass Position Constraint defines the latest track position the train must pass at which PES must send the STA Request, so that the train can receive a MP over that STA without the need to drive into the ETCS Indication Curve of a current, already existing MP. Triggering of STA Request: * The Pass Position Constraint indicates where the first attempt to send the STA Request is made. If the STA is allocated e.g. by another Train Object at this point in time, then the STA Request is not send, it is queued by PES and executed once the STA is no longer allocated.{comment:21}{comment:46}"
-- "Definition of Pass Position Constraint for STA Request: * The Pass Position Constraint defines the latest track position the train must pass at which PES must send the STA Request, so that the train can receive a MP over that STA without the need to drive into the braking curves of a current, already existing MP. Triggering of STA Request: * The Pass Position Constraint indicates where the first attempt to send the STA Request is made. If the STA is allocated e.g. by another Train Object at this point in time, then the STA Request is not send, it is queued by PES and executed once the STA is no longer allocated.{comment:21}{comment:46}"
"Degraded Mode" in railway operations refers to defined procedures applied when one or more safety-critical technical systems (such as signalling, train detection, level crossings, automatic train protection, or communication systems) are unavailable or functioning abnormally. In such situations, normal operational processes are replaced by alternative or emergency procedures that require dedicated fall back solutions (technically) {comment:117}or mainly trained personnel to manually initiate, execute, and monitor train movements, thereby temporarily assuming responsibilities normally fulfilled by technology. The goal is to sustain railway operations at an acceptable level of safety until full technical functionality is restored. Degraded Mode does not include ad hoc operational deviations (such as rerouting trains for non-technical reasons) but specifically addresses failures or constraints in technical systems essential for safe operation. All measures are to be thoroughly documented and communicated, and operations in degraded mode are to be minimized in time and extent due to inherently increased risk."{comment:157}
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:DEMAND_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A Demand on the SCI-SCMD interface is a message from a client to ETPS which asks ETPS for a certain task where the client (usually the Signaller) or the designated procedure takes over responsibility. Therefore, certain safety checks can be overridden. The Demand always follows a Request on the SCI-SCMD interface where ETPS had found that overridable safety checks would be violated. After a confirmation of the Signaller that he takes over responsibility, this Request then becomes a Demand and will be granted/executed. A Demand shall not be used for regular operation.", -- "A Demand on the SCI-SCMD interface is a message from a client to ETPS which asks ETPS for a certain task where the client (usually the Signaller) or the designated procedure takes over responsibility. Therefore, certain safety checks can be overridden.{comment:1327} The Demand always follows a Request{comment:1328} on the SCI-SCMD interface where ETPS had found that overridable safety checks would be violated. After a confirmation of the Signaller that he takes over responsibility, this Request then becomes a Demand and will be granted/executed. A Demand shall not be used for regular operation." :diff_0172 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:DEMAND_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A Demand on the SCI-SCMD interface is a message from a client to ETPS which asks ETPS for a certain task where the client (usually the Signaller) or the designated procedure takes over responsibility. Therefore, certain safety checks can be overridden. The Demand always follows a Request on the SCI-SCMD interface where ETPS had found that overridable safety checks would be violated. After a confirmation of the Signaller that he takes over responsibility, this Request then becomes a Demand and will be granted/executed. A Demand shall not be used for regular operation.
A Demand on the SCI-SCMD interface is a message from a client to ETPS which asks ETPS for a certain task where the client (usually the Signaller) or the designated procedure takes over responsibility. Therefore, certain safety checks can be overridden.{comment:1327} The Demand always follows a Request{comment:1328} on the SCI-SCMD interface where ETPS had found that overridable safety checks would be violated. After a confirmation of the Signaller that he takes over responsibility, this Request then becomes a Demand and will be granted/executed. A Demand shall not be used for regular operation.
] . :diff_0173 a :Object_addition ; ordv:entity lex_sp-defs-251201:DEMAND_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:DESIGN--SAFETY--CASE_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0174 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:DESIGN--SAFETY--CASE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The {comment:26}Design Safety Case gives evidence to the design for a {comment:27}product or application done in Phase 1 to 5. The {comment:28}Design Safety Case will: * fulfil the requirements of Phase 4 (including validation report) and integrated in a modular architecture in Phase 5,{comment:7} * define the SuC and its interfaces and must comply thereby to a harmonised reference architecture (e.g. "System Pillar Reference Architecture"): * functional allocation, * interfaces description, * standardised tests activities (e.f. test benches, procedures), * allocation of safety requirements (e.g. TFFR, SRAC) * be presented to the ISA for a first statement, * be reused for further generic product safety cases or generic/specific safety cases, * evolve along the whole lifecycle of the SuC design, * cover the Safety Management topics in the EU-Rail Standardisation and TSI Input Plan (STIP).
The Design Safety Case gives evidence to the design for a product or application done in Phase 1 to 5. The Design Safety Case will: * fulfil the requirements of Phase 4 (including validation report) and integrated in a modular architecture in Phase 5, * define the SuC and its interfaces and must comply thereby to a harmonised reference architecture (e.g. "System Pillar Reference Architecture"): * functional allocation, * interfaces description, * standardised tests activities (e.f. test benches, procedures), * allocation of safety requirements (e.g. TFFR, SRAC) * be presented to the ISA for a first statement, * be reused for further generic product safety cases or generic/specific safety cases, * evolve along the whole lifecycle of the SuC design, * cover the Safety Management topics in the EU-Rail Standardisation and TSI Input Plan (STIP).
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:DESK--DISPLAY--AREA_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Desk Display Area identifies the desk controlled by MDS (in case of multiple cabins controlled only by one MDS such as locomotive or centralised integration).{comment:223}", -- "The Desk Display Area identifies the desk controlled by MDS (in case of multiple cabins controlled only by one MDS such as locomotive or centralised integration)." :diff_0175 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:DESK--DISPLAY--AREA_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Desk Display Area identifies the desk controlled by MDS (in case of multiple cabins controlled only by one MDS such as locomotive or centralised integration).{comment:223}
The Desk Display Area identifies the desk controlled by MDS (in case of multiple cabins controlled only by one MDS such as locomotive or centralised integration).
] . :diff_0176 a :Object_addition ; ordv:entity lex_sp-defs-251201:DRIVER_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:END--OF--MISSION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "End of Mission. {comment:251}", -- "End of Mission." :diff_0177 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:END--OF--MISSION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
] . :diff_0178 a :Object_addition ; ordv:entity lex_sp-defs-251201:ENTRY_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:ERROR--CORRECTION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
deviating from intended functions and/or performance
:diff_0179 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:ERROR--CORRECTION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Error corrections are a type of evolutions, covered by the Evolution management process. Several types of error correction at building block level can occur: * error correction of the TSI, because it is incorrect (curently not covered by the Evolution Management process). * error correction of the specification, because it is not compliant with the TSI. * error correction of the specification, because it is incorrect * error correction of the source code, because it is not implementing correctly the specification i.e. "deviating from intended functions and/or performance". Error corrections are basically defined in: * SPPRAMSS-4525 - [Directive 2016/797] (Article 16) and * SPPRAMSS-328 - [Commission Implementing Regulation 2023/1695 "TSI CCS"] (section 6.5 Management of errors and 7.2.10 ) More details are defined in SPPRAMSS-14396 - Error correction.
Error corrections are a type of evolutions, covered by the Evolution management process. Several types of error correction at building block level can occur: * error correction of the TSI, because it is incorrect (curently not covered by the Evolution Management process). * error correction of the specification, because it is not compliant with the TSI. * error correction of the specification, because it is incorrect * error correction of the source code, because it is not implementing correctly the specification i.e. "deviating from intended functions and/or performance". Error corrections are basically defined in: * SPPRAMSS-4525 - [Directive 2016/797] (Article 16) and * SPPRAMSS-328 - [TSI CCS + (EU) 2023/1695] (section 6.5 Management of errors and 7.2.10 ) More details are defined in SPPRAMSS-14396 - Error correction.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:ETCS--CCD--DISPLAY_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The{comment:202}{comment:201} display associated to this system is called CCD (Control Command Display) in UIC-612. The functionalities and the ergonomics of this system are standardised in the subset 026 and ERA DMI 15560.The CCD display is located in front of the driver according to UIC-612-0, EN 16186-2 (chapter 7.21). According to subset 091, some THR are related to the DMI and involve THR equivalent to SIL2. Information of ETCS are mandatory when train is in motion. It could be debatable if this is also the case at standstill. There is a proposal for standardisation communication between ETCS and MDS known as Subset-121. {comment:153}", -- "The display associated to this system is called CCD (Control Command Display) in UIC-612. The functionalities and the ergonomics of this system are standardised in the subset 026 and ERA DMI 15560.The CCD display is located in front of the driver according to UIC-612-0, EN 16186-2 (chapter 7.21). According to subset 091, some THR are related to the DMI and involve THR equivalent to SIL2. Information of ETCS are mandatory when train is in motion. It could be debatable if this is also the case at standstill. There is a proposal for standardisation communication between ETCS and MDS known as Subset-121. {comment:153}" :diff_0180 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:ETCS--CCD--DISPLAY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The{comment:202}{comment:201} display associated to this system is called CCD (Control Command Display) in UIC-612. The functionalities and the ergonomics of this system are standardised in the subset 026 and ERA DMI 15560.The CCD display is located in front of the driver according to UIC-612-0, EN 16186-2 (chapter 7.21). According to subset 091, some THR are related to the DMI and involve THR equivalent to SIL2. Information of ETCS are mandatory when train is in motion. It could be debatable if this is also the case at standstill. There is a proposal for standardisation communication between ETCS and MDS known as Subset-121. {comment:153}
The display associated to this system is called CCD (Control Command Display) in UIC-612. The functionalities and the ergonomics of this system are standardised in the subset 026 and ERA DMI 15560.The CCD display is located in front of the driver according to UIC-612-0, EN 16186-2 (chapter 7.21). According to subset 091, some THR are related to the DMI and involve THR equivalent to SIL2. Information of ETCS are mandatory when train is in motion. It could be debatable if this is also the case at standstill. There is a proposal for standardisation communication between ETCS and MDS known as Subset-121. {comment:153}
] . :diff_0181 a :Object_addition ; ordv:entity lex_sp-defs-251201:ETPS--OPERATIONAL--STATE_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:EUROPEAN--INSTRUCTION--7_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Authorisation to start after preparing a movement.{comment:268}", -- "Authorisation to start after preparing a movement.{comment:132}" :diff_0182 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:EUROPEAN--INSTRUCTION--7_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Authorisation to start after preparing a movement.{comment:268}
Authorisation to start after preparing a movement.{comment:132}
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:EUROPEAN--INSTRUCTION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A European Instruction is an instruction issued by the Signaller to the Driver to ensure safe operation when this cannot be provided by the signalling system. A European Instruction will state for example: - which train it is issued to - the time and date it was issued - location of train (if relevant) - location of issuer - a clear, precise, unambiguous instruction - a Unique Identification. The EI precises speed, special conditions for train movement and other requests for safe operations.{comment:267}{comment:311}", -- "{comment:129}{comment:150}A European Instruction is an instruction issued by the Signaller to the Driver to ensure safe operation when this cannot be provided by the signalling system. A European Instruction will state for example: - which train it is issued to - the time and date it was issued - location of train (if relevant) - location of issuer - a clear, precise, unambiguous instruction - a Unique Identification. The EI precises speed, special conditions for train movement and other requests for safe operations." :diff_0183 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:EUROPEAN--INSTRUCTION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A European Instruction is an instruction issued by the Signaller to the Driver to ensure safe operation when this cannot be provided by the signalling system. A European Instruction will state for example: - which train it is issued to - the time and date it was issued - location of train (if relevant) - location of issuer - a clear, precise, unambiguous instruction - a Unique Identification. The EI precises speed, special conditions for train movement and other requests for safe operations.{comment:267}{comment:311}
{comment:129}{comment:150}A European Instruction is an instruction issued by the Signaller to the Driver to ensure safe operation when this cannot be provided by the signalling system. A European Instruction will state for example: - which train it is issued to - the time and date it was issued - location of train (if relevant) - location of issuer - a clear, precise, unambiguous instruction - a Unique Identification. The EI precises speed, special conditions for train movement and other requests for safe operations.
] . :diff_0184 a :Object_addition ; ordv:entity lex_sp-defs-251201:EXIT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:FIS-----FUNCTIONAL--INTERFACE--SPECIFICATION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Functional requirements and description of an interface. This clarifies also the functional apportionment and related safety requirements of the two sub-systems of the interface.", -- "implicit-from-entry-label: FIS - Functional Interface Specification" :diff_0185 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:FIS-----FUNCTIONAL--INTERFACE--SPECIFICATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Functional requirements and description of an interface. This clarifies also the functional apportionment and related safety requirements of the two sub-systems of the interface.
implicit-from-entry-label: FIS - Functional Interface Specification
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:FIS-----FUNCTIONAL--INTERFACE--SPECIFICATION_lexConcept_2 ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "FIS - Functional Interface Specification", -- "Functional requirements and description of an interface. This clarifies also the functional apportionment and related safety requirements of the two sub-systems of the interface." :diff_0186 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:FIS-----FUNCTIONAL--INTERFACE--SPECIFICATION_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
FIS - Functional Interface Specification
] . :diff_0187 a :Object_addition ; ordv:entity lex_sp-defs-251201:FUNCTIONAL--ADAPTER_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:GEOMETRIC--SAFETY--LOGIC_lexConcept_2 ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Geometric Safety Logic is a generic safety logic implementation, independent from the specific, where the paths reserved for train movements can start and end at any geometric location on the railway track. This is in contrast to a more traditional route-based signalling system, where the paths reserved for train movements start and end at fixed, pre-determined locations (e.g. route origin and destination).{comment:296}", -- "Geometric Safety Logic is a generic safety logic implementation independent from the specific where the paths reserved for train movements can start and end at any geometric location on the railway track. This is in contrast to a more traditional route-based signaling system, where the paths reserved for train movements start and end at fixed, pre-determined locations (e.g. route origin and destination)." :diff_0188 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:GEOMETRIC--SAFETY--LOGIC_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
Geometric Safety Logic is a generic safety logic implementation, independent from the specific, where the paths reserved for train movements can start and end at any geometric location on the railway track. This is in contrast to a more traditional route-based signalling system, where the paths reserved for train movements start and end at fixed, pre-determined locations (e.g. route origin and destination).{comment:296}
Geometric Safety Logic is a generic safety logic implementation independent from the specific where the paths reserved for train movements can start and end at any geometric location on the railway track. This is in contrast to a more traditional route-based signaling system, where the paths reserved for train movements start and end at fixed, pre-determined locations (e.g. route origin and destination).
] . :diff_0189 a :Object_addition ; ordv:entity lex_sp-defs-251201:HANDING-OVER--SYSTEM_lexConcept . :diff_0190 a :Object_addition ; ordv:entity lex_sp-defs-251201:HANDOVER--CHECKLIST_lexConcept . :diff_0191 a :Object_addition ; ordv:entity lex_sp-defs-251201:HANDOVER--PACKAGE_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:HAZARD_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0192 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:HAZARD_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Condition that could lead to an accident [SOURCE: SPPRAMSS-619 - [Commission Implementing Regulations 402/2013 "CSM RA" + 2015/1136] Article 3 Definitions (13)] Note 1 to entry: The equivalent definition in [IEC 60050-903:2013, 903-01-02] refers to "harm" instead of "accident". Note 2 to entry: A Hazard sits at the boundary of the system under consideration. [ ERA-REC-116-2015-GUI]
Condition that could lead to an accident Note 1 to entry: The equivalent definition in [IEC 60050-903:2013, 903-01-02] refers to "harm" instead of "accident". Note 2 to entry: A Hazard sits at the boundary of the system under consideration. [ ERA-REC-116-2015-GUI]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:HOF--HAZARD_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0193 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:HOF--HAZARD_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Hazard whose cause is related to human and organisational (HOF) factors. These hazards are managed by means of the "HOF Hazard" Work Item.
Hazard whose cause is related to human and organisational (HOF) factors. These harzards are managed by means of the "HOF Hazard" Work Item.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:HYBRID--TRAIN--DETECTION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Hybrid Train Detection is a type of train detection which uses fixed (pre-configured) virtual blocks for the separation of trains which are able to send train integrity confirmation in the position report, while a limited installation of trackside train detection is used for the separation of trains which are not able to send integrity confirmation, as well as for the handling of degraded situations.{comment:248}", -- "Hybrid Train Detection is a type of train detection which uses fixed (pre-configured) virtual blocks for the separation of trains which are able to send train integrity confirmation in the position report, while a limited installation of trackside train detection is used for the separation of trains which are not able to send integrity confirmation, as well as for the handling of degraded situations." :diff_0194 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:HYBRID--TRAIN--DETECTION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Hybrid Train Detection is a type of train detection which uses fixed (pre-configured) virtual blocks for the separation of trains which are able to send train integrity confirmation in the position report, while a limited installation of trackside train detection is used for the separation of trains which are not able to send integrity confirmation, as well as for the handling of degraded situations.{comment:248}
Hybrid Train Detection is a type of train detection which uses fixed (pre-configured) virtual blocks for the separation of trains which are able to send train integrity confirmation in the position report, while a limited installation of trackside train detection is used for the separation of trains which are not able to send integrity confirmation, as well as for the handling of degraded situations.
] . :diff_0195 a :Object_addition ; ordv:entity lex_sp-defs-251201:IN--THE--STAFF--RESPONSIBLE--MODE--SR--THE--MISSION--IS--PERFORMED--ON--SIGHT--AND--WITH--OU_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:ISSUE_lexConcept_2 ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Polarion workitem type: Issue. A problem description to be solved in the specification. Can also be an open question, or a generic question, or a point on an agenda.", -- "A problem description to be solved in the specification. Can also be an open question, or a generic question, or a point on an agenda." :diff_0196 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:ISSUE_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
Polarion workitem type: Issue. A problem description to be solved in the specification. Can also be an open question, or a generic question, or a point on an agenda.
A problem description to be solved in the specification. Can also be an open question, or a generic question, or a point on an agenda.
] . :diff_0197 a :Object_addition ; ordv:entity lex_sp-defs-251201:ISSUE_lexConcept_3 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:LAYOUT--ENGINE_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => **++ "The Layout Engine is an application and supplier-specific piece of software, able to generate any View based on application specific needs.", **-- "The Layout Engine is an application and supplier specific piece of software, able to generate any View based on application specific needs." :diff_0198 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:LAYOUT--ENGINE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Layout Engine is an application and supplier-specific piece of software, able to generate any View based on application specific needs.
The Layout Engine is an application and supplier specific piece of software, able to generate any View based on application specific needs.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:LEVEL--CROSSING_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Any level intersection between a road or passage and a railway, as recognised by the infrastructure manager and open to public or private users. There are different types of Level Crossings that require different levels of protection. A Level Crossing can be within the signalling system or not and can be equipped with a protective system to warn users about approaching trains. Warning devices can be a combination of e.g. lights, bells or barriers. A Level Crossing can be considered protected or not protected as identified in Subset-026. A defective Level Crossing is understood not protected as per 315 Passing non protected LX. Pending to add new definitions of the different types of LXs if needed.", -- "Any level intersection between a road or passage and a railway, as recognised by the infrastructure manager and open to public or private users. There are different types of Level Crossings. A level crossing can be equipped with a protective system to warn users about approaching trains. Warning devises can be a combination of e.g. lights, bells and barriers.{comment:133}{comment:152}" :diff_0199 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:LEVEL--CROSSING_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Any level intersection between a road or passage and a railway, as recognised by the infrastructure manager and open to public or private users. There are different types of Level Crossings that require different levels of protection. A Level Crossing can be within the signalling system or not and can be equipped with a protective system to warn users about approaching trains. Warning devices can be a combination of e.g. lights, bells or barriers. A Level Crossing can be considered protected or not protected as identified in Subset-026. A defective Level Crossing is understood not protected as per 315 Passing non protected LX. Pending to add new definitions of the different types of LXs if needed.
Any level intersection between a road or passage and a railway, as recognised by the infrastructure manager and open to public or private users. There are different types of Level Crossings. A level crossing can be equipped with a protective system to warn users about approaching trains. Warning devises can be a combination of e.g. lights, bells and barriers.{comment:133}{comment:152}
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:LOCAL--OPERATION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0200 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:LOCAL--OPERATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Local operation of a movable element refers to operation physically/onsite done by Field Force{comment:282} not involving Trackside CCS and neither using a centralised panel (TMS) nor a local panel nor a handheld terminal. The alternative to the local operation would be a "remote" operation from a centralised panel (TMS) or a local panel or a handheld terminal. Note: Currently the use of local is understood as a "planned" operation while the use of "manual" would imply an "unplanned" operation.{comment:283}{comment:315}
Local operation of a movable element refers to operation physically/onsite done by Field Force not involving Trackside CCS and neither using a centralised panel (TMS) nor a local pannel nor a handheld terminal. The alternative to the local operation would be a "remote" operation from a centralised panel (TMS) or a local pannel or a handheld terminal. Currently the use of local is undestood as a "planned" operation while the use of "manual" would imply an "unplanned" operation.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:LOCATION--MARKER_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A Harmonised trackside ETCS marker board defined in EN 16494/2015 ( 2 ) is used to identify a potential EOA, e.g. the end of a block section. ERTMS User Group defines a ETCS location Marker: * To be used to unambiguously identify an EOA which does not protect a safety-critical location. It is up to IM to decide whether an ETCS Location Marker can be used instead of an ETCS Stop Marker where no safety critical point needs to be protected. * To be used to identify specific locations on the track where the train shall stop when running without MA if the driver has received specific instruction from the signaller. * To be used to mark the location up to which the driver needs to confirm that the line is clear (e.g. for TAF function) To be used to mark the location up to which the driver has to drive under his/her responsibility before a possible MA in FS/OS is received. (image: 9-screenshot-20251001-151744-6.png) {comment:266}", -- "A Harmonised trackside ETCS marker board defined in EN 16494/2015 ( 2 ) is used to identify a potential EOA, e.g. the end of a block section. ERTMS User Group defines a ETCS location Marker: * To be used to unambiguously identify an EOA which does not protect a safety-critical location. It is up to IM to decide whether an ETCS Location Marker can be used instead of an ETCS Stop Marker where no safety critical point needs to be protected. * To be used to identify specific locations on the track where the train shall stop when running without MA if the driver has received specific instruction from the signaller. * To be used to mark the location up to which the driver needs to confirm that the line is clear (e.g. for TAF function) To be used to mark the location up to which the driver has to drive under his/her responsibility before a possible MA in FS/OS is received. (image: 9-screenshot-20251001-151744-6.png)" :diff_0201 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:LOCATION--MARKER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A Harmonised trackside ETCS marker board defined in EN 16494/2015 ( 2 ) is used to identify a potential EOA, e.g. the end of a block section. ERTMS User Group defines a ETCS location Marker: * To be used to unambiguously identify an EOA which does not protect a safety-critical location. It is up to IM to decide whether an ETCS Location Marker can be used instead of an ETCS Stop Marker where no safety critical point needs to be protected. * To be used to identify specific locations on the track where the train shall stop when running without MA if the driver has received specific instruction from the signaller. * To be used to mark the location up to which the driver needs to confirm that the line is clear (e.g. for TAF function) To be used to mark the location up to which the driver has to drive under his/her responsibility before a possible MA in FS/OS is received. (image: 9-screenshot-20251001-151744-6.png) {comment:266}
A Harmonised trackside ETCS marker board defined in EN 16494/2015 ( 2 ) is used to identify a potential EOA, e.g. the end of a block section. ERTMS User Group defines a ETCS location Marker: * To be used to unambiguously identify an EOA which does not protect a safety-critical location. It is up to IM to decide whether an ETCS Location Marker can be used instead of an ETCS Stop Marker where no safety critical point needs to be protected. * To be used to identify specific locations on the track where the train shall stop when running without MA if the driver has received specific instruction from the signaller. * To be used to mark the location up to which the driver needs to confirm that the line is clear (e.g. for TAF function) To be used to mark the location up to which the driver has to drive under his/her responsibility before a possible MA in FS/OS is received. (image: 9-screenshot-20251001-151744-6.png)
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:MANUAL--ROUTE--SETTING_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Manual route setting refers to the {comment:274} process of manually configuring and establishing train routes within the railway network. This involves selecting and activating specific track paths that trains will follow during their journey. Manual route setting is typically carried out by railway signallers{comment:226} in the event that automatic route setting fails.{comment:229}Route{comment:242} will be replaced{comment:275} in the target system of SERA by Movement Permission, {comment:301}see here: SPT2TRAFFIC-7866 - Movement Permission", -- "Manual route setting refers to the historical process of manually configuring and establishing train routes within the railway network. This involves selecting and activating specific track paths that trains will follow during their journey. Manual route setting is typically carried out by railway operators or dispatchers in the event that automatic route setting fails. This concept will be replaced in the target system of SERA by Movement Permission, see here: SPT2TRAFFIC-7866 - Movement Permission" :diff_0202 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:MANUAL--ROUTE--SETTING_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Manual route setting refers to the {comment:274} process of manually configuring and establishing train routes within the railway network. This involves selecting and activating specific track paths that trains will follow during their journey. Manual route setting is typically carried out by railway signallers{comment:226} in the event that automatic route setting fails.{comment:229}Route{comment:242} will be replaced{comment:275} in the target system of SERA by Movement Permission, {comment:301}see here: SPT2TRAFFIC-7866 - Movement Permission
Manual route setting refers to the historical process of manually configuring and establishing train routes within the railway network. This involves selecting and activating specific track paths that trains will follow during their journey. Manual route setting is typically carried out by railway operators or dispatchers in the event that automatic route setting fails. This concept will be replaced in the target system of SERA by Movement Permission, see here: SPT2TRAFFIC-7866 - Movement Permission
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:MOVABLE--ELEMENT--DETECTION--_--DETECTED_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0203 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:MOVABLE--ELEMENT--DETECTION--_--DETECTED_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Refers to the position of a movable trackside element (see SPP-26712 - Movable trackside element) verified/confirmed by the Trackside CCS.{comment:280} For example, points/derailers can be detected right/left (direct or diverging) and Level Crossings can be detected "closed" (protected) or "open" (non-protected / with restrictions).{comment:228}{comment:239}
Refers to the position of a movable trackside element (see SPP-26712 - Movable trackside element) verified/confirmed by the Trackside CCS (Interlocking). For example, points/derailers can be detected right/left (direct or diverging) and Level Crossings can be detected "closed" (protected) or "open" (non-protected / with restrictions).{comment:151}
] . :diff_0204 a :Object_addition ; ordv:entity lex_sp-defs-251201:MOVABLE--ELEMENTS--ARE_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:MOVABLE--TRACKSIDE--ELEMENT_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Refers to points, derailers/catch points, LXs, bascule bridges, etc that can be operated to a specific position/direction normally between 2 possibilities. Position/direction refers to for example left/right in case of points.{comment:238}", -- "Refers to points, derailers/catch points, LXs, bascule bridges, etc that can be operated to a specific position/direction normally between 2 possibilities. Position/direction refers to for example left/right in case of points.{comment:148}" :diff_0205 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:MOVABLE--TRACKSIDE--ELEMENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Refers to points, derailers/catch points, LXs, bascule bridges, etc that can be operated to a specific position/direction normally between 2 possibilities. Position/direction refers to for example left/right in case of points.{comment:238}
Refers to points, derailers/catch points, LXs, bascule bridges, etc that can be operated to a specific position/direction normally between 2 possibilities. Position/direction refers to for example left/right in case of points.{comment:148}
] . :diff_0206 a :Object_addition ; ordv:entity lex_sp-defs-251201:MOVEMENT--PERMISSION_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:MULTI--DISPLAY--SYSTEM--UNIT_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The{comment:226}{comment:9} Multi Display System Unit consists of the generic Display Computing Unit, the Display Controller and the Touch Display (Touch Panel).", -- "The{comment:9} Multi Display System Unit consists of the generic Display Computing Unit, the Display Controller and the Touch Display (Touch Panel)." :diff_0207 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:MULTI--DISPLAY--SYSTEM--UNIT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The{comment:226}{comment:9} Multi Display System Unit consists of the generic Display Computing Unit, the Display Controller and the Touch Display (Touch Panel).
The{comment:9} Multi Display System Unit consists of the generic Display Computing Unit, the Display Controller and the Touch Display (Touch Panel).
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:OVERLAPPED_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Overlapped is the word used to describe two different objects referring, at least partially, to the same physical part of the track. For example, if a Movement Permission Extent is overlapping a Level Crossing, it means that at least some part of the Movement Permission extent goes over the outer limits of the Level Crossing. The technical description is as follows: Object A is overlapped by Object B (or vice versa) if the following condition is TRUE for at least one LinearElementSection in Object A: { The starting point of the LinearElementSection from Object A is between the starting and ending point of at least one LinearElementSection in Object B with the same LinearElement ID } OR { The ending point of the LinearElementSection from Object A is between the starting and ending point of at least one LinearElementSection B with the same LinearElement ID } OR { The starting point of at least one LinearElementSection from Object B is between the starting and ending point of the LinearElementSection from Object A with the same LinearElement ID }", -- "Overlapped is the word used to describe two different objects refering, at least partially, to the same physical part of the track. For example, if a Movement Permission Extent is overlapping a Level Crossing, it means that at least some part of the Movement Permission extent goes over the outer limits of the Level Crossing. The technical description is as follows: Object A is overlapped by Object B (or vice versa) if the following condition is TRUE for at least one LinearElementSection in Object A: { The starting point of the LinearElementSection from Object A is between the starting and ending point of at least one LinearElementSection in Object B with the same LinearElement ID } OR { The ending point of the LinearElementSection from Object A is between the starting and ending point of at least one LinearElementSection B with the same LinearElement ID } OR { The starting point of at least one LinearElementSection from Object B is between the starting and ending point of the LinearElementSection from Object A with the same LinearElement ID }" :diff_0208 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:OVERLAPPED_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Overlapped is the word used to describe two different objects referring, at least partially, to the same physical part of the track. For example, if a Movement Permission Extent is overlapping a Level Crossing, it means that at least some part of the Movement Permission extent goes over the outer limits of the Level Crossing. The technical description is as follows: Object A is overlapped by Object B (or vice versa) if the following condition is TRUE for at least one LinearElementSection in Object A: { The starting point of the LinearElementSection from Object A is between the starting and ending point of at least one LinearElementSection in Object B with the same LinearElement ID } OR { The ending point of the LinearElementSection from Object A is between the starting and ending point of at least one LinearElementSection B with the same LinearElement ID } OR { The starting point of at least one LinearElementSection from Object B is between the starting and ending point of the LinearElementSection from Object A with the same LinearElement ID }
Overlapped is the word used to describe two different objects refering, at least partially, to the same physical part of the track. For example, if a Movement Permission Extent is overlapping a Level Crossing, it means that at least some part of the Movement Permission extent goes over the outer limits of the Level Crossing. The technical description is as follows: Object A is overlapped by Object B (or vice versa) if the following condition is TRUE for at least one LinearElementSection in Object A: { The starting point of the LinearElementSection from Object A is between the starting and ending point of at least one LinearElementSection in Object B with the same LinearElement ID } OR { The ending point of the LinearElementSection from Object A is between the starting and ending point of at least one LinearElementSection B with the same LinearElement ID } OR { The starting point of at least one LinearElementSection from Object B is between the starting and ending point of the LinearElementSection from Object A with the same LinearElement ID }
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:OVERRIDE_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A procedure in specific degraded situations (for example in the case of loss of communication session or a failed trackside element (signal/MB,{comment:234} track circuit, failed point,{comment:235} etc)),{comment:233} when railways{comment:236} allow a train to pass its End of Movement Authority or an authorised location or a location that will trip the train. The driver must not use the Override procedure unless authorised by trackside personnel / Signaller. The OB has to fulfill certain conditions for the Override to be available in the DMI, these conditions are stated in Subset-026 section 5.8.2.1 and ERA_ERTMS_015560 (DMI specs) Table 34.", -- "A procedure in specific degraded situations (for example in the case of loss of communication session or a failed trackside element (signal/MB, track circuit, failed point, etc)), when railways allow a train to pass its End of Movement Authority or an authorised location or a location that will trip the train. The driver must not use the Override procedure unless authorised by trackside personnel / Signaller. The OB has to fulfill certain conditions for the Override to be available in the DMI, these conditions are stated in Subset-026 section 5.8.2.1 and ERA_ERTMS_015560 (DMI specs) Table 34." :diff_0209 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:OVERRIDE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A procedure in specific degraded situations (for example in the case of loss of communication session or a failed trackside element (signal/MB,{comment:234} track circuit, failed point,{comment:235} etc)),{comment:233} when railways{comment:236} allow a train to pass its End of Movement Authority or an authorised location or a location that will trip the train. The driver must not use the Override procedure unless authorised by trackside personnel / Signaller. The OB has to fulfill certain conditions for the Override to be available in the DMI, these conditions are stated in Subset-026 section 5.8.2.1 and ERA_ERTMS_015560 (DMI specs) Table 34.
A procedure in specific degraded situations (for example in the case of loss of communication session or a failed trackside element (signal/MB, track circuit, failed point, etc)), when railways allow a train to pass its End of Movement Authority or an authorised location or a location that will trip the train. The driver must not use the Override procedure unless authorised by trackside personnel / Signaller. The OB has to fulfill certain conditions for the Override to be available in the DMI, these conditions are stated in Subset-026 section 5.8.2.1 and ERA_ERTMS_015560 (DMI specs) Table 34.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:POSITION--REPORT_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0210 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:POSITION--REPORT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The "Position Report" (PR) is a structured message {comment:302}sent from the train’s On-board (OBU){comment:312} to the trackside CCS such as the RBC). This report communicates the current position of the train, including its precise {comment:303}location, direction, speed, and other relevant status information. The Position Report allows the trackside system to continuously {comment:304}track the train’s progress, ensure safety, and allocate new movement authorities accordingly. Position Reports are fundamental to ETCS because they enable accurate, real-time management of train movements without relying on trackside detection equipment.{comment:270}{comment:313}{comment:314}
{comment:131}The "Position Report" (PR) is a structured message sent from the train’s On-board (OBU) to the trackside CCS such as the RBC). This report communicates the current position of the train, including its precise location, direction, speed, and other relevant status information. The Position Report allows the trackside system to continuously track the train’s progress, ensure safety, and allocate new movement authorities accordingly. Position Reports are fundamental to ETCS because they enable accurate, real-time management of train movements without relying on trackside detection equipment.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:PRESENTATION--LOGIC_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The presentation logic controls the flow (dialogue sequence) and layout elements of the User{comment:227} interface using system specific layouts based on generic layout elements. The presentation logic may also include data validation", -- "The presentation logic controls the flow (dialogue sequence) and layout elements of the User interface using system specific layouts based on generic layout elements. The presentation logic may also include data validation" :diff_0211 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:PRESENTATION--LOGIC_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The presentation logic controls the flow (dialogue sequence) and layout elements of the User{comment:227} interface using system specific layouts based on generic layout elements. The presentation logic may also include data validation
The presentation logic controls the flow (dialogue sequence) and layout elements of the User interface using system specific layouts based on generic layout elements. The presentation logic may also include data validation
] . :diff_0212 a :Object_addition ; ordv:entity lex_sp-defs-251201:PRIMARY--ROUTE_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:RADIO--CONNECTION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0213 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:RADIO--CONNECTION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Often referred in the specifications as "safe radio connection" or "safe connection" is the connection between an On-board and an RBC{comment:291} and its management is contained in the EURORADIO specifications.{comment:306}{comment:319} The indication statuses of the safe radio connection are: “No Connection”, “Connection Lost/Set-Up failed”, “Connection{comment:292} Up”.{comment:307} The national/default values for the supervision of the safe radio connection are T_NVCONTACT{comment:318} and M_NVCONTACT. Note that it is a different concept to SPP-28486 - Missing cross-reference.
Often referred in the specifications as "safe radio connection" or "safe connection" is the connection between an On-board and an RBC and its management is contained in the EURORADIO specifications. The indication statuses of the safe radio connection are: “No Connection”, “Connection Lost/Set-Up failed”, “Connection Up”. The national/default values for the supervision of the safe radio connection are T_NVCONTACT and M_NVCONTACT. Note that it is a different concept to SPP-28486 - Missing cross-reference.{comment:154}
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:REARVIEW--SYSTEM_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Rearview system permits to see the states of the doors at standstill. The ergonomics of this system is{comment:211} supplier-specific; no norm or standard specify it. Two displays are used for the rearview system. Two options exist for the position of the displays : one on the left side of the cab and the other on the right side of the cab (left doors vs. right doors), or the two displays side by side on the left or on the right side of the cab. The SIL associated to this system is SIL0 (Basic Integrity). Images from cameras are only displayed at standstill. Current communication between Rearview system and its displays{comment:212} is supplier-specific. To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered.", -- "The Rearview system permits to see the states of the doors at standstill. The ergonomics of this system is supplier specific; no norm or standard specify it. Two displays are used for the rearview system. Two options exist for the position of the displays : one on the left side of the cab and the other on the right side of the cab (left doors vs. right doors), or the two displays side by side on the left or on the right side of the cab. The SIL associated to this system is SIL0 (Basic Integrity). Images from cameras are only displayed at standstill. Current communication between Rearview system and its displays is supplier specific. To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered." :diff_0214 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:REARVIEW--SYSTEM_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Rearview system permits to see the states of the doors at standstill. The ergonomics of this system is{comment:211} supplier-specific; no norm or standard specify it. Two displays are used for the rearview system. Two options exist for the position of the displays : one on the left side of the cab and the other on the right side of the cab (left doors vs. right doors), or the two displays side by side on the left or on the right side of the cab. The SIL associated to this system is SIL0 (Basic Integrity). Images from cameras are only displayed at standstill. Current communication between Rearview system and its displays{comment:212} is supplier-specific. To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered.
The Rearview system permits to see the states of the doors at standstill. The ergonomics of this system is supplier specific; no norm or standard specify it. Two displays are used for the rearview system. Two options exist for the position of the displays : one on the left side of the cab and the other on the right side of the cab (left doors vs. right doors), or the two displays side by side on the left or on the right side of the cab. The SIL associated to this system is SIL0 (Basic Integrity). Images from cameras are only displayed at standstill. Current communication between Rearview system and its displays is supplier specific. To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:REMOTE--TRAIN--OPERATION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Remote Train Operation (RTO) system is an operational entity. It provides the status of the train in terms of remote driving: stand-alone, monitored, observed and controlled. Depending on these{comment:196} stati, the MDS can change the active configuration of the cab displays. In addition to provide input to the MDS, the RTO may require a specific view on a display. If so, {comment:195}the interface between the RTO and the MDS will be the same as for the other systems described below.", -- "The Remote Train Operation (RTO) system is an operational entity. It provides the status of the train in terms of remote driving: stand-alone, monitored, observed and controlled. Depending on this status, the MDS can change the active configuration of the cab displays. In addition to provide input to the MDS, the RTO may require a specific view on a display. If so, the interface between the RTO and the MDS will be the same as for the other systems described below." :diff_0215 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:REMOTE--TRAIN--OPERATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Remote Train Operation (RTO) system is an operational entity. It provides the status of the train in terms of remote driving: stand-alone, monitored, observed and controlled. Depending on these{comment:196} stati, the MDS can change the active configuration of the cab displays. In addition to provide input to the MDS, the RTO may require a specific view on a display. If so, {comment:195}the interface between the RTO and the MDS will be the same as for the other systems described below.
The Remote Train Operation (RTO) system is an operational entity. It provides the status of the train in terms of remote driving: stand-alone, monitored, observed and controlled. Depending on this status, the MDS can change the active configuration of the cab displays. In addition to provide input to the MDS, the RTO may require a specific view on a display. If so, the interface between the RTO and the MDS will be the same as for the other systems described below.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:REQUEST_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A Request on the SCI-CMD or SCI-SCMD interface is a message from a client to ETPS which asks ETPS for a certain task. ETPS will perform a number of safety checks and if at least one fails, the Request is rejected, otherwise it is granted and executed.", -- "A Request on the SCI-CMD or SCI-SCMD{comment:1276} interface is a message from a client to ETPS which asks ETPS for a certain task. ETPS will perform a number of safety checks and if at least one fails, the Request is rejected, otherwise it is granted and executed." :diff_0216 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:REQUEST_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A Request on the SCI-CMD or SCI-SCMD interface is a message from a client to ETPS which asks ETPS for a certain task. ETPS will perform a number of safety checks and if at least one fails, the Request is rejected, otherwise it is granted and executed.
A Request on the SCI-CMD or SCI-SCMD{comment:1276} interface is a message from a client to ETPS which asks ETPS for a certain task. ETPS will perform a number of safety checks and if at least one fails, the Request is rejected, otherwise it is granted and executed.
] . :diff_0217 a :Object_addition ; ordv:entity lex_sp-defs-251201:REQUEST_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:RISK--PATH_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Risk Path is one potential path by which a non-permitted vehicle movement could result in a flank collision with a vehicle moving along the Movement Permission extent. The Risk Path starts at each end of the relevant Fouling Section in the extent of the Movement Permission (including the Risk Buffer, if not opted out by other configuration) and is limited through a sufficient method for providing flank protection. For instance, a Switchable Track Asset or Movement Permission could be used for limiting the Risk Path. The Risk Path is defined as a Contiguous Track Area.", -- "A Risk Path is one potential path (a linear contiguous stretch of track) by which a non-permitted vehicle movement could result in a flank collision with a vehicle moving along the Movement Permission Extent. A Movement Permission can contain zero or more Risk Paths." :diff_0218 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:RISK--PATH_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Risk Path is one potential path by which a non-permitted vehicle movement could result in a flank collision with a vehicle moving along the Movement Permission extent. The Risk Path starts at each end of the relevant Fouling Section in the extent of the Movement Permission (including the Risk Buffer, if not opted out by other configuration) and is limited through a sufficient method for providing flank protection. For instance, a Switchable Track Asset or Movement Permission could be used for limiting the Risk Path. The Risk Path is defined as a Contiguous Track Area.
A Risk Path is one potential path (a linear contiguous stretch of track) by which a non-permitted vehicle movement could result in a flank collision with a vehicle moving along the Movement Permission Extent. A Movement Permission can contain zero or more Risk Paths.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:RISK--PATH_lexConcept_2 ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A Risk Path is one potential path (a linear contiguous stretch of track) by which a non-permitted vehicle movement could result in a flank collision with a vehicle moving along the Movement Permission Extent. A Movement Permission can contain zero or more Risk Paths.", -- "The Risk Path is one potential path by which a non-permitted vehicle movement could result in a flank collision with a vehicle moving along the Movement Permission extent. The Risk Path starts at each end of the relevant Fouling Section in the extent of the Movement Permission (including the Risk Buffer, if not opted out by other configuration) and is limited through a sufficient method for providing flank protection. For instance, a Switchable Track Asset or Movement Permission could be used for limiting the Risk Path. The Risk Path is defined as a Contiguous Track Area." :diff_0219 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:RISK--PATH_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
] . :diff_0220 a :Object_addition ; ordv:entity lex_sp-defs-251201:RISK--PATH_lexConcept_3 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:ROUTE--IN--RAILWAY--OPERATIONS--AND--CCS_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0221 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:ROUTE--IN--RAILWAY--OPERATIONS--AND--CCS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A "route" refers in railway operations and the context of Control Command and Signalling (CCS) to a specific path through the railway network that is set or authorised for a train to move from a defined starting point to a defined end point. This path is ensured to be free of conflicting train movements, with all points (switches) and signals{comment:286} set accordingly to allow the train to pass safely. In the CCS context, the route includes: * The successive track sections or blocks * Configured points set and locked for the intended movement * Required flank or protection measures active{comment:284} * All other conflicting movements prevented by interlocking or CCS logic{comment:232} Routes are fundamental to safe train movement and are established by the signalling system before a train is allowed to proceed. This concept of route will be replaced{comment:285} in the target system of SERA by Movement Permission, see here: SPT2TRAFFIC-7866 - Movement Permission
A "route" refers in railway operations and the context of Control Command and Signalling (CCS) to a specific path through the railway network that is set or authorised for a train to move from a defined starting point to a defined end point. This path is ensured to be free of conflicting train movements, with all points (switches) and signals set accordingly to allow the train to pass safely. In the CCS context, the route includes: * The successive track sections or blocks * Configured points set and locked for the intended movement * Required flank or protection measures active * All other conflicting movements prevented by interlocking or CCS logic Routes are fundamental to safe train movement and are established by the signalling system before a train is allowed to proceed. This concept of route will be replaced in the target system of SERA by Movement Permission, see here: SPT2TRAFFIC-7866 - Movement Permission{comment:153}
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:SAFE--TRAIN--EXTENT_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Safe Train Extent represents the extent of the track that may be occupied by a connected train. It is calculated from train-side information (Confirmed Rear End and Max Safe Front End derived from the ETCS Position Report) and track-side information (track vacancy proving sections like track circuits or axle counters), taking into account the most recent information available from these train- and track-side information sources. Remarks: * The Safe Train Extent for a train will be updated when new information becomes available. * For a moving train, it is likely that the train will move outside the Safe Train Extent between updates", -- "The Safe Train Extent represents the extent of the track that may be occupied by a connected train. It is calculated from train-side information (Confirmed Rear End and Max Safe Front End derived from the ETCS Position Report) and track-side information (track vacancy proving sections like track circuits or axle counters), taking into account the most recent information available from these train- and track-side information sources. Remarks: * The Safe Train Extent for a train will be updated when new information becomes available. * For a moving train, it is likely that the train will move outside the Safe Train Extent between update" :diff_0222 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:SAFE--TRAIN--EXTENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Safe Train Extent represents the extent of the track that may be occupied by a connected train. It is calculated from train-side information (Confirmed Rear End and Max Safe Front End derived from the ETCS Position Report) and track-side information (track vacancy proving sections like track circuits or axle counters), taking into account the most recent information available from these train- and track-side information sources. Remarks: * The Safe Train Extent for a train will be updated when new information becomes available. * For a moving train, it is likely that the train will move outside the Safe Train Extent between updates
The Safe Train Extent represents the extent of the track that may be occupied by a connected train. It is calculated from train-side information (Confirmed Rear End and Max Safe Front End derived from the ETCS Position Report) and track-side information (track vacancy proving sections like track circuits or axle counters), taking into account the most recent information available from these train- and track-side information sources. Remarks: * The Safe Train Extent for a train will be updated when new information becomes available. * For a moving train, it is likely that the train will move outside the Safe Train Extent between update
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:SAFETY--PRINCIPLES--ARE--BINDING--GUIDELINES--AND--CONDITIONS--TO--RESPECT--FOR--SAFE--TRAI_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Safety principles are binding guidelines and conditions to respect for safe train movement. Details described here: S2 Harmonisation operational Safety Principles (image: 1-9-screenshot-20250930-145656-24.png)", -- "Safety principles are binding guidelines and conditions to respect for safe train movement. Details described here: S2 Harmonisation operational Safety Principles (image: 9-screenshot-20250930-145656-24.png)" :diff_0223 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:SAFETY--PRINCIPLES--ARE--BINDING--GUIDELINES--AND--CONDITIONS--TO--RESPECT--FOR--SAFE--TRAI_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Safety principles are binding guidelines and conditions to respect for safe train movement. Details described here: S2 Harmonisation operational Safety Principles (image: 1-9-screenshot-20250930-145656-24.png)
Safety principles are binding guidelines and conditions to respect for safe train movement. Details described here: S2 Harmonisation operational Safety Principles (image: 9-screenshot-20250930-145656-24.png)
] . :diff_0224 a :Object_addition ; ordv:entity lex_sp-defs-251201:SAFETY--PRINCIPLES--ARE--BINDING--GUIDELINES--AND--CONDITIONS--TO--RESPECT--FOR--SAFE--TRAI_lexConcept_2 . :diff_0225 a :Object_addition ; ordv:entity lex_sp-defs-251201:SECONDARY--ROUTE_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:SECURE--COMPONENT_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "An implementation, as part of an automation control system, which comprises one or more host devices, embedded devices, network devices or software applications on host devices. A secure component realizes subsystem functions, implements security capabilities, consists of a physical encasing, computing capabilities and network communication, and interfaces to the Shared Cybersecurity Services. Examples of CCS secure components are object controller, trackside cabinet, IXL rack, ATO-OB, OBU, ATO-TS, IXL/RBC combination, shared cybersecurity services, security proxy for legacy devices, …) Examples of components which are not meeting the definition of a Secure Component are components with no network communication, e.g. directly connected sensors or displays.", -- "An implementation, as part of an automation control system, either a host device, embedded device, network device or software application on a host device, which realizes subsystem functions, implements security capabilities and consisting of a physical encasing, computing capabilities and network communication, and interfacing to the Shared Cybersecurity Services. Examples of CCS secure components are object controller, trackside cabinet, IXL rack, ATO-OB, OBU, ATO-TS, IXL/RBC combination, shared cybersecurity services, security proxy for legacy devices, …) Examples of components which are not meeting the definition of a Secure Component are components with no network communication, e.g. directly connected sensors or displays." :diff_0226 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:SECURE--COMPONENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
An implementation, as part of an automation control system, which comprises one or more host devices, embedded devices, network devices or software applications on host devices. A secure component realizes subsystem functions, implements security capabilities, consists of a physical encasing, computing capabilities and network communication, and interfaces to the Shared Cybersecurity Services. Examples of CCS secure components are object controller, trackside cabinet, IXL rack, ATO-OB, OBU, ATO-TS, IXL/RBC combination, shared cybersecurity services, security proxy for legacy devices, …) Examples of components which are not meeting the definition of a Secure Component are components with no network communication, e.g. directly connected sensors or displays.
An implementation, as part of an automation control system, either a host device, embedded device, network device or software application on a host device, which realizes subsystem functions, implements security capabilities and consisting of a physical encasing, computing capabilities and network communication, and interfacing to the Shared Cybersecurity Services. Examples of CCS secure components are object controller, trackside cabinet, IXL rack, ATO-OB, OBU, ATO-TS, IXL/RBC combination, shared cybersecurity services, security proxy for legacy devices, …) Examples of components which are not meeting the definition of a Secure Component are components with no network communication, e.g. directly connected sensors or displays.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:SHUNTING--MOVEMENT_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Shunting movement refers to the process of moving railway vehicles (such as locomotives, passengers carriages, or freight wagons) within a rail yard or between tracks, typically for the purpose of assembling trains, repositioning vehicles, or preparing them for departure. Shunting movements are essential for the efficient management of rail operations. Shunting movements can be classified into two categories: supervised shunting and unsupervised shunting. {comment:230}See also reference SPLI-1040 - SHUNTING MOVEMENT and SPLI-1796 - Shunting movement", -- "Shunting movement refers to the process of moving railway vehicles (such as locomotives, passengers carriages, or freight wagons) within a rail yard or between tracks, typically for the purpose of assembling trains, repositioning vehicles, or preparing them for departure. Shunting movements are essential for the efficient management of rail operations. Shunting movements can be classified into two categories: supervised shunting and unsupervised shunting. See also reference SPLI-1040 - SHUNTING MOVEMENT and SPLI-1796 - Shunting movement" :diff_0227 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:SHUNTING--MOVEMENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Shunting movement refers to the process of moving railway vehicles (such as locomotives, passengers carriages, or freight wagons) within a rail yard or between tracks, typically for the purpose of assembling trains, repositioning vehicles, or preparing them for departure. Shunting movements are essential for the efficient management of rail operations. Shunting movements can be classified into two categories: supervised shunting and unsupervised shunting. {comment:230}See also reference SPLI-1040 - SHUNTING MOVEMENT and SPLI-1796 - Shunting movement
Shunting movement refers to the process of moving railway vehicles (such as locomotives, passengers carriages, or freight wagons) within a rail yard or between tracks, typically for the purpose of assembling trains, repositioning vehicles, or preparing them for departure. Shunting movements are essential for the efficient management of rail operations. Shunting movements can be classified into two categories: supervised shunting and unsupervised shunting. See also reference SPLI-1040 - SHUNTING MOVEMENT and SPLI-1796 - Shunting movement
] . :diff_0228 a :Object_addition ; ordv:entity lex_sp-defs-251201:SIGNALLER--AREA--OF--CONTROL_lexConcept . :diff_0229 a :Object_addition ; ordv:entity lex_sp-defs-251201:SPRING--POINT_SWITCH_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:STANDSTILL_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Standstill is when the train’s speed is detected as 0 km/h by the onboard system,{comment:305} within the accuracy and limits of the system’s detection capabilities.{comment:290} In context of door closing procedure there is also the limit at or below 3 km/h and no un-commanded propulsion is available.{comment:316} This harmonises the intent of both TSIs: it acknowledges the LOC&PAS practical threshold (due to system tolerances) but defaults to the CCS zero-movement criterion when safety functions are involved.{comment:271}", -- "Standstill is when the train’s speed is detected as 0 km/h by the onboard system, within the accuracy and limits of the system’s detection capabilities. In context of door closing procedure there is also the limit at or below 3 km/h and no un-commanded propulsion is available. This harmonises the intent of both TSIs: it acknowledges the LOC&PAS practical threshold (due to system tolerances) but defaults to the CCS zero-movement criterion when safety functions are involved." :diff_0230 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:STANDSTILL_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Standstill is when the train’s speed is detected as 0 km/h by the onboard system,{comment:305} within the accuracy and limits of the system’s detection capabilities.{comment:290} In context of door closing procedure there is also the limit at or below 3 km/h and no un-commanded propulsion is available.{comment:316} This harmonises the intent of both TSIs: it acknowledges the LOC&PAS practical threshold (due to system tolerances) but defaults to the CCS zero-movement criterion when safety functions are involved.{comment:271}
Standstill is when the train’s speed is detected as 0 km/h by the onboard system, within the accuracy and limits of the system’s detection capabilities. In context of door closing procedure there is also the limit at or below 3 km/h and no un-commanded propulsion is available. This harmonises the intent of both TSIs: it acknowledges the LOC&PAS practical threshold (due to system tolerances) but defaults to the CCS zero-movement criterion when safety functions are involved.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:STOP--MARKER--BOARD_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A Harmonised trackside ETCS marker board defined in EN 16494/2015 is a fixed, clearly recognisable trackside sign that indicates the location where a driver has to stop the train, if running without an MA. Further purpose defined by ERTMS Users Group: * To be used to unambiguously identify an EOA which must not be overpassed without authorisation by the signaller and which may protect one or a group of safety-critical points such as a point switch, a conflicting route, an entrance of a station, junctions, etc. * To be used to identify specific location on the track the train shall not overpass when an MA is not available, unless the driver has received a specific authorisation by the signaller. * To be used to mark the location up to which the driver needs to confirm that the line is clear (e.g. for TAF function).{comment:281} To be used to mark the location up to which the driver has to drive under his/her responsibility before a possible MA in FS/OS is received. (image: 8-screenshot-20251001-151620-5.png) {comment:265}{comment:310}", -- "{comment:130}{comment:177}A Harmonised trackside ETCS marker board defined in EN 16494/2015 is a fixed, clearly recognisable trackside sign that indicates the location where a driver has to stop the train, if running without an MA. Further purpose defined by ERTMS Users Group: * To be used to unambiguously identify an EOA which must not be overpassed without authorisation by the signaller and which may protect one or a group of safety-critical points such as a point switch, a conflicting route, an entrance of a station, junctions, etc. * To be used to identify specific location on the track the train shall not overpass when an MA is not available, unless the driver has received a specific authorisation by the signaller. * To be used to mark the location up to which the driver needs to confirm that the line is clear (e.g. for TAF function). To be used to mark the location up to which the driver has to drive under his/her responsibility before a possible MA in FS/OS is received. (image: 8-screenshot-20251001-151620-5.png)" :diff_0231 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:STOP--MARKER--BOARD_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A Harmonised trackside ETCS marker board defined in EN 16494/2015 is a fixed, clearly recognisable trackside sign that indicates the location where a driver has to stop the train, if running without an MA. Further purpose defined by ERTMS Users Group: * To be used to unambiguously identify an EOA which must not be overpassed without authorisation by the signaller and which may protect one or a group of safety-critical points such as a point switch, a conflicting route, an entrance of a station, junctions, etc. * To be used to identify specific location on the track the train shall not overpass when an MA is not available, unless the driver has received a specific authorisation by the signaller. * To be used to mark the location up to which the driver needs to confirm that the line is clear (e.g. for TAF function).{comment:281} To be used to mark the location up to which the driver has to drive under his/her responsibility before a possible MA in FS/OS is received. (image: 8-screenshot-20251001-151620-5.png) {comment:265}{comment:310}
{comment:130}{comment:177}A Harmonised trackside ETCS marker board defined in EN 16494/2015 is a fixed, clearly recognisable trackside sign that indicates the location where a driver has to stop the train, if running without an MA. Further purpose defined by ERTMS Users Group: * To be used to unambiguously identify an EOA which must not be overpassed without authorisation by the signaller and which may protect one or a group of safety-critical points such as a point switch, a conflicting route, an entrance of a station, junctions, etc. * To be used to identify specific location on the track the train shall not overpass when an MA is not available, unless the driver has received a specific authorisation by the signaller. * To be used to mark the location up to which the driver needs to confirm that the line is clear (e.g. for TAF function). To be used to mark the location up to which the driver has to drive under his/her responsibility before a possible MA in FS/OS is received. (image: 8-screenshot-20251001-151620-5.png)
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:STOPPING--LOCATION_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0232 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:STOPPING--LOCATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A stopping location (see also stopping point SPLI-1805 - Stopping point ) in ETCS Level 2 is the operational or electronic location where a train must stop, which can be defined by the EoA, a Stop Marker Board, buffer stop, other signals or operational situations (e. g. wrong path/point) or a platform-specific marker. The specific type chosen and its relation to the actual stopping action depends on operational context and infrastructure. ETCS ensures the train never passes its defined EoA, which may be set according to these physical or operational markers to match the scenario. In ETCS Level 2 railway operations, a "stopping location" is a precisely defined location where a train must come to a controlled standstill according to operational or signalling requirements. The stopping point can relate to different types of end locations or markers, such as: * End of Movement Authority (EoA):** The EoA is the furthest point up to which a train is authorized to move, transmitted electronically to the train via ETCS. It is a dynamic safe limit but not always a physically visible location. The EoA serves as a crucial stopping point, particularly in signal-controlled or cab-signalling sections. * Stop Marker Board (z. B. ETCS Stop Marker):** This is a physical sign on the track indicating where the train must stop. In ETCS operations, such boards are used at locations like platform ends or station entries where a precise physical stop is required. They serve as a visual reference and may coincide with the EoA or be separately enforced under operational rules. * Buffer Stops:** Buffer stops are physical barriers at the end of tracks, typically in terminal stations. The stopping point is set at a safe distance before the buffer stop, defined either by an operational instruction or by a marker. In ETCS, an EoA is placed in front of the buffer stop to ensure safe braking. * Platform Stops with Orientation Markers:** At platforms, stopping points may be designated by physical boards or electronic information, ensuring that the train aligns doors with the platform for passenger exchange. These points can include additional orientation markers (e.g., "Stop 1", "Stop 2") to guide train drivers depending on train length or type. There is no established difference between "stopping point" and "stopping location" in the context of ETCS Level 2 operations. Both terms generally refer to a defined spot—whether electronically (such as by EoA) or physically (such as a stop board, buffer stop, or platform marker)—where a train is required to come to a halt according to operational directives. In official documentation, the terms may sometimes be used interchangeably. If any distinction is made, it would usually be context-dependent, for example: - "Stopping point" could emphasize precision, meaning an exact, narrowly-defined halt position. - "Stopping location" might refer to a somewhat broader area, for example the general place where stopping is to occur, possibly including range markers (such as “between marker X and Y”). Both terms serve the same safety-critical function: specifying where a train is required to stop. For formal safety and operation, always use the terminology and definitions provided by your company or infrastructure manager. If you need clarification with official sources, please specify your organization or documentation type.
A stopping location (see also stopping point SPLI-1805 - Stopping point ) in ETCS Level 2 is the operational or electronic location where a train must stop, which can be defined by the EoA, a Stop Marker Board, buffer stop, other signals or operational situations (e. g. wrong path/point) or a platform-specific marker. The specific type chosen and its relation to the actual stopping action depends on operational context and infrastructure. ETCS ensures the train never passes its defined EoA, which may be set according to these physical or operational markers to match the scenario. In ETCS Level 2 railway operations, a "stopping location" is a precisely defined location where a train must come to a controlled standstill according to operational or signaling requirements. The stopping point can relate to different types of end locations or markers, such as: * End of Movement Authority (EoA):** The EoA is the furthest point up to which a train is authorized to move, transmitted electronically to the train via ETCS. It is a dynamic safe limit but not always a physically visible location. The EoA serves as a crucial stopping point, particularly in signal-controlled or cab-signaling sections. * Stop Marker Board (z. B. ETCS Stop Marker):** This is a physical sign on the track indicating where the train must stop. In ETCS operations, such boards are used at locations like platform ends or station entries where a precise physical stop is required. They serve as a visual reference and may coincide with the EoA or be separately enforced under operational rules. * Buffer Stops:** Buffer stops are physical barriers at the end of tracks, typically in terminal stations. The stopping point is set at a safe distance before the buffer stop, defined either by an operational instruction or by a marker. In ETCS, an EoA is placed in front of the buffer stop to ensure safe braking. * Platform Stops with Orientation Markers:** At platforms, stopping points may be designated by physical boards or electronic information, ensuring that the train aligns doors with the platform for passenger exchange. These points can include additional orientation markers (e.g., "Stop 1", "Stop 2") to guide train drivers depending on train length or type. There is no established difference between "stopping point" and "stopping location" in the context of ETCS Level 2 operations. Both terms generally refer to a defined spot—whether electronically (such as by EoA) or physically (such as a stop board, buffer stop, or platform marker)—where a train is required to come to a halt according to operational directives. In official documentation, the terms may sometimes be used interchangeably. If any distinction is made, it would usually be context-dependent, for example: - "Stopping point" could emphasize precision, meaning an exact, narrowly-defined halt position. - "Stopping location" might refer to a somewhat broader area, for example the general place where stopping is to occur, possibly including range markers (such as “between marker X and Y”). Both terms serve the same safety-critical function: specifying where a train is required to stop. For formal safety and operation, always use the terminology and definitions provided by your company or infrastructure manager. If you need clarification with official sources, please specify your organization or documentation type.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:SYSTEMS_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "In the context of MDS, these are operational entities that require a human-machine interface. There are several systems in a cab. In this chapter, it is proposed to present the main systems considered in this paper in order to find the characteristic{comment:197} to be analysed from perspective of MDS. {comment:198}So descriptions of ETCS, TCMS, CVR and Rearview systems are given below and give an overview of their current situation. Other systems exist, such as Electronic{comment:199} Timetable Display, and should also be considered. However, it is assumed that the characteristics of the systems analysed would remain applicable to the other systems. An exhaustive analysis should be carried out to be sure of the relevance of this proposal. So far, the following characteristics have been considered: ergonomics, location in the cab, SIL requirements, {comment:200}when visibility is required, interface between the system and the driver's display.", -- "In the context of MDS, these are operational entities that require a human-machine interface. There are several systems in a cab. In this chapter, it is proposed to present the main systems considered in this paper in order to find the characteristic to be analysed from perspective of MDS. So descriptions of ETCS, TCMS, CVR and Rearview systems are given below and give an overview of their current situation. Other systems exist, such as Electronic Timetable Display, and should also be considered. However, it is assumed that the characteristics of the systems analysed would remain applicable to the other systems. An exhaustive analysis should be carried out to be sure of the relevance of this proposal. So far, the following characteristics have been considered: ergonomics, location in the cab, SIL requirements, when visibility is required, interface between the system and the driver's display." :diff_0233 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:SYSTEMS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
In the context of MDS, these are operational entities that require a human-machine interface. There are several systems in a cab. In this chapter, it is proposed to present the main systems considered in this paper in order to find the characteristic{comment:197} to be analysed from perspective of MDS. {comment:198}So descriptions of ETCS, TCMS, CVR and Rearview systems are given below and give an overview of their current situation. Other systems exist, such as Electronic{comment:199} Timetable Display, and should also be considered. However, it is assumed that the characteristics of the systems analysed would remain applicable to the other systems. An exhaustive analysis should be carried out to be sure of the relevance of this proposal. So far, the following characteristics have been considered: ergonomics, location in the cab, SIL requirements, {comment:200}when visibility is required, interface between the system and the driver's display.
In the context of MDS, these are operational entities that require a human-machine interface. There are several systems in a cab. In this chapter, it is proposed to present the main systems considered in this paper in order to find the characteristic to be analysed from perspective of MDS. So descriptions of ETCS, TCMS, CVR and Rearview systems are given below and give an overview of their current situation. Other systems exist, such as Electronic Timetable Display, and should also be considered. However, it is assumed that the characteristics of the systems analysed would remain applicable to the other systems. An exhaustive analysis should be carried out to be sure of the relevance of this proposal. So far, the following characteristics have been considered: ergonomics, location in the cab, SIL requirements, when visibility is required, interface between the system and the driver's display.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:TCMS--TDD--DISPLAY_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The display associated to this system is called TDD (Technical and Diagnostic Display) in UIC-612. The ergonomics of this system is{comment:203} also defined in UIC-612-3.The TDD is located on the right side of the cab according to UIC-612-0, EN 16186-2 (chapter 7.21). Depending of the configuration of the train, the SIL associated to TDD could be SIL2 (when safety related information are only displayed on TDD) or SIL0 / Basic Integrity (when safety related information is{comment:204} presented on TDD and also with safe lights in cab). According to EN 16186-3 (table B.2), if existing, some information is{comment:205} mandatory for high speed class 1 trains. Otherwise, other information is{comment:206} optional. Current communication between TCMS and TDD is supplier-specific. To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered.", -- "The display associated to this system is called TDD (Technical and Diagnostic Display) in UIC-612. The ergonomics of this system is also defined in UIC-612-3.The TDD is located on the right side of the cab according to UIC-612-0, EN 16186-2 (chapter 7.21). Depending of the configuration of the train, the SIL associated to TDD could be SIL2 (when safety related information are only displayed on TDD) or SIL0 / Basic Integrity (when safety related information is presented on TDD and also with safe lights in cab). According to EN 16186-3 (table B.2), if existing, some information is mandatory for high speed class 1 trains. Otherwise, other information is optional. Current communication between TCMS and TDD is supplier-specific. To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered." :diff_0234 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:TCMS--TDD--DISPLAY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The display associated to this system is called TDD (Technical and Diagnostic Display) in UIC-612. The ergonomics of this system is{comment:203} also defined in UIC-612-3.The TDD is located on the right side of the cab according to UIC-612-0, EN 16186-2 (chapter 7.21). Depending of the configuration of the train, the SIL associated to TDD could be SIL2 (when safety related information are only displayed on TDD) or SIL0 / Basic Integrity (when safety related information is{comment:204} presented on TDD and also with safe lights in cab). According to EN 16186-3 (table B.2), if existing, some information is{comment:205} mandatory for high speed class 1 trains. Otherwise, other information is{comment:206} optional. Current communication between TCMS and TDD is supplier-specific. To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered.
The display associated to this system is called TDD (Technical and Diagnostic Display) in UIC-612. The ergonomics of this system is also defined in UIC-612-3.The TDD is located on the right side of the cab according to UIC-612-0, EN 16186-2 (chapter 7.21). Depending of the configuration of the train, the SIL associated to TDD could be SIL2 (when safety related information are only displayed on TDD) or SIL0 / Basic Integrity (when safety related information is presented on TDD and also with safe lights in cab). According to EN 16186-3 (table B.2), if existing, some information is mandatory for high speed class 1 trains. Otherwise, other information is optional. Current communication between TCMS and TDD is supplier-specific. To facilitate the deployment of the MDS solution, a migration to a generic communication used also by other systems should be considered.
] . :diff_0235 a :Object_addition ; ordv:entity lex_sp-defs-251201:THE--DESTINATION--IS--A--LOCATION--WHERE_lexConcept_2 . :diff_0236 a :Object_addition ; ordv:entity lex_sp-defs-251201:THE--START--OF--MISSION--SOM--IS--THE--ETCS-START---THE--DRIVER--PREPARES--WITH--THE--SOM--T_lexConcept_2 . :diff_0237 a :Object_addition ; ordv:entity lex_sp-defs-251201:THE--TRAIN--CHARACTERISTICS--INCLUDE--THE--MANDATORY--INFORMATION--ON--THE--TECHNICAL--CHA_lexConcept_2 . :diff_0238 a :Object_addition ; ordv:entity lex_sp-defs-251201:TRACK--ELEMENTS--ARE--MOVABLE--ELEMENTS--TRACK--SECTIONS--LEVEL--CROSSINGS_lexConcept_2 . :diff_0239 a :Object_addition ; ordv:entity lex_sp-defs-251201:TRACKSIDE--DETECTORS_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:TRAFFIC--MANAGEMENT--SYSTEM_lexConcept_2 ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Traffic Management System", -- "Traffic Management System is used to manage the operation of the railway system and to ensure efficient recovery when unexpected traffic disruptions occur." :diff_0240 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:TRAFFIC--MANAGEMENT--SYSTEM_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
Traffic Management System is used to manage the operation of the railway system and to ensure efficient recovery when unexpected traffic disruptions occur.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:TRAFFIC--MANAGEMENT--SYSTEM_lexConcept_3 ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Traffic Management System is used to manage the operation of the railway system and to ensure efficient recovery when unexpected traffic disruptions occur.", -- "Traffic Management System" :diff_0241 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:TRAFFIC--MANAGEMENT--SYSTEM_lexConcept_3 ; ordv:predicate skos:definition ; ordv:changes [
] . :diff_0242 a :Object_addition ; ordv:entity lex_sp-defs-251201:TRAFFIC--MANAGEMENT--SYSTEM_lexConcept_4 . :diff_0243 a :Object_addition ; ordv:entity lex_sp-defs-251201:TRAILED--POINT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:TRAIN--JOINING_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Train joining is an operational procedure that involves the process of combining two or more separate consists into a single train, possible anywhere on the network. This operation is typically planned in advance as part of the operational plan, whether short-term or long-term.{comment:246}", -- "Train joining is an operational procedure that involves the process of combining two or more separate consists into a single train, possible anywhere on the network. This operation is typically planned in advance as part of the operational plan, whether short-term or long-term." :diff_0244 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:TRAIN--JOINING_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Train joining is an operational procedure that involves the process of combining two or more separate consists into a single train, possible anywhere on the network. This operation is typically planned in advance as part of the operational plan, whether short-term or long-term.{comment:246}
Train joining is an operational procedure that involves the process of combining two or more separate consists into a single train, possible anywhere on the network. This operation is typically planned in advance as part of the operational plan, whether short-term or long-term.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:TRAIN--OBJECT_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Train Object is the object needed by the ETPS to manage the connected trains. It stores the information needed by the ETPS about the connected train (e.g. Onboard ETCS identity, Validated train data, Safe Train Extent) {comment:84}{comment:85}", -- "Train Object is the object needed by the ETPS to manage the Communication with an ETCS Equipped train.{comment:84}{comment:85}" :diff_0245 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:TRAIN--OBJECT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Train Object is the object needed by the ETPS to manage the connected trains. It stores the information needed by the ETPS about the connected train (e.g. Onboard ETCS identity, Validated train data, Safe Train Extent) {comment:84}{comment:85}
Train Object is the object needed by the ETPS to manage the Communication with an ETCS Equipped train.{comment:84}{comment:85}
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:TRAIN--SPLITTING_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Train Splitting{comment:244} is an operational procedure that involves the process of separating a train into two or more consists, possible anywhere on the network and normally based on the operational plan as planned splitting. Specific procedures of the Railway Undertaking describe (vehicles specific, e.g., closing of flaps, protection covering against snow) details to perform the splitting. Unplanned splitting needs the communication with the signaller.{comment:245} {comment:231}", -- "Train Splitting is an operational procedure that involves the process of separating a train into two or more consists, possible anywhere on the network and normally based on the operational plan as planned splitting. Specific procedures of the Railway Undertaking describe (vehicles specific, e.g., closing of flaps, protection covering against snow) details to perform the splitting. Unplanned splitting needs the communication with the signaller." :diff_0246 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:TRAIN--SPLITTING_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Train Splitting{comment:244} is an operational procedure that involves the process of separating a train into two or more consists, possible anywhere on the network and normally based on the operational plan as planned splitting. Specific procedures of the Railway Undertaking describe (vehicles specific, e.g., closing of flaps, protection covering against snow) details to perform the splitting. Unplanned splitting needs the communication with the signaller.{comment:245} {comment:231}
Train Splitting is an operational procedure that involves the process of separating a train into two or more consists, possible anywhere on the network and normally based on the operational plan as planned splitting. Specific procedures of the Railway Undertaking describe (vehicles specific, e.g., closing of flaps, protection covering against snow) details to perform the splitting. Unplanned splitting needs the communication with the signaller.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:TRAIN_lexConcept_2 ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The train is an operational entity that provides informations{comment:217} to MDS such as cab is active, train in motion or at standstill. The train is involved in the following tasks: activate/deactivate the cab and configure displays on the cab.", -- "The train is an operational entity that provides informations to MDS such as cab is active, train in motion or at standstill. The train is involved in the following tasks: activate/deactivate the cab and configure displays on the cab." :diff_0247 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:TRAIN_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
The train is an operational entity that provides informations{comment:217} to MDS such as cab is active, train in motion or at standstill. The train is involved in the following tasks: activate/deactivate the cab and configure displays on the cab.
The train is an operational entity that provides informations to MDS such as cab is active, train in motion or at standstill. The train is involved in the following tasks: activate/deactivate the cab and configure displays on the cab.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:UNSUPERVISED--MOVEMENT_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The unsupervised movement is not under the supervision of the CCS system. So, there is no Movement Authority like OS or FS.{comment:250} During this type of movement the Signaller and Driver have the responsibility for ensuring the safety and control of the train in the absence of the supervision by the CCS system.", -- "The unsupervised movement is not under the supervision of the CCS system. So, there is no Movement Authority like OS or FS. During this type of movement the Signaller and Driver have the responsibility for ensuring the safety and control of the train in the absence of the supervision by the CCS system." :diff_0248 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:UNSUPERVISED--MOVEMENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The unsupervised movement is not under the supervision of the CCS system. So, there is no Movement Authority like OS or FS.{comment:250} During this type of movement the Signaller and Driver have the responsibility for ensuring the safety and control of the train in the absence of the supervision by the CCS system.
The unsupervised movement is not under the supervision of the CCS system. So, there is no Movement Authority like OS or FS. During this type of movement the Signaller and Driver have the responsibility for ensuring the safety and control of the train in the absence of the supervision by the CCS system.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-251201:VIEW_lexConcept ( was in lex_sp-defs-251007: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Aggregation of Areas{comment:228}{comment:52} required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time.", -- "Aggregation of Areas{comment:52} required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time." :diff_0249 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-251201:VIEW_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Aggregation of Areas{comment:228}{comment:52} required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time.
Aggregation of Areas{comment:52} required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time.