diff/lex sp-defs-231012
target: lex sp-defs-231113#
versus: lex sp-defs-231012#
issued: 2024-01-11T16:42:51.023489
version date: 2024-01-11 16:37:49
type: 1
type: 2
type: 3
type: 4
type: 5
…: 1
…: , --
…: 21839
…: type
…: 15288

diff/lex sp-defs-231012/diff 1257
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: ADAPTABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :ADAPTABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1259
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: AUTOMATIC--CONFLICT--SOLUTION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :AUTOMATIC--CONFLICT--SOLUTION_lexConcept_2

diff/lex sp-defs-231012/diff 1260
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPABILITY--MEANING lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :CAPABILITY--MEANING_lexConcept_2

diff/lex sp-defs-231012/diff 1261
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPACITY--PLAN--AND--DECISION--PROCESSING lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :CAPACITY--PLAN--AND--DECISION--PROCESSING_lexConcept_2

diff/lex sp-defs-231012/diff 1262
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPACITY--WASTE--MEANS lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :CAPACITY--WASTE--MEANS_lexConcept_2

diff/lex sp-defs-231012/diff 1263
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPACITY-FRIENDLY--BEHAVIOUR--MEANS lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :CAPACITY-FRIENDLY--BEHAVIOUR--MEANS_lexConcept_2

diff/lex sp-defs-231012/diff 1264
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPEX lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :CAPEX_lexConcept_2

diff/lex sp-defs-231012/diff 1265
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CHANGEABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :CHANGEABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1273
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: DEVIATION--DETECTION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :DEVIATION--DETECTION_lexConcept_2

diff/lex sp-defs-231012/diff 1280
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: ERTMS lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :ERTMS_lexConcept_3

diff/lex sp-defs-231012/diff 1284
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: EVOLVABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :EVOLVABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1285
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: EXCHANGEABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :EXCHANGEABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1288
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FFFIS-----FORM--FIT--FUNCTIONAL--INTERFACE--SPECIFICATION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :FFFIS-----FORM--FIT--FUNCTIONAL--INTERFACE--SPECIFICATION_lexConcept_2

diff/lex sp-defs-231012/diff 1289
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FIS-----FUNCTIONAL--INTERFACE--SPECIFICATION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :FIS-----FUNCTIONAL--INTERFACE--SPECIFICATION_lexConcept_3

diff/lex sp-defs-231012/diff 1291
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FUNCTIONAL--APPORTIONMENT lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :FUNCTIONAL--APPORTIONMENT_lexConcept_2

diff/lex sp-defs-231012/diff 1292
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: GRANULARITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :GRANULARITY_lexConcept_2

diff/lex sp-defs-231012/diff 1293
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: GRANULARIZATION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :GRANULARIZATION_lexConcept_2

diff/lex sp-defs-231012/diff 1296
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: HUMAN--MACHINE--INTERFACE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :HUMAN--MACHINE--INTERFACE_lexConcept_3

diff/lex sp-defs-231012/diff 1297
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INCIDENT--IMPACT--MANAGEMENT lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :INCIDENT--IMPACT--MANAGEMENT_lexConcept_2

diff/lex sp-defs-231012/diff 1299
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INTERCHANGEABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :INTERCHANGEABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1300
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INTERFACE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :INTERFACE_lexConcept_4

diff/lex sp-defs-231012/diff 1301
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INTEROPERABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :INTEROPERABILITY_lexConcept_3

diff/lex sp-defs-231012/diff 1302
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MAINTAINABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :MAINTAINABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1304
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MODULARITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :MODULARITY_lexConcept_4

diff/lex sp-defs-231012/diff 1305
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: NARROW--INTERFACES lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :NARROW--INTERFACES_lexConcept_2

diff/lex sp-defs-231012/diff 1311
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OPEX lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :OPEX_lexConcept_2

diff/lex sp-defs-231012/diff 1313
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: PORTABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :PORTABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1315
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: REAL-TIME--CONFLICT--DETECTION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :REAL-TIME--CONFLICT--DETECTION_lexConcept_2

diff/lex sp-defs-231012/diff 1318
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: REUSABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :REUSABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1324
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SCALABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :SCALABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1325
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SECTIONAL--RUNTIME--CALCULATION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :SECTIONAL--RUNTIME--CALCULATION_lexConcept_2

diff/lex sp-defs-231012/diff 1330
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SSI lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :SSI_lexConcept_2

diff/lex sp-defs-231012/diff 1331
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SUB-SYSTEM--SOMETIMES--CALLED-- BUILDING--BLOCK lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :SUB-SYSTEM--SOMETIMES--CALLED--_BUILDING--BLOCK_lexConcept_2

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

diff/lex sp-defs-231012/diff 1335
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_2

diff/lex sp-defs-231012/diff 1336
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TESTABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :TESTABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1338
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TMS--DAILY--TOPOLOGY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :TMS--DAILY--TOPOLOGY_lexConcept_2

diff/lex sp-defs-231012/diff 1340
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TOPOLOGY--MASTER--DATA--VALIDATION--AND--IMPORT lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :TOPOLOGY--MASTER--DATA--VALIDATION--AND--IMPORT_lexConcept_2

diff/lex sp-defs-231012/diff 1343
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: UPDATEABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :UPDATEABILITY_lexConcept_2

diff/lex sp-defs-231012/diff 1344
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: UPGRADEABILITY lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :UPGRADEABILITY_lexConcept_2

…: 3
…: 11
…:
  …: 3
  …: 11

diff/lex sp-defs-231012/diff 1356
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: ACCIDENT lexConcept
predicate: definition
changes:
  changes: ++ "‘accident’ means an unwanted or unintended sudden event or a specific chain of such events which have harmful consequences; accidents are divided into the following categories: collisions; derailments; level crossing accidents; accidents to persons involving rolling stock in motion; fires and others; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (11) ]"
  changes: -- "‘accident’ means an unwanted or unintended sudden event or a specific chain of such events which have harmful consequences; accidents are divided into the following categories: collisions; derailments; level crossing accidents; accidents to persons involving rolling stock in motion; fires and others; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (11) ]"

diff/lex sp-defs-231012/diff 1357
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: ACTOR--VARIANT lexConcept
predicate: definition
changes:
  changes: ++ "An actor variant is an deviation to an existing actor regarding function deployment. It arises in two cases: * An additional (unusual) function is deployed to the actor variant. * A common actor function is removed and deployed to another actor or to a system. Identification of actor variants is a precondition for harmonisation of operational processes."
  changes: -- "An actor variant is an deviation to an existing actor regarding function deployment. It arises in two cases: * An additional (unusual) function is deployed to the actor variant. * A common actor function is removed and deployed to another actor or to a system. Identification of actor variants is a precondition for harmonisation of operational processes."

diff/lex sp-defs-231012/diff 1359
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: APPLICATION lexConcept
predicate: definition
changes:
  changes: ++ "An application in SP context is the resulting situation of a system beeing used in a specific environment by specific actors. In short - Application = System + Processes + Actors + Environment."
  changes: -- "An application in SP context is the resulting situation of a system beeing used in a specific environment by specific actors. In short - Application = System + Processes + Actors + Environment."

diff/lex sp-defs-231012/diff 1360
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/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 the technical systems.{comment:4} This analysis should focus as purely as possible on the processes and ideally does not take any specific technical system architecture into account. The operational analysis is usually performed on an abstraction layer above the topmost system in the systems of systems hierarchy and performed only once. See Chapter 5.6 * System analysis (SA): identify the needs of the system of interest. This step does not design a specific technical solution but captures the needs for the future system. It hence represents a statement of work and not a finished piece of engineering. It is used to rationalize the decision, which operational processes will be performed by the system of interest, and which will be not (these processes then mostly will be either performed by other systems or by human actors and defined as operating rules). System analysis is performed recursively: * Once for the topmost system of systems, deriving the initial need from the operational analysis * Multiple times for each system of system decomposition step, deriving the system needs of the lower level of decomposition from the higher level of decomposition * Logical architecture (LA): design a solution to the system needs based on solution concepts and architectural concepts. Split the system functions based on solution concepts (e.g. absolute positioning vs reference point based localisation, moving blocks, fixed blocks or hybrid) so that it becomes clear, how and by …
  changes: -- "The architectural process comprises four steps, each dealing with a separate concern. The general concept implements the architecture recommendations from the System Pillar report [SPREP, page 11] for a function-based architecture and a layered architecture approach. Both concepts can be realised with the architectural principles described herein.These steps are described in detail in the following chapters. * Operational analysis (OA): identify the operational process needs that are to be supported by the technical systems.{comment:4} This analysis should focus as purely as possible on the processes and ideally does not take any specific technical system architecture into account. The operational analysis is usually performed on an abstraction layer above the topmost system in the systems of systems hierarchy and performed only once. See Chapter 5.6 * System analysis (SA): identify the needs of the system of interest. This step does not design a specific technical solution but captures the needs for the future system. It hence represents a statement of work and not a finished piece of engineering. It is used to rationalize the decision, which operational processes will be performed by the system of interest, and which will be not (these processes then mostly will be either performed by other systems or by human actors and defined as operating rules). System analysis is performed recursively: * Once for the topmost system of systems, deriving the initial need from the operational analysis * Multiple times for each system of system decomposition step, deriving the system needs of the lower level of decomposition from the higher level of decomposition * Logical architecture (LA): design a solution to the system needs based on solution concepts and architectural concepts. Split the system functions based on solution concepts (e.g. absolute positioning vs reference point based localisation, moving blocks, fixed blocks or hybrid) so that it becomes clear, how and by …

diff/lex sp-defs-231012/diff 1363
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: AUTHENTICATION lexConcept
predicate: definition
changes:
  changes: ++ "The process to verify the identity of communicating peers. (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"
  changes: -- "The process to verify the identity of communicating peers. (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"

…: 60050
…: -821
…: diff/lex sp-defs-231012
…: 821
…: -05
…: -82
…: , --
…: type
…:
  …: 60050
  …: -821
  …: diff/lex sp-defs-231012
  …: 821
  …: -05
  …: -82

diff/lex sp-defs-231012/diff 1364
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: AVAILABILITY--<OF--A--PRODUCT> lexConcept
predicate: definition
changes:
  changes: ++ "Ability of an item to be in a state to perform a required function under given conditions at a given instant of time or over a given time interval, assuming that the required external resources are provided [SOURCE: IEC 60050-821: FDIS2016, 821-05-82, modified] Source: SPPRAMSS-349 - [EN 50126-1:2017]"
  changes: -- "Ability of an item to be in a state to perform a required function under given conditions at a given instant of time or over a given time interval, assuming that the required external resources are provided [SOURCE: IEC 60050-821: FDIS2016, 821-05-82, modified] Source: SPPRAMSS-349 - [EN 50126-1:2017]"

diff/lex sp-defs-231012/diff 1368
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: BUILDING--BLOCK lexConcept
predicate: definition
changes:
  changes: ++ "{comment:33} A building block is a sourceable unit of the CCS system (hardware and/or software), having standardised functionality, standardised performance (RAM), standardised safety (including Tolerable Functional Failure Rate [TFFR], Safety Integrity Level [SIL] and Safety Related Application Conditions [SRAC]), standardised security and standardised interfaces towards other building blocks and/or external systems. A building block can also be defined as a standardised module. {comment:158}"
  changes: -- "{comment:33} A building block is a sourceable unit of the CCS system (hardware and/or software), having standardised functionality, standardised performance (RAM), standardised safety (including Tolerable Functional Failure Rate [TFFR], Safety Integrity Level [SIL] and Safety Related Application Conditions [SRAC]), standardised security and standardised interfaces towards other building blocks and/or external systems. A building block can also be defined as a standardised module. {comment:158}"

diff/lex sp-defs-231012/diff 1369
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: BUILDING--STRATEGY lexConcept
predicate: definition
changes:
  changes: ++ "processus allowing to regroup physical components into consistent sub-collection in terms of industral development concerns and a strategy point of view"
  changes: -- "processus allowing to regroup physical components into consistent sub-collection in terms of industral development concerns and a strategy point of view"

diff/lex sp-defs-231012/diff 1370
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPACITY--WASTE--MEANS lexConcept
predicate: definition
changes:
  changes: ++ "* Paths are ordered without proper need, allocated and modified after allocation so that other ROCs cannot sensibly make use of them * Allocated paths are changed by RIMs after allocation due to the impact of TCRs by RIMs (same one allocating the path or another one on a different network) * An unnecessary number of paths are not allocated or are cancelled by RIMs due to poor alignment of several planned TCRs * Paths are not allocated or are cancelled by RIMs due to planned TCRs at times when little or no work is actually being carried out * Paths are not allocated or are cancelled by RIMs due to planned TCRs that were cancelled * Paths are not usable (or re-usable) due to the changes being communicated too late (i.e., due to paths being cancelled too late, TCRs cancelled, etc.)"
  changes: -- "* Paths are ordered without proper need, allocated and modified after allocation so that other ROCs cannot sensibly make use of them * Allocated paths are changed by RIMs after allocation due to the impact of TCRs by RIMs (same one allocating the path or another one on a different network) * An unnecessary number of paths are not allocated or are cancelled by RIMs due to poor alignment of several planned TCRs * Paths are not allocated or are cancelled by RIMs due to planned TCRs at times when little or no work is actually being carried out * Paths are not allocated or are cancelled by RIMs due to planned TCRs that were cancelled * Paths are not usable (or re-usable) due to the changes being communicated too late (i.e., due to paths being cancelled too late, TCRs cancelled, etc.)"

diff/lex sp-defs-231012/diff 1371
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPACITY-FRIENDLY--BEHAVIOUR--MEANS lexConcept
predicate: definition
changes:
  changes: ++ "* A path confirmed is a commitment from both ROC and RIM, which should be kept after it has been allocated and accepted * Ordering capacity only when the market need for it need has been confirmed (ROC) * Give back the capacity as soon the market need changes, or other external requirements are known (ROC) * Defining the capacity for TCRs in a way that no more capacity than necessary is blocked – in dialogue between ROCs and RIMs * Planning the majority of TCRs and their impact to paths before path allocation (RIM) * Reducing TCRs in operational timetable to the minimum and planning their impact to paths/trains as early as possible (RIM) * Stabilising TCR planning - avoiding TCR cancellations that lead to a double loss of business, as well as massive re-planning of scheduled TCRs, which results in high efforts in operational planning (RIM)"
  changes: -- "* A path confirmed is a commitment from both ROC and RIM, which should be kept after it has been allocated and accepted * Ordering capacity only when the market need for it need has been confirmed (ROC) * Give back the capacity as soon the market need changes, or other external requirements are known (ROC) * Defining the capacity for TCRs in a way that no more capacity than necessary is blocked – in dialogue between ROCs and RIMs * Planning the majority of TCRs and their impact to paths before path allocation (RIM) * Reducing TCRs in operational timetable to the minimum and planning their impact to paths/trains as early as possible (RIM) * Stabilising TCR planning - avoiding TCR cancellations that lead to a double loss of business, as well as massive re-planning of scheduled TCRs, which results in high efforts in operational planning (RIM)"

