diff/lex sp-defs-240903
target: lex sp-defs-241203#
versus: lex sp-defs-240903#
issued: 2024-12-03T12:33:15.901068
version date: 2024-01-11 16:37:49

diff/lex sp-defs-240903/diff 0004
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONTROL-COMMAND--AND--SIGNALLING abbrev
predicate: canonicalForm
changes:
  changes: ++ :CONTROL-COMMAND--AND--SIGNALLING_lexForm_3

diff/lex sp-defs-240903/diff 0012
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK abbrev
predicate: canonicalForm
changes:
  changes: ++ :MOVING--BLOCK_lexForm_3

diff/lex sp-defs-240903/diff 0013
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK abbrev
predicate: label
changes:
  changes: ++ "FMB"

diff/lex sp-defs-240903/diff 0019
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--CONCEPTS abbrev
predicate: abbreviationFor
changes:
  changes: **++ :"Operational concepts"
  changes: **-- :"Operational Concepts"

diff/lex sp-defs-240903/diff 0020
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: POLARION--WORK--ITEM--OF--TYPE--REFERENCE abbrev
predicate: canonicalForm
changes:
  changes: ++ :POLARION--WORK--ITEM--OF--TYPE--REFERENCE_lexForm_3

diff/lex sp-defs-240903/diff 0038
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: APPLICATION--CONDITION label
predicate: label
changes:
  changes: **++ "Application Condition"
  changes: **-- "Application Condition."

diff/lex sp-defs-240903/diff 0046
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: COMMON--BUSINESS--OBJECTIVE acronym
predicate: acronymFor
changes:
  changes: **++ :"Common Business Objective"
  changes: **-- :"Common Business Objective."

diff/lex sp-defs-240903/diff 0047
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: COMMON--BUSINESS--OBJECTIVE acronym
predicate: canonicalForm
changes:
  changes: ++ :COMMON--BUSINESS--OBJECTIVE_lexForm_3

diff/lex sp-defs-240903/diff 0048
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONTROL-COMMAND--AND--SIGNALLING abbrev
predicate: canonicalForm
changes:
  changes: ++ :CONTROL-COMMAND--AND--SIGNALLING_lexForm_3

diff/lex sp-defs-240903/diff 0055
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: COMMON--BUSINESS--OBJECTIVE label
predicate: label
changes:
  changes: **++ "Common Business Objective"
  changes: **-- "Common Business Objective."

diff/lex sp-defs-240903/diff 0058
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONCEPT--ASPECT label
predicate: label
changes:
  changes: **++ "Concept Aspect"
  changes: **-- "Concept Aspect."

diff/lex sp-defs-240903/diff 0061
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DIGITAL--AUTOMATED--COUPLING acronym
predicate: canonicalForm
changes:
  changes: ++ :DIGITAL--AUTOMATED--COUPLING_lexForm_3

diff/lex sp-defs-240903/diff 0076
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK abbrev
predicate: canonicalForm
changes:
  changes: ++ :MOVING--BLOCK_lexForm_3

diff/lex sp-defs-240903/diff 0077
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK abbrev
predicate: label
changes:
  changes: ++ "FMB"

diff/lex sp-defs-240903/diff 0078
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ENGINEERING--DATA label
predicate: label
changes:
  changes: **++ "Engineering data"
  changes: **-- "Engineering Data"

diff/lex sp-defs-240903/diff 0084
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FEATURE label
predicate: label
changes:
  changes: **++ "Feature"
  changes: **-- "Feature."

diff/lex sp-defs-240903/diff 0105
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LOGICAL--ACTOR label
predicate: label
changes:
  changes: **++ "Logical Actor"
  changes: **-- "Logical actor"

diff/lex sp-defs-240903/diff 0114
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--CONCEPTS label
predicate: label
changes:
  changes: **++ "Operational concepts"
  changes: **-- "Operational Concepts"

diff/lex sp-defs-240903/diff 0115
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--CONCEPTS abbrev
predicate: abbreviationFor
changes:
  changes: **++ :"Operational concepts"
  changes: **-- :"Operational Concepts"

diff/lex sp-defs-240903/diff 0116
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: POLARION--WORK--ITEM--OF--TYPE--REFERENCE abbrev
predicate: canonicalForm
changes:
  changes: ++ :POLARION--WORK--ITEM--OF--TYPE--REFERENCE_lexForm_3

diff/lex sp-defs-240903/diff 0123
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: RAILWAY--REQUIREMENT label
predicate: label
changes:
  changes: **++ "Railway Requirement"
  changes: **-- "Railway Requirement."

diff/lex sp-defs-240903/diff 0142
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: SYSTEM--UNDER--CONSIDERATION acronym
predicate: acronymFor
changes:
  changes: **++ :"System under consideration"
  changes: **-- :"System under Consideration"

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

diff/lex sp-defs-240903/diff 0149
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: SYSTEM--REQUIREMENT label
predicate: label
changes:
  changes: **++ "System Requirement"
  changes: **-- "System Requirement."

diff/lex sp-defs-240903/diff 0150
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: SYSTEM--UNDER--CONSIDERATION label
predicate: label
changes:
  changes: **++ "System under consideration"
  changes: **-- "System under Consideration"

diff/lex sp-defs-240903/diff 0227
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: APPLICATION--CONDITION lexForm
predicate: writtenRep
changes:
  changes: **++ "Application Condition"
  changes: **-- "Application Condition."

diff/lex sp-defs-240903/diff 0241
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: COMMON--BUSINESS--OBJECTIVE lexForm
predicate: writtenRep
changes:
  changes: **++ "Common Business Objective"
  changes: **-- "Common Business Objective."

diff/lex sp-defs-240903/diff 0246
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONCEPT--ASPECT lexForm
predicate: writtenRep
changes:
  changes: **++ "Concept Aspect"
  changes: **-- "Concept Aspect."

diff/lex sp-defs-240903/diff 0266
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ENGINEERING--DATA lexForm
predicate: writtenRep
changes:
  changes: **++ "Engineering data"
  changes: **-- "Engineering Data"

diff/lex sp-defs-240903/diff 0273
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FEATURE lexForm
predicate: writtenRep
changes:
  changes: **++ "Feature"
  changes: **-- "Feature."

diff/lex sp-defs-240903/diff 0296
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LOGICAL--ACTOR lexForm
predicate: writtenRep
changes:
  changes: **++ "Logical Actor"
  changes: **-- "Logical actor"

diff/lex sp-defs-240903/diff 0297
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK lexForm 2
predicate: writtenRep
changes:
  changes: ++ "FMB"
  changes: -- "ETCS L2MB"

diff/lex sp-defs-240903/diff 0307
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--CONCEPTS lexForm
predicate: writtenRep
changes:
  changes: **++ "Operational concepts"
  changes: **-- "Operational Concepts"

diff/lex sp-defs-240903/diff 0312
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: RAILWAY--REQUIREMENT lexForm
predicate: writtenRep
changes:
  changes: **++ "Railway Requirement"
  changes: **-- "Railway Requirement."

diff/lex sp-defs-240903/diff 0340
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: SYSTEM--REQUIREMENT lexForm
predicate: writtenRep
changes:
  changes: **++ "System Requirement"
  changes: **-- "System Requirement."

diff/lex sp-defs-240903/diff 0341
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: SYSTEM--UNDER--CONSIDERATION lexForm
predicate: writtenRep
changes:
  changes: **++ "System under consideration"
  changes: **-- "System under Consideration"

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

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

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

diff/lex sp-defs-240903/diff 0434
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONTROL-COMMAND--AND--SIGNALLING lexSense
predicate: identifier
changes:
  changes: ++ "SPPRAMSS-11099"

diff/lex sp-defs-240903/diff 0435
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONTROL-COMMAND--AND--SIGNALLING lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :CONTROL-COMMAND--AND--SIGNALLING_lexConcept_2

diff/lex sp-defs-240903/diff 0436
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DAS-OB-----DRIVER--ADVISORY--SYSTEM--ON--BOARD lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-4668"
  changes: -- "SPT2TRAIN-3778"

diff/lex sp-defs-240903/diff 0439
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DIGITAL--AUTOMATED--COUPLING lexSense
predicate: identifier
changes:
  changes: ++ "SPPRAMSS-11111"

diff/lex sp-defs-240903/diff 0440
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DIGITAL--AUTOMATED--COUPLING lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :DIGITAL--AUTOMATED--COUPLING_lexConcept_2

diff/lex sp-defs-240903/diff 0443
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DOCUMENT--EXCHANGE lexSense
predicate: identifier
changes:
  changes: -- "SPPR-5617"

diff/lex sp-defs-240903/diff 0444
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DOCUMENT--EXCHANGE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :DOCUMENT--EXCHANGE_lexConcept_2

diff/lex sp-defs-240903/diff 0445
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DOCUMENT--GENERATION--AND--MANAGEMENT lexSense
predicate: identifier
changes:
  changes: -- "SPPR-5615"

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

diff/lex sp-defs-240903/diff 0447
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DOCUMENTS--PUBLICATION lexSense
predicate: identifier
changes:
  changes: -- "SPPR-5616"

diff/lex sp-defs-240903/diff 0448
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DOCUMENTS--PUBLICATION lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :DOCUMENTS--PUBLICATION_lexConcept_2

diff/lex sp-defs-240903/diff 0453
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ENGINEERING--DATA lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TS-127778"
  changes: -- "SPT2TS-125754"

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

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

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

diff/lex sp-defs-240903/diff 0465
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: GASC lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :GASC_lexConcept_2

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

diff/lex sp-defs-240903/diff 0469
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: GPSC lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :GPSC_lexConcept_2

diff/lex sp-defs-240903/diff 0477
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MANAGEMENT--BY--TRACEABILITY--KANBAN--BASED lexSense
predicate: identifier
changes:
  changes: ++ "SPP-8740"
  changes: ++ "SPT2MIG-5245"

diff/lex sp-defs-240903/diff 0478
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MANAGEMENT--BY--TRACEABILITY--KANBAN--BASED lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :MANAGEMENT--BY--TRACEABILITY--KANBAN--BASED_lexConcept_2
  changes: ++ :MANAGEMENT--BY--TRACEABILITY--KANBAN--BASED_lexConcept_3

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

diff/lex sp-defs-240903/diff 0480
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :MDS-----MULTI--DISPLAY--SYSTEM--ALTERNATIVE--NAMING--FOR--TRAIN--DISPLAY--SYSTEM--NOT--YET_lexConcept_7

diff/lex sp-defs-240903/diff 0481
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAFFIC-8816"

diff/lex sp-defs-240903/diff 0482
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :MOVING--BLOCK_lexConcept_3

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

diff/lex sp-defs-240903/diff 0489
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :OMTS-----ON--BOARD--MULTIMEDIA--AND--TELEMATICS--SYSTEM--X2R4--EQUIVALENT--WITH--PASSENGER_lexConcept_7

diff/lex sp-defs-240903/diff 0490
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATING--STATE lexSense
predicate: identifier
changes:
  changes: ++ "SPT3TMS-15942"

diff/lex sp-defs-240903/diff 0491
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATING--STATE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :OPERATING--STATE_lexConcept_2

diff/lex sp-defs-240903/diff 0492
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--CONCEPTS lexSense
predicate: identifier
changes:
  changes: -- "SPPR-2069"

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

diff/lex sp-defs-240903/diff 0494
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--CONCEPTS lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :OPERATIONAL--CONCEPTS_lexConcept_2

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

diff/lex sp-defs-240903/diff 0497
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: PIS-----PASSENGER--INFORMATION--SYSTEM lexSense
predicate: identifier
changes:
  changes: ++ "SPT2TRAIN-4671"

diff/lex sp-defs-240903/diff 0498
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: PIS-----PASSENGER--INFORMATION--SYSTEM lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_7

