++ :CONTROL-COMMAND--AND--SIGNALLING_lexForm_3
++ :POLARION--WORK--ITEM--OF--TYPE--REFERENCE_lexForm_3
++ :COMMON--BUSINESS--OBJECTIVE_lexForm_3
++ :DIGITAL--AUTOMATED--COUPLING_lexForm_3
++ :SYSTEM--UNDER--CONSIDERATION_lexForm_3
-- <https://dbpedia.org/property/workItem>
-- <https://en.wikipedia.org/wiki/Work_breakdown_structure>
-- <https://polarion.plm.automation.siemens.com/>
++ :CONTROL-COMMAND--AND--SIGNALLING_lexConcept_2
++ :DIGITAL--AUTOMATED--COUPLING_lexConcept_2
-- :DOCUMENT--GENERATION--AND--MANAGEMENT_lexConcept_2
-- <https://dbpedia.org/page/Arcadia_(engineering)>
-- <https://en.wikipedia.org/wiki/Arcadia_(engineering)>
++ :MANAGEMENT--BY--TRACEABILITY--KANBAN--BASED_lexConcept_2
++ :MANAGEMENT--BY--TRACEABILITY--KANBAN--BASED_lexConcept_3
++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_7
++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_7
++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_7
++ :POLARION--WORK--ITEM--OF--TYPE--REFERENCE_lexConcept_2
++ :SYSTEM--UNDER--CONSIDERATION_lexConcept_2
++ :SYSTEM--UNDER--CONSIDERATION_lexConcept_3
++ :THE--SET--OF--ALL--TRACES--TOGETHER--IS--CALLED--A--_MODEL_lexConcept_2
++ "1 D reference frame is a one-dimensional reference frame where the bogie position, speed and acceleration along the track centreline axis are expressed. It is defined by the bogie frame. On the plan defined by the carriage floor, the x axis is the tangent of the track centreline oriented toward the train front end, the bogie pin close to the train front end is the tangency point. The bogie pin is located on the longitudinal axis of the carriage."
-- "1 D reference frame is a one-dimensional reference frame where the bogie position, speed and acceleration along the track centreline axis are expressed. It is defined by the bogie frame. On the plan defined by the carriage floor, the x axis is the tangent of the track centreline oriented toward the train front end, the bogie pin close to the train front end is the tangency point. The bogie pin is located on the longitudinal axis of the carriage."
++ "It is a three-dimensional reference frame where the train speed and acceleration are expressed on the 3 axis component values. It is defined by the carriage frame by a right trihedron. On the plan defined by the carriage floor, the x axis is the carriage longitudinal axis oriented toward the train front end, y axis is the orthogonal to the carriage longitudinal axis oriented to the left, z axis the orthogonal to the carriage floor oriented up, the origin point is the bogie pin close to the train front end."
-- "It is a three-dimensional reference frame where the train speed and acceleration are expressed on the 3 axis component values. It is defined by the carriage frame by a right trihedron. On the plan defined by the carriage floor, the x axis is the carriage longitudinal axis oriented toward the train front end, y axis is the orthogonal to the carriage longitudinal axis oriented to the left, z axis the orthogonal to the carriage floor oriented up, the origin point is the bogie pin close to the train front end."
++ "ETCS System Compatibility (ESC) is the recording of technical compatibility between ETCS on-board and the trackside parts ETCS of the CCS subsystems within an area of use. Each ESC Type identifies the set of ESC checks (e.g. document check, lab or track test, …) applicable for a section or group of sections within an area of use. It is possible to use the same ESC type for cross border infrastructure and for different national infrastructures. The results of the ESC checks for an on-board unit on the Interoperability Constituent level or subsystem level, including findings and conditions arising, are recorded in the ESC Check Report. ‘Representative configuration’ means a configuration on the basis of which test results can be achieved, which are valid for various configurations of the same certified ETCS on-board interoperability constituent or of a certified on-board subsystem. These results shall also be equivalent for various configurations of a certified ETCS trackside subsystem. For ESC checks at ETCS on-board Interoperability Constituent level the following is to be observed: (1) The ESC Interoperability Constituent Statement records the ESC results of the ETCS On-board Interoperability Constituent to the ESC Type(s) that is valid regardless of the specific configuration of the ETCS on-board Interoperability Constituent. This document shall be produced by the on-board supplier. The template provided in Appendix C.2 or C.6 shall be used. (2) The ESC Interoperability Constituent Statement shall include the summary of the findings and conditions of the ESC Check Report(s) on the results of the ESC checks passed (defined in one or more ESC Type), which are valid independently from the specific configuration parameters of the on-board Interoperability Constituent and can therefore be used in every applicable specific on-board CCS subsystem level. (3) The ESC Interoperability Constituent Statement shall include the list of ESC checks performed for the ESC Type(s). (4) The ESC Interoperability Constituent Statement shall include the reference to the NoBo assessment Report according to 6.2.4.3 (ETCS and radio system compatibility checks for Interoperability Constituent). The ESC of the specific on-board CCS subsystem with respect to one or more ESC Type(s) is laid down in the ESC Statement. The template provided in Appendix C.1 or C.5 shall be used. At subsystem level, the ESC Statement shall also include the summary of the ESC Check Report and shall demonstrate the fulfilment of the required ESC checks (for each ESC Type included in the Statement) published in the Agency ESC/RSC technical document in addition to already provided ESC interoperability constituent statements. The ESC Statement shall also include the full list of ESC Interoperability Constituent statements taken into account in the assessment (if any), the conditions (if any) with respect to the different ESC Types and the NoBo Assessment Report according to 6.3.3.1 (ETCS and radio system compatibility checks)."
-- "ETCS System Compatibility (ESC) is the recording of technical compatibility between ETCS on-board and the trackside parts ETCS of the CCS subsystems within an area of use. Each ESC Type identifies the set of ESC checks (e.g. document check, lab or track test, …) applicable for a section or group of sections within an area of use. It is possible to use the same ESC type for cross border infrastructure and for different national infrastructures. The results of the ESC checks for an on-board unit on the Interoperability Constituent level or subsystem level, including findings and conditions arising, are recorded in the ESC Check Report. ‘Representative configuration’ means a configuration on the basis of which test results can be achieved, which are valid for various configurations of the same certified ETCS on-board interoperability constituent or of a certified on-board subsystem. These results shall also be equivalent for various configurations of a certified ETCS trackside subsystem. For ESC checks at ETCS on-board Interoperability Constituent level the following is to be observed: (1) The ESC Interoperability Constituent Statement records the ESC results of the ETCS On-board Interoperability Constituent to the ESC Type(s) that is valid regardless of the specific configuration of the ETCS on-board Interoperability Constituent. This document shall be produced by the on-board supplier. The template provided in Appendix C.2 or C.6 shall be used. (2) The ESC Interoperability Constituent Statement shall include the summary of the findings and conditions of the ESC Check Report(s) on the results of the ESC checks passed (defined in one or more ESC Type), which are valid independently from the specific configuration parameters of the on-board Interoperability Constituent and can therefore be used in every applicable specific on-board CCS subsystem level. (3) The ESC Interoperability Constituent Statement shall include the list of ESC checks performed for the ESC Type(s). (4) The ESC Interoperability Constituent Statement shall include the reference to the NoBo assessment Report according to 6.2.4.3 (ETCS and radio system compatibility checks for Interoperability Constituent). The ESC of the specific on-board CCS subsystem with respect to one or more ESC Type(s) is laid down in the ESC Statement. The template provided in Appendix C.1 or C.5 shall be used. At subsystem level, the ESC Statement shall also include the summary of the ESC Check Report and shall demonstrate the fulfilment of the required ESC checks (for each ESC Type included in the Statement) published in the Agency ESC/RSC technical document in addition to already provided ESC interoperability constituent statements. The ESC Statement shall also include the full list of ESC Interoperability Constituent statements taken into account in the assessment (if any), the conditions (if any) with respect to the different ESC Types and the NoBo Assessment Report according to 6.3.3.1 (ETCS and radio system compatibility checks)."
++ "Train front end position expressed with absolute geo coordinate system using a 3 D reference frame (e.g., Long, Lat, Alt, WGS84, ETRS89…)."
-- "Train front end position expressed with absolute geo coordinate system using a 3 D reference frame (e.g., Long, Lat, Alt, WGS84, ETRS89…)."
++ "Advanced Safe Train Positioning (ASTP) is a CCS onboard interoperability constituent, separated from the ERTMS/ETCS on-board equipment by fully standardized interfaces with all connected systems. ASTP shall perform functions for safety relevant applications and be the only source of odometry information in the CCS-OB. The main ASTP functionalities interfacing with other onboard systems, are: * provision of Odometry information * identification of all potential virtual Reference Location(s) * provision of 3D kinematic information"
-- "Advanced Safe Train Positioning (ASTP) is a CCS onboard interoperability constituent, separated from the ERTMS/ETCS on-board equipment by fully standardized interfaces with all connected systems. ASTP shall perform functions for safety relevant applications and be the only source of odometry information in the CCS-OB. The main ASTP functionalities interfacing with other onboard systems, are: * provision of Odometry information * identification of all potential virtual Reference Location(s) * provision of 3D kinematic information"
++ "The area in the trackside which shall be free of operational conflict(s) for the execution of an operational need (movement or other). In other words, it is the area in the trackside that shall be reserved to an operational movement. The safety system shall not allow an SPT2OD-6043 - Missing cross-reference to be allocated to conflicting movement(s) or conflicting operational need(s). (image: diagram_20231213-1048.28106.mxg.svg) {comment:64} Note as a representation, SPT2OD-6043 - Missing cross-reference is equivalent to the combined Danger Zone(s) of the underlying assets over the area in which it is intended to next perform a train movement, possibly including flank protection and overlap areas (to be discussed at a later stage)."
-- "The area in the trackside which shall be free of operational conflict(s) for the execution of an operational need (movement or other). In other words, it is the area in the trackside that shall be reserved to an operational movement. The safety system shall not allow an SPT2OD-6043 - Missing cross-reference to be allocated to conflicting movement(s) or conflicting operational need(s). (image: diagram_20231213-1048.28106.mxg.svg) {comment:64} Note as a representation, SPT2OD-6043 - Missing cross-reference is equivalent to the combined Danger Zone(s) of the underlying assets over the area in which it is intended to next perform a train movement, possibly including flank protection and overlap areas (to be discussed at a later stage)."
++ "The Application Execution Environment refers to the combination of Runtime Environment and Safety Framework. Previous definition: The Application Execution Environment refers to the combination of Runtime Environment and Safety Environment."
-- "The Application Execution Environment refers to the combination of Runtime Environment and Safety Framework. Previous definition: The Application Execution Environment refers to the combination of Runtime Environment and Safety Environment."
++ "The Application Layer refers to the functions provided by the Functional Systems. These functions are implemented as Tasks within Functional Applications. Previous definition: The Application Layer contains Functional Applications that constitute Functional Systems."
-- "The Application Layer refers to the functions provided by the Functional Systems. These functions are implemented as Tasks within Functional Applications. Previous definition: The Application Layer contains Functional Applications that constitute Functional Systems."
++ "An application in SP context is the resulting situation of a system beeing used in a specific environment by specific actors. In short - Application = System + Processes + Actors + Environment."
-- "An application in SP context is the resulting situation of a system beeing used in a specific environment by specific actors. In short - Application = System + Processes + Actors + Environment."
++ "The architectural process comprises four steps, each dealing with a separate concern. The general concept implements the architecture recommendations from the System Pillar report [SPREP, page 11]{comment:6} for a function-based architecture and a layered architecture approach. Both concepts can be realised with the architectural principles described herein.These steps are described in detail in the following chapters. * Operational analysis (OA): identify the operational process needs that are to be supported by systems or organisations. This analysis should focus as purely as possible on the processes and ideally does not take any specific technical system architecture into account. The operational analysis is usually performed on an abstraction layer above the topmost system in the systems of systems hierarchy and performed only once. * System analysis (SA): identify the needs of the system of interest. This step does not design a specific technical solution but captures the needs for the future system. It hence represents a statement of work and not a finished piece of engineering. It is used to rationalize the decision, which operational processes will be performed by the system of interest, and which will be not (these processes then mostly will be either performed by other systems or by human actors and defined as operating rules). System analysis is performed recursively: * Once for the topmost system of systems, deriving the initial need from the operational analysis * Multiple times for each system of system decomposition step, deriving the system needs of the lower level of decomposition from the higher level of decomposition * Logical architecture (LA): design a solution to the system needs based on solution concepts and architectural concepts. Split the system functions based on solution concepts (e.g. absolute positioning vs reference point based localisation, moving blocks, fixed blocks or hybrid) so that it becomes clear, how and by which steps the inputs to a system function are converted to the outputs. This step does not yet define an architecture and does not refer to technical solution concepts like ETCS or ATO. As the system under consideration is still a blackbox, the logical architecture still leaves the question open, what subsystem structure is the to be used (e.g. very modular subsystems vs. bigger subsystems or combined HW/SW subsystems vs. SW-modules on a common platform). This step is performed once, before the subsystem architecture shall be derived. * Physical architecture (PA): design the final set of tenderable subsystems and integrate all necessary non-functional requirements. This step integrates all considerations on the intended structure of subsystems and interfaces (down to FFFIS) as well as all open technical aspects into a consistent architectural definition."
-- "The architectural process comprises four steps, each dealing with a separate concern. The general concept implements the architecture recommendations from the System Pillar report [SPREP, page 11] for a function-based architecture and a layered architecture approach. Both concepts can be realised with the architectural principles described herein.These steps are described in detail in the following chapters. * Operational analysis (OA): identify the operational process needs that are to be supported by {comment:7} systems or organisations.{comment:4} This analysis should focus as purely as possible on the processes and ideally does not take any specific technical system architecture into account. The operational analysis is usually performed on an abstraction layer above the topmost system in the systems of systems hierarchy and performed only once. * System analysis (SA): identify the needs of the system of interest. This step does not design a specific technical solution but captures the needs for the future system. It hence represents a statement of work and not a finished piece of engineering. It is used to rationalize the decision, which operational processes will be performed by the system of interest, and which will be not (these processes then mostly will be either performed by other systems or by human actors and defined as operating rules). System analysis is performed recursively: * Once for the topmost system of systems, deriving the initial need from the operational analysis * Multiple times for each system of system decomposition step, deriving the system needs of the lower level of decomposition from the higher level of decomposition * Logical architecture (LA): design a solution to the system needs based on solution concepts and architectural concepts. Split the system functions based on solution concepts (e.g. absolute positioning vs reference point based localisation, moving blocks, fixed blocks or hybrid) so that it becomes clear, how and by which steps the inputs to a system function are converted to the outputs. This step does not yet define an architecture and does not refer to technical solution concepts like ETCS or ATO. As the system under consideration is still a blackbox, the logical architecture still leaves the question open, what subsystem structure is the to be used (e.g. very modular subsystems vs. bigger subsystems or combined HW/SW subsystems vs. SW-modules on a common platform). This step is performed once, before the subsystem architecture shall be derived. * Subsystem architecture (SSA): design the final set of tenderable subsystems and integrate all necessary non-functional requirements. This step integrates all considerations on the intended structure of subsystems and interfaces (down to FFFIS) as well as all open technical aspects into a consistent architectural definition.{comment:3}"
++ "Area Controller The Area Controller manages areas for the View."
-- "Area Controller The Area Controller manages areas for the View."
++ "ATO | Automatic Train Operation AoC | Area of Control | CCS | Control Command and Signaling CI/CD | Continuous Integration / Continuous Deployment CMS | Capacity Management system CPU | Central Processing Unit CTC | Centralized traffic control CVSS | Common Vulnerability Scoring System | DBMS | Database Management System DDOS | Distributed Denial of Service DEV | Development DLP | Data loss prevention DNS | Domain Name System DR | Disaster Recovery-Plan | EDA | Event-driven architecture ELK | Elasticsearch, Logstash, Kibana | FAM | Fixed asset mgmt | HMI | Human Machine Interface HTTP | Hypertext Transfer Protocol | IRM | Information Rights Management | OS | Operating system OR | Operational Requirements | NTMS | Neighborhood TMS | MD5 | Message Digest Method 5 MITM | Man-in-the-middle attack MS | Microservices MVCC | Multi-version concurrency control | PE | Plan Execution PIS | Passenger Information System POS | Path Order System PROD | Production | QA | Quality Assurance{comment:128} | RAID | Redundant Array of Independent Disks RAM | Random Access Memory RBAS | Role Based Access Control REST | Representational State Transfer RIM | Rail Infrastructure Manager ROC | Rail Operating Company RT | Real Time RU | Rail Undertakings | SAD | System Architecture Description SCI-OP | Standard Communications Interface – Operational Plan SEMP | System Engineering Management Plan SOAP | Simple Object Access Protocol SoC | Separation of Concerns SSL | Secure Sockets Layer | TAF | Telematics Applications for Freight TAP | Telematics Applications for Passenger Services TCR | Temporary Capacity Restrictions TLS | Transport Layer Security TMS | Traffic Management System TSI | Technical Specification for Interoperability | UML | Unified Modeling Language | WAF | Web Application Firewall WSDL | Web Services Description Language | XFN | Cross functional"
-- "ATO | Automatic Train Operation AoC | Area of Control | CCS | Control Command and Signaling CI/CD | Continuous Integration / Continuous Deployment CMS | Capacity Management system CPU | Central Processing Unit CTC | Centralized traffic control CVSS | Common Vulnerability Scoring System | DBMS | Database Management System DDOS | Distributed Denial of Service DEV | Development DLP | Data loss prevention DNS | Domain Name System DR | Disaster Recovery-Plan | EDA | Event-driven architecture ELK | Elasticsearch, Logstash, Kibana | FAM | Fixed asset mgmt | HMI | Human Machine Interface HTTP | Hypertext Transfer Protocol | IRM | Information Rights Management | OS | Operating system OR | Operational Requirements | NTMS | Neighborhood TMS | MD5 | Message Digest Method 5 MITM | Man-in-the-middle attack MS | Microservices MVCC | Multi-version concurrency control | PE | Plan Execution PIS | Passenger Information System POS | Path Order System PROD | Production | QA | Quality Assurance{comment:128} | RAID | Redundant Array of Independent Disks RAM | Random Access Memory RBAS | Role Based Access Control REST | Representational State Transfer RIM | Rail Infrastructure Manager ROC | Rail Operating Company RT | Real Time RU | Rail Undertakings | SAD | System Architecture Description SCI-OP | Standard Communications Interface – Operational Plan SEMP | System Engineering Management Plan SOAP | Simple Object Access Protocol SoC | Separation of Concerns SSL | Secure Sockets Layer | TAF | Telematics Applications for Freight TAP | Telematics Applications for Passenger Services TCR | Temporary Capacity Restrictions TLS | Transport Layer Security TMS | Traffic Management System TSI | Technical Specification for Interoperability | UML | Unified Modeling Language | WAF | Web Application Firewall WSDL | Web Services Description Language | XFN | Cross functional"
++ "The process to verify the identity of communicating peers. (source: SPPRAMSS-1705 - [UNISIG Subset-146] )"
-- "The process to verify the identity of communicating peers. (source: SPPRAMSS-1705 - [UNISIG Subset-146] )"
++ "Automatic Train Operation is technology for automating the operation of trains. The degree of the automatisation is shown by the Grade of Automatation (GoA). GoA0: train operating on-sight, no automation GoA1: train operating manual, train driver controls starting, stopping, passenger service functions as opening and closing doors and handling emergency. Train protection systems like ETCS L1 in place. GoA2: train operating semi-automatic. Starting and stopping automated using advanced train protection systems like ETCS L2 or 3, driver operates passenger service functions and handles emergencies GoA3: driverless train operation. Starting and stopping automated, service staff operates passenger service functions and handles emergencies GoA4: unattended train operation. All operations are fully automated without any on-train staff"
-- "Automatic Train Operation is technology for automating the operation of trains. The degree of the automatisation is shown by the Grade of Automatation (GoA). GoA0: train operating on-sight, no automation GoA1: train operating manual, train driver controls starting, stopping, passenger service functions as opening and closing doors and handling emergency. Train protection systems like ETCS L1 in place. GoA2: train operating semi-automatic. Starting and stopping automated using advanced train protection systems like ETCS L2 or 3, driver operates passenger service functions and handles emergencies GoA3: driverless train operation. Starting and stopping automated, service staff operates passenger service functions and handles emergencies GoA4: unattended train operation. All operations are fully automated without any on-train staff"
++ "Ability of an item to be in a state to perform a required function under given conditions at a given instant of time or over a given time interval, assuming that the required external resources are provided [SOURCE: IEC 60050-821: FDIS2016, 821-05-82, modified] Source: SPPRAMSS-349 - [EN 50126-1:2017]"
-- "Ability of an item to be in a state to perform a required function under given conditions at a given instant of time or over a given time interval, assuming that the required external resources are provided [SOURCE: IEC 60050-821: FDIS2016, 821-05-82, modified] Source: SPPRAMSS-349 - [EN 50126-1:2017]"
++ "Availability: property of being accessible and usable on demand by an authorized entity (source: ISO 27000-2018 )"
-- "Availability: property of being accessible and usable on demand by an authorized entity (source: ISO 27000-2018 )"
++ "Baseline{comment:46} Sets of specifications or work products at specific points in time that have been formally reviewed and agreed on. Notes: - Pay attention that, in the context of System Pillar (and use of Polarion), several kinds of baselines exist: Polarion Document Baseline, Polarion Project Baseline, Polarion Collection Baseline and System Pillar Baseline (treated in the Configuration Management Plan ){comment:218} - This definition is a general definition. Another definition exists in glossary imported from the Subset-23. : SPLI-772 - BASELINE"
-- "Baseline{comment:46} Sets of specifications or work products at specific points in time that have been formally reviewed and agreed on. Notes: - Pay attention that, in the context of System Pillar (and use of Polarion), several kinds of baselines exist: Polarion Document Baseline, Polarion Project Baseline, Polarion Collection Baseline and System Pillar Baseline (treated in the Configuration Management Plan ) - This definition is a general definition. Another definition exists in glossary imported from the Subset-23. : SPLI-772 - BASELINE"
++ "Biometric Reader Device that reads the identity of a person by comparing some attribute of their physiological being or behavioral traits against a sample database. This reader permits the authentication of the actor."
-- "Biometric Reader Device that reads the identity of a person by comparing some attribute of their physiological being or behavioral traits against a sample database. This reader permits the authentication of the actor."
++ "A BuildingBlock is a logical unit of the system that is bound to a sourceable physical equipment by means of a Basic Data Identifier having: * standardised functionality or aggregates standard functionality it depends on * may have standardised PRAMS requirements (including Tolerable Functional Failure Rate [TFFR] * may have Safety Integrity Levels [SIL] for functions within the system border and Safety Related Application Conditions [SRAC]) * standardised cyber security requirements (including Security Level [SL] based on the security requirements, and Security Related Application Conditions [SRAC]) * may have (on lower levels) standardised interfaces (on all OSI Layers) towards other Building Blocks and/or external systems. One equipment can host several BuildingBlocks (e.g in the case of a MultiObjectController) and may be separately sourceable from different suppliers and capable of being integrated by a third party (integrator). A BuildingBlock is configured by one or more BuildingBlockConfigurations. A BuildingBlock must have an unique identifier called bbId (that could be a technical system or subsystem identifier). The bbIds are assigned by the integrator and are transferred to another physical unit in case of replacement. Each bbId must be unique."
-- "A Building Block is an equipment based (hardware and/or software) or logical unit of the System having: * standardised functionality or aggregates standard functionality it depends on * may have standardised PRAMS requirements (including Tolerable Functional Failure Rate [TFFR] * may have Safety Integrity Levels [SIL] for functions within the system border and Safety Related Application Conditions [SRAC]) * standardised cyber security requirements (including Security Level [SL] based on the security requirements, and Security Related Application Conditions [SRAC]) * may have (on lower levels) standardised interfaces (on all OSI Layers) towards other Building Blocks and/or external systems. Equipment based Building Blocks are separately sourceable from different suppliers and capable of being integrated by a third party (integrator). A BuildingBlock has one or more BuildingBlockConfigurations. A BuildingBlock must have a unique identifier composed of configurationGroupId and configurationId."
++ "Button A Hard Key allocated to a dedicated system on a cab. It's designed with a dedicated SIL level. It allows a selection from two states and keeps one state as long as it is pressed."
-- "Button A Hard Key allocated to a dedicated system on a cab. It's designed with a dedicated SIL level. It allows a selection from two states and keeps one state as long as it is pressed."
++ "It is represented by a point on the carriage floor along the longitudinal axis. This point is the most forward element belonging to the carriage. Its absolute position is expressed in a geocoordinate reference frame. It is used in the case the ASTP is not installed in the first vehicle."
-- "It is represented by a point on the carriage floor along the longitudinal axis. This point is the most forward element belonging to the carriage. Its absolute position is expressed in a geocoordinate reference frame. It is used in the case the ASTP is not installed in the first vehicle."
++ "condition-based maintenance preventive maintenance based on the assessment of physical condition Note 1 to entry: The condition assessment may be by operator observation, conducted according to a schedule, or by condition monitoring (192-06-28 SPPRAMSS-4462 - condition monitoring, <of an item> ) of system parameters. [SOURCE: IEC 60050-192:2015, 192-06-07]"
-- "condition-based maintenance preventive maintenance based on the assessment of physical condition Note 1 to entry: The condition assessment may be by operator observation, conducted according to a schedule, or by condition monitoring (192-06-28 SPPRAMSS-4462 - condition monitoring, <of an item> ) of system parameters. [SOURCE: IEC 60050-192:2015, 192-06-07]"
++ "CCS Deployment refers to one physical deployment of a CCS System, that is uniquely identifiable with bbId, bbcId and bbcVersion. A CCS Deployment consists of the CCS hardware running the BBCs that are defined in a Top-Level BuildingBlockConfiguration (BBC) and its dependencies."
-- "CCS Deployment refers to one physical deployment of a CCS System, that is uniquely identifiable with configurationGroupId, configurationId and configurationVersion. A CCS Deployment consists of the CCS hardware running the BBCs that are defined in a Top-Level BuildingBlockConfiguration (BBC) and its dependencies."
++ "The CCS/TMS Data Model{comment:91} defines the harmonised language to generate and transport the Domain Data at System Pillar interfaces. The Transversal CCS Subdomain 1 (SD1) is responsible for the specification of the CCS/TMS Data Model in collaboration with * the System Pillar domains which apply the defined data structures in interface specifications * the Innovation Pillar which proves the applicability of the data model by demonstrators."
-- "The CCS/TMS Data Model{comment:91} defines the harmonised language to generate and transport the Domain Data at System Pillar interfaces. The Transversal CCS Subdomain 1 (SD1) is responsible for the specification of the CCS/TMS Data Model in collaboration with * the System Pillar domains which apply the defined data structures in interface specifications * the Innovation Pillar which proves the applicability of the data model by demonstrators."
++ "CI = Central Instance ECM 1 and vehicle keeper are registered in EVR () FDFTO TCG = Technical Coordination Group{comment:7}"
-- "CI = Central Instance ECM 1 and vehicle keeper are registered in EVR () FDFTO TCG = Technical Coordination Group{comment:7}"
++ "Clean code has an important implication of the project’s success as clean code is more efficient and reduces potential bugs. The following code guidelines should be followed: * Readability: Readable code is easy to follow and optimizes space and time * Conventions: Follow conventions will structure the code in a better way and reduces unnecessary lines of code - less code is less complexity. * Indentation: Proper indentation is very important to increase the readability. * Design Principles: Resolves common problems in a very structured way. * Documentation: The code should be properly commented for understanding easily. Especially for microservices, the following guidelines should be followed: * Software components should be built as independent stateless services. * All business logic in a service should be encapsulated with the data upon which it acts. * There should be no direct access to a database from outside a service. Any and all access to a database should be accomplished by invoking a service specifically implemented to do so. * Each service should publish an interface that enables access to its data and functionality by other services. Furthermore, the system follows the 12-factor-app methodology: * Codebase: One codebase tracked in revision control; many deploys. * Dependencies: Explicitly declare and isolate dependencies. * Config: Store config in the environment. * Backing services: Treat backing services as attached resources. * Build, release, run: Strictly separate build and run stages. * Processes: Execute the app as one or more stateless processes. * Port binding: Export services via port binding. * Concurrency: Scale out via the process model. * Disposability: Maximize robustness with fast startup and graceful shutdown. * Dev/prod parity: Keep development, staging, and production as similar as possible. * Logs: Treat logs as event streams. * Admin processes: Run admin/management tasks as one-off processes."
-- "Clean code has an important implication of the project’s success as clean code is more efficient and reduces potential bugs. The following code guidelines should be followed: * Readability: Readable code is easy to follow and optimizes space and time * Conventions: Follow conventions will structure the code in a better way and reduces unnecessary lines of code - less code is less complexity. * Indentation: Proper indentation is very important to increase the readability. * Design Principles: Resolves common problems in a very structured way. * Documentation: The code should be properly commented for understanding easily. Especially for microservices, the following guidelines should be followed: * Software components should be built as independent stateless services. * All business logic in a service should be encapsulated with the data upon which it acts. * There should be no direct access to a database from outside a service. Any and all access to a database should be accomplished by invoking a service specifically implemented to do so. * Each service should publish an interface that enables access to its data and functionality by other services. Furthermore, the system follows the 12-factor-app methodology: * Codebase: One codebase tracked in revision control; many deploys. * Dependencies: Explicitly declare and isolate dependencies. * Config: Store config in the environment. * Backing services: Treat backing services as attached resources. * Build, release, run: Strictly separate build and run stages. * Processes: Execute the app as one or more stateless processes. * Port binding: Export services via port binding. * Concurrency: Scale out via the process model. * Disposability: Maximize robustness with fast startup and graceful shutdown. * Dev/prod parity: Keep development, staging, and production as similar as possible. * Logs: Treat logs as event streams. * Admin processes: Run admin/management tasks as one-off processes."
++ "A generic target or high level objective defining the mandate of the System Pillar. They are derived by tasks and domains and are not created by them. They can be formulated freely."
-- "Generic target of the System Pillar."
++ "* Title: The name of the work item * Description/design: The description of the work item = the design. The description is work item type specific (e.g., a class description for an exchange object). * Type: One of the types in the next chapter, like “operational problem analysis”, “operational requirement”, “System Function” or “logical component” * State: Work items and link types have a sequence of states, they runs through while a trace is worked out. The minimal set of states is * Suspect: Because of trace changes potentially not any more valid (to be checked) * Configuration: (Multiple choice list) Every work item is part of one or more “configurations”. Configurations can be releases, or certain versions of an architecture (for scalability or migration) * Assignment: Every work item shall be assigned to a person or team. It is the role of a functional team to assign unassigned work items when the author is not sure where to assign. The “unassigned” work items are forming the work que for a functional team. * Priority * Due date/finished on * System Level: Every work item has one of the following System levels: “1/2”, “3”, “4”, “5”. The levels are needed to make the right team assignment choices. Example for some requirements: * Requirement “The ATO GoA 4 operational capability shall allow to move trains without driver” – this requirement has System Level 1/2 because CCS, TMS and DAC are involved. Therefore, the modelling service needs to break it down it. * “The ATP operational capability shall allow safe train ahead distances that are shorter than the breaking distance of the following train” – this requirement has System Level 3 because several elements of CCS are involved. * “The maintenance process of an object controller shall be possible via remote operations as far as economically viable” – this requirement has system level 4, the Trackside Asset CS domain will resolve it. * Rationale: The reason for the design (description) * Comments: All historical work/review comments to a work item incl. Answer/reaction * Approvers: Experts that are asked to confirm / object to the correctness of a work item"
-- "* Title: The name of the work item * Description/design: The description of the work item = the design. The description is work item type specific (e.g., a class description for an exchange object). * Type: One of the types in the next chapter, like “operational problem analysis”, “operational requirement”, “System Function” or “logical component” * State: Work items and link types have a sequence of states, they runs through while a trace is worked out. The minimal set of states is * Suspect: Because of trace changes potentially not any more valid (to be checked) * Configuration: (Multiple choice list) Every work item is part of one or more “configurations”. Configurations can be releases, or certain versions of an architecture (for scalability or migration) * Assignment: Every work item shall be assigned to a person or team. It is the role of a functional team to assign unassigned work items when the author is not sure where to assign. The “unassigned” work items are forming the work que for a functional team. * Priority * Due date/finished on * System Level: Every work item has one of the following System levels: “1/2”, “3”, “4”, “5”. The levels are needed to make the right team assignment choices. Example for some requirements: * Requirement “The ATO GoA 4 operational capability shall allow to move trains without driver” – this requirement has System Level 1/2 because CCS, TMS and DAC are involved. Therefore, the modelling service needs to break it down it. * “The ATP operational capability shall allow safe train ahead distances that are shorter than the breaking distance of the following train” – this requirement has System Level 3 because several elements of CCS are involved. * “The maintenance process of an object controller shall be possible via remote operations as far as economically viable” – this requirement has system level 4, the Trackside Asset CS domain will resolve it. * Rationale: The reason for the design (description) * Comments: All historical work/review comments to a work item incl. Answer/reaction * Approvers: Experts that are asked to confirm / object to the correctness of a work item"
++ "A Compartment is a consistent, integrated entity comprising exactly one Runtime Environment Instance, at most one Safety Environment Replica, and Task Replicas of its respective Functional Applications. It can be deployed on either a Physical or a Virtual Computing Element. Previous definition: A Compartment is a consistent, integrated entity comprising exactly one Runtime Environment Instance, Safety Environment Task Replicas of at most one Safety Environment, and Functional Application Task Replicas of its respective Functional Applications. It can be deployed on either a Physical or a Virtual Computing Element."
-- "A Compartment is a consistent, integrated entity comprising exactly one Runtime Environment Instance, at most one Safety Environment Replica, and Task Replicas of its respective Functional Applications. It can be deployed on either a Physical or a Virtual Computing Element. Previous definition: A Compartment is a consistent, integrated entity comprising exactly one Runtime Environment Instance, Safety Environment Task Replicas of at most one Safety Environment, and Functional Application Task Replicas of its respective Functional Applications. It can be deployed on either a Physical or a Virtual Computing Element."
++ "A content for sketching concepts regarding analysis purposes which is linked to requirements."
++ "Container of concepts, typically class model illustrating a lexical definition, incl. relationships between concepts. May also be imported or authored by the project. Conceptual glossaries are referred to by lexcial glossaries."
-- "Container of concepts, typically class model illustrating a lexical definition, incl. relationships between concepts. May also be imported or authored by the project. Conceptual glossaries are referred to by lexcial glossaries."
++ "obtaining information about physical state or operational parameters Note 1 to entry: Condition monitoring is used to determine when preventive maintenance may be required. Note 2 to entry: Condition monitoring may be conducted automatically during operation or at planned intervals. Note 3 to entry: Condition monitoring methods include: vibration analysis, tribology and thermography. [SOURCE: IEC 60050-192:2015, 192-06-28]"
-- "obtaining information about physical state or operational parameters Note 1 to entry: Condition monitoring is used to determine when preventive maintenance may be required. Note 2 to entry: Condition monitoring may be conducted automatically during operation or at planned intervals. Note 3 to entry: Condition monitoring methods include: vibration analysis, tribology and thermography. [SOURCE: IEC 60050-192:2015, 192-06-28]"
++ "The position, speed, acceleration interval within which the ASTP assumes the true train position, speed, acceleration is, with a defined probability."
-- "The position, speed, acceleration interval within which the ASTP assumes the true train position, speed, acceleration is, with a defined probability."
++ "Property that information is not made available or disclosed to unauthorized individuals, entities, or processes (source: ISO 27000-2018 )"
-- "Confidentiality: property that information is not made available or disclosed to unauthorized individuals, entities, or processes (source: ISO 27000-2018 )"
++ "A configuration item refers to any resource within a system that needs to be managed and controlled in order to support the delivery of products or services. It can be an unchangeable item such as a software (provided by the originator it remains unchanged until installation), or it can be a changeable item such as a parametrisation file (provided by the originator it may be changed by a third party before installation). Configuration items are typically identified, documented, and tracked throughout their lifecycle to ensure proper control, maintenance, and change management. They are often part of a configuration management system or database, which helps in organizing and managing the configuration items and their relationships. The purpose of managing configuration items is to have a clear understanding of the resources that make up a system, their interdependencies, and their characteristics. This enables effective control, planning, and decision-making, particularly in areas such as asset management, change management, and problem resolution."
-- "A configuration item refers to any resource within a system that needs to be managed and controlled in order to support the delivery of products or services. It can be an unchangeable item such as a software (provided by the originator it remains unchanged until installation), or it can be a changeable item such as a parametrisation file (provided by the originator it may be changed by a third party before installation). Configuration items are typically identified, documented, and tracked throughout their lifecycle to ensure proper control, maintenance, and change management. They are often part of a configuration management system or database, which helps in organizing and managing the configuration items and their relationships. The purpose of managing configuration items is to have a clear understanding of the resources that make up a system, their interdependencies, and their characteristics. This enables effective control, planning, and decision-making, particularly in areas such as asset management, change management, and problem resolution."
++ "A SPPR-5436 - Lexical Glossary is called consolidated if all contained items are not contradictory nor ambiguous toward other glossaries of System Pillar. All possible ambiguities are resolved by means of context information added to the definitions. A consolidated glossary provides a safe basis for the context underlying its namespace. This supports efficient communication in expert groups. See SPPR-5313 - Consolidate the glossary items."
-- "A SPPR-5436 - Lexical Glossary is called consolidated if all contained items are not contradictory nor ambiguous toward other glossaries of System Pillar. All possible ambiguities are resolved by means of context information added to the definitions. A consolidated glossary provides a safe basis for the context underlying its namespace. This supports efficient communication in expert groups. See SPPR-5313 - Consolidate the glossary items."
++ "Controller Unit The Controller Unit is a hardware component which embeds logical controller(s). There may be only one Hardware or distributed to several HMI elements."
-- "Controller Unit The Controller Unit is a hardware component which embeds logical controller(s). There may be only one Hardware or distributed to several HMI elements."
++ "Maintenance carried out after fault detection to effect restoration Note 1 to entry: Corrective maintenance of software invariably involves some modification. [SOURCE: IEC 60050-192:2015, 192-06-06]"
-- "Maintenance carried out after fault detection to effect restoration Note 1 to entry: Corrective maintenance of software invariably involves some modification. [SOURCE: IEC 60050-192:2015, 192-06-06]"
++ "Status{comment:1393} achieved by a product that has been accepted by one authority to the relevant standards and is acceptable to other authorities without the necessity for further assessment, see [IEC 60050-821:2017,{comment:1335} 821-12-15]."
-- "Status{comment:1393} achieved by a product that has been accepted by one authority to the relevant standards and is acceptable to other authorities without the necessity for further assessment, see [IEC 60050-821:2017,{comment:1335} 821-12-15]."
++ "Common Safety Methods for assessing the safety level and the safety performance of railway operators [SOURCE: RECOMMENDATION ERA1219 OF THE EUROPEAN UNION AGENCY FOR RAILWAYS]"
-- "Common Safety Methods for assessing the safety level and the safety performance of railway operators [SOURCE: RECOMMENDATION ERA1219 OF THE EUROPEAN UNION AGENCY FOR RAILWAYS]"
++ "The area in the trackside in which the track path shall be uninterrupted and unobstructed at the time a train runs over it.{comment:101} (image: diagram_20231212-1333.02592.mxg.svg) Note as a representation, it has the dimensions of the trackside asset (within its boundaries)."
-- "The area in the trackside in which the track path shall be uninterrupted and unobstructed at the time a train runs over it.{comment:101} (image: diagram_20231212-1333.02592.mxg.svg) Note as a representation, it has the dimensions of the trackside asset (within its boundaries)."
++ "Note: informelle Gruppierung im Modell (analog zur RCA tiers), für Kommunikation/Verständnis A data model layer offers a view of the information as needed by, and as limited by a functional domain such as topology, geometry, signalling, gauge, etc."
-- "Note: informelle Gruppierung im Modell (analog zur RCA tiers), für Kommunikation/Verständnis A data model layer offers a view of the information as needed by, and as limited by a functional domain such as topology, geometry, signalling, gauge, etc."
++ "Desk Display Area A Zone displaying a piece of visual information of particular system and defined by a size (in cells) and an absolute position (x ,y, z axes). It is more commonly named Area in this specification."
-- "Desk Display Area A Zone displaying a piece of visual information of particular system and defined by a size (in cells) and an absolute position (x ,y, z axes). It is more commonly named Area in this specification."
++ "Desk Inside a cab, the set of operating controls*, which is dedicated to preferred movements in a given direction (i.e. forward movements, in which visibility from the cab is provided to the driver). Exception: some single cab locomotives are fitted with one single desk, allowing normal movements in both directions. *set of operating controls: screens, buttons, traction/brake lever, direction controller, radio control, switches, …Desk"
-- "Desk Inside a cab, the set of operating controls*, which is dedicated to preferred movements in a given direction (i.e. forward movements, in which visibility from the cab is provided to the driver). Exception: some single cab locomotives are fitted with one single desk, allowing normal movements in both directions. *set of operating controls: screens, buttons, traction/brake lever, direction controller, radio control, switches, …Desk"
++ "Device{comment:36} A physical entity performing a predefined (set of) task(s). It consists of software integrated on a hardware."
-- "Device{comment:36} A physical entity performing a predefined (set of) task(s). It consists of software integrated on a hardware."
++ "A DistributionJob is defines the time and conditions when one or more CCS deployments with the same homologation receive their software configuration update (preload and activation). Examples for conditions when the distribution-job is started are approvals from a train-driver, or someone from operation or a GOA4 system that need to approve the configuration update within the preloading and activation time windows. The distribution-job.json document references the Top Level BuildingBlockConfiguration (BBC), that has recursive dependency tree. The distribution-job is defined within a distribution-job.json document that is validated by the distribution-job.schema.json."
-- "A DistributionJob is defines the time and conditions when one or more CCS deployments with the same homologation receive their software configuration update (preload and activation). Examples for conditions when the distribution-job is started are approvals from a train-driver, or someone from operation or a GOA4 system that need to approve the configuration update within the preloading and activation time windows. The distribution-job.json document references the Top Level BuildingBlockConfiguration (BBC), that has recursive dependency tree. The distribution-job is defined within a distribution-job.json document that is validated by the distribution-job.schema.json."
++ "The equivalent area in the trackside in which (controllable) trackside assets shall be restricted from changing its correlation. In other words, whilst the SPT2OD-6035 - Missing cross-reference is occupied, the safety system shall not allow any request that could lead to the unsafe operation of a (controllable) trackside asset to be executed. {comment:40} (image: diagram_20231212-1351.17308.mxg.svg) Note as a representation, as a minimum, it has the equivalent dimensions of Danger Zone + Operating Time (+ applicable Margin), where: * 'Operation time' represents the (best case){comment:60} minimum period of time required for a controllable trackside asset to complete its operation from one defined state to another. * 'Margin' could refer to processing/communication time, etc."
-- "The equivalent area in the trackside in which (controllable) trackside assets shall be restricted from changing its correlation. In other words, whilst the SPT2OD-6035 - Missing cross-reference is occupied, the safety system shall not allow any request that could lead to the unsafe operation of a (controllable) trackside asset to be executed. {comment:40} (image: diagram_20231212-1351.17308.mxg.svg) Note as a representation, as a minimum, it has the equivalent dimensions of Danger Zone + Operating Time (+ applicable Margin), where: * 'Operation time' represents the (best case){comment:60} minimum period of time required for a controllable trackside asset to complete its operation from one defined state to another. * 'Margin' could refer to processing/communication time, etc."
++ "The Engineering Data aka Configuration Input Data is created based on the Engineering Input Data (IM Data) but generic (IM-unspecific). Typically, the data are not adapted to cope with specific views demanded by different Consuming Systems. The Engineering Data contains all the base data (i.e., track topology and topography) for deriving the Configuration Data during the compile process. Besides providing base data for the Configuration Data generation, the Engineering Data shall also cover the needs for the configuration of Consuming Systems (e.g., Parameter Data). The Engineering Data must fulfill engineering rules that are influenced by requirements of the Configuration Data for the Consuming Systems. The Engineering Data contains only the updated resulting data (i.e., not several variants/versions of the same track) that is needed for the next compiling and provisioning of Configuration Data and operation at a certain point in time in the Consuming Systems."
-- "The Engineering Data is created based on the Engineering Input Data (IM Data) but generic (IM-unspecific). Typically, the data are not adapted to cope with specific views demanded by different Consuming Systems. The Engineering Data contains all the base data (i.e., track topology and topography) for deriving the Configuration Data during the compile process. Besides providing base data for the Configuration Data generation, the Engineering Data shall also cover the needs for the configuration of Consuming Systems (e.g., Parameter Data). The Engineering Data must fulfil engineering rules that are influenced by requirements of the Configuration Data model and the Consuming Systems. The Engineering Data contains only the updated resulting data (i.e., not several variants/versions of the same track) that is needed for the next compiling and provisioning of Configuration Data and operation at a certain point in time in the Consuming Systems."
-- "function or capability that is required to maintain health, safety, the environment and availability for the equipment under control Note 1 to the entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control function and the ability of the operator to view and manipulate the equipment under control. The loss of essential functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries additional functions such as history may be considered essential. IEC 63452 definition: all functions needed to operate the railway system, such as per example traffic control, speed control, traction/brake control,..."
++ "function or capability that is required to maintain health, safety, the environment and availability for the equipment under control Note 1 to the entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control function and the ability of the operator to view and manipulate the equipment under control. The loss of essential functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries additional functions such as history may be considered essential. IEC 63452 definition: all functions needed to operate the railway system, such as per example traffic control, speed control, traction/breake control,..."
-- "function or capability that is required to maintain health, safety, the environment and availability for the equipment under control Note 1 to the entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control function and the ability of the operator to view and manipulate the equipment under control. The loss of essential functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries additional functions such as history may be considered essential. IEC 63452 definition: all functions needed to operate the railway system, such as per example traffic control, speed control, traction/breake control,..."
++ "It is expressed as the distance along the track centreline between a reference location and the estimated train front end position."
-- "It is expressed as the distance along the track centreline between a reference location and the estimated train front end position."
++ "ETP-OB - European Train Protection On-Board Note: ETP-OB equivalent with ETCS-OB"
-- "ETP-OB - European Train Protection On-Board Note: ETP-OB equivalent with ETCS-OB"
++ "EU-RailGoverning Board Final decision body, where a decisions are adopted a majority of at least 55% of the votes"
-- "EU-RailGoverning Board Final decision body, where a decisions are adopted a majority of at least 55% of the votes"
++ "Element transferred through an interface, which can be either energy, matter, and/or information. A exchange item carries elements with the same transport conditions, simultaneously with the same non-functional properties."
-- "Collection of elements brought together during one interaction or one exchange between functions or components (such as data, signal, flows ...). A exchange item carries elements with the same transport conditions, simultanuously with the same non-functional properties."
++ "Exchangeability is the ability to replace a sub-system from supplier A by a subsystem from supplier B without affecting other sub-systems or the overall system/subsystem and with a reasonable integration effort and/or certification effort. Different to interchangeability, exchangeability does not specify physical characteristics of subsystem. {comment:1413}"
-- "Exchangeability is the ability to replace a sub-system from supplier A by a subsystem from supplier B without affecting other sub-systems or the overall system/subsystem and with a reasonable integration effort and/or certification effort. Exchangeability and interchangeability are related to the physical characteristics and replacement of sub-systems whereas interoperability is related to interactions between sub-systems (e.g. also between STM and ETCS on-board there is interoperability).{comment:1413}"
++ "Extended View View displayed on more than one Display Panel."
-- "Extended View View displayed on more than one Display Panel."
++ "External Button A button which is not directly managed by TDS."
-- "External Button A button which is not directly managed by TDS."
++ "able to enter or remain in a safe state in the event of a failure [SOURCE: IEC 60050-821:2017 , 821-01-10]"
-- "able to enter or remain in a safe state in the event of a failure [SOURCE: IEC 60050-821:2017 , 821-01-10]"
++ "set of circumstances that leads to failure Note 1 to entry: A failure cause may originate during specification, design, manufacture, installation, operation or maintenance of an item. [SOURCE: IEC 60050.192:2015, 192-03-11]"
-- "set of circumstances that leads to failure Note 1 to entry: A failure cause may originate during specification, design, manufacture, installation, operation or maintenance of an item. [SOURCE: IEC 60050.192:2015, 192-03-11]"
++ "Manner in which failure occurs. Note 1 to entry: A failure mode may be defined by the function lost or other state transition that occurred. [SOURCE: IEC 60050-192:2015, 192-03-17]"
-- "Manner in which failure occurs. Note 1 to entry: A failure mode may be defined by the function lost or other state transition that occurred. [SOURCE: IEC 60050-192:2015, 192-03-17]"
++ "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [SOURCE: IEC 62278:2002, 3.14, modified]"
-- "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [SOURCE: IEC 62278:2002, 3.14, modified]"
++ "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [IEC 60050-821, 821-12-21]"
-- "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [IEC 60050-821, 821-12-21]"
++ "part of active corrective maintenance time taken to perform fault correction [SOURCE: IEC 60050-192:2015,192-07-14]"
-- "part of active corrective maintenance time taken to perform fault correction [SOURCE: IEC 60050-192:2015,192-07-14]"
++ "DEPRECATED: undetected fault time time interval between failure and detection of the resulting fault [SOURCE: IEC 60050-192:2015,192-07-11]"
-- "DEPRECATED: undetected fault time time interval between failure and detection of the resulting fault [SOURCE: IEC 60050-192:2015,192-07-11]"
++ "DEPRECATED: fault location time part of active corrective maintenance time taken to complete fault localization"
-- "DEPRECATED: fault location time part of active corrective maintenance time taken to complete fault localization [SOURCE: IEC 60050-192:2015,192-07-18]"
++ "logic diagram showing the faults of sub items, external events, or combinations thereof, which cause a predefined, undesired event [SOURCE: IEC 60050-192:2015, 192-11-07]"
-- "logic diagram showing the faults of sub items, external events, or combinations thereof, which cause a predefined, undesired event [SOURCE: IEC 60050-192:2015, 192-11-07]"
++ "Characteristic of a system in a product line that distinguishes it from other systems in the product line. Those characteristics express either stakeholder-visible variability or implementation variability. Note: In feature-based product line engineering, features express differences among member products. A characteristic common to all member products in the product line is usually not modelled as a feature. Features in railway is everything what can be different when moving between A and B. Variation type / Dependency | Description (image: 5-screenshot-20241129-173318-7.png) | A mandatory features is implicitly selected if its parent feature is selected. (image: 6-screenshot-20241129-173318-8.png) | Only one group of alternative features is possible under a parent node. Exactly one feature has to be selected from a group if the parent feature is selected. The other alternative feature are automatically excluded. (image: 7-screenshot-20241129-173318-9.png) | The optional features are not belonging to each other (building not a group of similar features). If at least one of the optional features is selected the parent node is selected as well. (image: 8-screenshot-20241129-173318-10.png) | Only one group of or features is possible under a parent node and 0..n features can be selected. If at least one of the or features is selected the parent node is selected as well. In principal optional features and or features are equivalent. The only difference is that optional features do not belong to each other and or features are a group of similar features."
fault mode, effects and criticality analysis
++ "A trace (nodes/work items and their links) is a graph that works out one issue (e.g. one requirement) in the most efficient, complete and fast way, down to its operational and system implementation (image: 2-image2.png) Figure {caption:Figure}: Trace for a CBO requirement (red point in the middle) in an ALM System System Levels are just “areas of team responsibilities” for working on parts of the graph * System Level 1 / 2 = teams … = Work item detail level … * System Level 3 = teams … = Work item detail level … * System Level 4 = teams … = Work item detail level … * System Level 5 = teams … = Work item detail level … Assigning a work item to a System Level just means: Assigning them to a team. No good idea: Design every System Level with everything that a real-world system would need. Systems on Level 1-4 are no real-world systems, they just structure the work assignment. Trace Example – just one “branch”: The reality is not puristic, it is like a “neuron-mesh” A. SL2: Requirement “High, scalable, and flexible transport capacity” >> B. SL3: Process “efficient ATP for high density lines” >> C. SL4: Requirement “Precise and frequent localisation” in the train >> D. SL3: Architecture (functions) for a high- performance localisation System >> E. SL5: Interface requirements to deliver a map to the train >> F. SL5: Requirement that Traffic CS delivers a reliable map >> …. Think in “good complete traces”, and do not “fill all System Levels” (!) --> It is just important that “traces are complete, good and correct”, with work items assigned to the right team level --> What System Levels are NOT for: Being the basic scheme for everything * Creating a break-down element on every System Level --> this does not work and requires too much effort * Exception: The work item “system” is broken down on every level, but for example interfaces or logical components only exist in System Level 5) When do we need “completion” on System Levels? Sometimes it is necessary. Example 1: Safety analysis for “Assure that all CCS processes are safe” * All operational processes need to be listed and analysed on System level 3 (OA) * Out of this all traces have to be analysed to understand the hazards and risks But this does not mean that this is also done for System Level 1,2, or 4. Just the operational design team in Task 2 has to do this. Example 2: Systems on System Level 5 (“standard products”) * Complete description how to install and use them (processes) * Complete functional description * Complete system and interface description How to follow “traces” Following a trace means to break down work items more and more. Every breakdown is not necessarily “homogenous”. One breakdown step (indicative): A break down step follows this workflow (for the assigned team) * Assess if work item is accepted and makes sense. If not, reject and forward work item to a functional team * Analyse, work out, and refine a work item; change status when finished * Draft and link the derived work items, set status to “proposed” * Propose their assignment to a team * Assigned team accepts or forwards the derived work item to a functional team. How do traces start, how to reach “completeness”? A. New traces start from * Any input of the stakeholders * Common Business Objectives (CBO) * A System Level 2/3 mission and the needed operational capabilities, derived operational scenarios and their operational requirements * Any input inside of the System Pillar team – if a backward linking to CBO or operational missions/capabilities is possible or stakeholder (steering group) agree Completeness is reached if for all of these (decided) inputs a trace down to the implementation exists with a valid trace. B. A trace is valid if * …it is connected up to a decided demand (A.) * …it is connected down to an implementation in operational processes and System Level 5. * … all links between work items of the trace are valid (correct derivation) The status of all traces will be visible at any time via the ALM."
-- "A trace (nodes/work items and their links) is a graph that works out one issue (e.g. one requirement) in the most efficient, complete and fast way, down to its operational and system implementation (image: 2-image2.png) Figure {caption:Figure}: Trace for a CBO requirement (red point in the middle) in an ALM System System Levels are just “areas of team responsibilities” for working on parts of the graph * System Level 1 / 2 = teams … = Work item detail level … * System Level 3 = teams … = Work item detail level … * System Level 4 = teams … = Work item detail level … * System Level 5 = teams … = Work item detail level … Assigning a work item to a System Level just means: Assigning them to a team. No good idea: Design every System Level with everything that a real-world system would need. Systems on Level 1-4 are no real-world systems, they just structure the work assignment. Trace Example – just one “branch”: The reality is not puristic, it is like a “neuron-mesh” A. SL2: Requirement “High, scalable, and flexible transport capacity” >> B. SL3: Process “efficient ATP for high density lines” >> C. SL4: Requirement “Precise and frequent localisation” in the train >> D. SL3: Architecture (functions) for a high- performance localisation System >> E. SL5: Interface requirements to deliver a map to the train >> F. SL5: Requirement that Traffic CS delivers a reliable map >> …. Think in “good complete traces”, and do not “fill all System Levels” (!) --> It is just important that “traces are complete, good and correct”, with work items assigned to the right team level --> What System Levels are NOT for: Being the basic scheme for everything * Creating a break-down element on every System Level --> this does not work and requires too much effort * Exception: The work item “system” is broken down on every level, but for example interfaces or logical components only exist in System Level 5) When do we need “completion” on System Levels? Sometimes it is necessary. Example 1: Safety analysis for “Assure that all CCS processes are safe” * All operational processes need to be listed and analysed on System level 3 (OA) * Out of this all traces have to be analysed to understand the hazards and risks But this does not mean that this is also done for System Level 1,2, or 4. Just the operational design team in Task 2 has to do this. Example 2: Systems on System Level 5 (“standard products”) * Complete description how to install and use them (processes) * Complete functional description * Complete system and interface description How to follow “traces” Following a trace means to break down work items more and more. Every breakdown is not necessarily “homogenous”. One breakdown step (indicative): (image: 1-screenshot-20221229-205247.png) A break down step follows this workflow (for the assigned team) * Assess if work item is accepted and makes sense. If not, reject and forward work item to a functional team * Analyse, work out, and refine a work item; change status when finished * Draft and link the derived work items, set status to “proposed” * Propose their assignment to a team * Assigned team accepts or forwards the derived work item to a functional team. How do traces start, how to reach “completeness”? A. New traces start from * Any input of the stakeholders * Common Business Objectives (CBO) * A System Level 2/3 mission and the needed operational capabilities, derived operational scenarios and their operational requirements * Any input inside of the System Pillar team – if a backward linking to CBO or operational missions/capabilities is possible or stakeholder (steering group) agree Completeness is reached if for all of these (decided) inputs a trace down to the implementation exists with a valid trace. B. A trace is valid if * …it is connected up to a decided demand (A.) * …it is connected down to an implementation in operational processes and System Level 5. * … all links between work items of the trace are valid (correct derivation) The status of all traces will be visible at any time via the ALM."
++ "A FFFIS is the complete definition of an interface between functional or physical entities. The FFFIS includes: - FIS, - Electrical characteristics related to data, - communication protocol, - and including connector and plug. The FFFIS and accompanying documents (e.g. safety analysis) guarantees the interoperability but not the exchangeability of physical entities, see Subset-037 SPT2ARC-1620."
-- "A FFFIS is the complete definition of an interface between functional or physical entities. The FFFIS includes: - FIS, - Electrical characteristics related to data, - communication protocol, - and including connector and plug. The FFFIS and accompanying documents (e.g. safety analysis) guarantees the interoperability but not the exchangeability of physical entities, see Subset-037 SPT2ARC-1620."
++ "fault tree analysis deductive analysis using fault trees Note 1 to entry: See also fault tree (192-11-07 SPPRAMSS-4464 - fault tree ). [SOURCE: IEC 60050-192:2015, 192-11-08]"
-- "fault tree analysis deductive analysis using fault trees Note 1 to entry: See also fault tree (192-11-07 SPPRAMSS-4464 - fault tree ). [SOURCE: IEC 60050-192:2015, 192-11-08]"
++ "A function is a transformation of inputs into outputs which is purpose-oriented and pays towards a higher goal of a system. All possible input and output values are defined by the exchange items allocated to the functional exchanges of the function. Consequently, when the inputs to the system change, the transformations within the system modify the outputs accordingly. They can be available in a range of system states and therefore change its behaviour based on the current state of inputs. The structure of functions does not have to reflect any possible implementation and does not have to follow an object decomposition paradigm, as would be followed normally by software engineers implementing one or more systems. In addition, each function is continuously performed by the system or system actors. They are not created, called and terminated. Functions are allocated to the system or to the system actors. Each function is allocated to one or multiple functional requirements, defining “what” the function is doing. The expected characteristics of functions are then specified via non-functional requirements, which define the “how” (how safe, how accurate, how fast, how reliable, etc.) the function is performing the transformation."
-- "A function is a continuous transformation of inputs into outputs which is purpose-oriented and pays towards a higher goal of a system. All possible input and output values are defined by the exchange items allocated to the functional exchanges of the function. Functions are allocated to the system or to the system actors. Consequently, when the inputs to the system change, the transformations within the system modify the outputs accordingly. They can be also available in a range of system states and therefore change its behaviour based on the current state. Each function is allocated to {comment:17}one or multiple functional requirements, defining “what” the function is doing. The expected characteristics of functions are then specified via non-functional requirements, which define the “how” (how safe, how accurate, how fast, how reliable, etc.) the function is performing the transformation. The structure of functions does not have to reflect any possible implementation and does not have to follow an object decomposition paradigm, as would be followed normally by software engineers implementing one or more systems."
++ "Generic Application Safety Case;SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] {comment:99},SPPRAMSS-335 - [EN 50126-2:2017]"
-- "Generic Application Safety Case (from EN 50129:2018)"
++ "* Assignment workflow: Unassigned, rejected, or unlinked work items are assigned to a team based on the work item type and system level (done by a functional team, see [2]) * Derivation workflow: The standard workflow, where work items are resolved along the mandatory trace (along the workflow rules), work is moving from team to team, or from team collaboration to team collaboration * Trace change workflow: A change in a trace is analysed up to the highest work item again (done by modelling service, all work items get “suspect”), and from there all derivations are checked, resolved, and approved again (derivation workflow). * Uplink workflow: A set of traces is “connected” to another set. This typically happens, when “external contributions” are imported (e.g. a team that proposes the interfaces of a subsystem). The connection links are created as proposals. For all new connection links a trace change workflow is executed. Redundancies are analysed and eliminated, what again triggers trace change workflows. * Trace analysis workflow: Progress and trace consistency are analysed and reported by the modelling service These workflows are assigned by the team or person, where the triggering work item is assigned to. The trace analysis is done by the modelling service on a frequent basis."
-- "* Assignment workflow: Unassigned, rejected, or unlinked work items are assigned to a team based on the work item type and system level (done by a functional team, see [2]) * Derivation workflow: The standard workflow, where work items are resolved along the mandatory trace (along the workflow rules), work is moving from team to team, or from team collaboration to team collaboration * Trace change workflow: A change in a trace is analysed up to the highest work item again (done by modelling service, all work items get “suspect”), and from there all derivations are checked, resolved, and approved again (derivation workflow). * Uplink workflow: A set of traces is “connected” to another set. This typically happens, when “external contributions” are imported (e.g. a team that proposes the interfaces of a subsystem). The connection links are created as proposals. For all new connection links a trace change workflow is executed. Redundancies are analysed and eliminated, what again triggers trace change workflows. * Trace analysis workflow: Progress and trace consistency are analysed and reported by the modelling service These workflows are assigned by the team or person, where the triggering work item is assigned to. The trace analysis is done by the modelling service on a frequent basis."
-- "Generic Product Safety Case (from EN 50129:2018)"
++ "Hard Key Physical key not part of view. This key can also have a text label or symbol."
-- "Hard Key Physical key not part of view. This key can also have a text label or symbol."
++ "The Hardware Abstraction Interface I2 (Interface 2) provides an abstraction of all technology layers above from the specific hardware used below, enabling easy replace ability of commercial of-the-shelf hardware procurable from a well-sized market of hardware vendors. Note: This is not really an interface, but rather a compatibility list of allowed hardware incl. CPU, memory, etc."
-- "The Hardware Abstraction Interface I2 (Interface 2) provides an abstraction of all technology layers above from the specific hardware used below, enabling easy replace ability of commercial of-the-shelf hardware procurable from a well-sized market of hardware vendors. Note: This is not really an interface, but rather a compatibility list of allowed hardware incl. CPU, memory, etc."
**++ "A product is harmonized only if it adapts all availabe harmonized interfaces of the System Pillar Refernce Architecture (SPRA) on all interface types (system interface, user interface, physical interface) and the correlating system behaviour (=stateful reaction on input interfaces/events on state changes/output interfaces). A harmonized product could have customized additional optional interfaces and system behavior, if the system can be used in the harmonized way without making use of them."
**-- "A product is harmonized only if it adapts all availabe harmonized interfaces of the System Pillar Refernce Architecture (SPRA) on all interface types (system interface, user interface, physical interface) and the correlating system behaviour (=stateful reaction on input interfaces/events on state changes/output interfaces). A harmonized product could have customized additional optional interfaces and system behavior, if the system can be used in the harmonized way without making use of them."
++ "A hazard and operability study (HAZOP) is a structured and systematic examination of a complex planned or existing process or operation in order to identify and evaluate problems that may represent risks to personnel or equipment. The intention of performing a HAZOP is to review the design to pick up design and engineering issues that may otherwise not have been found. The technique is based on breaking the overall complex design of the process into a number of simpler sections called 'nodes' which are then individually reviewed. It is carried out by a suitably experienced multi-disciplinary team (HAZOP) during a series of meetings. The HAZOP technique is qualitative, and aims to stimulate the imagination of participants to identify potential hazards and operability problems. Structure and direction are given to the review process by applying standardised guide-word prompts to the review of each node. [SOURCE: Wikipedia Hazard and operability study - Wikipedia]"
-- "A hazard and operability study (HAZOP) is a structured and systematic examination of a complex planned or existing process or operation in order to identify and evaluate problems that may represent risks to personnel or equipment. The intention of performing a HAZOP is to review the design to pick up design and engineering issues that may otherwise not have been found. The technique is based on breaking the overall complex design of the process into a number of simpler sections called 'nodes' which are then individually reviewed. It is carried out by a suitably experienced multi-disciplinary team (HAZOP) during a series of meetings. The HAZOP technique is qualitative, and aims to stimulate the imagination of participants to identify potential hazards and operability problems. Structure and direction are given to the review process by applying standardised guide-word prompts to the review of each node. [SOURCE: Wikipedia Hazard and operability study - Wikipedia]"
++ "HFI Activities are conducted to optimise the effectiveness and efficiency of human performance by fully considering the human contribution to system performance. Human Performance is the observable and measurable behaviour that occurs in job and task situations, the extent to which goals such as speed, accuracy, quality and other criteria are met by people in their work environments. The focus is on the ability of operators and maintainers to meet system performance requirements, including reliability and maintainability, under the conditions in which the system is employed."
-- "HFI Activities are conducted to optimise the effectiveness and efficiency of human performance by fully considering the human contribution to system performance. Human Performance is the observable and measurable behaviour that occurs in job and task situations, the extent to which goals such as speed, accuracy, quality and other criteria are met by people in their work environments. The focus is on the ability of operators and maintainers to meet system performance requirements, including reliability and maintainability, under the conditions in which the system is employed."
++ "A Secure Component with a human machine interface. Examples of HMI Components are PC Workstation, tablet device, smart phone, device with touch screen,... Exemptions: embedded components without a screen, e.g. with push buttons and LEDs."
-- "A Secure Component with a human user interface. Examples of HMI Components are PC Workstation, tablet device, smart phone, device with touch screen,... Exemptions: embedded components without a screen, e.g. with push buttons and LEDs."
++ "HMI Element An HMI Element is a physical component that interacts with the driver: Buzzer, Display Panel, loudspeaker, Hard Key..."
-- "HMI Element An HMI Element is a physical component that interacts with the driver: Buzzer, Display Panel, loudspeaker, Hard Key..."
++ "Human factors issues include anything that affects human performance, particularly those factors that may cause or contribute to human error. The main human factors areas include: * Individual (physical size, personal preferences, cognitive skills, attitudes, background) * Organisation (culture, work pattern, communications, supervision, training) * Job (design of equipment, rules and procedures, tools, signage, environment) The purpose of human factors is to minimise safety risk from the possibility of human error by: * ensuring human characteristics are accounted for in the design (or re-design) of new and existing systems and equipment * identifying the issues which may cause or contribute to human errors * conducting activities and applying controls to reduce likelihood and consequences."
-- "Human factors issues include anything that affects human performance, particularly those factors that may cause or contribute to human error. The main human factors areas include: * Individual (physical size, personal preferences, cognitive skills, attitudes, background) * Organisation (culture, work pattern, communications, supervision, training) * Job (design of equipment, rules and procedures, tools, signage, environment) The purpose of human factors is to minimise safety risk from the possibility of human error by: * ensuring human characteristics are accounted for in the design (or re-design) of new and existing systems and equipment * identifying the issues which may cause or contribute to human errors * conducting activities and applying controls to reduce likelihood and consequences."
++ "Human-System Integration, an interdisciplinary approach that aims at optimizing in an early development stage the global system performance by desgining solutions adapted for both human and technical system. HSI studies integrates work from multiple human centered domains - process analysis, both qualitative and quantitatve, ergonomics, safety, survivability, habitability, skill analysis, training. HSI typically help define user interfaces and lead to workitem SPPR-2246 - Application Condition or SPPR-2244 - Safety related application conditions ."
-- "Human-System Integration, an interdisciplinary approach that aims at optimizing in an early development stage the global system performance by desgining solutions adapted for both human and technical system. HSI studies integrates work from multiple human centered domains - process analysis, both qualitative and quantitatve, ergonomics, safety, survivability, habitability, skill analysis, training. HSI typically help define user interfaces and lead to workitem SPPR-2246 - Application Condition or SPPR-2244 - Safety related application conditions ."
++ "Impersonation, in terms of behavior, involves a person or entity imitating or mimicking the actions, mannerisms, or characteristics of another individual or entity. In the context on how this definition is to be understood, a newer system would behave exactly like an older version system of itself, allowing it to interact with older systems/subsystems transparently, by behaving exactly like the older version expected by them. From a software perspective, the different impersonations a system can take could be implemented as independent modules, which would reduce the complexity of each module implementing an specific impersonation, and also limit the side effects of changes or bugs in one module to the others. It could also facilitate the addition of a new version of a system, while still keeping the former version of the system available in a transparent way."
-- "Impersonation, in terms of behavior, involves a person or entity imitating or mimicking the actions, mannerisms, or characteristics of another individual or entity. In the context on how this definition is to be understood, a newer system would behave exactly like an older version system of itself, allowing it to interact with older systems/subsystems transparently, by behaving exactly like the older version expected by them. From a software perspective, the different impersonations a system can take could be implemented as independent modules, which would reduce the complexity of each module implementing an specific impersonation, and also limit the side effects of changes or bugs in one module to the others. It could also facilitate the addition of a new version of a system, while still keeping the former version of the system available in a transparent way."
for Railway Undertaking are used due to their widespread use in the rail sector. The equivalents terms are
++ "* Input documents” are for example * Imported documents that are stored as “unstructured” content in the ALM in the first step (no work items created already) * Unstructured documents that are step by step converted to documents with structured work items * A model or model sketch from another modelling system, that is not compliant or convertible to SP modelling method/system, created as input document with concrete Polarion work items in the status “proposal”. These are seen as input sketches and are added manually into the SP modelling system using the correct method and modelling process * ALM documents in which new work items are created in a free structure and sequence (workflow designed in the domains) * Input documents are not used as formal deliverable (because they are created manually and may not contain all work items in a certain scope), but they can be used as background documentation. * The differentiation of input and output documents allows to create input documents along the needs of the workflows – having “things at one place where the team is currently working” – without the constraint to structure or “sort” it as a formal output (image: 1-screenshot-20221230-141047.png)"
-- "* Input documents” are for example * Imported documents that are stored as “unstructured” content in the ALM in the first step (no work items created already) * Unstructured documents that are step by step converted to documents with structured work items * A model or model sketch from another modelling system, that is not compliant or convertible to SP modelling method/system, created as input document with concrete Polarion work items in the status “proposal”. These are seen as input sketches and are added manually into the SP modelling system using the correct method and modelling process * ALM documents in which new work items are created in a free structure and sequence (workflow designed in the domains) * Input documents are not used as formal deliverable (because they are created manually and may not contain all work items in a certain scope), but they can be used as background documentation. * The differentiation of input and output documents allows to create input documents along the needs of the workflows – having “things at one place where the team is currently working” – without the constraint to structure or “sort” it as a formal output (image: 1-screenshot-20221230-141047.png)"
++ "Integrity: property of accuracy and completeness (source: ISO 27000-2018 )"
-- "Integrity: property of accuracy and completeness (source: ISO 27000-2018 )"
++ "Interchangeability is the ability to replace a subsystem from supplier A by a sub-system from supplier B without affecting other sub-systems or the overall system/subsystem and with a lowest reasonable integration effort{comment:1295} and without any need for recertification. Interchangeability is related also to the physical characteristics of sub-systems."
-- "Interchangeability is the ability to replace a subsystem from supplier A by a sub-system from supplier B without affecting other sub-systems or the overall system/subsystem and with a lowest reasonable integration effort{comment:1295} and without any need for recertification. Exchangeability and interchangeability are related to the physical characteristics and replacement of sub-systems whereas interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."
++ "Internal Button The Internal Button is a button which is managed directly by TDS."
-- "Internal Button The Internal Button is a button which is managed directly by TDS."
++ "SPPRAMSS-328 - [TSI CCS + (EU) 2023/1695] section 5.1. Definition In accordance with Article 2(7) of Directive (EU) 2016/797, interoperability constituents means any elementary component, group of components, subassembly or complete assembly of equipment incorporated or intended to be incorporated into a subsystem, upon which the interoperability of the rail system depends directly or indirectly, including both tangible objects and intangible objects."
-- "SPPRAMSS-328 - [TSI CCS + (EU) 2023/1695] section 5.1. Definition In accordance with Article 2(7) of Directive (EU) 2016/797, interoperability constituents means any elementary component, group of components, subassembly or complete assembly of equipment incorporated or intended to be incorporated into a subsystem, upon which the interoperability of the rail system depends directly or indirectly, including both tangible objects and intangible objects."
++ "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance, see [Subset-023] SPT2ARC-1619 and [IOP-Dir 2016/797] SPT2ARC-1617 so that a train is able to run across different Infrastructure Managers (IM) networks, and that an IM network and that an infrastructure network{comment:1394} is able to interact with trains of different Railway Undertakings, using systems/sub-systems from different origins. Interoperability between subsystems is defined to achieve a similar unrestricted safe and uninterrupted interaction between subsystems."
-- "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance, see [Subset-023] SPT2ARC-1619 and [IOP-Dir 2016/797] SPT2ARC-1617 so that a train is able to run across different Infrastructure Managers (IM) networks, and that an IM network and that an infrastructure network{comment:1394} is able to interact with trains of different Railway Undertakings, using systems/sub-systems from different origins. Exchangeability and interchangeability are related to the physical characteristics of sub-systems whereas interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."
++ "Key Controller Controller which manages states and failures of Hard Keys (internal and Lateral Key) and switches."
-- "Key Controller Controller which manages states and failures of Hard Keys (internal and Lateral Key) and switches."
++ "Lateral Key Hard Key located close to a Display Area allowing soft key technology."
-- "Lateral Key Hard Key located close to a Display Area allowing soft key technology."
++ "Layout Controller The Layout Controller manages the Layout for an Area."
-- "Layout Controller The Layout Controller manages the Layout for an Area."
++ "Layout Element Controller The Layout Element Controller managesLayout Elements of a Layout. It knows how to present itself and how to react on events."
-- "Layout Element Controller The Layout Element Controller managesLayout Elements of a Layout. It knows how to present itself and how to react on events."
++ "Layout Engine The Layout Engine is a generic piece of software able to generate any View based on Areas, Layouts and Layout Elements as defined in a configuration."
-- "Layout Engine The Layout Engine is a generic piece of software able to generate any View based on Areas, Layouts and Layout Elements as defined in a configuration."
++ "Layout Layout is a list of layout elements which is displayed in an area."
-- "Layout Layout is a list of layout elements which is displayed in an area."
++ "either imported from outside the project or authored inside the project, lexical glossaries are the containers for lexical entiries and abbreviations. A lexical glossary is first consolidated by its glossary author in its own scope, i.e. its definitions shall not be redundant with each other. It is then consolidated towards other glossaries. This glossary is then called SPPR-5441 - Missing cross-reference. Lexical glossaries are the source of the lexical definitons and abbreviations referred to in SPPR-5434 - Refering document."
-- "either imported from outside the project or authored inside the project, lexical glossaries are the containers for lexical entiries and abbreviations. A lexical glossary is first consolidated by its glossary author in its own scope, i.e. its definitions shall not be redundant with each other. It is then consolidated towards other glossaries. This glossary is then called SPPR-5441 - Missing cross-reference. Lexical glossaries are the source of the lexical definitons and abbreviations referred to in SPPR-5434 - Refering document."
++ "Set of spatial values referenced to the rail network, and kinematic variables referenced to the train unit, that provide the train front end position of the train in a specific point of the network and its dynamic behaviour from its speed, acceleration, and orientation values."
-- "Set of spatial values referenced to the rail network, and kinematic variables referenced to the train unit, that provide the train front end position of the train in a specific point of the network and its dynamic behaviour from its speed, acceleration, and orientation values."
++ "delay, excluding administrative delay, incurred for the provision of resources needed for a maintenance action to proceed or continue. [SOURCE: IEC 60050-192:2015, 192-07-13]"
-- "delay, excluding administrative delay, incurred for the provision of resources needed for a maintenance action to proceed or continue. [SOURCE: IEC 60050-192:2015, 192-07-13]"
++ "Loudspeaker Device that converts an electrical audio signal into a corresponding sound."
-- "Loudspeaker Device that converts an electrical audio signal into a corresponding sound."
++ "mean active corrective maintenance time expectation of the active corrective maintenance time [SOURCE: IEC 60050-192:2015, 192-07-22]"
-- "mean active corrective maintenance time expectation of the active corrective maintenance time [SOURCE: IEC 60050-192:2015, 192-07-22]"
++ "mean administrative delay. Expectation of the administrative delay. [SOURCE: IEC 60050-192:2015,192-07-26]"
-- "mean administrative delay. Expectation of the administrative delay. [SOURCE: IEC 60050-192:2015,192-07-26]"
++ "Ability to be retained in, or restored to, a state to perform as required, under given conditions of use and maintenance Note 1 to entry: Given conditions would include aspects that affect maintainability, such as: location for maintenance, accessibility, maintenance procedures and maintenance resources. [SOURCE: IEC 60050-192:2015, 192-01-27] Source: SPPRAMSS-349 - [EN 50126-1:2017]"
-- "Ability to be retained in, or restored to, a state to perform as required, under given conditions of use and maintenance Note 1 to entry: Given conditions would include aspects that affect maintainability, such as: location for maintenance, accessibility, maintenance procedures and maintenance resources. [SOURCE: IEC 60050-192:2015, 192-01-27] Source: SPPRAMSS-349 - [EN 50126-1:2017]"
**++ "A trace (nodes/work items and their links) is a graph that works out one issue (e.g. one requirement) in the most efficient, complete and fast way, down to its operational and system implementation (image: 1-image10.png)"
**-- "A trace (nodes/work items and their links) is a graph that works out one issue (e.g. one requirement) in the most efficient, complete and fast way, down to its operational and system implementation (image: 1-image10.png)"
++ "Mean Distance Between Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"
-- "Mean Distance Between Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"
++ "Mean Distance Between Service Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"
-- "Mean Distance Between Service Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"
++ "Measure of Effectiveness (that the system performs as required). Characteristics: * Relates to performance * Objective * Simple to state * Testable * Complete * Clear * States any time dependency * States any environmental conditions * Can be measured quantitatively (if required, may be measured statistically or as a probability) * Easy to measure * Select only MoEs that measure the degree to which the desired outcome is achieved * Use the same MoEs to measure more than one condition when appropriate * Structure so that they have measurable, collectible, and relevant indicators * Write as statements (not questions) * Maximize clarity"
-- "Measure of Effectiveness (that the system performs as required). Characteristics: * Relates to performance * Objective * Simple to state * Testable * Complete * Clear * States any time dependency * States any environmental conditions * Can be measured quantitatively (if required, may be measured statistically or as a probability) * Easy to measure * Select only MoEs that measure the degree to which the desired outcome is achieved * Use the same MoEs to measure more than one condition when appropriate * Structure so that they have measurable, collectible, and relevant indicators * Write as statements (not questions) * Maximize clarity"
++ "A collection of related processes, methods, and tools.{comment:408}"
-- "A collection of related processes, methods, and tools."
++ "A technique for performing a task. Method is a grouping of guidance, modelling{comment:72} language, rules, techniques and patterns. Different methods may be available for the same task. It defines the “HOW” of each task. (In this context, the words “method,” “technique,” “practice,” and “procedure” are often used interchangeably.) At any level, process tasks are performed using methods. {comment:407}"
-- "A technique for performing a task. Method is a grouping of guidance, modelling{comment:72} language, rules, techniques and patterns. Different methods may be available for the same task. It defines the “HOW” of each task. (In this context, the words “method,” “technique,” “practice,” and “procedure” are often used interchangeably.) At any level, process tasks are performed using methods."
++ "mean fault detection time [SOURCE: SPPRAMSS-3539 - [EN 61703: 2016]]"
-- "mean fault detection time [SOURCE: SPPRAMSS-3539 - [EN 61703: 2016]]"
++ "Microphone Controller The Microphone Controller manages states and signals of Microphone."
-- "Microphone Controller The Microphone Controller manages states and signals of Microphone."
++ "Microphone Device that translates sound vibrations from the air into electronic signals and scribes them to a recording medium or over a loudspeaker."
-- "Microphone Device that translates sound vibrations from the air into electronic signals and scribes them to a recording medium or over a loudspeaker."
++ "The typical expected international timing of the harmonisation phase from international perspective is, that there will be early providers/early birds, and late providers/late birds. Since the reference architecture consists of different systems, the railways can also apply different migration strategies to different systems (image: 1-diagram_20240626-1851.56163.mxg.svg)"
-- "The typical expected international timing of the harmonisation phase from international perspective is, that there will be early providers/early birds, and late providers/late birds. Since the reference architecture consists of different systems, the railways can also apply different migration strategies to different systems (image: 1-diagram_20240626-1851.56163.mxg.svg)"
++ "mean logistic delay. Expectation of the logistic delay. [SOURCE: IEC 60050-192:2015,192-07-27]"
-- "mean logistic delay. Expectation of the logistic delay. [SOURCE: IEC 60050-192:2015,192-07-27]"
++ "* There are two types of synchronisations: * A copy of all MBSE models is stored in the ALM. The copied work items can be part of the ALM workflow or can be approved, decided, commented and linked in the ALM. * Synchronisation between “mother LA/PA” and “daughter LA/PA” in the MBSE platform. These are done to split architecting work to different teams. * Example (start situation for the SP): (image: 1-Picture_1.png)"
-- "* There are two types of synchronisations: * A copy of all MBSE models is stored in the ALM. The copied work items can be part of the ALM workflow or can be approved, decided, commented and linked in the ALM. * Synchronisation between “mother LA/PA” and “daughter LA/PA” in the MBSE platform. These are done to split architecting work to different teams. * Example (start situation for the SP): (image: 1-Picture_1.png)"
++ "mean operating time between failures expectation of the duration of the operating time between failures Note 1 to entry: Mean operating time between failures should only be applied to repairable items. For non-repairable items, see mean operating time to failure (192-05-11) SPPRAMSS-4040 - MTTF . [SOURCE: IEC 60050-192:2015, 192-05-13]"
-- "mean operating time between failures expectation of the duration of the operating time between failures Note 1 to entry: Mean operating time between failures should only be applied to repairable items. For non-repairable items, see mean operating time to failure (192-05-11) SPPRAMSS-4040 - MTTF . [SOURCE: IEC 60050-192:2015, 192-05-13]"
++ "A Movement Permission (MP) is an authorisation for a particular Train Object to move. A Movement Permission includes all conditions under which the movement of the Train Object can be performed safely. A Movement Permission always refers to exactly one Train Object."
-- "Movement Permissions are within the Operating State of TPS. A Movement Permission represents the area of the track layout reserved for a train within TPS. (image: 1-screenshot-20240815-145159.png)"
++ "A Trackside where the Movement Authority for a train can be issued to the Confirmed Rear End of the preceding train. End of Authority can therefore be an arbitrary location on the railway and not constrained to fixed block locations."
-- "The term moving block is part of the ETCS Level 2 Moving Block Principle, which is a signalling concept placing emphasis on a largely independent signalling from the physical infrastructure. A moving block is defined by a block bounded by the confirmed rear end and the confirmed rear end of the preceding train (case 1, Figure 1) or, if closer, the beginning of the next fixed block (case 2, Figure 2). Such fixed blocks are delimited by TTDs e.g. around points and may for efficiency reasons still be used on ETCS L2MB lines. (image: 2-Def_MovingBlock1.png) Figure {caption:Figure} Case 1 Definition of Moving Block(image: 1-Def_MovingBlock2.png) Figure {caption:Figure} Case 2 Definition of Moving Block (incl. TTDs)) The confirmed rear end of the preceding train is what releases the track behind it and in most cases delimits the moving block. It is established from the safe train length, represented by the distance between the estimated train front end position and the min safe rear end of the train [SUBSET-026 Baseline 4], if derived from a train position report with confirmed train integrity."
++ "The term moving block is part of the ETCS Level 2 Moving Block Principle, which is a signalling concept placing emphasis on a largely independent signalling from the physical infrastructure. A moving block is defined by a block bounded by the confirmed rear end and the confirmed rear end of the preceding train (case 1, Figure 1) or, if closer, the beginning of the next fixed block (case 2, Figure 2). Such fixed blocks are delimited by TTDs e.g. around points and may for efficiency reasons still be used on ETCS L2MB lines. (image: 2-Def_MovingBlock1.png) Figure {caption:Figure} Case 1 Definition of Moving Block Figure {caption:Figure} Case 2 Definition of Moving Block (incl. TTDs)) The confirmed rear end of the preceding train is what releases the track behind it and in most cases delimits the moving block. It is established from the safe train length, represented by the distance between the estimated train front end position and the min safe rear end of the train [SUBSET-026 Baseline 4], if derived from a train position report with confirmed train integrity."
-- "Moving block is based on the principle of spacing trains in absolute braking distance. In a moving block system, the rear end of a train is considered as a moving danger point to be protected against a following train. Positions of the trains are either given by trackside or trainside localisation euqipment."
++ "expectation of the (mean) repair time [SOURCE: IEC 60050-192:2015, 192-07-21] Note 1: MRT = fault localization time + fault correction time + function checkout time according SPPRAMSS-3539 - [EN 61703: 2016]"
-- "expectation of the (mean) repair time [SOURCE: IEC 60050-192:2015, 192-07-21] Note 1: MRT = fault localization time + fault correction time + function checkout time according SPPRAMSS-3539 - [EN 61703: 2016]"
++ "mean operating time between service failures Note 1 to entry: Service failures should be defined as one of the failures severity levels. These failures are understood as failures with operational impact. For example failures for which the safety reaction is application of the service brake. Note 2 to entry: Abbreviation is not yet defined in any CEN/CENELEC railway standard but is often used by railway operators and infrastructure managers."
-- "mean operating time between service failures Note 1 to entry: Service failures should be defined as one of the failures severity levels. These failures are understood as failures with operational impact. For example failures for which the safety reaction is application of the service brake. Note 2 to entry: Abbreviation is not yet defined in any CEN/CENELEC railway standard but is often used by railway operators and infrastructure managers."
++ "mean technical delay [SOURCE: SPPRAMSS-349 - [EN 50126-1:2017] Annex B.4]"
-- "mean technical delay [SOURCE: SPPRAMSS-349 - [EN 50126-1:2017] Annex B.4]"
++ "mean operating time to first failure expectation of the operating time to first failure Note 1 to entry: See also operating time to first failure (192-05-02). Note 2 to entry: For non-repairable items, the MTTFF is also the MTTF. [SOURCE: IEC 60050-192:2015, 192-05-12]"
-- "mean operating time to first failure expectation of the operating time to first failure Note 1 to entry: See also operating time to first failure (192-05-02). Note 2 to entry: For non-repairable items, the MTTFF is also the MTTF. [SOURCE: IEC 60050-192:2015, 192-05-12]"
++ "mean time to restoration - expectation of the time to restoration deprecated: mean time to repair, mean time to recovery Note 1 to entry: IEC 60050-191:1990 (now withdrawn; replaced by IEC 60050-192:2015) defined the term ”mean time to recovery” as a synonym, but restoration and recovery are not synonyms. Note 2 to entry: MTTR = MFDT + MAD + MLD + MTD + MRT according SPPRAMSS-3539 - [EN 61703: 2016] [SOURCE: IEC 60050-192, 192-07-23, modified: Note 2 to entry added.]"
-- "mean time to restoration - expectation of the time to restoration deprecated: mean time to repair, mean time to recovery Note 1 to entry: IEC 60050-191:1990 (now withdrawn; replaced by IEC 60050-192:2015) defined the term ”mean time to recovery” as a synonym, but restoration and recovery are not synonyms. Note 2 to entry: MTTR = MFDT + MAD + MLD + MTD + MRT according SPPRAMSS-3539 - [EN 61703: 2016] [SOURCE: IEC 60050-192, 192-07-23, modified: Note 2 to entry added.]"
++ "implicit-from-entry-label: Multiple Independent Levels of Security or Safety"
++ "In 2016, the EC also asked the EU Member States to establish the so-called “National Implementation Plans” (NIPs) in which they have to describe their actions to comply with the relevant standard for ERTMS, i.e. CCS TSI 2016/919. The CCS TSI regulates the implementation of fully interoperable 'control-command and signalling' subsystems. The NIPs have to fulfil two conditions, i.e. they must cover a period of at least 15 years and they must be updated every 5 years. In addition, they have to contain the following information: (image: 1-screenshot-20230616-124455.png)"
-- "In 2016, the EC also asked the EU Member States to establish the so-called “National Implementation Plans” (NIPs) in which they have to describe their actions to comply with the relevant standard for ERTMS, i.e. CCS TSI 2016/919. The CCS TSI regulates the implementation of fully interoperable 'control-command and signalling' subsystems. The NIPs have to fulfil two conditions, i.e. they must cover a period of at least 15 years and they must be updated every 5 years. In addition, they have to contain the following information: (image: 1-screenshot-20230616-124455.png)"
++ "A device that facilitates IP data flow between devices, or restricts the flow of data, but may not directly interact with a control process. Examples of Network Components are network switches, LAN/WAN routers, firewalls, data diodes and VPN endpoints. Excluded from this definition are media converters, transceivers and bridges with no routing, switching or filtering capabilities. Such devices are not affected by this specification."
-- "An implementation of data networking functions such as switching, routing, filtering or tunneling. Examples of Network Components are network switches, LAN/WAN routers, firewalls, data diodes and VPN endpoints. Excluded are from this definition are media converters, transceivers and bridges with no routing, switching or filtering capabilities."
++ "Non-Repudiation: ability to prove the occurrence of a claimed event or action and its originating entities (source: ISO 27000-2018 )"
-- "Non-Repudiation: ability to prove the occurrence of a claimed event or action and its originating entities (source: ISO 27000-2018 )"
++ "The database for Notified National Rules. Has been replaced by SRD: Single Rule Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]"
-- "The database for Notified National Rules. Has been replaced by SRD: Single Rule Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]"
++ "This term represents the odometry functionality as specified in the CCS TSI 2023. According to the glossary (SUBSET-23, TSI 2023): Odometry is the process of measuring the train’s movement along the track. Used for speed measurement and distance measurement."
-- "This term represents the odometry functionality as specified in the CCS TSI 2023. According to the glossary (SUBSET-23, TSI 2023): Odometry is the process of measuring the train’s movement along the track. Used for speed measurement and distance measurement."
++ "OMS - Online Monitoring System NOTE : OMS is both trackside and on-board."
-- "OMS - Online Monitoring System NOTE : OMS is both trackside and on-board."
++ "The operating state describes the current state of production: * how trains move * where trains are * which route is set in control system * status of assets This information is based on inputs from control systems."
-- "The operating state describes the current state of production: * how trains move * where trains are * which route is set in control system * status of assets This information is based on inputs from control systems."
++ "operating time accumulated from the first use, or from restoration, until failure Note 1 to entry: See also operating time (192-02-05) SPPRAMSS-4080 - operating time . [SOURCE: IEC 60050-192:2015, 192-05-01]"
-- "operating time accumulated from the first use, or from restoration, until failure Note 1 to entry: See also operating time (192-02-05) SPPRAMSS-4080 - operating time . [SOURCE: IEC 60050-192:2015, 192-05-01]"
++ "Time interval for which an item is in an operating state Note 1 to entry: The duration of operating time may be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc., and the units should always be clearly stated. [SOURCE: IEC 60050-192:2015, 192-02-05]"
-- "Time interval for which an item is in an operating state Note 1 to entry: The duration of operating time may be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc., and the units should always be clearly stated. [SOURCE: IEC 60050-192:2015, 192-02-05]"
++ "Operational concepts (How system should function)"
++ "Operational epics refer to large-scale initiatives or projects that are focused on improving the operational aspects of a business or organization. Unlike user epics, which typically address customer or user needs, operational epics are aimed at enhancing internal processes, systems, or infrastructure to optimize efficiency, productivity, and overall performance. Operational epics often involve cross-functional collaboration and may span multiple departments or teams within an organization. They are typically strategic in nature and aligned with the overall goals and objectives of the organization. Examples of operational epics could include implementing a new supply chain management system, revamping the customer support process, or optimizing the IT infrastructure to improve data security and accessibility. The use of epics in operational contexts helps break down complex initiatives into manageable units, allowing for better planning, resource allocation, and tracking of progress. By focusing on operational improvements, organizations can streamline their workflows, reduce costs, and enhance the overall effectiveness of their operations."
-- "Operational epics refer to large-scale initiatives or projects that are focused on improving the operational aspects of a business or organization. Unlike user epics, which typically address customer or user needs, operational epics are aimed at enhancing internal processes, systems, or infrastructure to optimize efficiency, productivity, and overall performance. Operational epics often involve cross-functional collaboration and may span multiple departments or teams within an organization. They are typically strategic in nature and aligned with the overall goals and objectives of the organization. Examples of operational epics could include implementing a new supply chain management system, revamping the customer support process, or optimizing the IT infrastructure to improve data security and accessibility. The use of epics in operational contexts helps break down complex initiatives into manageable units, allowing for better planning, resource allocation, and tracking of progress. By focusing on operational improvements, organizations can streamline their workflows, reduce costs, and enhance the overall effectiveness of their operations."
++ "SPT2OD-4977 - Missing cross-reference refers to the complete operational journey planned from one initial position on the railway network to a final position on the railway network. Most commonly this can be exemplified by the commercial journey starting at a central station, passing through many regional stations before ending at a final central station somewhere else on the railway network. One SPT2OD-4977 - Missing cross-reference may have many SPT2OD-4978 - Missing cross-reference and may be assigned to the responsibility of one or more SPT2OD-4967 - Missing cross-reference along the way."
-- "SPT2OD-4977 - Missing cross-reference refers to the complete operational journey planned from one initial position on the railway network to a final position on the railway network. Most commonly this can be exemplified by the commercial journey starting at a central station, passing through many regional stations before ending at a final central station somewhere else on the railway network. One SPT2OD-4977 - Missing cross-reference may have many SPT2OD-4978 - Missing cross-reference and may be assigned to the responsibility of one or more SPT2OD-4967 - Missing cross-reference along the way."
++ "Operational requirements are requirements which an operational procedure and its design has to fulfil."
-- "Something a process design has to fulfil."
++ "Properties of a given piece of track, impacting operations. Non-exhaustive list: * Air tightness * Axle load/Line category * Load type restrictions (e.g. hazardous material, passenger) * Loading gauge restrictions * Low adhesion * Switchable neutral section * Operating regime * Driveability Hint: This includes a track closure. The driveability parameter can be train (category) specific. * Driving on sight * Local Operation Area Hint: A Local Operation Area is meant to be the technical possibility to implement a Temporary Shunting Area via this restriction toolset. * Modes/accepted GoA level * Speed Hint: The Static Speed Profile is not subject of this scenario, only temporary restrictions. * Overhead current restrictions (including restart of operations after a blackout, with not enough power for all trains to start simultaneously) * Prohibitions of usage of brakes * Sanding * Traction type * Wind vulnerability The following track properties are considered to be static properties, which will not be managed with dynamic restrictions, but via the static infrastructure data (Digital Map/Digital Register): * Big Metal Masses * Non-stopping area * Powerless area * Radio hole * Tunnel Stopping Are"
-- "Properties of a given piece of track, impacting operations. Non-exhaustive list: * Air tightness * Axle load/Line category * Load type restrictions (e.g. hazardous material, passenger) * Loading gauge restrictions * Low adhesion * Switchable neutral section * Operating regime * Driveability Hint: This includes a track closure. The driveability parameter can be train (category) specific. * Driving on sight * Local Operation Area Hint: A Local Operation Area is meant to be the technical possibility to implement a Temporary Shunting Area via this restriction toolset. * Modes/accepted GoA level * Speed Hint: The Static Speed Profile is not subject of this scenario, only temporary restrictions. * Overhead current restrictions (including restart of operations after a blackout, with not enough power for all trains to start simultaneously) * Prohibitions of usage of brakes * Sanding * Traction type * Wind vulnerability The following track properties are considered to be static properties, which will not be managed with dynamic restrictions, but via the static infrastructure data (Digital Map/Digital Register): * Big Metal Masses * Non-stopping area * Powerless area * Radio hole * Tunnel Stopping Are"
++ "Performance is the ability of all technical and operational functions, in a specific operational context, to deliver a pre-defined and agreed level of service of the system and/or vehicle in operation. With the addition (and further clarification) that: The minimum level of performance is determined and influenced by technical and operational aspects on system, vehicle and operational level, such as but not limited to: reliability, availability, maintainability, safety, security, human factors, quality, mission profile, environment, environmental conditions and laws and regulations. This means the scope and boundaries (span of control) of performance need to be defined clearly. This also stresses why the inclusion of the principles of the RAM Policy to the ERJU activities for PRAMS, is of high importance."
-- "Performance is the ability of all technical and operational functions, in a specific operational context, to deliver a pre-defined and agreed level of service of the system and/or vehicle in operation. With the addition (and further clarification) that: The minimum level of performance is determined and influenced by technical and operational aspects on system, vehicle and operational level, such as but not limited to: reliability, availability, maintainability, safety, security, human factors, quality, mission profile, environment, environmental conditions and laws and regulations. This means the scope and boundaries (span of control) of performance need to be defined clearly. This also stresses why the inclusion of the principles of the RAM Policy to the ERJU activities for PRAMS, is of high importance."
. NOTE 2 From a theoretical point of view, the PFH is the average of the unconditional failure intensity, also called failure frequency, and which is generally designated w(t). It should not be confused with a failure rate (see Annex B of IEC 61508-6). NOTE 3 When the E/E/PE safety-related system is the ultimate safety layer, the PFH should be calculated from its unreliability F(T)=1-R(t) (see “failure rate” above). When it is not the ultimate safety-related system its PFH should be calculated from its unavailability U(t) (see PFD above). PFH approximations are given by F(T)/T and 1/MTTF in the first case and 1/MTBF in the second case. NOTE 4 When the E/E/PE safety-related system implies only quickly repaired revealed failures then an asymptotic failure rate λas is quickly reached. It provides an estimate of the PFH. [EN 61508-4:2010 - §3.6.19]
average frequency of a dangerous failure per hour average frequency of a dangerous failure of an E/E/PE safety related system to perform the specified safety function over a given period of time NOTE 1 The term “probability of dangerous failure per hour” is not used in this standard but the acronym PFH has been retained but when it is used it means “average frequency of dangerous failure [h]". NOTE 2 From a theoretical point of view, the PFH is the average of the unconditional failure intensity, also called failure frequency, and which is generally designated w(t). It should not be confused with a failure rate (see Annex B of IEC 61508-6). NOTE 3 When the E/E/PE safety-related system is the ultimate safety layer, the PFH should be calculated from its unreliability F(T)=1-R(t) (see “failure rate” above). When it is not the ultimate safety-related system its PFH should be calculated from its unavailability U(t) (see PFD above). PFH approximations are given by F(T)/T and 1/MTTF in the first case and 1/MTBF in the second case. NOTE 4 When the E/E/PE safety-related system implies only quickly repaired revealed failures then an asymptotic failure rate λas is quickly reached. It provides an estimate of the PFH. [EN 61508-4:2010 - §3.6.19]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:PFH_lexConcept_3 ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]", -- "probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]" :diff_0797 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:PFH_lexConcept_3 ; ordv:predicate skos:definition ; ordv:changes [
probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]
] . :diff_0798 a :Object_addition ; ordv:entity lex_sp-defs-241203:PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_7 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:PLATEAU_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0799 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:PLATEAU_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A Plateau is a consistent requirement subset of the System Pillar Reference Architecture (SPRA) to be defined by the System Pillar domains. It can be used for market tenders in a specific timeframe and is recommended by and agreed across the sector. In the context of system engineering, a "plateau" refers to a distinct stage or phase within the system development lifecycle (SDLC) where progress or development remains relatively stable or flat for a period of time. It is characterized by a temporary pause or leveling off in the advancement or evolution of the system being developed.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:PLATEAU_lexConcept_2 ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0800 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:PLATEAU_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
In the context of system engineering, a "plateau" refers to a distinct stage or phase within the system development lifecycle (SDLC) where progress or development remains relatively stable or flat for a period of time. It is characterized by a temporary pause or leveling off in the advancement or evolution of the system being developed. During a plateau, the system or project may have reached a certain level of functionality, maturity, or completion. It can be seen as a natural phase in the development process, where the initial rapid progress slows down, and further enhancements or major changes are temporarily put on hold. This can occur for various reasons, such as: * Technical Stability: The system has achieved a stable and functioning state, meeting the primary objectives or requirements defined for that particular stage of development. The focus during this phase may shift towards fine-tuning, optimization, and bug fixing. * Resource Allocation: The allocation of resources, including personnel, time, and budget, may be temporarily redirected to other areas of priority. This can result in a pause in major advancements for the system on the plateau. * Stakeholder Evaluation: Stakeholders may require time to evaluate and provide feedback on the current state of the system before proceeding to the next phase. This evaluation period can lead to a plateau in development activities. * Planning and Preparation: The system engineering team may use the plateau phase to plan and prepare for the next stage of development. This includes conducting feasibility studies, conducting risk assessments, gathering requirements, or developing a roadmap for future enhancements or releases. While plateaus can be a temporary slowdown in the system development process, they can also provide opportunities for reflection, evaluation, and strategic decision-making. During this phase, system engineers and stakeholders can assess the current state of the system, address any outstanding issues or challenges, and plan for future iterations or developments. It's important for system engineers to effectively manage plateaus by maintaining clear communication with stakeholders, ensuring proper documentation, and utilizing the time and resources available to refine and improve the system before progressing to the next stage of development.
] . :diff_0801 a :Object_addition ; ordv:entity lex_sp-defs-241203:POLARION--WORK--ITEM--OF--TYPE--REFERENCE_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:PROCESS--FRAMEWORK_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A process framework refers to a structured and systematic approach for designing, documenting, and managing processes within an organisation for a defined scope.{comment:402}", -- "A process framework refers to a structured and systematic approach for designing, documenting, and managing processes within an organisation for a defined scope." :diff_0802 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:PROCESS--FRAMEWORK_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A process framework refers to a structured and systematic approach for designing, documenting, and managing processes within an organisation for a defined scope.{comment:402}
A process framework refers to a structured and systematic approach for designing, documenting, and managing processes within an organisation for a defined scope.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:PROCESS-SYSTEM--HARMONISATION--DEPENDENCY_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => **++ "The process-system harmonisation dependency decribes the fact, that in the highly automated CCS processes, which form a mixed sequence of actor actions and system function activation, the integration of a single not harmonized process action or a single not harmonized functional system behaiour already leads to a non harmonized system behaviour demanding for non harmonized operational process steps. Or in other words: A specific process depends on a specific system functionality and vice versa. Therefore harmonising one side in a specific way is only possible by harmonising the other side in a specific way. (image: 2-diagram_20240622-2035.38937.mxg.svg)", **-- "The process-system harmonisation dependency decribes the fact, that in the highly automated CCS processes, which form a mixed sequence of actor actions and system function activation, the integration of a single not harmonized process action or a single not harmonized functional system behaiour already leads to a non harmonized system behaviour demanding for non harmonized operational process steps. Or in other words: A specific process depends on a specific system functionality and vice versa. Therefore harmonising one side in a specific way is only possible by harmonising the other side in a specific way. (image: 2-diagram_20240622-2035.38937.mxg.svg)" :diff_0803 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:PROCESS-SYSTEM--HARMONISATION--DEPENDENCY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The process-system harmonisation dependency decribes the fact, that in the highly automated CCS processes, which form a mixed sequence of actor actions and system function activation, the integration of a single not harmonized process action or a single not harmonized functional system behaiour already leads to a non harmonized system behaviour demanding for non harmonized operational process steps. Or in other words: A specific process depends on a specific system functionality and vice versa. Therefore harmonising one side in a specific way is only possible by harmonising the other side in a specific way. (image: 2-diagram_20240622-2035.38937.mxg.svg)
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:PROCESS_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Set of interrelated or interacting activities that use inputs to deliver an intended result. * Processes require a purpose and outcome, all processes have at least one activity. * A process defines “WHAT” is to be done, without specifying “HOW” each task is performed.", -- "Set of interrelated or interacting activities that use inputs to deliver an intended result. * Processes require a purpose and outcome, all processes have at least one activity. * A process defines “WHAT” is to be done, without specifying “HOW” each task is performed." :diff_0804 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:PROCESS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Set of interrelated or interacting activities that use inputs to deliver an intended result. * Processes require a purpose and outcome, all processes have at least one activity. * A process defines “WHAT” is to be done, without specifying “HOW” each task is performed.
] . :diff_0805 a :Object_addition ; ordv:entity lex_sp-defs-241203:PRODUCT--DATA--MANAGEMENT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RAILWAY--HAZARD_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Top level hazard at railway level that can be caused by: * an operational scenario/procedure failure and/or * a system function/component failure. Each railway hazard shall be traced with at least: * One SPPRAMSS-7602 - Operational Hazard, * one SPPRAMSS-7603 - System Hazard", -- "Top level hazard at railway level that can be caused by: * an operational scenario/procedure failure and/or * a system function/component failure. Each railway hazard shall be traced with at least: * One SPPRAMSS-7602 - Operational Hazard, * one SPPRAMSS-7603 - System Hazard" :diff_0806 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RAILWAY--HAZARD_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Top level hazard at railway level that can be caused by: * an operational scenario/procedure failure and/or * a system function/component failure. Each railway hazard shall be traced with at least: * One SPPRAMSS-7602 - Operational Hazard, * one SPPRAMSS-7603 - System Hazard
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RAILWAY--REQUIREMENT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Railway requirements are epics, visions, needs or user stories coming from stakeholders as their concrete vision (who, what, why). It can be formulated in a few sentences and has not a strict form criteria. These can be translated to precise operational requirements during analysis processes in case they describe operational epics for the business target picture of an operational area (like CCS or Energy). The can be freely formulated but should follow the writing patterns of epics and user stories. They should be specific enough to be assigned to exactly one System Pillar task.", -- "Epic/User Story coming from stakeholders as their concrete vision. Who, what, why. Not strict form criteria. Formulated in 3-5 sentences. Is translated to precise operational requirements during the design process." :diff_0807 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RAILWAY--REQUIREMENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Railway requirements are epics, visions, needs or user stories coming from stakeholders as their concrete vision (who, what, why). It can be formulated in a few sentences and has not a strict form criteria. These can be translated to precise operational requirements during analysis processes in case they describe operational epics for the business target picture of an operational area (like CCS or Energy). The can be freely formulated but should follow the writing patterns of epics and user stories. They should be specific enough to be assigned to exactly one System Pillar task.
Epic/User Story coming from stakeholders as their concrete vision. Who, what, why. Not strict form criteria. Formulated in 3-5 sentences. Is translated to precise operational requirements during the design process.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RBD_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "reliability block diagram logical, graphical representation of a system showing how reliability of its sub items (represented by blocks) and combinations thereof, affect reliability of the system [SOURCE: IEC 60050-192:2015, 192-11-03]", -- "reliability block diagram logical, graphical representation of a system showing how reliability of its sub items (represented by blocks) and combinations thereof, affect reliability of the system [SOURCE: IEC 60050-192:2015, 192-11-03]" :diff_0808 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RBD_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
reliability block diagram logical, graphical representation of a system showing how reliability of its sub items (represented by blocks) and combinations thereof, affect reliability of the system [SOURCE: IEC 60050-192:2015, 192-11-03]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:READER--CONTROLLER_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Reader Controller The Reader Controller manages states and failures of the Biometric Readerand/or the RFID Reader.", -- "Reader Controller The Reader Controller manages states and failures of the Biometric Readerand/or the RFID Reader." :diff_0809 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:READER--CONTROLLER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Reader Controller The Reader Controller manages states and failures of the Biometric Readerand/or the RFID Reader.
] . :diff_0810 a :Object_addition ; ordv:entity lex_sp-defs-241203:REGISTER--OF--INFRASTRUCTURE_lexConcept . :diff_0811 a :Object_addition ; ordv:entity lex_sp-defs-241203:REGISTER--OF--INFRASTRUCTURE_lexConcept_2 . :diff_0812 a :Object_addition ; ordv:entity lex_sp-defs-241203:REGISTER--OF--INFRASTRUCTURE_lexConcept_3 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RELATIVE--POSITION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Train front end position expressed with a distance from a reference location in a 1D reference frame.", -- "The Train front end position expressed with a distance from a reference location in a 1D reference frame." :diff_0813 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RELATIVE--POSITION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Train front end position expressed with a distance from a reference location in a 1D reference frame.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RELIABILITY--%3COF--AN--ITEM%3E_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - [EN 50126-1:2017]", -- "Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - [EN 50126-1:2017]" :diff_0814 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RELIABILITY--%3COF--AN--ITEM%3E_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - [EN 50126-1:2017]
] . :diff_0815 a :Object_addition ; ordv:entity lex_sp-defs-241203:RELIABILITY--CENTRED--MAINTENANCE_lexConcept . :diff_0816 a :Object_addition ; ordv:entity lex_sp-defs-241203:REQUIREMENT--SET_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RFID--READER_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "RFID Reader Radio Frequency Identification (RFID) refers to a wireless system comprised of two components: tags and readers. The reader is a device that has one or more antennas that emit radio waves and receive signals back from the RFID tag. This reader permits the authentication of the actor.", -- "RFID Reader Radio Frequency Identification (RFID) refers to a wireless system comprised of two components: tags and readers. The reader is a device that has one or more antennas that emit radio waves and receive signals back from the RFID tag. This reader permits the authentication of the actor." :diff_0817 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RFID--READER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
RFID Reader Radio Frequency Identification (RFID) refers to a wireless system comprised of two components: tags and readers. The reader is a device that has one or more antennas that emit radio waves and receive signals back from the RFID tag. This reader permits the authentication of the actor.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RISK--%3COF--A--HAZARD%3E_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0818 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RISK--%3COF--A--HAZARD%3E_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
combination of the probability of occurrence of accident and the severity of that accident Note 1 to entry: In French, the term “risque” also denotes the potential source of harm, in English “hazard” (see 903-01-02) SPPRAMSS-4044 - Hazard . [SOURCE: IEC 60050-903:2013, 903-01-07, modified — <of a hazard> has been added and "harm" has been replaced with "accident"]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RISK--ANALYSIS_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "systematic use of available information to identify hazards and to estimate the risk [Source: IEC 60050-903:2013, 903-01-08]", -- "systematic use of available information to identify hazards and to estimate the risk [Source: IEC 60050-903:2013, 903-01-08]" :diff_0819 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RISK--ANALYSIS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
systematic use of available information to identify hazards and to estimate the risk [Source: IEC 60050-903:2013, 903-01-08]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RISK--ASSESSMENT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "overall process comprising a risk analysis and a risk evaluation [Source: IEC 60050-903:2013, 903-01-10]", -- "overall process comprising a risk analysis and a risk evaluation [Source: IEC 60050-903:2013, 903-01-10]" :diff_0820 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RISK--ASSESSMENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
overall process comprising a risk analysis and a risk evaluation [Source: IEC 60050-903:2013, 903-01-10]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:RISK--EVALUATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "procedure based on the risk analysis to determine whether the tolerable risk has been achieved [Source: IEC 60050-903:2013, 903-01-09]", -- "procedure based on the risk analysis to determine whether the tolerable risk has been achieved [Source: IEC 60050-903:2013, 903-01-09]" :diff_0821 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:RISK--EVALUATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
procedure based on the risk analysis to determine whether the tolerable risk has been achieved [Source: IEC 60050-903:2013, 903-01-09]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:ROLL--AWAY_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "An unintended and non-powered movement of the train in a direction, which conflicts with the current position of the direction controller in the active desk. Reference: Glossary of Terms and Abbreviation. SUBSET-023. Issue 4.0.0", -- "An unintended and non-powered movement of the train in a direction, which conflicts with the current position of the direction controller in the active desk. Reference: Glossary of Terms and Abbreviation. SUBSET-023. Issue 4.0.0" :diff_0822 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:ROLL--AWAY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
An unintended and non-powered movement of the train in a direction, which conflicts with the current position of the direction controller in the active desk. Reference: Glossary of Terms and Abbreviation. SUBSET-023. Issue 4.0.0
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SAFE--STATE--_821-12-49_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "condition which continues to preserve safety [SOURCE: IEC 62425:2007, 3.1.42]", -- "condition which continues to preserve safety [SOURCE: IEC 62425:2007, 3.1.42]" :diff_0823 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SAFE--STATE--_821-12-49_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
condition which continues to preserve safety [SOURCE: IEC 62425:2007, 3.1.42]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SAFE--STATE_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "condition which continues to preserve safety [Source: IEC 60050-821, 821-12-49]", -- "condition which continues to preserve safety [Source: IEC 60050-821, 821-12-49]" :diff_0824 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SAFE--STATE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
condition which continues to preserve safety [Source: IEC 60050-821, 821-12-49]
] . :diff_0825 a :Object_addition ; ordv:entity lex_sp-defs-241203:SAFE--TRAIN--EXTENT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SAFETY--ENVIRONMENT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Safety Environment refers to the software needed to provide the services of the Safety Layer in one single Compartment. Previous definition: The Safety Environment refers to all Safety Environment Tasks needed for a Functional System.", -- "The Safety Environment refers to the software needed to provide the services of the Safety Layer in one single Compartment. Previous definition: The Safety Environment refers to all Safety Environment Tasks needed for a Functional System." :diff_0826 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SAFETY--ENVIRONMENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Safety Environment refers to the software needed to provide the services of the Safety Layer in one single Compartment. Previous definition: The Safety Environment refers to all Safety Environment Tasks needed for a Functional System.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SAFETY--FRAMEWORK_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Safety Framework refers to all Safety Environment Replicas needed for a Functional System. Previous definition: new term", -- "The Safety Framework refers to all Safety Environment Replicas needed for a Functional System. Previous definition: new term" :diff_0827 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SAFETY--FRAMEWORK_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Safety Framework refers to all Safety Environment Replicas needed for a Functional System. Previous definition: new term
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SCENARIO_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Scenarios are diagrams that describe the interactions between structural elements by focusing on the exchange of information in a given context and with a time axis. They allow the ordering of information sequences and behaviours of structural elements, but can also be used as a basis for specification tests. Finally, their constitution, from top to bottom and from right to left, makes it easier to understand the elements described, even for people unfamiliar with an MBSE approach. Scenarios can be linked to sequence diagrams (SysML wording). Scenarios are suitable to be used for the following model elements: * Regarding abstractions: operational analysis, system analysis, logical architecture, physical architecture * Regarding structural entities: system, system element, logical component, interface layer component * Regarding functions: behaviour definition of function (how functions of structural entities exchange data through exchange items) * Regarding other behavioural aspects: pre and postconditions and invariants as start to end conditions as well as state invariants of the scenario * Regarding purpose: represent, at least, one complete sequence of functional exchanges on a time axis Scenarios are often used with a capability perspective depending on the implementation conditions (pre and post-conditions) and describing a specific context at the system, logical and physical structural elements. For example: * Visualise an initial sequence to achieve a system capability's outcome. * Visualise interactions between entities to achieve the system capability with an acceptable level of risk. * Visualise system black-box behaviour or system interaction behaviour with actors.", -- "Scenarios are diagrams that describe the interactions between structural elements by focusing on the exchange of information in a given context and with a time axis. They allow the ordering of information sequences and behaviours of structural elements, but can also be used as a basis for specification tests. Finally, their constitution, from top to bottom and from right to left, makes it easier to understand the elements described, even for people unfamiliar with an MBSE approach. Scenarios can be linked to sequence diagrams (SysML wording). Scope: Scenarios are suitable to be used for the following model elements: * Regarding abstractions: operational analysis, system analysis, logical architecture, physical architecture * Regarding structural entities: system, system element, logical component, interface layer component * Regarding functions: behaviour definition of function (how functions of structural entities exchange data through exchange items) * Regarding other behavioural aspects: pre and postconditions and invariants as start to end conditions as well as state invariants of the scenario * Regarding purpose: represent, at least, one complete sequence of functional exchanges on a time axis Scenarios are often used with a capability perspective depending on the implementation conditions (pre and post-conditions) and describing a specific context at the system, logical and physical structural elements. For example: * Visualise an initial sequence to achieve a system capability's outcome. * Visualise interactions between entities to achieve the system capability with an acceptable level of risk. * Visualise system black-box behaviour or system interaction behaviour with actors." :diff_0828 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SCENARIO_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Scenarios are diagrams that describe the interactions between structural elements by focusing on the exchange of information in a given context and with a time axis. They allow the ordering of information sequences and behaviours of structural elements, but can also be used as a basis for specification tests. Finally, their constitution, from top to bottom and from right to left, makes it easier to understand the elements described, even for people unfamiliar with an MBSE approach. Scenarios can be linked to sequence diagrams (SysML wording). Scenarios are suitable to be used for the following model elements: * Regarding abstractions: operational analysis, system analysis, logical architecture, physical architecture * Regarding structural entities: system, system element, logical component, interface layer component * Regarding functions: behaviour definition of function (how functions of structural entities exchange data through exchange items) * Regarding other behavioural aspects: pre and postconditions and invariants as start to end conditions as well as state invariants of the scenario * Regarding purpose: represent, at least, one complete sequence of functional exchanges on a time axis Scenarios are often used with a capability perspective depending on the implementation conditions (pre and post-conditions) and describing a specific context at the system, logical and physical structural elements. For example: * Visualise an initial sequence to achieve a system capability's outcome. * Visualise interactions between entities to achieve the system capability with an acceptable level of risk. * Visualise system black-box behaviour or system interaction behaviour with actors.
Scenarios are diagrams that describe the interactions between structural elements by focusing on the exchange of information in a given context and with a time axis. They allow the ordering of information sequences and behaviours of structural elements, but can also be used as a basis for specification tests. Finally, their constitution, from top to bottom and from right to left, makes it easier to understand the elements described, even for people unfamiliar with an MBSE approach. Scenarios can be linked to sequence diagrams (SysML wording). Scope: Scenarios are suitable to be used for the following model elements: * Regarding abstractions: operational analysis, system analysis, logical architecture, physical architecture * Regarding structural entities: system, system element, logical component, interface layer component * Regarding functions: behaviour definition of function (how functions of structural entities exchange data through exchange items) * Regarding other behavioural aspects: pre and postconditions and invariants as start to end conditions as well as state invariants of the scenario * Regarding purpose: represent, at least, one complete sequence of functional exchanges on a time axis Scenarios are often used with a capability perspective depending on the implementation conditions (pre and post-conditions) and describing a specific context at the system, logical and physical structural elements. For example: * Visualise an initial sequence to achieve a system capability's outcome. * Visualise interactions between entities to achieve the system capability with an acceptable level of risk. * Visualise system black-box behaviour or system interaction behaviour with actors.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SECRAC_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "security-related application condition [SOURCE: CLC/TS 50701:2023]", -- "security-related application condition [SOURCE: CLC/TS 50701:2023]" :diff_0829 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SECRAC_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
security-related application condition [SOURCE: CLC/TS 50701:2023]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SECURE--COMMUNICATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "defines an integrity-protected and optionally encrypted channel between two entities. Security is achieved by using TLS 1.3 or OPC UA Secure Conversation.", -- "defining an encrypted channel between two entities using TLS1.3" :diff_0830 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SECURE--COMMUNICATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
defines an integrity-protected and optionally encrypted channel between two entities. Security is achieved by using TLS 1.3 or OPC UA Secure Conversation.
defining an encrypted channel between two entities using TLS1.3
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SECURE--COMPONENT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "An implementation, as part of an industrial automation control system, which comprises system components, such as host devices, embedded devices, network devices or software applications on a host device, that implement 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.", -- "An implementation, as part of the rail automation system, which comprises system components, such as host devices, embedded devices, network devices or software applications, that implement 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…)" :diff_0831 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SECURE--COMPONENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
An implementation, as part of an industrial automation control system, which comprises system components, such as host devices, embedded devices, network devices or software applications on a host device, that implement 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.
An implementation, as part of the rail automation system, which comprises system components, such as host devices, embedded devices, network devices or software applications, that implement 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…)
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SEGMENT--PROFILE_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A Segment Profile is a one-dimensional object that describes a single and consecutive section of track and corresponds to the Track Centreline of that section of track. A Segment Profile has a Start Point and an End Point, which correspond to the boundary points of the section of Track Centreline of that Segment Profile. A Segment Profile defines a set of static infrastructure data required by different on-board applications like ATO, Perception, Localisation, APM. {comment:2} The Segment Profile is part of Application Configuration Data. These data are derived from Infrastructure Data according to the interface data structure requirements of the consumers.", -- "A Segment Profile is a one-dimensional object that describes a single and consecutive section of track and corresponds to the Track Centreline of that section of track. A Segment Profile has a Start Point and an End Point, which correspond to the boundary points of the section of Track Centreline of that Segment Profile. A Segment Profile defines a set of static infrastructure data required by the ATO on-board to compute the Operational Speed Profile. The Segment Profile is part of Trackside Configuration Data. These data are derived from Map Data according to the data structure as defined by ATO over ETCS Subset 126." :diff_0832 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SEGMENT--PROFILE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A Segment Profile is a one-dimensional object that describes a single and consecutive section of track and corresponds to the Track Centreline of that section of track. A Segment Profile has a Start Point and an End Point, which correspond to the boundary points of the section of Track Centreline of that Segment Profile. A Segment Profile defines a set of static infrastructure data required by different on-board applications like ATO, Perception, Localisation, APM. {comment:2} The Segment Profile is part of Application Configuration Data. These data are derived from Infrastructure Data according to the interface data structure requirements of the consumers.
A Segment Profile is a one-dimensional object that describes a single and consecutive section of track and corresponds to the Track Centreline of that section of track. A Segment Profile has a Start Point and an End Point, which correspond to the boundary points of the section of Track Centreline of that Segment Profile. A Segment Profile defines a set of static infrastructure data required by the ATO on-board to compute the Operational Speed Profile. The Segment Profile is part of Trackside Configuration Data. These data are derived from Map Data according to the data structure as defined by ATO over ETCS Subset 126.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SEMP--LINK--RULE_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Defines how certain Polarion workitems shall be linked. See: SPPROCESS/SEMP Annex D Processes/SEMP Link Rules overview", -- "Defines how certain Polarion workitems shall be linked. See: SEMP Link Rules overview" :diff_0833 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SEMP--LINK--RULE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Defines how certain Polarion workitems shall be linked. See: SPPROCESS/SEMP Annex D Processes/SEMP Link Rules overview
Defines how certain Polarion workitems shall be linked. See: SEMP Link Rules overview
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SERIOUS--ACCIDENT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "‘serious accident’ means any train collision or derailment of trains resulting in the death of at least one person or serious injuries to five or more persons or extensive damage to rolling stock, the infrastructure or the environment, and any other accident with the same consequences which has an obvious impact on railway safety regulation or the management of safety; ‘extensive damage’ means damage that can be immediately assessed by the investigating body to cost at least EUR 2 million in total; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (12) ]", -- "‘serious accident’ means any train collision or derailment of trains resulting in the death of at least one person or serious injuries to five or more persons or extensive damage to rolling stock, the infrastructure or the environment, and any other accident with the same consequences which has an obvious impact on railway safety regulation or the management of safety; ‘extensive damage’ means damage that can be immediately assessed by the investigating body to cost at least EUR 2 million in total; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (12) ]" :diff_0834 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SERIOUS--ACCIDENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
‘serious accident’ means any train collision or derailment of trains resulting in the death of at least one person or serious injuries to five or more persons or extensive damage to rolling stock, the infrastructure or the environment, and any other accident with the same consequences which has an obvious impact on railway safety regulation or the management of safety; ‘extensive damage’ means damage that can be immediately assessed by the investigating body to cost at least EUR 2 million in total; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (12) ]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SERVICE--FUNCTION--CONFIGURATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The Service Function Configuration (SFC) is the implementation of the Configuration Management System. The SFC is a central location technical system that is responsible for managing the BuildingBlock Configurations. Each BuildingBlock deployment is managed by exactly one SFC.", -- "The Service Function Configuration (SFC) is the implementation of the Configuration Management System. The SFC is a central location technical system that is responsible for managing the BuildingBlock Configurations. Each BuildingBlock deployment is managed by exactly one SFC." :diff_0835 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SERVICE--FUNCTION--CONFIGURATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The Service Function Configuration (SFC) is the implementation of the Configuration Management System. The SFC is a central location technical system that is responsible for managing the BuildingBlock Configurations. Each BuildingBlock deployment is managed by exactly one SFC.
] . :diff_0836 a :Object_addition ; ordv:entity lex_sp-defs-241203:SHARED--CYBERSECURITY--SERVICES--SCS_lexConcept . :diff_0837 a :Object_addition ; ordv:entity lex_sp-defs-241203:SHARED--SECURITY--SERVICE_lexConcept . :diff_0838 a :Object_addition ; ordv:entity lex_sp-defs-241203:SHOP--REPLACEABLE--UNIT_lexConcept . :diff_0839 a :Object_addition ; ordv:entity lex_sp-defs-241203:SIGNALLER--DEFINITION_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SIL2--HAZARD--MITIGATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Safety requirement regarding activities for lowering the effect of a hazard. It reduces the damage to people, property, and the environment by lowering the frequency, damping the consequences. Unlike a safety invariant, a mitigation may not be enforced in a predictable fashion, for instance because it addresses hazards that cannot be influenced by they system themselves. For instance, trespassers on the track cannot be influenced by the railway system. A mitigation can be a realized by * fault detection (hazard will be detected), typically this needs additional activities * failure reaction (after detection the hazard will be excluded), typically this needs additional activities * SRAC safety application condition (hazard will be avoided principly)", -- "Safety requirement regarding activities for lowering the effect of a hazard. It reduces the damage to people, property, and the environment by lowering the frequency, damping the consequences. Unlike a safety invariant, a mitigation may not be enforced in a predictable fashion, for instance because it addresses hazards that cannot be influenced by they system themselves. For instance, trespassers on the track cannot be influenced by the railway system. A mitigation can be a realized by * fault detection (hazard will be detected), typically this needs additional activities * failure reaction (after detection the hazard will be excluded), typically this needs additional activities * SRAC safety application condition (hazard will be avoided principly)" :diff_0840 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SIL2--HAZARD--MITIGATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Safety requirement regarding activities for lowering the effect of a hazard. It reduces the damage to people, property, and the environment by lowering the frequency, damping the consequences. Unlike a safety invariant, a mitigation may not be enforced in a predictable fashion, for instance because it addresses hazards that cannot be influenced by they system themselves. For instance, trespassers on the track cannot be influenced by the railway system. A mitigation can be a realized by * fault detection (hazard will be detected), typically this needs additional activities * failure reaction (after detection the hazard will be excluded), typically this needs additional activities * SRAC safety application condition (hazard will be avoided principly)
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SIL4--SAFETY--INVARIANT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Safety invariants are safety requirements typically designed to address SIL4 hazards. Safety invariants defining conditions or properties critical to avoid such a SIL4 hazrard. The safety invariant shall be maintained true at any time during operations so that the system does not enter into a hazardous state or condition. Safety invariants shall be constantly monitored and predictably enforced during operations. * Predictably enforced means that the system shall, by design, avoid to enter conditions deviating from the invariant. The acknowledge execution principle is normally applied (e.g., a train enters a switch only after the switch move to position is acknowledged as safey finished). As such, Invariants are often used in formal methods to validate the system design. They may also be input to fault tree analysis, or other safety assessment techniques to ensure the robustness and reliability of systems towards defects. * Continuously monitored means that the invariant fulfillment shall be measured continuously or frequently enough to detect deviations early enough to mitigate them effitciently. Deviations shall lead to a immediate corrective actions to prevent accidents or failures (safety reaction).", -- "Safety invariants are safety requirements typically designed to address SIL4 hazards. Safety invariants defining conditions or properties critical to avoid such a SIL4 hazrard. The safety invariant shall be maintained true at any time during operations so that the system does not enter into a hazardous state or condition. Safety invariants shall be constantly monitored and predictably enforced during operations. * Predictably enforced means that the system shall, by design, avoid to enter conditions deviating from the invariant. The acknowledge execution principle is normally applied (e.g., a train enters a switch only after the switch move to position is acknowledged as safey finished). As such, Invariants are often used in formal methods to validate the system design. They may also be input to fault tree analysis, or other safety assessment techniques to ensure the robustness and reliability of systems towards defects. * Continuously monitored means that the invariant fulfillment shall be measured continuously or frequently enough to detect deviations early enough to mitigate them effitciently. Deviations shall lead to a immediate corrective actions to prevent accidents or failures (safety reaction)." :diff_0841 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SIL4--SAFETY--INVARIANT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Safety invariants are safety requirements typically designed to address SIL4 hazards. Safety invariants defining conditions or properties critical to avoid such a SIL4 hazrard. The safety invariant shall be maintained true at any time during operations so that the system does not enter into a hazardous state or condition. Safety invariants shall be constantly monitored and predictably enforced during operations. * Predictably enforced means that the system shall, by design, avoid to enter conditions deviating from the invariant. The acknowledge execution principle is normally applied (e.g., a train enters a switch only after the switch move to position is acknowledged as safey finished). As such, Invariants are often used in formal methods to validate the system design. They may also be input to fault tree analysis, or other safety assessment techniques to ensure the robustness and reliability of systems towards defects. * Continuously monitored means that the invariant fulfillment shall be measured continuously or frequently enough to detect deviations early enough to mitigate them effitciently. Deviations shall lead to a immediate corrective actions to prevent accidents or failures (safety reaction).
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SOFT--KEY_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Soft Key Context-dependent key which consists of a Hard Key with an associated label on the Display Area. When using a soft key technology, the driver action is done via the Hard Key adjacent to the label.", -- "Soft Key Context-dependent key which consists of a Hard Key with an associated label on the Display Area. When using a soft key technology, the driver action is done via the Hard Key adjacent to the label." :diff_0842 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SOFT--KEY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Soft Key Context-dependent key which consists of a Hard Key with an associated label on the Display Area. When using a soft key technology, the driver action is done via the Hard Key adjacent to the label.
] . :diff_0843 a :Object_addition ; ordv:entity lex_sp-defs-241203:SOFTWARE--CONFIGURATION--DATA_lexConcept . :diff_0844 a :Object_addition ; ordv:entity lex_sp-defs-241203:SPECIFIC--CONTRACT--FOR--LOT--2--OF--YEAR--X_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SRD_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Single Rules Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]", -- "Single Rules Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]" :diff_0845 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SRD_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Single Rules Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:STAKEHOLDER--NEEDS_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "These needs are taken into account for the definition of the system of interest. Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree, - Requirements proposed by any party and approved in the SP decision process according to SP governance.", -- "These needs are taken into account for the definition of the System of interest. Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree, - Requirements proposed by any party and approved in the SP decision process according to SP governance." :diff_0846 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:STAKEHOLDER--NEEDS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
These needs are taken into account for the definition of the system of interest. Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree, - Requirements proposed by any party and approved in the SP decision process according to SP governance.
These needs are taken into account for the definition of the System of interest. Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree, - Requirements proposed by any party and approved in the SP decision process according to SP governance.
] . :diff_0847 a :Object_addition ; ordv:entity lex_sp-defs-241203:STAKEHOLDER--REQUIREMENT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:STAKEHOLDER_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Individual or organisation having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations. Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers.", -- "Individual or organisation having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations. Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers." :diff_0848 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:STAKEHOLDER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Individual or organisation having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations. Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers.
] . :diff_0849 a :Object_addition ; ordv:entity lex_sp-defs-241203:STANDARDISATION--AND--TSI--INPUT--PLAN_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:STATE_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "An observable and measurable attribute used to characterise a behaviour of an entity during which some invariant condition holds. States can be applied to elements such as actors, systems or subsystems.", -- "Behavioural characteristics of the system or physical conditions imposed by the environment. States can be applied to elements such as actors and components." :diff_0850 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:STATE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
An observable and measurable attribute used to characterise a behaviour of an entity during which some invariant condition holds. States can be applied to elements such as actors, systems or subsystems.
Behavioural characteristics of the system or physical conditions imposed by the environment. States can be applied to elements such as actors and components.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:STATIC--OR--SEMI-STATIC--DATA_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Static (or semi-static) data refers to information or data that remains unchanged or constant over time. It is data that does not require frequent updates or modifications. Static data typically includes reference data, constants, configuration settings, or any other data that remains consistent throughout the operation of a system or application. This type of data is often used as a foundation or reference point for various processes or calculations within a system. Static data is generally stored in a read-only format and is not subject to frequent modifications or user interactions. This is often data that requires a homologation process before it can be applied on a system going in operation. However, it can also include data that does not require a homologation like IP-address, security patches, etc. Example of statical data: software, firmware, parametrisation file, data related to the topology stored in an interlocking, braking curves stored in the ETCS on-board, etc.", -- "Static (or semi-static) data refers to information or data that remains unchanged or constant over time. It is data that does not require frequent updates or modifications. Static data typically includes reference data, constants, configuration settings, or any other data that remains consistent throughout the operation of a system or application. This type of data is often used as a foundation or reference point for various processes or calculations within a system. Static data is generally stored in a read-only format and is not subject to frequent modifications or user interactions. This is often data that requires a homologation process before it can be applied on a system going in operation. However, it can also include data that does not require a homologation like IP-address, security patches, etc. Example of statical data: software, firmware, parametrisation file, data related to the topology stored in an interlocking, braking curves stored in the ETCS on-board, etc." :diff_0851 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:STATIC--OR--SEMI-STATIC--DATA_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Static (or semi-static) data refers to information or data that remains unchanged or constant over time. It is data that does not require frequent updates or modifications. Static data typically includes reference data, constants, configuration settings, or any other data that remains consistent throughout the operation of a system or application. This type of data is often used as a foundation or reference point for various processes or calculations within a system. Static data is generally stored in a read-only format and is not subject to frequent modifications or user interactions. This is often data that requires a homologation process before it can be applied on a system going in operation. However, it can also include data that does not require a homologation like IP-address, security patches, etc. Example of statical data: software, firmware, parametrisation file, data related to the topology stored in an interlocking, braking curves stored in the ETCS on-board, etc.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:STPA_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "System Theoretic Process Analysis [Source: J3187:202305]", -- "System Theoretic Process Analysis [Source: J3187:202305]" :diff_0852 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:STPA_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
System Theoretic Process Analysis [Source: J3187:202305]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SUPPORTING--INFORMATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Information not directly translatable into localisation information but needed to provide the desired output. This information will be used by internal ASTP processes to enable, improve, or validate localisation information.", -- "Information not directly translatable into localisation information but needed to provide the desired output. This information will be used by internal ASTP processes to enable, improve, or validate localisation information." :diff_0853 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SUPPORTING--INFORMATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Information not directly translatable into localisation information but needed to provide the desired output. This information will be used by internal ASTP processes to enable, improve, or validate localisation information.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SWITCH_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Switch Physical component which allows a selection of 2 to N states and keeps the state until its position is changed.", -- "Switch Physical component which allows a selection of 2 to N states and keeps the state until its position is changed." :diff_0854 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SWITCH_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Switch Physical component which allows a selection of 2 to N states and keeps the state until its position is changed.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SWITCH_lexConcept_3 ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Electrical switch. Closes or opens a circuit.", -- "a switch is a device that opens or closes electrical circuits." :diff_0855 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SWITCH_lexConcept_3 ; ordv:predicate skos:definition ; ordv:changes [
Electrical switch. Closes or opens a circuit.
a switch is a device that opens or closes electrical circuits.
] . :diff_0856 a :Object_addition ; ordv:entity lex_sp-defs-241203:SYNTAX_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SYSTEM--CAPABILITY_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Description of a high-level behaviour of a system and its interaction with other involved entities, which yields an observable outcome. The system capability is the system’s expected ability to provide a high-level service allowing it to carry out an operational objective. A system capability represents a system usage context. It is characterised by a set of functional chains and scenarios that it references, and which more precisely describes the conditions for performing the system functions that contribute to it. A capability can also reference a function that contributes to it by itself. A capability can use one or more other capabilities that it will reference. Although the ARCADIA method describes system capabilities from the system perspective. We have decided that a deviation from the established method is preferred for our purposes. So the system capabilities shall be written from an actor's perspective, similar to use cases. In order to have a greater distinction between capability and function and to be compatible with SysML.", -- "Description of a high-level behaviour of a system and its interaction with other involved entities, which yields an observable outcome. The system capability is the system’s expected ability to provide a high-level service allowing it to carry out an operational objective. A system capability represents a system usage context. It is characterised by a set of functional chains and scenarios that it references, and which more precisely describes the conditions for performing the system functions that contribute to it. A capability can also reference a function that contributes to it by itself. A capability can use one or more other capabilities that it will reference. Although the ARCADIA method describes system capabilities from the system perspective. We have decided that a deviation from the established method is preferred for our purposes. So the system capabilities shall be written from an actor's perspective, similar to use cases. In order to have a greater distinction between capability and function and to be compatible with SysML." :diff_0857 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SYSTEM--CAPABILITY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Description of a high-level behaviour of a system and its interaction with other involved entities, which yields an observable outcome. The system capability is the system’s expected ability to provide a high-level service allowing it to carry out an operational objective. A system capability represents a system usage context. It is characterised by a set of functional chains and scenarios that it references, and which more precisely describes the conditions for performing the system functions that contribute to it. A capability can also reference a function that contributes to it by itself. A capability can use one or more other capabilities that it will reference. Although the ARCADIA method describes system capabilities from the system perspective. We have decided that a deviation from the established method is preferred for our purposes. So the system capabilities shall be written from an actor's perspective, similar to use cases. In order to have a greater distinction between capability and function and to be compatible with SysML.
] . :diff_0858 a :Object_addition ; ordv:entity lex_sp-defs-241203:SYSTEM--CONFIGURATION--DATA_lexConcept . :diff_0859 a :Object_addition ; ordv:entity lex_sp-defs-241203:SYSTEM--CONTEXT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SYSTEM--DEVELOPMENT--LIFE--CYCLE_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The System Development Life Cycle (SDLC) is a structured approach or methodology used in system engineering to guide the creation, deployment, and maintenance of systems. It provides a systematic framework for managing and controlling the entire process of building a system, from inception to retirement. The SDLC provides a structured approach to system development, ensuring that all necessary activities are carried out in a logical and controlled manner. It helps in managing risks, controlling costs, and delivering high-quality systems that meet stakeholder expectations.", -- "The System Development Life Cycle (SDLC) is a structured approach or methodology used in system engineering to guide the creation, deployment, and maintenance of systems. It provides a systematic framework for managing and controlling the entire process of building a system, from inception to retirement. The SDLC provides a structured approach to system development, ensuring that all necessary activities are carried out in a logical and controlled manner. It helps in managing risks, controlling costs, and delivering high-quality systems that meet stakeholder expectations." :diff_0860 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SYSTEM--DEVELOPMENT--LIFE--CYCLE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The System Development Life Cycle (SDLC) is a structured approach or methodology used in system engineering to guide the creation, deployment, and maintenance of systems. It provides a systematic framework for managing and controlling the entire process of building a system, from inception to retirement. The SDLC provides a structured approach to system development, ensuring that all necessary activities are carried out in a logical and controlled manner. It helps in managing risks, controlling costs, and delivering high-quality systems that meet stakeholder expectations.
] . :diff_0861 a :Object_addition ; ordv:entity lex_sp-defs-241203:SYSTEM--LEVELS--OF--THE--SYSTEM--PILLAR_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SYSTEM--OF--SYSTEMS_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "According to ISO 21839, a system of systems is set of systems that interact to provide a unique capability that none of the constituent systems can accomplish on its own. A system of systems in our understanding at least comprises two constituent systems. A system of systems itself can be nested as a constituent system in a larger system of systems, i.e. system of systems can span multiple levels recursively.{comment:1}", -- "According to ISO 21839, a system of systems is set of systems that interact to provide a unique capability that none of the constituent systems can accomplish on its own. A system of systems in our understanding at least comprises two constituent systems. A system of systems itself can be nested as a constituent system in a larger system of systems, i.e. system of systems can span multiple levels recursively." :diff_0862 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SYSTEM--OF--SYSTEMS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
According to ISO 21839, a system of systems is set of systems that interact to provide a unique capability that none of the constituent systems can accomplish on its own. A system of systems in our understanding at least comprises two constituent systems. A system of systems itself can be nested as a constituent system in a larger system of systems, i.e. system of systems can span multiple levels recursively.{comment:1}
According to ISO 21839, a system of systems is set of systems that interact to provide a unique capability that none of the constituent systems can accomplish on its own. A system of systems in our understanding at least comprises two constituent systems. A system of systems itself can be nested as a constituent system in a larger system of systems, i.e. system of systems can span multiple levels recursively.
] . :diff_0863 a :Object_addition ; ordv:entity lex_sp-defs-241203:SYSTEM--PILLAR--BASELINE_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SYSTEM--PILLAR--STEERING--GROUP_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "System Pillar Steering Group monitoring the progress of the System Pillar", -- "System Pillar Steering Group monitoring the progress of the System Pillar" :diff_0864 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SYSTEM--PILLAR--STEERING--GROUP_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
System Pillar Steering Group monitoring the progress of the System Pillar
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SYSTEM--PILLAR--UNIT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "System Pillar Unit Chairs the System Pillar Core Group", -- "System Pillar Unit Chairs the System Pillar Core Group" :diff_0865 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SYSTEM--PILLAR--UNIT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
System Pillar Unit Chairs the System Pillar Core Group
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SYSTEM--REQUIREMENT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "System requirements are precise functional or non-functional requirements that are derived from system analysis or system architecture. They are recursively used on system level and subsystem level, where a subsystem is specified as system.", -- "A System Requirement defines a capability of a linked system. It represents a task for designers and validators." :diff_0866 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SYSTEM--REQUIREMENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
System requirements are precise functional or non-functional requirements that are derived from system analysis or system architecture. They are recursively used on system level and subsystem level, where a subsystem is specified as system.
A System Requirement defines a capability of a linked system. It represents a task for designers and validators.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SYSTEM--UNDER--CONSIDERATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The defined scope of components and its interrelation the security analysis and security specifications are made for. The system under consideration is defined in Security Architecture. The red rectangle displays the scope. These are the components in the system under consideration (SuC).", -- "System under Consideration [SOURCE: SPPRAMSS-4697 - [EN IEC 62443-3-2:2020]]" :diff_0867 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SYSTEM--UNDER--CONSIDERATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The defined scope of components and its interrelation the security analysis and security specifications are made for. The system under consideration is defined in Security Architecture. The red rectangle displays the scope. These are the components in the system under consideration (SuC).
System under Consideration [SOURCE: SPPRAMSS-4697 - [EN IEC 62443-3-2:2020]]
] . :diff_0868 a :Object_addition ; ordv:entity lex_sp-defs-241203:SYSTEM--UNDER--CONSIDERATION_lexConcept_2 . :diff_0869 a :Object_addition ; ordv:entity lex_sp-defs-241203:SYSTEM--UNDER--CONSIDERATION_lexConcept_3 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:SYSTEM_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Arrangement of system elements, that together exhibit a stated behaviour or meaning that the individual constituents do not. According to ISO 15288 a system is “a combination of interacting elements organised to achieve one or more stated purposes. “. In terms of this document, a system in black box view is furthermore defined by: * interfaces to actors outside the system, defining the system boundary * at least one function allocated to it * at least one capability that the system delivers as a service to the actors A system in white box view can be further refined into (exclusive or): * into a more granular systems, hence making itself to a system of systems * into subsystems on the lowest level of system of systems refinement In both cases, a system is a conceptual entity that aggregates the properties of its constituents but is not the element that defines the properties itself. A system is hence subject to the emerging properties of its constituents. Usage context definitions of term „system“: * Constituent system: according to ISO 21839, a system that forms part of a system of systems * System of interest: according to ISO 21839, a system whose life cycle or properties are under consideration in a given context", -- "Arrangement of system elements, that together exhibit a stated behaviour or meaning that the individual constituents do not. According to ISO 15288 a system is “a combination of interacting elements organised to achieve one or more stated purposes. “. In terms of this document, a system in black box view is furthermore defined by: * interfaces to actors outside the system, defining the system boundary * at least one function allocated to it * at least one capability that the system delivers as a service to the actors A system in white box view can be further refined into (exclusive or): * into a more granular systems, hence making itself to a system of systems * into subsystems on the lowest level of system of systems refinement In both cases, a system is a conceptual entity that aggregates the properties of its constituents but is not the element that defines the properties itself. A system is hence subject to the emerging properties of its constituents. Usage context definitions of term „system“: * Constituent system: according to ISO 21839, a system that forms part of a system of systems * System of interest: according to ISO 21839, a system whose life cycle or properties are under consideration in a given context" :diff_0870 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:SYSTEM_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Arrangement of system elements, that together exhibit a stated behaviour or meaning that the individual constituents do not. According to ISO 15288 a system is “a combination of interacting elements organised to achieve one or more stated purposes. “. In terms of this document, a system in black box view is furthermore defined by: * interfaces to actors outside the system, defining the system boundary * at least one function allocated to it * at least one capability that the system delivers as a service to the actors A system in white box view can be further refined into (exclusive or): * into a more granular systems, hence making itself to a system of systems * into subsystems on the lowest level of system of systems refinement In both cases, a system is a conceptual entity that aggregates the properties of its constituents but is not the element that defines the properties itself. A system is hence subject to the emerging properties of its constituents. Usage context definitions of term „system“: * Constituent system: according to ISO 21839, a system that forms part of a system of systems * System of interest: according to ISO 21839, a system whose life cycle or properties are under consideration in a given context
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TAILORING--OF--REQUIREMENT--BREAKDOWN_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "SoS engineering can go wrong (quite often) if done in an overengineered and abstract way. If every artefact is created on every System Level (e.g. 5-7 levels and types or requirements that are broken down), the workload is artificially multiplied without need, and this policy is not creating a really good work split. To avoid this, every work process uses a tailoring approach which means * “Copy” (reference) things from a higher level, if possible like they are * Break up and translate through the levels that you really need, and not more. * Be sure that the right requirements are broken down to System Level 5 specification and to support concept definition in projects and manage the system, its performance and standards management. * Operational rulebooks include all that is needed. * Support design phases in managing requirement allocation, interfaces managements, testing planning. Engineering rules are complete and fulfilling the requirements * Support integration phase supporting data analysis, simulation process, anomaly resolution Programs can fail (cost, duration, time to market) because of too long and intense workout on System Level 1-4 (overengineered analytical architecting) without getting to real implementation specification and questions. If for example a high level requirement coming from the stakeholders can be addressed directly to System Level 5 without risk, this should be done. This is a (workflow) “tailoring” decision to be taken in the functional teams. Wrong approach: Breakdown every work item on every level. Right approaches: * Specific workflow tailoring, and * Generic workflow tailoring “Specific (workflow) tailoring” (intelligent work assignment per work item) = Single work items are only assigned on levels, where work is really needed (image: 1-image1.png) Second example for specific workflow tailoring: Two different process break downs * Op. process “Emergency stop of a train”, splits up “untailored” into work assignments… * System level 1/2: Define generic roles of CCS and TMS in this case * System Level 3 TMS: Define TMS process for it * System Level 3 CCS: Define generic roles and basic information flow of Level 4 CCS Systems for it * …. * System Level 4/5 Traffic CS: …. * System Level 4/5 Train CS: … * … * Operational process “Reset object controller” shall be tailored into these work assignments * System Level 1/2: Skipped * System Level 3: Delegate interface coordination to Traffic CS / Trackside Asset CS * System Level 4/5 Traffic CS: Define process for the remote reset * System Level 4/5 Traffic CS: Define process for the local OC reset * System Level 4/5 Trackside Asset CS: Define process for the remote OC reset * System Level 4/5 Trackside Asset CS: Define process for the local OC reset Consequence: With specific workflow tailoring, the analytical system levels are incomplete (see table above). “Generic (Workflow) Tailoring” = Certain work item types are worked out only on certain layers Example: Examples: | CBO | Requirements | Operational Processes | Logical Components System Level 1/2 | X | X | Business process | System Level 3/4 | | X | X | System Level 5 | | X | X | X Coordination of “tailoring” is the main role of all “functional teams” (see chapter later in the document). A good tailoring fulfils the following requirements * Work is parallelized early and in a precise way (independent work) * No “dummy” work items just for the sake of symmetric work item break downs in the system of systems * The derivation process does not “block” everything because of sequential working dependencies * The level of details of the specification is always only as good as needed on System Level 1-4 (analytical clarification = work preparation) so that the teams working on System Level 5 know what to do. * A domain team on System Level 5 – the real specification level – can concentrate on its local work functions, engineering rules, and the collaboration with other domain teams concerning concrete interfaces * A task level architecture team (ARC, OD, MIG) just focusses on the role to provide all needed specifications (especially requirements, process definitions, functional allocation) that enables the work on System Level 5 Team - without already creating too much design “Tailoring” is the work to dynamically assign work items to the system level that shall work on them. A tailoring process is executed by a functional team. The typical workflow for tailoring is * An “inbox” (automated workflow, state driven) for new/changed work items is automated (e.g. inbox for new requirements, or for a proposal of process design change) * Some work items can be assigned automatically by rules (generic tailoring) * Else: The responsible person (role owner in the functional team) checks (evtl. discusses) the new work item * The new work item is assigned to a system level and team. This happens to all types of inputs and changes. Conclusions: * Do only the minimal needed work on System Level 1-4, needed to get good Level 5 specifications, rulebooks, etc. * Apply a generic tailoring to avoid that everybody is working on the same things * Design a workflow that assigns work items dynamically to the right level.", -- "SoS engineering can go wrong (quite often) if done in an overengineered and abstract way. If every artefact is created on every System Level (e.g. 5-7 levels and types or requirements that are broken down), the workload is artificially multiplied without need, and this policy is not creating a really good work split. To avoid this, every work process uses a tailoring approach which means * “Copy” (reference) things from a higher level, if possible like they are * Break up and translate through the levels that you really need, and not more. * Be sure that the right requirements are broken down to System Level 5 specification and to support concept definition in projects and manage the system, its performance and standards management. * Operational rulebooks include all that is needed. * Support design phases in managing requirement allocation, interfaces managements, testing planning. Engineering rules are complete and fulfilling the requirements * Support integration phase supporting data analysis, simulation process, anomaly resolution Programs can fail (cost, duration, time to market) because of too long and intense workout on System Level 1-4 (overengineered analytical architecting) without getting to real implementation specification and questions. If for example a high level requirement coming from the stakeholders can be addressed directly to System Level 5 without risk, this should be done. This is a (workflow) “tailoring” decision to be taken in the functional teams. Wrong approach: Breakdown every work item on every level. Right approaches: * Specific workflow tailoring, and * Generic workflow tailoring “Specific (workflow) tailoring” (intelligent work assignment per work item) = Single work items are only assigned on levels, where work is really needed (image: 1-image1.png) Second example for specific workflow tailoring: Two different process break downs * Op. process “Emergency stop of a train”, splits up “untailored” into work assignments… * System level 1/2: Define generic roles of CCS and TMS in this case * System Level 3 TMS: Define TMS process for it * System Level 3 CCS: Define generic roles and basic information flow of Level 4 CCS Systems for it * …. * System Level 4/5 Traffic CS: …. * System Level 4/5 Train CS: … * … * Operational process “Reset object controller” shall be tailored into these work assignments * System Level 1/2: Skipped * System Level 3: Delegate interface coordination to Traffic CS / Trackside Asset CS * System Level 4/5 Traffic CS: Define process for the remote reset * System Level 4/5 Traffic CS: Define process for the local OC reset * System Level 4/5 Trackside Asset CS: Define process for the remote OC reset * System Level 4/5 Trackside Asset CS: Define process for the local OC reset Consequence: With specific workflow tailoring, the analytical system levels are incomplete (see table above). “Generic (Workflow) Tailoring” = Certain work item types are worked out only on certain layers Example: Examples: | CBO | Requirements | Operational Processes | Logical Components System Level 1/2 | X | X | Business process | System Level 3/4 | | X | X | System Level 5 | | X | X | XCoordination of “tailoring” is the main role of all “functional teams” (see chapter later in the document). A good tailoring fulfils the following requirements * Work is parallelized early and in a precise way (independent work) * No “dummy” work items just for the sake of symmetric work item break downs in the system of systems * The derivation process does not “block” everything because of sequential working dependencies * The level of details of the specification is always only as good as needed on System Level 1-4 (analytical clarification = work preparation) so that the teams working on System Level 5 know what to do. * A domain team on System Level 5 – the real specification level – can concentrate on its local work functions, engineering rules, and the collaboration with other domain teams concerning concrete interfaces * A task level architecture team (ARC, OD, MIG) just focusses on the role to provide all needed specifications (especially requirements, process definitions, functional allocation) that enables the work on System Level 5 Team - without already creating too much design “Tailoring” is the work to dynamically assign work items to the system level that shall work on them. A tailoring process is executed by a functional team. The typical workflow for tailoring is * An “inbox” (automated workflow, state driven) for new/changed work items is automated (e.g. inbox for new requirements, or for a proposal of process design change) * Some work items can be assigned automatically by rules (generic tailoring) * Else: The responsible person (role owner in the functional team) checks (evtl. discusses) the new work item * The new work item is assigned to a system level and team. This happens to all types of inputs and changes. Conclusions: * Do only the minimal needed work on System Level 1-4, needed to get good Level 5 specifications, rulebooks, etc. * Apply a generic tailoring to avoid that everybody is working on the same things * Design a workflow that assigns work items dynamically to the right level." :diff_0871 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TAILORING--OF--REQUIREMENT--BREAKDOWN_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
SoS engineering can go wrong (quite often) if done in an overengineered and abstract way. If every artefact is created on every System Level (e.g. 5-7 levels and types or requirements that are broken down), the workload is artificially multiplied without need, and this policy is not creating a really good work split. To avoid this, every work process uses a tailoring approach which means * “Copy” (reference) things from a higher level, if possible like they are * Break up and translate through the levels that you really need, and not more. * Be sure that the right requirements are broken down to System Level 5 specification and to support concept definition in projects and manage the system, its performance and standards management. * Operational rulebooks include all that is needed. * Support design phases in managing requirement allocation, interfaces managements, testing planning. Engineering rules are complete and fulfilling the requirements * Support integration phase supporting data analysis, simulation process, anomaly resolution Programs can fail (cost, duration, time to market) because of too long and intense workout on System Level 1-4 (overengineered analytical architecting) without getting to real implementation specification and questions. If for example a high level requirement coming from the stakeholders can be addressed directly to System Level 5 without risk, this should be done. This is a (workflow) “tailoring” decision to be taken in the functional teams. Wrong approach: Breakdown every work item on every level. Right approaches: * Specific workflow tailoring, and * Generic workflow tailoring “Specific (workflow) tailoring” (intelligent work assignment per work item) = Single work items are only assigned on levels, where work is really needed (image: 1-image1.png) Second example for specific workflow tailoring: Two different process break downs * Op. process “Emergency stop of a train”, splits up “untailored” into work assignments… * System level 1/2: Define generic roles of CCS and TMS in this case * System Level 3 TMS: Define TMS process for it * System Level 3 CCS: Define generic roles and basic information flow of Level 4 CCS Systems for it * …. * System Level 4/5 Traffic CS: …. * System Level 4/5 Train CS: … * … * Operational process “Reset object controller” shall be tailored into these work assignments * System Level 1/2: Skipped * System Level 3: Delegate interface coordination to Traffic CS / Trackside Asset CS * System Level 4/5 Traffic CS: Define process for the remote reset * System Level 4/5 Traffic CS: Define process for the local OC reset * System Level 4/5 Trackside Asset CS: Define process for the remote OC reset * System Level 4/5 Trackside Asset CS: Define process for the local OC reset Consequence: With specific workflow tailoring, the analytical system levels are incomplete (see table above). “Generic (Workflow) Tailoring” = Certain work item types are worked out only on certain layers Example: Examples: | CBO | Requirements | Operational Processes | Logical Components System Level 1/2 | X | X | Business process | System Level 3/4 | | X | X | System Level 5 | | X | X | X Coordination of “tailoring” is the main role of all “functional teams” (see chapter later in the document). A good tailoring fulfils the following requirements * Work is parallelized early and in a precise way (independent work) * No “dummy” work items just for the sake of symmetric work item break downs in the system of systems * The derivation process does not “block” everything because of sequential working dependencies * The level of details of the specification is always only as good as needed on System Level 1-4 (analytical clarification = work preparation) so that the teams working on System Level 5 know what to do. * A domain team on System Level 5 – the real specification level – can concentrate on its local work functions, engineering rules, and the collaboration with other domain teams concerning concrete interfaces * A task level architecture team (ARC, OD, MIG) just focusses on the role to provide all needed specifications (especially requirements, process definitions, functional allocation) that enables the work on System Level 5 Team - without already creating too much design “Tailoring” is the work to dynamically assign work items to the system level that shall work on them. A tailoring process is executed by a functional team. The typical workflow for tailoring is * An “inbox” (automated workflow, state driven) for new/changed work items is automated (e.g. inbox for new requirements, or for a proposal of process design change) * Some work items can be assigned automatically by rules (generic tailoring) * Else: The responsible person (role owner in the functional team) checks (evtl. discusses) the new work item * The new work item is assigned to a system level and team. This happens to all types of inputs and changes. Conclusions: * Do only the minimal needed work on System Level 1-4, needed to get good Level 5 specifications, rulebooks, etc. * Apply a generic tailoring to avoid that everybody is working on the same things * Design a workflow that assigns work items dynamically to the right level.
SoS engineering can go wrong (quite often) if done in an overengineered and abstract way. If every artefact is created on every System Level (e.g. 5-7 levels and types or requirements that are broken down), the workload is artificially multiplied without need, and this policy is not creating a really good work split. To avoid this, every work process uses a tailoring approach which means * “Copy” (reference) things from a higher level, if possible like they are * Break up and translate through the levels that you really need, and not more. * Be sure that the right requirements are broken down to System Level 5 specification and to support concept definition in projects and manage the system, its performance and standards management. * Operational rulebooks include all that is needed. * Support design phases in managing requirement allocation, interfaces managements, testing planning. Engineering rules are complete and fulfilling the requirements * Support integration phase supporting data analysis, simulation process, anomaly resolution Programs can fail (cost, duration, time to market) because of too long and intense workout on System Level 1-4 (overengineered analytical architecting) without getting to real implementation specification and questions. If for example a high level requirement coming from the stakeholders can be addressed directly to System Level 5 without risk, this should be done. This is a (workflow) “tailoring” decision to be taken in the functional teams. Wrong approach: Breakdown every work item on every level. Right approaches: * Specific workflow tailoring, and * Generic workflow tailoring “Specific (workflow) tailoring” (intelligent work assignment per work item) = Single work items are only assigned on levels, where work is really needed (image: 1-image1.png) Second example for specific workflow tailoring: Two different process break downs * Op. process “Emergency stop of a train”, splits up “untailored” into work assignments… * System level 1/2: Define generic roles of CCS and TMS in this case * System Level 3 TMS: Define TMS process for it * System Level 3 CCS: Define generic roles and basic information flow of Level 4 CCS Systems for it * …. * System Level 4/5 Traffic CS: …. * System Level 4/5 Train CS: … * … * Operational process “Reset object controller” shall be tailored into these work assignments * System Level 1/2: Skipped * System Level 3: Delegate interface coordination to Traffic CS / Trackside Asset CS * System Level 4/5 Traffic CS: Define process for the remote reset * System Level 4/5 Traffic CS: Define process for the local OC reset * System Level 4/5 Trackside Asset CS: Define process for the remote OC reset * System Level 4/5 Trackside Asset CS: Define process for the local OC reset Consequence: With specific workflow tailoring, the analytical system levels are incomplete (see table above). “Generic (Workflow) Tailoring” = Certain work item types are worked out only on certain layers Example: Examples: | CBO | Requirements | Operational Processes | Logical Components System Level 1/2 | X | X | Business process | System Level 3/4 | | X | X | System Level 5 | | X | X | XCoordination of “tailoring” is the main role of all “functional teams” (see chapter later in the document). A good tailoring fulfils the following requirements * Work is parallelized early and in a precise way (independent work) * No “dummy” work items just for the sake of symmetric work item break downs in the system of systems * The derivation process does not “block” everything because of sequential working dependencies * The level of details of the specification is always only as good as needed on System Level 1-4 (analytical clarification = work preparation) so that the teams working on System Level 5 know what to do. * A domain team on System Level 5 – the real specification level – can concentrate on its local work functions, engineering rules, and the collaboration with other domain teams concerning concrete interfaces * A task level architecture team (ARC, OD, MIG) just focusses on the role to provide all needed specifications (especially requirements, process definitions, functional allocation) that enables the work on System Level 5 Team - without already creating too much design “Tailoring” is the work to dynamically assign work items to the system level that shall work on them. A tailoring process is executed by a functional team. The typical workflow for tailoring is * An “inbox” (automated workflow, state driven) for new/changed work items is automated (e.g. inbox for new requirements, or for a proposal of process design change) * Some work items can be assigned automatically by rules (generic tailoring) * Else: The responsible person (role owner in the functional team) checks (evtl. discusses) the new work item * The new work item is assigned to a system level and team. This happens to all types of inputs and changes. Conclusions: * Do only the minimal needed work on System Level 1-4, needed to get good Level 5 specifications, rulebooks, etc. * Apply a generic tailoring to avoid that everybody is working on the same things * Design a workflow that assigns work items dynamically to the right level.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TASK_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as Task Replicas. Previous definition: A Functional Application Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as FA Task Replicas.", -- "A Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as Task Replicas. Previous definition: A Functional Application Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as FA Task Replicas." :diff_0872 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TASK_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as Task Replicas. Previous definition: A Functional Application Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as FA Task Replicas.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TEMPORARY--SHUNTING--AREA--TSHA_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Temporary Shunting Area (TShA) A temporary shunting area is an interlocked area{comment:15} temporarily set up to allow shunting operations. A temporary shunting area is always under the responsibility of a Shunting area manager. (OR.DEF.161 - Banedanmark)", -- "Temporary Shunting Area (TShA) A temporary shunting area is an interlocked area{comment:15} temporarily set up to allow shunting operations. A temporary shunting area is always under the responsibility of a Shunting area manager. (OR.DEF.161 - Banedanmark)" :diff_0873 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TEMPORARY--SHUNTING--AREA--TSHA_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Temporary Shunting Area (TShA) A temporary shunting area is an interlocked area{comment:15} temporarily set up to allow shunting operations. A temporary shunting area is always under the responsibility of a Shunting area manager. (OR.DEF.161 - Banedanmark)
] . :diff_0874 a :Object_addition ; ordv:entity lex_sp-defs-241203:THE--SET--OF--ALL--TRACES--TOGETHER--IS--CALLED--A--_MODEL_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:THE--_TRACE_--FOR--A--WORK--ITEM--CHAIN_TREE_GRAPH_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => **++ "* A Trace is a chain of all linked work items (a “directed graph” of nodes and links), that resolve all dependencies of a single work item * Example trace (in this case a “simple tree of nodes”, but can also be more complex): * A common business objective is solved by * a list of operational capabilities and requirements which are implemented in * a list of operational processes which need * a list of system capabilities and functions which are allocated in * logical components that are implemented in * physical subsystems which have * a list of precisely defined interfaces and * engineering rules.. * A trace is valid if all derivations are complete and correct. * A trace is complete if all dependencies are resolved by specified and verified work items (down to the implementation of detailed operational rulebooks and system handbooks, engineering rules and FFFiS interface specifications) * The overall specification is complete when all objectives, operational capabilities, and operational requirements are resolved by complete traces. * Example of the trace of one requirement (red node) down to functions, processes and components (other colours) (image: 1-Grafik_1780564629.png)", **-- "* A Trace is a chain of all linked work items (a “directed graph” of nodes and links), that resolve all dependencies of a single work item * Example trace (in this case a “simple tree of nodes”, but can also be more complex): * A common business objective is solved by * a list of operational capabilities and requirements which are implemented in * a list of operational processes which need * a list of system capabilities and functions which are allocated in * logical components that are implemented in * physical subsystems which have * a list of precisely defined interfaces and * engineering rules.. * A trace is valid if all derivations are complete and correct. * A trace is complete if all dependencies are resolved by specified and verified work items (down to the implementation of detailed operational rulebooks and system handbooks, engineering rules and FFFiS interface specifications) * The overall specification is complete when all objectives, operational capabilities, and operational requirements are resolved by complete traces. * Example of the trace of one requirement (red node) down to functions, processes and components (other colours) (image: 1-Grafik_1780564629.png)" :diff_0875 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:THE--_TRACE_--FOR--A--WORK--ITEM--CHAIN_TREE_GRAPH_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
* A Trace is a chain of all linked work items (a “directed graph” of nodes and links), that resolve all dependencies of a single work item * Example trace (in this case a “simple tree of nodes”, but can also be more complex): * A common business objective is solved by * a list of operational capabilities and requirements which are implemented in * a list of operational processes which need * a list of system capabilities and functions which are allocated in * logical components that are implemented in * physical subsystems which have * a list of precisely defined interfaces and * engineering rules.. * A trace is valid if all derivations are complete and correct. * A trace is complete if all dependencies are resolved by specified and verified work items (down to the implementation of detailed operational rulebooks and system handbooks, engineering rules and FFFiS interface specifications) * The overall specification is complete when all objectives, operational capabilities, and operational requirements are resolved by complete traces. * Example of the trace of one requirement (red node) down to functions, processes and components (other colours) (image: 1-Grafik_1780564629.png)
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:THREAT--LANDSCAPE_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Threat landscape is used in this document as synonym for threat environment. Threat environment (definition from CENELEC TS 50701, IEC PT 63452) environment summary of information about threats, such as threat sources, threat vectors and trends, that have the potential to adversely impact a defined target (for example a company, facility or SuC)", -- "Threat landscape is used in this document as synonym for threat environment. Threat environment (definition from CENELEC TS 50701, IEC PT 63452) environment summary of information about threats, such as threat sources, threat vectors and trends, that have the potential to adversely impact a defined target (for example a company, facility or SuC)" :diff_0876 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:THREAT--LANDSCAPE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Threat landscape is used in this document as synonym for threat environment. Threat environment (definition from CENELEC TS 50701, IEC PT 63452) environment summary of information about threats, such as threat sources, threat vectors and trends, that have the potential to adversely impact a defined target (for example a company, facility or SuC)
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TLS_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Transport Layer Security (source: SPPRAMSS-1705 - [UNISIG Subset-146] )", -- "Transport Layer Security (source: SPPRAMSS-1705 - [UNISIG Subset-146] )" :diff_0877 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TLS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Transport Layer Security (source: SPPRAMSS-1705 - [UNISIG Subset-146] )
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TOOL_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "An instrument that, when applied to a particular method, can enhance the efficiency of the task, provided it is applied properly and by somebody with proper skills and training.{comment:409}", -- "An instrument that, when applied to a particular method, can enhance the efficiency of the task, provided it is applied properly and by somebody with proper skills and training." :diff_0878 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TOOL_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
An instrument that, when applied to a particular method, can enhance the efficiency of the task, provided it is applied properly and by somebody with proper skills and training.{comment:409}
An instrument that, when applied to a particular method, can enhance the efficiency of the task, provided it is applied properly and by somebody with proper skills and training.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TOUCH--CONTROLLER_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Touch Controller Controller which manages the states and failures of a Touch Panel.", -- "Touch Controller Controller which manages the states and failures of a Touch Panel." :diff_0879 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TOUCH--CONTROLLER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Touch Controller Controller which manages the states and failures of a Touch Panel.
] . :diff_0880 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRACKSIDE--ASSET_lexConcept . :diff_0881 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRACKSIDE--PROTECTION--SYSTEM_lexConcept . :diff_0882 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRACKSIDE--TRAIN--DETECTION_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRADE-SPACE--FACTOR_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0883 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRADE-SPACE--FACTOR_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
"trade-space factors" represent the different factors/characteristics defining the solution space/alternatives. From this trade-off playspace containing set of good/acceptable solutions, we will need to identify the optimal one (i.e. "best" trade-off).
] . :diff_0884 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRAFFIC--CONTROL--AND--SUPERVISION_lexConcept . :diff_0885 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRAIN--CONTROL--AND--MONITORING--SYSTEM_lexConcept . :diff_0886 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRAIN--CONTROL--AND--MONITORING--SYSTEM_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRAIN--DISPLAY--SYSTEM--CONTROLLER_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Train Display System Controller The TDS Controller interacts with system (CCS, TCMS,CVR) and manages the Desk Display Area.", -- "Train Display System Controller The TDS Controller interacts with system (CCS, TCMS,CVR) and manages the Desk Display Area." :diff_0887 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRAIN--DISPLAY--SYSTEM--CONTROLLER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Train Display System Controller The TDS Controller interacts with system (CCS, TCMS,CVR) and manages the Desk Display Area.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRAIN--DISPLAY--SYSTEM--TDS_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Train Display System (TDS) The Train Display System is the train cab display system that comprises and manages one or more displays on the driver desk and a driver interface. It is composed of at least one display with the associated input devices, at least one loudspeaker and at least one Train Display System Controller. It offers a standardised communication interface to systems that need driver interaction.", -- "Train Display System (TDS) The Train Display System is the train cab display system that comprises and manages one or more displays on the driver desk and a driver interface. It is composed of at least one display with the associated input devices, at least one loudspeaker and at least one Train Display System Controller. It offers a standardised communication interface to systems that need driver interaction." :diff_0888 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRAIN--DISPLAY--SYSTEM--TDS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Train Display System (TDS) The Train Display System is the train cab display system that comprises and manages one or more displays on the driver desk and a driver interface. It is composed of at least one display with the associated input devices, at least one loudspeaker and at least one Train Display System Controller. It offers a standardised communication interface to systems that need driver interaction.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRAIN--FRONT--END_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "It is represented by a point on the carriage floor along the longitudinal axis. This point is the most forward element belonging to the engine with regards to the train orientation.  For the absolute position it is expressed in a geocoordinate reference frame . Note: if the ASTP is not installed in the first vehicle, the absolute position is given from carriage front end where the ASTP is installed.  For the 1D train front end position it is derived from the bogie pin 1D position by adding the distance between the bogie pin and the train front end. Rationale: Thanks to the absolute positioning of the ASTP and the Map Data, the absolute position of the bogie is determined. From this absolute position the bogie pin 1D position can be derived. Note the absolute error between the bogie and the train front end, and the bogie and the train front end on the track centreline is negligible (less than 0,02cm for curve with a radius of 150m).", -- "It is represented by a point on the carriage floor along the longitudinal axis. This point is the most forward element belonging to the engine with regards to the train orientation.  For the absolute position it is expressed in a geocoordinate reference frame . Note: if the ASTP is not installed in the first vehicle, the absolute position is given from carriage front end where the ASTP is installed.  For the 1D train front end position it is derived from the bogie pin 1D position by adding the distance between the bogie pin and the train front end. Rationale: Thanks to the absolute positioning of the ASTP and the Map Data, the absolute position of the bogie is determined. From this absolute position the bogie pin 1D position can be derived. Note the absolute error between the bogie and the train front end, and the bogie and the train front end on the track centreline is negligible (less than 0,02cm for curve with a radius of 150m)." :diff_0889 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRAIN--FRONT--END_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
It is represented by a point on the carriage floor along the longitudinal axis. This point is the most forward element belonging to the engine with regards to the train orientation.  For the absolute position it is expressed in a geocoordinate reference frame . Note: if the ASTP is not installed in the first vehicle, the absolute position is given from carriage front end where the ASTP is installed.  For the 1D train front end position it is derived from the bogie pin 1D position by adding the distance between the bogie pin and the train front end. Rationale: Thanks to the absolute positioning of the ASTP and the Map Data, the absolute position of the bogie is determined. From this absolute position the bogie pin 1D position can be derived. Note the absolute error between the bogie and the train front end, and the bogie and the train front end on the track centreline is negligible (less than 0,02cm for curve with a radius of 150m).
] . :diff_0890 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRAIN--LENGTH--MASTER_lexConcept . :diff_0891 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRAIN--LENGTH--MERGING--FUNCTION_lexConcept . :diff_0892 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRAIN--OBJECT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRAIN--RUNNING--NUMBER_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A number under which the train is operated. Reference: Glossary of Terms and Abbreviation. SUBSET-023. Issue 4.0.0", -- "A number under which the train is operated. Reference: Glossary of Terms and Abbreviation. SUBSET-023. Issue 4.0.0" :diff_0893 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRAIN--RUNNING--NUMBER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A number under which the train is operated. Reference: Glossary of Terms and Abbreviation. SUBSET-023. Issue 4.0.0
] . :diff_0894 a :Object_addition ; ordv:entity lex_sp-defs-241203:TRAIN--SPLITTING_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRAIN--TRUE--ACCELERATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The real signed acceleration of the train along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame.", -- "The real signed acceleration of the train along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame." :diff_0895 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRAIN--TRUE--ACCELERATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The real signed acceleration of the train along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRAIN--TRUE--POSITION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The real position of the train front-end along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame or a geocoordinate reference frame .", -- "The real position of the train front-end along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame or a geocoordinate reference frame ." :diff_0896 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRAIN--TRUE--POSITION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The real position of the train front-end along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame or a geocoordinate reference frame .
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRAIN--TRUE--SPEED_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The real absolute speed of the train along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame.", -- "The real absolute speed of the train along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame." :diff_0897 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRAIN--TRUE--SPEED_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The real absolute speed of the train along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TRAIN-CENTRIC--TRACK--OCCUPANCY_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0898 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TRAIN-CENTRIC--TRACK--OCCUPANCY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
With train-centric approach the trackside focus is on representing a railway vehicle with an extent in a topology rather than on representing anonymous occupancy states of fixed sizes reported by TTD systems as in today's conventional block-centric signaling systems. In other words, the term "train-centric" refers to a "train-oriented" view of the trackside system about the track occupation caused by a railway vehicle, e.g., an ETCS-equipped train. This view is achieved by fusion of localisation information from both train and trackside. A train-centric track occupancy determination is based primarily on localisation information received from the railway vehicle, e.g., from trains sent via ETCS Train Position Reports. The trackside system will also take into account additional trackside localisation information if available such as Trackside Train Detection (TTD) inputs, for example to: * Adjust the trackside view of track occupancy by train, based on clear TTD sections at the front or rear of the train * Detect movement of non-communicating railway vehicles, e.g., trains/wagons not equipped with ETCS and trains equipped with ETCS that have lost communication * Handle degraded situations, such as loss of train integrity.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:TSI--CCS--2023-----4-1-1---BASIC--PARAMETERS_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "In accordance with the relevant essential requirements, the Control-Command and Signalling Subsystems are characterised by the following basic parameters: (1) Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability (point 4.2.1); (2) On-Board ETCS functionality (point 4.2.2); (3) Trackside ETCS functionality (point 4.2.3); (4) Mobile communication functions for railways RMR (point 4.2.4); (5) RMR, ETCS and ATO air gap interfaces (point 4.2.5); (6) On-Board Interfaces Internal to Control-Command and Signalling (point 4.2.6); (7) Trackside Interfaces Internal to Control-Command and Signalling (point 4.2.7); (8) Key Management (point 4.2.8); (9) ETCS-ID Management (point 4.2.9); (10) Trackside Train Detection Systems (point 4.2.10); (11) Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment (point 4.2.11); (12) ETCS DMI (Driver-Machine Interface) (point 4.2.12); (13) RMR DMI (Driver-Machine Interface) (point 4.2.13); (14) Interface to Data Recording for Regulatory Purposes (point 4.2.14); (15) Trackside Control-Command and Signalling objects (point 4.2.15); (16) Construction of equipment used in CCS subsystems (point 4.2.16); (17) ETCS and Radio System Compatibility (point 4.2.17); (18) On-Board ATO functionality (point 4.2.18); (19) Trackside ATO functionality (point 4.2.19); (20) Technical documentation for Maintenance (point 4.2.20).", -- "In accordance with the relevant essential requirements, the Control-Command and Signalling Subsystems are characterised by the following basic parameters: (1) Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability (point 4.2.1); (2) On-Board ETCS functionality (point 4.2.2); (3) Trackside ETCS functionality (point 4.2.3); (4) Mobile communication functions for railways RMR (point 4.2.4); (5) RMR, ETCS and ATO air gap interfaces (point 4.2.5); (6) On-Board Interfaces Internal to Control-Command and Signalling (point 4.2.6); (7) Trackside Interfaces Internal to Control-Command and Signalling (point 4.2.7); (8) Key Management (point 4.2.8); (9) ETCS-ID Management (point 4.2.9); (10) Trackside Train Detection Systems (point 4.2.10); (11) Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment (point 4.2.11); (12) ETCS DMI (Driver-Machine Interface) (point 4.2.12); (13) RMR DMI (Driver-Machine Interface) (point 4.2.13); (14) Interface to Data Recording for Regulatory Purposes (point 4.2.14); (15) Trackside Control-Command and Signalling objects (point 4.2.15); (16) Construction of equipment used in CCS subsystems (point 4.2.16); (17) ETCS and Radio System Compatibility (point 4.2.17); (18) On-Board ATO functionality (point 4.2.18); (19) Trackside ATO functionality (point 4.2.19); (20) Technical documentation for Maintenance (point 4.2.20)." :diff_0899 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:TSI--CCS--2023-----4-1-1---BASIC--PARAMETERS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
In accordance with the relevant essential requirements, the Control-Command and Signalling Subsystems are characterised by the following basic parameters: (1) Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability (point 4.2.1); (2) On-Board ETCS functionality (point 4.2.2); (3) Trackside ETCS functionality (point 4.2.3); (4) Mobile communication functions for railways RMR (point 4.2.4); (5) RMR, ETCS and ATO air gap interfaces (point 4.2.5); (6) On-Board Interfaces Internal to Control-Command and Signalling (point 4.2.6); (7) Trackside Interfaces Internal to Control-Command and Signalling (point 4.2.7); (8) Key Management (point 4.2.8); (9) ETCS-ID Management (point 4.2.9); (10) Trackside Train Detection Systems (point 4.2.10); (11) Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment (point 4.2.11); (12) ETCS DMI (Driver-Machine Interface) (point 4.2.12); (13) RMR DMI (Driver-Machine Interface) (point 4.2.13); (14) Interface to Data Recording for Regulatory Purposes (point 4.2.14); (15) Trackside Control-Command and Signalling objects (point 4.2.15); (16) Construction of equipment used in CCS subsystems (point 4.2.16); (17) ETCS and Radio System Compatibility (point 4.2.17); (18) On-Board ATO functionality (point 4.2.18); (19) Trackside ATO functionality (point 4.2.19); (20) Technical documentation for Maintenance (point 4.2.20).
] . :diff_0900 a :Object_addition ; ordv:entity lex_sp-defs-241203:UNRESOLVED--TRACKBOUND--OBJECT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:UPLINKING_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_0901 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:UPLINKING_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
To handle deviated new designs or new/changed external inputs the whole “engineering” has to be understood as * Work items with type, versions, and state * Their links with versions, link roles and state The engineering database is in the end a “directed graph” with “nodes” (work items) and links (graph just indicated in the picture):{comment:13} (image: 3-image3.png) The basic principle for continuous integration using an ALM+MBSE system is based on the mathematical process of “adding a directed graph to another directed graph which can overlap in certain nodes”. This is called “Uplinking” in the System Pillar. Existing graph (e.g. ALM master database) New graph fragment (external contribution) “Merging these graphs” ="uplinking" (of conceptual, requirement and modelling work items) is the most feared job to do in system engineering when done manually. A strong system support is necessary. This merge can happen when * A daughter-system graph is “uplinked” to the mother-system (master) graph * An external contribution is integrated (perhaps again and again) * An external editor was used to edit elements in the mater database (e.g. ALM= master database, MBSE-Tool = editor for a part of the work items) * A bottom-up process is faster (domain team) then the top-down process (Level 3) * The architecture teams is faster concerning functional design then the operational design team with the process design. Or both are fast then the requirement feedback from the migration team is coming. * Etc. A lot of isolated (time, team, engineering tool) asynchronous designs will occur in the System Pillar. They lead to these synchronization needs: This does not mean, that “synchronization” is the standard choice to integrate work. The preferred choice is top-down design and working in the same system whenever possible. But synchronization will anyway be needed very often. The sync process of these integration steps is the same. All integration work (conceptual level, system models, requirements, etc.) is about this merging process. The following things can happen: * A new node (work item) is added and linked to 0-n{comment:14} old nodes * An old node is changed or deleted or relinked in another way The indirect effect of such a change/add process can be * In a “trace” (chain of work items) links can get{comment:15} “suspect” if earlier links or nodes were changed (through partially-automated impact analysis) * New workflows are triggered by new work item states. If a new node is created with the state “draft”, it is because of this assigned by a tailoring process in a certain way. To add the new fragment{comment:16} to the exiting master database (can only be done efficiently with automated ALM systems) the following work steps are executed * Convert contribution to graph structure (work items/links), check consistency * Analyse and assess new contribution * Perhaps adapt/change contribution before synchronisation * Create difference to master database automatically * Assess difference and indirect impacts * Replace/link fragment in database (fully or partially) or revoke it * Check and analyse the new state of the master database Simplification of synchronization * Assigned designated areas to be designed only in certain teams/tools/places (only connecting links to be synchronized) * Check separated designs together frequently to avoid large deviations How often synchronize/integrate? * Best: Directly work on the master model (possible with ALM, performance problems with MBSE tools) * Second best: Do the sync/integration very frequently (daily, weekly, or monthly) * Worst: do it once in 6 months --> Risk of unsolvable incompatibility and lost work is increased Conclusion: * We need a very efficient and sophisticated tool support for the synchronization/integration process * The integration/synchronization process will create large efforts in the Modelling Service Team The concrete rules, when and how “uplinking” is done, are defined in chapter 20.
To handle deviated new designs or new/changed external inputs the whole “engineering” has to be understood as * Work items with type, versions, and state * Their links with versions, link roles and state The engineering database is in the end a “directed graph” with “nodes” (work items) and links (graph just indicated in the picture):{comment:13} (image: 3-image3.png) The basic principle for continuous integration using an ALM+MBSE system is based on the mathematical process of “adding a directed graph to another directed graph which can overlap in certain nodes”. This is called “Uplinking” in the System Pillar. Existing graph (e.g. ALM master database) New graph fragment (external contribution) (image: 1-screenshot-20221229-210015.png) “Merging these graphs” ="uplinking" (of conceptual, requirement and modelling work items) is the most feared job to do in system engineering when done manually. A strong system support is necessary. This merge can happen when * A daughter-system graph is “uplinked” to the mother-system (master) graph * An external contribution is integrated (perhaps again and again) * An external editor was used to edit elements in the mater database (e.g. ALM= master database, MBSE-Tool = editor for a part of the work items) * A bottom-up process is faster (domain team) then the top-down process (Level 3) * The architecture teams is faster concerning functional design then the operational design team with the process design. Or both are fast then the requirement feedback from the migration team is coming. * Etc. A lot of isolated (time, team, engineering tool) asynchronous designs will occur in the System Pillar. They lead to these synchronization needs: (image: 2-screenshot-20221229-210015.png) This does not mean, that “synchronization” is the standard choice to integrate work. The preferred choice is top-down design and working in the same system whenever possible. But synchronization will anyway be needed very often. The sync process of these integration steps is the same. All integration work (conceptual level, system models, requirements, etc.) is about this merging process. The following things can happen: * A new node (work item) is added and linked to 0-n{comment:14} old nodes * An old node is changed or deleted or relinked in another way The indirect effect of such a change/add process can be * In a “trace” (chain of work items) links can get{comment:15} “suspect” if earlier links or nodes were changed (through partially-automated impact analysis) * New workflows are triggered by new work item states. If a new node is created with the state “draft”, it is because of this assigned by a tailoring process in a certain way. To add the new fragment{comment:16} to the exiting master database (can only be done efficiently with automated ALM systems) the following work steps are executed * Convert contribution to graph structure (work items/links), check consistency * Analyse and assess new contribution * Perhaps adapt/change contribution before synchronisation * Create difference to master database automatically * Assess difference and indirect impacts * Replace/link fragment in database (fully or partially) or revoke it * Check and analyse the new state of the master database Simplification of synchronization * Assigned designated areas to be designed only in certain teams/tools/places (only connecting links to be synchronized) * Check separated designs together frequently to avoid large deviations How often synchronize/integrate? * Best: Directly work on the master model (possible with ALM, performance problems with MBSE tools) * Second best: Do the sync/integration very frequently (daily, weekly, or monthly) * Worst: do it once in 6 months --> Risk of unsolvable incompatibility and lost work is increased Conclusion: * We need a very efficient and sophisticated tool support for the synchronization/integration process * The integration/synchronization process will create large efforts in the Modelling Service Team The concrete rules, when and how “uplinking” is done, are defined in chapter 20.
] . :diff_0902 a :Object_addition ; ordv:entity lex_sp-defs-241203:USAGE--RESTRICTION--AREA_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:VALID--LOCALISATION--INFORMATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Localisation information processed and validated by the ASTP achieving safety requirements for safe relevant data (e.g., valid position, valid speed…). Note: this valid position is the view from the ASTP, there is no link with the position status (unambiguous, ambiguous, valid, invalid…) at the ETCS system level.", -- "Localisation information processed and validated by the ASTP achieving safety requirements for safe relevant data (e.g., valid position, valid speed…). Note: this valid position is the view from the ASTP, there is no link with the position status (unambiguous, ambiguous, valid, invalid…) at the ETCS system level." :diff_0903 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:VALID--LOCALISATION--INFORMATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Localisation information processed and validated by the ASTP achieving safety requirements for safe relevant data (e.g., valid position, valid speed…). Note: this valid position is the view from the ASTP, there is no link with the position status (unambiguous, ambiguous, valid, invalid…) at the ETCS system level.
] . :diff_0904 a :Object_addition ; ordv:entity lex_sp-defs-241203:VEHICLE--DATA_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:VELOCITY_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Train speed expressed in a 3D reference frame defined by the carriage reference frame.", -- "Train speed expressed in a 3D reference frame defined by the carriage reference frame." :diff_0905 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:VELOCITY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Train speed expressed in a 3D reference frame defined by the carriage reference frame.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:VIEW--CONTROLLER_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "View Controller The View Controller aggregates the View, the output devices and the controller of each input device.", -- "View Controller The View Controller aggregates the View, the output devices and the controller of each input device." :diff_0906 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:VIEW--CONTROLLER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
View Controller The View Controller aggregates the View, the output devices and the controller of each input device.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:VIEW_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "View Aggregation of Areas required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time.", -- "View Aggregation of Areas required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time." :diff_0907 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:VIEW_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
View Aggregation of Areas required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:VLAN-----VIRTUAL--LOCAL--AREA--NETWORK_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "VLAN - Virtual Local Area Network{comment:49}", -- "VLAN - Virtual Local Area Network" :diff_0908 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:VLAN-----VIRTUAL--LOCAL--AREA--NETWORK_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
VLAN - Virtual Local Area Network{comment:49}
] . :diff_0909 a :Object_addition ; ordv:entity lex_sp-defs-241203:WAYSIDE--MONITORING--SYSTEM_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:WIRELESS--COMMUNICATION_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Wireless Communication refers to the requirements for Wireless Communication from IEC 62443-3-3 mentioned in SR 1.6, SR 1.6 RE1 and SR 2.2, SR 2.2 RE1. Note: Secure Components are only seen as connected to Wireless Communication, if the Secure Component itself has Wireless Communication abilities implemented. This may count for Work Force Warning systems, for example. This explicitly does exclude Secure Components like Field element controllers, Euro radio, Interlockings and many more according to today's definitions.", -- "Wireless Communication refers to the requirements for Wireless Communication from IEC 62443-3-3 mentioned in SR 1.6, SR 1.6 RE1 and SR 2.2, SR 2.2 RE1. Secure Components are only seen as connected to Wireless Communication, if the Secure Component itself has Wireless Communication abilities implemented. This may count for Work Force Warning systems, for example. This explicitly does exclude Secure Components like Field element controllers, Euro radio, Interlockings and many more according to today's definitions." :diff_0910 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:WIRELESS--COMMUNICATION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Wireless Communication refers to the requirements for Wireless Communication from IEC 62443-3-3 mentioned in SR 1.6, SR 1.6 RE1 and SR 2.2, SR 2.2 RE1. Note: Secure Components are only seen as connected to Wireless Communication, if the Secure Component itself has Wireless Communication abilities implemented. This may count for Work Force Warning systems, for example. This explicitly does exclude Secure Components like Field element controllers, Euro radio, Interlockings and many more according to today's definitions.
Wireless Communication refers to the requirements for Wireless Communication from IEC 62443-3-3 mentioned in SR 1.6, SR 1.6 RE1 and SR 2.2, SR 2.2 RE1. Secure Components are only seen as connected to Wireless Communication, if the Secure Component itself has Wireless Communication abilities implemented. This may count for Work Force Warning systems, for example. This explicitly does exclude Secure Components like Field element controllers, Euro radio, Interlockings and many more according to today's definitions.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:WIRELESS--COMPONENT_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A Secure Component or Network Component with a wireless communication interface. Examples of Wireless Components are handheld devices, WLAN access points, WLAN/5G/FRMCS/... routers, modems and wireless object controllers. Note: additional requirements apply to Wireless Components (as IEC 62443-4-2 SR 1.6, SR 1.6 RE1 and SR 2.2, SR 2.2 RE1)", -- "A Secure Component or Network Component with a wireless communication interface. Examples of Wireless Components are handheld devices, WLAN access points, WLAN/5G/FRMCS/... routers, modems and wireless object controllers,...." :diff_0911 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:WIRELESS--COMPONENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A Secure Component or Network Component with a wireless communication interface. Examples of Wireless Components are handheld devices, WLAN access points, WLAN/5G/FRMCS/... routers, modems and wireless object controllers. Note: additional requirements apply to Wireless Components (as IEC 62443-4-2 SR 1.6, SR 1.6 RE1 and SR 2.2, SR 2.2 RE1)
A Secure Component or Network Component with a wireless communication interface. Examples of Wireless Components are handheld devices, WLAN access points, WLAN/5G/FRMCS/... routers, modems and wireless object controllers,....
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:WORK--ITEM--EDITOR_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "* The basic system and workflow management tool is the ALM system (currently Polarion). * The ALM offers different frontend types to create/edit/change work items (document editors, database frontends, graphical design, etc.) * Additional editors (like graphical modelling tools for ARCADIA and SysML) can be used to edit elements of the engineering database in the ALM System (synchronized data) as far as a synchronisation software is available (see chapter data management)", -- "* The basic system and workflow management tool is the ALM system (currently Polarion). * The ALM offers different frontend types to create/edit/change work items (document editors, database frontends, graphical design, etc.) * Additional editors (like graphical modelling tools for ARCADIA and SysML) can be used to edit elements of the engineering database in the ALM System (synchronized data) as far as a synchronisation software is available (see chapter data management)" :diff_0912 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:WORK--ITEM--EDITOR_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
* The basic system and workflow management tool is the ALM system (currently Polarion). * The ALM offers different frontend types to create/edit/change work items (document editors, database frontends, graphical design, etc.) * Additional editors (like graphical modelling tools for ARCADIA and SysML) can be used to edit elements of the engineering database in the ALM System (synchronized data) as far as a synchronisation software is available (see chapter data management)
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:WORK--ITEM_lexConcept_2 ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "* Work items examples: “A requirement”, or “a function”, or “a concept aspect” * Work items are objects in the “engineering database” (ALM) that represent the result of a design step. * The structure of the work items is defined by the SEMP process definition documents (overview in the maps), that also make use of modelling standards like ARCADIA or SysML * The master-engineering database is the ALM System (currently Polarion) which contains all work items and their links.", -- "* Work items examples: “A requirement”, or “a function”, or “a concept aspect” * Work items are objects in the “engineering database” (ALM) that represent the result of a design step. * The structure of the work items is defined by the SEMP process definition documents (overview in the maps), that also make use of modelling standards like ARCADIA or SysML * The master-engineering database is the ALM System (currently Polarion) which contains all work items and their links." :diff_0913 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:WORK--ITEM_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
* Work items examples: “A requirement”, or “a function”, or “a concept aspect” * Work items are objects in the “engineering database” (ALM) that represent the result of a design step. * The structure of the work items is defined by the SEMP process definition documents (overview in the maps), that also make use of modelling standards like ARCADIA or SysML * The master-engineering database is the ALM System (currently Polarion) which contains all work items and their links.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:WORKFLOW--AND--WORKFLOW--RULES_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "* A workflow describes the rules (processes) how a “trace” shall be created step by step. * A workflow includes a set of rules that define, how * work items must be broken down and linked (link rules) * work item types must be resolved * certain work item types are assigned to certain teams in the organisation * Every work item, that is not compliant to a workflow is marked as invalid * There are optional workflow steps in a workflow. E.g. a requirement can be directly resolved by multiple functions (that are always explained with a rational attribute) without having a “solution concept” work item, which is optional.", -- "* A workflow describes the rules (processes) how a “trace” shall be created step by step. * A workflow includes a set of rules that define, how * work items must be broken down and linked (link rules) * work item types must be resolved * certain work item types are assigned to certain teams in the organisation * Every work item, that is not compliant to a workflow is marked as invalid * There are optional workflow steps in a workflow. E.g. a requirement can be directly resolved by multiple functions (that are always explained with a rational attribute) without having a “solution concept” work item, which is optional." :diff_0914 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:WORKFLOW--AND--WORKFLOW--RULES_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
* A workflow describes the rules (processes) how a “trace” shall be created step by step. * A workflow includes a set of rules that define, how * work items must be broken down and linked (link rules) * work item types must be resolved * certain work item types are assigned to certain teams in the organisation * Every work item, that is not compliant to a workflow is marked as invalid * There are optional workflow steps in a workflow. E.g. a requirement can be directly resolved by multiple functions (that are always explained with a rational attribute) without having a “solution concept” work item, which is optional.
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:WORKFLOW--PRIORITISATION--STRATEGY--TO--BE--DECIDED--PER--AREA_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "In general, there are two directions for prioritisation, which are “horizontal” or “vertical” * Horizontal prioritisation means for example “which of all operational capabilities do we break down first down to their operational processes (just the next derivation step per capability)” * Vertical prioritisation means for example “which operational capability do we resolve down to the physical architecture before we start to resolve the next * capability” (image: 1-Grafik_1.png) * Both prioritisation methods are mixed to reach two targets in parallel: a) Use the capacity of all teams in parallel with different roles (vertical prioritisation), b) get a more and more full picture top-down (horizontal prioritisation). * A “mix” can for example be: “At first only all operational capabilities for standard train movements (no shunting etc.) and only the processes related to ETCS Level R without ATO are traced down to the physical architecture in the first step”. For the prioritisation these aspects are important: * As much as possible early usable results shall be created (year by year). * Example 1 (“bottom-up”): All traces, that lead to the EULYNX interfaces shall be resolved and approved fast. EULYNX interfaces should be standardized soon. * This means to import and resolve all traces, and to connect all interfaces to the overall architecture “upwards” (connecting workflow) * Example 2 (“top-down”): All traces for DAC shall be resolved fast, but there are not so much complete (resolved) traces to import in terms of processes and architecture. All operational capabilities and operational requirements for DAC need to be created and broken down and resolved down to the implementation (=vertical prioritisation). * Important decisions shall be decided early as a basis for all work * Example 3: (“horizontal prioritisation”): The process standardisation scope and depth shall be decided as early as possible. This means to create all operational capabilities, derive them town to operational processes, and assess every process impact on the later grade of standardisation of products. * Example 4 (“horizontal + vertical prioritisation”): The functional allocation and ambition in the logical architecture shall be decided as early as possible. For this, all operational capabilities need to be derived down to the logical architecture, and every logical component needs to be designed concerning the external dependencies that it has for other logical components (e.g. delegation of safety requirements from one to other components get only visible with the deep dive in the functional design).", -- "In general, there are two directions for prioritisation, which are “horizontal” or “vertical” * Horizontal prioritisation means for example “which of all operational capabilities do we break down first down to their operational processes (just the next derivation step per capability)” * Vertical prioritisation means for example “which operational capability do we resolve down to the physical architecture before we start to resolve the next * capability” (image: 1-Grafik_1.png) * Both prioritisation methods are mixed to reach two targets in parallel: a) Use the capacity of all teams in parallel with different roles (vertical prioritisation), b) get a more and more full picture top-down (horizontal prioritisation). * A “mix” can for example be: “At first only all operational capabilities for standard train movements (no shunting etc.) and only the processes related to ETCS Level R without ATO are traced down to the physical architecture in the first step”. For the prioritisation these aspects are important: * As much as possible early usable results shall be created (year by year). * Example 1 (“bottom-up”): All traces, that lead to the EULYNX interfaces shall be resolved and approved fast. EULYNX interfaces should be standardized soon. * This means to import and resolve all traces, and to connect all interfaces to the overall architecture “upwards” (connecting workflow) * Example 2 (“top-down”): All traces for DAC shall be resolved fast, but there are not so much complete (resolved) traces to import in terms of processes and architecture. All operational capabilities and operational requirements for DAC need to be created and broken down and resolved down to the implementation (=vertical prioritisation). * Important decisions shall be decided early as a basis for all work * Example 3: (“horizontal prioritisation”): The process standardisation scope and depth shall be decided as early as possible. This means to create all operational capabilities, derive them town to operational processes, and assess every process impact on the later grade of standardisation of products. * Example 4 (“horizontal + vertical prioritisation”): The functional allocation and ambition in the logical architecture shall be decided as early as possible. For this, all operational capabilities need to be derived down to the logical architecture, and every logical component needs to be designed concerning the external dependencies that it has for other logical components (e.g. delegation of safety requirements from one to other components get only visible with the deep dive in the functional design)." :diff_0915 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:WORKFLOW--PRIORITISATION--STRATEGY--TO--BE--DECIDED--PER--AREA_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
In general, there are two directions for prioritisation, which are “horizontal” or “vertical” * Horizontal prioritisation means for example “which of all operational capabilities do we break down first down to their operational processes (just the next derivation step per capability)” * Vertical prioritisation means for example “which operational capability do we resolve down to the physical architecture before we start to resolve the next * capability” (image: 1-Grafik_1.png) * Both prioritisation methods are mixed to reach two targets in parallel: a) Use the capacity of all teams in parallel with different roles (vertical prioritisation), b) get a more and more full picture top-down (horizontal prioritisation). * A “mix” can for example be: “At first only all operational capabilities for standard train movements (no shunting etc.) and only the processes related to ETCS Level R without ATO are traced down to the physical architecture in the first step”. For the prioritisation these aspects are important: * As much as possible early usable results shall be created (year by year). * Example 1 (“bottom-up”): All traces, that lead to the EULYNX interfaces shall be resolved and approved fast. EULYNX interfaces should be standardized soon. * This means to import and resolve all traces, and to connect all interfaces to the overall architecture “upwards” (connecting workflow) * Example 2 (“top-down”): All traces for DAC shall be resolved fast, but there are not so much complete (resolved) traces to import in terms of processes and architecture. All operational capabilities and operational requirements for DAC need to be created and broken down and resolved down to the implementation (=vertical prioritisation). * Important decisions shall be decided early as a basis for all work * Example 3: (“horizontal prioritisation”): The process standardisation scope and depth shall be decided as early as possible. This means to create all operational capabilities, derive them town to operational processes, and assess every process impact on the later grade of standardisation of products. * Example 4 (“horizontal + vertical prioritisation”): The functional allocation and ambition in the logical architecture shall be decided as early as possible. For this, all operational capabilities need to be derived down to the logical architecture, and every logical component needs to be designed concerning the external dependencies that it has for other logical components (e.g. delegation of safety requirements from one to other components get only visible with the deep dive in the functional design).
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:WORKFLOW--STEP--ON--STEP--IN--A--WORKITEM--TRACE_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A workflow step includes some of the following actions * “Create a trace”: The work item on the “top/start” of a trace is created based on external decisions. These are typically * Steering group decisions about system capabilities, common business objectives, improvement targets or problem descriptions, operational requirements, new safety requirements, etc. (see chapter below). * Technical regulations * “Derive” a work item: A team that is responsible for a derivation step in a trace for work items of a specific type looks for all unresolved work items and derives the resolving work items that are part of the own team scope. E.g., an ARC team sees unresolved actions in an operational process an derives all needed system requirements and functions that need to be worked out. * “Propose” a work item: A team or person receives (assignment) a work item with the status “proposed” from another team, that wants to resolve a dependency. E.g., an OD team designed an action in an operational process and “proposes” (“push”) a system requirement to an ARC team. * “Design / engineer / work out” a work item: The content of the work item is worked out. (e.g. an operational process with all actions) * “Break down” (“dependencies defined/delegated”) a work item: All necessary next work items are derived (as proposals) and linked. * “Resolve” a work item: All necessary next/downwards work items are derived, linked, designed, approved and resolved. E.g., all system functions to fulfil (resolve) an operational requirement are completed. * “Assign” a work item: The work item is assigned to a team or person that shall design it. * “Uplink” a work item. A “free floating” (not linked top-down, completely unlinked, or currently invalid) work item (e.g. coming from a bottom-up process or external contributor) is linked “upwards” to a “traced/valid” work item as if it had been derived from it before (e.g. a process is linked ex post to a capability). This is only done if this new link is really needed to resolve the traced work item in a correct way. Afterwards, the following “change action” is executed. * “Change a work item or link in an existing trace”: Because of a change of a work item or link in a trace the trace gets invalid in some parts(has “suspect links”). It must be reassured that the derivation process in all directions of the trace is correct, or otherwise further work items need to be adapted until all work items are resolved again. E.g., a system requirement lead to 5 system functions that are needed. One system function cannot be implemented. Therefore, all 5 derivations need to be reworked and perhaps all functions need to be deleted and the resolving process starts again. Other example for a suspect link: A function was derived from a requirement. Later the requirement is changed, and the link gets automatically suspect because it is not clear if the function is still implementing the requirement. * “Approve” a work item (see chapter below). An approval step is done in the ALM on work item level by experts based on their knowledge. The group of approvers is assigned depending on the work item type and content. A single approver agrees with an approval that a work item is correctly derived, designed, and broken. Approvals are done per single work items like requirements, concept paragraphs or operational requirements. Approval sessions are typically done for a selected set of work items. * “Decide a deliverable”. When all work items for a certain work area / release are resolved and approved, a document is generated for a formal decision process (e.g. an interface specification or a rulebook). * The typical sequence of actions in a work step is * Pull a work item or check proposed work items * Design the work item * Resolve the work item * Assign resolving work items to a team or person", -- "A workflow step includes some of the following actions * “Create a trace”: The work item on the “top/start” of a trace is created based on external decisions. These are typically * Steering group decisions about system capabilities, common business objectives, improvement targets or problem descriptions, operational requirements, new safety requirements, etc. (see chapter below). * Technical regulations * “Derive” a work item: A team that is responsible for a derivation step in a trace for work items of a specific type looks for all unresolved work items and derives the resolving work items that are part of the own team scope. E.g., an ARC team sees unresolved actions in an operational process an derives all needed system requirements and functions that need to be worked out. * “Propose” a work item: A team or person receives (assignment) a work item with the status “proposed” from another team, that wants to resolve a dependency. E.g., an OD team designed an action in an operational process and “proposes” (“push”) a system requirement to an ARC team. * “Design / engineer / work out” a work item: The content of the work item is worked out. (e.g. an operational process with all actions) * “Break down” (“dependencies defined/delegated”) a work item: All necessary next work items are derived (as proposals) and linked. * “Resolve” a work item: All necessary next/downwards work items are derived, linked, designed, approved and resolved. E.g., all system functions to fulfil (resolve) an operational requirement are completed. * “Assign” a work item: The work item is assigned to a team or person that shall design it. * “Uplink” a work item. A “free floating” (not linked top-down, completely unlinked, or currently invalid) work item (e.g. coming from a bottom-up process or external contributor) is linked “upwards” to a “traced/valid” work item as if it had been derived from it before (e.g. a process is linked ex post to a capability). This is only done if this new link is really needed to resolve the traced work item in a correct way. Afterwards, the following “change action” is executed. * “Change a work item or link in an existing trace”: Because of a change of a work item or link in a trace the trace gets invalid in some parts(has “suspect links”). It must be reassured that the derivation process in all directions of the trace is correct, or otherwise further work items need to be adapted until all work items are resolved again. E.g., a system requirement lead to 5 system functions that are needed. One system function cannot be implemented. Therefore, all 5 derivations need to be reworked and perhaps all functions need to be deleted and the resolving process starts again. Other example for a suspect link: A function was derived from a requirement. Later the requirement is changed, and the link gets automatically suspect because it is not clear if the function is still implementing the requirement. * “Approve” a work item (see chapter below). An approval step is done in the ALM on work item level by experts based on their knowledge. The group of approvers is assigned depending on the work item type and content. A single approver agrees with an approval that a work item is correctly derived, designed, and broken. Approvals are done per single work items like requirements, concept paragraphs or operational requirements. Approval sessions are typically done for a selected set of work items. * “Decide a deliverable”. When all work items for a certain work area / release are resolved and approved, a document is generated for a formal decision process (e.g. an interface specification or a rulebook). * The typical sequence of actions in a work step is * Pull a work item or check proposed work items * Design the work item * Resolve the work item * Assign resolving work items to a team or person" :diff_0916 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:WORKFLOW--STEP--ON--STEP--IN--A--WORKITEM--TRACE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
A workflow step includes some of the following actions * “Create a trace”: The work item on the “top/start” of a trace is created based on external decisions. These are typically * Steering group decisions about system capabilities, common business objectives, improvement targets or problem descriptions, operational requirements, new safety requirements, etc. (see chapter below). * Technical regulations * “Derive” a work item: A team that is responsible for a derivation step in a trace for work items of a specific type looks for all unresolved work items and derives the resolving work items that are part of the own team scope. E.g., an ARC team sees unresolved actions in an operational process an derives all needed system requirements and functions that need to be worked out. * “Propose” a work item: A team or person receives (assignment) a work item with the status “proposed” from another team, that wants to resolve a dependency. E.g., an OD team designed an action in an operational process and “proposes” (“push”) a system requirement to an ARC team. * “Design / engineer / work out” a work item: The content of the work item is worked out. (e.g. an operational process with all actions) * “Break down” (“dependencies defined/delegated”) a work item: All necessary next work items are derived (as proposals) and linked. * “Resolve” a work item: All necessary next/downwards work items are derived, linked, designed, approved and resolved. E.g., all system functions to fulfil (resolve) an operational requirement are completed. * “Assign” a work item: The work item is assigned to a team or person that shall design it. * “Uplink” a work item. A “free floating” (not linked top-down, completely unlinked, or currently invalid) work item (e.g. coming from a bottom-up process or external contributor) is linked “upwards” to a “traced/valid” work item as if it had been derived from it before (e.g. a process is linked ex post to a capability). This is only done if this new link is really needed to resolve the traced work item in a correct way. Afterwards, the following “change action” is executed. * “Change a work item or link in an existing trace”: Because of a change of a work item or link in a trace the trace gets invalid in some parts(has “suspect links”). It must be reassured that the derivation process in all directions of the trace is correct, or otherwise further work items need to be adapted until all work items are resolved again. E.g., a system requirement lead to 5 system functions that are needed. One system function cannot be implemented. Therefore, all 5 derivations need to be reworked and perhaps all functions need to be deleted and the resolving process starts again. Other example for a suspect link: A function was derived from a requirement. Later the requirement is changed, and the link gets automatically suspect because it is not clear if the function is still implementing the requirement. * “Approve” a work item (see chapter below). An approval step is done in the ALM on work item level by experts based on their knowledge. The group of approvers is assigned depending on the work item type and content. A single approver agrees with an approval that a work item is correctly derived, designed, and broken. Approvals are done per single work items like requirements, concept paragraphs or operational requirements. Approval sessions are typically done for a selected set of work items. * “Decide a deliverable”. When all work items for a certain work area / release are resolved and approved, a document is generated for a formal decision process (e.g. an interface specification or a rulebook). * The typical sequence of actions in a work step is * Pull a work item or check proposed work items * Design the work item * Resolve the work item * Assign resolving work items to a team or person
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:WORKSTEP--_WORKITEM--CHECK_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "* Is the workitem content correct and without inner contradictions? * Does the workitem content fit to the wokitem type? * Are all standard or custom workitem fields filled? * Does the workitem content implement the demands coming to it by existing links? * Do all mandatory links exist and are they completely fulfilling their role? Does the content fit to them? E.g. a system requirements can be implemented by a function... but it needs to be completely implemented and not partly.", -- "* Is the workitem content correct and without inner contradictions? * Does the workitem content fit to the wokitem type? * Are all standard or custom workitem fields filled? * Does the workitem content implement the demands coming to it by existing links? * Do all mandatory links exist and are they completely fulfilling their role? Does the content fit to them? E.g. a system requirements can be implemented by a function... but it needs to be completely implemented and not partly." :diff_0917 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:WORKSTEP--_WORKITEM--CHECK_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
* Is the workitem content correct and without inner contradictions? * Does the workitem content fit to the wokitem type? * Are all standard or custom workitem fields filled? * Does the workitem content implement the demands coming to it by existing links? * Do all mandatory links exist and are they completely fulfilling their role? Does the content fit to them? E.g. a system requirements can be implemented by a function... but it needs to be completely implemented and not partly.