diff/lex sp-defs-231012/diff 1372
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPELLA--VIEWPOINT lexConcept
predicate: definition
changes:
  changes: ++ "A viewpoint is the tailoring of a capella diagram: * It has a specific purpose * It follows some diagram rules, that enforce this purpose * It is exported from Capella to Polarion in graphical form with a pre-defined filter"
  changes: -- "A viewpoint is the tailoring of a capella diagram: * It has a specific purpose * It follows some diagram rules, that enforce this purpose * It is exported from Capella to Polarion in graphical form with a pre-defined filter"

diff/lex sp-defs-231012/diff 1373
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CAPEX lexConcept
predicate: definition
changes:
  changes: ++ "Capital Expenditures or Capital Expenses"
  changes: -- "Capital Expenditures oder Capital Expenses"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -06
…: -07

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -06
…: -07

diff/lex sp-defs-231012/diff 1374
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CBM lexConcept
predicate: definition
changes:
  changes: ++ "condition-based maintenance preventive maintenance based on the assessment of physical condition Note 1 to entry: The condition assessment may be by operator observation, conducted according to a schedule, or by condition monitoring (192-06-28 SPPRAMSS-4462 - condition monitoring, <of an item> ) of system parameters. [SOURCE: IEC 60050-192:2015, 192-06-07]"
  changes: -- "condition-based maintenance preventive maintenance based on the assessment of physical condition Note 1 to entry: The condition assessment may be by operator observation, conducted according to a schedule, or by condition monitoring (192-06-28 SPPRAMSS-4462 - condition monitoring, <of an item> ) of system parameters. [SOURCE: IEC 60050-192:2015, 192-06-07]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -03
…: -18

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -03
…: -18

diff/lex sp-defs-231012/diff 1377
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CCS--CONFIGURATION lexConcept
predicate: definition
changes:
  changes: ++ "The CCS Configuration is an exhaustive, unambiguous description (all configuration items and an overarching CCS manifest file) of all building blocks necessary to operate a physical instance of a CCS System, approved (in line with the CENELEC process) for deployment to a specific CCS Instance (identified via an identifier, for instance the already existing NID_ENGINE, or other identifier already in use) and authorised to either operate on specific Railway Networks (identified via unique Railway Network Identifiers) or to be part of a specific Railway Network. The CCS Configuration is used for distribution of statical or semi-statical data (update data packet). It does not cover dynamic operational data like Moving Authority (for ETCS) or Journey Profiles (for ATO). The CCS Configuration is intended for CCS building blocks being present in multiple units, either close to infrastructure elements (e.g. CCS trackside instance and related signalling components like object controller) or CCS components on-board a train. It is not the aim to use CCS configuration management process (and the related CCS Configuration) for the update of large cloud based applications (installed on server farms). For the latter there are more suitable solutions from the IT industry. It is not a prerequisite that CCS building blocks need to stay in operation when activating / installing a CCS Configuration (however, this is allowed). These components could shut down / restart, basically go out of operation, or remain in operation. The main sources for the CCS Configuration (configuration items and overarching CCS manifest file) content are the Building Block Suppliers and the Integrator (as described in the TCCS Configuration - High Level Concept document), accordingly the CCS Configuration content (and the related Configuration Management process) is restricted to what these roles are capable to provide. The Operator will only enrich the CCS Configuration with definitions in terms of poin…
  changes: -- "The CCS Configuration is an exhaustive, unambiguous description (all configuration items and an overarching CCS manifest file) of all field elements necessary to operate a physical instance of a CCS System, approved (in line with the CENELEC process) for deployment to a specific CCS Instance (identified via an identifier, for instance the already existing NID_ENGINE, or other identifier already in use) and authorised to either operate on specific Networks (identified via unique Network Identifiers) or to be part of a specific Network. The CCS Configuration is used for distribution of statical or semi-statical data (update data packet). It does not cover dynamic operational data like Moving Authority (for ETCS) or Journey Profiles (for ATO). The CCS Configuration is intended for CCS field components being present in multiple units, either close to infrastructure elements (e.g. CCS trackside instance and related signalling components like object controller) or CCS components on-board a train. It is not a prerequisite that CCS field components need to stay in operation when activating / installing a CCS Configuration (however, this is allowed). These components could shut down / restart, basically go out of operation, or remain in operation. The main sources for the CCS Configuration (configuration items and overarching CCS manifest file) content are the Building Block Suppliers and the Integrator (as described in the TCCS Configuration - High Level Concept document), accordingly the CCS Configuration content (and the related Configuration Management process) is restricted to what these roles are capable to provide. The Operator will only enrich the CCS Configuration with definitions in terms of point in time and other operationally significant parameters for the activation."

diff/lex sp-defs-231012/diff 1382
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CMS lexConcept
predicate: definition
changes:
  changes: ++ "CMS Central modelling services"
  changes: -- "CMS Central modelling services"

diff/lex sp-defs-231012/diff 1383
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CM lexConcept
predicate: definition
changes:
  changes: ++ "Capacity Management. In the railway context, capacity management refers to the strategic planning and operational control measures implemented to effectively manage the available resources and infrastructure of a railway system in order to meet the demand for transportation services. It involves assessing, optimizing, and maximizing the capacity of various components within the railway system, such as tracks, stations, trains, and associated facilities."
  changes: -- "Capacity Management. In the railway context, capacity management refers to the strategic planning and operational control measures implemented to effectively manage the available resources and infrastructure of a railway system in order to meet the demand for transportation services. It involves assessing, optimizing, and maximizing the capacity of various components within the railway system, such as tracks, stations, trains, and associated facilities."

diff/lex sp-defs-231012/diff 1385
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: COMPONENT lexConcept
predicate: definition
changes:
  changes: ++ "{comment:35} A component is used to structure functionality within building blocks. It implements and encapsulates one or more behaviors (business logic) and exposes services via defined interfaces to other components.{comment:159}"
  changes: -- "{comment:35} A component is used to structure functionality within building blocks. It implements and encapsulates one or more behaviors (business logic) and exposes services via defined interfaces to other components.{comment:159}"

diff/lex sp-defs-231012/diff 1386
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CONCEPTUAL--GLOSSARY lexConcept
predicate: definition
changes:
  changes: ++ "Container of concepts, typically class model illustrating a lexical definition, incl. relationships between concepts. May also be imported or authored by the project. Conceptual glossaries are referred to by lexcial glossaries."
  changes: -- "Container of concepts, typically class model illustrating a lexical definition, incl. relationships between concepts. May also be imported or authored by the project. Conceptual glossaries are referred to by lexcial glossaries."

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -06
…: -28

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -06
…: -28

diff/lex sp-defs-231012/diff 1387
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CONDITION--MONITORING--<OF--AN--ITEM> lexConcept
predicate: definition
changes:
  changes: ++ "obtaining information about physical state or operational parameters Note 1 to entry: Condition monitoring is used to determine when preventive maintenance may be required. Note 2 to entry: Condition monitoring may be conducted automatically during operation or at planned intervals. Note 3 to entry: Condition monitoring methods include: vibration analysis, tribology and thermography. [SOURCE: IEC 60050-192:2015, 192-06-28]"
  changes: -- "obtaining information about physical state or operational parameters Note 1 to entry: Condition monitoring is used to determine when preventive maintenance may be required. Note 2 to entry: Condition monitoring may be conducted automatically during operation or at planned intervals. Note 3 to entry: Condition monitoring methods include: vibration analysis, tribology and thermography. [SOURCE: IEC 60050-192:2015, 192-06-28]"

diff/lex sp-defs-231012/diff 1388
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CONFIDENTIALITY lexConcept
predicate: definition
changes:
  changes: ++ "Confidentiality, in the context of computer systems, allows only authorised users to access protected data using specific mechanisms to ensure confidentiality and safeguard data from harmful intrusion. (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"
  changes: -- "Confidentiality, in the context of computer systems, allows only authorised users to access protected data using specific mechanisms to ensure confidentiality and safeguard data from harmful intrusion. (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"

diff/lex sp-defs-231012/diff 1390
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CONFIGURATION--ITEM lexConcept
predicate: definition
changes:
  changes: ++ "part of the system that must be enginereed, 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"
  changes: -- "part of the system that must be enginereed, 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-231012/diff 1391
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CONFIGURATION lexConcept
predicate: definition
changes:
  changes: ++ "Description of a collection of model elements, either available or unavailable in a given context. A context can be a mode, a state or a combination of both."
  changes: -- "Description of a collection of model elements, either available or unavailable in a given context. A context can be a mode, a state or a combination of both."

diff/lex sp-defs-231012/diff 1392
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CONSOLIDATED--GLOSSARY lexConcept
predicate: definition
changes:
  changes: ++ "A SPPR-5436 - Lexical Glossary is called consolidated if all contained items are not contradictory nor ambiguous toward other glossaries of System Pillar. All possible ambiguities are resolved by means of context information added to the definitions. A consolidated glossary provides a safe basis for the context underlying its namespace. This supports efficient communication in expert groups. See SPPR-5313 - Consolidate the glossary items."
  changes: -- "A SPPR-5436 - Lexical Glossary is called consolidated if all contained items are not contradictory nor ambiguous toward other glossaries of System Pillar. All possible ambiguities are resolved by means of context information added to the definitions. A consolidated glossary provides a safe basis for the context underlying its namespace. This supports efficient communication in expert groups. See SPPR-5313 - Consolidate the glossary items."

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -06

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -06

diff/lex sp-defs-231012/diff 1394
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: CORRECTIVE--MAINTENANCE lexConcept
predicate: definition
changes:
  changes: ++ "Maintenance carried out after fault detection to effect restoration Note 1 to entry: Corrective maintenance of software invariably involves some modification. [SOURCE: IEC 60050-192:2015, 192-06-06]"
  changes: -- "Maintenance carried out after fault detection to effect restoration Note 1 to entry: Corrective maintenance of software invariably involves some modification. [SOURCE: IEC 60050-192:2015, 192-06-06]"

diff/lex sp-defs-231012/diff 1395
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: DATA--MODEL--LAYER lexConcept
predicate: definition
changes:
  changes: ++ "Note: informelle Gruppierung im Modell (analog zur RCA tiers), für Kommunikation/Verständnis A data model layer offers a view of the information as needed by, and as limited by a functional domain such as topology, geometry, signalling, gauge, etc."
  changes: -- "Note: informelle Gruppierung im Modell (analog zur RCA tiers), für Kommunikation/Verständnis A data model layer offers a view of the information as needed by, and as limited by a functional domain such as topology, geometry, signalling, gauge, etc."

…
…: 1
entity: diff/lex sp-defs-231012/entity
entity: ETCS lexConcept 2
predicate: definition
changes:
  changes: ++ "European Train Control System (ETCS) is a cab-signalling system that incorporates automatic train protection (ERA definition). ETCS in the frame of SERA will support the following Levels: * L2 with fixed train detection (classic L2 with trackside detection (track circuits, axle-counters, …)) * L2 with hybrid train detection (virtual fixed or moving blocks with trackside detection (axle-counters, …)) – formerly known as Hybrid L3 * L2 with virtual fixed or moving blocks and train integrity (no trackside detection) – formerly known as pure L3"
  changes: -- "European Train Control System (ETCS) is a cab-signalling system that incorporates automatic train protection (ERA definition). ETCS in the frame of SERA will support the following Levels: * L2 with fixed train detection (classic L2 with trackside detection (track circuits, axle-counters, …)) * L2 with hybrid train detection (virtual fixed or moving blocks with trackside detection (axle-counters, …)) – formerly known as Hybrid L3 * L2 with virtual fixed or moving blocks and train integrity (no trackside detection) – formerly known as pure L3"