diff/lex sp-defs-240903/diff 0499
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: POLARION--WORK--ITEM--OF--TYPE--REFERENCE lexSense
predicate: identifier
changes:
  changes: ++ "SPLI-1848"

diff/lex sp-defs-240903/diff 0500
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: POLARION--WORK--ITEM--OF--TYPE--REFERENCE lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :POLARION--WORK--ITEM--OF--TYPE--REFERENCE_lexConcept_2

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

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

diff/lex sp-defs-240903/diff 0516
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: SWITCH lexSense
predicate: identifier
changes:
  changes: -- "SPPR-5600"
  changes: -- "SPPR-5601"

diff/lex sp-defs-240903/diff 0517
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: SWITCH lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: -- :SWITCH_lexConcept_4
  changes: -- :SWITCH_lexConcept_5

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

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

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

diff/lex sp-defs-240903/diff 0526
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: THE--SET--OF--ALL--TRACES--TOGETHER--IS--CALLED--A-- MODEL lexSense
predicate: identifier
changes:
  changes: ++ "SPP-8741"

diff/lex sp-defs-240903/diff 0527
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: THE--SET--OF--ALL--TRACES--TOGETHER--IS--CALLED--A-- MODEL lexSense
predicate: isLexicalizedSenseOf
changes:
  changes: ++ :THE--SET--OF--ALL--TRACES--TOGETHER--IS--CALLED--A--_MODEL_lexConcept_2

diff/lex sp-defs-240903/diff 0585
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: 1D--REFERENCE--FRAME lexConcept
predicate: definition
changes:
  changes: ++ "1 D reference frame is a one-dimensional reference frame where the bogie position, speed and acceleration along the track centreline axis are expressed. It is defined by the bogie frame. On the plan defined by the carriage floor, the x axis is the tangent of the track centreline oriented toward the train front end, the bogie pin close to the train front end is the tangency point. The bogie pin is located on the longitudinal axis of the carriage."
  changes: -- "1 D reference frame is a one-dimensional reference frame where the bogie position, speed and acceleration along the track centreline axis are expressed. It is defined by the bogie frame. On the plan defined by the carriage floor, the x axis is the tangent of the track centreline oriented toward the train front end, the bogie pin close to the train front end is the tangency point. The bogie pin is located on the longitudinal axis of the carriage."

diff/lex sp-defs-240903/diff 0586
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: 3D--REFERENCE--FRAME lexConcept
predicate: definition
changes:
  changes: ++ "It is a three-dimensional reference frame where the train speed and acceleration are expressed on the 3 axis component values. It is defined by the carriage frame by a right trihedron. On the plan defined by the carriage floor, the x axis is the carriage longitudinal axis oriented toward the train front end, y axis is the orthogonal to the carriage longitudinal axis oriented to the left, z axis the orthogonal to the carriage floor oriented up, the origin point is the bogie pin close to the train front end."
  changes: -- "It is a three-dimensional reference frame where the train speed and acceleration are expressed on the 3 axis component values. It is defined by the carriage frame by a right trihedron. On the plan defined by the carriage floor, the x axis is the carriage longitudinal axis oriented toward the train front end, y axis is the orthogonal to the carriage longitudinal axis oriented to the left, z axis the orthogonal to the carriage floor oriented up, the origin point is the bogie pin close to the train front end."

diff/lex sp-defs-240903/diff 0587
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: 4-2-17-1---ETCS--SYSTEM--COMPATIBILITY lexConcept
predicate: definition
changes:
  changes: ++ "ETCS System Compatibility (ESC) is the recording of technical compatibility between ETCS on-board and the trackside parts ETCS of the CCS subsystems within an area of use. Each ESC Type identifies the set of ESC checks (e.g. document check, lab or track test, …) applicable for a section or group of sections within an area of use. It is possible to use the same ESC type for cross border infrastructure and for different national infrastructures. The results of the ESC checks for an on-board unit on the Interoperability Constituent level or subsystem level, including findings and conditions arising, are recorded in the ESC Check Report. ‘Representative configuration’ means a configuration on the basis of which test results can be achieved, which are valid for various configurations of the same certified ETCS on-board interoperability constituent or of a certified on-board subsystem. These results shall also be equivalent for various configurations of a certified ETCS trackside subsystem. For ESC checks at ETCS on-board Interoperability Constituent level the following is to be observed: (1) The ESC Interoperability Constituent Statement records the ESC results of the ETCS On-board Interoperability Constituent to the ESC Type(s) that is valid regardless of the specific configuration of the ETCS on-board Interoperability Constituent. This document shall be produced by the on-board supplier. The template provided in Appendix C.2 or C.6 shall be used. (2) The ESC Interoperability Constituent Statement shall include the summary of the findings and conditions of the ESC Check Report(s) on the results of the ESC checks passed (defined in one or more ESC Type), which are valid independently from the specific configuration parameters of the on-board Interoperability Constituent and can therefore be used in every applicable specific on-board CCS subsystem level. (3) The ESC Interoperability Constituent Statement shall include the list of ESC checks performed for the ESC Type(…
  changes: -- "ETCS System Compatibility (ESC) is the recording of technical compatibility between ETCS on-board and the trackside parts ETCS of the CCS subsystems within an area of use. Each ESC Type identifies the set of ESC checks (e.g. document check, lab or track test, …) applicable for a section or group of sections within an area of use. It is possible to use the same ESC type for cross border infrastructure and for different national infrastructures. The results of the ESC checks for an on-board unit on the Interoperability Constituent level or subsystem level, including findings and conditions arising, are recorded in the ESC Check Report. ‘Representative configuration’ means a configuration on the basis of which test results can be achieved, which are valid for various configurations of the same certified ETCS on-board interoperability constituent or of a certified on-board subsystem. These results shall also be equivalent for various configurations of a certified ETCS trackside subsystem. For ESC checks at ETCS on-board Interoperability Constituent level the following is to be observed: (1) The ESC Interoperability Constituent Statement records the ESC results of the ETCS On-board Interoperability Constituent to the ESC Type(s) that is valid regardless of the specific configuration of the ETCS on-board Interoperability Constituent. This document shall be produced by the on-board supplier. The template provided in Appendix C.2 or C.6 shall be used. (2) The ESC Interoperability Constituent Statement shall include the summary of the findings and conditions of the ESC Check Report(s) on the results of the ESC checks passed (defined in one or more ESC Type), which are valid independently from the specific configuration parameters of the on-board Interoperability Constituent and can therefore be used in every applicable specific on-board CCS subsystem level. (3) The ESC Interoperability Constituent Statement shall include the list of ESC checks performed for the ESC Type(…

diff/lex sp-defs-240903/diff 0588
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ABSOLUTE--POSITION--REFERENCE--FRAME lexConcept
predicate: definition
changes:
  changes: ++ "Train front end position expressed with absolute geo coordinate system using a 3 D reference frame (e.g., Long, Lat, Alt, WGS84, ETRS89…)."
  changes: -- "Train front end position expressed with absolute geo coordinate system using a 3 D reference frame (e.g., Long, Lat, Alt, WGS84, ETRS89…)."

diff/lex sp-defs-240903/diff 0589
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ADVANCED--SAFE--TRAIN--POSITIONING--ASTP lexConcept
predicate: definition
changes:
  changes: ++ "Advanced Safe Train Positioning (ASTP) is a CCS onboard interoperability constituent, separated from the ERTMS/ETCS on-board equipment by fully standardized interfaces with all connected systems. ASTP shall perform functions for safety relevant applications and be the only source of odometry information in the CCS-OB. The main ASTP functionalities interfacing with other onboard systems, are: * provision of Odometry information * identification of all potential virtual Reference Location(s) * provision of 3D kinematic information"
  changes: -- "Advanced Safe Train Positioning (ASTP) is a CCS onboard interoperability constituent, separated from the ERTMS/ETCS on-board equipment by fully standardized interfaces with all connected systems. ASTP shall perform functions for safety relevant applications and be the only source of odometry information in the CCS-OB. The main ASTP functionalities interfacing with other onboard systems, are: * provision of Odometry information * identification of all potential virtual Reference Location(s) * provision of 3D kinematic information"

diff/lex sp-defs-240903/diff 0591
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ALLOCATION--AREA lexConcept
predicate: definition
changes:
  changes: ++ "The area in the trackside which shall be free of operational conflict(s) for the execution of an operational need (movement or other). In other words, it is the area in the trackside that shall be reserved to an operational movement. The safety system shall not allow an SPT2OD-6043 - Missing cross-reference to be allocated to conflicting movement(s) or conflicting operational need(s). (image: diagram_20231213-1048.28106.mxg.svg) {comment:64} Note as a representation, SPT2OD-6043 - Missing cross-reference is equivalent to the combined Danger Zone(s) of the underlying assets over the area in which it is intended to next perform a train movement, possibly including flank protection and overlap areas (to be discussed at a later stage)."
  changes: -- "The area in the trackside which shall be free of operational conflict(s) for the execution of an operational need (movement or other). In other words, it is the area in the trackside that shall be reserved to an operational movement. The safety system shall not allow an SPT2OD-6043 - Missing cross-reference to be allocated to conflicting movement(s) or conflicting operational need(s). (image: diagram_20231213-1048.28106.mxg.svg) {comment:64} Note as a representation, SPT2OD-6043 - Missing cross-reference is equivalent to the combined Danger Zone(s) of the underlying assets over the area in which it is intended to next perform a train movement, possibly including flank protection and overlap areas (to be discussed at a later stage)."

diff/lex sp-defs-240903/diff 0592
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: APPLICATION--CONDITION lexConcept
predicate: definition
changes:
  changes: ++

diff/lex sp-defs-240903/diff 0594
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: APPLICATION--EXECUTION--ENVIRONMENT lexConcept
predicate: definition
changes:
  changes: ++ "The Application Execution Environment refers to the combination of Runtime Environment and Safety Framework. Previous definition: The Application Execution Environment refers to the combination of Runtime Environment and Safety Environment."
  changes: -- "The Application Execution Environment refers to the combination of Runtime Environment and Safety Framework. Previous definition: The Application Execution Environment refers to the combination of Runtime Environment and Safety Environment."

diff/lex sp-defs-240903/diff 0595
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: APPLICATION--LAYER lexConcept
predicate: definition
changes:
  changes: ++ "The Application Layer refers to the functions provided by the Functional Systems. These functions are implemented as Tasks within Functional Applications. Previous definition: The Application Layer contains Functional Applications that constitute Functional Systems."
  changes: -- "The Application Layer refers to the functions provided by the Functional Systems. These functions are implemented as Tasks within Functional Applications. Previous definition: The Application Layer contains Functional Applications that constitute Functional Systems."

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

diff/lex sp-defs-240903/diff 0599
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: AREA--CONTROLLER lexConcept
predicate: definition
changes:
  changes: ++ "Area Controller The Area Controller manages areas for the View."
  changes: -- "Area Controller The Area Controller manages areas for the View."

