diff/lex sp-defs-240619
target: lex sp-defs-240716#
versus: lex sp-defs-240619#
issued: 2024-07-16T14:45:28.577519
version date: 2024-01-11 16:37:49

diff/lex sp-defs-240619/diff 0025
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: SYSTEM--UNDER--CONSIDERATION acronym
predicate: canonicalForm
changes:
  changes: ++ :SYSTEM--UNDER--CONSIDERATION_lexForm_3

diff/lex sp-defs-240619/diff 0073
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: DEFINITION lexSense
predicate: identifier
changes:
  changes: -- "SPPR-2290"

diff/lex sp-defs-240619/diff 0074
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: DEFINITION lexSense
predicate: subject
changes:
  changes: -- :"ARCADIA Method"
  changes: -- <https://dbpedia.org/page/Arcadia_(engineering)>
  changes: -- <https://en.wikipedia.org/wiki/Arcadia_(engineering)>

diff/lex sp-defs-240619/diff 0075
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: DEFINITION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :DEFINITION_lexConcept_2

diff/lex sp-defs-240619/diff 0077
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: EXCHANGE--ITEM lexSense
predicate: subject
changes:
  changes: -- :"ARCADIA Method"
  changes: -- <https://dbpedia.org/page/Arcadia_(engineering)>
  changes: -- <https://en.wikipedia.org/wiki/Arcadia_(engineering)>

diff/lex sp-defs-240619/diff 0085
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: INTERFACE lexSense
predicate: identifier
changes:
  changes: -- "SPPR-2032"

diff/lex sp-defs-240619/diff 0086
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: INTERFACE lexSense
predicate: subject
changes:
  changes: -- :"ARCADIA Method"
  changes: -- <https://dbpedia.org/page/Arcadia_(engineering)>
  changes: -- <https://en.wikipedia.org/wiki/Arcadia_(engineering)>

diff/lex sp-defs-240619/diff 0087
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: INTERFACE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :INTERFACE_lexConcept_3

diff/lex sp-defs-240619/diff 0088
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-2767"
  changes: ++ "SPT2TRAIN-2898"
  changes: ++ "SPT2TRAIN-3184"

diff/lex sp-defs-240619/diff 0089
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_3
  changes: ++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_4
  changes: ++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_5

diff/lex sp-defs-240619/diff 0091
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: MODULARITY lexSense
predicate: identifier
changes:
  changes: ++ "SPP-2239"

diff/lex sp-defs-240619/diff 0092
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: MODULARITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :MODULARITY_lexConcept_4

diff/lex sp-defs-240619/diff 0094
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-2768"
  changes: ++ "SPT2TRAIN-2899"
  changes: ++ "SPT2TRAIN-3185"

diff/lex sp-defs-240619/diff 0095
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_3
  changes: ++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_4
  changes: ++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_5

diff/lex sp-defs-240619/diff 0096
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: PIS-----PASSENGER--INFORMATION--SYSTEM lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-2769"
  changes: ++ "SPT2TRAIN-2900"
  changes: ++ "SPT2TRAIN-3186"

diff/lex sp-defs-240619/diff 0097
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: PIS-----PASSENGER--INFORMATION--SYSTEM lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_3
  changes: ++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_4
  changes: ++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_5

diff/lex sp-defs-240619/diff 0099
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: RINF-----RINF--MEANS--REGISTER--OF--INFRASTRUCTURE---THE--RINF--COMPREHENSIVELY--DESCRIBES lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-3002"

diff/lex sp-defs-240619/diff 0100
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: RINF-----RINF--MEANS--REGISTER--OF--INFRASTRUCTURE---THE--RINF--COMPREHENSIVELY--DESCRIBES lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :RINF-----RINF--MEANS--REGISTER--OF--INFRASTRUCTURE---THE--RINF--COMPREHENSIVELY--DESCRIBES_lexConcept_2

diff/lex sp-defs-240619/diff 0101
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: SCENARIO lexSense
predicate: subject
changes:
  changes: -- :"ARCADIA Method"
  changes: -- <https://dbpedia.org/page/Arcadia_(engineering)>
  changes: -- <https://en.wikipedia.org/wiki/Arcadia_(engineering)>

diff/lex sp-defs-240619/diff 0104
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: SYSTEM--UNDER--CONSIDERATION lexSense
predicate: identifier
changes:
  changes: ++ "SPPRAMSS-8882"

diff/lex sp-defs-240619/diff 0105
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: SYSTEM--UNDER--CONSIDERATION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :SYSTEM--UNDER--CONSIDERATION_lexConcept_2

diff/lex sp-defs-240619/diff 0116
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: ARCHITECTURAL--CONCEPT lexConcept
predicate: definition
changes:
  changes: ++ "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, …
  changes: -- "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 …