type: fault
type: 192
type: -04
type: -01
…: 2
…: , --
…: :diff_1441 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231113:FUNCTIONAL--TEAM_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
…: A Functional team includes the role owners of the same role. It organizes the work allocation and overall results for that role, including the workflows and working methods. The name of the functional team has a “-F” at the end. The functional teams form a matrix to the organisational units of the SP. If an organisational unit has more persons with the same role, one of them can be delegated to the functional team as a "speaker". Functional teams organise themselves internally. From "outside" (SP processes) the team is addressed as one actor. The worksplit in the functional teams is decided in the team. The functional teams act with the responsibilities and tasks defined by the role it represents. The functional team is lead and moderated by the participant from System Level 1/ (mostly people from the engineering services, see role allocation table). Functional teams decide in consensus, or escalate to the coregroup. Example for the functional Team “REQ-F” (image: 1-Bild_2.png) (image: 2-Grafik_1.png)
…: ,
…: ] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231113:FUNCTION_lexConcept ( was in lex_sp-defs-231012: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "A function transforms several one or more input values to several one or more output values according to the function’s behaviour. The function’s behaviour is defined by one or multiple functional requirements, defining “what” the function is doing. Additional non-functional requirements attached to the function define the quality attributes of “how” (how safe, how accurate, how fast, how reliable, etc.) the function is performing the transformation. Some non-functional requirements, e.g., on weight constraints or physical dimension constraints), will also be allocated to subsystems.", -- "A function transforms several one or more input values to several one or more output values according to the function’s behaviour. The function’s behaviour is defined by one or multiple functional requirements, defining “what” the function is doing. Additional non-functional requirements attached to the function define the quality attributes of “how” (how safe, how accurate, how fast, how reliable, etc.) the function is performing the transformation. Some non-functional requirements, e.g., on weight constraints or physical dimension constraints), will also be allocated to subsystems." :diff_1442 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231113:FUNCTION_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
type: , --
diff/lex sp-defs-231012/2015: type
…: -- "Capella Viewpoint. Purpose: displays the operational entities and actors involved in an operational capability- and only that Rule: contains 1 and only 1 capability Rule: contains at least on 1 entity or actor Filter: show entities * Yes: Hide Communication Means * No: Hide Involvement Links * Yes: Hide Operational Capabiltiy Extends * Yes: Hide Operational Capabiltiy Includes * Yes: Hide Operational Capabiltiy Generatlizations * Yes: Hide Property Values * Yes: Hide Diagram Title Blocks * Yes: Hilde Element Title Blocks"
…: type
diff/lex sp-defs-231012: type
diff/lex sp-defs-231012: 3
diff/lex sp-defs-231012: diff/lex sp-defs-231012
diff/lex sp-defs-231012: 4
diff/lex sp-defs-231012: 5
…: 3
…: 4
…: 5

diff/lex sp-defs-231012/diff 1397
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: DEFINITION lexConcept 2
predicate: definition
changes:
  changes: ++ "ARCADIA (Architecture Analysis & Design Integrated Approach) is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities. Main resources about ARCADIA can be found on the official websites: https://www.eclipse.org/capella/arcadia-reference.html (image: 1-screenshot-20230107-163323.png)"
  changes: -- "ARCADIA (Architecture Analysis & Design Integrated Approach) is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities. Main resources about ARCADIA can be found on the official websites: https://www.eclipse.org/capella/arcadia-reference.html (image: 1-screenshot-20230107-163323.png)"

diff/lex sp-defs-231012/diff 1399
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: DEVELOPMENT--TASK lexConcept
predicate: definition
changes:
  changes: ++ "* Take spec, build system * Usually starts on CENELEC P5 * Bottom of CENELEC “V”"
  changes: -- "* Take spec, build system * Usually starts on CENELEC P5 * Bottom of CENELEC “V”"

diff/lex sp-defs-231012/diff 1400
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: DEVICE lexConcept
predicate: definition
changes:
  changes: ++ "Device{comment:36} A physical entity performing a predefined (set of) task(s). It consists of software integrated on a hardware."
  changes: -- "Device{comment:36} A physical entity performing a predefined (set of) task(s). It consists of software integrated on a hardware."

diff/lex sp-defs-231012/diff 1401
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: DISTRIBUTION--JOB lexConcept
predicate: definition
changes:
  changes: ++ "Distribution Job is the complete configuration data packet that is finally provided to the building blocks. The Distribution Job contains the metadata required for the distribution of a CCS Configuration. In addition to linking a referenced CCS Manifest to a CCS Vehicle Identifier or a CCS Trackside Identifier, it also includes information like distribution date / time, activation location, etc. This metadata will be evaluated by central location system (centrally located: typically a CCS configuration management system) and different distributed systems (distributed in the field: e.g. on-board) involved in the distribution process."
  changes: -- "Distribution Job is the complete configuration data packet that is finally provided to the field components. The Distribution Job contains the metadata required for the distribution of a CCS Configuration. In addition to linking a referenced CCS Manifest to a CCS Vehicle Identifier or a CCS Trackside Identifier, it also includes information like distribution date / time, activation location, etc. This metadata will be evaluated by central location system (centrally located: typically a CCS configuration management system) and different distributed systems (distributed in the field: e.g. on-board) involved in the distribution process."

diff/lex sp-defs-231012/diff 1408
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: ERTMS lexConcept
predicate: definition
changes:
  changes: ++ "European Railway Traffic Management System (ERTMS) is a single European signalling and speed control system that ensures interoperability of the national railway systems, reducing the purchasing and maintenance costs of the signalling systems as well as increasing the speed of trains, the capacity of infrastructure and the level of safety in rail transport. ERTMS comprises of the European Train Control System (ETCS), i.e. a cab-signalling system that incorporates automatic train protection, the Global System for Mobile communications for Railways (GSM-R) and operating rules. (ERA definition)"
  changes: -- "ERTMS comprises of the European Train Control System (ETCS), i.e. a cab-signalling system that incorporates automatic train protection, the Global System for Mobile communications for Railways (GSM-R) and operating rules. (ERA definition)"

diff/lex sp-defs-231012/diff 1409
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: ERTMS lexConcept 2
predicate: definition
changes:
  changes: ++ "European Rail Traffic Management System"
  changes: -- "European Railway Traffic Management System (ERTMS) is a single European signalling and speed control system that ensures interoperability of the national railway systems, reducing the purchasing and maintenance costs of the signalling systems as well as increasing the speed of trains, the capacity of infrastructure and the level of safety in rail transport. ERTMS comprises of the European Train Control System (ETCS), i.e. a cab-signalling system that incorporates automatic train protection, the Global System for Mobile communications for Railways (GSM-R) and operating rules. (ERA definition)"

diff/lex sp-defs-231012/diff 1413
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: EU-RAILGOVERNING--BOARD lexConcept
predicate: definition
changes:
  changes: ++ "EU-RailGoverning Board Final decision body, where a decisions are adopted a majority of at least 55% of the votes"
  changes: -- "EU-RailGoverning Board Final decision body, where a decisions are adopted a majority of at least 55% of the votes"

diff/lex sp-defs-231012/diff 1415
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: EVOLVABILITY lexConcept
predicate: definition
changes:
  changes: ++ "Evolvability is the ability to easily adapt to new technologies or to extend the functionality of the CCS system without the involvement of the original supplier.{comment:429}"
  changes: -- "Evolvability is the ability to easily adapt to new technologies or to extend the functionality of the CCS system without the involvement of the original supplier."

diff/lex sp-defs-231012/diff 1416
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/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 of sub-systems whereas interoperability is related to interactions between sub-systems (e.g. also between STM and ETCS on-board there is interoperability)."
  changes: -- "Exchangeability is the ability to replace a sub-system from supplier A by a subsystem from supplier B without affecting other sub-systems or the overall system/subsystem and with a reasonable integration effort and/or certification effort. Exchangeability and interchangeability are related to the physical characteristics of sub-systems wheres interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."

…: 60050
…: -821
…: diff/lex sp-defs-231012/2017
…: 821
…: -01
…: -10

…: 60050
…: -821
…: diff/lex sp-defs-231012/2017
…: 821
…: -01
…: -10

diff/lex sp-defs-231012/diff 1417
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAIL-SAFE lexConcept
predicate: definition
changes:
  changes: ++ "able to enter or remain in a safe state in the event of a failure [SOURCE: IEC 60050-821:2017 , 821-01-10]"
  changes: -- "able to enter or remain in a safe state in the event of a failure [SOURCE: IEC 60050-821:2017 , 821-01-10]"

diff/lex sp-defs-231012/diff 1418
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAIL-SAFE lexConcept 2
predicate: definition
changes:
  changes: ++ "able to enter or remain in a safe state in the event of a failure [821-01-10 ]"
  changes: -- "able to enter or remain in a safe state in the event of a failure [821-01-10 ]"

…: 60050.192
…: diff/lex sp-defs-231012/2015
…: 192
…: -03
…: -11

…: 60050.192
…: diff/lex sp-defs-231012/2015
…: 192
…: -03
…: -11

diff/lex sp-defs-231012/diff 1419
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAILURE--CAUSE lexConcept
predicate: definition
changes:
  changes: ++ "set of circumstances that leads to failure Note 1 to entry: A failure cause may originate during specification, design, manufacture, installation, operation or maintenance of an item. [SOURCE: IEC 60050.192:2015, 192-03-11]"
  changes: -- "set of circumstances that leads to failure Note 1 to entry: A failure cause may originate during specification, design, manufacture, installation, operation or maintenance of an item. [SOURCE: IEC 60050.192:2015, 192-03-11]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -03
…: -17

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -03
…: -17

diff/lex sp-defs-231012/diff 1420
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAILURE--MODE lexConcept
predicate: definition
changes:
  changes: ++ "Manner in which failure occurs. Note 1 to entry: A failure mode may be defined by the function lost or other state transition that occurred. [SOURCE: IEC 60050-192:2015, 192-03-17]"
  changes: -- "Manner in which failure occurs. Note 1 to entry: A failure mode may be defined by the function lost or other state transition that occurred. [SOURCE: IEC 60050-192:2015, 192-03-17]"

…: 62278
…: diff/lex sp-defs-231012/2002
…: 3.14

…: 62278
…: diff/lex sp-defs-231012/2002
…: 3.14

diff/lex sp-defs-231012/diff 1421
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAILURE--RATE-- 821-12-21 lexConcept
predicate: definition
changes:
  changes: ++ "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [SOURCE: IEC 62278:2002, 3.14, modified]"
  changes: -- "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [SOURCE: IEC 62278:2002, 3.14, modified]"

diff/lex sp-defs-231012/2002: 3.14

diff/lex sp-defs-231012/diff 1422
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAILURE--RATE lexConcept
predicate: definition
changes:
  changes: ++ "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [IEC 60050-821, 821-12-21]"
  changes: -- "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [821-12-21][IEC 62278:2002, 3.14, modified]"

diff/lex sp-defs-231012/2002: 3.14

diff/lex sp-defs-231012/2002: 3.14

diff/lex sp-defs-231012/diff 1423
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAILURE--RATE lexConcept 2
predicate: definition
changes:
  changes: ++ "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [821-12-21][IEC 62278:2002, 3.14, modified]"
  changes: -- "limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [821-12-21][IEC 62278:2002, 3.14, modified]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -03
…: -01

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -03
…: -01

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -04
…: -01

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -11

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -11

diff/lex sp-defs-231012/diff 1427
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAULT--DETECTION--TIME lexConcept
predicate: definition
changes:
  changes: ++ "DEPRECATED: undetected fault time time interval between failure and detection of the resulting fault [SOURCE: IEC 60050-192:2015,192-07-11]"
  changes: -- "DEPRECATED: undetected fault time time interval between failure and detection of the resulting fault [SOURCE: IEC 60050-192:2015,192-07-11]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -11
…: -07

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -11
…: -07

diff/lex sp-defs-231012/diff 1429
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FAULT--TREE lexConcept
predicate: definition
changes:
  changes: ++ "logic diagram showing the faults of sub items, external events, or combinations thereof, which cause a predefined, undesired event [SOURCE: IEC 60050-192:2015, 192-11-07]"
  changes: -- "logic diagram showing the faults of sub items, external events, or combinations thereof, which cause a predefined, undesired event [SOURCE: IEC 60050-192:2015, 192-11-07]"

diff/lex sp-defs-231012/diff 1430
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FEATURE--SUMMARY lexConcept
predicate: definition
changes:
  changes: ++ "The ARCADIA method: * Covers all structured engineering activities, from capturing customer operational needs to system integration verification validation (IVV); * Takes into account multiple engineering levels and their effective collaboration (system, subsystem, software, hardware, etc.); * Integrates co-engineering with specialty engineering (safety, security, performance, interfaces, logistics ...) and IVV; * Provides the ability not only to share descriptive models but also to collaboratively validate properties of the definition and the architecture; * Is field-tested in full-scale industrial applications, and is currently deployed on dozens of major projects in several countries and divisions of Thales."
  changes: -- "The ARCADIA method: * Covers all structured engineering activities, from capturing customer operational needs to system integration verification validation (IVV); * Takes into account multiple engineering levels and their effective collaboration (system, subsystem, software, hardware, etc.); * Integrates co-engineering with specialty engineering (safety, security, performance, interfaces, logistics ...) and IVV; * Provides the ability not only to share descriptive models but also to collaboratively validate properties of the definition and the architecture; * Is field-tested in full-scale industrial applications, and is currently deployed on dozens of major projects in several countries and divisions of Thales."

diff/lex sp-defs-231012/diff 1431
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FFFIS-----FORM--FIT--FUNCTIONAL--INTERFACE--SPECIFICATION lexConcept
predicate: definition
changes:
  changes: ++ "A FFFIS is the complete definition of an interface between functional or physical entities. The FFFIS includes: - FIS, - Electrical characteristics related to data, - communication protocol, - and including connector and plug. The FFFIS and accompanying documents (e.g. safety analysis) guarantees the interoperability but not the exchangeability of physical entities, see Subset-037 SPT2ARC-1620."
  changes: -- "A FFFIS is the complete definition of an interface between functional or physical entities. The FFFIS includes: - FIS, - Electrical characteristics related to data, - communication protocol, - and including connector and plug. he FFFIS and accompanying documents (e.g. safety analysis) guarantees the interoperability but not the exchangeability of physical entities. [Subset-037]"

diff/lex sp-defs-231012/diff 1432
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FIS-----FUNCTIONAL--INTERFACE--SPECIFICATION lexConcept 2
predicate: definition
changes:
  changes: ++ "FIS - Functional Interface Specification"
  changes: -- "Functional requirements and description of an interface. This clarifies also the functional apportionment and related safety requirements of the two sub-systems of the interface."

type
…: fault mode, effects and criticality analysis
…: 60050
…: -191
…: diff/lex sp-defs-231012/1990
diff/lex sp-defs-231012/2015: 192
diff/lex sp-defs-231012/2015: -04
diff/lex sp-defs-231012/2015: -01
diff/lex sp-defs-231012/2015: -03
diff/lex sp-defs-231012/2015: -17
…: 1
…: , --
type: 1
type: diff/lex sp-defs-231012
diff/lex sp-defs-231012: diff/lex sp-defs-231012
type: , --

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -11
…: -06
…: type

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -11
…: -06
…: type

diff/lex sp-defs-231012/diff 1435
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FOLLOW--A--TRACE lexConcept
predicate: definition
changes:
  changes: ++ "A trace (nodes/work items and their links) is a graph that works out one issue (e.g. one requirement) in the most efficient, complete and fast way, down to its operational and system implementation (image: 2-image2.png) Figure {caption:Figure}: Trace for a CBO requirement (red point in the middle) in an ALM System System Levels are just “areas of team responsibilities” for working on parts of the graph * System Level 1 / 2 = teams … = Work item detail level … * System Level 3 = teams … = Work item detail level … * System Level 4 = teams … = Work item detail level … * System Level 5 = teams … = Work item detail level … Assigning a work item to a System Level just means: Assigning them to a team. No good idea: Design every System Level with everything that a real-world system would need. Systems on Level 1-4 are no real-world systems, they just structure the work assignment. Trace Example – just one “branch”: The reality is not puristic, it is like a “neuron-mesh” A. SL2: Requirement “High, scalable, and flexible transport capacity” >> B. SL3: Process “efficient ATP for high density lines” >> C. SL4: Requirement “Precise and frequent localisation” in the train >> D. SL3: Architecture (functions) for a high- performance localisation System >> E. SL5: Interface requirements to deliver a map to the train >> F. SL5: Requirement that Traffic CS delivers a reliable map >> …. Think in “good complete traces”, and do not “fill all System Levels” (!) --> It is just important that “traces are complete, good and correct”, with work items assigned to the right team level --> What System Levels are NOT for: Being the basic scheme for everything * Creating a break-down element on every System Level --> this does not work and requires too much effort * Exception: The work item “system” is broken down on every level, but for example interfaces or logical components only exist in System Level 5) When do we need “completion” on System Levels? Sometimes it is necessary. Example 1: Sa…
  changes: -- "A trace (nodes/work items and their links) is a graph that works out one issue (e.g. one requirement) in the most efficient, complete and fast way, down to its operational and system implementation (image: 2-image2.png) Figure {caption:Figure}: Trace for a CBO requirement (red point in the middle) in an ALM System System Levels are just “areas of team responsibilities” for working on parts of the graph * System Level 1 / 2 = teams … = Work item detail level … * System Level 3 = teams … = Work item detail level … * System Level 4 = teams … = Work item detail level … * System Level 5 = teams … = Work item detail level … Assigning a work item to a System Level just means: Assigning them to a team. No good idea: Design every System Level with everything that a real-world system would need. Systems on Level 1-4 are no real-world systems, they just structure the work assignment. Trace Example – just one “branch”: The reality is not puristic, it is like a “neuron-mesh” A. SL2: Requirement “High, scalable, and flexible transport capacity” >> B. SL3: Process “efficient ATP for high density lines” >> C. SL4: Requirement “Precise and frequent localisation” in the train >> D. SL3: Architecture (functions) for a high- performance localisation System >> E. SL5: Interface requirements to deliver a map to the train >> F. SL5: Requirement that Traffic CS delivers a reliable map >> …. Think in “good complete traces”, and do not “fill all System Levels” (!) --> It is just important that “traces are complete, good and correct”, with work items assigned to the right team level --> What System Levels are NOT for: Being the basic scheme for everything * Creating a break-down element on every System Level --> this does not work and requires too much effort * Exception: The work item “system” is broken down on every level, but for example interfaces or logical components only exist in System Level 5) When do we need “completion” on System Levels? Sometimes it is necessary. Example 1: Sa…

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -11
…: -08

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -11
…: -08

diff/lex sp-defs-231012/diff 1436
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FTA lexConcept
predicate: definition
changes:
  changes: ++ "fault tree analysis deductive analysis using fault trees Note 1 to entry: See also fault tree (192-11-07 SPPRAMSS-4464 - fault tree ). [SOURCE: IEC 60050-192:2015, 192-11-08]"
  changes: -- "fault tree analysis deductive analysis using fault trees Note 1 to entry: See also fault tree (192-11-07 SPPRAMSS-4464 - fault tree ). [SOURCE: IEC 60050-192:2015, 192-11-08]"

diff/lex sp-defs-231012/diff 1440
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: FUNCTIONAL--APPORTIONMENT lexConcept
predicate: definition
changes:
  changes: ++ "Functional apportionment is the clear assignment of functions to sub-systems. It is an architectural choice supporting the ability to replace a sub-system of supplier A by a subsystem of supplier B both compliant with a given FIS."
  changes: -- "Functional apportionment is an architectural choice supporting the ability to replace a sub-system of supplier A by a subsystem of supplier B both compliant with a given FIS."

diff/lex sp-defs-231012/diff 1445
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: GRANULARITY lexConcept
predicate: definition
changes:
  changes: ++ "The granularity characterises the level of modularity of a system. The more subsystems a system is composed of, the higher its granularity."
  changes: -- "The granularity characterizes the level of modularity of a system. The more granularity is achieved, the more the system is decomposed in many sub-systems."

diff/lex sp-defs-231012/diff 1446
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: GROUND--FOOTPRINT lexConcept
predicate: definition
changes:
  changes: ++ "The ground footprint of an object moving on the earth is defined as the projection of its volume on the earth ground. Note: This defintion is applicable for collission detection between two ground vehicles moving on the same level."
  changes: -- "The ground footprint of an object moving on the earth is defined as the projection of its volume on the earth ground. Note: This defintion is applicable for collission detection between two ground vehicles moving on the same level."

diff/lex sp-defs-231012/diff 1448
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: HAZARD--MITIGATION lexConcept
predicate: definition
changes:
  changes: ++ "Safety requirement regarding activities for lowering the effect of a hazard. It reduces the damage to people, property, and the environment by lowering the frequency, damping the consequences. Note: A mitigation can be a realized by * fault detection (hazard will be detected), typically this needs additional activities * failure reaction (after detection the hazard will be excluded), typically this needs additional activities * SRAC safety application condition (hazard will be avoided principly)"
  changes: -- "Safety requirement regarding activities for lowering the effect of a hazard. It reduces the damage to people, property, and the environment by lowering the frequency, damping the consequences."

diff/lex sp-defs-231012/2013: 903
diff/lex sp-defs-231012/2013: -01
diff/lex sp-defs-231012/2013: -02

diff/lex sp-defs-231012/2013: 903
diff/lex sp-defs-231012/2013: -01
diff/lex sp-defs-231012/2013: -02

diff/lex sp-defs-231012/2013: 903
diff/lex sp-defs-231012/2013: -01
diff/lex sp-defs-231012/2013: -02

diff/lex sp-defs-231012/2013: 903
diff/lex sp-defs-231012/2013: -01
diff/lex sp-defs-231012/2013: -02

diff/lex sp-defs-231012/diff 1452
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: HFI--ACTIVITIES lexConcept
predicate: definition
changes:
  changes: ++ "HFI Activities are conducted to optimise the effectiveness and efficiency of human performance by fully considering the human contribution to system performance. Human Performance is the observable and measurable behaviour that occurs in job and task situations, the extent to which goals such as speed, accuracy, quality and other criteria are met by people in their work environments. The focus is on the ability of operators and maintainers to meet system performance requirements, including reliability and maintainability, under the conditions in which the system is employed."
  changes: -- "HFI Activities are conducted to optimise the effectiveness and efficiency of human performance by fully considering the human contribution to system performance. Human Performance is the observable and measurable behaviour that occurs in job and task situations, the extent to which goals such as speed, accuracy, quality and other criteria are met by people in their work environments. The focus is on the ability of operators and maintainers to meet system performance requirements, including reliability and maintainability, under the conditions in which the system is employed."

diff/lex sp-defs-231012/diff 1454
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: HSI lexConcept
predicate: definition
changes:
  changes: ++ "Human-System Integration, an interdisciplinary approach that aims at optimizing in an early development stage the global system performance by desgining solutions adapted for both human and technical system. HSI studies integrates work from multiple human centered domains - process analysis, both qualitative and quantitatve, ergonomics, safety, survivability, habitability, skill analysis, training. HSI typically help define user interfaces and lead to workitem SPPR-2246 - Application Condition or SPPR-2244 - SRAC ."
  changes: -- "Human-System Integration, an interdisciplinary approach that aims at optimizing in an early development stage the global system performance by desgining solutions adapted for both human and technical system. HSI studies integrates work from multiple human centered domains - process analysis, both qualitative and quantitatve, ergonomics, safety, survivability, habitability, skill analysis, training. HSI typically help define user interfaces and lead to workitem SPPR-2246 - Application Condition or SPPR-2244 - SRAC ."

diff/lex sp-defs-231012/diff 1455
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: HUMAN--FACTORS lexConcept
predicate: definition
changes:
  changes: ++ "Human factors issues include anything that affects human performance, particularly those factors that may cause or contribute to human error. The main human factors areas include: * Individual (physical size, personal preferences, cognitive skills, attitudes, background) * Organisation (culture, work pattern, communications, supervision, training) * Job (design of equipment, rules and procedures, tools, signage, environment) The purpose of human factors is to minimise safety risk from the possibility of human error by: * ensuring human characteristics are accounted for in the design (or re-design) of new and existing systems and equipment * identifying the issues which may cause or contribute to human errors * conducting activities and applying controls to reduce likelihood and consequences."
  changes: -- "Human factors issues include anything that affects human performance, particularly those factors that may cause or contribute to human error. The main human factors areas include: * Individual (physical size, personal preferences, cognitive skills, attitudes, background) * Organisation (culture, work pattern, communications, supervision, training) * Job (design of equipment, rules and procedures, tools, signage, environment) The purpose of human factors is to minimise safety risk from the possibility of human error by: * ensuring human characteristics are accounted for in the design (or re-design) of new and existing systems and equipment * identifying the issues which may cause or contribute to human errors conducting activities and applying controls to reduce likelihood and consequences."

diff/lex sp-defs-231012/diff 1456
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: HUMAN--MACHINE--INTERFACE lexConcept 2
predicate: definition
changes:
  changes: ++ "The Human Machine Interface is a physical interface permitting an interaction between a human and the system control. The purpose of this interface is to allow effective operation by the human (ie: acknowledgement for a function) permitting to the machine (computer) to adapt simultanously the behaviour of the control command."
  changes: -- "Graphical component to interact with a user e.g., by train graph."

diff/lex sp-defs-231012/diff 1457
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: IMPERSONATION lexConcept
predicate: definition
changes:
  changes: ++ "Impersonation, in terms of behavior, involves a person or entity imitating or mimicking the actions, mannerisms, or characteristics of another individual or entity. In the context on how this definition is to be understood, a newer system would behave exactly like an older version system of itself, allowing it to interact with older systems/subsystems transparently, by behaving exactly like the older version expected by them. From a software perspective, the different impersonations a system can take could be implemented as independent modules, which would reduce the complexity of each module implementing an specific impersonation, and also limit the side effects of changes or bugs in one module to the others. It could also facilitate the addition of a new version of a system, while still keeping the former version of the system available in a transparent way."
  changes: -- "Impersonation, in terms of behavior, involves a person or entity imitating or mimicking the actions, mannerisms, or characteristics of another individual or entity. In the context on how this definition is to be understood, a newer system would behave exactly like an older version system of itself, allowing it to interact with older systems/subsystems transparently, by behaving exactly like the older version expected by them. From a software perspective, the different impersonations a system can take could be implemented as independent modules, which would reduce the complexity of each module implementing an specific impersonation, and also limit the side effects of changes or bugs in one module to the others. It could also facilitate the addition of a new version of a system, while still keeping the former version of the system available in a transparent way."

diff/lex sp-defs-231012/diff 1459
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INPUT--DOCUMENTS lexConcept
predicate: definition
changes:
  changes: ++ "* Input documents” are for example * Imported documents that are stored as “unstructured” content in the ALM in the first step (no work items created already) * Unstructured documents that are step by step converted to documents with structured work items * A model or model sketch from another modelling system, that is not compliant or convertible to SP modelling method/system, created as input document with concrete Polarion work items in the status “proposal”. These are seen as input sketches and are added manually into the SP modelling system using the correct method and modelling process * ALM documents in which new work items are created in a free structure and sequence (workflow designed in the domains) * Input documents are not used as formal deliverable (because they are created manually and may not contain all work items in a certain scope), but they can be used as background documentation. * The differentiation of input and output documents allows to create input documents along the needs of the workflows – having “things at one place where the team is currently working” – without the constraint to structure or “sort” it as a formal output (image: 1-screenshot-20221230-141047.png)"
  changes: -- "* Input documents” are for example * Imported documents that are stored as “unstructured” content in the ALM in the first step (no work items created already) * Unstructured documents that are step by step converted to documents with structured work items * A model or model sketch from another modelling system, that is not compliant or convertible to SP modelling method/system, created as input document with concrete Polarion work items in the status “proposal”. These are seen as input sketches and are added manually into the SP modelling system using the correct method and modelling process * ALM documents in which new work items are created in a free structure and sequence (workflow designed in the domains) * Input documents are not used as formal deliverable (because they are created manually and may not contain all work items in a certain scope), but they can be used as background documentation. * The differentiation of input and output documents allows to create input documents along the needs of the workflows – having “things at one place where the team is currently working” – without the constraint to structure or “sort” it as a formal output (image: 1-screenshot-20221230-141047.png)"

diff/lex sp-defs-231012/diff 1460
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INTEGRATION--TASK lexConcept
predicate: definition
changes:
  changes: ++ "* Combine elements, validate/test whole system behaviour, implement/commission * Right side of CENELEC “V”"
  changes: -- "* Combine elements, validate/test whole system behaviour, implement/commission * Right side of CENELEC “V”"

diff/lex sp-defs-231012/diff 1461
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/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 without any integration effort (lowest reasonable integration effort) 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)."
  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 without any integration effort (lowest reasonable integration effort) and without any need for recertification. Exchangeability and interchangeability are related to the physical characteristics of sub-systems wheres interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."