diff/lex sp-defs-240903/diff 0602
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ATO--AUTOMATIC--TRAIN--OPERATION--AOC--AREA--OF--CONTROL--CCS--CONTROL--COMMAND--AND--SIGNAL lexConcept
predicate: definition
changes:
  changes: ++ "ATO | Automatic Train Operation AoC | Area of Control | CCS | Control Command and Signaling CI/CD | Continuous Integration / Continuous Deployment CMS | Capacity Management system CPU | Central Processing Unit CTC | Centralized traffic control CVSS | Common Vulnerability Scoring System | DBMS | Database Management System DDOS | Distributed Denial of Service DEV | Development DLP | Data loss prevention DNS | Domain Name System DR | Disaster Recovery-Plan | EDA | Event-driven architecture ELK | Elasticsearch, Logstash, Kibana | FAM | Fixed asset mgmt | HMI | Human Machine Interface HTTP | Hypertext Transfer Protocol | IRM | Information Rights Management | OS | Operating system OR | Operational Requirements | NTMS | Neighborhood TMS | MD5 | Message Digest Method 5 MITM | Man-in-the-middle attack MS | Microservices MVCC | Multi-version concurrency control | PE | Plan Execution PIS | Passenger Information System POS | Path Order System PROD | Production | QA | Quality Assurance{comment:128} | RAID | Redundant Array of Independent Disks RAM | Random Access Memory RBAS | Role Based Access Control REST | Representational State Transfer RIM | Rail Infrastructure Manager ROC | Rail Operating Company RT | Real Time RU | Rail Undertakings | SAD | System Architecture Description SCI-OP | Standard Communications Interface – Operational Plan SEMP | System Engineering Management Plan SOAP | Simple Object Access Protocol SoC | Separation of Concerns SSL | Secure Sockets Layer | TAF | Telematics Applications for Freight TAP | Telematics Applications for Passenger Services TCR | Temporary Capacity Restrictions TLS | Transport Layer Security TMS | Traffic Management System TSI | Technical Specification for Interoperability | UML | Unified Modeling Language | WAF | Web Application Firewall WSDL | Web Services Description Language | XFN | Cross functional"
  changes: -- "ATO | Automatic Train Operation AoC | Area of Control | CCS | Control Command and Signaling CI/CD | Continuous Integration / Continuous Deployment CMS | Capacity Management system CPU | Central Processing Unit CTC | Centralized traffic control CVSS | Common Vulnerability Scoring System | DBMS | Database Management System DDOS | Distributed Denial of Service DEV | Development DLP | Data loss prevention DNS | Domain Name System DR | Disaster Recovery-Plan | EDA | Event-driven architecture ELK | Elasticsearch, Logstash, Kibana | FAM | Fixed asset mgmt | HMI | Human Machine Interface HTTP | Hypertext Transfer Protocol | IRM | Information Rights Management | OS | Operating system OR | Operational Requirements | NTMS | Neighborhood TMS | MD5 | Message Digest Method 5 MITM | Man-in-the-middle attack MS | Microservices MVCC | Multi-version concurrency control | PE | Plan Execution PIS | Passenger Information System POS | Path Order System PROD | Production | QA | Quality Assurance{comment:128} | RAID | Redundant Array of Independent Disks RAM | Random Access Memory RBAS | Role Based Access Control REST | Representational State Transfer RIM | Rail Infrastructure Manager ROC | Rail Operating Company RT | Real Time RU | Rail Undertakings | SAD | System Architecture Description SCI-OP | Standard Communications Interface – Operational Plan SEMP | System Engineering Management Plan SOAP | Simple Object Access Protocol SoC | Separation of Concerns SSL | Secure Sockets Layer | TAF | Telematics Applications for Freight TAP | Telematics Applications for Passenger Services TCR | Temporary Capacity Restrictions TLS | Transport Layer Security TMS | Traffic Management System TSI | Technical Specification for Interoperability | UML | Unified Modeling Language | WAF | Web Application Firewall WSDL | Web Services Description Language | XFN | Cross functional"

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

diff/lex sp-defs-240903/diff 0604
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: AUTOMATIC--TRAIN--OPERATION lexConcept 2
predicate: definition
changes:
  changes: ++ "Automatic Train Operation is technology for automating the operation of trains. The degree of the automatisation is shown by the Grade of Automatation (GoA). GoA0: train operating on-sight, no automation GoA1: train operating manual, train driver controls starting, stopping, passenger service functions as opening and closing doors and handling emergency. Train protection systems like ETCS L1 in place. GoA2: train operating semi-automatic. Starting and stopping automated using advanced train protection systems like ETCS L2 or 3, driver operates passenger service functions and handles emergencies GoA3: driverless train operation. Starting and stopping automated, service staff operates passenger service functions and handles emergencies GoA4: unattended train operation. All operations are fully automated without any on-train staff"
  changes: -- "Automatic Train Operation is technology for automating the operation of trains. The degree of the automatisation is shown by the Grade of Automatation (GoA). GoA0: train operating on-sight, no automation GoA1: train operating manual, train driver controls starting, stopping, passenger service functions as opening and closing doors and handling emergency. Train protection systems like ETCS L1 in place. GoA2: train operating semi-automatic. Starting and stopping automated using advanced train protection systems like ETCS L2 or 3, driver operates passenger service functions and handles emergencies GoA3: driverless train operation. Starting and stopping automated, service staff operates passenger service functions and handles emergencies GoA4: unattended train operation. All operations are fully automated without any on-train staff"

diff/lex sp-defs-240903/diff 0605
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0606
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: AVAILABILITY lexConcept
predicate: definition
changes:
  changes: ++ "Availability: property of being accessible and usable on demand by an authorized entity (source: ISO 27000-2018 )"
  changes: -- "Availability: property of being accessible and usable on demand by an authorized entity (source: ISO 27000-2018 )"

diff/lex sp-defs-240903/diff 0607
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: BACKWARDS--COMPATIBILITY lexConcept
predicate: definition
changes:
  changes: ++
  changes: type

diff/lex sp-defs-240903/diff 0608
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: BASELINE lexConcept
predicate: definition
changes:
  changes: ++ "Baseline{comment:46} Sets of specifications or work products at specific points in time that have been formally reviewed and agreed on. Notes: - Pay attention that, in the context of System Pillar (and use of Polarion), several kinds of baselines exist: Polarion Document Baseline, Polarion Project Baseline, Polarion Collection Baseline and System Pillar Baseline (treated in the Configuration Management Plan ){comment:218} - This definition is a general definition. Another definition exists in glossary imported from the Subset-23. : SPLI-772 - BASELINE"
  changes: -- "Baseline{comment:46} Sets of specifications or work products at specific points in time that have been formally reviewed and agreed on. Notes: - Pay attention that, in the context of System Pillar (and use of Polarion), several kinds of baselines exist: Polarion Document Baseline, Polarion Project Baseline, Polarion Collection Baseline and System Pillar Baseline (treated in the Configuration Management Plan ) - This definition is a general definition. Another definition exists in glossary imported from the Subset-23. : SPLI-772 - BASELINE"

diff/lex sp-defs-240903/diff 0610
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: BIOMETRIC--READER lexConcept
predicate: definition
changes:
  changes: ++ "Biometric Reader Device that reads the identity of a person by comparing some attribute of their physiological being or behavioral traits against a sample database. This reader permits the authentication of the actor."
  changes: -- "Biometric Reader Device that reads the identity of a person by comparing some attribute of their physiological being or behavioral traits against a sample database. This reader permits the authentication of the actor."

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

diff/lex sp-defs-240903/diff 0612
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: BUILDING--BLOCK lexConcept 2
predicate: definition
changes:
  changes: ++ "A BuildingBlock is a logical unit of the system that is bound to a sourceable physical equipment by means of a Basic Data Identifier having: * standardised functionality or aggregates standard functionality it depends on * may have standardised PRAMS requirements (including Tolerable Functional Failure Rate [TFFR] * may have Safety Integrity Levels [SIL] for functions within the system border and Safety Related Application Conditions [SRAC]) * standardised cyber security requirements (including Security Level [SL] based on the security requirements, and Security Related Application Conditions [SRAC]) * may have (on lower levels) standardised interfaces (on all OSI Layers) towards other Building Blocks and/or external systems. One equipment can host several BuildingBlocks (e.g in the case of a MultiObjectController) and may be separately sourceable from different suppliers and capable of being integrated by a third party (integrator). A BuildingBlock is configured by one or more BuildingBlockConfigurations. A BuildingBlock must have an unique identifier called bbId (that could be a technical system or subsystem identifier). The bbIds are assigned by the integrator and are transferred to another physical unit in case of replacement. Each bbId must be unique."
  changes: -- "A Building Block is an equipment based (hardware and/or software) or logical unit of the System having: * standardised functionality or aggregates standard functionality it depends on * may have standardised PRAMS requirements (including Tolerable Functional Failure Rate [TFFR] * may have Safety Integrity Levels [SIL] for functions within the system border and Safety Related Application Conditions [SRAC]) * standardised cyber security requirements (including Security Level [SL] based on the security requirements, and Security Related Application Conditions [SRAC]) * may have (on lower levels) standardised interfaces (on all OSI Layers) towards other Building Blocks and/or external systems. Equipment based Building Blocks are separately sourceable from different suppliers and capable of being integrated by a third party (integrator). A BuildingBlock has one or more BuildingBlockConfigurations. A BuildingBlock must have a unique identifier composed of configurationGroupId and configurationId."

diff/lex sp-defs-240903/diff 0613
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: BUILDINGBLOCKCONFIGURATION-- CONFIGURATION-JSON --DOCUMENT lexConcept
predicate: definition
changes:
  changes: ++
  changes: type

diff/lex sp-defs-240903/diff 0614
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: BUTTON lexConcept
predicate: definition
changes:
  changes: ++ "Button A Hard Key allocated to a dedicated system on a cab. It's designed with a dedicated SIL level. It allows a selection from two states and keeps one state as long as it is pressed."
  changes: -- "Button A Hard Key allocated to a dedicated system on a cab. It's designed with a dedicated SIL level. It allows a selection from two states and keeps one state as long as it is pressed."

diff/lex sp-defs-240903/diff 0617
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CARRIAGE--FRONT--END lexConcept
predicate: definition
changes:
  changes: ++ "It is represented by a point on the carriage floor along the longitudinal axis. This point is the most forward element belonging to the carriage. Its absolute position is expressed in a geocoordinate reference frame. It is used in the case the ASTP is not installed in the first vehicle."
  changes: -- "It is represented by a point on the carriage floor along the longitudinal axis. This point is the most forward element belonging to the carriage. Its absolute position is expressed in a geocoordinate reference frame. It is used in the case the ASTP is not installed in the first vehicle."

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

diff/lex sp-defs-240903/diff 0619
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0620
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CCF lexConcept
predicate: definition
changes:
  changes: ++
  changes: type
  changes: 1
  changes: common mode failures
  changes: 192
  changes: -03
  changes: -19

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

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

diff/lex sp-defs-240903/diff 0621
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CCS--DEPLOYMENT lexConcept
predicate: definition
changes:
  changes: ++ "CCS Deployment refers to one physical deployment of a CCS System, that is uniquely identifiable with bbId, bbcId and bbcVersion. A CCS Deployment consists of the CCS hardware running the BBCs that are defined in a Top-Level BuildingBlockConfiguration (BBC) and its dependencies."
  changes: -- "CCS Deployment refers to one physical deployment of a CCS System, that is uniquely identifiable with configurationGroupId, configurationId and configurationVersion. A CCS Deployment consists of the CCS hardware running the BBCs that are defined in a Top-Level BuildingBlockConfiguration (BBC) and its dependencies."

diff/lex sp-defs-240903/diff 0622
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CCS--FEATURE lexConcept
predicate: definition
changes:
  changes: ++
  changes: type
  changes: 3

diff/lex sp-defs-240903/diff 0624
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CCS TMS--DATA--MODEL lexConcept
predicate: definition
changes:
  changes: ++ "The CCS/TMS Data Model{comment:91} defines the harmonised language to generate and transport the Domain Data at System Pillar interfaces. The Transversal CCS Subdomain 1 (SD1) is responsible for the specification of the CCS/TMS Data Model in collaboration with * the System Pillar domains which apply the defined data structures in interface specifications * the Innovation Pillar which proves the applicability of the data model by demonstrators."
  changes: -- "The CCS/TMS Data Model{comment:91} defines the harmonised language to generate and transport the Domain Data at System Pillar interfaces. The Transversal CCS Subdomain 1 (SD1) is responsible for the specification of the CCS/TMS Data Model in collaboration with * the System Pillar domains which apply the defined data structures in interface specifications * the Innovation Pillar which proves the applicability of the data model by demonstrators."

