-- :SYSTEM--UNDER--CONSIDERATION_lexForm_3
-- <https://dbpedia.org/page/Arcadia_(engineering)>
-- <https://en.wikipedia.org/wiki/Arcadia_(engineering)>
++ :DOCUMENT--GENERATION--AND--MANAGEMENT_lexConcept_2
++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_6
++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_6
++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_6
-- <https://dbpedia.org/property/workItem>
-- <https://en.wikipedia.org/wiki/Work_breakdown_structure>
-- <https://polarion.plm.automation.siemens.com/>
-- :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 {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}"
-- "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}"
++ "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 standardised FFFIS compliant interface, but could be used for other applications on the train."
-- "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."
++ "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."
-- "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 safe and non-safe Top-Level BuildingBlockConfigurations (BBC) and their dependencies."
++ "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."
-- "part of the system that must be engineered, produced or bought, duplicated as much as it is used in the system and assembled with others in order to build a copy of the system"
++ "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]."
-- "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]."
++ "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 safe and non-safe Top Level BuildingBlockConfigurations (BBC) as a dependency, that have in turn their recursive dependency trees. The distribution-job is defined within a distribution-job.json document that is validated by the distribution-job.schema.json."
++ "Document Generation is the collection of information/workitems, and its following updating/review, within a single document having a specific scope and foreseen by the Documents Management Plan. The document generation shall be executed by the task that is in charge of the document (as foreseen by the Documents Management Plan). Templates from SP-Central Modelling Service shall be used (80 Templates )."
-- "Document Generation is the collection of information/workitems,{comment:3} and its following updating/review, within a single document having a specific scope and foreseen by the Documents Management Plan.{comment:4} The document generation shall be executed by the task that is in charge of the document (as foreseen by the Documents Management Plan). Templates from SP-Central Modelling Service shall be used (80 Templates ).{comment:27}"
++ "Documents Publication is the creation of a document baseline and subsequent exportation in a defined exchangeable format (pdf, doc)."
-- "Documents Publication is the creation of a document baseline and subsequent exportation in a defined exchangeable format (pdf, doc). {comment:5}"
++ "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 Cybersecurity 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 27033, ISO 27034, NIST 800-53, IEC 62443-4-2,..."
++ "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."
++ "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,..."
++ "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}"
-- "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)."
++ "A requirement which specifies a function that a system has to do."
-- "Functional Requirements specify the functions of the system. What the system has to do in order to achieve the Operational Requirement. They capture and define the sub-purposes of the overall system purpose (given in the operational requirements). Since Functional Requirements specify the functions of the system that are best described as a verb-noun phrase that defines an action on an object."
++ "The Functional System Deployment Rules comprises all necessary information for deploying the respective Functional System onto specific approved Compartment Execution Environment(s). These deployment rules are compiled as part of the FS integration process and are part of each integrated, tested and qualified/approved Functional System along with its FS Compartments and all necessary approval documentation."
-- "The Functional System Deployment Rules comprises all necessary information for deploying the respective Functional System onto specific approved Compartment Execution Environment(s). These deployment rules are compiled as part of the FS integration process and are part of each integrated, tested and certified/approved Functional System along with its FS Compartments and all necessary approval documentation."
++ "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."
-- "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."
++ "Generic Application Safety Case (from EN 50129:2018)"
-- "Generic Application Safety Case;SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] {comment:99},SPPRAMSS-335 - [EN 50126-2:2017]"
++ "Generic Product Safety Case (from EN 50129:2018)"
**++ "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."
**-- "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"
++ "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)."
-- "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 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 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)."
-- "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)."
++ "An abstraction of a system that performs the system functions without imposing restrictions on implementation. Logical components are also only connected via FIS and not via FFFIS interfaces."
-- "An aggregation of logical functions that together fulfil a very specific task. Logical components are not yet allocated to a specific location kind (trackside or onboard) nor do they have any physical properties or requirements (like space requirements, permitted temperature ranges, etc.). Logical components are also only connected via FIS and not via FFFIS interfaces. Logical components or part of their logical functions are allocated to subsystems to define the subsystem behaviour."
++ "Modularity is used in this document as a general term for partinioning{comment:1395} 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 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(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 integrity."
++ "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."
-- "A set of interrelated or interacting set of cohesive process tasks that transforms inputs into outputs. The Processes require a purpose and outcome, all processes have at least one process task."
++ "A role is described by a set of responsibilities. Roles are used to define the responsibilities of tasks, ensuring that individuals or a group of people perform their assign tasks and contribute to their successful execution."
++ "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…)"
-- "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 Security Services Examples of CCS secure components are object controller, trackside cabinet, IXL rack, ATO-OB, OBU, ATO-TS, IXL/RBC combination, shared security services…)"
++ "* Common Business Objectives (CBO): High level objectives defining the mandate of the System Pillar. They are derived by Tasks and domains. They are not created in the Tasks and Domains. They can be formulated freely; * Railway Requirements: are operational epics that formulate concrete visions and user stories 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 shall be specific enough to be assigned to exactly one System Pillar Task; * Operational Requirements: Are precise requirements that the Operational Analysis shall fulfil. They include PRAMSS and other non functional requirements; * Functional System Requirements: they are system requirements that the System Analysis, Logical Architecture or Subsystem Architecture shall fulfil and specify the functions of the System; * Non-Functional System Requirements: Are precise requirements that the System Analysis, Logical Architecture or Subsystem Architecture shall fulfil. They include PRAMSS and other non functional requirements. * Application Conditions + SRAC definitions: are precise requirements that the environment of the System In Use shall fulfill. They include physical needs, skill levels of maintenance personal, temperatures of server rooms, engineering rules, etc. The SRAC are specific application conditions relevant to safety."
-- "* Common Business Objectives (CBO): High level objectives defining the mandate of the System Pillar. They are derived by Tasks and domains. They are not created in the Tasks and Domains. They can be formulated freely;{comment:48} * Railway Requirements: are operational epics that formulate concrete visions and user stories 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 shall be specific enough to be assigned to exactly one System Pillar Task;{comment:49} * Operational Requirements: Are precise requirements that the Operational Analysis shall fulfil. {comment:24}They include PRAMSS and other non functional requirements; * Functional System Requirements: {comment:7}they are system requirements that the System Analysis, Logical Architecture or Subsystem Architecture shall fulfil and specify the functions of the System;{comment:14} * Non-Functional System Requirements: Are precise {comment:15}requirements that the System Analysis, Logical Architecture or Subsystem Architecture{comment:8} shall fulfil. They include PRAMSS and other non functional requirements.{comment:19} * Application Conditions + SRAC definitions: are precise requirements that the {comment:25}environment of the System In Use shall fulfill. They include physical needs, skill levels of maintenance personal, temperatures of server rooms, engineering rules, etc. The SRAC{comment:58} are specific application conditions relevant to safety."
++ "A collection of standardized interfaces of central security functions accessible for all Secure Components in the automation solution. Examples of shared cybersecurity services are TIME, IAM, SSO, PKI, LOG, and BKP. The realization of the shared cybersecurity services implement the requirements of the Secure Component Specification as they are considered also are as Secure Components. The interfaces from Secure Components to Shared Cybersecurity Service are identified by SSI-<Service name>."
-- "A collection of standardized interfaces of central security functions accessible for all Secure Components in the automation solution. Examples of shared cybersecurity services are TIME, IAM, SSO, PKI, LOG, and BKP. The realization of the shared security services implement the requirements of the Secure Component Specification as they are considered also are as Secure Components. The interfaces from Secure Components to Shared Cybersecurity Service are identified by SSI-<Service name>."
++ "Sub-systems are along ARCADIA systems on System Level 5. Not to be confused with sub-systems in the TSI / interoperability directive. In the TSI / interoperability directive context a sub-system shall be regarded as a interoperability constituent{comment:1505} A sub-system is a part of a system, which is not split into smaller entities. It represents a leaf element in the hierarchy of systems-of-systems. Physically speaking, a sub-system is either a piece of hardware plus software, or just a piece of software. A sub-system is a source able unit of the CCS system, in particular: * a sub-system can be individually tendered to a supplier, * a sub-system can be built individually by a supplier, * a sub-system must be integrated into a system, which includes all necessary test, verification, certification and validation activities depending on the level of harmonisation. The harmonisation of the sub-system’s features is to be defined according to the requested level: * Functional Apportionment, * Interoperability, * Exchangeability, or * Interchangeability."
-- "Sub-systems are along ARCADIA systems on System Level 5. Not to be confused with sub-systems in the TSI / interoperability directive. In the TSI / interoperability directive context a sub-system shall be regarded as a interoperability constituent A sub-system is a part of a system, which is not split into smaller entities. It represents a leaf element in the hierarchy of systems-of-systems. Physically speaking, a sub-system is either a piece of hardware plus software, or just a piece of software. A sub-system is a source able unit of the CCS system, in particular: * a sub-system can be individually tendered to a supplier, * a sub-system can be built individually by a supplier, * a sub-system must be integrated into a system, which includes all necessary test, verification, certification and validation activities depending on the level of harmonisation. The harmonisation of the sub-system’s features is to be defined according to the requested level: * Functional Apportionment, * Interoperability, * Exchangeability, or * Interchangeability."
++ "Switch Physical component which allows a selection of 2 to N states and keeps the state until its position is changed."
-- "a switch is a device that opens or closes electrical circuits."
++ "a switch is a device that opens or closes electrical circuits."
-- "Electrical switch. Closes or opens a circuit."
++ "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."
-- "The system capability as part of the the system analysis 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."
++ "System under Consideration [SOURCE: SPPRAMSS-4697 - [EN IEC 62443-3-2:2020]]"
++ "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"
-- "According to ISO 15288 a system is “a combination of interacting elements organized 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 system 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"
++ "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 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)"
++ "View Aggregation of Areas required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time."
-- "A view is a filter that restricts the set of data types to a subset that is of interest in the context of a use case. Filtering is by discipline and spatially."
-- "* 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."