diff/lex sp-defs-231012/diff 1462
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INTERFACE lexConcept 2
predicate: definition
changes:
  changes: ++ "Based on ISO/IEC 2382, a shared boundary between two systems or subsystems, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics."
  changes: -- "With an interface the sub-systems of different suppliers are combined."

diff/lex sp-defs-231012/diff 1463
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INTERFACE lexConcept 3
predicate: definition
changes:
  changes: ++ "a means provided or required by components for an interaction between them or with actors"
  changes: -- "Based on ISO/IEC 2382, a shared boundary between two systems or subsystems, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics."

diff/lex sp-defs-231012/diff 1464
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INTEROPERABILITY lexConcept
predicate: definition
changes:
  changes: ++ "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance.Reference to the TSI (European Regulation) would be good to understand the importance (double. needs to be deleted)"
  changes: -- "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance. [Subset-023], [IOP-Dir 2016/797] so that a train is able to run across different infrastructure networks (IMs) and that an infrastructure network is able to interact with trains of different Railway Undertakings, using systems/sub-systems from different origins. Exchangeability and interchangeability are related to the physical characteristics of sub-systems wheres interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."

diff/lex sp-defs-231012/diff 1465
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: INTEROPERABILITY lexConcept 2
predicate: definition
changes:
  changes: ++ "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance, see [Subset-023] SPT2ARC-1619 and [IOP-Dir 2016/797] SPT2ARC-1617 so that a train is able to run across different infrastructure networks (IMs) and that an infrastructure network 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.Reference to the TSI (European Regulation) would be good to understand the importance (double. needs to be deleted)"

diff/lex sp-defs-231012/diff 1466
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: LEXICAL--GLOSSARY lexConcept
predicate: definition
changes:
  changes: ++ "either imported from outside the project or authored inside the project, lexical glossaries are the containers for lexical entiries and abbreviations. A lexical glossary is first consolidated by its glossary author in its own scope, i.e. its definitions shall not be redundant with each other. It is then consolidated towards other glossaries. This glossary is then called SPPR-5441 - Missing cross-reference. Lexical glossaries are the source of the lexical definitons and abbreviations referred to in SPPR-5434 - Refering document."
  changes: -- "either imported from outside the project or authored inside the project, lexical glossaries are the containers for lexical entiries and abbreviations. A lexical glossary is first consolidated by its glossary author in its own scope, i.e. its definitions shall not be redundant with each other. It is then consolidated towards other glossaries. This glossary is then called SPPR-5441 - Missing cross-reference. Lexical glossaries are the source of the lexical definitons and abbreviations referred to in SPPR-5434 - Refering document."

diff/lex sp-defs-231012/diff 1467
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: LOGIAL--COMPONENT lexConcept
predicate: definition
changes:
  changes: ++ "conceptual element being part of the system, contributing to its behaviour, by interacting with other logical components and logical actors"
  changes: -- "conceptual element being part of the system, contributing to its behaviour, by interacting with other logical components and logical actors"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -13

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -13

diff/lex sp-defs-231012/diff 1468
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: LOGISTIC--DELAY lexConcept
predicate: definition
changes:
  changes: ++ "delay, excluding administrative delay, incurred for the provision of resources needed for a maintenance action to proceed or continue. [SOURCE: IEC 60050-192:2015, 192-07-13]"
  changes: -- "delay, excluding administrative delay, incurred for the provision of resources needed for a maintenance action to proceed or continue. [SOURCE: IEC 60050-192:2015, 192-07-13]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -22

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -22

diff/lex sp-defs-231012/diff 1469
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MACMT lexConcept
predicate: definition
changes:
  changes: ++ "mean active corrective maintenance time expectation of the active corrective maintenance time [SOURCE: IEC 60050-192:2015, 192-07-22]"
  changes: -- "mean active corrective maintenance time expectation of the active corrective maintenance time [SOURCE: IEC 60050-192:2015, 192-07-22]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -26

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -26

diff/lex sp-defs-231012/diff 1470
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MAD lexConcept
predicate: definition
changes:
  changes: ++ "mean administrative delay. Expectation of the administrative delay. [SOURCE: IEC 60050-192:2015,192-07-26]"
  changes: -- "mean administrative delay. Expectation of the administrative delay. [SOURCE: IEC 60050-192:2015,192-07-26]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -01
…: -27
…: , --
…: type
…: 1

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -01
…: -27

