diff/lex sp-defs-240716
target: lex sp-defs-240903#
versus: lex sp-defs-240716#
issued: 2024-09-03T09:43:35.227117
version date: 2024-01-11 16:37:49

diff/lex sp-defs-240716/diff 0740
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: CONFIGURATION--ITEM label
predicate: label
changes:
  changes: **++ "Configuration item"
  changes: **-- "Configuration Item"

diff/lex sp-defs-240716/diff 0785
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: ROLE label
predicate: label
changes:
  changes: **++ "Role"
  changes: **-- "Role."

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

diff/lex sp-defs-240716/diff 0807
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: WORK--ITEM label
predicate: label
changes:
  changes: **++ "Work Item"
  changes: **-- "Work item"

diff/lex sp-defs-240716/diff 0867
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: CONFIGURATION--ITEM lexForm
predicate: writtenRep
changes:
  changes: **++ "Configuration item"
  changes: **-- "Configuration Item"

diff/lex sp-defs-240716/diff 0914
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: ROLE lexForm
predicate: writtenRep
changes:
  changes: **++ "Role"
  changes: **-- "Role."

diff/lex sp-defs-240716/diff 0934
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: WORK--ITEM lexForm
predicate: writtenRep
changes:
  changes: **++ "Work Item"
  changes: **-- "Work item"

diff/lex sp-defs-240716/diff 0997
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: CONFIGURATION--ITEM lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TS-127456"
  changes: -- "SPPR-2045"

diff/lex sp-defs-240716/diff 0998
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: CONFIGURATION--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-240716/diff 1006
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DOCUMENT--EXCHANGE lexSense
predicate: identifier
changes:
  changes: ++ "SPPR-9160"

diff/lex sp-defs-240716/diff 1007
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DOCUMENT--EXCHANGE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :DOCUMENT--EXCHANGE_lexConcept_2

diff/lex sp-defs-240716/diff 1008
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DOCUMENT--GENERATION--AND--MANAGEMENT lexSense
predicate: identifier
changes:
  changes: ++ "SPPR-9158"

diff/lex sp-defs-240716/diff 1009
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DOCUMENT--GENERATION--AND--MANAGEMENT lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :DOCUMENT--GENERATION--AND--MANAGEMENT_lexConcept_2

diff/lex sp-defs-240716/diff 1010
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DOCUMENTS--PUBLICATION lexSense
predicate: identifier
changes:
  changes: ++ "SPPR-9159"

diff/lex sp-defs-240716/diff 1011
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DOCUMENTS--PUBLICATION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :DOCUMENTS--PUBLICATION_lexConcept_2

diff/lex sp-defs-240716/diff 1012
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: ESSENTIAL--FUNCTION lexSense
predicate: identifier
changes:
  changes: ++ "SPPRAMSS-9640"

diff/lex sp-defs-240716/diff 1013
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: ESSENTIAL--FUNCTION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :ESSENTIAL--FUNCTION_lexConcept_3

diff/lex sp-defs-240716/diff 1021
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: GASC lexSense
predicate: identifier
changes:
  changes: ++ "SPPRAMSS-8881"

diff/lex sp-defs-240716/diff 1022
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: GASC lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :GASC_lexConcept_2

diff/lex sp-defs-240716/diff 1023
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: GPSC lexSense
predicate: identifier
changes:
  changes: ++ "SPPRAMSS-8880"

diff/lex sp-defs-240716/diff 1024
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: GPSC lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :GPSC_lexConcept_2

diff/lex sp-defs-240716/diff 1036
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: LOGICAL--COMPONENT lexSense
predicate: identifier
changes:
  changes: -- "SPPR-2033"

diff/lex sp-defs-240716/diff 1037
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: LOGICAL--COMPONENT 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-240716/diff 1038
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: LOGICAL--COMPONENT lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :LOGICAL--COMPONENT_lexConcept_2

diff/lex sp-defs-240716/diff 1042
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-3868"

diff/lex sp-defs-240716/diff 1043
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/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_6

diff/lex sp-defs-240716/diff 1048
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-3869"

diff/lex sp-defs-240716/diff 1049
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/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_6

diff/lex sp-defs-240716/diff 1052
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: PIS-----PASSENGER--INFORMATION--SYSTEM lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-3870"

diff/lex sp-defs-240716/diff 1053
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: PIS-----PASSENGER--INFORMATION--SYSTEM lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_6

diff/lex sp-defs-240716/diff 1056
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: ROLE lexSense
predicate: subject
changes:
  changes: -- :"Polarion Workitem"
  changes: -- <https://dbpedia.org/property/workItem>
  changes: -- <https://en.wikipedia.org/wiki/Work_breakdown_structure>
  changes: -- <https://polarion.plm.automation.siemens.com/>

