++ :SYSTEM--UNDER--CONSIDERATION_lexForm_3
-- <https://dbpedia.org/page/Arcadia_(engineering)>
-- <https://en.wikipedia.org/wiki/Arcadia_(engineering)>
++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_3
++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_4
++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_5
++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_3
++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_4
++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_5
++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_3
++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_4
++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_5
++ :RINF-----RINF--MEANS--REGISTER--OF--INFRASTRUCTURE---THE--RINF--COMPREHENSIVELY--DESCRIBES_lexConcept_2
++ :SYSTEM--UNDER--CONSIDERATION_lexConcept_2
++ "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 supported{comment:7} by 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}"
-- "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 the technical systems.{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. See Chapter 5.6 * 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}"
**++ "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"
++ "Basic Advanced Safe Train Positioning (Basic ASTP) is a new CCS-OB interoperability constituent providing Odometry functionality with to be defined performance and availability targets. Basic ASTP shall perform this function primarily for ERTMS/ETCS on-board equipment via a mandatory FFFIS compliant interface, but could be used for other applications on the train."
++ "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."
-- "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, configurationId and configurationVersion."
++ "Satus{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]."
-- "Satus 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]."
++ "A collection of standardized interface implementations of central security and IT communication functions in a back-office environment. Examples are Security Incident and Event Management System (SIEM), Intrusion Detection System, PKI Certificate Authority, Corporate Directory, Asset Management, DNS. These services are typically accessible for the automation network via controlled communication paths (e.g. DMZ). The interfaces from the Shared Security Services to the Enterprise Services are identified by ESI-<Service name>. Enterprise Shared Services are typically 3rd-party components not dedicated to the rail environment. Therefore the realization of the Enterprise Shared Services may use other security requirements than the Secure Component Specification. Recommended security specification are ISO 27033, ISO 27034, NIST 800-53, IEC 62443-4-2,..."
-- "A collection of standardized interface implementations of central security and IT communication functions in a back-office environment. Examples are Security Incident and Event Management System (SIEM), Intrusion Detection System, PKI Certificate Authority, Corporate Directory, Asset Management, DNS. These services are typically accessible for the automation network via controlled communication paths (e.g. DMZ). The interfaces from the Shared Security Services to the Enterprise Services are identified by ESI-<Service name>. Enterprise Shared Services are typically 3rd-party components not dedicated to the rail environment. Therefore the realization of the Enterprise Shared Services may use other security requirements than the Secure Component Specification. Recommended security specification are ISO 27..., NIST 800-53, IEC 62443-4-2,..."
++ "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{comment:1413} of sub-systems whereas interoperability is related to interactions between sub-systems (e.g. also between STM and ETCS on-board there is interoperability)."
-- "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 of sub-systems whereas interoperability is related to interactions between sub-systems (e.g. also between STM and ETCS on-board there is interoperability)."
++ "A Functional Exchange is a oriented possible flow between a source Function and a target Function, able to transmit exchange items from a Function Output Port to a Function Input Port. A System Functional Exchange is a Functional Exchange that takes place between two System Functions."
-- "possible flow of exchange items between 2 functions through their respective functional ports."
++ "A function in context of the System Pillar is a purpose-oriented and persistent transformation inputs into outputs with continuous behaviour through it's whole application. The functionality of the system appears to those observing from the outside as a collection of such transformation that are always available. Consequently, when the inputs to the system change, the transformations within the system modify the outputs accordingly. Functions can be also available in a range of system states and therefore change its behaviour based on the current state. The function's behavioural description describes the transformation of all possible values of inputs and outputs as defined in the exchange items flowing through the functional exchanges. It is defined by 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 transformation is in the sense of how a particular type of output is generated from a particular type of input for all possible input and output ranges (including absent or invalid inputs) - that is, treating the inputs and outputs as part of a continuous flow rather than triggers. This results in fewer and more general functions, where 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."
-- "A function transforms several one or more input values to several one or more output values according to the function’s behaviour. The function’s behaviour is defined by one or multiple functional requirements, defining “what” the function is doing. Additional non-functional requirements attached to the function define the quality attributes of “how” (how safe, how accurate, how fast, how reliable, etc.) the function is performing the transformation."
++ "A shared boundary between two systems, that interchange exchange items."
-- "Based on ISO/IEC 2382, a shared boundary between two systems or subsystems, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics."
++ "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 networks (IMs) 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)."
-- "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 networks (IMs) and that an infrastructure network 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)."
++ "The target of modularity means, that only harmonized interchangeable products should be developed."
-- "Modularity is used in this document as a general term for dividing a system/sub-system/module in sub-systems/modules."
++ "Modularity is used in this document as a general term for dividing{comment:1395} a system/sub-system/module in sub-systems/modules."
-- "The property of a system being composed of a coherent whole of single, independent building blocks or modules."
-- "implicit-from-entry-label: Multiple Independent Levels of Security or Safety"
++ "The Safety Layer implements all the technical safety principles related to fulfilling the requirements of EN 50126, EN 50716 (formerly 50128)%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22Physical%20Computing%26lt%3Bbr%26gt%3BElement%26amp%3Bnbsp%3B%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23D6D6D6%3BfontColor%3D%23333333%3BstrokeColor%3D%23666666%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-130%22%20y%3D%22410%22%20width%3D%22240%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%223%22%20value%3D%22Core%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23cac5d3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-120%22%20y%3D%22438%22%20width%3D%2240%22%20height%3D%2225%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%224%22%20value%3D%22Memory%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23cac5d3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%2250%22%20y%3D%22440%22%20width%3D%2250%22%20height%3D%2225%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%225%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BgradientColor%3Dnone%3Bglass%3D0%3Bshadow%3D0%3BfillStyle%3Dhatch%3BstrokeWidth%3D0.3%3BfillColor%3D%23404040%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22404%22%20width%3D%22370%22%20height%3D%2272%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%226%22%20value%3D%22I3%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-23.61%22%20y%3D%22305.5%22%20width%3D%2255%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%227%22%20value%3D%22I2%22%20style%3D%22shape%3Dnote%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BbackgroundOutline%3D1%3BdarkOpacity%3D0.05%3Bsize%3D15%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-100%22%20y%3D%22386%22%20width%3D%2230%22%20height%3D%2234%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%228%22%20value%3D%22Hardware%26lt%3Bbr%26gt%3B%26amp%3Bnbsp%3BLayer%22%20style%3D%22text%3Bhtml%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-235%22%20y%3D%22410%22%20width%3D%2290%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%229%22%20value%3D%22Virtualization%20%26lt%3Bbr%26gt%3BLayer%22%20style%3D%22text%3Bhtml%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22317.75%22%20width%3D%2290%22%20height%3D%2267%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2210%22%20value%3D%22I1%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3Brotation%3D90%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-155%22%20y%3D%22435%22%20width%3D%2235%22%20height%3D%2216%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2211%22%20value%3D%22I1%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3Brotation%3D90%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-150%22%20y%3D%22345%22%20width%3D%2235%22%20height%3D%2216%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2212%22%20value%3D%22Virtualisation%20Environment%26lt%3Bbr%26gt%3B%26lt%3Bbr%26gt%3BVirtual%20Computing%20Element%26lt%3Bbr%20style%3D%26quot%3Bborder-color%3A%20var(--border-color)%3B%26quot%3B%26gt%3B%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23d5e8d4%3BstrokeColor%3D%2382b366%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-126%22%20y%3D%22325.5%22%20width%3D%22251%22%20height%3D%2243.5%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2213%22%20value%3D%22Runtime%26lt%3Bbr%26gt%3BLayer%22%20style%3D%22text%3Bhtml%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22163%22%20width%3D%22100%22%20height%3D%2267%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2214%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BgradientColor%3Dnone%3Bglass%3D0%3Bshadow%3D0%3BfillStyle%3Dhatch%3BstrokeWidth%3D0.3%3BfillColor%3D%23404040%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22314%22%20width%3D%22370%22%20height%3D%2272%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2215%22%20value%3D%22RTE%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-118.21%22%20y%3D%22190%22%20width%3D%22158.21%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2216%22%20value%3D%22I1%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3Brotation%3D90%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-138.10999999999999%22%20y%3D%22197%22%20width%3D%2228.11%22%20height%3D%2216%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2217%22%20value%3D%22I4%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-54.599999999999994%22%20y%3D%22172.68%22%20width%3D%2230.99%22%20height%3D%2217.32%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2218%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BgradientColor%3Dnone%3Bglass%3D0%3Bshadow%3D0%3BfillStyle%3Dhatch%3BstrokeWidth%3D0.3%3BfillColor%3D%23404040%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-210%22%20y%3D%22172.68%22%20width%3D%22310%22%20height%3D%2272%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2219%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3Dnone%3Bdashed%3D1%3BstrokeWidth%3D2%3BstrokeColor%3D%23FF1D0D%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22170%22%20width%3D%22350%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2220%22%20value%3D%22%22%20style%3D%22shape%3DflexArrow%3BendArrow%3Dclassic%3Bhtml%3D1%3Brounded%3D0%3B%22%20edge%3D%221%22%20target%3D%2214%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2250%22%20height%3D%2250%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-50%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20y%3D%22200%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2221%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3Dnone%3BstrokeWidth%3D2%3BstrokeColor%3D%23000000%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-230%22%20y%3D%22305.5%22%20width%3D%22390%22%20height%3D%22200%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E, EN 50129, EN 50159 (e.g., composite fail safety, fault tolerance, voting mechanisms, redundancy mechanisms for availability, safety communication layers etc.) that are needed to enable the execution of Functional Applications up to SIL4.{comment:1}"
-- "The Safety Layer implements all the technical safety principles related to fulfilling the requirements of EN 50126, EN 50128, EN 50129, EN 50159 (e.g., composite fail safety, fault tolerance, voting mechanisms, redundancy mechanisms for availability, safety communication layers etc.) that are needed to enable the execution of Functional Applications up to SIL4.{comment:1}"
++ "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."
-- "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 abstraction levels: 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."
++ "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."
-- "Someone who is entitled to express needs for the system of interest. 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."
++ "NOTE: This work item will be updated and replaced. The upcoming approach can be found here which is currently work in progress: List of System Pillar deliverables List of deliverables per subsystem (System Level 5) * ORS is done for System Level 3, and then tailored for the subsystems (especially CONEMP processes are done only on System Level 5). System specific Operational Requirement Specification (ORS) -> will be replaced by SPPR-7913 - Missing cross-reference D2.1 As-Is analysis D2.2 Referred CBO and railway requirements D2.3 Problem analysis and derived process improvements D2.4 Application categories D2.5 Operational requirements (incl. non-functional and process requirements) D2.6 Operational entities and actor D2.7 Operational capabilities D2.8 PRAMSS targets, strategies and indicators D2.9 Operational processes D2.10 Operational hazards and risks D2.11 Rule books for all actors D2.12 The concept for the operational migrationFunctional Requirement Specification (FRS) -> will be replaced by SPPR-7906 - Missing cross-reference D3.1 System definition D3.2 Detailed system actor descriptions and roles D3.3 System capabilities D3.4 Functional chains and sequences per capability D3.5 Function specification D3.6 Functional hazards and risksSystem requirement Specification (SRS) -> will be replaced by SPPR-7923 - Missing cross-reference, SPPR-7924 - Missing cross-reference and SPPR-7925 - Missing cross-reference D4.1 Architecture of systems of the next level (if standardized) D4.2 Functional allocation to logical components D4.3 Physical architecture D4.4 Technical and physical hazards and risks D4.5 The technical migration strategy is defined D4.6 System requirements and interface specification, incl. legacy adpaters D4.7 Non-functional System requirementsApplication specification (ARS) D5.1 Release and Implementation Configurations D5.2 Application conditions, CSM/CST, HSI Plan D5.3 Application/life cycle/usage guideline/rules D5.4 Engineering and maintenance guideline/rules D5.5 Validation and test specificationValidation and test specification (VRS) D6.1 Model checking specification D6.2 Simulation/test environment specification D6.3 Simulation/test/validation cases and dataStandardisation and CCM documentation D7.1 Standardisation packages and publications D7.2 External quality and experience monitoring for the standard is set up D7.2 External change management documentation"
-- "Deliverables are “output documents” that are automatically or manually created and exported from the engineering database (ALM) in the predefined structure of the SP deliverable templates List of deliverables per subsystem (System Level 5). ORS is done for System Level 3, and then tailored for the subsystems (especially CONEMP processes are done only on System Level 5). System specific Operational Requirement Specification (ORS) D2.1 As-Is analysis D2.2 Referred CBO and railway requirements D2.3 Problem analysis and derived process improvements D2.4 Application categories D2.5 Operational requirements (incl. non-functional and process requirements) D2.6 Operational entities and actor D2.7 Operational capabilities D2.8 PRAMSS targets, strategies and indicators D2.9 Operational processes D2.10 Operational hazards and risks D2.11 Rule books for all actors D2.12 The concept for the operational migrationFunctional Requirement Specification (FRS) D3.1 System definition D3.2 Detailed system actor descriptions and roles D3.3 System capabilities D3.4 Functional chains and sequences per capability D3.5 Function specification D3.6 Functional hazards and risksSystem requirement Specification (SRS) D4.1 Architecture of systems of the next level (if standardized) D4.2 Functional allocation to logical components D4.3 Physical architecture D4.4 Technical and physical hazards and risks D4.5 The technical migration strategy is defined D4.6 System requirements and interface specification, incl. legacy adpaters D4.7 Non-functional System requirementsApplication specification (ARS) D5.1 Release and Implementation Configurations D5.2 Application conditions, CSM/CST, HSI Plan D5.3 Application/life cycle/usage guideline/rules D5.4 Engineering and maintenance guideline/rules D5.5 Validation and test specificationValidation and test specification (VRS) D6.1 Model checking specification D6.2 Simulation/test environment specification D6.3 Simulation/test/validation cases and dataStandardisation and CCM documentation D7.1 Standardisation packages and publications D7.2 External quality and experience monitoring for the standard is set up D7.2 External change management documentation"
-- "System under Consideration [SOURCE: SPPRAMSS-4697 - [EN IEC 62443-3-2:2020]]"
++ "Threat landscape is used in this document as synonym for threat environment. Threat environment (definition from CENELEC TS50701, IEC PT63452) 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 landscape (definition from IEC 62443-3-2) Summary of available threat information such as threat sources, threat vectors and trends that may affect a defined target (for example, company, facility or SuC)."