diff/lex sp-defs-231012/diff 1471
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MAINTAINABILITY--<OF--AN--ITEM> lexConcept
predicate: definition
changes:
  changes: ++ "Ability to be retained in, or restored to, a state to perform as required, under given conditions of use and maintenance Note 1 to entry: Given conditions would include aspects that affect maintainability, such as: location for maintenance, accessibility, maintenance procedures and maintenance resources. [SOURCE: IEC 60050-192:2015, 192-01-27] Source: SPPRAMSS-349 - [EN 50126-1:2017]"
  changes: -- "Ability to be retained in, or restored to, a state to perform as required, under given conditions of use and maintenance Note 1 to entry: Given conditions would include aspects that affect maintainability, such as: location for maintenance, accessibility, maintenance procedures and maintenance resources. [SOURCE: IEC 60050-192:2015, 192-01-27] Source: SPPRAMSS-349 - [EN 50126-1:2017]"

diff/lex sp-defs-231012/diff 1472
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MAINTAINABILITY lexConcept
predicate: definition
changes:
  changes: ++ "Ability to be retained in, or restored to, a state to perform as required, under given conditions of use and maintenance [EN50126] SPT2ARC-1616 ."
  changes: -- "Ability to be retained in, or restored to, a state to perform as required, under given conditions of use and maintenance [EN50126]."

diff/lex sp-defs-231012/diff 1473
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MANAGEMENT--BY--TRACEABILITY--KANBAN--BASED lexConcept
predicate: definition
changes:
  changes: ++ "A trace (nodes/work items and their links) is a graph that works out one issue (e.g. one requirement) in the most efficient, complete and fast way, down to its operational and system implementation (image: 1-image10.png)"
  changes: -- "A trace (nodes/work items and their links) is a graph that works out one issue (e.g. one requirement) in the most efficient, complete and fast way, down to its operational and system implementation (image: 1-image10.png)"

diff/lex sp-defs-231012/diff 1474
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MDBF lexConcept
predicate: definition
changes:
  changes: ++ "Mean Distance Between Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"
  changes: -- "Mean Distance Between Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"

diff/lex sp-defs-231012/diff 1475
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MDBSF lexConcept
predicate: definition
changes:
  changes: ++ "Mean Distance Between Service Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"
  changes: -- "Mean Distance Between Service Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"

…:
  diff/lex sp-defs-231012: 2016

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -27

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -27

diff/lex sp-defs-231012/diff 1479
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MLD lexConcept
predicate: definition
changes:
  changes: ++ "mean logistic delay. Expectation of the logistic delay. [SOURCE: IEC 60050-192:2015,192-07-27]"
  changes: -- "mean logistic delay. Expectation of the logistic delay. [SOURCE: IEC 60050-192:2015,192-07-27]"

diff/lex sp-defs-231012/diff 1480
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MODE--TRANSITION lexConcept
predicate: definition
changes:
  changes: ++ "A change of mode toward itself or toward another mode. A transition is characterised by a trigger which can be a boolean condition applied on certain model elements, such as functional exchanges."
  changes: -- "A change of mode toward itself or toward another mode. A transition is characterised by a trigger which can be a boolean condition applied on certain model elements, such as functional exchanges."

diff/lex sp-defs-231012/diff 1481
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MODEL--SYNCHRONISATION lexConcept
predicate: definition
changes:
  changes: ++ "* There are two types of synchronisations: * A copy of all MBSE models is stored in the ALM. The copied work items can be part of the ALM workflow or can be approved, decided, commented and linked in the ALM. * Synchronisation between “mother LA/PA” and “daughter LA/PA” in the MBSE platform. These are done to split architecting work to different teams. * Example (start situation for the SP): (image: 1-Picture_1.png)"
  changes: -- "* There are two types of synchronisations: * A copy of all MBSE models is stored in the ALM. The copied work items can be part of the ALM workflow or can be approved, decided, commented and linked in the ALM. * Synchronisation between “mother LA/PA” and “daughter LA/PA” in the MBSE platform. These are done to split architecting work to different teams. * Example (start situation for the SP): (image: 1-Picture_1.png)"

diff/lex sp-defs-231012/diff 1482
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MODULARITY lexConcept
predicate: definition
changes:
  changes: ++ "Modularity is used in this document as a general term for dividing a system/sub-system/module in sub-systems/modules."
  changes: -- "Modularity is used in this document as a general term for devide a system/sub-system/module in sub-systems/modules."

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

diff/lex sp-defs-231012/diff 1484
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MODULE lexConcept
predicate: definition
changes:
  changes: ++ "{comment:34} A module is a sourceable unit of the CCS system (hardware and/or software), having full defined functionality, interface, performance, safety. {comment:180}"
  changes: -- "{comment:34} A module is a sourceable unit of the CCS system (hardware and/or software), having full defined functionality, interface, performance, safety. {comment:180}"

diff/lex sp-defs-231012/diff 1485
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MOE lexConcept
predicate: definition
changes:
  changes: ++ "Measure of Effectiveness (that the system performs as required). Characteristics: * Relates to performance * Objective * Simple to state * Testable * Complete * Clear * States any time dependency * States any environmental conditions * Can be measured quantitatively (if required, may be measured statistically or as a probability) * Easy to measure * Select only MoEs that measure the degree to which the desired outcome is achieved * Use the same MoEs to measure more than one condition when appropriate * Structure so that they have measurable, collectible, and relevant indicators * Write as statements (not questions) * Maximize clarity"
  changes: -- "Measure of Effectiveness (that the system performs as required). Characteristics: * Relates to performance * Objective * Simple to state * Testable * Complete * Clear * States any time dependency * States any environmental conditions * Can be measured quantitatively (if required, may be measured statistically or as a probability) * Easy to measure * Select only MoEs that measure the degree to which the desired outcome is achieved * Use the same MoEs to measure more than one condition when appropriate * Structure so that they have measurable, collectible, and relevant indicators * Write as statements (not questions) * Maximize clarity"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -13

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -13

diff/lex sp-defs-231012/diff 1486
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MOTBF lexConcept
predicate: definition
changes:
  changes: ++ "mean operating time between failures expectation of the duration of the operating time between failures Note 1 to entry: Mean operating time between failures should only be applied to repairable items. For non-repairable items, see mean operating time to failure (192-05-11) SPPRAMSS-4040 - MTTF . [SOURCE: IEC 60050-192:2015, 192-05-13]"
  changes: -- "mean operating time between failures expectation of the duration of the operating time between failures Note 1 to entry: Mean operating time between failures should only be applied to repairable items. For non-repairable items, see mean operating time to failure (192-05-11) SPPRAMSS-4040 - MTTF . [SOURCE: IEC 60050-192:2015, 192-05-13]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -21
diff/lex sp-defs-231012:
  diff/lex sp-defs-231012: 2016
diff/lex sp-defs-231012: , --
diff/lex sp-defs-231012:
  …: 60050
  …: -192
  …: diff/lex sp-defs-231012/2015
  …: 192
  …: -07
  …: -21
diff/lex sp-defs-231012: 1
diff/lex sp-defs-231012: diff/lex sp-defs-231012
diff/lex sp-defs-231012:
  diff/lex sp-defs-231012: 2016

diff/lex sp-defs-231012/diff 1487
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MRT lexConcept
predicate: definition
changes:
  changes: ++ "expectation of the (mean) repair time [SOURCE: IEC 60050-192:2015, 192-07-21] Note 1: MRT = fault localization time + fault correction time + function checkout time according SPPRAMSS-3539 - [EN 61703: 2016]"
  changes: -- "expectation of the (mean) repair time [SOURCE: IEC 60050-192:2015, 192-07-21] Note 1: MRT = FLT + FCT + FCKT according SPPRAMSS-3539 - [EN 61703: 2016]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -13

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -13

diff/lex sp-defs-231012/diff 1488
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MTBF lexConcept 2
predicate: definition
changes:
  changes: ++ "mean operating time between failures expectation of the duration of the operating time between failures Note 1 to entry: Mean operating time between failures should only be applied to repairable items. For non-repairable items, see mean operating time to failure (192-05-11) SPPRAMSS-4040 - MTTF . [SOURCE: IEC 60050-192:2015, 192-05-13]"
  changes: -- "mean operating time between failures expectation of the duration of the operating time between failures Note 1 to entry: Mean operating time between failures should only be applied to repairable items. For non-repairable items, see mean operating time to failure (192-05-11) SPPRAMSS-4040 - MTTF . [SOURCE: IEC 60050-192:2015, 192-05-13]"

diff/lex sp-defs-231012/diff 1489
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MTBSF lexConcept
predicate: definition
changes:
  changes: ++ "mean operating time between service failures Note 1 to entry: Service failures should be defined as one of the failures severity levels. These failures are understood as failures with operational impact. For example failures for which the safety reaction is application of the service brake. Note 2 to entry: Abbreviation is not yet defined in any CEN/CENELEC railway standard but is often used by railway operators and infrastructure managers."
  changes: -- "Mean (operating) Time Between Service Failures Note: it is often used by customers to distinguish the failure classes with operational impact from intrinsic ones. It is not coming from a standard."

diff/lex sp-defs-231012/diff 1490
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MTD lexConcept
predicate: definition
changes:
  changes: ++ "mean technical delay [SOURCE: SPPRAMSS-349 - [EN 50126-1:2017] Annex B.4]"
  changes: -- "mean technical delay [SOURCE: SPPRAMSS-349 - [EN 50126-1:2017] Annex B.4]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -12

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -12

diff/lex sp-defs-231012/diff 1491
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: MTTFF lexConcept
predicate: definition
changes:
  changes: ++ "mean operating time to first failure expectation of the operating time to first failure Note 1 to entry: See also operating time to first failure (192-05-02). Note 2 to entry: For non-repairable items, the MTTFF is also the MTTF. [SOURCE: IEC 60050-192:2015, 192-05-12]"
  changes: -- "mean operating time to first failure expectation of the operating time to first failure Note 1 to entry: See also operating time to first failure (192-05-02). Note 2 to entry: For non-repairable items, the MTTFF is also the MTTF. [SOURCE: IEC 60050-192:2015, 192-05-12]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -11

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -11

diff/lex sp-defs-231012: 2016

…: 60050
…: -192
…: 192
…: -07
…: -23
…: 2

diff/lex sp-defs-231012/diff 1494
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: NATIONAL--IMPLEMENATION--PLAN lexConcept
predicate: definition
changes:
  changes: ++ "In 2016, the EC also asked the EU Member States to establish the so-called “National Implementation Plans” (NIPs) in which they have to describe their actions to comply with the relevant standard for ERTMS, i.e. CCS TSI 2016/919. The CCS TSI regulates the implementation of fully interoperable 'control-command and signalling' subsystems. The NIPs have to fulfil two conditions, i.e. they must cover a period of at least 15 years and they must be updated every 5 years. In addition, they have to contain the following information: (image: 1-screenshot-20230616-124455.png)"
  changes: -- "In 2016, the EC also asked the EU Member States to establish the so-called “National Implementation Plans” (NIPs) in which they have to describe their actions to comply with the relevant standard for ERTMS, i.e. CCS TSI 2016/919. The CCS TSI regulates the implementation of fully interoperable 'control-command and signalling' subsystems. The NIPs have to fulfil two conditions, i.e. they must cover a period of at least 15 years and they must be updated every 5 years. In addition, they have to contain the following information: (image: 1-screenshot-20230616-124455.png)"

diff/lex sp-defs-231012/diff 1497
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: NON-FUNCTIONAL--REQUIREMENTS lexConcept
predicate: definition
changes:
  changes: ++ "Non-Functional Requirements are constraints on the system that define how well something is to be done or how it is to be done which fall into three categories:{comment:66} * Performance Requirements SPPR-4175 - Performance Requirements ; * System Requirements SPPR-4177 - System Requirements ;{comment:65} * Implementation Requirements SPPR-4180 - Implementation Requirements . These categories are derived from consideration of the essential relationships with the Operational{comment:31} and Functional Requirements and ensure the completeness and consistency of the requirements model (It is these essential relationships between the functionally-based requirements and constraint-based requirements that make the Holistic Requirements Model so useful)."
  changes: -- "Non-Functional Requirements are constraints on the system that define how well something is to be done or how it is to be done which fall into three categories:{comment:66} * Performance Requirements SPPR-4175 - Performance Requirements ; * System Requirements SPPR-4177 - System Requirements ;{comment:65} * Implementation Requirements SPPR-4180 - Implementation Requirements . These categories are derived from consideration of the essential relationships with the Operational{comment:31} and Functional Requirements and ensure the completeness and consistency of the requirements model (It is these essential relationships between the functionally-based requirements and constraint-based requirements that make the Holistic Requirements Model so useful)."

diff/lex sp-defs-231012/diff 1498
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: NOTIF-IT lexConcept
predicate: definition
changes:
  changes: ++ "The database for Notified National Rules. Has been replaced by SRD: Single Rule Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]"
  changes: -- "The database for Notified National Rules. Has been replaced by SRD: Single Rule Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]"

diff/lex sp-defs-231012/diff 1499
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OAB -- ENTITIES ACTORS lexConcept
predicate: definition
changes:
  changes: ++ "Capella Viewpoint. Purpose: displays the sub-entities and actors of an entity. Rule: contains at least 1 operational entity Rule: May contain operational actors Rule: contains no operational activities Filter: TBD"
  changes: -- "Capella Viewpoint. Purpose: displays the sub-entities and actors of an entity. Rule: contains at least 1 operational entity Rule: May contain operational actors Rule: contains no operational activities Filter: TBD"

diff/lex sp-defs-231012/diff 1500
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OAB -- PROCESS--INVOLVEMENT lexConcept
predicate: definition
changes:
  changes: ++ "Capella Viewpoint. Purpose: For a process p, displays the activities it involves and the entities or actors they are allocated to. Rule0: There is one and only one [OAB][ProcessInvolvement] per process Rule1: At least each leaf activity/actor hosting the an activity of p shall be displayed on the diagram. Rule2: Structure Entities, defined as containing the activity or actors or rule 1, may be displayed (Author's decision). If so, the diagram shall remain clear even if exported on A4 protrait. Rule3: Contains at least 1 operational entity, at least 2 actitivies. Rule4: The diagram forbids entities or actors that do not allocate any activity of the process it describes Filter: TBD"
  changes: -- "Capella Viewpoint. Purpose: For a process p, displays the activities it involves and the entities or actors they are allocated to. Rule0: There is one and only one [OAB][ProcessInvolvement] per process Rule1: At least each leaf activity/actor hosting the an activity of p shall be displayed on the diagram. Rule2: Structure Entities, defined as containing the activity or actors or rule 1, may be displayed (Author's decision). If so, the diagram shall remain clear even if exported on A4 protrait. Rule3: Contains at least 1 operational entity, at least 2 actitivies. Rule4: The diagram forbids entities or actors that do not allocate any activity of the process it describes Filter: TBD"

diff/lex sp-defs-231012/diff 1501
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OAIB -- OPERATIONAL--PROCESS lexConcept
predicate: definition
changes:
  changes: ++ "Capella Viewpoint. Purpose: displays the activities of a process. Rule: contains at least 2 operational activity Rule: each activity has an interaction with another activity Filter: TBD"
  changes: -- "Capella Viewpoint. Purpose: displays the activities of a process. Rule: contains at least 2 operational activity Rule: each activity has an interaction with another activity Filter: TBD"