diff/lex sp-defs-240716/diff 1061
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SWITCH lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-883"

diff/lex sp-defs-240716/diff 1062
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SWITCH lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :SWITCH_lexConcept_5

diff/lex sp-defs-240716/diff 1063
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SYSTEM--CAPABILITY lexSense
predicate: identifier
changes:
  changes: -- "SPPR-2044"

diff/lex sp-defs-240716/diff 1064
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SYSTEM--CAPABILITY 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-240716/diff 1065
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SYSTEM--CAPABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :SYSTEM--CAPABILITY_lexConcept_2

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

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

diff/lex sp-defs-240716/diff 1074
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: THREAT--LANDSCAPE lexSense
predicate: identifier
changes:
  changes: ++ "SPPRAMSS-9642"

diff/lex sp-defs-240716/diff 1075
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: THREAT--LANDSCAPE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :THREAT--LANDSCAPE_lexConcept_2

diff/lex sp-defs-240716/diff 1081
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: VIEW lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-887"

diff/lex sp-defs-240716/diff 1082
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: VIEW lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :VIEW_lexConcept_2

diff/lex sp-defs-240716/diff 1083
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: WORK--ITEM lexSense
predicate: identifier
changes:
  changes: ++ "SPP-2894"

diff/lex sp-defs-240716/diff 1084
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: WORK--ITEM lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :WORK--ITEM_lexConcept_2

diff/lex sp-defs-240716/diff 1134
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/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 {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 w…
  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, …

diff/lex sp-defs-240716/diff 1137
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/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 standardised FFFIS compliant interface, but could be used for other applications on the train."
  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."

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

diff/lex sp-defs-240716/diff 1143
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: CATEGORISATION--OF--NATIONAL--MIGRATION--PHASES--FOR--A--SINGLE--COUNTRY lexConcept
predicate: definition
changes:
  changes: ++

diff/lex sp-defs-240716/diff 1144
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: CCS--DEPLOYMENT lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1147
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: CONFIGURATION--ITEM lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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"

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

diff/lex sp-defs-240716/diff 1157
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DISTRIBUTIONJOB-- DISTRIBUTION-JOB-JSON --DOCUMENT lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1159
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DOCUMENT--GENERATION--AND--MANAGEMENT lexConcept
predicate: definition
changes:
  changes: ++ "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 )."
  changes: -- "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}"

diff/lex sp-defs-240716/diff 1161
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: DOCUMENTS--PUBLICATION lexConcept
predicate: definition
changes:
  changes: ++ "Documents Publication is the creation of a document baseline and subsequent exportation in a defined exchangeable format (pdf, doc)."
  changes: -- "Documents Publication is the creation of a document baseline and subsequent exportation in a defined exchangeable format (pdf, doc). {comment:5}"

diff/lex sp-defs-240716/diff 1163
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/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 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,..."
  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,..."

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

diff/lex sp-defs-240716/diff 1165
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: ESSENTIAL--FUNCTION lexConcept 2
predicate: definition
changes:
  changes: ++ "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,..."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1168
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/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 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}"
  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)."

diff/lex sp-defs-240716/diff 1175
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: FUNCTIONAL--REQUIREMENTS lexConcept
predicate: definition
changes:
  changes: ++ "A requirement which specifies a function that a system has to do."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1176
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: FUNCTIONAL--SYSTEM--DEPLOYMENT--RULES lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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."

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

diff/lex sp-defs-240716/diff 1178
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: GASC lexConcept
predicate: definition
changes:
  changes: ++ "Generic Application Safety Case (from EN 50129:2018)"
  changes: -- "Generic Application Safety Case;SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] {comment:99},SPPRAMSS-335 - [EN 50126-2:2017]"

diff/lex sp-defs-240716/diff 1180
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: GPSC lexConcept
predicate: definition
changes:
  changes: ++ "Generic Product Safety Case (from EN 50129:2018)"
  changes: -- "Generic Product Safety Case; SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] {comment:100},SPPRAMSS-335 - [EN 50126-2:2017]"

diff/lex sp-defs-240716/diff 1184
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: HMI--COMPONENT lexConcept
predicate: definition
changes:
  changes: **++ "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."
  changes: **-- "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"

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

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

diff/lex sp-defs-240716/diff 1190
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/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 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)."
  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)."

diff/lex sp-defs-240716/diff 1197
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: LOGICAL--COMPONENT lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1204
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: MODULARITY lexConcept 2
predicate: definition
changes:
  changes: ++ "Modularity is used in this document as a general term for partinioning{comment:1395} a system/sub-system/module in sub-systems/modules."
  changes: -- "Modularity is used in this document as a general term for dividing{comment:1395} a system/sub-system/module in sub-systems/modules."