diff/lex sp-defs-240903/diff 0625
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: https://glossaries.ontorail.org/LEX_SP-DEFS/lex_sp-defs-241203#CI--%3D--CENTRAL--INSTANCE_lexConcept
predicate: definition
changes:
  changes: ++ "CI = Central Instance ECM 1 and vehicle keeper are registered in EVR () FDFTO TCG = Technical Coordination Group{comment:7}"
  changes: -- "CI = Central Instance ECM 1 and vehicle keeper are registered in EVR () FDFTO TCG = Technical Coordination Group{comment:7}"

diff/lex sp-defs-240903/diff 0626
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CLEAN--CODE--HAS--AN--IMPORTANT--IMPLICATION--OF--THE--PROJECT S--SUCCESS--AS--CLEAN--CODE--I lexConcept
predicate: definition
changes:
  changes: ++ "Clean code has an important implication of the project’s success as clean code is more efficient and reduces potential bugs. The following code guidelines should be followed: * Readability: Readable code is easy to follow and optimizes space and time * Conventions: Follow conventions will structure the code in a better way and reduces unnecessary lines of code - less code is less complexity. * Indentation: Proper indentation is very important to increase the readability. * Design Principles: Resolves common problems in a very structured way. * Documentation: The code should be properly commented for understanding easily. Especially for microservices, the following guidelines should be followed: * Software components should be built as independent stateless services. * All business logic in a service should be encapsulated with the data upon which it acts. * There should be no direct access to a database from outside a service. Any and all access to a database should be accomplished by invoking a service specifically implemented to do so. * Each service should publish an interface that enables access to its data and functionality by other services. Furthermore, the system follows the 12-factor-app methodology: * Codebase: One codebase tracked in revision control; many deploys. * Dependencies: Explicitly declare and isolate dependencies. * Config: Store config in the environment. * Backing services: Treat backing services as attached resources. * Build, release, run: Strictly separate build and run stages. * Processes: Execute the app as one or more stateless processes. * Port binding: Export services via port binding. * Concurrency: Scale out via the process model. * Disposability: Maximize robustness with fast startup and graceful shutdown. * Dev/prod parity: Keep development, staging, and production as similar as possible. * Logs: Treat logs as event streams. * Admin processes: Run admin/management tasks as one-off processes."
  changes: -- "Clean code has an important implication of the project’s success as clean code is more efficient and reduces potential bugs. The following code guidelines should be followed: * Readability: Readable code is easy to follow and optimizes space and time * Conventions: Follow conventions will structure the code in a better way and reduces unnecessary lines of code - less code is less complexity. * Indentation: Proper indentation is very important to increase the readability. * Design Principles: Resolves common problems in a very structured way. * Documentation: The code should be properly commented for understanding easily. Especially for microservices, the following guidelines should be followed: * Software components should be built as independent stateless services. * All business logic in a service should be encapsulated with the data upon which it acts. * There should be no direct access to a database from outside a service. Any and all access to a database should be accomplished by invoking a service specifically implemented to do so. * Each service should publish an interface that enables access to its data and functionality by other services. Furthermore, the system follows the 12-factor-app methodology: * Codebase: One codebase tracked in revision control; many deploys. * Dependencies: Explicitly declare and isolate dependencies. * Config: Store config in the environment. * Backing services: Treat backing services as attached resources. * Build, release, run: Strictly separate build and run stages. * Processes: Execute the app as one or more stateless processes. * Port binding: Export services via port binding. * Concurrency: Scale out via the process model. * Disposability: Maximize robustness with fast startup and graceful shutdown. * Dev/prod parity: Keep development, staging, and production as similar as possible. * Logs: Treat logs as event streams. * Admin processes: Run admin/management tasks as one-off processes."

diff/lex sp-defs-240903/diff 0627
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: COMMON--BUSINESS--OBJECTIVE lexConcept
predicate: definition
changes:
  changes: ++ "A generic target or high level objective defining the mandate of the System Pillar. They are derived by tasks and domains and are not created by them. They can be formulated freely."
  changes: -- "Generic target of the System Pillar."

diff/lex sp-defs-240903/diff 0629
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: COMMON--STANDARD--PROPERTIES--OF--WORKITEMS lexConcept
predicate: definition
changes:
  changes: ++ "* Title: The name of the work item * Description/design: The description of the work item = the design. The description is work item type specific (e.g., a class description for an exchange object). * Type: One of the types in the next chapter, like “operational problem analysis”, “operational requirement”, “System Function” or “logical component” * State: Work items and link types have a sequence of states, they runs through while a trace is worked out. The minimal set of states is * Suspect: Because of trace changes potentially not any more valid (to be checked) * Configuration: (Multiple choice list) Every work item is part of one or more “configurations”. Configurations can be releases, or certain versions of an architecture (for scalability or migration) * Assignment: Every work item shall be assigned to a person or team. It is the role of a functional team to assign unassigned work items when the author is not sure where to assign. The “unassigned” work items are forming the work que for a functional team. * Priority * Due date/finished on * System Level: Every work item has one of the following System levels: “1/2”, “3”, “4”, “5”. The levels are needed to make the right team assignment choices. Example for some requirements: * Requirement “The ATO GoA 4 operational capability shall allow to move trains without driver” – this requirement has System Level 1/2 because CCS, TMS and DAC are involved. Therefore, the modelling service needs to break it down it. * “The ATP operational capability shall allow safe train ahead distances that are shorter than the breaking distance of the following train” – this requirement has System Level 3 because several elements of CCS are involved. * “The maintenance process of an object controller shall be possible via remote operations as far as economically viable” – this requirement has system level 4, the Trackside Asset CS domain will resolve it. * Rationale: The reason for the design (description) * Comments: All historic…
  changes: -- "* Title: The name of the work item * Description/design: The description of the work item = the design. The description is work item type specific (e.g., a class description for an exchange object). * Type: One of the types in the next chapter, like “operational problem analysis”, “operational requirement”, “System Function” or “logical component” * State: Work items and link types have a sequence of states, they runs through while a trace is worked out. The minimal set of states is * Suspect: Because of trace changes potentially not any more valid (to be checked) * Configuration: (Multiple choice list) Every work item is part of one or more “configurations”. Configurations can be releases, or certain versions of an architecture (for scalability or migration) * Assignment: Every work item shall be assigned to a person or team. It is the role of a functional team to assign unassigned work items when the author is not sure where to assign. The “unassigned” work items are forming the work que for a functional team. * Priority * Due date/finished on * System Level: Every work item has one of the following System levels: “1/2”, “3”, “4”, “5”. The levels are needed to make the right team assignment choices. Example for some requirements: * Requirement “The ATO GoA 4 operational capability shall allow to move trains without driver” – this requirement has System Level 1/2 because CCS, TMS and DAC are involved. Therefore, the modelling service needs to break it down it. * “The ATP operational capability shall allow safe train ahead distances that are shorter than the breaking distance of the following train” – this requirement has System Level 3 because several elements of CCS are involved. * “The maintenance process of an object controller shall be possible via remote operations as far as economically viable” – this requirement has system level 4, the Trackside Asset CS domain will resolve it. * Rationale: The reason for the design (description) * Comments: All historic…

diff/lex sp-defs-240903/diff 0630
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: COMPARTMENT lexConcept
predicate: definition
changes:
  changes: ++ "A Compartment is a consistent, integrated entity comprising exactly one Runtime Environment Instance, at most one Safety Environment Replica, and Task Replicas of its respective Functional Applications. It can be deployed on either a Physical or a Virtual Computing Element. Previous definition: A Compartment is a consistent, integrated entity comprising exactly one Runtime Environment Instance, Safety Environment Task Replicas of at most one Safety Environment, and Functional Application Task Replicas of its respective Functional Applications. It can be deployed on either a Physical or a Virtual Computing Element."
  changes: -- "A Compartment is a consistent, integrated entity comprising exactly one Runtime Environment Instance, at most one Safety Environment Replica, and Task Replicas of its respective Functional Applications. It can be deployed on either a Physical or a Virtual Computing Element. Previous definition: A Compartment is a consistent, integrated entity comprising exactly one Runtime Environment Instance, Safety Environment Task Replicas of at most one Safety Environment, and Functional Application Task Replicas of its respective Functional Applications. It can be deployed on either a Physical or a Virtual Computing Element."

diff/lex sp-defs-240903/diff 0632
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONCEPT--ASPECT lexConcept
predicate: definition
changes:
  changes: ++ "A content for sketching concepts regarding analysis purposes which is linked to requirements."
  changes: -- "For sketching concepts."

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

diff/lex sp-defs-240903/diff 0634
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0635
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONFIDENCE--INTERVAL lexConcept
predicate: definition
changes:
  changes: ++ "The position, speed, acceleration interval within which the ASTP assumes the true train position, speed, acceleration is, with a defined probability."
  changes: -- "The position, speed, acceleration interval within which the ASTP assumes the true train position, speed, acceleration is, with a defined probability."

diff/lex sp-defs-240903/diff 0636
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONFIDENTIALITY lexConcept
predicate: definition
changes:
  changes: ++ "Property that information is not made available or disclosed to unauthorized individuals, entities, or processes (source: ISO 27000-2018 )"
  changes: -- "Confidentiality: property that information is not made available or disclosed to unauthorized individuals, entities, or processes (source: ISO 27000-2018 )"

diff/lex sp-defs-240903/diff 0637
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONFIGURATION--ITEM lexConcept
predicate: definition
changes:
  changes: ++ "A configuration item refers to any resource within a system that needs to be managed and controlled in order to support the delivery of products or services. It can be an unchangeable item such as a software (provided by the originator it remains unchanged until installation), or it can be a changeable item such as a parametrisation file (provided by the originator it may be changed by a third party before installation). Configuration items are typically identified, documented, and tracked throughout their lifecycle to ensure proper control, maintenance, and change management. They are often part of a configuration management system or database, which helps in organizing and managing the configuration items and their relationships. The purpose of managing configuration items is to have a clear understanding of the resources that make up a system, their interdependencies, and their characteristics. This enables effective control, planning, and decision-making, particularly in areas such as asset management, change management, and problem resolution."
  changes: -- "A configuration item refers to any resource within a system that needs to be managed and controlled in order to support the delivery of products or services. It can be an unchangeable item such as a software (provided by the originator it remains unchanged until installation), or it can be a changeable item such as a parametrisation file (provided by the originator it may be changed by a third party before installation). Configuration items are typically identified, documented, and tracked throughout their lifecycle to ensure proper control, maintenance, and change management. They are often part of a configuration management system or database, which helps in organizing and managing the configuration items and their relationships. The purpose of managing configuration items is to have a clear understanding of the resources that make up a system, their interdependencies, and their characteristics. This enables effective control, planning, and decision-making, particularly in areas such as asset management, change management, and problem resolution."

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

diff/lex sp-defs-240903/diff 0642
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CONTROLLER--UNIT lexConcept
predicate: definition
changes:
  changes: ++ "Controller Unit The Controller Unit is a hardware component which embeds logical controller(s). There may be only one Hardware or distributed to several HMI elements."
  changes: -- "Controller Unit The Controller Unit is a hardware component which embeds logical controller(s). There may be only one Hardware or distributed to several HMI elements."

diff/lex sp-defs-240903/diff 0643
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0644
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CROSS-ACCEPTANCE lexConcept
predicate: definition
changes:
  changes: ++ "Status{comment:1393} achieved by a product that has been accepted by one authority to the relevant standards and is acceptable to other authorities without the necessity for further assessment, see [IEC 60050-821:2017,{comment:1335} 821-12-15]."
  changes: -- "Status{comment:1393} achieved by a product that has been accepted by one authority to the relevant standards and is acceptable to other authorities without the necessity for further assessment, see [IEC 60050-821:2017,{comment:1335} 821-12-15]."

diff/lex sp-defs-240903/diff 0645
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: CSM-ALSP lexConcept
predicate: definition
changes:
  changes: ++ "Common Safety Methods for assessing the safety level and the safety performance of railway operators [SOURCE: RECOMMENDATION ERA1219 OF THE EUROPEAN UNION AGENCY FOR RAILWAYS]"
  changes: -- "Common Safety Methods for assessing the safety level and the safety performance of railway operators [SOURCE: RECOMMENDATION ERA1219 OF THE EUROPEAN UNION AGENCY FOR RAILWAYS]"