diff/lex sp-defs-231012/diff 1504
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OCB -- STRUCTURE lexConcept
predicate: definition
changes:
  changes: ++ "Capella Viewpoint. Purpose: displays the hierachy of operational capabilities - and only that Rule: contains only capabilities and their relationships, no entities Rule: organised as a tree (folder like) Filter: * Yes: Hide Communication Means * Yes: Hide Involvement Links * TBD: Hide Operational Capabiltiy Extends * TBD: Hide Operational Capabiltiy Includes * TBD: Hide Operational Capabiltiy Generatlizations * Yes: Hide Property Values * Yes: Hide Diagram Title Blocks * Yes: Hilde Element Title Blocks"
  changes: -- "Capella Viewpoint. Purpose: displays the hierachy of operational capabilities - and only that Rule: contains only capabilities and their relationships, no entities Rule: organised as a tree (folder like) Filter: * Yes: Hide Communication Means * Yes: Hide Involvement Links * TBD: Hide Operational Capabiltiy Extends * TBD: Hide Operational Capabiltiy Includes * TBD: Hide Operational Capabiltiy Generatlizations * Yes: Hide Property Values * Yes: Hide Diagram Title Blocks * Yes: Hilde Element Title Blocks"

diff/lex sp-defs-231012/diff 1505
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OES -- OPERATIONAL--PROCESS -- SCENARIO lexConcept
predicate: definition
changes:
  changes: ++ "Capella Viewpoint. Purpose: Display the selected sequence of activities, interactions and related dependencies in a swimlane diagram Rule: Each activity is deployed to an entity or an actor. Rule: Each activity has at least one input and one output interaction. Filter: TBD selected path/sequence"
  changes: -- "Capella Viewpoint. Purpose: Display the selected sequence of activities, interactions and related dependencies in a swimlane diagram Rule: Each activity is deployed to an entity or an actor. Rule: Each activity has at least one input and one output interaction. Filter: TBD selected path/sequence"

diff/lex sp-defs-231012/diff 1506
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OPD -- OPERATIONAL--PROCESS -- LOGIC lexConcept
predicate: definition
changes:
  changes: ++ "Capella viewpoint Purpose: Show all activities of operational process with their data flow (interactions) and control flow. Rule: Each activity has at least one input and one output interaction. Filter: TBD"
  changes: -- "Capella viewpoint Purpose: Show all activities of operational process with their data flow (interactions) and control flow. Rule: Each activity has at least one input and one output interaction. Filter: TBD"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -01

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -05
…: -01

diff/lex sp-defs-231012/diff 1507
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OPERATING--TIME--TO--FAILURE--<OF--AN--ITEM> lexConcept
predicate: definition
changes:
  changes: ++ "operating time accumulated from the first use, or from restoration, until failure Note 1 to entry: See also operating time (192-02-05) SPPRAMSS-4080 - operating time . [SOURCE: IEC 60050-192:2015, 192-05-01]"
  changes: -- "operating time accumulated from the first use, or from restoration, until failure Note 1 to entry: See also operating time (192-02-05) SPPRAMSS-4080 - operating time . [SOURCE: IEC 60050-192:2015, 192-05-01]"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -02
…: -05

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -02
…: -05

diff/lex sp-defs-231012/diff 1508
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: OPERATING--TIME lexConcept
predicate: definition
changes:
  changes: ++ "Time interval for which an item is in an operating state Note 1 to entry: The duration of operating time may be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc., and the units should always be clearly stated. [SOURCE: IEC 60050-192:2015, 192-02-05]"
  changes: -- "Time interval for which an item is in an operating state Note 1 to entry: The duration of operating time may be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc., and the units should always be clearly stated. [SOURCE: IEC 60050-192:2015, 192-02-05]"

diff/lex sp-defs-231012/diff 1515
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: PERFORMANCE--<--OF--AN--ITEM--> lexConcept
predicate: definition
changes:
  changes: ++ "Performance is the ability of all technical and operational functions, in a specific operational context, to deliver a pre-defined and agreed level of service of the system and/or vehicle in operation. With the addition (and further clarification) that: The minimum level of performance is determined and influenced by technical and operational aspects on system, vehicle and operational level, such as but not limited to: reliability, availability, maintainability, safety, security, human factors, quality, mission profile, environment, environmental conditions and laws and regulations. This means the scope and boundaries (span of control) of performance need to be defined clearly. This also stresses why the inclusion of the principles of the RAM Policy to the ERJU activities for PRAMS, is of high importance."
  changes: -- "Performance is the ability of all technical and operational functions, in a specific operational context, to deliver a pre-defined and agreed level of service of the system and/or vehicle in operation. With the addition (and further clarification) that: The minimum level of performance is determined and influenced by technical and operational aspects on system, vehicle and operational level, such as but not limited to: reliability, availability, maintainability, safety, security, human factors, quality, mission profile, environment, environmental conditions and laws and regulations. This means the scope and boundaries (span of control) of performance need to be defined clearly. This also stresses why the inclusion of the principles of the RAM Policy to the ERJU activities for PRAMS, is of high importance."

diff/lex sp-defs-231012/2010: 3.6
diff/lex sp-defs-231012/2010: .19
entity: diff/lex sp-defs-231012/entity
entity: PFH lexConcept
predicate: definition
changes:
  changes: ++
  changes: type
  changes: 1

diff/lex sp-defs-231012/2010: 3.6
diff/lex sp-defs-231012/2010: .19

…: 61508
…: -4
…: diff/lex sp-defs-231012/2010

…: 61508
…: -4
…: diff/lex sp-defs-231012/2010

diff/lex sp-defs-231012/diff 1518
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: PFH lexConcept 3
predicate: definition
changes:
  changes: ++ "probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]"
  changes: -- "probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]"

diff/lex sp-defs-231012/diff 1519
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: PHYSICAL--LINK lexConcept
predicate: definition
changes:
  changes: ++ "means of communication/transport relating to the hosting of physical components, used as a medium by exchanges between behavioural components"
  changes: -- "means of communication/transport relating to the hosting of physical components, used as a medium by exchanges between behavioural components"

diff/lex sp-defs-231012/diff 1520
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: PHYSICAL--PORT lexConcept
predicate: definition
changes:
  changes: ++ "connection point of one or more physical links allocated to a host component, by specifying how the component can be connected to the others or external actors"
  changes: -- "connection point of one or more physical links allocated to a host component, by specifying how the component can be connected to the others or external actors"

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -11
…: -03

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -01
…: -24
…: , --
…: type

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -01
…: -24

diff/lex sp-defs-231012/diff 1524
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: RELIABILITY--<OF--AN--ITEM> lexConcept
predicate: definition
changes:
  changes: ++ "Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - [EN 50126-1:2017]"
  changes: -- "Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - [EN 50126-1:2017]"

diff/lex sp-defs-231012/diff 1527
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: REQUIREMENT--STATEMENT lexConcept
predicate: definition
changes:
  changes: ++ "A requirement statement is the result of a formal transformation of one or more needs or parent requirements into an agreed-to obligation for an entity to perform some function or possess some quality within specified constraints with acceptable risk. Requirements are formal textual “shall” statements that communicate in a structured, natural language what an entity must do to realise the intent of the needs from which they were transformed. (Source: https://portal.incose.org/commerce/store?productId=INCOSE-GUIDEWRITINGREQ)"
  changes: -- "A requirement statement is the result of a formal transformation of one or more needs or parent requirements into an agreed-to obligation for an entity to perform some function or possess some quality within specified constraints with acceptable risk. Requirements are formal textual “shall” statements that communicate in a structured, natural language what an entity must do to realise the intent of the needs from which they were transformed. (Source: https://portal.incose.org/commerce/store?productId=INCOSE-GUIDEWRITINGREQ)"

…: 60050
…: -903
…: diff/lex sp-defs-231012/2013
…: 903
…: -01
…: -07
…: type
…: harm
…: accident

…: 60050
…: -903
…: diff/lex sp-defs-231012/2013
…: 903
…: -01
…: -07
…: harm
…: accident

…: 60050
…: -903
…: diff/lex sp-defs-231012/2013
…: 903
…: -01
…: -08

…: 60050
…: -903
…: diff/lex sp-defs-231012/2013
…: 903
…: -01
…: -10

…: 60050
…: -903
…: diff/lex sp-defs-231012/2013
…: 903
…: -01
…: -10

diff/lex sp-defs-231012/diff 1532
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: RISK--ASSESSMENT lexConcept
predicate: definition
changes:
  changes: ++ "overall process comprising a risk analysis and a risk evaluation [Source: IEC 60050-903:2013, 903-01-10]"
  changes: -- "overall process comprising a risk analysis and a risk evaluation [Source: IEC 60050-903:2013, 903-01-10]"

…: 60050
…: -903
…: diff/lex sp-defs-231012/2013
…: 903
…: -01
…: -09

…: 60050
…: -903
…: diff/lex sp-defs-231012/2013
…: 903
…: -01
…: -09

diff/lex sp-defs-231012/diff 1533
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: RISK--EVALUATION lexConcept
predicate: definition
changes:
  changes: ++ "procedure based on the risk analysis to determine whether the tolerable risk has been achieved [Source: IEC 60050-903:2013, 903-01-09]"
  changes: -- "procedure based on the risk analysis to determine whether the tolerable risk has been achieved [Source: IEC 60050-903:2013, 903-01-09]"

…: 62425
…: diff/lex sp-defs-231012/2007
…: 3.1
…: .42

…: 62425
…: diff/lex sp-defs-231012/2007
…: 3.1
…: .42

diff/lex sp-defs-231012/diff 1537
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SAFE--STATE-- 821-12-49 lexConcept
predicate: definition
changes:
  changes: ++ "condition which continues to preserve safety [SOURCE: IEC 62425:2007, 3.1.42]"
  changes: -- "condition which continues to preserve safety [SOURCE: IEC 62425:2007, 3.1.42]"

…: 60050
…: -821
…: 821
…: -12
…: -49

…: 60050
…: -821
…: 821
…: -12
…: -49

diff/lex sp-defs-231012/diff 1538
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SAFE--STATE lexConcept
predicate: definition
changes:
  changes: ++ "condition which continues to preserve safety [Source: IEC 60050-821, 821-12-49]"
  changes: -- "condition which continues to preserve safety [Source: IEC 60050-821, 821-12-49]"

diff/lex sp-defs-231012/2007: 3.1
diff/lex sp-defs-231012/2007: .42

diff/lex sp-defs-231012/2007: 3.1
diff/lex sp-defs-231012/2007: .42

diff/lex sp-defs-231012/diff 1539
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SAFE--STATE lexConcept 2
predicate: definition
changes:
  changes: ++ "condition which continues to preserve safety [821-12-49][IEC 62425:2007, 3.1.42]"
  changes: -- "condition which continues to preserve safety [821-12-49][IEC 62425:2007, 3.1.42]"

diff/lex sp-defs-231012/diff 1540
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SAFETY--INVARIANT lexConcept
predicate: definition
changes:
  changes: ++ "Safety requirement regarding conditions or properties that are critical for maintaining the safe operation of a system. It ensures that the system does not enter into a hazardous state or condition. Note: By defining and monitoring an invariant, engineers and safety professionals can detect deviations from expected behavior and take corrective actions to prevent accidents or failures. Invariants are often used in formal methods, fault tree analysis, hazard analysis, and other safety assessment techniques to ensure the robustness and reliability of systems."
  changes: -- "Safety requirement regarding conditions or properties that are critical for maintaining the safe operation of a system. It ensures that the system does not enter into a hazardous state or condition. Note: By defining and monitoring an invariant, engineers and safety professionals can detect deviations from expected behavior and take corrective actions to prevent accidents or failures. Invariants are often used in formal methods, fault tree analysis, hazard analysis, and other safety assessment techniques to ensure the robustness and reliability of systems."