diff/lex sp-defs-240716/diff 1206
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: MOVING--BLOCK lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1212
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: PROCESS lexConcept
predicate: definition
changes:
  changes: ++ "Set of interrelated or interacting activities that use inputs to deliver an intended result. * Processes require a purpose and outcome, all processes have at least one activity. * A process defines “WHAT” is to be done, without specifying “HOW” each task is performed."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1215
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: ROLE lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "Role assigned to a actor"

diff/lex sp-defs-240716/diff 1216
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SECURE--COMPONENT lexConcept
predicate: definition
changes:
  changes: ++ "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…)"
  changes: -- "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…)"

diff/lex sp-defs-240716/diff 1217
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SEMP--REQUIREMENTS--TYPES lexConcept
predicate: definition
changes:
  changes: ++ "* 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."
  changes: -- "* 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."

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

diff/lex sp-defs-240716/diff 1221
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SUB-SYSTEM--SOMETIMES--CALLED-- BUILDING--BLOCK lexConcept
predicate: definition
changes:
  changes: ++ "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."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1224
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SWITCH lexConcept
predicate: definition
changes:
  changes: ++ "Switch Physical component which allows a selection of 2 to N states and keeps the state until its position is changed."
  changes: -- "Switch"

diff/lex sp-defs-240716/diff 1225
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SWITCH lexConcept 2
predicate: definition
changes:
  changes: ++ "Switch"
  changes: -- "a switch is a device that opens or closes electrical circuits."

diff/lex sp-defs-240716/diff 1226
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SWITCH lexConcept 4
predicate: definition
changes:
  changes: ++ "a switch is a device that opens or closes electrical circuits."
  changes: -- "Electrical switch. Closes or opens a circuit."

diff/lex sp-defs-240716/diff 1228
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SYSTEM--CAPABILITY lexConcept
predicate: definition
changes:
  changes: ++ "Description of a high-level behaviour of a system and its interaction with other involved entities, which yields an observable outcome. The system capability is the system’s expected ability to provide a high-level service allowing it to carry out an operational objective. A system capability represents a system usage context. It is characterised by a set of functional chains and scenarios that it references, and which more precisely describes the conditions for performing the system functions that contribute to it. A capability can also reference a function that contributes to it by itself. A capability can use one or more other capabilities that it will reference. Although the ARCADIA method describes system capabilities from the system perspective. We have decided that a deviation from the established method is preferred for our purposes. So the system capabilities shall be written from an actor's perspective, similar to use cases. In order to have a greater distinction between capability and function and to be compatible with SysML."
  changes: -- "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."

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

diff/lex sp-defs-240716/diff 1234
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: SYSTEM lexConcept
predicate: definition
changes:
  changes: ++ "Arrangement of system elements, that together exhibit a stated behaviour or meaning that the individual constituents do not. According to ISO 15288 a system is “a combination of interacting elements organised to achieve one or more stated purposes. “. In terms of this document, a system in black box view is furthermore defined by: * interfaces to actors outside the system, defining the system boundary * at least one function allocated to it * at least one capability that the system delivers as a service to the actors A system in white box view can be further refined into (exclusive or): * into a more granular systems, hence making itself to a system of systems * into subsystems on the lowest level of system of systems refinement In both cases, a system is a conceptual entity that aggregates the properties of its constituents but is not the element that defines the properties itself. A system is hence subject to the emerging properties of its constituents. Usage context definitions of term „system“: * Constituent system: according to ISO 21839, a system that forms part of a system of systems * System of interest: according to ISO 21839, a system whose life cycle or properties are under consideration in a given context"
  changes: -- "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"

diff/lex sp-defs-240716/diff 1237
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/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 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)"
  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)"

diff/lex sp-defs-240716/diff 1244
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: VIEW lexConcept
predicate: definition
changes:
  changes: ++ "View Aggregation of Areas required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time."
  changes: -- "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."

diff/lex sp-defs-240716/diff 1246
type: diff/lex sp-defs-240716/Object attribute changedValues
entity: diff/lex sp-defs-240716/entity
entity: WORK--ITEM lexConcept
predicate: definition
changes:
  changes: ++ "Polarion work item."
  changes: -- "* Work items examples: “A requirement”, or “a function”, or “a concept aspect” * Work items are objects in the “engineering database” (ALM) that represent the result of a design step. * The structure of the work items is defined by the SEMP process definition documents (overview in the maps), that also make use of modelling standards like ARCADIA or SysML * The master-engineering database is the ALM System (currently Polarion) which contains all work items and their links."