diff/lex sp-defs-240903/diff 0646
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DANGER--ZONE lexConcept
predicate: definition
changes:
  changes: ++ "The area in the trackside in which the track path shall be uninterrupted and unobstructed at the time a train runs over it.{comment:101} (image: diagram_20231212-1333.02592.mxg.svg) Note as a representation, it has the dimensions of the trackside asset (within its boundaries)."
  changes: -- "The area in the trackside in which the track path shall be uninterrupted and unobstructed at the time a train runs over it.{comment:101} (image: diagram_20231212-1333.02592.mxg.svg) Note as a representation, it has the dimensions of the trackside asset (within its boundaries)."

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

diff/lex sp-defs-240903/diff 0650
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DESK--DISPLAY--AREA lexConcept
predicate: definition
changes:
  changes: ++ "Desk Display Area A Zone displaying a piece of visual information of particular system and defined by a size (in cells) and an absolute position (x ,y, z axes). It is more commonly named Area in this specification."
  changes: -- "Desk Display Area A Zone displaying a piece of visual information of particular system and defined by a size (in cells) and an absolute position (x ,y, z axes). It is more commonly named Area in this specification."

diff/lex sp-defs-240903/diff 0651
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DESK lexConcept
predicate: definition
changes:
  changes: ++ "Desk Inside a cab, the set of operating controls*, which is dedicated to preferred movements in a given direction (i.e. forward movements, in which visibility from the cab is provided to the driver). Exception: some single cab locomotives are fitted with one single desk, allowing normal movements in both directions. *set of operating controls: screens, buttons, traction/brake lever, direction controller, radio control, switches, …Desk"
  changes: -- "Desk Inside a cab, the set of operating controls*, which is dedicated to preferred movements in a given direction (i.e. forward movements, in which visibility from the cab is provided to the driver). Exception: some single cab locomotives are fitted with one single desk, allowing normal movements in both directions. *set of operating controls: screens, buttons, traction/brake lever, direction controller, radio control, switches, …Desk"

diff/lex sp-defs-240903/diff 0652
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0655
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: DISTRIBUTIONJOB-- DISTRIBUTION-JOB-JSON --DOCUMENT lexConcept
predicate: definition
changes:
  changes: ++ "A DistributionJob is defines the time and conditions when one or more CCS deployments with the same homologation receive their software configuration update (preload and activation). Examples for conditions when the distribution-job is started are approvals from a train-driver, or someone from operation or a GOA4 system that need to approve the configuration update within the preloading and activation time windows. The distribution-job.json document references the Top Level BuildingBlockConfiguration (BBC), that has recursive dependency tree. The distribution-job is defined within a distribution-job.json document that is validated by the distribution-job.schema.json."
  changes: -- "A DistributionJob is defines the time and conditions when one or more CCS deployments with the same homologation receive their software configuration update (preload and activation). Examples for conditions when the distribution-job is started are approvals from a train-driver, or someone from operation or a GOA4 system that need to approve the configuration update within the preloading and activation time windows. The distribution-job.json document references the Top Level BuildingBlockConfiguration (BBC), that has recursive dependency tree. The distribution-job is defined within a distribution-job.json document that is validated by the distribution-job.schema.json."

diff/lex sp-defs-240903/diff 0661
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ENGAGED--AREA lexConcept
predicate: definition
changes:
  changes: ++ "The equivalent area in the trackside in which (controllable) trackside assets shall be restricted from changing its correlation. In other words, whilst the SPT2OD-6035 - Missing cross-reference is occupied, the safety system shall not allow any request that could lead to the unsafe operation of a (controllable) trackside asset to be executed. {comment:40} (image: diagram_20231212-1351.17308.mxg.svg) Note as a representation, as a minimum, it has the equivalent dimensions of Danger Zone + Operating Time (+ applicable Margin), where: * 'Operation time' represents the (best case){comment:60} minimum period of time required for a controllable trackside asset to complete its operation from one defined state to another. * 'Margin' could refer to processing/communication time, etc."
  changes: -- "The equivalent area in the trackside in which (controllable) trackside assets shall be restricted from changing its correlation. In other words, whilst the SPT2OD-6035 - Missing cross-reference is occupied, the safety system shall not allow any request that could lead to the unsafe operation of a (controllable) trackside asset to be executed. {comment:40} (image: diagram_20231212-1351.17308.mxg.svg) Note as a representation, as a minimum, it has the equivalent dimensions of Danger Zone + Operating Time (+ applicable Margin), where: * 'Operation time' represents the (best case){comment:60} minimum period of time required for a controllable trackside asset to complete its operation from one defined state to another. * 'Margin' could refer to processing/communication time, etc."

diff/lex sp-defs-240903/diff 0662
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ENGINEERING--DATA lexConcept
predicate: definition
changes:
  changes: ++ "The Engineering Data aka Configuration Input Data is created based on the Engineering Input Data (IM Data) but generic (IM-unspecific). Typically, the data are not adapted to cope with specific views demanded by different Consuming Systems. The Engineering Data contains all the base data (i.e., track topology and topography) for deriving the Configuration Data during the compile process. Besides providing base data for the Configuration Data generation, the Engineering Data shall also cover the needs for the configuration of Consuming Systems (e.g., Parameter Data). The Engineering Data must fulfill engineering rules that are influenced by requirements of the Configuration Data for the Consuming Systems. The Engineering Data contains only the updated resulting data (i.e., not several variants/versions of the same track) that is needed for the next compiling and provisioning of Configuration Data and operation at a certain point in time in the Consuming Systems."
  changes: -- "The Engineering Data is created based on the Engineering Input Data (IM Data) but generic (IM-unspecific). Typically, the data are not adapted to cope with specific views demanded by different Consuming Systems. The Engineering Data contains all the base data (i.e., track topology and topography) for deriving the Configuration Data during the compile process. Besides providing base data for the Configuration Data generation, the Engineering Data shall also cover the needs for the configuration of Consuming Systems (e.g., Parameter Data). The Engineering Data must fulfil engineering rules that are influenced by requirements of the Configuration Data model and the Consuming Systems. The Engineering Data contains only the updated resulting data (i.e., not several variants/versions of the same track) that is needed for the next compiling and provisioning of Configuration Data and operation at a certain point in time in the Consuming Systems."

diff/lex sp-defs-240903/diff 0666
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ESSENTIAL--FUNCTION lexConcept
predicate: definition
changes:
  changes: ++
  changes: 62443
  changes: -4
  changes: -2

diff/lex sp-defs-240903/diff 0667
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ESSENTIAL--FUNCTION lexConcept 2
predicate: definition
changes:
  changes: ++ "function or capability that is required to maintain health, safety, the environment and availability for the equipment under control Note 1 to the entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control function and the ability of the operator to view and manipulate the equipment under control. The loss of essential functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries additional functions such as history may be considered essential. IEC 63452 definition: all functions needed to operate the railway system, such as per example traffic control, speed control, traction/breake control,..."
  changes: -- "function or capability that is required to maintain health, safety, the environment and availability for the equipment under control Note 1 to the entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control function and the ability of the operator to view and manipulate the equipment under control. The loss of essential functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries additional functions such as history may be considered essential. IEC 63452 definition: all functions needed to operate the railway system, such as per example traffic control, speed control, traction/breake control,..."

diff/lex sp-defs-240903/diff 0668
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ESTIMATED--DISTANCE lexConcept
predicate: definition
changes:
  changes: ++ "It is expressed as the distance along the track centreline between a reference location and the estimated train front end position."
  changes: -- "It is expressed as the distance along the track centreline between a reference location and the estimated train front end position."

diff/lex sp-defs-240903/diff 0669
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ETP-OB-----EUROPEAN--TRAIN--PROTECTION--ON-BOARD lexConcept
predicate: definition
changes:
  changes: ++ "ETP-OB - European Train Protection On-Board Note: ETP-OB equivalent with ETCS-OB"
  changes: -- "ETP-OB - European Train Protection On-Board Note: ETP-OB equivalent with ETCS-OB"

diff/lex sp-defs-240903/diff 0670
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0671
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: EXCHANGE--ITEM lexConcept
predicate: definition
changes:
  changes: ++ "Element transferred through an interface, which can be either energy, matter, and/or information. A exchange item carries elements with the same transport conditions, simultaneously with the same non-functional properties."
  changes: -- "Collection of elements brought together during one interaction or one exchange between functions or components (such as data, signal, flows ...). A exchange item carries elements with the same transport conditions, simultanuously with the same non-functional properties."

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

diff/lex sp-defs-240903/diff 0674
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: EXTENDED--VIEW lexConcept
predicate: definition
changes:
  changes: ++ "Extended View View displayed on more than one Display Panel."
  changes: -- "Extended View View displayed on more than one Display Panel."

diff/lex sp-defs-240903/diff 0675
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: EXTERNAL--BUTTON lexConcept
predicate: definition
changes:
  changes: ++ "External Button A button which is not directly managed by TDS."
  changes: -- "External Button A button which is not directly managed by TDS."

diff/lex sp-defs-240903/diff 0676
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0677
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0678
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0679
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0680
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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. [IEC 60050-821, 821-12-21]"

diff/lex sp-defs-240903/diff 0681
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FAILURE lexConcept
predicate: definition
changes:
  changes: ++
  changes: 1
  changes: type
  changes: fault
  changes: 192
  changes: -04
  changes: -01

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

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

diff/lex sp-defs-240903/diff 0682
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FAULT--CORRECTION--TIME lexConcept
predicate: definition
changes:
  changes: ++ "part of active corrective maintenance time taken to perform fault correction [SOURCE: IEC 60050-192:2015,192-07-14]"
  changes: -- "part of active corrective maintenance time taken to perform fault correction [SOURCE: IEC 60050-192:2015,192-07-14]"

diff/lex sp-defs-240903/diff 0683
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0684
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FAULT--LOCALIZATION--TIME lexConcept
predicate: definition
changes:
  changes: ++ "DEPRECATED: fault location time part of active corrective maintenance time taken to complete fault localization"
  changes: -- "DEPRECATED: fault location time part of active corrective maintenance time taken to complete fault localization [SOURCE: IEC 60050-192:2015,192-07-18]"

diff/lex sp-defs-240903/diff 0685
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0686
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FEATURE lexConcept
predicate: definition
changes:
  changes: ++ "Characteristic of a system in a product line that distinguishes it from other systems in the product line. Those characteristics express either stakeholder-visible variability or implementation variability. Note: In feature-based product line engineering, features express differences among member products. A characteristic common to all member products in the product line is usually not modelled as a feature. Features in railway is everything what can be different when moving between A and B. Variation type / Dependency | Description (image: 5-screenshot-20241129-173318-7.png) | A mandatory features is implicitly selected if its parent feature is selected. (image: 6-screenshot-20241129-173318-8.png) | Only one group of alternative features is possible under a parent node. Exactly one feature has to be selected from a group if the parent feature is selected. The other alternative feature are automatically excluded. (image: 7-screenshot-20241129-173318-9.png) | The optional features are not belonging to each other (building not a group of similar features). If at least one of the optional features is selected the parent node is selected as well. (image: 8-screenshot-20241129-173318-10.png) | Only one group of or features is possible under a parent node and 0..n features can be selected. If at least one of the or features is selected the parent node is selected as well. In principal optional features and or features are equivalent. The only difference is that optional features do not belong to each other and or features are a group of similar features."
  changes: --