diff/lex sp-defs-231012/diff 1543
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/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;{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."
  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-231012/diff 1544
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SERA-CCS lexConcept
predicate: definition
changes:
  changes: ++ "SERA-CCS{comment:3} Single European Railway Area - Command Control and Signaling: For the railway sector, EU policy focuses on the main goal of establishing a single European railway area, an EU-wide system of railway networks which would allow the expansion of the rail sector based on * competition, * technical harmonization and * joint development of cross-border connections [see Building the single European railway area]. To this end, the EU aims to: * open and restructure the rail market * increase competitiveness by creating a level playing field for companies * develop infrastructure to ensure interoperability * improve efficiency in infrastructure use and safety * ensure fair prices for consumers{comment:5} SERA-CCS is understood to consist of those SERA objectives which are relevant for CCS (technical/operational target). It is defined by the following capabilities: * Provides Independence between Infrastructure Managers (IM) and Railway Undertakings (RU) or Vehicle Owners (VO): * No track access restriction or extra costs for a compliant RU/VO fleet/services accessing a given IM infrastructure compliant with SERA-CCS. * Non discriminatory access to IM services and capacity allocation across SERA-CCS IMs for compliant RU/VO fleet/services. * Ensures interoperability, which is the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance across different infrastructure networks (IMs) and the ability that an infrastructure network is able to interact with trains of different RUs/VOs. * Ensures Harmonized Operations, based on: * Radio-based CAB Signalling, * Automatic Train{comment:1} Operation (ATO), * Single licensing for Drivers and Signalers across SERA-CCS. * Provides Backwards Compatibility: * Compatibility is considered to be achieved for a particular combination of on-board and trackside when the on-board is able to run a normal service on that trackside. The expression “train is running a nor…
  changes: -- "SERA-CCS{comment:3} Single European Railway Area - Command Control and Signaling: For the railway sector, EU policy focuses on the main goal of establishing a single European railway area, an EU-wide system of railway networks which would allow the expansion of the rail sector based on * competition, * technical harmonization and * joint development of cross-border connections [see Building the single European railway area]. To this end, the EU aims to: * open and restructure the rail market * increase competitiveness by creating a level playing field for companies * develop infrastructure to ensure interoperability * improve efficiency in infrastructure use and safety * ensure fair prices for consumers{comment:5} SERA-CCS is understood to consist of those SERA objectives which are relevant for CCS (technical/operational target). It is defined by the following capabilities: * Provides Independence between Infrastructure Managers (IM) and Railway Undertakings (RU) or Vehicle Owners (VO): * No track access restriction or extra costs for a compliant RU/VO fleet/services accessing a given IM infrastructure compliant with SERA-CCS. * Non discriminatory access to IM services and capacity allocation across SERA-CCS IMs for compliant RU/VO fleet/services. * Ensures interoperability, which is the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance across different infrastructure networks (IMs) and the ability that an infrastructure network is able to interact with trains of different RUs/VOs. * Ensures Harmonized Operations, based on: * Radio-based CAB Signalling, * Automatic Train{comment:1} Operation (ATO), * Single licensing for Drivers and Signalers across SERA-CCS. * Provides Backwards Compatibility: * Compatibility is considered to be achieved for a particular combination of on-board and trackside when the on-board is able to run a normal service on that trackside. The expression “train is running a nor…

…: 3
…: 12

…: 3
…: 12

diff/lex sp-defs-231012/diff 1545
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SERIOUS--ACCIDENT lexConcept
predicate: definition
changes:
  changes: ++ "‘serious accident’ means any train collision or derailment of trains resulting in the death of at least one person or serious injuries to five or more persons or extensive damage to rolling stock, the infrastructure or the environment, and any other accident with the same consequences which has an obvious impact on railway safety regulation or the management of safety; ‘extensive damage’ means damage that can be immediately assessed by the investigating body to cost at least EUR 2 million in total; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (12) ]"
  changes: -- "‘serious accident’ means any train collision or derailment of trains resulting in the death of at least one person or serious injuries to five or more persons or extensive damage to rolling stock, the infrastructure or the environment, and any other accident with the same consequences which has an obvious impact on railway safety regulation or the management of safety; ‘extensive damage’ means damage that can be immediately assessed by the investigating body to cost at least EUR 2 million in total; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (12) ]"

diff/lex sp-defs-231012/diff 1547
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SITUATION lexConcept
predicate: definition
changes:
  changes: ++ "A logical combination of modes and states using logical operations (AND, OR, NOT) representing the superposition of modes and states occurring simultaneously at a given moment."
  changes: -- "A logical combination of modes and states using logical operations (AND, OR, NOT) representing the superposition of modes and states occurring simultaneously at a given moment."

diff/lex sp-defs-231012/diff 1548
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SPECIFICATION--TASK lexConcept
predicate: definition
changes:
  changes: ++ "* Result: specification for an artifact * Usually ends on CENELEC P4 * Left side of the CENELEC “V”"
  changes: -- "* Result: specification for an artifact * Usually ends on CENELEC P4 * Left side of the CENELEC “V”"

diff/lex sp-defs-231012/diff 1550
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SRD lexConcept
predicate: definition
changes:
  changes: ++ "Single Rules Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]"
  changes: -- "Single Rules Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]"

diff/lex sp-defs-231012/diff 1551
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: STAKEHOLDER--NEEDS lexConcept
predicate: definition
changes:
  changes: ++ "These needs are taken into account for the definition of the System of interest. Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree, - Requirements proposed by any party and approved in the SP decision process according to SP governance."
  changes: -- "These needs are taken into account for the definition of the System of interest. Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree, - Requirements proposed by any party and approved in the SP decision process according to SP governance."

diff/lex sp-defs-231012/diff 1552
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: STAKEHOLDER lexConcept
predicate: definition
changes:
  changes: ++ "Someone who is entitled to express needs for the system of interest. Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers."
  changes: -- "Someone who is entitled to express needs for the system of interest. Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers."

diff/lex sp-defs-231012/diff 1553
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: STPA lexConcept
predicate: definition
changes:
  changes: ++ "System Theoretic Process Analysis [Source: J3187:202305]"
  changes: -- "System Theoretic Process Analysis [Source: J3187:202305]"

diff/lex sp-defs-231012/diff 1554
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/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 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 with standard interfaces on System Level 5. Not to be confused with sub-systems in the TSI / interoperability directive. In the TSI / interoperability directive context a subssystem 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 + software, or just a piece of software. A sub-system is a sourceable 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 standardisation. The standardization of the sub-system’s features is to be defined according to the requested level: Functional apportionment / Interoperability / Exchangeability / Interchangeability."

diff/lex sp-defs-231012/diff 1555
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SUBSYSTEM lexConcept
predicate: definition
changes:
  changes: ++ "Subsystems are along ARCADIA systems with standard interfaces on System Level 5. Not to be confused with subsystems in the TSI / interoperability directive. A subsystem is a part of a system, which is not refined any further during the specification task(The term subsystem is used in this document following the referenced architecting standards, it does not correspond to the subsystem definition as in the Interoperability Directive.). It represents a leaf element in the hierarchy of systems-of-systems. A subsystem is defined by the following characteristics: * For each subsystem exists a set of specification documents, that allows a supplier to build that subsystem, ideally without the need for further documentation. * The level of strictness of the specification can be variable: * Interoperable specification: Strict standardisation of all interface aspects that are needed for to systems to fulfil a defined set of operational capabilities together on runtime. * Interchangeable specification: Standardisation of all interface aspects that are needed to exchange one of the systems with the lowest reasonable integration effort. * Core standardisation specification: An interoperable standardisation that defines a guaranteed minimum of interoperability, but allows and gives room for specific and perhaps incompatible extensions that are only used, when all involved systems have them. * Guideline: A recommended specification that can be used as a whole, or can be used partly or changed. * A subsystem can be implemented as software only, as hardware only, as a mixture of both depending on the strictness of the specification (the specification can leave that aspect open). * Each subsystem can be individually tendered to a supplier * Each subsystem can be built individually by a supplier * Each subsystem must be integrated into a system, which includes all necessary test, verification, certification and validation activities. Some non-functional requirements (e.g. weight c…
  changes: -- "Subsystems are along ARCADIA systems with standard interfaces on System Level 5. Not to be confused with subsystems in the TSI / interoperability directive. A subsystem is a part of a system, which is not refined any further during the specification task(The term subsystem is used in this document following the referenced architecting standards, it does not correspond to the subsystem definition as in the Interoperability Directive.). It represents a leaf element in the hierarchy of systems-of-systems. A subsystem is defined by the following characteristics: * For each subsystem exists a set of specification documents, that allows a supplier to build that subsystem, ideally without the need for further documentation. * The level of strictness of the specification can be variable: * Interoperable specification: Strict standardisation of all interface aspects that are needed for to systems to fulfil a defined set of operational capabilities together on runtime. * Interchangeable specification: Standardisation of all interface aspects that are needed to exchange one of the systems with the lowest reasonable integration effort. * Core standardisation specification: An interoperable standardisation that defines a guaranteed minimum of interoperability, but allows and gives room for specific and perhaps incompatible extensions that are only used, when all involved systems have them. * Guideline: A recommended specification that can be used as a whole, or can be used partly or changed. * A subsystem can be implemented as software only, as hardware only, as a mixture of both depending on the strictness of the specification (the specification can leave that aspect open). * Each subsystem can be individually tendered to a supplier * Each subsystem can be built individually by a supplier * Each subsystem must be integrated into a system, which includes all necessary test, verification, certification and validation activities. Some non-functional requirements (e.g. weight c…

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

diff/lex sp-defs-231012/diff 1557
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/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-231012/diff 1558
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/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-231012/diff 1560
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--AND--INNOVATION--PROGRAMME--BOARD lexConcept
predicate: definition
changes:
  changes: ++ "System and Innovation Programme Board advises the Executive Director on project and programme management of the JU including interaction between the two pillars as well as change management and conflicts, supported by the System Pillar Core Group"
  changes: -- "System and Innovation Programme Board advises the Executive Director on project and programme management of the JU including interaction between the two pillars as well as change management and conflicts, supported by the System Pillar Core Group"

diff/lex sp-defs-231012/diff 1561
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--DEVELOPMENT--LIFE--CYCLE lexConcept
predicate: definition
changes:
  changes: ++ "The System Development Life Cycle (SDLC) is a structured approach or methodology used in system engineering to guide the creation, deployment, and maintenance of systems. It provides a systematic framework for managing and controlling the entire process of building a system, from inception to retirement. The SDLC provides a structured approach to system development, ensuring that all necessary activities are carried out in a logical and controlled manner. It helps in managing risks, controlling costs, and delivering high-quality systems that meet stakeholder expectations."
  changes: -- "The System Development Life Cycle (SDLC) is a structured approach or methodology used in system engineering to guide the creation, deployment, and maintenance of systems. It provides a systematic framework for managing and controlling the entire process of building a system, from inception to retirement. The SDLC provides a structured approach to system development, ensuring that all necessary activities are carried out in a logical and controlled manner. It helps in managing risks, controlling costs, and delivering high-quality systems that meet stakeholder expectations."

diff/lex sp-defs-231012/diff 1562
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--LEVELS lexConcept
predicate: definition
changes:
  changes: ++ "The following figure shows the decomposition of a system of systems on one consistent example spanning 5 layers of refinement. Level 5 is the actual subsystem layer and is visually integrated into the bottom layer in the following figure to be able to show the relationship to logical components. (image: 1-screenshot-20221229-202431.png) Figure {caption:Figure}: System Level 1-5 combined view"
  changes: -- "The following figure shows the decomposition of a system of systems on one consistent example spanning 5 layers of refinement. Level 5 is the actual subsystem layer and is visually integrated into the bottom layer in the following figure to be able to show the relationship to logical components. (image: 1-screenshot-20221229-202431.png) Figure {caption:Figure}: System Level 1-5 combined view"

diff/lex sp-defs-231012/diff 1563
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--OF--SYSTEMS lexConcept
predicate: definition
changes:
  changes: ++ "According to ISO 21839, a system of systems is set of systems that interact to provide a unique capability that none of the constituent systems can accomplish on its own. A system of systems in our understanding at least comprises two constituent systems. A system of systems itself can be nested as a constituent system in a larger system of systems, i.e. system of systems can span multiple levels recursively."
  changes: -- "According to ISO 21839, a system of systems is set of systems that interact to provide a unique capability that none of the constituent systems can accomplish on its own. A system of systems in our understanding at least comprises two constituent systems. A system of systems itself can be nested as a constituent system in a larger system of systems, i.e. system of systems can span multiple levels recursively."

diff/lex sp-defs-231012/diff 1564
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--PILLAR--CORE--GROUP lexConcept
predicate: definition
changes:
  changes: ++ "System Pillar Core Group Manages the common business objectives and deliverables from the Tasks"
  changes: -- "System Pillar Core Group Manages the common business objectives and deliverables from the Tasks"

diff/lex sp-defs-231012/diff 1565
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--PILLAR--DELIVERABLES-- OUTPUT--DOCUMENTS lexConcept
predicate: definition
changes:
  changes: ++ "Deliverables are “output documents” that are automatically or manually created and exported from the engineering database (ALM) in the predefined structure of the SP deliverable templates List of deliverables per subsystem (System Level 5). ORS is done for System Level 3, and then tailored for the subsystems (especially CONEMP processes are done only on System Level 5). System specific Operational Requirement Specification (ORS) D2.1 As-Is analysis D2.2 Referred CBO and railway requirements D2.3 Problem analysis and derived process improvements D2.4 Application categories D2.5 Operational requirements (incl. non-functional and process requirements) D2.6 Operational entities and actor D2.7 Operational capabilities D2.8 PRAMSS targets, strategies and indicators D2.9 Operational processes D2.10 Operational hazards and risks D2.11 Rule books for all actors D2.12 The concept for the operational migrationFunctional Requirement Specification (FRS) D3.1 System definition D3.2 Detailed system actor descriptions and roles D3.3 System capabilities D3.4 Functional chains and sequences per capability D3.5 Function specification D3.6 Functional hazards and risksSystem requirement Specification (SRS) D4.1 Architecture of systems of the next level (if standardized) D4.2 Functional allocation to logical components D4.3 Physical architecture D4.4 Technical and physical hazards and risks D4.5 The technical migration strategy is defined D4.6 System requirements and interface specification, incl. legacy adpaters D4.7 Non-functional System requirementsApplication specification (ARS) D5.1 Release and Implementation Configurations D5.2 Application conditions, CSM/CST, HSI Plan D5.3 Application/life cycle/usage guideline/rules D5.4 Engineering and maintenance guideline/rules D5.5 Validation and test specificationValidation and test specification (VRS) D6.1 Model checking specification D6.2 Simulation/test environment specification D6.3 Simulation/test/validation cases and dataStandardis…
  changes: -- "Deliverables are “output documents” that are automatically or manually created and exported from the engineering database (ALM) in the predefined structure of the SP deliverable templates List of deliverables per subsystem (System Level 5). ORS is done for System Level 3, and then tailored for the subsystems (especially CONEMP processes are done only on System Level 5). System specific Operational Requirement Specification (ORS) D2.1 As-Is analysis D2.2 Referred CBO and railway requirements D2.3 Problem analysis and derived process improvements D2.4 Application categories D2.5 Operational requirements (incl. non-functional and process requirements) D2.6 Operational entities and actor D2.7 Operational capabilities D2.8 PRAMSS targets, strategies and indicators D2.9 Operational processes D2.10 Operational hazards and risks D2.11 Rule books for all actors D2.12 The concept for the operational migrationFunctional Requirement Specification (FRS) D3.1 System definition D3.2 Detailed system actor descriptions and roles D3.3 System capabilities D3.4 Functional chains and sequences per capability D3.5 Function specification D3.6 Functional hazards and risksSystem requirement Specification (SRS) D4.1 Architecture of systems of the next level (if standardized) D4.2 Functional allocation to logical components D4.3 Physical architecture D4.4 Technical and physical hazards and risks D4.5 The technical migration strategy is defined D4.6 System requirements and interface specification, incl. legacy adpaters D4.7 Non-functional System requirementsApplication specification (ARS) D5.1 Release and Implementation Configurations D5.2 Application conditions, CSM/CST, HSI Plan D5.3 Application/life cycle/usage guideline/rules D5.4 Engineering and maintenance guideline/rules D5.5 Validation and test specificationValidation and test specification (VRS) D6.1 Model checking specification D6.2 Simulation/test environment specification D6.3 Simulation/test/validation cases and dataStandardis…

diff/lex sp-defs-231012/diff 1566
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--PILLAR--STEERING--GROUP lexConcept
predicate: definition
changes:
  changes: ++ "System Pillar Steering Group monitoring the progress of the System Pillar"
  changes: -- "System Pillar Steering Group monitoring the progress of the System Pillar"

diff/lex sp-defs-231012/diff 1567
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--PILLAR--UNIT--CHAIRS--THE--SYSTEM--PILLAR--CORE--GROUP lexConcept
predicate: definition
changes:
  changes: ++ "System Pillar Unit Chairs the System Pillar Core Group"
  changes: -- "System Pillar Unit Chairs the System Pillar Core Group"

diff/lex sp-defs-231012/diff 1568
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM--REQUIREMENTS lexConcept
predicate: definition
changes:
  changes: ++ "define the constraints that affect the whole or a significant proportion of the system and include: * Physical Attributes: * System Style * System Size * System Weight * The 'RAMI' properties: * System Reliability * System Availability * System Maintainability * System Interoperability"
  changes: -- "define the constraints that affect the whole or a significant proportion of the system and include: * Physical Attributes: * System Style * System Size * System Weight * The 'RAMI' properties: * System Reliability * System Availability * System Maintainability * System Interoperability"

diff/lex sp-defs-231012/diff 1569
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: SYSTEM lexConcept
predicate: definition
changes:
  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. Example: The system “onboard CCS” does not define the properties of this system itself, the properties emerge from the combined properties of the subsystems “ETCS core”, “Onboard localization” and “Onboard map” (examples only). 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. Example: The system “onboard CCS” does not define the properties of this system itself, the properties emerge from the combined properties of the subsystems “ETCS core”, “Onboard localization” and “Onboard map” (examples only). 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-231012/diff 1571
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TAILORING--OF--REQUIREMENT--BREAKDOWN lexConcept
predicate: definition
changes:
  changes: ++ "SoS engineering can go wrong (quite often) if done in an overengineered and abstract way. If every artefact is created on every System Level (e.g. 5-7 levels and types or requirements that are broken down), the workload is artificially multiplied without need, and this policy is not creating a really good work split. To avoid this, every work process uses a tailoring approach which means * “Copy” (reference) things from a higher level, if possible like they are * Break up and translate through the levels that you really need, and not more. * Be sure that the right requirements are broken down to System Level 5 specification and to support concept definition in projects and manage the system, its performance and standards management. * Operational rulebooks include all that is needed. * Support design phases in managing requirement allocation, interfaces managements, testing planning. Engineering rules are complete and fulfilling the requirements * Support integration phase supporting data analysis, simulation process, anomaly resolution Programs can fail (cost, duration, time to market) because of too long and intense workout on System Level 1-4 (overengineered analytical architecting) without getting to real implementation specification and questions. If for example a high level requirement coming from the stakeholders can be addressed directly to System Level 5 without risk, this should be done. This is a (workflow) “tailoring” decision to be taken in the functional teams. Wrong approach: Breakdown every work item on every level. Right approaches: * Specific workflow tailoring, and * Generic workflow tailoring “Specific (workflow) tailoring” (intelligent work assignment per work item) = Single work items are only assigned on levels, where work is really needed (image: 1-image1.png) Second example for specific workflow tailoring: Two different process break downs * Op. process “Emergency stop of a train”, splits up “untailored” into work assignments… * System l…
  changes: -- "SoS engineering can go wrong (quite often) if done in an overengineered and abstract way. If every artefact is created on every System Level (e.g. 5-7 levels and types or requirements that are broken down), the workload is artificially multiplied without need, and this policy is not creating a really good work split. To avoid this, every work process uses a tailoring approach which means * “Copy” (reference) things from a higher level, if possible like they are * Break up and translate through the levels that you really need, and not more. * Be sure that the right requirements are broken down to System Level 5 specification and to support concept definition in projects and manage the system, its performance and standards management. * Operational rulebooks include all that is needed. * Support design phases in managing requirement allocation, interfaces managements, testing planning. Engineering rules are complete and fulfilling the requirements * Support integration phase supporting data analysis, simulation process, anomaly resolution Programs can fail (cost, duration, time to market) because of too long and intense workout on System Level 1-4 (overengineered analytical architecting) without getting to real implementation specification and questions. If for example a high level requirement coming from the stakeholders can be addressed directly to System Level 5 without risk, this should be done. This is a (workflow) “tailoring” decision to be taken in the functional teams. Wrong approach: Breakdown every work item on every level. Right approaches: * Specific workflow tailoring, and * Generic workflow tailoring “Specific (workflow) tailoring” (intelligent work assignment per work item) = Single work items are only assigned on levels, where work is really needed (image: 1-image1.png) Second example for specific workflow tailoring: Two different process break downs * Op. process “Emergency stop of a train”, splits up “untailored” into work assignments… * System l…

diff/lex sp-defs-231012/diff 1572
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TARGET--PICTURE lexConcept
predicate: definition
changes:
  changes: ++ "The following are considered minimum characteristics (baseline) for the targeted solution: * Operational processes directly related to the railway traffic commercial production are harmonised. This includes ETCS related processes, processes for securing and releasing railway lines/areas to/from maintenance and commissioning, operating through and recovering from degraded (non-regular) operations, reacting to and managing emergency situations (from operational perspective). * Railway system operates ETCS L2, without signals. * Railway system operates EULYNX type equipment."
  changes: -- "The following are considered minimum characteristics (baseline) for the targeted solution: * Operational processes directly related to the railway traffic commercial production are harmonised. This includes ETCS related processes, processes for securing and releasing railway lines/areas to/from maintenance and commissioning, operating through and recovering from degraded (non-regular) operations, reacting to and managing emergency situations (from operational perspective). * Railway system operates ETCS L2, without signals. * Railway system operates EULYNX type equipment."

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -15

…: 60050
…: -192
…: diff/lex sp-defs-231012/2015
…: 192
…: -07
…: -15

diff/lex sp-defs-231012/diff 1574
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TECHNICAL--DELAY lexConcept
predicate: definition
changes:
  changes: ++ "delay incurred in performing auxiliary technical actions associated with, but not part of, the maintenance action EXAMPLE Rendering the equipment safe (such as immobilising, cooling, isolation and grounding). [SOURCE: IEC 60050-192:2015,192-07-15]"
  changes: -- "delay incurred in performing auxiliary technical actions associated with, but not part of, the maintenance action EXAMPLE Rendering the equipment safe (such as immobilising, cooling, isolation and grounding). [SOURCE: IEC 60050-192:2015,192-07-15]"

diff/lex sp-defs-231012/diff 1575
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TEMPORARY--SHUNTING--AREA--TSHA--OR-DEF-160--TEMPORARY--SHUNTING--AREA--OR-DEF-161--DEF lexConcept
predicate: definition
changes:
  changes: ++ "Temporary Shunting Area (TShA) OR.DEF.160 Temporary shunting area OR.DEF.161 DEFINITION A temporary shunting area is an interlocked area{comment:15} temporarily set up to allow shunting operations. A temporary shunting area is always under the responsibility of a Shunting area manager."
  changes: -- "Temporary Shunting Area (TShA) OR.DEF.160 Temporary shunting area OR.DEF.161 DEFINITION A temporary shunting area is an interlocked area{comment:15} temporarily set up to allow shunting operations. A temporary shunting area is always under the responsibility of a Shunting area manager."

diff/lex sp-defs-231012/diff 1580
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TLS lexConcept
predicate: definition
changes:
  changes: ++ "Transport Layer Security (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"
  changes: -- "Transport Layer Security (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"

diff/lex sp-defs-231012/diff 1582
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: TRACK--FOOTPRINT lexConcept
predicate: definition
changes:
  changes: ++ "The track Footprint of an object is defined for a specific track. It is the perpendicular projection of this object's ground footprint on the track center line. Notes: The definition corresponds to UNISIG's occupancy, without consideration fix-block / moving block. This definition is weak for intersections of two vehicles near points, where the width of vehicles has to be considered (e.g. with a fouling point indicator near the track) and for level crossings, because the road users are not associated with the rail track."
  changes: -- "The track Footprint of an object is defined for a specific track. It is the perpendicular projection of this object's ground footprint on the track center line. Notes: The definition corresponds to UNISIG's occupancy, without consideration fix-block / moving block. This definition is weak for intersections of two vehicles near points, where the width of vehicles has to be considered (e.g. with a fouling point indicator near the track) and for level crossings, because the road users are not associated with the rail track."

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

diff/lex sp-defs-231012/diff 1591
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: WORKFLOW--AND--WORKFLOW--RULES lexConcept
predicate: definition
changes:
  changes: ++ "* A workflow describes the rules (processes) how a “trace” shall be created step by step. * A workflow includes a set of rules that define, how * work items must be broken down and linked (link rules) * work item types must be resolved * certain work item types are assigned to certain teams in the organisation * Every work item, that is not compliant to a workflow is marked as invalid * There are optional workflow steps in a workflow. E.g. a requirement can be directly resolved by multiple functions (that are always explained with a rational attribute) without having a “solution concept” work item, which is optional."
  changes: -- "* A workflow describes the rules (processes) how a “trace” shall be created step by step. * A workflow includes a set of rules that define, how * work items must be broken down and linked (link rules) * work item types must be resolved * certain work item types are assigned to certain teams in the organisation * Every work item, that is not compliant to a workflow is marked as invalid * There are optional workflow steps in a workflow. E.g. a requirement can be directly resolved by multiple functions (that are always explained with a rational attribute) without having a “solution concept” work item, which is optional."

diff/lex sp-defs-231012/diff 1592
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: WORKFLOW--PRIORITISATION--STRATEGY--TO--BE--DECIDED--PER--AREA lexConcept
predicate: definition
changes:
  changes: ++ "In general, there are two directions for prioritisation, which are “horizontal” or “vertical” * Horizontal prioritisation means for example “which of all operational capabilities do we break down first down to their operational processes (just the next derivation step per capability)” * Vertical prioritisation means for example “which operational capability do we resolve down to the physical architecture before we start to resolve the next * capability” (image: 1-Grafik_1.png) * Both prioritisation methods are mixed to reach two targets in parallel: a) Use the capacity of all teams in parallel with different roles (vertical prioritisation), b) get a more and more full picture top-down (horizontal prioritisation). * A “mix” can for example be: “At first only all operational capabilities for standard train movements (no shunting etc.) and only the processes related to ETCS Level R without ATO are traced down to the physical architecture in the first step”. For the prioritisation these aspects are important: * As much as possible early usable results shall be created (year by year). * Example 1 (“bottom-up”): All traces, that lead to the EULYNX interfaces shall be resolved and approved fast. EULYNX interfaces should be standardized soon. * This means to import and resolve all traces, and to connect all interfaces to the overall architecture “upwards” (connecting workflow) * Example 2 (“top-down”): All traces for DAC shall be resolved fast, but there are not so much complete (resolved) traces to import in terms of processes and architecture. All operational capabilities and operational requirements for DAC need to be created and broken down and resolved down to the implementation (=vertical prioritisation). * Important decisions shall be decided early as a basis for all work * Example 3: (“horizontal prioritisation”): The process standardisation scope and depth shall be decided as early as possible. This means to create all operational capabilities, derive them town…
  changes: -- "In general, there are two directions for prioritisation, which are “horizontal” or “vertical” * Horizontal prioritisation means for example “which of all operational capabilities do we break down first down to their operational processes (just the next derivation step per capability)” * Vertical prioritisation means for example “which operational capability do we resolve down to the physical architecture before we start to resolve the next * capability” (image: 1-Grafik_1.png) * Both prioritisation methods are mixed to reach two targets in parallel: a) Use the capacity of all teams in parallel with different roles (vertical prioritisation), b) get a more and more full picture top-down (horizontal prioritisation). * A “mix” can for example be: “At first only all operational capabilities for standard train movements (no shunting etc.) and only the processes related to ETCS Level R without ATO are traced down to the physical architecture in the first step”. For the prioritisation these aspects are important: * As much as possible early usable results shall be created (year by year). * Example 1 (“bottom-up”): All traces, that lead to the EULYNX interfaces shall be resolved and approved fast. EULYNX interfaces should be standardized soon. * This means to import and resolve all traces, and to connect all interfaces to the overall architecture “upwards” (connecting workflow) * Example 2 (“top-down”): All traces for DAC shall be resolved fast, but there are not so much complete (resolved) traces to import in terms of processes and architecture. All operational capabilities and operational requirements for DAC need to be created and broken down and resolved down to the implementation (=vertical prioritisation). * Important decisions shall be decided early as a basis for all work * Example 3: (“horizontal prioritisation”): The process standardisation scope and depth shall be decided as early as possible. This means to create all operational capabilities, derive them town…

diff/lex sp-defs-231012/diff 1593
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: WORKFLOW--STEP--ON--STEP--IN--A--WORKITEM--TRACE lexConcept
predicate: definition
changes:
  changes: ++ "A workflow step includes some of the following actions * “Create a trace”: The work item on the “top/start” of a trace is created based on external decisions. These are typically * Steering group decisions about system capabilities, common business objectives, improvement targets or problem descriptions, operational requirements, new safety requirements, etc. (see chapter below). * Technical regulations * “Derive” a work item: A team that is responsible for a derivation step in a trace for work items of a specific type looks for all unresolved work items and derives the resolving work items that are part of the own team scope. E.g., an ARC team sees unresolved actions in an operational process an derives all needed system requirements and functions that need to be worked out. * “Propose” a work item: A team or person receives (assignment) a work item with the status “proposed” from another team, that wants to resolve a dependency. E.g., an OD team designed an action in an operational process and “proposes” (“push”) a system requirement to an ARC team. * “Design / engineer / work out” a work item: The content of the work item is worked out. (e.g. an operational process with all actions) * “Break down” (“dependencies defined/delegated”) a work item: All necessary next work items are derived (as proposals) and linked. * “Resolve” a work item: All necessary next/downwards work items are derived, linked, designed, approved and resolved. E.g., all system functions to fulfil (resolve) an operational requirement are completed. * “Assign” a work item: The work item is assigned to a team or person that shall design it. * “Uplink” a work item. A “free floating” (not linked top-down, completely unlinked, or currently invalid) work item (e.g. coming from a bottom-up process or external contributor) is linked “upwards” to a “traced/valid” work item as if it had been derived from it before (e.g. a process is linked ex post to a capability). This is only done if this new link i…
  changes: -- "A workflow step includes some of the following actions * “Create a trace”: The work item on the “top/start” of a trace is created based on external decisions. These are typically * Steering group decisions about system capabilities, common business objectives, improvement targets or problem descriptions, operational requirements, new safety requirements, etc. (see chapter below). * Technical regulations * “Derive” a work item: A team that is responsible for a derivation step in a trace for work items of a specific type looks for all unresolved work items and derives the resolving work items that are part of the own team scope. E.g., an ARC team sees unresolved actions in an operational process an derives all needed system requirements and functions that need to be worked out. * “Propose” a work item: A team or person receives (assignment) a work item with the status “proposed” from another team, that wants to resolve a dependency. E.g., an OD team designed an action in an operational process and “proposes” (“push”) a system requirement to an ARC team. * “Design / engineer / work out” a work item: The content of the work item is worked out. (e.g. an operational process with all actions) * “Break down” (“dependencies defined/delegated”) a work item: All necessary next work items are derived (as proposals) and linked. * “Resolve” a work item: All necessary next/downwards work items are derived, linked, designed, approved and resolved. E.g., all system functions to fulfil (resolve) an operational requirement are completed. * “Assign” a work item: The work item is assigned to a team or person that shall design it. * “Uplink” a work item. A “free floating” (not linked top-down, completely unlinked, or currently invalid) work item (e.g. coming from a bottom-up process or external contributor) is linked “upwards” to a “traced/valid” work item as if it had been derived from it before (e.g. a process is linked ex post to a capability). This is only done if this new link i…

diff/lex sp-defs-231012/diff 1594
type: diff/lex sp-defs-231012/Object attribute changedValues
entity: diff/lex sp-defs-231012/entity
entity: WORKSTEP-- WORKITEM--CHECK lexConcept
predicate: definition
changes:
  changes: ++ "* Is the workitem content correct and without inner contradictions? * Does the workitem content fit to the wokitem type? * Are all standard or custom workitem fields filled? * Does the workitem content implement the demands coming to it by existing links? * Do all mandatory links exist and are they completely fulfilling their role? Does the content fit to them? E.g. a system requirements can be implemented by a function... but it needs to be completely implemented and not partly."
  changes: -- "* Is the workitem content correct and without inner contradictions? * Does the workitem content fit to the wokitem type? * Are all standard or custom workitem fields filled? * Does the workitem content implement the demands coming to it by existing links? * Do all mandatory links exist and are they completely fulfilling their role? Does the content fit to them? E.g. a system requirements can be implemented by a function... but it needs to be completely implemented and not partly."