++ :AB--CI--CMS--DCM--ECMT--GUI--ETA--PCS--RIM--RIS--ROC--TAF_TAP--TSI--TCR--TMS--ALLOCATION--BODY--C_lexConcept_2
++ :AB--CI--CMS--DCM--ECMT--GUI--ETA--PCS--RIM--RIS--ROC--TAF_TAP--TSI--TCR--TMS--ALLOCATION--BODY--C_lexConcept_3
++ :AUTOMATIC--CONFLICT--SOLUTION_lexConcept_2
++ :AUTOMATIC--CONFLICT--SOLUTION_lexConcept_3
++ :CAPACITY--PLAN--AND--DECISION--PROCESSING_lexConcept_2
++ :CAPACITY--PLAN--AND--DECISION--PROCESSING_lexConcept_3
++ :CAPACITY-FRIENDLY--BEHAVIOUR--MEANS_lexConcept_2
++ :FFFIS-----FORM--FIT--FUNCTIONAL--INTERFACE--SPECIFICATION_lexConcept_2
++ :FUNCTIONAL--APPORTIONMENT_lexConcept_2
++ :HUMAN--MACHINE--INTERFACE_lexConcept_3
++ :HUMAN--MACHINE--INTERFACE_lexConcept_4
++ :INCIDENT--IMPACT--MANAGEMENT_lexConcept_2
++ :INCIDENT--IMPACT--MANAGEMENT_lexConcept_3
++ :REAL-TIME--CONFLICT--DETECTION_lexConcept_2
++ :REAL-TIME--CONFLICT--DETECTION_lexConcept_3
++ :SECTIONAL--RUNTIME--CALCULATION_lexConcept_2
++ :SECTIONAL--RUNTIME--CALCULATION_lexConcept_3
++ :TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_3
++ :TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_4
++ :TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_5
++ :TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_6
++ :TOPOLOGY--MASTER--DATA--VALIDATION--AND--IMPORT_lexConcept_2
++ :TOPOLOGY--MASTER--DATA--VALIDATION--AND--IMPORT_lexConcept_3
++ :TOPOLOGY--MASTER--DATA--VALIDATION--AND--IMPORT_lexConcept_4
++ "‘accident’ means an unwanted or unintended sudden event or a specific chain of such events which have harmful consequences; accidents are divided into the following categories: collisions; derailments; level crossing accidents; accidents to persons involving rolling stock in motion; fires and others; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (11) ]"
-- "‘accident’ means an unwanted or unintended sudden event or a specific chain of such events which have harmful consequences; accidents are divided into the following categories: collisions; derailments; level crossing accidents; accidents to persons involving rolling stock in motion; fires and others; [SPPRAMSS-337 - Missing cross-reference ]"
++ "The process to verify the identity of communicating peers. (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"
-- "The process to verify the identity of communicating peers."
++ "The process to verify the identity of communicating peers."
-- "The process to verify the identity of communicating peers. (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"
++ "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]"
-- "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 - Missing cross-reference"
++ "implemented as component exchange: interaction between two behavioural physical components or logical components, through their behavioural ports"
-- "implemented as Component Exchange): interaction between 2 behavioural or logical components, through their behavioural ports"
++ "Connection point of one or more behavioural exchanges allocated to a logical or physical component, by specifying what the component can provide (output port) and what it must perform (input port) (original definition may be not that accurate)."
-- "Connection point of one or more behavioural exchanges allocated to a logical component, by specifying what the logical component can provide (output port) and what it must perform (input port) (original definition may be not that accurate)."
++ "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]"
++ "Changeability refers to the ease with which a system can be modified or customized to meet specific requirements or adapt to new circumstances. It encompasses both minor changes, such as configuration adjustments, and more substantial modifications, such as adding or removing sub-systems."
-- "Changeability refers to the ease with which a system can be modified or customized to meet specific requirements or adapt to new circumstances. It encompasses both minor changes, such as configuration adjustments, and more substantial modifications, such as adding or removing subsystems."
++ "Refers to an environment, that allows building and running Functional Applications. It comprises of hardware and software (i.e., the Runtime Environment and the necessary tools for development, testing, integration, etc.)"
-- "Refers to an environment on which Functional Applications are run, comprised of hardware and software (i.e., the runtime environment)."
++ "synonym for the Computing Environment"
-- "Refers to a specific instance of a Computing Environment on which functional applications are run, comprised of hardware and software (i.e., the runtime environment)."
++ "Confidentiality, in the context of computer systems, allows only authorised users to access protected data using specific mechanisms to ensure confidentiality and safeguard data from harmful intrusion. (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"
-- "Confidentiality, in the context of computer systems, allows only authorised users to access protected data using specific mechanisms to ensure confidentiality and safeguard data from harmful intrusion"
++ "Confidentiality, in the context of computer systems, allows only authorised users to access protected data using specific mechanisms to ensure confidentiality and safeguard data from harmful intrusion"
-- "Confidentiality, in the context of computer systems, allows only authorised users to access protected data using specific mechanisms to ensure confidentiality and safeguard data from harmful intrusion. (source: SPPRAMSS-1705 - [UNSIG Subset-146] )"
++ "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]"
-- "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]"
++ "‘common safety targets’ (CSTs) means the minimum safety levels that are to be reached by the system as a whole, and where feasible, by different parts of the Union rail system (such as the conventional rail system, the high-speed rail system, long railway tunnels or lines solely used for freight transport); SPPRAMSS-337 - [Directive (EU) 2016/798]"
-- "‘common safety targets’ (CSTs) means the minimum safety levels that are to be reached by the system as a whole, and where feasible, by different parts of the Union rail system (such as the conventional rail system, the high-speed rail system, long railway tunnels or lines solely used for freight transport); SPPRAMSS-337 - Missing cross-reference"
++ "Evolvability is the ability to easily adapt to new technologies or to extend the functionality of the CCS system without the involvement of the original supplier."
-- "Evolvability is the ability to easily adapt to new technologies or to extend the functionality of the CCS system without the involvement of the original supplier.{comment:353}{comment:429}"
++ "Exchangeability is the ability to replace a sub-system from supplier A by a subsystem from supplier B without affecting other sub-systems or the overall system/subsystem and with a reasonable integration effort and/or certification effort. Exchangeability and interchangeability are related to the physical characteristics of sub-systems wheres interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."
-- "Echangeability{comment:487} is the ability to replace a subsystem without affecting other subsystems or the overall CCS system. This replacement may require a reasonable integration effort.{comment:430}{comment:431}{comment:432}{comment:183}"
++ "able to enter or remain in a safe state in the event of a failure [SOURCE: IEC 60050-821:2017 , 821-01-10]"
-- "able to enter or remain in a safe state in the event of a failure [821-01-10 ]"
++ "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]"
-- "Manner in which failure occurs. [SOURCE: IEC 60050-192:2015, 192-03-17]"
++ "A FFFIS is the complete definition of an interface between functional or physical entities. The FFFIS includes: - FIS, - Electrical characteristics related to data, - communication protocol, - and including connector and plug. he FFFIS and accompanying documents (e.g. safety analysis) guarantees the interoperability but not the exchangeability of physical entities. [Subset-037]"
-- "A FFFIS{comment:377} is the complete definition of an interface between functional or physical entities. The FFFIS includes: - FIS,{comment:527} - Electrical characteristics related to data, - communication protocol, - and including connector and physical level. The FFFIS guarantees the interoperability but not the exchangeability of physical entities. [Subset-037]"
++ "Fit Form Function Interface Specification"
-- "Form Fit Function Interface Specification"
fault mode, effects and criticality analysis
-- "Failure modes and effects analysis (FMEA) is a systematic method of evaluating an item or process to identify the ways in which it might potentially fail, and the effects of the mode of failure upon the performance of the item or process and on the surrounding environment and personnel. Failure modes may be prioritized according to their importance. The prioritization can be based on a ranking of the severity alone, or this can be combined with other measures of importance. When failure modes are prioritized, the process is referred to as failure modes, effects and criticality analysis (FMECA)."
**++ "Failures Per Million Hours{comment:96}"
**-- "Failures per million hours{comment:96}"
++ "Failures Per Million Kilometres{comment:97}"
-- "Failures per million kilometers{comment:97}"
++ "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]"
-- "The Fault Tree Analysis (FTA) deals with the identification and investigation of conditions and influencing variables that lead to or contribute to the occurrence or potentially possible occurrence of a defined main event. For the Fault Tree Analysis, this event is usually the blocking or impairment of system performance, safety or other important operational features"
++ "A comprehensive set of self-contained software functions, assumed to be provided as one product by a single vendor. A functional application could consist of: * 1..n software functions and * a generic (deployment) configuration. Note that runtime environment is not part of the functional application, even if it is sometimes (not always) exchanged within the same step as the application is changed."
-- "A comprehensive set of self-contained software functions, assumed to be provided as one product by a single vendor. Functions within one application may have different functional safety requirements."
++ "Functional apportionment is an architectural choice supporting the ability to replace a sub-system of supplier A by a subsystem of supplier B both compliant with a given FIS."
-- "Functional apportionment{comment:1087} is the ability to replace a subsystem of supplier A by a subsystem of supplier B both compliant with a given FIS.{comment:379}"
++ "A Functional System consists of the Functional Application (see above) plus the Runtime Environment (see below) but without Hardware. The purpose to exclude HW is to address a painpoint from today regarding HW exchange.."
-- "A Functional System consists of: * 1..n Functional Applications integrated with a specific Runtime Environment, * a generic (deployment) configuration."
++ "‘fatalities and weighted serious injuries (FWSIs)’ means a measurement of the consequences of significant accidents combining fatalities and serious injuries, where 1 serious injury is considered statistically equivalent to 0,1 fatalities;{comment:98} SPPRAMSS-347 - [2009/460/EC]"
-- "‘fatalities and weighted serious injuries (FWSIs)’ means a measurement of the consequences of significant accidents combining fatalities and serious injuries, where 1 serious injury is considered statistically equivalent to 0,1 fatalities;{comment:98} SPPRAMSS-347 - Missing cross-reference"
++ "Generic Application Safety Case;SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] {comment:99},SPPRAMSS-335 - [EN 50126-2:2017]"
-- "Generic Application Safety Case; SPPRAMSS-334 - Missing cross-reference {comment:99}"
-- "Generic Product Safety Case; SPPRAMSS-334 - Missing cross-reference{comment:100}"
++ "The granularity characterizes the level of modularity of a system. The more granularity is achieved, the more the system is decomposed in many sub-systems."
-- "The granularity characterizes the level of modularity{comment:528} of a system. The more granularity is achieved, the more the system is decomposed in many subsystems{comment:1074}.{comment:37} {comment:179}"
++ "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]"
-- "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."
++ "Graphical component to interact with a user e.g., by train graph."
-- "The Human Machine Interface is a physical interface permitting an interaction between a human and the system control. The purpose of this interface is to allow effective operation by the human (ie: acknowledgement for a function) permitting to the machine (computer) to adapt simultanously the behaviour of the control command."
++ "‘incident’ means any occurrence, other than an accident or serious accident, affecting the safety of railway operations; SPPRAMSS-337 - [Directive (EU) 2016/798]"
-- "‘incident’ means any occurrence, other than an accident or serious accident, affecting the safety of railway operations; SPPRAMSS-337 - Missing cross-reference"
++ "Interchangeability is the ability to replace a subsystem from supplier A by a sub-system from supplier B without affecting other sub-systems or the overall system/subsystem and without any integration effort (lowest reasonable integration effort) and without any need for recertification. Exchangeability and interchangeability are related to the physical characteristics of sub-systems wheres interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."
-- "Interchangeability is the ability to replace a subsystem from supplier A by a subsystem from supplier B without affecting other subsystems or the overall CCS system and without any integration effort{comment:1091}.{comment:397}{comment:434}{comment:435}"
++ "With an interface the sub-systems of different suppliers are combined."
-- "Based on ISO/IEC 2382, a shared boundary between two systems or subsystems, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics."
-- "a means provided or required by components for an interaction between them or with actors"
++ "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance. [Subset-023], [IOP-Dir 2016/797] so that a train is able to run across different infrastructure networks (IMs) and that an infrastructure network is able to interact with trains of different Railway Undertakings, using systems/sub-systems from different origins. Exchangeability and interchangeability are related to the physical characteristics of sub-systems wheres interoperability is related to interactions between subsystems (e.g. also between STM and ETCS on-board there is interoperability)."
-- "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance.Reference to the TSI (European Regulation) would be good to understand the importance (double. needs to be deleted)"
++ "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance.Reference to the TSI (European Regulation) would be good to understand the importance (double. needs to be deleted)"
-- "Interoperability means the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance. [Subset-023]{comment:436}{comment:488}{comment:108}"
++ "mean active corrective maintenance time expectation of the active corrective maintenance time [SOURCE: IEC 60050-192:2015, 192-07-22]"
-- "Mean Active Corrective Maintenance Time"
++ "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]"
-- "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 - Missing cross-reference"
++ "Ability to be retained in, or restored to, a state to perform as required, under given conditions of use and maintenance [EN50126]."
-- "Ease and efficiency with which a system can be modified, repaired, or updated. It is a measure of how well a system is designed and structured to facilitate future changes, enhancements, or bug fixes. A maintainable system is typically characterized by clear and modular design and separation of concerns, which allows for easier troubleshooting, maintenance, and scalability."
++ "Mean Distance Between Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"
++ "Mean Distance Between Service Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]"
-- "Mean Distance Between Service Failures"
++ "Modularity is used in this document as a general term for devide a system/sub-system/module in sub-systems/modules."
-- "The property of a system being composed of a coherent whole of single, independent building blocks or modules."
++ "Modularity is used in this document as a general term for dividing a system/sub-system/module in sub-systems/modules."
++ "expectation of the (mean) repair time [SOURCE: IEC 60050-192:2015, 192-07-21] Note 1: MRT = FLT + FCT + FCKT according SPPRAMSS-3539 - [EN 61703: 2016]"
++ "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]"
-- "Mean operating Time Between Failures{comment:101}"
++ "Mean (operating) Time Between Service Failures Note: it is often used by customers to distinguish the failure classes with operational impact from intrinsic ones. It is not coming from a standard."
-- "Mean operating Time Between Service Failures"
-- "Mean operating Time To Failure{comment:102}"
++ "Mean time to restoration [SOURCE: SPPRAMSS-349 - [EN 50126-1:2017] Annex B.4] Note 1: MTTR = MFDT + MAD + MLD + MTD + MRT according SPPRAMSS-3539 - [EN 61703: 2016]"
++ "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 ]"
-- "The database for Notified National Rules. Has been replaced by SRD: Single Rule Database"
++ "‘national reference value (NRV)’ means a reference measure indicating, for the Member State concerned, the maximum tolerable level for a railway risk category; SPPRAMSS-347 - [2009/460/EC]"
-- "‘national reference value (NRV)’ means a reference measure indicating, for the Member State concerned, the maximum tolerable level for a railway risk category; SPPRAMSS-347 - Missing cross-reference"
. 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]
probability of dangerous failure per hour [EN 61508-4:2010]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:PORTABILITY_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Function by considering the ability for one function to be ported from one technology to another technology. The property that allows migrating a software from one concrete computing platform implementation to another concrete computing platform implementation.", -- "The property that allows migrating a software{comment:1075} from one concrete computing platform implementation to another concrete computing platform implementation." :diff_2284 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:PORTABILITY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Function by considering the ability for one function to be ported from one technology to another technology. The property that allows migrating a software from one concrete computing platform implementation to another concrete computing platform implementation.
The property that allows migrating a software{comment:1075} from one concrete computing platform implementation to another concrete computing platform implementation.
] . :diff_2285 a :Object_addition ; ordv:entity lex_sp-defs-231011:PORTABILITY_lexConcept_2 . :diff_2286 a :Object_addition ; ordv:entity lex_sp-defs-231011:PRAMS_lexConcept . :diff_2287 a :Object_addition ; ordv:entity lex_sp-defs-231011:QOS-----QUALITY--OF--SERVICE_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:RBD_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "reliability block diagram logical, graphical representation of a system showing how reliability of its sub items (represented by blocks) and combinations thereof, affect reliability of the system [SOURCE: IEC 60050-192:2015, 192-11-03]", -- "A Reliability Block Diagram (RBD) is a graphical representation of the successful operation of a system. It shows the logical connection of the (functional) components (represented by blocks), which is required for the successful operation of the system. Consequently, an RBD is equivalent to a logical equation of Boolean variables and the probability calculations primarily refer to constant values of the success/failure probabilities of a block." :diff_2288 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:RBD_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
reliability block diagram logical, graphical representation of a system showing how reliability of its sub items (represented by blocks) and combinations thereof, affect reliability of the system [SOURCE: IEC 60050-192:2015, 192-11-03]
A Reliability Block Diagram (RBD) is a graphical representation of the successful operation of a system. It shows the logical connection of the (functional) components (represented by blocks), which is required for the successful operation of the system. Consequently, an RBD is equivalent to a logical equation of Boolean variables and the probability calculations primarily refer to constant values of the success/failure probabilities of a block.
] . :diff_2289 a :Object_addition ; ordv:entity lex_sp-defs-231011:REAL-TIME--CONFLICT--DETECTION_lexConcept_2 . :diff_2290 a :Object_addition ; ordv:entity lex_sp-defs-231011:REAL-TIME--CONFLICT--DETECTION_lexConcept_3 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:RELIABILITY--%3COF--AN--ITEM%3E_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - [EN 50126-1:2017]", -- "Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - Missing cross-reference" :diff_2291 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:RELIABILITY--%3COF--AN--ITEM%3E_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - [EN 50126-1:2017]
Ability to perform as required, without failure, for a given time interval, under given conditions. Note 1 to entry: The time interval duration can be expressed in units appropriate to the item concerned, e.g. calendar time, operating cycles, distance run, etc. Note 2 to entry: Given conditions include aspects that affect reliability, such as: mode of operation, stress levels, environmental conditions, and maintenance. Note 3 to entry: Reliability can be quantified using measures defined in Section 192-05, Reliability related concepts: measures. [SOURCE: IEC 60050-192:2015, 192-01-24] Source: SPPRAMSS-349 - Missing cross-reference
] . :diff_2292 a :Object_addition ; ordv:entity lex_sp-defs-231011:REP-----REPOSITORY_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:REUSABILITY_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "The property of a sub-system to be integrated without any modification inside various CCS possibly deployed in different operation contexts.", -- "The property of a subsystem to be integrated without any modification inside various CCS possibly deployed in different operation contexts." :diff_2293 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:REUSABILITY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
The property of a sub-system to be integrated without any modification inside various CCS possibly deployed in different operation contexts.
The property of a subsystem to be integrated without any modification inside various CCS possibly deployed in different operation contexts.
] . :diff_2294 a :Object_addition ; ordv:entity lex_sp-defs-231011:REUSABILITY_lexConcept_2 . :diff_2295 a :Object_addition ; ordv:entity lex_sp-defs-231011:RISK--%3COF--A--HAZARD%3E_lexConcept . :diff_2296 a :Object_addition ; ordv:entity lex_sp-defs-231011:RISK--ANALYSIS_lexConcept . :diff_2297 a :Object_addition ; ordv:entity lex_sp-defs-231011:RISK--ASSESSMENT_lexConcept . :diff_2298 a :Object_addition ; ordv:entity lex_sp-defs-231011:RISK--EVALUATION_lexConcept . :diff_2299 a :Object_addition ; ordv:entity lex_sp-defs-231011:RTO_lexConcept . :diff_2300 a :Object_addition ; ordv:entity lex_sp-defs-231011:RU-----RAILWAY--UNDERTAKING_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:RUNTIME--ENVIRONMENT_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Refers to a software that acts as intermediary by providing a generalized abstraction of the underlying hardware and software and enabling communication and data management for distributed applications. It consists of the Runtime Layer and the Safety Layer.", -- "A software that acts as intermediary by providing a generalized abstraction of the underlying hardware and software and enabling communication and data management for distributed applications. It contains also capabiltites like security, availability, configurability." :diff_2301 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:RUNTIME--ENVIRONMENT_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Refers to a software that acts as intermediary by providing a generalized abstraction of the underlying hardware and software and enabling communication and data management for distributed applications. It consists of the Runtime Layer and the Safety Layer.
A software that acts as intermediary by providing a generalized abstraction of the underlying hardware and software and enabling communication and data management for distributed applications. It contains also capabiltites like security, availability, configurability.
] . :diff_2302 a :Object_addition ; ordv:entity lex_sp-defs-231011:RUNTIME--LAYER_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:SAFE--STATE_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "condition which continues to preserve safety [Source: IEC 60050-821, 821-12-49]", -- "condition which continues to preserve safety [821-12-49][IEC 62425:2007, 3.1.42]" :diff_2303 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:SAFE--STATE_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
condition which continues to preserve safety [Source: IEC 60050-821, 821-12-49]
condition which continues to preserve safety [821-12-49][IEC 62425:2007, 3.1.42]
] . :diff_2304 a :Object_addition ; ordv:entity lex_sp-defs-231011:SAFETY--INVARIANT_lexConcept . :diff_2305 a :Object_addition ; ordv:entity lex_sp-defs-231011:SAFETY--LAYER_lexConcept . :diff_2306 a :Object_addition ; ordv:entity lex_sp-defs-231011:SAFETY--PLATFORM--INDEPENDENCE--INTERFACE--I5_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:SASC_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Specific Application Safety Case; SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] ,SPPRAMSS-335 - [EN 50126-2:2017] {comment:104}", -- "Specific Application Safety Case; SPPRAMSS-334 - Missing cross-reference{comment:104}" :diff_2307 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:SASC_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Specific Application Safety Case; SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] ,SPPRAMSS-335 - [EN 50126-2:2017] {comment:104}
Specific Application Safety Case; SPPRAMSS-334 - Missing cross-reference{comment:104}
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:SCALABILITY_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Scalability refers to the ability of a system/sub-system to handle an increasing workload or expand its capacity without significantly impacting performance, efficiency, or cost.", -- "Scalability refers to the ability of a system/subsystem to handle an increasing workload or expand its capacity without significantly{comment:1088} impacting performance, efficiency, or cost." :diff_2308 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:SCALABILITY_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Scalability refers to the ability of a system/sub-system to handle an increasing workload or expand its capacity without significantly impacting performance, efficiency, or cost.
Scalability refers to the ability of a system/subsystem to handle an increasing workload or expand its capacity without significantly{comment:1088} impacting performance, efficiency, or cost.
] . :diff_2309 a :Object_addition ; ordv:entity lex_sp-defs-231011:SCALABILITY_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:SCENARIO_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "dynamic interaction between elements like the system and the actors, components or between functions", -- "dynamic interaction between elements: the system and the actors, or between functions" :diff_2310 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:SCENARIO_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
dynamic interaction between elements like the system and the actors, components or between functions
dynamic interaction between elements: the system and the actors, or between functions
] . :diff_2311 a :Object_addition ; ordv:entity lex_sp-defs-231011:SCV-OB-----SIGNAL--CONVERTER-ON-BOARD_lexConcept . :diff_2312 a :Object_addition ; ordv:entity lex_sp-defs-231011:SECTIONAL--RUNTIME--CALCULATION_lexConcept_2 . :diff_2313 a :Object_addition ; ordv:entity lex_sp-defs-231011:SECTIONAL--RUNTIME--CALCULATION_lexConcept_3 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:SERA-CCS_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "SERA-CCS{comment:3} Single European Railway Area - Command Control and Signaling: For the railway sector, EU policy focuses on the main goal of establishing a single European railway area, an EU-wide system of railway networks which would allow the expansion of the rail sector based on * competition, * technical harmonization and * joint development of cross-border connections [see Building the single European railway area]. To this end, the EU aims to: * open and restructure the rail market * increase competitiveness by creating a level playing field for companies * develop infrastructure to ensure interoperability * improve efficiency in infrastructure use and safety * ensure fair prices for consumers{comment:5} SERA-CCS is understood to consist of those SERA objectives which are relevant for CCS (technical/operational target). It is defined by the following capabilities: * Provides Independence between Infrastructure Managers (IM) and Railway Undertakings (RU) or Vehicle Owners (VO): * No track access restriction or extra costs for a compliant RU/VO fleet/services accessing a given IM infrastructure compliant with SERA-CCS. * Non discriminatory access to IM services and capacity allocation across SERA-CCS IMs for compliant RU/VO fleet/services. * Ensures interoperability, which is the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance across different infrastructure networks (IMs) and the ability that an infrastructure network is able to interact with trains of different RUs/VOs. * Ensures Harmonized Operations, based on: * Radio-based CAB Signalling, * Automatic Train{comment:1} Operation (ATO), * Single licensing for Drivers and Signalers across SERA-CCS. * Provides Backwards Compatibility: * Compatibility is considered to be achieved for a particular combination of on-board and trackside when the on-board is able to run a normal service on that trackside. The expression “train is running a normal service” shall be understood as “a train not penalized because of a reduction of performance or safety”. * {comment:2}The full functionality of any old version shall always be available in any new version of SERA-CCS * Enables significantly lower life cycle costs having easy Upgradability, Scaleability, Adaptability and Changeability of Hardware and Software components/systems/subsystems * Consists of a Modular Architecture, both trackside and onboard: * Trackside and Onboard architecture are designed to allow for separate replacements/upgrades of individual sub-systems with reasonable integration effort. * Enables Interchangeability of hardware and software components/systems/subsystems across suppliers * The modular architecture shall also allow for situations where the replacement/upgrade of individual components from different suppliers is needed. {comment:4}", -- "Single European Railway Area - Command Control and Signaling: For the railway sector, EU policy focuses on the main goal of establishing a single European railway area, an EU-wide system of railway networks which would allow the expansion of the rail sector based on * competition, * technical harmonization and * joint development of cross-border connections [see Building the single European railway area]. To this end, the EU aims to: * open and restructure the rail market * increase competitiveness by creating a level playing field for companies * develop infrastructure to ensure interoperability * improve efficiency in infrastructure use and safety * ensure fair prices for consumers SERA-CCS it is understood be parts of SERA objectives which are relevant for CCS. It is defined by the following capabilities. * Provides Independence between Infrastructure Managers (IM) and Railway Undertakings (RU): * No track access restriction or extra costs for a compliant RU fleet/services accessing a given IM infrastructure included in the SERA-CCS. * Non discriminatory access to IM services and capacity allocation across SERA-CCS IMs for compliant RU fleet/services. * Enables Interoperability which is the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance across different infrastructure networks (IMs) and the ability that an infrastructure network is able to interact with trains of different RUs * Provides Harmonized Operation: * Radio-based operation, CAB Signalling, and ATO (except on degrades situations?). * Single licensing for Drivers and Signalers across SERA-CCS. * Provides Backward Compatibility: * Compatibility is considered to be achieved for a particular combination of on-board and trackside when the on-board is able to run a normal service on that trackside. The expression “train is running a normal service” shall be understood as “a train not penalized because of a reduction of performance or safety”. * Enables cost effective Upgradability, Adaptability, Changeability and Upgradeability of Hardware and Software components/systems/subsystems * Consist of a Modular Architecture, both trackside and onboard: * Trackside and Onboard architecture are designed to allow separate replacement/upgrade of individual sub-systems with reasonable integration effort. * Enables Interchangeability of hardware and software components/systems/subsystems across suppliers * The modular architecture shall also allow where required the replacement/upgrade of individual components from different suppliers." :diff_2314 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:SERA-CCS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
SERA-CCS{comment:3} Single European Railway Area - Command Control and Signaling: For the railway sector, EU policy focuses on the main goal of establishing a single European railway area, an EU-wide system of railway networks which would allow the expansion of the rail sector based on * competition, * technical harmonization and * joint development of cross-border connections [see Building the single European railway area]. To this end, the EU aims to: * open and restructure the rail market * increase competitiveness by creating a level playing field for companies * develop infrastructure to ensure interoperability * improve efficiency in infrastructure use and safety * ensure fair prices for consumers{comment:5} SERA-CCS is understood to consist of those SERA objectives which are relevant for CCS (technical/operational target). It is defined by the following capabilities: * Provides Independence between Infrastructure Managers (IM) and Railway Undertakings (RU) or Vehicle Owners (VO): * No track access restriction or extra costs for a compliant RU/VO fleet/services accessing a given IM infrastructure compliant with SERA-CCS. * Non discriminatory access to IM services and capacity allocation across SERA-CCS IMs for compliant RU/VO fleet/services. * Ensures interoperability, which is the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance across different infrastructure networks (IMs) and the ability that an infrastructure network is able to interact with trains of different RUs/VOs. * Ensures Harmonized Operations, based on: * Radio-based CAB Signalling, * Automatic Train{comment:1} Operation (ATO), * Single licensing for Drivers and Signalers across SERA-CCS. * Provides Backwards Compatibility: * Compatibility is considered to be achieved for a particular combination of on-board and trackside when the on-board is able to run a normal service on that trackside. The expression “train is running a normal service” shall be understood as “a train not penalized because of a reduction of performance or safety”. * {comment:2}The full functionality of any old version shall always be available in any new version of SERA-CCS * Enables significantly lower life cycle costs having easy Upgradability, Scaleability, Adaptability and Changeability of Hardware and Software components/systems/subsystems * Consists of a Modular Architecture, both trackside and onboard: * Trackside and Onboard architecture are designed to allow for separate replacements/upgrades of individual sub-systems with reasonable integration effort. * Enables Interchangeability of hardware and software components/systems/subsystems across suppliers * The modular architecture shall also allow for situations where the replacement/upgrade of individual components from different suppliers is needed. {comment:4}
Single European Railway Area - Command Control and Signaling: For the railway sector, EU policy focuses on the main goal of establishing a single European railway area, an EU-wide system of railway networks which would allow the expansion of the rail sector based on * competition, * technical harmonization and * joint development of cross-border connections [see Building the single European railway area]. To this end, the EU aims to: * open and restructure the rail market * increase competitiveness by creating a level playing field for companies * develop infrastructure to ensure interoperability * improve efficiency in infrastructure use and safety * ensure fair prices for consumers SERA-CCS it is understood be parts of SERA objectives which are relevant for CCS. It is defined by the following capabilities. * Provides Independence between Infrastructure Managers (IM) and Railway Undertakings (RU): * No track access restriction or extra costs for a compliant RU fleet/services accessing a given IM infrastructure included in the SERA-CCS. * Non discriminatory access to IM services and capacity allocation across SERA-CCS IMs for compliant RU fleet/services. * Enables Interoperability which is the ability to allow the safe and uninterrupted movement of trains that accomplish the specified levels of performance across different infrastructure networks (IMs) and the ability that an infrastructure network is able to interact with trains of different RUs * Provides Harmonized Operation: * Radio-based operation, CAB Signalling, and ATO (except on degrades situations?). * Single licensing for Drivers and Signalers across SERA-CCS. * Provides Backward Compatibility: * Compatibility is considered to be achieved for a particular combination of on-board and trackside when the on-board is able to run a normal service on that trackside. The expression “train is running a normal service” shall be understood as “a train not penalized because of a reduction of performance or safety”. * Enables cost effective Upgradability, Adaptability, Changeability and Upgradeability of Hardware and Software components/systems/subsystems * Consist of a Modular Architecture, both trackside and onboard: * Trackside and Onboard architecture are designed to allow separate replacement/upgrade of individual sub-systems with reasonable integration effort. * Enables Interchangeability of hardware and software components/systems/subsystems across suppliers * The modular architecture shall also allow where required the replacement/upgrade of individual components from different suppliers.
] . :diff_2315 a :Object_addition ; ordv:entity lex_sp-defs-231011:SERIOUS--ACCIDENT_lexConcept . :diff_2316 a :Object_addition ; ordv:entity lex_sp-defs-231011:SIL-----SAFETY--INTERITY--LEVEL_lexConcept . :diff_2317 a :Object_addition ; ordv:entity lex_sp-defs-231011:SP-----SYSTEM--PILLAR_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:SRD_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Single Rules Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]", -- "To be filled by Frédéric" :diff_2318 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:SRD_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Single Rules Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:SRS_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "System Requirement Specifications", -- "System Requirements Specification" :diff_2319 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:SRS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
] . :diff_2320 a :Object_addition ; ordv:entity lex_sp-defs-231011:SRS_lexConcept_2 . :diff_2321 a :Object_addition ; ordv:entity lex_sp-defs-231011:SSI_lexConcept . :diff_2322 a :Object_addition ; ordv:entity lex_sp-defs-231011:SSI_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:STAKEHOLDER--NEEDS_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "These needs are taken into account for the definition of the System of interest. Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree, - Requirements proposed by any party and approved in the SP decision process according to SP governance.", -- "Needs to be taken into account for the definition of the System of interest Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree - Requirements proposed by any party and approved in the SP decision process according to SP governance" :diff_2323 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:STAKEHOLDER--NEEDS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
These needs are taken into account for the definition of the System of interest. Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree, - Requirements proposed by any party and approved in the SP decision process according to SP governance.
Needs to be taken into account for the definition of the System of interest Note: In the Europe's Rail context, stakeholder needs are defined by valid input channels, which are - Decided SP Common Business Objectives as the top-level of the requirement tree - Requirements proposed by any party and approved in the SP decision process according to SP governance
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:STAKEHOLDER_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Someone who is entitled to express needs for the system of interest. Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers.", -- "Someone who is entitled to express needs for the system of interest Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers" :diff_2324 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:STAKEHOLDER_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Someone who is entitled to express needs for the system of interest. Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers.
Someone who is entitled to express needs for the system of interest Note: In the Europe's Rail context, the list of stakeholders is defined by the members of the System Pillar Steering group and their delegates or speakers
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:STPA_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "System Theoretic Process Analysis [Source: J3187:202305]", -- "A Systems-Theoretic Process Analysis (STPA) is a hazard analysis technique based on control and system theory rather than the reliability theory underlying most existing hazard analysis techniques with the same goals as any hazard analysis technique, that is, to accumulate information about how hazards can occur." :diff_2325 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:STPA_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
System Theoretic Process Analysis [Source: J3187:202305]
A Systems-Theoretic Process Analysis (STPA) is a hazard analysis technique based on control and system theory rather than the reliability theory underlying most existing hazard analysis techniques with the same goals as any hazard analysis technique, that is, to accumulate information about how hazards can occur.
] . :diff_2326 a :Object_addition ; ordv:entity lex_sp-defs-231011:SUB-SYSTEM--SOMETIMES--CALLED--_BUILDING--BLOCK_lexConcept . :diff_2327 a :Object_addition ; ordv:entity lex_sp-defs-231011:SUB-SYSTEM--SOMETIMES--CALLED--_BUILDING--BLOCK_lexConcept_2 . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:SUC_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "System under Consideration [SOURCE: SPPRAMSS-4697 - [IEC 62443-3-2:2020]]", -- "System under Consideration" :diff_2328 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:SUC_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
System under Consideration [SOURCE: SPPRAMSS-4697 - [IEC 62443-3-2:2020]]
] . :diff_2329 a :Object_addition ; ordv:entity lex_sp-defs-231011:TAP-----TELEMATICS--APPLICATION--FOR--PASSENGER--SERVICE_lexConcept . :diff_2330 a :Object_addition ; ordv:entity lex_sp-defs-231011:TCMS-----TRAIN--CONTROL--AND--MANAGEMENT--SYSTEM_lexConcept . :diff_2331 a :Object_addition ; ordv:entity lex_sp-defs-231011:TDS-----TRAIN--DISPLAY--SYSTEM_lexConcept . :diff_2332 a :Object_addition ; ordv:entity lex_sp-defs-231011:TECHNICAL--DELAY_lexConcept . :diff_2333 a :Object_addition ; ordv:entity lex_sp-defs-231011:TEMPORARY--SHUNTING--AREA--TSHA--OR-DEF-160--TEMPORARY--SHUNTING--AREA--OR-DEF-161--DEF_lexConcept . :diff_2334 a :Object_addition ; ordv:entity lex_sp-defs-231011:TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_3 . :diff_2335 a :Object_addition ; ordv:entity lex_sp-defs-231011:TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_4 . :diff_2336 a :Object_addition ; ordv:entity lex_sp-defs-231011:TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_5 . :diff_2337 a :Object_addition ; ordv:entity lex_sp-defs-231011:TERM--STATUS--DESCRIPTION--OPERATING--STATE--DRAFT--THE--OPERATING--STATE--DESCRIBES--THE_lexConcept_6 . :diff_2338 a :Object_addition ; ordv:entity lex_sp-defs-231011:TESTABILITY_lexConcept . :diff_2339 a :Object_addition ; ordv:entity lex_sp-defs-231011:TESTABILITY_lexConcept_2 . :diff_2340 a :Object_addition ; ordv:entity lex_sp-defs-231011:TIMS-----TRAIN--INTEGRITY_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:TLS_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Transport Layer Security (source: SPPRAMSS-1705 - [UNSIG Subset-146] )", -- "Transport Layer Security" :diff_2341 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:TLS_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
Transport Layer Security (source: SPPRAMSS-1705 - [UNSIG Subset-146] )
] . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:TLS_lexConcept_2 ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "Transport Layer Security", -- "Transport Layer Security (source: SPPRAMSS-1705 - [UNSIG Subset-146] )" :diff_2342 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:TLS_lexConcept_2 ; ordv:predicate skos:definition ; ordv:changes [
] . :diff_2343 a :Object_addition ; ordv:entity lex_sp-defs-231011:TMS--DAILY--TOPOLOGY_lexConcept_2 . :diff_2344 a :Object_addition ; ordv:entity lex_sp-defs-231011:TMS--DAILY--TOPOLOGY_lexConcept_3 . :diff_2345 a :Object_addition ; ordv:entity lex_sp-defs-231011:TOPOLOGY--MASTER--DATA--VALIDATION--AND--IMPORT_lexConcept_2 . :diff_2346 a :Object_addition ; ordv:entity lex_sp-defs-231011:TOPOLOGY--MASTER--DATA--VALIDATION--AND--IMPORT_lexConcept_3 . :diff_2347 a :Object_addition ; ordv:entity lex_sp-defs-231011:TOPOLOGY--MASTER--DATA--VALIDATION--AND--IMPORT_lexConcept_4 . :diff_2348 a :Object_addition ; ordv:entity lex_sp-defs-231011:TRACK--FOOTPRINT_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:TRADE-SPACE--FACTOR_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++
:diff_2349 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:TRADE-SPACE--FACTOR_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
"trade-space factors" represent the different factors/characteristics defining the solution space/alternatives. From this trade-off playspace containing set of good/acceptable solutions, we will need to identify the optimal one (i.e. "best" trade-off).
"trade-space factors" represent the different factors/characteristics defining the solution space/alternatives. From this tradeoff playspace containing set of good/acceptable solutions, we will need to identify the optimal one (i.e. "best" tradeoff).
] . :diff_2350 a :Object_addition ; ordv:entity lex_sp-defs-231011:TRD-----TRAIN--DATA_lexConcept . ## # # == ontorail:ontolex:LexicalConcept lex_sp-defs-231011:TSI_lexConcept ( was in lex_sp-defs-230908: ) # == rdf:type => ontolex:LexicalConcept # == skos:definition => ++ "‘technical specification for interoperability’ (TSI) means a specification adopted in accordance with Directive (EU) 2016/797 by which each subsystem or part of a subsystem is covered in order to meet the essential requirements and ensure the interoperability of the Union rail system; SPPRAMSS-337 - [Directive (EU) 2016/798]", -- "‘technical specification for interoperability’ (TSI) means a specification adopted in accordance with Directive (EU) 2016/797 by which each subsystem or part of a subsystem is covered in order to meet the essential requirements and ensure the interoperability of the Union rail system; SPPRAMSS-337 - Missing cross-reference" :diff_2351 a :Object_attribute_changedValues ; ordv:entity :entity lex_sp-defs-231011:TSI_lexConcept ; ordv:predicate skos:definition ; ordv:changes [
‘technical specification for interoperability’ (TSI) means a specification adopted in accordance with Directive (EU) 2016/797 by which each subsystem or part of a subsystem is covered in order to meet the essential requirements and ensure the interoperability of the Union rail system; SPPRAMSS-337 - [Directive (EU) 2016/798]
‘technical specification for interoperability’ (TSI) means a specification adopted in accordance with Directive (EU) 2016/797 by which each subsystem or part of a subsystem is covered in order to meet the essential requirements and ensure the interoperability of the Union rail system; SPPRAMSS-337 - Missing cross-reference