diff/lex sp-defs-240903/diff 0688
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FMECA lexConcept
predicate: definition
changes:
  changes: ++
  changes: type
  changes: 1
  changes: fault mode, effects and criticality analysis
  changes: 60050
  changes: -191
  changes: diff/lex sp-defs-240903/1990
  diff/lex sp-defs-240903/2015: type
  diff/lex sp-defs-240903/2015: 192
  diff/lex sp-defs-240903/2015: -04
  diff/lex sp-defs-240903/2015: -01
  diff/lex sp-defs-240903/2015: -03
  diff/lex sp-defs-240903/2015: -17

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

type
diff/lex sp-defs-240903/2015: 192
diff/lex sp-defs-240903/2015: -04
diff/lex sp-defs-240903/2015: -01
diff/lex sp-defs-240903/2015: -03
diff/lex sp-defs-240903/2015: -17

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

diff/lex sp-defs-240903/diff 0689
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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…

diff/lex sp-defs-240903/diff 0691
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: 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. The FFFIS and accompanying documents (e.g. safety analysis) guarantees the interoperability but not the exchangeability of physical entities, see Subset-037 SPT2ARC-1620."

diff/lex sp-defs-240903/diff 0692
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0693
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FULL--BACKWARDS--COMPATIBILITY lexConcept
predicate: definition
changes:
  changes: ++
  changes: complete backward compatibility,
  changes: type

diff/lex sp-defs-240903/diff 0696
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FUNCTIONAL--TEAM lexConcept
predicate: definition
changes:
  changes: ++

…
…: 2

diff/lex sp-defs-240903/diff 0697
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FUNCTION lexConcept
predicate: definition
changes:
  changes: ++ "A function is a transformation of inputs into outputs which is purpose-oriented and pays towards a higher goal of a system. All possible input and output values are defined by the exchange items allocated to the functional exchanges of the function. Consequently, when the inputs to the system change, the transformations within the system modify the outputs accordingly. They can be available in a range of system states and therefore change its behaviour based on the current state of inputs. The structure of functions does not have to reflect any possible implementation and does not have to follow an object decomposition paradigm, as would be followed normally by software engineers implementing one or more systems. In addition, each function is continuously performed by the system or system actors. They are not created, called and terminated. Functions are allocated to the system or to the system actors. Each function is allocated to one or multiple functional requirements, defining “what” the function is doing. The expected characteristics of functions are then specified via non-functional requirements, which define the “how” (how safe, how accurate, how fast, how reliable, etc.) the function is performing the transformation."
  changes: -- "A function is a continuous transformation of inputs into outputs which is purpose-oriented and pays towards a higher goal of a system. All possible input and output values are defined by the exchange items allocated to the functional exchanges of the function. Functions are allocated to the system or to the system actors. Consequently, when the inputs to the system change, the transformations within the system modify the outputs accordingly. They can be also available in a range of system states and therefore change its behaviour based on the current state. Each function is allocated to {comment:17}one or multiple functional requirements, defining “what” the function is doing. The expected characteristics of functions are then specified via non-functional requirements, which define the “how” (how safe, how accurate, how fast, how reliable, etc.) the function is performing the transformation. The structure of functions does not have to reflect any possible implementation and does not have to follow an object decomposition paradigm, as would be followed normally by software engineers implementing one or more systems."

diff/lex sp-defs-240903/diff 0698
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: FUNKTIONAL--TEAM lexConcept
predicate: definition
changes:
  changes: ++

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

diff/lex sp-defs-240903/diff 0702
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: GENERIC--WORKFLOW--TYPES lexConcept
predicate: definition
changes:
  changes: ++ "* Assignment workflow: Unassigned, rejected, or unlinked work items are assigned to a team based on the work item type and system level (done by a functional team, see [2]) * Derivation workflow: The standard workflow, where work items are resolved along the mandatory trace (along the workflow rules), work is moving from team to team, or from team collaboration to team collaboration * Trace change workflow: A change in a trace is analysed up to the highest work item again (done by modelling service, all work items get “suspect”), and from there all derivations are checked, resolved, and approved again (derivation workflow). * Uplink workflow: A set of traces is “connected” to another set. This typically happens, when “external contributions” are imported (e.g. a team that proposes the interfaces of a subsystem). The connection links are created as proposals. For all new connection links a trace change workflow is executed. Redundancies are analysed and eliminated, what again triggers trace change workflows. * Trace analysis workflow: Progress and trace consistency are analysed and reported by the modelling service These workflows are assigned by the team or person, where the triggering work item is assigned to. The trace analysis is done by the modelling service on a frequent basis."
  changes: -- "* Assignment workflow: Unassigned, rejected, or unlinked work items are assigned to a team based on the work item type and system level (done by a functional team, see [2]) * Derivation workflow: The standard workflow, where work items are resolved along the mandatory trace (along the workflow rules), work is moving from team to team, or from team collaboration to team collaboration * Trace change workflow: A change in a trace is analysed up to the highest work item again (done by modelling service, all work items get “suspect”), and from there all derivations are checked, resolved, and approved again (derivation workflow). * Uplink workflow: A set of traces is “connected” to another set. This typically happens, when “external contributions” are imported (e.g. a team that proposes the interfaces of a subsystem). The connection links are created as proposals. For all new connection links a trace change workflow is executed. Redundancies are analysed and eliminated, what again triggers trace change workflows. * Trace analysis workflow: Progress and trace consistency are analysed and reported by the modelling service These workflows are assigned by the team or person, where the triggering work item is assigned to. The trace analysis is done by the modelling service on a frequent basis."

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

diff/lex sp-defs-240903/diff 0704
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HARD--KEY lexConcept
predicate: definition
changes:
  changes: ++ "Hard Key Physical key not part of view. This key can also have a text label or symbol."
  changes: -- "Hard Key Physical key not part of view. This key can also have a text label or symbol."

diff/lex sp-defs-240903/diff 0705
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HARDWARE--ABSTRACTION--INTERFACE lexConcept
predicate: definition
changes:
  changes: ++ "The Hardware Abstraction Interface I2 (Interface 2) provides an abstraction of all technology layers above from the specific hardware used below, enabling easy replace ability of commercial of-the-shelf hardware procurable from a well-sized market of hardware vendors. Note: This is not really an interface, but rather a compatibility list of allowed hardware incl. CPU, memory, etc."
  changes: -- "The Hardware Abstraction Interface I2 (Interface 2) provides an abstraction of all technology layers above from the specific hardware used below, enabling easy replace ability of commercial of-the-shelf hardware procurable from a well-sized market of hardware vendors. Note: This is not really an interface, but rather a compatibility list of allowed hardware incl. CPU, memory, etc."

diff/lex sp-defs-240903/diff 0706
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HARMONIZED--PRODUCT lexConcept
predicate: definition
changes:
  changes: **++ "A product is harmonized only if it adapts all availabe harmonized interfaces of the System Pillar Refernce Architecture (SPRA) on all interface types (system interface, user interface, physical interface) and the correlating system behaviour (=stateful reaction on input interfaces/events on state changes/output interfaces). A harmonized product could have customized additional optional interfaces and system behavior, if the system can be used in the harmonized way without making use of them."
  changes: **-- "A product is harmonized only if it adapts all availabe harmonized interfaces of the System Pillar Refernce Architecture (SPRA) on all interface types (system interface, user interface, physical interface) and the correlating system behaviour (=stateful reaction on input interfaces/events on state changes/output interfaces). A harmonized product could have customized additional optional interfaces and system behavior, if the system can be used in the harmonized way without making use of them."

diff/lex sp-defs-240903/diff 0707
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HAZARD lexConcept
predicate: definition
changes:
  changes: ++
  changes: 1
  changes:
    diff/lex sp-defs-240903/2013: 903
    diff/lex sp-defs-240903/2013: -01
    diff/lex sp-defs-240903/2013: -02
  changes: harm
  changes: accident

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

diff/lex sp-defs-240903/diff 0708
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HAZOP lexConcept
predicate: definition
changes:
  changes: ++ "A hazard and operability study (HAZOP) is a structured and systematic examination of a complex planned or existing process or operation in order to identify and evaluate problems that may represent risks to personnel or equipment. The intention of performing a HAZOP is to review the design to pick up design and engineering issues that may otherwise not have been found. The technique is based on breaking the overall complex design of the process into a number of simpler sections called 'nodes' which are then individually reviewed. It is carried out by a suitably experienced multi-disciplinary team (HAZOP) during a series of meetings. The HAZOP technique is qualitative, and aims to stimulate the imagination of participants to identify potential hazards and operability problems. Structure and direction are given to the review process by applying standardised guide-word prompts to the review of each node. [SOURCE: Wikipedia Hazard and operability study - Wikipedia]"
  changes: -- "A hazard and operability study (HAZOP) is a structured and systematic examination of a complex planned or existing process or operation in order to identify and evaluate problems that may represent risks to personnel or equipment. The intention of performing a HAZOP is to review the design to pick up design and engineering issues that may otherwise not have been found. The technique is based on breaking the overall complex design of the process into a number of simpler sections called 'nodes' which are then individually reviewed. It is carried out by a suitably experienced multi-disciplinary team (HAZOP) during a series of meetings. The HAZOP technique is qualitative, and aims to stimulate the imagination of participants to identify potential hazards and operability problems. Structure and direction are given to the review process by applying standardised guide-word prompts to the review of each node. [SOURCE: Wikipedia Hazard and operability study - Wikipedia]"

diff/lex sp-defs-240903/diff 0709
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0710
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HIGH--LEVEL--BUILDINGBLOCKS lexConcept
predicate: definition
changes:
  changes: ++

diff/lex sp-defs-240903/diff 0711
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HMI--COMPONENT lexConcept
predicate: definition
changes:
  changes: ++ "A Secure Component with a human machine interface. Examples of HMI Components are PC Workstation, tablet device, smart phone, device with touch screen,... Exemptions: embedded components without a screen, e.g. with push buttons and LEDs."
  changes: -- "A Secure Component with a human user interface. Examples of HMI Components are PC Workstation, tablet device, smart phone, device with touch screen,... Exemptions: embedded components without a screen, e.g. with push buttons and LEDs."

diff/lex sp-defs-240903/diff 0712
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HMI--ELEMENT lexConcept
predicate: definition
changes:
  changes: ++ "HMI Element An HMI Element is a physical component that interacts with the driver: Buzzer, Display Panel, loudspeaker, Hard Key..."
  changes: -- "HMI Element An HMI Element is a physical component that interacts with the driver: Buzzer, Display Panel, loudspeaker, Hard Key..."

diff/lex sp-defs-240903/diff 0713
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HOMOLOGATION lexConcept
predicate: definition
changes:
  changes: ++
  changes: type

diff/lex sp-defs-240903/diff 0715
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0716
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: HUMAN-SYSTEM--INTEGRATION 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 - Safety related application conditions ."
  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 - Safety related application conditions ."

diff/lex sp-defs-240903/diff 0717
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0718
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: IN--THIS--DOCUMENT--THE--ABBREVIATIONS-- IM --FOR--INFRASTRUCTURE--MANAGER --AND-- RU --FO lexConcept
predicate: definition
changes:
  changes: ++
  changes: IM
  changes: and
  changes: for Railway Undertaking are used due to their widespread use in the rail sector. The equivalents terms are
  changes: for Rail Infrastructure Managers
  changes: ROC

diff/lex sp-defs-240903/diff 0722
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0723
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: INTEGRITY lexConcept
predicate: definition
changes:
  changes: ++ "Integrity: property of accuracy and completeness (source: ISO 27000-2018 )"
  changes: -- "Integrity: property of accuracy and completeness (source: ISO 27000-2018 )"

diff/lex sp-defs-240903/diff 0724
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: INTERCHANGEABILITY lexConcept
predicate: definition
changes:
  changes: ++ "Interchangeability is the ability to replace a subsystem from supplier A by a sub-system from supplier B without affecting other sub-systems or the overall system/subsystem and with a lowest reasonable integration effort{comment:1295} and without any need for recertification. Interchangeability is related also to the physical characteristics of sub-systems."
  changes: -- "Interchangeability is the ability to replace a subsystem from supplier A by a sub-system from supplier B without affecting other sub-systems or the overall system/subsystem and with a lowest reasonable integration effort{comment:1295} and without any need for recertification. Exchangeability and interchangeability are related to the physical characteristics and replacement of sub-systems whereas interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."