diff/lex sp-defs-240619/diff 0117
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: ATO--AUTOMATIC--TRAIN--OPERATION--AOC--AREA--OF--CONTROL--CCS--CONTROL--COMMAND--AND--SIGNAL lexConcept
predicate: definition
changes:
  changes: **++ "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"
  changes: **-- "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"

diff/lex sp-defs-240619/diff 0118
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: BASIC--ADVANCED--SAFE--TRAIN--POSITIONING--BASIC--ASTP lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: --
  changes: type

diff/lex sp-defs-240619/diff 0119
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: BUILDING--BLOCK--CONFIGURATION lexConcept
predicate: definition
changes:
  changes: ++
  changes: type

diff/lex sp-defs-240619/diff 0120
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: BUILDING--BLOCK lexConcept 2
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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."

diff/lex sp-defs-240619/diff 0122
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: CROSS-ACCEPTANCE lexConcept
predicate: definition
changes:
  changes: ++ "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]."
  changes: -- "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]."

diff/lex sp-defs-240619/diff 0123
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: ENTERPRISE--SHARED--SERVICES lexConcept
predicate: definition
changes:
  changes: ++ "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,..."
  changes: -- "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,..."

diff/lex sp-defs-240619/diff 0125
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: EXCHANGEABILITY lexConcept
predicate: definition
changes:
  changes: ++ "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)."
  changes: -- "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)."

diff/lex sp-defs-240619/diff 0127
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: FUNCTIONAL--EXCHANGE lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "possible flow of exchange items between 2 functions through their respective functional ports."

diff/lex sp-defs-240619/diff 0129
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: FUNCTION lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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."

diff/lex sp-defs-240619/diff 0135
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: INTERFACE lexConcept
predicate: definition
changes:
  changes: ++

diff/lex sp-defs-240619/diff 0136
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: INTERFACE lexConcept 2
predicate: definition
changes:
  changes: ++ "A shared boundary between two systems, that interchange exchange items."
  changes: -- "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."

diff/lex sp-defs-240619/diff 0137
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: INTEROPERABILITY lexConcept 2
predicate: definition
changes:
  changes: ++ "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)."
  changes: -- "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)."

diff/lex sp-defs-240619/diff 0142
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: MODULARITY lexConcept
predicate: definition
changes:
  changes: ++ "The target of modularity means, that only harmonized interchangeable products should be developed."
  changes: -- "Modularity is used in this document as a general term for dividing a system/sub-system/module in sub-systems/modules."

diff/lex sp-defs-240619/diff 0143
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: MODULARITY lexConcept 2
predicate: definition
changes:
  changes: ++ "Modularity is used in this document as a general term for dividing{comment:1395} a system/sub-system/module in sub-systems/modules."
  changes: -- "The property of a system being composed of a coherent whole of single, independent building blocks or modules."

diff/lex sp-defs-240619/diff 0145
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: MULTIPLE--INDEPENDENT--LEVELS--OF--SECURITY--OR--SAFETY lexConcept
predicate: definition
changes:
  changes: ++ "{comment:82}"
  changes: -- "implicit-from-entry-label: Multiple Independent Levels of Security or Safety"

diff/lex sp-defs-240619/diff 0150
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: OPERATIONAL--SCENARIO lexConcept
predicate: definition
changes:
  changes: ++ "See SPPR-2066 - Scenario"
  changes: -- "See SPPR-2066 - ARCADIA Scenario"

diff/lex sp-defs-240619/diff 0156
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: SAFETY--LAYER lexConcept
predicate: definition
changes:
  changes: ++ "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%3CmxCe…
  changes: -- "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}"

diff/lex sp-defs-240619/diff 0157
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: SCENARIO lexConcept
predicate: definition
changes:
  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). 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."
  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). 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."

diff/lex sp-defs-240619/diff 0160
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: STAKEHOLDER lexConcept
predicate: definition
changes:
  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."
  changes: -- "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."

diff/lex sp-defs-240619/diff 0161
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: SYSTEM--PILLAR--DELIVERABLES-- OUTPUT--DOCUMENTS lexConcept
predicate: definition
changes:
  changes: ++ "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 g…
  changes: -- "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 dataStandardis…

diff/lex sp-defs-240619/diff 0162
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: SYSTEM--UNDER--CONSIDERATION lexConcept
predicate: definition
changes:
  changes: ++ "System under Consideration"
  changes: -- "System under Consideration [SOURCE: SPPRAMSS-4697 - [EN IEC 62443-3-2:2020]]"

diff/lex sp-defs-240619/diff 0165
type: diff/lex sp-defs-240619/Object attribute changedValues
entity: diff/lex sp-defs-240619/entity
entity: THREAT--LANDSCAPE lexConcept
predicate: definition
changes:
  changes: ++ "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)"
  changes: -- "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)."