diff/lex sp-defs-240903/diff 0725
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: INTERNAL--BUTTON lexConcept
predicate: definition
changes:
  changes: ++ "Internal Button The Internal Button is a button which is managed directly by TDS."
  changes: -- "Internal Button The Internal Button is a button which is managed directly by TDS."

diff/lex sp-defs-240903/diff 0726
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: INTEROPERABILITY--CONSTITUENTS lexConcept
predicate: definition
changes:
  changes: ++ "SPPRAMSS-328 - [TSI CCS + (EU) 2023/1695] section 5.1. Definition In accordance with Article 2(7) of Directive (EU) 2016/797, interoperability constituents means any elementary component, group of components, subassembly or complete assembly of equipment incorporated or intended to be incorporated into a subsystem, upon which the interoperability of the rail system depends directly or indirectly, including both tangible objects and intangible objects."
  changes: -- "SPPRAMSS-328 - [TSI CCS + (EU) 2023/1695] section 5.1. Definition In accordance with Article 2(7) of Directive (EU) 2016/797, interoperability constituents means any elementary component, group of components, subassembly or complete assembly of equipment incorporated or intended to be incorporated into a subsystem, upon which the interoperability of the rail system depends directly or indirectly, including both tangible objects and intangible objects."

diff/lex sp-defs-240903/diff 0727
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: INTEROPERABILITY lexConcept 2
predicate: definition
changes:
  changes: ++ "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance, see [Subset-023] SPT2ARC-1619 and [IOP-Dir 2016/797] SPT2ARC-1617 so that a train is able to run across different Infrastructure Managers (IM) networks, and that an IM network and that an infrastructure network{comment:1394} is able to interact with trains of different Railway Undertakings, using systems/sub-systems from different origins. Interoperability between subsystems is defined to achieve a similar unrestricted safe and uninterrupted interaction between subsystems."
  changes: -- "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance, see [Subset-023] SPT2ARC-1619 and [IOP-Dir 2016/797] SPT2ARC-1617 so that a train is able to run across different Infrastructure Managers (IM) networks, and that an IM network and that an infrastructure network{comment:1394} is able to interact with trains of different Railway Undertakings, using systems/sub-systems from different origins. Exchangeability and interchangeability are related to the physical characteristics of sub-systems whereas interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."

diff/lex sp-defs-240903/diff 0729
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: KEY--CONTROLLER lexConcept
predicate: definition
changes:
  changes: ++ "Key Controller Controller which manages states and failures of Hard Keys (internal and Lateral Key) and switches."
  changes: -- "Key Controller Controller which manages states and failures of Hard Keys (internal and Lateral Key) and switches."

diff/lex sp-defs-240903/diff 0730
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LATERAL--KEY lexConcept
predicate: definition
changes:
  changes: ++ "Lateral Key Hard Key located close to a Display Area allowing soft key technology."
  changes: -- "Lateral Key Hard Key located close to a Display Area allowing soft key technology."

diff/lex sp-defs-240903/diff 0731
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LAYOUT--CONTROLLER lexConcept
predicate: definition
changes:
  changes: ++ "Layout Controller The Layout Controller manages the Layout for an Area."
  changes: -- "Layout Controller The Layout Controller manages the Layout for an Area."

diff/lex sp-defs-240903/diff 0732
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LAYOUT--ELEMENT--CONTROLLER lexConcept
predicate: definition
changes:
  changes: ++ "Layout Element Controller The Layout Element Controller managesLayout Elements of a Layout. It knows how to present itself and how to react on events."
  changes: -- "Layout Element Controller The Layout Element Controller managesLayout Elements of a Layout. It knows how to present itself and how to react on events."

diff/lex sp-defs-240903/diff 0733
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LAYOUT--ENGINE lexConcept
predicate: definition
changes:
  changes: ++ "Layout Engine The Layout Engine is a generic piece of software able to generate any View based on Areas, Layouts and Layout Elements as defined in a configuration."
  changes: -- "Layout Engine The Layout Engine is a generic piece of software able to generate any View based on Areas, Layouts and Layout Elements as defined in a configuration."

diff/lex sp-defs-240903/diff 0734
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LAYOUT lexConcept
predicate: definition
changes:
  changes: ++ "Layout Layout is a list of layout elements which is displayed in an area."
  changes: -- "Layout Layout is a list of layout elements which is displayed in an area."

diff/lex sp-defs-240903/diff 0736
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0738
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LOCALISATION--INFORMATION lexConcept
predicate: definition
changes:
  changes: ++ "Set of spatial values referenced to the rail network, and kinematic variables referenced to the train unit, that provide the train front end position of the train in a specific point of the network and its dynamic behaviour from its speed, acceleration, and orientation values."
  changes: -- "Set of spatial values referenced to the rail network, and kinematic variables referenced to the train unit, that provide the train front end position of the train in a specific point of the network and its dynamic behaviour from its speed, acceleration, and orientation values."

diff/lex sp-defs-240903/diff 0739
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0740
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: LOUDSPEAKER lexConcept
predicate: definition
changes:
  changes: ++ "Loudspeaker Device that converts an electrical audio signal into a corresponding sound."
  changes: -- "Loudspeaker Device that converts an electrical audio signal into a corresponding sound."

diff/lex sp-defs-240903/diff 0741
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0742
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0743
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0744
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0747
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0748
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0750
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MEASURE--OF--EFFECTIVENESS 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"

diff/lex sp-defs-240903/diff 0751
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: METHODOLOGY lexConcept
predicate: definition
changes:
  changes: ++ "A collection of related processes, methods, and tools.{comment:408}"
  changes: -- "A collection of related processes, methods, and tools."

diff/lex sp-defs-240903/diff 0752
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: METHOD lexConcept
predicate: definition
changes:
  changes: ++ "A technique for performing a task. Method is a grouping of guidance, modelling{comment:72} language, rules, techniques and patterns. Different methods may be available for the same task. It defines the “HOW” of each task. (In this context, the words “method,” “technique,” “practice,” and “procedure” are often used interchangeably.) At any level, process tasks are performed using methods. {comment:407}"
  changes: -- "A technique for performing a task. Method is a grouping of guidance, modelling{comment:72} language, rules, techniques and patterns. Different methods may be available for the same task. It defines the “HOW” of each task. (In this context, the words “method,” “technique,” “practice,” and “procedure” are often used interchangeably.) At any level, process tasks are performed using methods."

diff/lex sp-defs-240903/diff 0753
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MFDT lexConcept
predicate: definition
changes:
  changes: ++ "mean fault detection time [SOURCE: SPPRAMSS-3539 - [EN 61703: 2016]]"
  changes: -- "mean fault detection time [SOURCE: SPPRAMSS-3539 - [EN 61703: 2016]]"

diff/lex sp-defs-240903/diff 0754
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MICROPHONE--CONTROLLER lexConcept
predicate: definition
changes:
  changes: ++ "Microphone Controller The Microphone Controller manages states and signals of Microphone."
  changes: -- "Microphone Controller The Microphone Controller manages states and signals of Microphone."

diff/lex sp-defs-240903/diff 0755
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MICROPHONE lexConcept
predicate: definition
changes:
  changes: ++ "Microphone Device that translates sound vibrations from the air into electronic signals and scribes them to a recording medium or over a loudspeaker."
  changes: -- "Microphone Device that translates sound vibrations from the air into electronic signals and scribes them to a recording medium or over a loudspeaker."

diff/lex sp-defs-240903/diff 0756
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MIGRATION--STRATEGIES lexConcept
predicate: definition
changes:
  changes: ++ "The typical expected international timing of the harmonisation phase from international perspective is, that there will be early providers/early birds, and late providers/late birds. Since the reference architecture consists of different systems, the railways can also apply different migration strategies to different systems (image: 1-diagram_20240626-1851.56163.mxg.svg)"
  changes: -- "The typical expected international timing of the harmonisation phase from international perspective is, that there will be early providers/early birds, and late providers/late birds. Since the reference architecture consists of different systems, the railways can also apply different migration strategies to different systems (image: 1-diagram_20240626-1851.56163.mxg.svg)"

diff/lex sp-defs-240903/diff 0757
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0758
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0759
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0760
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVEMENT--PERMISSION lexConcept
predicate: definition
changes:
  changes: ++ "A Movement Permission (MP) is an authorisation for a particular Train Object to move. A Movement Permission includes all conditions under which the movement of the Train Object can be performed safely. A Movement Permission always refers to exactly one Train Object."
  changes: -- "Movement Permissions are within the Operating State of TPS. A Movement Permission represents the area of the track layout reserved for a train within TPS. (image: 1-screenshot-20240815-145159.png)"

diff/lex sp-defs-240903/diff 0761
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK lexConcept
predicate: definition
changes:
  changes: ++ "A Trackside where the Movement Authority for a train can be issued to the Confirmed Rear End of the preceding train. End of Authority can therefore be an arbitrary location on the railway and not constrained to fixed block locations."
  changes: -- "The term moving block is part of the ETCS Level 2 Moving Block Principle, which is a signalling concept placing emphasis on a largely independent signalling from the physical infrastructure. A moving block is defined by a block bounded by the confirmed rear end and the confirmed rear end of the preceding train (case 1, Figure 1) or, if closer, the beginning of the next fixed block (case 2, Figure 2). Such fixed blocks are delimited by TTDs e.g. around points and may for efficiency reasons still be used on ETCS L2MB lines. (image: 2-Def_MovingBlock1.png) Figure {caption:Figure} Case 1 Definition of Moving Block(image: 1-Def_MovingBlock2.png) Figure {caption:Figure} Case 2 Definition of Moving Block (incl. TTDs)) The confirmed rear end of the preceding train is what releases the track behind it and in most cases delimits the moving block. It is established from the safe train length, represented by the distance between the estimated train front end position and the min safe rear end of the train [SUBSET-026 Baseline 4], if derived from a train position report with confirmed train integrity."

diff/lex sp-defs-240903/diff 0762
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MOVING--BLOCK lexConcept 2
predicate: definition
changes:
  changes: ++ "The term moving block is part of the ETCS Level 2 Moving Block Principle, which is a signalling concept placing emphasis on a largely independent signalling from the physical infrastructure. A moving block is defined by a block bounded by the confirmed rear end and the confirmed rear end of the preceding train (case 1, Figure 1) or, if closer, the beginning of the next fixed block (case 2, Figure 2). Such fixed blocks are delimited by TTDs e.g. around points and may for efficiency reasons still be used on ETCS L2MB lines. (image: 2-Def_MovingBlock1.png) Figure {caption:Figure} Case 1 Definition of Moving Block Figure {caption:Figure} Case 2 Definition of Moving Block (incl. TTDs)) The confirmed rear end of the preceding train is what releases the track behind it and in most cases delimits the moving block. It is established from the safe train length, represented by the distance between the estimated train front end position and the min safe rear end of the train [SUBSET-026 Baseline 4], if derived from a train position report with confirmed train integrity."
  changes: -- "Moving block is based on the principle of spacing trains in absolute braking distance. In a moving block system, the rear end of a train is considered as a moving danger point to be protected against a following train. Positions of the trains are either given by trackside or trainside localisation euqipment."

diff/lex sp-defs-240903/diff 0764
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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 = fault localization time + fault correction time + function checkout time according SPPRAMSS-3539 - [EN 61703: 2016]"

diff/lex sp-defs-240903/diff 0765
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MTBF 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]"

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

diff/lex sp-defs-240903/diff 0767
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0768
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0769
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MTTF lexConcept
predicate: definition
changes:
  changes: ++
  changes: 1

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

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

diff/lex sp-defs-240903/diff 0770
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: MTTR lexConcept
predicate: definition
changes:
  changes: ++ "mean time to restoration - expectation of the time to restoration deprecated: mean time to repair, mean time to recovery Note 1 to entry: IEC 60050-191:1990 (now withdrawn; replaced by IEC 60050-192:2015) defined the term ”mean time to recovery” as a synonym, but restoration and recovery are not synonyms. Note 2 to entry: MTTR = MFDT + MAD + MLD + MTD + MRT according SPPRAMSS-3539 - [EN 61703: 2016] [SOURCE: IEC 60050-192, 192-07-23, modified: Note 2 to entry added.]"
  changes: -- "mean time to restoration - expectation of the time to restoration deprecated: mean time to repair, mean time to recovery Note 1 to entry: IEC 60050-191:1990 (now withdrawn; replaced by IEC 60050-192:2015) defined the term ”mean time to recovery” as a synonym, but restoration and recovery are not synonyms. Note 2 to entry: MTTR = MFDT + MAD + MLD + MTD + MRT according SPPRAMSS-3539 - [EN 61703: 2016] [SOURCE: IEC 60050-192, 192-07-23, modified: Note 2 to entry added.]"

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

diff/lex sp-defs-240903/diff 0772
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0775
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: NETWORK--COMPONENT lexConcept
predicate: definition
changes:
  changes: ++ "A device that facilitates IP data flow between devices, or restricts the flow of data, but may not directly interact with a control process. Examples of Network Components are network switches, LAN/WAN routers, firewalls, data diodes and VPN endpoints. Excluded from this definition are media converters, transceivers and bridges with no routing, switching or filtering capabilities. Such devices are not affected by this specification."
  changes: -- "An implementation of data networking functions such as switching, routing, filtering or tunneling. Examples of Network Components are network switches, LAN/WAN routers, firewalls, data diodes and VPN endpoints. Excluded are from this definition are media converters, transceivers and bridges with no routing, switching or filtering capabilities."

diff/lex sp-defs-240903/diff 0777
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: NON-REPUDIATION lexConcept
predicate: definition
changes:
  changes: ++ "Non-Repudiation: ability to prove the occurrence of a claimed event or action and its originating entities (source: ISO 27000-2018 )"
  changes: -- "Non-Repudiation: ability to prove the occurrence of a claimed event or action and its originating entities (source: ISO 27000-2018 )"

diff/lex sp-defs-240903/diff 0778
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0781
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: ODOMETRY lexConcept
predicate: definition
changes:
  changes: ++ "This term represents the odometry functionality as specified in the CCS TSI 2023. According to the glossary (SUBSET-23, TSI 2023): Odometry is the process of measuring the train’s movement along the track. Used for speed measurement and distance measurement."
  changes: -- "This term represents the odometry functionality as specified in the CCS TSI 2023. According to the glossary (SUBSET-23, TSI 2023): Odometry is the process of measuring the train’s movement along the track. Used for speed measurement and distance measurement."

diff/lex sp-defs-240903/diff 0782
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OMS-----ONLINE--MONITORING--SYSTEM lexConcept
predicate: definition
changes:
  changes: ++ "OMS - Online Monitoring System NOTE : OMS is both trackside and on-board."
  changes: -- "OMS - Online Monitoring System NOTE : OMS is both trackside and on-board."

diff/lex sp-defs-240903/diff 0784
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATING--STATE lexConcept
predicate: definition
changes:
  changes: ++ "The operating state describes the current state of production: * how trains move * where trains are * which route is set in control system * status of assets This information is based on inputs from control systems."
  changes: -- "The operating state describes the current state of production: * how trains move * where trains are * which route is set in control system * status of assets This information is based on inputs from control systems."

diff/lex sp-defs-240903/diff 0786
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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]"

diff/lex sp-defs-240903/diff 0787
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0788
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--CONCEPTS lexConcept
predicate: definition
changes:
  changes: ++ "Operational concepts (How system should function)"
  changes: -- "(image: 1-screenshot-20230102-140337.png)"

diff/lex sp-defs-240903/diff 0789
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--EPICS lexConcept
predicate: definition
changes:
  changes: ++ "Operational epics refer to large-scale initiatives or projects that are focused on improving the operational aspects of a business or organization. Unlike user epics, which typically address customer or user needs, operational epics are aimed at enhancing internal processes, systems, or infrastructure to optimize efficiency, productivity, and overall performance. Operational epics often involve cross-functional collaboration and may span multiple departments or teams within an organization. They are typically strategic in nature and aligned with the overall goals and objectives of the organization. Examples of operational epics could include implementing a new supply chain management system, revamping the customer support process, or optimizing the IT infrastructure to improve data security and accessibility. The use of epics in operational contexts helps break down complex initiatives into manageable units, allowing for better planning, resource allocation, and tracking of progress. By focusing on operational improvements, organizations can streamline their workflows, reduce costs, and enhance the overall effectiveness of their operations."
  changes: -- "Operational epics refer to large-scale initiatives or projects that are focused on improving the operational aspects of a business or organization. Unlike user epics, which typically address customer or user needs, operational epics are aimed at enhancing internal processes, systems, or infrastructure to optimize efficiency, productivity, and overall performance. Operational epics often involve cross-functional collaboration and may span multiple departments or teams within an organization. They are typically strategic in nature and aligned with the overall goals and objectives of the organization. Examples of operational epics could include implementing a new supply chain management system, revamping the customer support process, or optimizing the IT infrastructure to improve data security and accessibility. The use of epics in operational contexts helps break down complex initiatives into manageable units, allowing for better planning, resource allocation, and tracking of progress. By focusing on operational improvements, organizations can streamline their workflows, reduce costs, and enhance the overall effectiveness of their operations."

diff/lex sp-defs-240903/diff 0790
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--HARMONIZATION lexConcept
predicate: definition
changes:
  changes: ++

diff/lex sp-defs-240903/diff 0791
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--MISSION lexConcept
predicate: definition
changes:
  changes: ++ "SPT2OD-4977 - Missing cross-reference refers to the complete operational journey planned from one initial position on the railway network to a final position on the railway network. Most commonly this can be exemplified by the commercial journey starting at a central station, passing through many regional stations before ending at a final central station somewhere else on the railway network. One SPT2OD-4977 - Missing cross-reference may have many SPT2OD-4978 - Missing cross-reference and may be assigned to the responsibility of one or more SPT2OD-4967 - Missing cross-reference along the way."
  changes: -- "SPT2OD-4977 - Missing cross-reference refers to the complete operational journey planned from one initial position on the railway network to a final position on the railway network. Most commonly this can be exemplified by the commercial journey starting at a central station, passing through many regional stations before ending at a final central station somewhere else on the railway network. One SPT2OD-4977 - Missing cross-reference may have many SPT2OD-4978 - Missing cross-reference and may be assigned to the responsibility of one or more SPT2OD-4967 - Missing cross-reference along the way."

diff/lex sp-defs-240903/diff 0792
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--REQUIREMENT lexConcept 2
predicate: definition
changes:
  changes: ++ "Operational requirements are requirements which an operational procedure and its design has to fulfil."
  changes: -- "Something a process design has to fulfil."

diff/lex sp-defs-240903/diff 0793
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: OPERATIONAL--TRACK--PROPERTIES lexConcept
predicate: definition
changes:
  changes: ++ "Properties of a given piece of track, impacting operations. Non-exhaustive list: * Air tightness * Axle load/Line category * Load type restrictions (e.g. hazardous material, passenger) * Loading gauge restrictions * Low adhesion * Switchable neutral section * Operating regime * Driveability Hint: This includes a track closure. The driveability parameter can be train (category) specific. * Driving on sight * Local Operation Area Hint: A Local Operation Area is meant to be the technical possibility to implement a Temporary Shunting Area via this restriction toolset. * Modes/accepted GoA level * Speed Hint: The Static Speed Profile is not subject of this scenario, only temporary restrictions. * Overhead current restrictions (including restart of operations after a blackout, with not enough power for all trains to start simultaneously) * Prohibitions of usage of brakes * Sanding * Traction type * Wind vulnerability The following track properties are considered to be static properties, which will not be managed with dynamic restrictions, but via the static infrastructure data (Digital Map/Digital Register): * Big Metal Masses * Non-stopping area * Powerless area * Radio hole * Tunnel Stopping Are"
  changes: -- "Properties of a given piece of track, impacting operations. Non-exhaustive list: * Air tightness * Axle load/Line category * Load type restrictions (e.g. hazardous material, passenger) * Loading gauge restrictions * Low adhesion * Switchable neutral section * Operating regime * Driveability Hint: This includes a track closure. The driveability parameter can be train (category) specific. * Driving on sight * Local Operation Area Hint: A Local Operation Area is meant to be the technical possibility to implement a Temporary Shunting Area via this restriction toolset. * Modes/accepted GoA level * Speed Hint: The Static Speed Profile is not subject of this scenario, only temporary restrictions. * Overhead current restrictions (including restart of operations after a blackout, with not enough power for all trains to start simultaneously) * Prohibitions of usage of brakes * Sanding * Traction type * Wind vulnerability The following track properties are considered to be static properties, which will not be managed with dynamic restrictions, but via the static infrastructure data (Digital Map/Digital Register): * Big Metal Masses * Non-stopping area * Powerless area * Radio hole * Tunnel Stopping Are"

diff/lex sp-defs-240903/diff 0794
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/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-240903/diff 0796
type: diff/lex sp-defs-240903/Object attribute changedValues
entity: diff/lex sp-defs-240903/entity
entity: PFH lexConcept
predicate: definition
changes:
  changes: ++
  changes: type
  changes: 1
  changes: . NOTE 2 From a theoretical point of view, the PFH is the average of the unconditional failure intensity, also called failure frequency, and which is generally designated w(t). It should not be confused with a failure rate (see Annex B of IEC 61508-6). NOTE 3 When the E/E/PE safety-related system is the ultimate safety layer, the PFH should be calculated from its unreliability F(T)=1-R(t) (see “failure rate” above). When it is not the ultimate safety-related system its PFH should be calculated from its unavailability U(t) (see PFD above). PFH approximations are given by F(T)/T and 1/MTTF in the first case and 1/MTBF in the second case. NOTE 4 When the E/E/PE safety-related system implies only quickly repaired revealed failures then an asymptotic failure rate λas is quickly reached. It provides an estimate of the PFH. [EN 61508-4:2010 - §3.6.19]
  changes: ,
  changes: average frequency of a dangerous failure per hour average frequency of a dangerous failure of an E/E/PE safety related system to perform the specified safety function over a given period of time NOTE 1 The term “probability of dangerous failure per hour” is not used in this standard but the acronym PFH has been retained but when it is used it means “average frequency of dangerous failure [h]". NOTE 2 From a theoretical point of view, the PFH is the average of the unconditional failure intensity, also called failure frequency, and which is generally designated w(t). It should not be confused with a failure rate (see Annex B of IEC 61508-6). NOTE 3 When the E/E/PE safety-related system is the ultimate safety layer, the PFH should be calculated from its unreliability F(T)=1-R(t) (see “failure rate” above). When it is not the ultimate safety-related system its PFH should be calculated from its unavailability U(t) (see PFD above). PFH approximations are given by F(T)/T and 1/MTTF in the first case and 1/MTBF in the second case. NOTE 4 When the E/E/PE safety-related system implies only quickly repaired revealed failures then an asymptotic failure rate λas is quickly reached. It provides an estimate of the PFH. [EN 61508-4:2010 - §3.6.19]
  changes: ] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:PFH_lexConcept_3 ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]", -- "probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]" :diff_0797 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-241203:PFH_lexConcept_3 ; ordv:predicate skos:definition ; ordv:changes [
  changes: probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]
  changes: ] . :diff_0798 a :Object_addition ; ordv:entity lex_sp-defs-241203:PIS-----PASSENGER--INFORMATION--SYSTEM_lexConcept_7 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-241203:PLATEAU_lexConcept ( was in lex_sp-defs-240903: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++

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

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