This is an example lexicon
Ceci est un exemple de lexique
1D reference frame
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.
3D reference frame
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.
ESC
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(s). (4) The ESC Interoperability Constituent Statement shall include the reference to the NoBo assessment Report according to 6.2.4.3 (ETCS and radio system compatibility checks for Interoperability Constituent). The ESC of the specific on-board CCS subsystem with respect to one or more ESC Type(s) is laid down in the ESC Statement. The template provided in Appendix C.1 or C.5 shall be used. At subsystem level, the ESC Statement shall also include the summary of the ESC Check Report and shall demonstrate the fulfilment of the required ESC checks (for each ESC Type included in the Statement) published in the Agency ESC/RSC technical document in addition to already provided ESC interoperability constituent statements. The ESC Statement shall also include the full list of ESC Interoperability Constituent statements taken into account in the assessment (if any), the conditions (if any) with respect to the different ESC Types and the NoBo Assessment Report according to 6.3.3.1 (ETCS and radio system compatibility checks).
4.2.17.1. ETCS System Compatibility
Absolute position reference frame
Train front end position expressed with absolute geo coordinate system using a 3 D reference frame (e.g., Long, Lat, Alt, WGS84, ETRS89…).
accident
‘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) ]
Accuracy
The difference between true and estimated values with a defined probability.
Adaptability
Adaptability refers to the ability to adjust a system in response to changes in its environment or changes of requirements. It involves a broader concept of flexibility and resilience, encompassing not only modifications to the system itself but also its capacity to accommodate evolving needs or external factors. An adaptable system can respond effectively to new technologies, market demands, user expectations, or regulatory changes.
Adapted product
In System Pillar context, an "adapted" product uses some of the SP compliant specifications, but not all. Its system behavior is not completely compliant to System Pillar specification. The adaption is done, to make current national products future ready (later connection or upgrade to SP compliant systems)
ADCARP something
Add, Change, Delete, Approve, Release, Decide and Publish
Add Train
Add a completely new train journey or add a new train journey to an existing train journey
ADM - Automatic Driving Module
ASTP
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
Advanced Safe Train Positioning (ASTP)
Advanced Safe Train Positioning
(AFARP) - As far as reasonably practicable
"As far as reasonably practicable" means that the action shall be undertaken until either the requirement is met, or the actors involved in the definition, review and approval of the work item conclude that further effort to resolve open issues is unlikely to bring an equivalent measurable benefit to the overall solution.
Allocation Area
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).
Analysis
Qualitative assessment of requirements, issues, etc.
Angular rate
It is the angular speed of the rotational angles of the attitude.
Answer.
Answers a Question. Questions and answers are used for Q&A or FAQ documents. If you have an open question in your project, use "Issue"
ASFA
Anuncio de Señales y Frenado Automático (ASFA; "Announcement of Signals and Automatic Braking"); Is an Automatic Protetion System which is widely used on the Spanish rail network. It consists of a mechanism that stops a train if the driver does not properly heed signals.
Anuncio de Señales y Frenado Automático
APM - Automatic Processing Module
Appliation (along EN 50126)
Describes the sum of: The system, its needed environment and its form of usage (other systems, processes), and the system life-cycle.
Application Condition
Application conditions are precise requirements about the environment and use of the target system, e.g. skills of maintenance people that need{comment:24} to be trained or requirements about the physical environment. ("exported constraint, relevant for users"). They include physical needs, skill levels of maintenance personal, temperatures of server rooms, engineering rules, etc. The safety-related applications (SRAC) are specific application conditions relevant to safety. More details to SRAC and RAM-related ones (RAM RAC) are to be considered as well at a later stage.{comment:33}
An Application Condition is a requirement for the environment of a system in its application. Concretely these can be for example requirements concerning the skills of the users, temperatures in a data center, or maintenance processes that need to be established.
Application Configuration Data
The Application configuration refers to use case-specific data for the Consuming Systems for a specific application. These can be detailed as Infrastructure-related data i.e., Track edges, Track geometry, Track properties, Segment Profiles, etc. and Vehicle-related data i.e., Max acceleration, Traction efforts, Rolling coefficients, etc.
Application Configuration.
Set of combined Features (which are child workitems).
AEE
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.
The Application Execution Environment refers to the combination of Runtime Environment and Safety Environment.
Application Execution Environment
Application Guideline
Defining procedural requirements for Railway Operators
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.
The Application Layer contains Functional Applications that constitute Functional Systems.
Application Layer
ALM
Application Lifecycle Management
Application
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.
ARCADIA
Arc{comment:3}hitecture Analysis & Design Integrated Approach (ARCADIA) is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities. A short description of the method can be found here. Main resources about ARCADIA can be found on the official website: https://www.eclipse.org/capella/arcadia-reference.html ARCADIA uses four layers to develop and model a system: * Operational Analysis - what the users of the system need to accomplish * System Analysis{comment:4} - what the system has to accomplish for the user * Logical Architecture - How the system will work to fulfil expectations * Physical Architecture - How the system will be developed and built (image: 3-1-screenshot-20230107-163323.png) Figure {caption:Figure} Figure Four perspectives of Arcadia [Arcadia web : https://www.eclipse.org/capella/arcadia.html ]
(Arc)hitecture (A)nalysis and (D)esign (I)ntegrated (A)pproach
Architectural Concept
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 the inputs to a system function are converted to the outputs. This step does not yet define an architecture and does not refer to technical solution concepts like ETCS or ATO. As the system under consideration is still a blackbox, the logical architecture still leaves the question open, what subsystem structure is the to be used (e.g. very modular subsystems vs. bigger subsystems or combined HW/SW subsystems vs. SW-modules on a common platform). This step is performed once, before the subsystem architecture shall be derived. * Physical architecture (PA): design the final set of tenderable subsystems and integrate all necessary non-functional requirements. This step integrates all considerations on the intended structure of subsystems and interfaces (down to FFFIS) as well as all open technical aspects into a consistent architectural definition.
ARCT
Architecture and Release Coordination Team
ATAM
Architecture Tradeoff Analysis Method{comment:4}
Architecture Tradeoff Analysis Method
AWC
Architecture Working Circle
Area Controller
Area Controller The Area Controller manages areas for the View.
AoC
The Area of Control is the topologically limited extent and the infrastructural Trackside Assets in this geographical extent. The term is used here for defining the technical and operational responsibility of a Trackside Subsystem.
Area of Control
Area of Use
Arrival Datetime Change
Change in the arrival time of a train in a station, either by arriving earlier or later than planned
AFARP
Denote that an action shall be done until the cost to do so does not justify the benefit of doing it.
As far as reasonably practicable
AsBo
From DIRECTIVE (EU) 2016/797 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 May 2016 on the interoperability of the rail system within the European Union: (42) ‘conformity assessment body’ means a body that has been notified or designated to be responsible for conformity assessment activities, including calibration, testing, certification and inspection; a conformity assessment body is classified as a ‘notified body’ following notification by a Member State; a conformity assessment body is classified as a ‘designated body’ following designation by a Member State;
Assessment Body
Assessment.
Quantitative assessment of requirements, issues, etc.
ATO - Automatic Train Operation
ATO Automatic Train Operation AoC Area of Control CCS Control Command and Signal...
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
Attitude reference frame
It describes the orientation of a rigid body with respect to a fixed coordinate system by determining the rotational angles, yaw-pitch-roll. On the plan defined by the carriage floor, the roll axis is the carriage longitudinal axis oriented toward the train front end, pitch axis is the orthogonal to the carriage longitudinal axis oriented to the left, yaw axis is the orthogonal to the carriage floor oriented up. Angles are absolute values using as references the horizontal plan to determine the pitch and roll angles, the direction to the north to determine the yaw.
Attribute
Attribute is an inherent property or characteristic of an entity that can be distinguished quantitatively or qualitatively by human or automated means
Authentication
The process to verify the identity of communicating peers. (source: SPPRAMSS-1705 - [UNISIG Subset-146] )
Authorised User
A system user with write access, who can configure the system
Automatic Conflict Solution
Solves conflicts based on algorithms. May use optimisation functions.
ASO
Automatic Shunting Operation
ATO
Automatic Train Operation
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
availability, <of a product>
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]
Availability
Availability: property of being accessible and usable on demand by an authorized entity (source: ISO 27000-2018 )
Backwards Compatibility
Backwards compatibility is a design or software feature that allows a product, system, or software application to remain compatible with earlier versions or older hardware. In the context of software, it means that a newer version of a program can still run and interact with files, data, or systems that were created using previous versions of that software. This ensures that users can upgrade to the latest version without losing access to their existing data or needing to make significant changes to their workflows. It's a valuable feature that enhances user convenience and reduces disruptions when technology evolves. Backward compatibility for hardware, also known as "hardware backward compatibility," refers to the ability of a newer piece of hardware to work seamlessly with older hardware components or peripherals, such as connectors, interfaces, or accessories. In the context of hardware, backward compatibility typically ensures that the new hardware can accommodate and interact with devices or components that were designed for older hardware specifications. Hardware backward compatibility is important for user convenience, cost savings, and reducing the need for immediate updates to all associated hardware components when a single component is upgraded. It often requires the inclusion of older ports or connectors on newer hardware or the development of adapters or converters to bridge the compatibility gap between old and new technologies.
Baseline
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
basic ASTP
Basic Advanced Safe Train Positioning (Basic ASTP) is a new CCS-OB interoperability constituent providing Odometry functionality with to be defined performance and availability targets. Basic ASTP shall perform this function primarily for ERTMS/ETCS on-board equipment via a standardised FFFIS compliant interface, but could be used for other applications on the train.
basic Advanced Safe Train Positioning (basic ASTP)
BIL
Integrity attribute for safety-related functions with a TFFR higher than (less demanding) 10−5.h−1 or for non-safety-related functions.
Basic Integrity Level
The Basic Integrity Platform Independence Interface I4 (Interface 4) is used to perform a basic integrity platform independence with the applications. In other words, this API is an interface limited to non-safety functionalities between runtime environment and applications.
Basic Integrity Platform Independence Interface
Biometric Reader
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.
Black Box View
The black box view hides structural decomposition of a system. In black box view, it cannot be differentiated between systems that are further refined into a system of systems or into subsystems.
Building Block Configuration
A BuildingBlockConfiguration (BBC) is a node on a layer within the configuration dependency tree. It must be uniquely identifiable within the system as bbcId. On the lower levels of the dependency trees the bbcIds are assigned by the supplier - for example by imprinting the structure of configurable items into a sourceable physical unit. A BBC may contain a configurationFile artifact and dependencies to other BBCs. One Building BlockConfiguration (BBC) has exactly one configuration.json file (and an additional configurationSafe.json if it is a safe BBC). BBCs that itself have no further dependencies in their configuration.json file are the Lowest Updatable Units (LUU - can be updated on its own). BBCs that are updatable must provide a corresponding configurationFile (payload). BBCs that are updatable need an endpoint described in the "configuration.json" file. That BBC endpoint can be accessed using a protocol capable of file transfer (e.g. opc ua).
Building Block Manifest
The Building Block Manifest is a document that describes a Building Block configuration. For more details see the description for SPT2TS-123463 - BuildingBlockConfiguration "configuration.json" document .
{comment:33} A building block is a sourceable unit of the CCS system (hardware and/or software), having standardised functionality, standardised performance (RAM), standardised safety (including Tolerable Functional Failure Rate [TFFR], Safety Integrity Level [SIL] and Safety Related Application Conditions [SRAC]), standardised security and standardised interfaces towards other building blocks and/or external systems. A building block can also be defined as a standardised module. {comment:158}
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.
Building block
BuildingBlockConfiguration "configuration.json" document
The BuildingBlockConfiguration configuration.json document describes a BuildingBlock Configuration. In the section <dependencies> the file lists all BuildingBlockConfiguration configuration files the BuildingBlockConfiguration depends on. The BuildingBlockConfiguration "configuration.json" document references other BBC configuration.json documents recursively. This forms a dependency tree that is resolved recursively until the BBC "configuration.json" has no further dependencies. These are the LUU - Lowest updatable units. The LUUs link a configurationFile (payload). As an example there may be different BBC "configuration.json" documents for a specific BuildingBlock: A generic BuildingBlockConfiguration including a firmware as "generic definition" (before integration in its environment) that has been compiled by the BuildingBlock supplier. There might be another BuildingBlockConfiguration from the integrator that includes the parametrization of the generic product and depends on the correct firmware BBC. The BBC configuration is defined within a "configuration.json" document that is validated by the configuration.schema.json.
Button
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.
Buzzer
Buzzer Electrical device that makes a buzzing noise and is used to provide an audible warning.
C-DAS - Connected Driver Advisory System
Capability Meaning
For the purposes of this document, a capability, in the framework of CMS, is considered as an interaction between processes, stakeholders and (IT) tools as illustrated in figure 5:
Capability
The ability of a system in performing a specific functionality
CMS
Capacity Management system
In the railway context, capacity management refers to the strategic planning and operational control measures implemented to effectively manage the available resources and infrastructure of a railway system in order to meet the demand for transportation services. It involves assessing, optimizing, and maximizing the capacity of various components within the railway system, such as tracks, stations, trains, and associated facilities.
Capacity Management
Capacity Planning
Capacity Planning is an instrument to determining the total theoretically available capacity supply (max. number of journeys per direction) and compare it to demand. Capacity can be requested from long term to short term (ad hoc slot ordering). Capacity planning supports the planning along all-time horizons (strategic to short term).
Capacity Plan
The capacity plan comprises any planned capacity usage (traffic and construction works) at any point in time during the planning period. The aim is a consistent and conflict free capacity plan.
Capacity Production
Capacity production is the implementation of the operational plan. Capacity production begins when the train starts its scheduled mission and ends with when it ends.
Capacity Restriction
Capacity restriction is a temporary full or partial unavailability of network infrastructure due to construction works, maintenance, inspection works or due to environmental influences and disruptions.
Capacity waste means:
* Paths are ordered without proper need, allocated and modified after allocation so that other ROCs cannot sensibly make use of them * Allocated paths are changed by RIMs after allocation due to the impact of TCRs by RIMs (same one allocating the path or another one on a different network) * An unnecessary number of paths are not allocated or are cancelled by RIMs due to poor alignment of several planned TCRs * Paths are not allocated or are cancelled by RIMs due to planned TCRs at times when little or no work is actually being carried out * Paths are not allocated or are cancelled by RIMs due to planned TCRs that were cancelled * Paths are not usable (or re-usable) due to the changes being communicated too late (i.e., due to paths being cancelled too late, TCRs cancelled, etc.)
Capacity-friendly behaviour means:
* A path confirmed is a commitment from both ROC and RIM, which should be kept after it has been allocated and accepted * Ordering capacity only when the market need for it need has been confirmed (ROC) * Give back the capacity as soon the market need changes, or other external requirements are known (ROC) * Defining the capacity for TCRs in a way that no more capacity than necessary is blocked – in dialogue between ROCs and RIMs * Planning the majority of TCRs and their impact to paths before path allocation (RIM) * Reducing TCRs in operational timetable to the minimum and planning their impact to paths/trains as early as possible (RIM) * Stabilising TCR planning - avoiding TCR cancellations that lead to a double loss of business, as well as massive re-planning of scheduled TCRs, which results in high efforts in operational planning (RIM)
Capacity
The total overall capability of the infrastructure that can be utilised by traffic or by maintenance. Capacity may apply to specific geographic sectors like stations or lines. Capacity usage must be requested, which results in capacity demand.
C2P
The Capella2Polarion bridge is used to synchronise Capella model elements with Polarion work items. These work items have the prefix C2P in the name to indicate the specific purpose. More information can be found in here: SPPR-7501 - Capella to Polarion synchronization: list of cloned elements and links.
Capella2Polarion
CAPEX
Capital Expenditures or Capital Expenses
Capital Expenditures
Carriage front end
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.
Categorisation of national migration phases for a single country
| LEGACY phase | ADAPTION phase | HARMONISATION phase | SERA CCS phase Description | No SP specification used in national propducts | Some SP specifications are used in national bespoke products, which show partly SPRA compliant behavior. This is especially done to connect them to future harmonized products, or to upgrade them to later harmonized products. | First fully harmonized products are available in Europe, and are procured "as is", together with the introduction of the harmonized operational processes that fit to them. Then more and more harmonized products are available. First full pilot lines with harmonized products are built. | A "core" of the harmonized architecture is defined and mandatory (by law, or because national bespoke solutions are not any more available in the market or not affordable for the architecture core). Railway Tasks | Define national requirements for bespoke products and installations. Optimisation of national products in "small steps". | Organize, negotiate and execute the integration of harmonized interfaces into national products | Buy harmonized products from the shelf for new lines, and procure also their connection to installed legacy systems. Introduce harmonized processes on the new lines. Perhaps upgrade old lines (optionally). | Buy all core products of the harmonized architecture from the shelf. And some preferred optional harmonized products (e.g. Tools). System Pillar Support | none | Provide first stable harmonized interface specifications and system requirement specifications | Provide and maintain operational rulebooks and system specification, (as recommendations, along STIP process). | Provide and maintain operational rulebooks and system specification, (as recommendations, along STIP process). Supplier Support | Provide and support national bespoke products installation projects and maintenance | Adapt national bespoke products plattforms early and perhaps partly to first harmonized SP specifications | Provide harmonized products. | Provide all harmonized products of the core architecture, and preferred optional harmonized products. Example Start-End year of a phase (in X years from now) | 0-15y | 0-15y | 8-40y | 20y-... Comments | | The business case for adaption is different in each situation, and needs national analysis and decision. If many adaptions are asked on national basis at the same time, the limited availability of development capacity for national solutions will lead to a quite restrictive prioritisation. | The availability of harmonized products depends on their development challenge, active market demand and supplier strategies. EULynx OC are available today. Harmonized ATO GoA4 solution for broad network wide usage in mainline might take 15 years and specifically built trains. | Solutions should convince and by this convince the market. Making them mandatory early creates large risks. But it should be clear what gets mandatory in a second step.
CBM
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]
CCF
Common Cause Failures: failures of multiple items, which would otherwise be considered independent of one another, resulting from a single cause Note 1 to entry: Common cause failures can also be "common mode failures" (IEV 192-03-19). Note 2 to entry: The potential for common cause failures reduces the effectiveness of system redundancy. [SOURCE: IEC 60050-192:2015, 192-03-18]
CCS - Control-Command and Signalling
CCS Deployment
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.
CCS Evolution Path
A (CCS) Evolution Path, is a standardised upgrade process (extensions, enhancements, and error corrections) of the CCS architecture. The evolution process shall respect the need for sufficient stability, i.e. periods for sufficient return of investment for developed products and installed systems.
CCS Feature (for MIG)
A CCS Feature is a cohesive piece of system functionality.{comment:9} It can be at the top level of the system of interest, in which case it is equivalent to the concept of System Capability, or it can be at a lower level, in which case it is to be considered as a sub-feature of a higher-level feature.
CCS Feature
A CCS Feature is a main/top-level function on System Level 3 for CCS. Examples: ATO GoA2, Cold Movement Detection, C-DAS Mixable onboard features (M/O means mandatory/optional) Feature(s) | M/O | Comment/Constrain/Condition/Version/Subfeature ETCS (ATP/ATO GoA1), only radio based | M | Compatibilty matrix onboard/trackside System Versions: Like today in TSI22. Assumption about phased out SV for the target system later on: Will be analysed in migration team. Inclusion of GSM-R in target architecture: To be analysed by MIG team with COM team, current TSI discussions to be included. ATO GoA 2,3 or 4 | O | RTO | O | Absolute Continuous Train Positioning | O | Option: Capabal to use trackside augmentation information (like EGNOS or map information) Train Integrity Information | O | Mandatory, if no trackside train detection exists Reliable train length information | O | Mandatory, if no trackside train detection exists Cold movement detection | O | DAC | O | C-DAS | O | Standard diagnostic interface | O | TMS onboard user interface | O | Fallback/light ATP system | O | To be discussed. Idependent and simplified mode or system that has minimal dependecies/maximized availability and allows safe rudimentory traffic in most degraded modes or for special vehicles Mixable trackside features in scope (M/O means mandatory/optional) Feature(s) | M/O | Comment/Constrain/Condition/Version/Subfeature ETCS onboard (ATP/ATO GoA1) | M | Radio based ETCS without lineside signals (no support for "overlay" installations. ATO GoA 2,3 or 4 | O | RTO | O | Postioning Augmentation Information | O | EGNOS, onboard map service Trackside Train detection | O | Mandatory, if trains/train units have no train-integrity, position reporting and reliable length information. Could be block sensors, geometric positions or point sensors. Onboard/trackside sensors can exist in parallel. DAC Control Applications | O | C-DAS Service | O | TMS services for onboard | O | e.g. request shunting route or possession by driver Support for fallback/light ATP system | O | To be discussed. Idependent and simplified mode or system that has minimal dependecies/maximized availability and allows safe rudimentory traffic in most degraded modes or for special vehicles
CCS Manifest
The CCS Manifest is a document that describes a CCS deployment configuration. For more details see the description for SPT2TS-123463 - BuildingBlockConfiguration "configuration.json" document .
CCS System
The control command and signalling (CCS) system covers signalling, train control, positioning equipment and telecommunications.
CCS TMS Configuration Data
The CCS/TMS Configuration Data refers to a conglomerate of different configuration data required for CCS/TMS systems. These can be broadly classified as Application Configuration Data and System Configuration Data.
CCS-OB
Control-Command and Signalling - On Board
CCS-TRK
Control-Command and Signalling - Track-side
CCS/TMS Data Model
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.
CEF Transport
Connecting Europe Facility Transport, funding tool of the European Commission
CPU
Central Processing Unit
CTC
Centralized traffic control
CCM
Change Control Management
PROPOSAL what to change where. Shall normally be linked to an Isse. See SPPR-2210 - Manage change request links
Change Request
Change Request.
Changeability
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.
CI = Central Instance
CI = Central Instance ECM 1 and vehicle keeper are registered in EVR () FDFTO TCG = Technical Coordination Group{comment:7}
Class A / B system
ERMTS is considered being a class A system whereas national legacy non-ERTMS systems are known as class B systems. In the frame of the migration to the future, harmonised CCS architecture based on harmonised operating rules, ERTMS systems based on earlier baselines are also treated as a kind of Class B system.
Class
An object is an instance of a class and a class is an object type.
Clean code has an important implication of the project’s success as clean code i...
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.
CMD - Cold Movement Detector
CCS
Command Control System TSI
CBO
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.
Common Business Objective
CSM-RA
‘common safety method for Risk evaluation and Assessement’ {comment:95} means the methods describing the assessment of safety levels and achievement of safety targets and compliance with other safety requirements; SPPRAMSS-619 - [CSM RA + (EU) No 1136/2015]
Common safety method for Risk evaluation and Assessement
Common standard properties of workitems
* 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 historical work/review comments to a work item incl. Answer/reaction * Approvers: Experts that are asked to confirm / object to the correctness of a work item
CVSS
Common Vulnerability Scoring System
Commonality
Commonality is the set of reusable features (interface, functionality, performance, environment insertion, etc.) that a module or a building block is made of. {comment:178}
Communication Mean
a medium that support interaction between operational entities/actors
CER
Community of European Railway and Infrastructure Companies
CEE
The Compartment Execution Environment refers to the combination of Physical Computing Element and Virtualization Environment.
Compartment Execution Environment
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.
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.
Compartment
Complete Train Cancellation
Completely cancel the train journey and remove the train from the Forecast calculations
Completeness
Component Exchange
A connection between two components that allows them to convey functional exchange and their exchange items.
Component
{comment:35} A component is used to structure functionality within building blocks. It implements and encapsulates one or more behaviors (business logic) and exposes services via defined interfaces to other components.{comment:159}
The Computing Element provides physical or virtual compute resources.
Computing Element
Concept Aspect
A content for sketching concepts regarding analysis purposes which is linked to requirements.
CONUSE
Concept how to use the system
CONEMP
Concept of Employment
CONOPS
Concept of Operations
Conceptual Data Model
The conceptual data model is the information model of the railway system. It captures domain knowledge by defining concepts that describe the railway system. The model includes relations between concepts.
Conceptual Glossary
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.
condition monitoring, <of an item>
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]
The position, speed, acceleration interval within which the ASTP assumes the true train position, speed, acceleration is, with a defined probability.
Confidence Interval
Confidentiality
Property that information is not made available or disclosed to unauthorized individuals, entities, or processes (source: ISO 27000-2018 )
Config Item
The name of a template that is used for System Pillar results
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.
Configuration item
Configuration Management Concept
The Configuration Management Concept is a solution oriented description of the Configuration Management Process: it defines all the technical solutions needed for the concrete implementation of the Configuration Management Process.
Configuration Management Process
The Configuration Management Process captures all concrete activities along the complete configuration management chain: from the Building Block realisation (by the Building Block Supplier(s)), to the integration into a specific System Instance (by the Integrator(s)), to the distribution to the field (by the Operator), and the actual activation (going into operation) in the field (it includes also on a train). The Configuration Management Process is a solution agnostic term that collects all activities needed for the Configuration Management.
Configuration Management
Configuration Management refers to the management of all Configuration Items of a physical instance of a System (e.g. trains or trackside CCS). From a process point of view, it covers activities along the complete chain, from the Building Block Supplier(s) to the Integrators, the Operator, and the actual Deployment being operational.
Configuration View
The configuration view exposes map data that{comment:1} fit the purpose of a given use case, e.g. ATO, TMS, ETCS L2/3 and delivers the information for the configuration of the subsystems that realise the use case.
Configuration
Description of a collection of model elements, either available or unavailable in a given context. A context can be a mode, a state or a combination of both.
Configure/administer content platform, define/moderate/train ACDARP process/prin...
Configure/administer content platform, define/moderate/train ACDARP process/principles/guideline, define quality criteria/dod, surveil quality/dod, define top-level content targets, moderate content break-down process, check target fulfilment
Conflict
A conflict is any difference between the operational plan and the forecast, regardless of any actual need for intervention to resolve it.
Connection Change
Change the time and/or location of a connecting train
Considered Fleet Type
type of rolling stock regarding a certain usecas, for example cargo trains, passenger trains, high speed passenger trains
Considered Track Type
type of track regarding a certain usecase, for example cargo line, high speed line, regional line
Consolidated Glossary
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.
Constraint
Constraints are requirements that limit the solution space beyond what is necessary to meet the given functional requirements and quality (or non-functional) requirements. Constraints should be classified according to its nature: Technical, Legal, Organisational, Stakeholders, Cultural, Enviromental - e.g. Project Requirements and SEMP related rules are organisational constraints -. 'Constraint' for requirement management (this definition) is not strictly the same as a model element 'constraint' used in Capella modelling, which is a "limitation of applicabilty of a design workitem" within a specific model view or perspective. See also from SPPR-2205 - P9.6 Explain engineering content with helper workitems : "A Constraint is typically linked to model elements like processes or functional chains. It limits limits the applicability of something or defines conditions for something."
Limitation of applicabilty of a design workitem
Context model
A context model is a window to the underlying comprehensive linked set of data types. The context model prescribes the content of a view. A context model is platform-independent, i.e. not designed with a particular technology in mind.
context
The ARCADIA method applies to the design of complex and critical systems, and more generally architectures that are subject to multiple functional and non-functional constraints, including software, electronic, electrical architectures, and industrial processes. It defines a set of practices that guides needs analysis and design to meet an operational requirement. At the same time it is adaptable to the processes and constraints linked to various types of life cycles such as bottom-up approach, application reuse, incremental, iterative and partial development.
CI/CD
Continuous Integration / Continuous Deployment
Control Command and Signaling
Control, Command and Signalling
CCS OB
CCS OB refers to the SPLI-372 - On-board control-command and signalling part of the SPLI-83 - Control-Command and Signalling
Control-Command and Signalling - Onboard
CCS TRK
CCS TRK refers to the SPLI-375 - Trackside control-command and signalling part of the SPLI-83 - Control-Command and Signalling.
Control-Command and Signalling - Trackside
Control-Command and Signalling
Controller Unit
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.
“Control” something
Define/derive deliverables and targets, break down and assign work, define process/leads, supervise timing, check results, organize approval and decision process
corrective maintenance
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]
CBA
Cost Benefit Analysis
CRL
Certificate Revocation List
XFN
Cross functional
Cross-Acceptance
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].
CSM-ALSP
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]
CST
‘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]
customer
a customer is an entity who buys and owns railway equipments and services from manufacturers (also called supplier) or engineering companies (e.g. Rus, IMs).
CVR-OB - Cabin Voice Radio On-Board
DAC - Digital Automatic Coupling
Danger Zone
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).
DAS - Driver Advisory System
DAS-OB - Driver Advisory System On Board
Data and Data Class
element of an exchange item. their content is described by a data class that can be shared by other data. A data class is a structure that defines the data and their elementary properties/attributes
DLP
Data loss prevention
Data Model Layer
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.
DBMS
Database Management System
Decision
A decision is a single action intended to make a modification the operational plan.
Link to workitems / documents, that shall be decided. Is assigned to the coregroup conveners.
Decommissioning
Withdrawing systems or components from service and dismantle it
Definition.
Glossary entry. See: Definitions
delete - CCS Configuration Manifest
implicit-from-entry-label: delete - CCS Configuration Manifest
Deliverable
An input or output of a task that crosses the process boundaries. Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project. (e.g. Requirement Specification)
Departure Datetime Change
Change in the departure time of a train in a station, either by departing earlier or later than planned
Deployment
rollout
Design Safety Case
The Design Safety Case gives evidence to the design for a product or application done in Phase 1 to 5. The Design Safety Case will: * fulfil the requirements of Phase 4 (including validation report) and integrated in a modular architecture in Phase 5, * define the SuC and its interfaces and must comply thereby to a harmonised reference architecture (e.g. "System Pillar Reference Architecture"): * functional allocation, * interfaces description, * standardised tests activities (e.f. test benches, procedures), * allocation of safety requirements (e.g. TFFR, SRAC) * be presented to the ISA for a first statement, * be reused for further generic product safety cases or generic/specific safety cases, * evolve along the whole lifecycle of the SuC design, * cover the Safety Management topics in the EU-Rail Standardisation and TSI Input Plan (STIP).
DeBo
Designated Body
“Design” something
Create content along the rules given by all "control" and "manage" roles, moderate review and approval process
Desk Area
Desk Area Desk Area is a location attribute (left, center...) associated to HMI Element for TDS Controller to allocate elements to a View.
Desk Display Area
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.
Desk
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
Development Partnership
Contract between IM or RU and one of more suppliers about developing product(s) or (sub)systems as a collaboration
Development Task
* Take spec, build system * Usually starts on CENELEC P5 * Bottom of CENELEC “V”
DEV
Development
Deviation Detection
Comparing the operational plan with the real-time status to detected operational deviations. Deviations have already happened and may only be mitigated but not solved.
Deviation
A deviation is any difference between the operational plan and the actual state of traffic; unlike a conflict, deviations may only be mitigated but not solved.
Device
Device{comment:36} A physical entity performing a predefined (set of) task(s). It consists of software integrated on a hardware.
Diagnostics
Diagnostics{comment:95} : Diagnostics is the assessment{comment:1} of health and performance of an asset or a group of assets. Furthermore, the diagnostic system also provides all information of single components in the field like: software version, parametrisation file version, firmware version, hardware version, manufacturer part number, manufacturer serial number,{comment:35} ID in the field (e.g. NID_ENGINE), cumulated hours in operation, IP address, etc. All this data is being used for analysis purposes.
Diagnostics is the assessment of health and performance of an asset or a group of assets. Furthermore, the diagnostic system also provides all information of single components in the field like: software version, parametrisation file version, firmware version, hardware version, manufacturer part number, manufacturer serial number, ID in the field (e.g. NID_ENGINE), cumulated hours in operation, IP address, etc. The latter is being used for analysis purposes.{comment:168} {comment:131}
Diagram.
Stores a diagram, slide, or picture.
Diffuse operational state
Detailed granular information about a subsystems that by themselves are not enough to implement a procedure in normal operation . E.g. track position of a starting train, pre-defined failure state of a trackside asset, etc.
DAC
Digital Automated Coupling
Digital Continuity
Digital continuity means that the transformation of information from the single source of truth all the way to production maps is fully automated, robust and without manual processing steps. Secondly, new storage technologies, computing platforms, communication protocols will come into fashion and the data model shouldn't prevent future users to adopt such technical innovations.
DR-I
The {comment:24}Digital Register Infrastructure{comment:12} (DR-I) is a database managing and providing static infrastructure data as central service. The data exchange between Traffic CS and this database is based on the EULYNX Standard Maintenance Interface SMI-xx via the subsystem Configuration (MDM).{comment:10}
Digital Register - Infrastructure
Direct Track Possession / Occupancy
Physical occupation of a train to a network or part of the network
DG MOVE
Directorate-General for Mobility and Transport
DG RTD
Directorate-General for Research and Innovation
Disaster Recovery-Plan
Dispatching
Dispatching is the sum of actions intended to make modifications the operational plan.
Display Panel
Display Panel Glass (LCD) showing pixels without controller.
DDOS
Distributed Denial of Service
DistributionJob "distribution-job.json" document
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.
DM - Digital Map
DMI - Driver Machine Interface
Document Author
Document Author is the document generator and belongs to a specific task/domain. See role SPPR-5408 - Document Author
Document Exchange
Document exchange is the act of sharing an exported document with people outside the document authoring group (domain task).
Document Generation and Management
Document Generation is the collection of information/workitems, and its following updating/review, within a single document having a specific scope and foreseen by the Documents Management Plan. The document generation shall be executed by the task that is in charge of the document (as foreseen by the Documents Management Plan). Templates from SP-Central Modelling Service shall be used (80 Templates ).
Documents Publication
Documents Publication is the creation of a document baseline and subsequent exportation in a defined exchangeable format (pdf, doc).
Domain Data Model
A domain data model is the information package needed by a professional discipline and the associated subsystems such as TMS, time tabling, ATO, ETCS signalling.
Domain Data
Domain Data as part of the SPT2TS-2040 - CCS/TMS Data Model is a use-case-specific representation of information following the specific needs of affected systems and their functionalities implementing the use case. Domain data are a tailored and potentially transformed subset of Engineering Data. {comment:20}
DNS
Domain Name System
Driveability (or Drivability)
The degree of smoothness and steadiness of acceleration of a vehicle.
DAS-OB
Driver Advisory System On Board
ABD
The extension of the movement authority of a following train considers the rear of the Safe Train Extent of a preceding train as an absolute limit that shall not be passed – the speed and braking capacity of the preceding train are neglected.{comment:3}{comment:21} (image: 1-screenshot-20240904-140007.png)
Driving in Absolute Braking Distance
RBD
The extension of the movement authority of a following train is derived from the Safe Train Extent of the preceding train considering also speed and braking capacity of the preceding train. The distance between both trains during motion can be shorter than driving in Absolute Braking Distance, increasing the rail operation efficiency.{comment:8}{comment:22} (image: 1-screenshot-20240904-140007.png)
Driving in Relative Braking Distance
Driving Strategy Change
Change the driving strategy from the defined list (energy efficient, reduce maximum speed, etc..)
Driving Strategy
How to drive the train as a combination of acceleration, braking, cruising and coasting (Energy efficient, reduced maximum speed, Maximal Coasting, Minimum Time Train Control, etc..)
Dual Trackside Signalling Strategy
Installing and running both class B signalling system and ETCS on the same track
Dynamic Business Rules
All defined rules related to the journey dynamics, e.g. Maximum waiting time of a connecting train
EARS
Easy Approach to Requirements Syntax
EB - Emergency Brake
ECN - Ethernet Consist Network
EET Configuration Manager
{comment:41}The EET Configuration Manager is the process owner of the Configuration Management Process under the System Pilar project.
ELK
Elasticsearch, Logstash, Kibana
Element
Any physical component that is part of the infrastructure composition (switches, tracks, signals)
End Occupancy Location
The location point where the infrastructure element (track, signal, switch, etc..) occupation has ended
End Occupancy Time
The timestamp where the infrastructure element (track, signal, switch, etc..) occupation has ended
EoL
In system design, the term "End of Life" refers to the stage in the lifecycle of a system or product when it is no longer considered viable, functional, or supported. It marks the point at which the system or product is no longer actively maintained, developed, or sold by the manufacturer or service provider.
End of Life
EoS
In system engineering, "End of Support" refers to the point in the lifecycle of a system or software product when the manufacturer or service provider discontinues providing technical support, maintenance, and updates for the product. It signifies the end of the official assistance and resources available from the provider to address issues, fix bugs, or offer guidance to users of the system.
End of Support
Engaged Area
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.
Engineering data
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.
The Engineering Data as part of the SPT2TS-2040 - CCS/TMS Data Model contains all the base data (i.e.,{comment:19} track topology, track geometry, track asset configuration) for compiling the next version(s) of use case-specific Domain Data. The standardized Engineering Data comprehensively covers the data needs for the SERA in the scope of the System Pillar (i.e. radio-based ETCS only). Specific data needed for migration is out of the scope of SPT2TS-2040 - CCS/TMS Data Model.
Engineering data are measurements, design data and derived data that parametrise the railway system, i.e. configuration information.
Engineering Input Data
Refers to data from Infrastructure Manager (IM) specific digital sources required for engineering, such as: * Track layout (nominal geometry of the respective construction phase * Track Assets (points, signals, train detection elements, etc.) * Properties (speeds, gradients, etc.) * Structures (platform, tunnel, etc.) * Logical data such as trackside train detection sections (if still available) * Acquisition Data * Configuration Data for track objects * Others (placeholder to include other possible data from IM)
Refers to data for specific digital sources required for engineering, such as * Track layout (nominal geometry of the respective construction phase) * Track Assets (points, signals, train detection elements, etc.) * Properties (speeds, gradients, etc.) * Structures (platform, tunnel, etc.) * Logical data such as trackside train detection sections (if still available) * Acquisition Data * Configuration Data for track objects * Train specific data like ETCS Braking curves * Any other data required for CCS/TMS system configuration
Engineering View
The engineering view exposes the configuration information that was used to build, test and release the railway system. This constitutes the as-planned situation.
Enterprise Cybersecurity Services (ECS)
A collection of enterprise security interface (ESI) implementations of central security and IT communication functions in a back-office environment. Examples are Security Incident and Event Management System (SIEM), Intrusion Detection System, PKI Certificate Authority, Corporate Directory, Asset Management, DNS. These services are typically accessible for the automation network via controlled communication paths (e.g. DMZ). The interfaces of the Shared Cybersecurity Services to the Enterprise Services are identified by ESI-<Service name>. Note: Enterprise Shared Services are typically 3rd-party components not dedicated to the rail environment. Therefore the realization of the Enterprise Shared Services may use other security requirements than the Secure Component Specification. Recommended security specification are ISO 27033, ISO 27034, NIST 800-53, and/or IEC 62443-4-2. Note: Enterprise Shared Services and Shared Cybersecurity Services are separated by the IT/OT border (e.g. by a DMZ).
ERP
Enterprise Ressource Management
ERA - European Railway Agency
EECT
ERA Extended Core Team
ERG - Euro Radio Gateway
ERJU Hazard Database
ERJU Hazard Database. A collection existing hazard lists of known hazards and accidents which is initiated and maintained by ERJU's PRAMS domain with the aim to provide a harmonized set of hazards/accidents.
ERTMS - European Rail Traffic Management System
ERTMS comprises of the European Train Control System (ETCS), i.e. a cab-signalling system that incorporates automatic train protection, the Global System for Mobile communications for Railways (GSM-R) and operating rules.
(ERA definition)
EUG
ERTMS Users Group
Essential Function
Function or capability that is required to maintain health, safety, the environment (HSE) and availability for the equipment under control (definition from IEC 62443-4-2) Note: 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. In the context of the ERJU System Pillar all systems in scope provide functionality as defined in "Essential functions". Note: IEC 63452 definition: All functions needed to operate the railway system, such as per example traffic control, speed control, traction/brake control,...
function or capability that is required to maintain health, safety, the environment and availability for the equipment under control Note 1 to the entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control function and the ability of the operator to view and manipulate the equipment under control. The loss of essential functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries additional functions such as history may be considered essential. IEC 63452 definition: all functions needed to operate the railway system, such as per example traffic control, speed control, traction/breake control,...
function or capability that is required to maintain health, safety, the environment and availability for the equipment under control Note 1 to the entry: Essential functions include, but are not limited to, the safety instrumented function (SIF), the control function and the ability of the operator to view and manipulate the equipment under control. The loss of essential functions is commonly termed loss of protection, loss of control and loss of view respectively. In some industries additional functions such as history may be considered essential.
Estimated Distance
It is expressed as the distance along the track centreline between a reference location and the estimated train front end position.
Estimated Train Front End Position
The position the ERTMS/ETCS localisation on-board equipment estimates the train front end is at, with the highest probability according to the physical characteristics of the train and to the localisation working conditions. Also referred to as “Estimated Position” SUBSET-023.
ETCS - European Train Control System
ETP-OB - European Train Protection On-Board
ETP-OB - European Train Protection On-Board Note: ETP-OB equivalent with ETCS-OB
EUSPA
EU Agency for the Space Programme
EU Regulations
EU-RailGoverning Board
EU-RailGoverning Board Final decision body, where a decisions are adopted a majority of at least 55% of the votes
EUG - ERTMS Users Group
COM
European Commission
CENELEC
European Committee for Electrotechnical Standardization
CEN
European Committee for Standardization
EDDP
European DAC Delivery Program
EGNOS
European Geostationary Navigation Overlay Service, European satellite navigation system
European Geostationary Navigation Overlay Service
EPF
European Passengers' Federation
EIM
European Rail Infrastructure Managers
ERRAC
European Rail Research Advisory Council
ERTMS
European Rail Traffic Management System
European Railway Traffic Management System (ERTMS) is a single European signalling and speed control system that ensures interoperability of the national railway systems, reducing the purchasing and maintenance costs of the signalling systems as well as increasing the speed of trains, the capacity of infrastructure and the level of safety in rail transport. ERTMS comprises of the European Train Control System (ETCS), i.e. a cab-signalling system that incorporates automatic train protection, the Global System for Mobile communications for Railways (GSM-R) and operating rules. (ERA definition)
European Railway Traffic Management System (ERTMS) is a single European signalling and speed control system that ensures interoperability of the national railway systems, reducing the purchasing and maintenance costs of the signalling systems as well as increasing the speed of trains, the capacity of infrastructure and the level of safety in rail transport. (ERA definition)
European Railway Traffic Management System
European Securities Committee
ESA
European Space Agency
ESO
European Standardization Organization
ESIF
European Structural and Investment Funds
ETSI
European Telecommunications Standards Institute
ETM
European traffic management
ETCS
European Train Control System (ETCS) is a cab-signalling system that incorporates automatic train protection. (ERA definition)
European Train Control System (ETCS) is a cab-signalling system that incorporates automatic train protection (ERA definition). ETCS in the frame of SERA will support the following Levels: * L2 with fixed train detection (classic L2 with trackside detection (track circuits, axle-counters, …)) * L2 with hybrid train detection (virtual fixed or moving blocks with trackside detection (axle-counters, …)) – formerly known as Hybrid L3 * L2 with virtual fixed or moving blocks and train integrity (no trackside detection) – formerly known as pure L3
European Train Control System
ETF
European Transport Workers' Federation
ENISA
European Union Agency for cybersecurity
ERA
European Union Agency for Railways
ERJU
Organisation being tasked with the standardisation in the railway domain at European level.
(Europe’s Rail) Joint Undertaking
Europe’s Rail Joint Undertaking
EU-Rail
Europe's Rail
EVC - European Vital Computer
EDA
Event-driven architecture
Evolution
Evolution is the process of gradually developing, refining or improving parts of the System Pillar Harmonized Operational Processes respectively the System Pillar Reference Architecture (SPRA).
Evolution refers to the gradual development and refinement of a system over time, through a process of adaptation and improvement. Evolution is often driven by the need to to improve system reliability , efficiency, or other key metrics, while addressing new or changing needs and challenges.
Evolvability
Evolvability is the ability to easily adapt to new technologies or to extend the functionality of the CCS system without the involvement of the original supplier.{comment:429}
Exchange item
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.
Exchangeability
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}
EAL
The{comment:27} Execution & Adaptation Layer is a subsystem of Traffic CS which is responsible for: * processing the Operational Plans provided by the TMS, which are based on the Operating State of the railway within the Area of Control and * providing the Operating State within the Area of Control received from Trackside Protection System towards the TMS.
Execution & Adaptation Layer
Extended View
Extended View View displayed on more than one Display Panel.
External Button
External Button A button which is not directly managed by TDS.
The External Diagnostic, Configuration & orchestration Interface I1 (Interface 1) comprises communication-based interfaces between rail systems and central infrastructure components as diagnostics, IT-security services and remote update.
External Diagnostic, Logging, Orchestration and IT Security Interface(s)
fail-safe [821-01-10]
able to enter or remain in a safe state in the event of a failure
fail-safe
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 ]
failure cause
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]
failure mode
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]
failure rate [821-12-21]
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]
failure rate
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]
limit of the ratio of the conditional probability that the instant of time, T, of a failure of a product falls within a given time interval (t, t + Δt) and the duration of this interval, Δt, when Δt tends towards zero, given that the item is in an up state at the start of the time interval Note 1 to entry: For applications where distance travelled or number of cycles of operation is more relevant than time then the unit of time can be replaced by the unit of distance or cycles, as appropriate. Note 2 to entry: The term “failure rate” is often used in the sense of “mean failure rate” defined in IEV 192-05-07. [821-12-21][IEC 62278:2002, 3.14, modified]
failure
loss of ability to perform as required Note 1 to entry: A failure of an item is an event that results in a fault of that item: see "fault" (IEV 192-04-01). Note 2 to entry: Qualifiers, such as catastrophic, critical, major, minor, marginal and insignificant, can be used to categorize failures according to the severity of consequences, the choice and definitions of severity criteria depending upon the field of application. Note 3 to entry: Qualifiers, such as misuse, mishandling and weakness, can be used to categorize failures according to the cause of failure. [SOURCE: IEC 60050-192:2015, 192-03-01]
fault, <of an item>
inability to perform as required, due to an internal state Note 1 to entry: A fault of an item results from a failure, either of the item itself, or from a deficiency in an earlier stage of the life cycle, such as specification, design, manufacture or maintenance. See latent fault (192-04-08).{comment:215} Note 2 to entry: Qualifiers, such as specification, design, manufacture, maintenance or misuse, may be used to indicate the cause of a fault. Note 3 to entry: The type of fault may be associated with the type of associated failure, e.g. wear-out fault and wear-out failure. Note 4 to entry: The adjective “faulty” designates an item having one or more faults. [SOURCE: IEC 60050-192:2015, 192-04-01]
fault correction time
part of active corrective maintenance time taken to perform fault correction [SOURCE: IEC 60050-192:2015,192-07-14]
fault detection time
DEPRECATED: undetected fault time time interval between failure and detection of the resulting fault [SOURCE: IEC 60050-192:2015,192-07-11]
fault localization time
DEPRECATED: fault location time part of active corrective maintenance time taken to complete fault localization
fault tree
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]
FCI
FDFTO Central Instance
feature summary
The ARCADIA method: * Covers all structured engineering activities, from capturing customer operational needs to system integration verification validation (IVV); * Takes into account multiple engineering levels and their effective collaboration (system, subsystem, software, hardware, etc.); * Integrates co-engineering with specialty engineering (safety, security, performance, interfaces, logistics ...) and IVV; * Provides the ability not only to share descriptive models but also to collaboratively validate properties of the definition and the architecture; * Is field-tested in full-scale industrial applications, and is currently deployed on dozens of major projects in several countries and divisions of Thales.
Feature
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.
FFFIS - Form Fit Functional Interface Specification
In contrast to an FIS (Functional Interface Specification), FFFIS describes not only the functional requirements for an interface, but also its complete, specific design. An FFFIS has the requirement that all devices with an interface developed according to it are interchangeable. "FF - Form Fit" is a classification of interchangeable parts which are identical in shape, fit and function and are therefore interchangeable with one another. An FFFIS is therefore a clear description of an interface between devices or modules.
FFFIS - Form-Fit Functional Interface Specification
FFFIS
Form, Fit and Function Interface Specification{comment:216}
FIS - Functional Interface Specification
implicit-from-entry-label: FIS - Functional Interface Specification
Functional requirements and description of an interface. This clarifies also the functional apportionment and related safety requirements of the two sub-systems of the interface.
FAM
Fixed asset mgmt
FVB
A Fixed Virtual Block is a Fixed Block where the extremities are virtual and do not necessarily correspond to train detection boundaries. {comment:71}
Fixed Virtual Block
Flagship Area
FMECA
failure modes, effects and criticality analysis quantitative or qualitative method of analysis that involves failure modes and effects analysis together with a consideration of the probability of the failure mode occurrence and the severity of the effects Note 1 to entry: The term "fault mode, effects and criticality analysis" in IEC 60050-191:1990 (now withdrawn; replaced by IEC 60050-192:2015) is deprecated, since a fault (192-04-01) is a state and cannot logically have a mode, whereas a failure mode (192-03-17) is a change of state. [SOURCE: IEC 60050-192:2015, 192-11-06] Note 2 to entry: 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).
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).
Follow a trace
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: Safety analysis for “Assure that all CCS processes are safe” * All operational processes need to be listed and analysed on System level 3 (OA) * Out of this all traces have to be analysed to understand the hazards and risks But this does not mean that this is also done for System Level 1,2, or 4. Just the operational design team in Task 2 has to do this. Example 2: Systems on System Level 5 (“standard products”) * Complete description how to install and use them (processes) * Complete functional description * Complete system and interface description How to follow “traces” Following a trace means to break down work items more and more. Every breakdown is not necessarily “homogenous”. One breakdown step (indicative): A break down step follows this workflow (for the assigned team) * Assess if work item is accepted and makes sense. If not, reject and forward work item to a functional team * Analyse, work out, and refine a work item; change status when finished * Draft and link the derived work items, set status to “proposed” * Propose their assignment to a team * Assigned team accepts or forwards the derived work item to a functional team. How do traces start, how to reach “completeness”? A. New traces start from * Any input of the stakeholders * Common Business Objectives (CBO) * A System Level 2/3 mission and the needed operational capabilities, derived operational scenarios and their operational requirements * Any input inside of the System Pillar team – if a backward linking to CBO or operational missions/capabilities is possible or stakeholder (steering group) agree Completeness is reached if for all of these (decided) inputs a trace down to the implementation exists with a valid trace. B. A trace is valid if * …it is connected up to a decided demand (A.) * …it is connected down to an implementation in operational processes and System Level 5. * … all links between work items of the trace are valid (correct derivation) The status of all traces will be visible at any time via the ALM.
Forecast
The forecast displays the future state of traffic. It based on the current operational state. The forecast projects the current operational plan into the future. A forecast for each train run under consideration of mutual train influence is processed (train run time, section run time, minimal section run time, detailed topology, headways and train sequence, circulation, connection, etc.).
FFF
Form, Fit and Function
Form Fit Function Interface Specification
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.
FORM FIT FUNCTIONAL INTERFACE SPECIFICATION
Formal Method
Founding Members
FP - Flagship Projects
FPMH
Failures Per Million Hours{comment:96}
FPMK
Failures Per Million Kilometres{comment:97}
FWC
Framework contract
FRMCS - Future Railway Mobile Communication System
FS - Full Supervision Mode in ETCS
FS - Full Supervision Mode in ETCS{comment:26}
FTA
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
Full Backwards Compatibility
Full backward compatibility, also known as "complete backward compatibility," refers to a situation in which a newer version of software, hardware, or a system is not only compatible with the previous version but also ensures compatibility with all previous versions and features without exceptions. In other words, any software, data, or hardware that worked with older versions will work seamlessly and without any issues with the new version. With full backward compatibility, users can transition to the latest version with confidence, knowing that they won't encounter any incompatibilities or disruptions. This level of compatibility often requires careful design and testing to ensure that all legacy functionalities and components are supported and function correctly in the newer version.
FDFTO
Full Digital Freight Train Operations
FTE
Full Time Equivalent
function checkout time
part of active maintenance time taken to complete function checkout [SOURCE: IEC 60050-192:2015,192-07-16]
FAT
A Functional Application Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as FA Task Replicas.
Functional Application Task
A Functional Application is a comprehensive set of self-contained software functions, assumed to be provided as one product by a single vendor. Depending on its role in the overall function provided by the Functional System, it has a specific SIL (BIL up to SIL4) assigned (in-line with total FS SIL definition).
Functional Application
Functional apportionment
Functional apportionment is the clear assignment of functions to sub-systems. It is an architectural choice supporting the ability to replace a sub-system of supplier A by a subsystem of supplier B both compliant with a given FIS.
Functional Chain
Is an ordered set of references to functions and the functional exchanges that link them, describing one possible path among all the paths forming the data-flow. Functional chains are used to describe the system behaviour in a particular usage context, to contribute to one or more capabilities. Each reference to a function or exchange inside the chain can be qualified by an expectation in the context of the chain (the value that an exchange item or a function attribute should take, for example). Furthermore: A functional chain also specifies constraints or expectations of precedence or anteriority via oriented sequence links. A set of functions and sequence links is a sequence. Control nodes can be defined between the sequence links, to express the parallelism or alternative between several sequences of functions, or, also the iteration or condition of a sequence to be realised. ARCADIA talks only about a functional chain from system level onwards, in operational analysis, it is still called operational process, the methodology is the same for both, therefore no further distinction is made.
Functional Echange
A connection between two functions or two components that allows them to convey exchange items.
FIS
Functional Interface Specification
FRS/FIS
Functional Requirement Specification/Functional Interface Specification
FRS
Functional Requirements Specification
Functional requirement
A requirement which specifies a function that a system has to do.
FSDR
The Functional System Deployment Rules comprises all necessary information for deploying the respective Functional System onto specific approved Compartment Execution Environment(s). These deployment rules are compiled as part of the FS integration process and are part of each integrated, tested and qualified/approved Functional System along with its FS Compartments and all necessary approval documentation.
Functional System Deployment Rules
A Functional System is a comprehensive set of self-contained Compartments, assumed to be provided as one product by a single vendor. Depending on its overall function, it has a specific SIL assigned.
Functional System
Functional Team
A Functional team includes the role owners of the same role. It organizes the work allocation and overall results for that role, including the workflows and working methods. The name of the functional team has a “-F” at the end. The functional teams form a matrix to the organisational units of the SP. If an organisational unit has more persons with the same role, one of them can be delegated to the functional team as a "speaker". Functional teams organise themselves internally. From "outside" (SP processes) the team is addressed as one actor. The worksplit in the functional teams is decided in the team. The functional teams act with the responsibilities and tasks defined by the role it represents. The functional team is lead and moderated by the participant from System Level 1/ (mostly people from the engineering services, see role allocation table). Functional teams decide in consensus, or escalate to the coregroup. Example for the functional Team “REQ-F” (image: 1-Bild_2.png)
Functional Topology
The 'Functional Topology' is part of railway infrastructure and defines different functional elements like Signals, Points, etc.
Functionality
Function
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.
Funktional team
A Functional team includes the role owners of the same role. It organizes the work allocation and overall results for that role, including the workflows and working methods. The name of the functional team has a “-F” at the end. The functional teams form a matrix to the organisational units of the SP. If an organisational unit has more persons with the same role, one of them can be delegated to the functional team as a "speaker". Functional teams organise themselves internally. From "outside" (SP processes) the team is addressedaddressed as one actor. The worksplit in the functional teams is decided in the team. The functional teams act with the responsibilities and tasks defined by the role it represents. The functional team is lead and moderated by the participant from System Level 1/ (mostly people from the engineering services, see role allocation table). Functional teams decide in consensus, or escalate to the coregroup. Example for the functional Team “REQ-F”
FRMCS
Future Railway Mobile Communication System
FVA - Functional Vehicle Adapter
FWSI
‘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]
GASC
Generic Application Safety Case;SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] {comment:99},SPPRAMSS-335 - [EN 50126-2:2017]
Generic Application Safety Case (from SPPRAMSS-334 - [EN 50129:2018/AC:2019-04])
Generic Application Safety Case
GPSC
Generic Product Safety Case (from SPPRAMSS-334 - [EN 50129:2018/AC:2019-04])
Generic Product Safety Case
Generic workflow types
* 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.
GoA - Grade of Automation
Generic Product Safety Case; SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] {comment:100},SPPRAMSS-335 - [EN 50126-2:2017]
Granularity
The granularity characterises the level of modularity of a system. The more subsystems a system is composed of, the higher its granularity.
Granularization
The granularization refers to system engineering activity aiming at defining granularity.
GSM-R - Global System for Mobile Communications – Railways
GW - Gateway
Hard Key
Hard Key Physical key not part of view. This key can also have a text label or symbol.
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.
Hardware Abstraction Interface
The Hardware Layer contains the actual Physical Computing Elements providing the compute resources to the platform.
Hardware Layer
Hardware refers to the physical components of a computer system or electronic device. It encompasses all the tangible parts that can be seen and touched, such as the central processing unit (CPU), memory modules, storage devices (hard drive, solid-state drive), possible input/output devices (e.g. keyboard, mouse, monitor, etc), motherboard, graphics card, sound card, and various other components that make up a computation unit or electronic device. Hardware is responsible for executing and processing instructions and data, providing the necessary functionality for software to run and perform tasks.
Hardware
Harmonisation
Harmonisation includes the options TSI specification (Annex A or Application Guide), Standardisation via ESO, or agreed System Pillar Publication.
Harmonization
Act or process to make something consistent or compatible. Harmonizing the railway system can include all kinds of technical systems, operations and processes.
Harmonized interchangeable product ("modular" product).
A harmonized product is interchangeable, if it implements ALL and ONLY harmonized SPRA interfaces together with the harmonized system behavior, which is only parametrizable, but not customizable in terms of software behavior with propietary customisation features.
Harmonized product
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.
Hazard
Condition that could lead to an accident Note 1 to entry: The equivalent definition in [IEC 60050-903:2013, 903-01-02] refers to "harm" instead of "accident". Note 2 to entry: A Hazard sits at the boundary of the system under consideration. [ ERA-REC-116-2015-GUI]
A problemativ situation that can occure with a system.
HAZOP
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.
Heading.
Chapter title. This is no normal wokitem type, cannot be commented, etc. Is automatically created in documents when a heading is entered.
Headway Distance
Safe distance between two running trains
HFI Activities
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.
High level BuildingBlocks
Due to the dependency concept the BuildingBlocks can form units of unlimited size. The recursive dependency tree can have any depth. Every level of the dependency tree links to the next level - that allows to assign clear responsibilities for each of the levels. As an example a BuildingBlock "area" might refer to a number of "interlocking interiors" and "filedelements" in its next downstream dependency level. The Top-Level BuildingBlockConfiguration is the root where all dependencies start from.
HMI Component
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.
HMI Element
HMI Element An HMI Element is a physical component that interacts with the driver: Buzzer, Display Panel, loudspeaker, Hard Key...
HRM
Holistic Requirements Model
Homologation
In the railway context, *homologation* refers to the formal approval process that ensures a railway system, component, or piece of equipment meets all relevant safety, technical, and regulatory standards before it can be put into operation. This process involves rigorous testing, certification, and validation by authorized bodies to confirm that the railway elements, such as trains, signaling systems, and infrastructure, comply with national and international standards. The process typically includes a series of assessments, including safety,{comment:240} interoperability, performance, and environmental impact evaluations, before final approval is granted for commercial use. This term is used as a "generic" term that covers any aspect related to certification, assessment, authorisation, approval, acceptance.
HOF
Human and Organisational Factors (HOF) are at the heart of safety operations and management. They even play a key role in both Operational Safety and Occupational Safety.
Human and Organisational Factors
Human and Organizational Factors (lead to workitem SPPR-2246 - Application Condition and perhaps SPPR-2244 - Safety related application conditions)
Human and Organizational Factors
Human Factors
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.
HMI
Human Machine Interface
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.
HSI
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 .
Human-System Integration
HTTP
Hypertext Transfer Protocol
Identity
An identity acts as an address where algorithms can retrieve detailed information about an object or struct.
Impersonation
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.
Implementation Requirements
define how a system is to be built in terms of specific technology. These may be specific requirements from the customer about a solution that they require or they may be legislative requirements.
In this document, the abbreviations "IM" for Infrastructure manager" and "RU" fo...
In this document, the abbreviations "IM" for Infrastructure manager" and "RU" for Railway Undertaking are used due to their widespread use in the rail sector. The equivalents terms are "RIM" for Rail Infrastructure Managers" and "ROC" for Railway Operating Company. CMS | Capacity Management System CBO | Common Business Objectives CCS | Command Control Signalling ETMN | European Traffic Management Network RIM | (Rail) Infrastructure Manager IM | Rail Infrastructure Manager ROC, RU | Rail Operating Company, Railway Undertaking TMS | Traffic Management System XS - S - M – L - XL | Extra Small - Small – Medium – Large – Extra Large TCC | IM Traffic Control Center TCR | Temporary Capacity Restriction ETM Network | European Traffic Management Network short – medium – long | Referring to implementation period in sub-chapter “Summary Assessment of Feasibility”
Incident Impact Management
Managing the recovery from incidents to normal state of operations.
incident
‘incident’ means any occurrence, other than an accident or serious accident, affecting the safety of railway operations; SPPRAMSS-337 - [Directive (EU) 2016/798]
ISA
The role is defined in "Table G.4 — Role specification for Independent Safety Assessor" of SPPRAMSS-335 - [EN 50126-2:2017]
Independent Safety Assessor
Indirect Track Possession / Occupancy
Part of the infrastructure that is not directly occupied by a train, but contains a buffer area for example between the train and signal.
Indivisible for deployment
When a set of CCS features must be included in full for any given deployment (e.g. migration plateau, SP release, migration target etc.).{comment:112}
Information model
An information model is formal documentation for data management. It is a guide to the implementation and use of data.
IRM
Information Rights Management
Infrastructure data
Infrastructure Data is a detailed digital representation of the railway network that contains all infrastructure related {comment:3}information necessary for planning and performing railway operations, such as infrastructure characteristics, location and details of Field Elements, etc. The Infrastructure Data is static and remains unchanged until relevant infrastructure updates occur.
Infrastructure Manager Operational Area of Control defines the region under the...
Infrastructure Manager Operational Area of Control defines the region under the responsability of only one Infrastructure Manager
Infrastructure Manager
Infrastructure
A section of the railway network (distance on the network between two points)
IPSE
Innovation Pillar System Experts
Input documents
* 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)
INS
An Instance is a specific realization of any entity.
Instance
Integration Task
* Combine elements, validate/test whole system behaviour, implement/commission * Right side of CENELEC “V”
Integration
Integration is to combine current and/or new systems with a known behaviour to a larger system with a target behaviour. For any country migrating or upgrading their system(s) ‘integration’ is an important consideration to ensure the whole railway operates in a safe and reliable manner.
Integrity
Integrity: property of accuracy and completeness (source: ISO 27000-2018 )
Interchangeability
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.
Interface adaption (in a national product pair)
An SPP-2228 - Missing cross-reference in a national product describes the development effort to change an existing product interface to a harmonized interface, which normally needs to be done at least on two sides. The SPP-2228 - Missing cross-reference leads to an SPP-2325 - Adapted product.
Interface
An interface is the link between different building blocks. Inside a building block there can be only "proprietary interfaces". {comment:1429}With an interface the sub-systems of different suppliers{comment:1296} can be combined.
A shared boundary between two systems, that interchange exchange items.
IXL
Interlocking is a set of signaling devices which physically materializes, in the area of action of a switch post (junction, crossing of tracks, etc.) throught mechanical, and / or electrical solutions . It allows train movement if the safety conditions have been met regarding train maneuver and signal control devices. (double. needs to be deleted)
Interlocking is a set of signaling devices which physically materializes, in the area of action of a switch post (junction, crossing of tracks, etc.) throught mechanical, and / or electrical solutions . It allows train movement if the safety conditions have been met regarding train maneuver and signal control devices.
Interlocking
Internal Button
Internal Button The Internal Button is a button which is managed directly by TDS.
Internal Publication
Any work product that is not required to be submitted in order to complete a process, phase, or project. An input or output of a task that does not cross the process boundaries.
UITP
The International Association of Public Transport
International Association of Public Transport
INCOSE
International Council on Systems Engineering
IEC
International Electrotechnical Commission
ISO
International Organization for Standardization
UIC
International union of railways
UIP
International Union of Wagon Keepers
INTEROPERABILITY CONSTITUENTS
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.
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, 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.
IDPS
An Intrusion Detection and Prevention System (IDPS) is a network security solution designed to monitor, detect, and prevent unauthorized access, misuse, or malicious activity on a computer network
Intrusion Detection and Prevention System
Issue.
A problem description to be solved in the specification. Can also be an open question, or a generic question, or a point on an agenda.
JP - Journey Profile
Juridical recorder: collecting and storing juridical data (e.g. JRU data: SUBSET...
Juridical recorder: collecting and storing juridical data (e.g. {comment:8}JRU data: SUBSET-027, possibly very similar data is also sufficient)
Key Controller
Key Controller Controller which manages states and failures of Hard Keys (internal and Lateral Key) and switches.
Kinematic data
Set of data including speed, acceleration, attitude or angular rate of the train.
Lateral Key
Lateral Key Hard Key located close to a Display Area allowing soft key technology.
Layout Controller
Layout Controller The Layout Controller manages the Layout for an Area.
Layout Element Controller
Layout Element Controller The Layout Element Controller managesLayout Elements of a Layout. It knows how to present itself and how to react on events.
Layout Engine
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.
Layout
Layout Layout is a list of layout elements which is displayed in an area.
LoS
Letter of Support
Lexical Glossary
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.
LRU
Line Replaceable Unit
LOC-OB - Localisation On-Board
Localisation Information
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.
Localisation
Determines the position of the train within the track network, using for example topological coordinates.
Logging: is the activity of keeping a list of events that occur in a computer sy...
Logging: is the activity of keeping a list of events that occur in a computer system, events such as problems, errors, or just information on current operations. [https://en.wikipedia.org/wiki/Logging_(computing)]
Logical Actor
See definition of SPPR-2579 - System Actor now the actor is used in the logical architecture.
Logical Component
An abstraction of a system that performs the system functions without imposing restrictions on implementation. Logical components are also only connected via FIS and not via FFFIS interfaces.
Logical Functional Chain
an ordered collection of behavioural exchanges transmitting one or several logical functional exchanges
Logical Function
A SPPR-2598 - Function derived during logical architecture by splitting a system function.
logistic delay
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]
Loudspeaker
Loudspeaker Device that converts an electrical audio signal into a corresponding sound.
LR is a collective term for L2 and L3 in the new CCS TSI 2022 (not yet officially issued) B4 R1.
LTM - Loop Transmission Module
LWG - Localisation Working Group
MooN
In an M-out-of-N configuration, a functional system consists of N redundant replicas, out of which at least M must be functionating correctly for the overall functional system to operate.
M-out-of N
MACMT
mean active corrective maintenance time expectation of the active corrective maintenance time [SOURCE: IEC 60050-192:2015, 192-07-22]
MAD
mean administrative delay. Expectation of the administrative delay. [SOURCE: IEC 60050-192:2015,192-07-26]
maintainability, <of an item>
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]
Maintainability
Ability to be retained in, or restored to, a state to perform as required, under given conditions of use and maintenance [EN50126], see SPT2ARC-1616, see also SPPRAMSS-3540 - maintainability, <of an item> .{comment:1297}
Maintenance Costs
Costs for maintaining the railway system
Maintenance Operator is the person in charge of applying the maintenance documents containing the maintenance constraints to repare the train if a default occurs, detected in commercial service, during tests or during train preparation. It role is also to apply preventive maintenance to improve the commercial service.
Maintenance Operator
MITM
Man-in-the-middle attack
Management by traceability (KANBAN based)
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)
The management compartment provides the deployment, configuration and monitoring services through the standardised interfaces. The details will be specified in the future documents.
Management Compartment
Manufacturer
The company or organization creating a component, product or system.
Master Data
Master data represents "data about the business entities that provide context for business transactions".
Maximum Stopping Time
Maximum allowed time for a train to wait on the platform according to the defined business rules
Maximum Waiting Time
The maximum time a train can wait for another train to arrive in order to take the passengers aboard
MBSE - Model-based System Engineering
MDBF
Mean Distance Between Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]
MDBSF
Mean Distance Between Service Failures [SOURCE: Wikipedia Mean Distance Between Failure – Wikipedia]
MDCM - Multi-Dimensional Configuration Management
MDS - Multi Display System; alternative naming for Train Display System, not yet...
MDS - Multi Display System; alternative naming for Train Display System, not yet in current architecture references.
MDS - Multi Display System
MTBF
Mean time between failure
MOE
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
Measure of Effectiveness
MOP
Measure of Performance. (one aspect of MOE)
Measure of Performance
MD5
Message Digest Method 5
Methodology
A collection of related processes, methods, and tools.{comment:408}
The ARCADIA method is used to identify functional chains, their overlapping scenarios and desired performance, along with their support by the architecture. * Starting with the first level of system analysis, they ensure traceability throughout the process definition and check each proposed architectural design against expected performance and constraints. * The non-functional properties expected from the system solution are also formalized in 'viewpoints'. Each viewpoint captures constraints that the system should face or meet (feared events, security threats, latency expectations, product line or reuse constraints, power consumption or cost issues, and more). * Then the architecture model is automatically analyzed to verify that it meets these constraints, thanks to dedicated expert rules (performance computation, resource consumption, safety or security barriers, etc.). This analysis can be done very early in the development cycle, detecting design issues as soon as possible ("early validation"). As a summary, the approach to characterization by views (or "viewpoints") cross-checks that the proposed architecture is capable of providing the required functions with the desired level of performance, security, dependability, mass, scalability, environments, mass, interfaces, etc. ensuring the consistency of engineering decisions, because all engineering stakeholders share the same engineering information, and can apply his/her own views and checks to them, so as to secure the common definition.
Method
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}
MFDT
mean fault detection time [SOURCE: SPPRAMSS-3539 - [EN 61703: 2016]]
Microphone Controller
Microphone Controller The Microphone Controller manages states and signals of Microphone.
Microphone
Microphone Device that translates sound vibrations from the air into electronic signals and scribes them to a recording medium or over a loudspeaker.
Microservices
MID - Mission Data
Migrateability / Scalability
The property of a system to allow changes to one or multiple building blocks, without affecting other building blocks or the overall system.{comment:144}
Migration Plateau
A Migration Plateau is a plateau used as target for a migration process.{comment:11}{comment:13}
Migration Strategies
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)
Migration
Migration is the national or company specific process of converting existing CCS/TMS systems including operational processes to corresponding systems and processes of the harmonized System Pillar Reference Architecture (SPRA).
Migration is the process or act of migrating (move from one part of something to another). In the context of CCS and TMS, migrating is the process of changing from the existing national CCS and TMS systems, currently in use in different European countries or on different infrastructures and moving to the target CCS and TMS architecture with Harmonised Operating Processes.
Minimum Circulation Time
Time taken to end the arrived journey, change crew, turn around, set the information of the new journey, start a new journey for the arrived train
Minimum Stopping Time
Minimum allowed time for a train to wait on the platform according to the defined business rules
MOT
Ministry of Transportation
Mission Assignment
SPT2OD-4976 - Missing cross-reference refers to the portion of a SPT2OD-4965 - Missing cross-reference SPT2OD-4977 - Missing cross-reference which is assigned to a SPT2OD-4967 - Missing cross-reference
MLD
mean logistic delay. Expectation of the logistic delay. [SOURCE: IEC 60050-192:2015,192-07-27]
Mode Machine
a collection of modes connected by transitions
Mode Transition
A change of mode toward itself or toward another mode. A transition is characterised by a trigger which can be a boolean condition applied on certain model elements, such as functional exchanges.
MBSE
Model based System Engineering
Model synchronisation
* 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)
Mode
Kind of system behaviour that is expected in given usage conditions. Modes can be applied to elements such as actors and components.
Modularity
The target of modularity means, that only harmonized interchangeable products should be developed.
Modularity is used in this document as a general term for partinioning{comment:1395} 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.
Module
{comment:34} A module is a sourceable unit of the CCS system (hardware and/or software), having full defined functionality, interface, performance, safety. {comment:180}
Monitoring: continuous supervision of the system condition for diagnostic or pro...
Monitoring: continuous supervision of the system condition for diagnostic or prognostic purposes.
MOTBF
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]
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.
Movement Permission
ETCS L2MB
FMB
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.
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.
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.
Moving Block
MRT
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]
MTBSF
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.
MTD
mean technical delay [SOURCE: SPPRAMSS-349 - [EN 50126-1:2017] Annex B.4]
MTTFF
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]
MTTF
mean operating time to failure expectation of the operating time to failure Note 1 to entry: In the case of non-repairable items with an exponential distribution of operating times to failure (i.e. a constant failure rate) the MTTF is numerically equal to the reciprocal of the failure rate. This is also true for repairable items if after restoration they can be considered to be "as-good-as-new". Note 2 to entry: See also operating time to failure (192-05-01) SPPRAMSS-4441 - operating time to failure, <of an item> . [SOURCE: IEC 60050-192:2015, 192-05-11]
MTTR
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.]
MVCC
Multi-version concurrency control
MILS
implicit-from-entry-label: Multiple Independent Levels of Security or Safety
Multiple Independent Levels of Security or Safety
Narrow Interfaces
narrow interfaces TBD
National development
A "national development" of product functionality creates SPP-2222 - Missing cross-reference.
NIP
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)
National Implemenation Plan
NSA
National Safety Authority
NTCC
National Traffic Control Centre
nTMS
National Traffic Management System
NB Rail
The NB-Rail Association is an international non-profit organization of the Third-Party Conformity Assessment Body (Notified Body (NoBo), Designated Body (DeBo), Assessment Body (AsBo), Entity in Charge of Maintenance – Certification Body (ECM-CB)) in the European railway sector. The association is installed to support and to complement the activities of NB-Rail coordination group.
NB-Rail Association
NTMS
Neighborhood TMS
Neighbouring Traffic CS
Neighbouring Traffic CS is located geographically adjacent to current Traffic CS territory. Neighbouring Traffic CS enables handing over or accepting a train going to/coming from current Traffic CS.{comment:17}{comment:28}
Network Component
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.
NFF
No Fault Found
Non-European Railway
IM and / or RU of a country that is no member of the European Union
Non-functional requirement
Non-Functional Requirements are constraints on the system that define how well something is to be done or how it is to be done which fall into three categories: * Performance Requirements SPPR-4175 - Performance requirement ; * System Requirements SPPR-4177 - System Requirements (deprecated) ; * Implementation Requirements SPPR-4180 - Implementation Requirements . These categories are derived from consideration of the essential relationships with the Operational and Functional Requirements and ensure the completeness and consistency of the requirements model (It is these essential relationships between the functionally-based requirements and constraint-based requirements that make the Holistic Requirements Model so useful).
Non-Repudiation
Non-Repudiation: ability to prove the occurrence of a claimed event or action and its originating entities (source: ISO 27000-2018 )
normal/regular operation
desired state of operation of a system/component/equipment, i.e. absence of faults.
NOTIF-IT
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 ]
NB-Rail
Notified bodies for interoperability in the railway sector
NoBo
Notified Body
NNTR
Articles 13 and 14 of Interoperability Directive define the cases where national rules (NRs) can be notified ant the procedure of notification of national rules by Member States. The applicable national rules (NRs) for vehicle authorisation are recorded in IT tool RDD. In particular, rules for ETCS and GSM-R are listed in section 12 “On-board control command and signaling” in the parameters list defined in Commission Regulation (EU) 2015/2299. The relevant NRs for fixed installation including Control Command and Signaling trackside subsystem have to be notified through SRD tool.
Notified national technical rules
NP - No Power Mode in ETCS
NRV
‘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]
NTC - National Train Control
NTP - National Train Protection
OB - On-board
Object Name
An object name is a string that helps humans identity an object and that may reveal meaningful information about the object.
objectives
ARCADIA is a structured engineering method to identify and check the architecture of complex systems. It promotes collaborative work among all stakeholders during many of the engineering phases of the system. It allows iterations during the definition phase that help the architects to converge towards satisfaction of all identified needs. Even if textual requirements are kept as a support for part of customer need capture, ARCADIA favours functional analysis as the major way to formalize the need and solution behaviour. This includes operational, functional and non-functional aspects, along with resulting definition of the architecture, based on – and justified against – this functional analysis. ARCADIA is based on the following general principles * All engineering stakeholders share the same language, method set of engineering artifacts and information, description of the need and the product itself as a shared model; * Each set of constraints (e.g. safety, performance, cost, mass, etc.) is formalized in a "viewpoint" against which each candidate architecture will be checked; * Architecture verification rules are established and the model is challenged against them, so as to check that architecture definition meets expectations, as early as possible in the process; * Co-engineering between the different levels of engineering is supported by the joint development of models. Models of various levels of the architecture and trade-offs are deduced, validated and/or connected with each other. The ARCADIA method is tooled through Capella, a modelling tool that meets full-scale deployment constraints in an operational context. Capella is available free of charge from the engineering community under open source.
OCORA - Open CCS On-board Reference Architecture
ODO
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.
Odometry
OE - Operational Execution
OMS - Online Monitoring System
OMS - Online Monitoring System NOTE : OMS is both trackside and on-board.
OMTS - On Board Multimedia & Telematics System (X2R4, equivalent with Passenger...
OMTS - On Board Multimedia & Telematics System (X2R4, equivalent with Passenger Information System)
Onboard Strategy
strategy of equipping and upgrading the trains with onboard communication units and additional technology as localisation, train integrity etc.
OSI layer
Open System Interaction Model, aka OSI 7 System Layer model
Open System Interaction Model
Operating Rules
Operating rules are entendend to inhance railway safety. They cover responsibilities, functionality of signalling equipment, procedures for safe train movement, handling incidents and accidents and other topics that are related to railway safety..
Operating state
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.
Operating system
operating time to failure, <of an item>
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]
operating time
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]
Operational Activity
On operational activity is one step in an operational process, that has one or more inputs, and one or more outputs. The activity describes what and how the operational entity the operational activity is allocated to is doing.
A step or function of an operational process, done by actors that might need to use the system to reach certain objectives.
Operational capability
An operational capability is an ability given by a group of processes.
An operational capability is an ability, expected of one or more operational entities. The operational capability provides a service contributing to fulfilling a high-level goal to which one or more operational entities should contribute, and which is likely to influence system definition or usage. It is characterised by a set of operational processes and scenarios describing more precisely the conditions for performing the operational activities that contribute to it. Operational capabilities are similar to use cases. They describe the application of the system from the point of view of the user/operational entity.
OpsCON
Operational concepts (How system should function)
Operational concepts
Operational Costs
Costs for operating the railway system
Operational Design
The operational Design, a synonym for operational analysis, includes the output workitems of all processes in the SEMP Process Group 02, which are for example operational... capabilities, processes, actor descriptions, requirements, hazards and risks. The operational design workitems are used for the System Pillar deliverable documents of the ORS (see SPPR-1848 )
Operational Entity/Actor
A person or organisation performing an operational activity.
Denotes an entity of the real world (such as another system, device, group or organisation ...) involved in operational activities to which the system of interest or stakeholders must contribute. An actor is a type of operational entity (usually human and indivisible).
Operational Epics
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.
OHT
Operational Harmonization Team
Operational harmonization
An operational topic (process, actor, defintion, ...) is considered harmonized if a description is provided in the SP context that fulfills: * This description is exhaustive, delimited and precise. There is no remaining "open space and freedom". The scope is clearly defined. Existing gaps are clearly identified. Statements are formulated unambiguously, if necessary in a formal form. {comment:98} * A set of variants and parameters, if necessary, are part of the description. * The description has been agreed by both Railway and Industry stakeholdes. This consens is especially defined under the light of project rework and domain standardisaton: * The description is agreed by the railways stakeholders of system Pillar as fitting their need, i.e. all their needs are fullfilled by the available variants and parameters without having again a solution discussion or check. * This description is agreed by the industry stakeholdes as 1:1 implementable, without having to reopen again the ambiguity discussion
Operational Hazard
Hazard whose cause is related to a failure in the application of an operational scenario/procedure (e.g. hazard due to operator or signaler or driver error) and/or to external events. These hazards are managed by means of "Operational Hazard" Work Item.
A problematic situation that can occure with a process design.
The I0 is the sum of all operational interfaces used from Functional Systems (as eg. an RBC) to communicate with other Functional Systems (as eg. an IXL). Expamles for these set of interfaces are the Eulynx Interfaces (SCI-xx) or interfaces like Euroradio or TSI-standardized interfaces.
Operational Interfaces
Operational Mission (deprecated)
A high-level operational objective. A drive or a goal that is assumed by a collection of operational entity, in order to reach specific objectives.
Operational Mission Segment
SPT2OD-5097 - Missing cross-reference refers to the portion of an SPT2OD-4977 - Missing cross-referencewhich represents the path on the railway track which is to be used for an immediate SPT2OD-4965 - Missing cross-reference movement and/or a related SPT2OD-4978 - Missing cross-reference .
Operational Mission
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.
Operational Plan
Analogous to the capacity plan, the operational plan supplies the train and traffic control and all other components with the operational train data. The operational plan is fed from the active timetable buffer and contains all trains (from the timetable buffer) that are currently in their operational time window. The operational plan is the result of various influences (decisions from dispatching, map data, etc.). It is updated every single minute.
Operational Process
An ordered (time or information) flow of operational activities.
Specific organisation of activities and interactions, forming one path to fulfil an operational capability, within the set of all possible paths of operational data flows. It describes either an expected behaviour of one or several operational entities in a given context, or expresses non-functional properties on the path (such as latency, criticality, confidentiality, redundancy ...).
Operational Requirements
Operational requirement
A requirement issued in the context of the operational analysis process group. May qualify some operational actor, actor property, activity, scenario.
Operational requirements are requirements which an operational procedure and its design has to fulfil.
Operational Risk.
Value and mitigation for a operational hazard
Operational Role
Collection of consistent activities that can be realised by one of several operational entities/actors, and should be considered as a whole. It's a means of structuring those activities and sharing them between several operational entities/actors.
Operational Scenario
See SPPR-2066 - Scenario
Operational Stop
SPT2OD-4978 - Missing cross-reference refer to the operational activities undertaken along, and in relation to, an SPT2OD-4977 - Missing cross-reference . Most commonly this can be exemplified by the station stops within a planned commercial journey for the entry/exit of passengers.
Operational track properties
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
OPE
Operational TSI
Operator Specific Add-On
Operator
An institution operating a system through its life-cycle, in context of the document usually an Infrastructure Manager or Train Operator.
Opex
Operational Expenditures
This interface is used to manage (monitor, control, diagnose, configure) the virtual computing environments. It only exists if a Virtualisation Interface is present. OI is part of I1.
Orchestration Interface
Partial Train Cancelation
Cancel parts of the train journey. E.g., Train 00715 Interlaken - Spiez - Bern - Olten - Basel -> Interlaken - Spiez - Bern
PIS
Passenger Information System
Passenger Information Time
The duration of the platform change announcement
POS
Path Order System
Pay Load Type
The contents loaded in a train. e.g., Dangerous goods is a type of the payload
PER - Perception
performance < of an item >
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.
PRAMSS
Performance, reliability, availability, maintainability, safety and security
Performance requirement
are associated with corresponding Functional Requirements and define how well a particular function has to perform – they are the constraints on that function.
PFH
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]
probability of dangerous failure per hour [EN 61508-4:2010]
probability of dangerous failure per hour [SOURCE: EN 61508-4:2010]
(physical) Behavioural Component
constituent part of the system, responsible of performing a subset of functions allocated to the system, by interacting with other behavioural components and external actors
(Physical) Behavioural Port
port of behavioural component
PCE
The Physical Computing Element refers to the physical device providing compute resources.
Physical Computing Element
(physical) Host component
physical component, (ressource) hosting behavioural components
Physical Link
means of communication/transport relating to the hosting of physical components, used as a medium by exchanges between behavioural components
Physical Port
connection point of one or more physical links allocated to a host component, by specifying how the component can be connected to the others or external actors
PIS - Passenger Information System
Plan Execution
Plateau
A Plateau is a consistent requirement subset of the System Pillar Reference Architecture (SPRA) to be defined by the System Pillar domains. It can be used for market tenders in a specific timeframe and is recommended by and agreed across the sector. In the context of system engineering, a "plateau" refers to a distinct stage or phase within the system development lifecycle (SDLC) where progress or development remains relatively stable or flat for a period of time. It is characterized by a temporary pause or leveling off in the advancement or evolution of the system being developed.
In the context of system engineering, a "plateau" refers to a distinct stage or phase within the system development lifecycle (SDLC) where progress or development remains relatively stable or flat for a period of time. It is characterized by a temporary pause or leveling off in the advancement or evolution of the system being developed. During a plateau, the system or project may have reached a certain level of functionality, maturity, or completion. It can be seen as a natural phase in the development process, where the initial rapid progress slows down, and further enhancements or major changes are temporarily put on hold. This can occur for various reasons, such as: * Technical Stability: The system has achieved a stable and functioning state, meeting the primary objectives or requirements defined for that particular stage of development. The focus during this phase may shift towards fine-tuning, optimization, and bug fixing. * Resource Allocation: The allocation of resources, including personnel, time, and budget, may be temporarily redirected to other areas of priority. This can result in a pause in major advancements for the system on the plateau. * Stakeholder Evaluation: Stakeholders may require time to evaluate and provide feedback on the current state of the system before proceeding to the next phase. This evaluation period can lead to a plateau in development activities. * Planning and Preparation: The system engineering team may use the plateau phase to plan and prepare for the next stage of development. This includes conducting feasibility studies, conducting risk assessments, gathering requirements, or developing a roadmap for future enhancements or releases. While plateaus can be a temporary slowdown in the system development process, they can also provide opportunities for reflection, evaluation, and strategic decision-making. During this phase, system engineers and stakeholders can assess the current state of the system, address any outstanding issues or challenges, and plan for future iterations or developments. It's important for system engineers to effectively manage plateaus by maintaining clear communication with stakeholders, ensuring proper documentation, and utilizing the time and resources available to refine and improve the system before progressing to the next stage of development.
Platform Change Time
Time for a passenger to move from the planned arrival platform to the new arrival platform
Platform Change
A change in the arrival/ departure platform. E.g., Train 00175 arrival in Bern platform 3 -> Train 00175 arrival in Bern platform 7
PWITD
Polarion Work Item of Type Definition
PWITR
Polarion Work Item of Type Reference
Portability
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.
PMAT
PRAMSS Management & Assurance Team
PRAMS
Performance, reliability, availability, maintainability, safety
Procedure
A procedure is a set of instructions for completing a single task or activity within a process. A process is a series of tasks/activities that produce an outcome. In other words, a procedure is the execution of a pre-defined process by means of pre-defined rules.
Process Framework
A process framework refers to a structured and systematic approach for designing, documenting, and managing processes within an organisation for a defined scope.{comment:402}
Process Task
An atomic activity that is included within a process. It is used when the work in the Process is not broken down to a finer level of Process detail. Action intended to contribute to the achievement of one or more outcomes of a process.
Process-System harmonisation dependency
The process-system harmonisation dependency decribes the fact, that in the highly automated CCS processes, which form a mixed sequence of actor actions and system function activation, the integration of a single not harmonized process action or a single not harmonized functional system behaiour already leads to a non harmonized system behaviour demanding for non harmonized operational process steps. Or in other words: A specific process depends on a specific system functionality and vice versa. Therefore harmonising one side in a specific way is only possible by harmonising the other side in a specific way. (image: 2-diagram_20240622-2035.38937.mxg.svg)
Process
Set of interrelated or interacting activities that use inputs to deliver an intended result. * Processes require a purpose and outcome, all processes have at least one activity. * A process defines “WHAT” is to be done, without specifying “HOW” each task is performed.
PdM
Product data management (PDM) is the name of a business function within product lifecycle management (PLM) that denotes the management and publication of product data.[1] In software engineering, this is known as version control. The goals of product data management include ensuring all stakeholders share a common understanding, that confusion during the execution of the processes is minimized, and that the highest standards of quality controls are maintained. PDM should not be confused with product information management (PIM).
Product data Management
Production view
The production view is an information model that is restricted to the needs of a given use case. It is designed to allow data delivery to consumers using a given technology.
PROD
Production
Prognostics: is the ability to predict an impeding failure of a system based on...
Prognostics:{comment:7} {comment:53}is the ability to predict an impeding failure of a system based on the current system conditions [ISBN-13: ‎978-0849398797]. Prognosis technologies typically use measured or inferred features, as well as data-driven and/or physics-based models, to predict the condition of the system at some future time [DOI: 10.1002/9780470117842].
PMO
Project Management Office
Project Milestone.
The planning hierarchy is Release>Project Milestone>Work Package>Task
Properties Topology
The 'Properties Topology' is part of railway infrastructure and defines different properties for a section of track like speed limit, traction system etc.
QoS - Quality of Service
Quality and Assurance
Quality attribute
Quality attribute is a realized non-functional requirement used to evaluate the performance of a system
Question.
Entry in a FAQ or Q&A list. Description holds answer. If there are many answers then workitems of type "Answer" can be linked.
RBC
Radio Block Centre is a computer-based system that elaborates messages to be sent to the train on basis of information received from external trackside systems and on basis of information exchanged with the on-board subsystems. The main objective of these messages is to provide movement authorities to allow the safe movement of trains on the Railway infrastructure area under the responsibility of the RBC. The interoperability requirements for the RBC are mainly related to the data exchange between the RBC and the on-board subsystem. (subset26-2)
Radio Block Centre
RIM
Rail Infrastructure Manager
RNE
Rail Net Europe
ROC
Rail Operating Company
RASCOP
Rail Standardisation Coordination Platform for Europe
Rail Undertakings
RNE TIS
RailNetEurope Train Information System
Railway Hazard
Top level hazard at railway level that can be caused by: * an operational scenario/procedure failure and/or * a system function/component failure. Each railway hazard shall be traced with at least: * One SPPRAMSS-7602 - Operational Hazard, * one SPPRAMSS-7603 - System Hazard
Railway Requirement
Railway requirements are epics, visions, needs or user stories coming from stakeholders as their concrete vision (who, what, why). It can be formulated in a few sentences and has not a strict form criteria. These can be translated to precise operational requirements during analysis processes in case they describe operational epics for the business target picture of an operational area (like CCS or Energy). The can be freely formulated but should follow the writing patterns of epics and user stories. They should be specific enough to be assigned to exactly one System Pillar task.
Railway Undertaking
Railway
The term "railway" is used to represent railway infrastructure managers, railway undertakings, vehicle owners and all other possible combinations of the rolling stock and infrastructure owning and operating companies.
RAM
Random Access Memory
Rationale.
Reasons why another workitem WAS designed this way
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.
Reaction Time
In semi automatic conflict solution, the Dispatcher can decline the executed dispatching measure and override it
Reader Controller
Reader Controller The Reader Controller manages states and failures of the Biometric Readerand/or the RFID Reader.
Real Time
Real-Time Conflict Detection
Determine the difference between the operational plan and the forecast. Conflicts predicted to occur in the future but may be solved before they happen. Conflicts arise from the impact of deviations.
RAID
Redundant Array of Independent Disks
Ref. Loc.
The reference location on the track which the train based distance reading refers to. It is used as a common location reference between the ERTMS/ETCS on-board and trackside equipment (according to the "Reference Location" definition in SUBSET-023, TSI 2023).
Reference Location
Reference.
Hyperlink and/or copy of an external document. See: References
Refering document
any system pillar document, but for glossaries, written by a document author or read by a document reader. The document contains System Pillar Work-items, but for definitions and concepts. The export of a document may contain a table of definitions generated out of the definitions refered to in the document.
RTCC
Regional traffic control centre
RINF
The Register of Infrastructure. (RINF) comprehensively describes the static rail network characteristics and capabilities. It contains network parameters for each subsystem or part subsystem.
The Register of Infrastructure comprehensively describes the static rail network characteristics and capabilities. It contains network parameters for each subsystem or part subsystem.
Register of Infrastructure
Relative position
The Train front end position expressed with a distance from a reference location in a 1D reference frame.
Release.
A package of documents (polarion collection) released by a domain at a certain time
reliability, <of an item>
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]
RAMS
Reliability, Availability, Maintainability and Safety
RCM
The concept of reliability centred maintenance is defined in SPPRAMSS-11144 - [IEC 60300-3-11:2009]. Reliability-centered maintenance (RCM) is a concept of maintenance planning to ensure that systems continue to do what their users require in their present operating context. Successful implementation of RCM will lead to increase in cost effectiveness, reliability, machine uptime, and a greater understanding of the level of risk that the organization is managing.
Reliability Centred Maintenance
Reliable Data
Reliable Data refers to a typical characteristic of data which satisfies the qualities of being trustworthy/low probability of incorrect information/low fault rate of the information, current (not obsolete), complete, and accurate. The attribute “reliable” is not limited or coupled exclusively to safety-related functions since a sufficient level of quality is also required to guarantee a good performance, high availability, and reliability of non-safe functions such as realised by ATO or TMS. Hence, the data quality attribute ‘Reliable’ means safety-related or non-safety-related data that satisfies the Consuming System’s data quality requirements.
RTO
Remote Train Operations
REP - Repository
REP
A Replica is a specific realization of any entity in a cluster of peers used for composite fail safety and/or availability. Replicas of the same entity always run in distinct Compartments deployed to distinct Computing Elements.
Replica
REST
Representational State Transfer
Requirement set
A requirement set can contain all relevant requirements for a given entity (enterprise/operational entity/system/subsystem). Usually this is captured in a requirements document and/or a baseline in a database.
Requirement statement
A requirement statement is the result of a formal transformation of one or more needs or parent requirements into an agreed-to obligation for an entity to perform some function or possess some quality within specified constraints with acceptable risk. Requirements are formal textual “shall” statements that communicate in a structured, natural language what an entity must do to realise the intent of the needs from which they were transformed. (Source: https://portal.incose.org/commerce/store?productId=INCOSE-GUIDEWRITINGREQ)
Retrofit
Addition of new technology or features to older systems. For trains it could be adding an ETCS onboard unit to a class B equipped train.
Reusability
The property of a sub-system to be integrated without any modification inside various CCS possibly deployed in different operation contexts. This is related to "cross acceptance" as defined in [EN50129]:{comment:1336} 3.1.7. {comment:1298}
RFID Reader
RFID Reader Radio Frequency Identification (RFID) refers to a wireless system comprised of two components: tags and readers. The reader is a device that has one or more antennas that emit radio waves and receive signals back from the RFID tag. This reader permits the authentication of the actor.
risk, <of a hazard>
combination of the probability of occurrence of accident and the severity of that accident Note 1 to entry: In French, the term “risque” also denotes the potential source of harm, in English “hazard” (see 903-01-02) SPPRAMSS-4044 - Hazard . [SOURCE: IEC 60050-903:2013, 903-01-07, modified — <of a hazard> has been added and "harm" has been replaced with "accident"]
risk analysis
systematic use of available information to identify hazards and to estimate the risk [Source: IEC 60050-903:2013, 903-01-08]
risk assessment
overall process comprising a risk analysis and a risk evaluation [Source: IEC 60050-903:2013, 903-01-10]
risk evaluation
procedure based on the risk analysis to determine whether the tolerable risk has been achieved [Source: IEC 60050-903:2013, 903-01-09]
Risk.
Value of damage and mitigation for a hazard.
Road Traffic (DRAFT)
Any traffic on a railway track level crossing other than railway traffic.
Roadmap
Visualization of a specific plan
RBAS
Role Based Access Control
Role
A role is described by a set of responsibilities. Roles are used to define the responsibilities of tasks, ensuring that individuals or a group of people perform their assign tasks and contribute to their successful execution.
Roll Away
An unintended and non-powered movement of the train in a direction, which conflicts with the current position of the direction controller in the active desk. Reference: Glossary of Terms and Abbreviation. SUBSET-023. Issue 4.0.0
Route Change
To change the assigned network of the train, including a change in the assigned stops. E.g., planned journey: Interlaken -> Spiez -> Bern -> Basel ...... New Plan: Spiez -> Zurich -> Basel
RU - Railway Undertaking.
Rule.
Design principle that shall used in a certain area. Is used to avoid the need of Rationals for every design element.
RTE
The Runtime Environment refers to the software needed to provide the services of the Runtime Layer in a single Compartment.
Runtime Environment
The Runtime Layer refers to the system services (e.g., application and computing resource orchestration, monitoring of the Functional Applications and the Application Execution Environment, tracing and logging, communication services that are not related to safety, security means incl. authentication, encryption, key storage, etc.) and the communication stack for information exchange between Functional Applications running on the same Computing Environment and with external entities. It may also include an operating system.
Runtime Layer
safe state [821-12-49]
condition which continues to preserve safety [SOURCE: IEC 62425:2007, 3.1.42]
safe state
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]
STE
The Safe Train Extent represents the extent of the track that may be occupied by a train. It is calculated from train-side information (confirmed rear end{comment:6} and max safe front end from ETCS Position Report) and track-side information (track vacancy proving sections like track circuits or axle counters), taking into account the most recent information available from these train- and track-side information sources. For a Fixed (Virtual) Block System, the Safe Train Extent is represented by one or more Fixed (Virtual) Blocks.{comment:9} Remarks: * The Safe Train Extent for a train will be updated when new information becomes available. * For a moving train, it is likely that the train will move outside the Safe Train Extent between updates {comment:23} (image: 1-screenshot-20240904-140007.png)
Safe Train Extent
Safe Train Length Determination
Function of ETCS Level 3.
SET
A Safety Environment Task implements part of the functionality provided by a Safety Environment. Depending on its role in the overall function provided, it has a specific SIL assigned (in-line with total SE SIL definition). It may run replicated in multiple Compartments as SE Task Replicas.
Safety Environment Task
The Safety Environment refers to the software needed to provide the services of the Safety Layer in one single Compartment. Previous definition: The Safety Environment refers to all Safety Environment Tasks needed for a Functional System.
The Safety Environment refers to all Safety Environment Tasks needed for a Functional System.
Safety Environment
The Safety Framework refers to all Safety Environment Replicas needed for a Functional System. Previous definition: new term
Safety Framework
The Safety Layer implements all the technical safety principles related to fulfilling the requirements of EN 50126, EN 50716 (formerly 50128)%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22Physical%20Computing%26lt%3Bbr%26gt%3BElement%26amp%3Bnbsp%3B%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23D6D6D6%3BfontColor%3D%23333333%3BstrokeColor%3D%23666666%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-130%22%20y%3D%22410%22%20width%3D%22240%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%223%22%20value%3D%22Core%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23cac5d3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-120%22%20y%3D%22438%22%20width%3D%2240%22%20height%3D%2225%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%224%22%20value%3D%22Memory%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23cac5d3%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%2250%22%20y%3D%22440%22%20width%3D%2250%22%20height%3D%2225%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%225%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BgradientColor%3Dnone%3Bglass%3D0%3Bshadow%3D0%3BfillStyle%3Dhatch%3BstrokeWidth%3D0.3%3BfillColor%3D%23404040%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22404%22%20width%3D%22370%22%20height%3D%2272%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%226%22%20value%3D%22I3%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-23.61%22%20y%3D%22305.5%22%20width%3D%2255%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%227%22%20value%3D%22I2%22%20style%3D%22shape%3Dnote%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BbackgroundOutline%3D1%3BdarkOpacity%3D0.05%3Bsize%3D15%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-100%22%20y%3D%22386%22%20width%3D%2230%22%20height%3D%2234%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%228%22%20value%3D%22Hardware%26lt%3Bbr%26gt%3B%26amp%3Bnbsp%3BLayer%22%20style%3D%22text%3Bhtml%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-235%22%20y%3D%22410%22%20width%3D%2290%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%229%22%20value%3D%22Virtualization%20%26lt%3Bbr%26gt%3BLayer%22%20style%3D%22text%3Bhtml%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22317.75%22%20width%3D%2290%22%20height%3D%2267%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2210%22%20value%3D%22I1%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3Brotation%3D90%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-155%22%20y%3D%22435%22%20width%3D%2235%22%20height%3D%2216%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2211%22%20value%3D%22I1%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3Brotation%3D90%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-150%22%20y%3D%22345%22%20width%3D%2235%22%20height%3D%2216%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2212%22%20value%3D%22Virtualisation%20Environment%26lt%3Bbr%26gt%3B%26lt%3Bbr%26gt%3BVirtual%20Computing%20Element%26lt%3Bbr%20style%3D%26quot%3Bborder-color%3A%20var(--border-color)%3B%26quot%3B%26gt%3B%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23d5e8d4%3BstrokeColor%3D%2382b366%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-126%22%20y%3D%22325.5%22%20width%3D%22251%22%20height%3D%2243.5%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2213%22%20value%3D%22Runtime%26lt%3Bbr%26gt%3BLayer%22%20style%3D%22text%3Bhtml%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22163%22%20width%3D%22100%22%20height%3D%2267%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2214%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BgradientColor%3Dnone%3Bglass%3D0%3Bshadow%3D0%3BfillStyle%3Dhatch%3BstrokeWidth%3D0.3%3BfillColor%3D%23404040%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22314%22%20width%3D%22370%22%20height%3D%2272%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2215%22%20value%3D%22RTE%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-118.21%22%20y%3D%22190%22%20width%3D%22158.21%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2216%22%20value%3D%22I1%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3Brotation%3D90%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-138.10999999999999%22%20y%3D%22197%22%20width%3D%2228.11%22%20height%3D%2216%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2217%22%20value%3D%22I4%22%20style%3D%22ellipse%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23a0522d%3BfontColor%3D%23ffffff%3BstrokeColor%3D%236D1F00%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-54.599999999999994%22%20y%3D%22172.68%22%20width%3D%2230.99%22%20height%3D%2217.32%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2218%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BgradientColor%3Dnone%3Bglass%3D0%3Bshadow%3D0%3BfillStyle%3Dhatch%3BstrokeWidth%3D0.3%3BfillColor%3D%23404040%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-210%22%20y%3D%22172.68%22%20width%3D%22310%22%20height%3D%2272%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2219%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3Dnone%3Bdashed%3D1%3BstrokeWidth%3D2%3BstrokeColor%3D%23FF1D0D%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-220%22%20y%3D%22170%22%20width%3D%22350%22%20height%3D%2280%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2220%22%20value%3D%22%22%20style%3D%22shape%3DflexArrow%3BendArrow%3Dclassic%3Bhtml%3D1%3Brounded%3D0%3B%22%20edge%3D%221%22%20target%3D%2214%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2250%22%20height%3D%2250%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-50%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20y%3D%22200%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2221%22%20value%3D%22%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3Dnone%3BstrokeWidth%3D2%3BstrokeColor%3D%23000000%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-230%22%20y%3D%22305.5%22%20width%3D%22390%22%20height%3D%22200%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E, EN 50129, EN 50159 (e.g., composite fail safety, fault tolerance, voting mechanisms, redundancy mechanisms for availability, safety communication layers etc.) that are needed to enable the execution of Functional Applications up to SIL4.{comment:1}
Safety Layer
The aim of introducing Safety Platform Independence Interface I5 (Interface 5), is to be able to implement platform independent Safe Functional Applications (up to SIL4) i.e., applications, based on a generalized abstraction between the application logic and the system interfaces, will run unchanged on different platform implementations.
Safety Platform Independence Interface
SRAC
Safety related application conditions are SPPR-2246 - Application Condition relevant for the safety of the application.
Safety related application conditions
SASC
Specific Application Safety Case; SPPRAMSS-334 - [EN 50129:2018/AC:2019-04] ,SPPRAMSS-335 - [EN 50126-2:2017] {comment:104}
Scalability
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.
Scenario
Scenarios are diagrams that describe the interactions between structural elements by focusing on the exchange of information in a given context and with a time axis. They allow the ordering of information sequences and behaviours of structural elements, but can also be used as a basis for specification tests. Finally, their constitution, from top to bottom and from right to left, makes it easier to understand the elements described, even for people unfamiliar with an MBSE approach. Scenarios can be linked to sequence diagrams (SysML wording). Scenarios are suitable to be used for the following model elements: * Regarding abstractions: operational analysis, system analysis, logical architecture, physical architecture * Regarding structural entities: system, system element, logical component, interface layer component * Regarding functions: behaviour definition of function (how functions of structural entities exchange data through exchange items) * Regarding other behavioural aspects: pre and postconditions and invariants as start to end conditions as well as state invariants of the scenario * Regarding purpose: represent, at least, one complete sequence of functional exchanges on a time axis Scenarios are often used with a capability perspective depending on the implementation conditions (pre and post-conditions) and describing a specific context at the system, logical and physical structural elements. For example: * Visualise an initial sequence to achieve a system capability's outcome. * Visualise interactions between entities to achieve the system capability with an acceptable level of risk. * Visualise system black-box behaviour or system interaction behaviour with actors.
Schema meta-model
A data schema is implemented in a known language such as XSD/XML or JSON schema. This allows a computer program to parse data that are known to conform to this specific schema. The schema documents the semantics of data entities so that an intelligent reader can interpret the information in the data. Such a schema can be represented as a meta-model.
SCV-OB - Signal Converter-On-board
secondary functions
"Value analysis defines a “basic function” as anything that makes the product work or sell. A function that is defined as “basic” cannot change. Secondary functions, also called “supporting functions”, described the manner in which the basic function(s) were implemented. Secondary functions could be modified or eliminated to reduce product cost."
SecRAC
security-related application condition [SOURCE: CLC/TS 50701:2023]
Secure Communication
defines an integrity-protected and optionally encrypted channel between two entities. Security is achieved by using TLS 1.3 or OPC UA Secure Conversation.
Secure Component
An implementation, as part of an industrial automation control system, which comprises system components, such as host devices, embedded devices, network devices or software applications on a host device, that implement security capabilities and consisting of a physical encasing, computing capabilities and network communication, and interfacing to the Shared Cybersecurity Services. Examples of CCS secure components are object controller, trackside cabinet, IXL rack, ATO-OB, OBU, ATO-TS, IXL/RBC combination, shared cybersecurity services, security proxy for legacy devices, …) Examples of components which are not meeting the definition of a Secure Component are components with no network communication, e.g. directly connected sensors or displays.
SSL
Secure Sockets Layer
Segment Profile
A Segment Profile is a one-dimensional object that describes a single and consecutive section of track and corresponds to the Track Centreline of that section of track. A Segment Profile has a Start Point and an End Point, which correspond to the boundary points of the section of Track Centreline of that Segment Profile. A Segment Profile defines a set of static infrastructure data required by different on-board applications like ATO, Perception, Localisation, APM. {comment:2} The Segment Profile is part of Application Configuration Data. These data are derived from Infrastructure Data according to the interface data structure requirements of the consumers.
SEMP Link Rule.
Defines how certain Polarion workitems shall be linked. See: SPPROCESS/SEMP Annex D Processes/SEMP Link Rules overview
SEMP Process.
Defines a process in the SEMP. See: SEMP Processes
SEMP Role Allocation.
Name of the person who has a certan role in a certain team. See: Tracker search for role allocations
Sensitivity points
Sensitivity points are any modeled values under a given individual quality attribute that are significantly affected by a change to the architecture
SoC
Separation of Concerns
serious accident
‘serious accident’ means any train collision or derailment of trains resulting in the death of at least one person or serious injuries to five or more persons or extensive damage to rolling stock, the infrastructure or the environment, and any other accident with the same consequences which has an obvious impact on railway safety regulation or the management of safety; ‘extensive damage’ means damage that can be immediately assessed by the investigating body to cost at least EUR 2 million in total; [SOURCE: SPPRAMSS-337 - [Directive (EU) 2016/798] Article 3 Definitions (12) ]
SFC
The Service Function Configuration (SFC) is the implementation of the Configuration Management System. The SFC is a central location technical system that is responsible for managing the BuildingBlock Configurations. Each BuildingBlock deployment is managed by exactly one SFC.
Service Function Configuration
Shared Cybersecurity Services (SCS)
A collection of standard security interfaces (SSIs) of central security functions accessible for all Secure Components in the automation solution. The realization of the Shared Cybersecurity Services (SCS) implements the requirements of the Secure Component Specification as they are considerede as Secure Components as well. The interfaces from Secure Components to Shared Cybersecurity Service are identified by SCS-<service name>. Standard Security Interfaces are identified by SSI-<Service <service name>.
SSS
{comment:7}
Shared Security Service
SRU
Shop Replaceable Unit
Signaller Definition
“Signaller” means: A person of operational railway staff responsible for · route setting of trains/shunting movements (including{comment:2} operating of points and signals from a signal box{comment:1} · issuing instructions · supervision and control of movements in the railway system in accordance with operational rules and regulations{comment:4}
SIL - Safety Interity Level
(SIL2) Hazard mitigation
Safety requirement regarding activities for lowering the effect of a hazard. It reduces the damage to people, property, and the environment by lowering the frequency, damping the consequences. Unlike a safety invariant, a mitigation may not be enforced in a predictable fashion, for instance because it addresses hazards that cannot be influenced by they system themselves. For instance, trespassers on the track cannot be influenced by the railway system. A mitigation can be a realized by * fault detection (hazard will be detected), typically this needs additional activities * failure reaction (after detection the hazard will be excluded), typically this needs additional activities * SRAC safety application condition (hazard will be avoided principly)
(SIL4) Safety Invariant
Safety invariants are safety requirements typically designed to address SIL4 hazards. Safety invariants defining conditions or properties critical to avoid such a SIL4 hazrard. The safety invariant shall be maintained true at any time during operations so that the system does not enter into a hazardous state or condition. Safety invariants shall be constantly monitored and predictably enforced during operations. * Predictably enforced means that the system shall, by design, avoid to enter conditions deviating from the invariant. The acknowledge execution principle is normally applied (e.g., a train enters a switch only after the switch move to position is acknowledged as safey finished). As such, Invariants are often used in formal methods to validate the system design. They may also be input to fault tree analysis, or other safety assessment techniques to ensure the robustness and reliability of systems towards defects. * Continuously monitored means that the invariant fulfillment shall be measured continuously or frequently enough to detect deviations early enough to mitigate them effitciently. Deviations shall lead to a immediate corrective actions to prevent accidents or failures (safety reaction).
SOAP
Simple Object Access Protocol
SERA-CCS
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
Situation
A logical combination of modes and states using logical operations (AND, OR, NOT) representing the superposition of modes and states occurring simultaneously at a given moment.
Skip Stop
Remove a planned stop
Soft Key
Soft Key Context-dependent key which consists of a Hard Key with an associated label on the Display Area. When using a soft key technology, the driver action is done via the Hard Key adjacent to the label.
Software Configuration Data
The Software Configuration data refers to executable binary files from supplies which are usually required to install software on the systems.
Software is software that encompasses both : the operating system and the computer application that runs the computer. They are both essential for the operation of a device.
Software
SP - System Pillar
SC2.x
This refers to the ERJU contracts for SP signed every year; SC2.1 for the first year of developmeent and so on. The SP domains are part of the "Lot 2" in the overall ERJU project (e.g. IP, SP).
Specific Contract for Lot 2 of year x
Specific national product functionality
The set of functions of a national specific product, including system behavior on electronic or analog system and user interfaces
Specification Task
* Result: specification for an artifact * Usually ends on CENELEC P4 * Left side of the CENELEC “V”
SPT1-railway System - Common business Objectives (rev. 63268)
SRAC.
Safety related application condition.
SRD
Single Rules Database [SOURCE: ERA, https://www.era.europa.eu/domains/registers/srd_en ]
SRS
System Requirement Specifications
Stakeholder needs
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.
Stakeholder Requirement
Stakeholder{comment:42} requirements are precise requirements that are derived from railway requirements and the operational analysis.{comment:23}
Stakeholder
Individual or organisation having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations. 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.
Characterizes a stakeholder
SCI-OP
Standard Communications Interface – Operational Plan
Standard Interfaces
Add definition for standard interfaces
SSI
Standard Security Interface
STIP
The Europe’s Rail (EU-Rail) Standardisation and TSI Input Plan (STIP) is a collection of all outputs from EU-Rail (Innovation and System Pillar) which contribute to the goal of harmonisation of the railway system. The harmonisation topics are categorised in technical domains and described by the foreseen harmonisation channel (TSI, EN standards, SP document), the time horizon as well as dependencies with existing regulations, standards, and R&I activities.
Standardisation and TSI Input Plan
standard/routine operation
operational production processes that routinely occur in the day-to-day of an operational railway network, both non-degraded operations and routine degraded operations. Standard/routine operation apply to all operational categories - i.e. All GoA levels,
Start Occupancy Location
The location point where the infrastructure element (track, signal, switch, etc..) occupation has started
Start Occupancy Time
The timestamp where the infrastructure element (track, signal, switch, etc..) occupation has started
State Machine
collection of states connected by transitions
State Transition
A change of state toward itself or toward another state. A transition is characterised by a trigger which can be a boolean condition applied on certain model elements, such as functional exchanges.
State
An observable and measurable attribute used to characterise a behaviour of an entity during which some invariant condition holds. States can be applied to elements such as actors, systems or subsystems.
Static (or semi-static) data
Static (or semi-static) data refers to information or data that remains unchanged or constant over time. It is data that does not require frequent updates or modifications. Static data typically includes reference data, constants, configuration settings, or any other data that remains consistent throughout the operation of a system or application. This type of data is often used as a foundation or reference point for various processes or calculations within a system. Static data is generally stored in a read-only format and is not subject to frequent modifications or user interactions. This is often data that requires a homologation process before it can be applied on a system going in operation. However, it can also include data that does not require a homologation like IP-address, security patches, etc. Example of statical data: software, firmware, parametrisation file, data related to the topology stored in an interlocking, braking curves stored in the ETCS on-board, etc.
STIP Milestone.
Standardisation and TSI Input Plan Milestone
STM interface
Interface of the Specific Transition Module of a train
STPA
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.
Struct
A struct is a named and organised structure for storing a set of coherent information items. It is a class without methods.
Sub Process (Activity)
Set of cohesive tasks of a process
Sub-system (sometimes called “Building Block”)
Sub-systems are along ARCADIA systems on System Level 5. Not to be confused with sub-systems in the TSI / interoperability directive. In the TSI / interoperability directive context a sub-system shall be regarded as a interoperability constituent{comment:1505} A sub-system is a part of a system, which is not split into smaller entities. It represents a leaf element in the hierarchy of systems-of-systems. Physically speaking, a sub-system is either a piece of hardware plus software, or just a piece of software. A sub-system is a source able unit of the CCS system, in particular: * a sub-system can be individually tendered to a supplier, * a sub-system can be built individually by a supplier, * a sub-system must be integrated into a system, which includes all necessary test, verification, certification and validation activities depending on the level of harmonisation. The harmonisation of the sub-system’s features is to be defined according to the requested level: * Functional Apportionment, * Interoperability, * Exchangeability, or * Interchangeability.
Subsystem
Subsystems are along ARCADIA systems with standard interfaces on System Level 5. Not to be confused with subsystems in the TSI / interoperability directive. A subsystem is a part of a system, which is not refined any further during the specification task(The term subsystem is used in this document following the referenced architecting standards, it does not correspond to the subsystem definition as in the Interoperability Directive.). It represents a leaf element in the hierarchy of systems-of-systems. A subsystem is defined by the following characteristics: * For each subsystem exists a set of specification documents, that allows a supplier to build that subsystem, ideally without the need for further documentation. * The level of strictness of the specification can be variable: * Interoperable specification: Strict standardisation of all interface aspects that are needed for to systems to fulfil a defined set of operational capabilities together on runtime. * Interchangeable specification: Standardisation of all interface aspects that are needed to exchange one of the systems with the lowest reasonable integration effort. * Core standardisation specification: An interoperable standardisation that defines a guaranteed minimum of interoperability, but allows and gives room for specific and perhaps incompatible extensions that are only used, when all involved systems have them. * Guideline: A recommended specification that can be used as a whole, or can be used partly or changed. * A subsystem can be implemented as software only, as hardware only, as a mixture of both depending on the strictness of the specification (the specification can leave that aspect open). * Each subsystem can be individually tendered to a supplier * Each subsystem can be built individually by a supplier * Each subsystem must be integrated into a system, which includes all necessary test, verification, certification and validation activities. Some non-functional requirements (e.g. weight constraints or physical dimension constraints) will be allocated to subsystems.
Supplier
The company or organization providing a component, product or system.
Supply Chain
IACSs are typically composed of products and services integrated and tested to work together. Each of these products and services is provided to the asset owner by an organization (which may include the asset owner) that is generally referred to as a supplier. Each supplier often has suppliers of its own, and each of these second level suppliers may have suppliers of its own. This cascading of suppliers is referred to as the supply chain. (from IEC 62443-2-1, Org 1.6)
Supporting Information
Information not directly translatable into localisation information but needed to provide the desired output. This information will be used by internal ASTP processes to enable, improve, or validate localisation information.
Support.
Used for support issues in Polarion
Switch
Switch Physical component which allows a selection of 2 to N states and keeps the state until its position is changed.
Electrical switch. Closes or opens a circuit.
Syntax
The arrangement of words and phrases to create well-formed sentences in a language. "The syntax of the English language". For more details on requirement syntax.
System Actor
Actors are entities outside the system under consideration (either humans or other technical systems) that interact with the system through its interfaces.
System and Innovation Programme Board
System and Innovation Programme Board advises the Executive Director on project and programme management of the JU including interaction between the two pillars as well as change management and conflicts, supported by the System Pillar Core Group
SAD
System Architecture Description
System Capability
Description of a high-level behaviour of a system and its interaction with other involved entities, which yields an observable outcome. The system capability is the system’s expected ability to provide a high-level service allowing it to carry out an operational objective. A system capability represents a system usage context. It is characterised by a set of functional chains and scenarios that it references, and which more precisely describes the conditions for performing the system functions that contribute to it. A capability can also reference a function that contributes to it by itself. A capability can use one or more other capabilities that it will reference. Although the ARCADIA method describes system capabilities from the system perspective. We have decided that a deviation from the established method is preferred for our purposes. So the system capabilities shall be written from an actor's perspective, similar to use cases. In order to have a greater distinction between capability and function and to be compatible with SysML.
System Configuration Data
The System Configuration data refers to use-case specific parameter data i.e, a static data set required to configure systems with primary information before being put into operation. These data consider national and (supplier)specific operative environments. Some examples for parameter data can be: * Traffic CS Domain: National safety rules, safety patterns for supervision of the safety logic, and the configuration of safety checks, ATO Transactor default contact information, national values * TM Domain: Min/max extent of Movement Permissions * Track Asset Domain: Drive engine type of the point machine/other track equipment, threshold for turnaround time, communication parameters (e.g. Protocol, IP address, hardware address)
System Context
Describes the system relationships and environment that exist around a system.
SDLC
The System Development Life Cycle (SDLC) is a structured approach or methodology used in system engineering to guide the creation, deployment, and maintenance of systems. It provides a systematic framework for managing and controlling the entire process of building a system, from inception to retirement. The SDLC provides a structured approach to system development, ensuring that all necessary activities are carried out in a logical and controlled manner. It helps in managing risks, controlling costs, and delivering high-quality systems that meet stakeholder expectations.
System Development Life Cycle
SEMP
System Engineering Management Plan
System Function
A SPPR-2598 - Function derived during system analysis.
System Hazard
Hazard whose cause is related to a failure of one of the system functions/components. These hazards are managed by means of the "Hazard" Work Item.
System Levels of the System Pillar
The system of systems approach is used inside the System Pillar to recursively refine the structure of the architecture down to the level of subsystems. The following figure shows the decomposition of a system of systems on one consistent example spanning 5 layers of refinement. Level 5 is the actual subsystem layer and is visually integrated into the bottom layer in the following figure to be able to show the relationship to logical components. (image: 1-screenshot-20221229-202431.png) Figure {caption:Figure}: System Level 1-5 combined view
SOI
System of Interest
SoS
According to ISO 21839, a system of systems is set of systems that interact to provide a unique capability that none of the constituent systems can accomplish on its own. A system of systems in our understanding at least comprises two constituent systems. A system of systems itself can be nested as a constituent system in a larger system of systems, i.e. system of systems can span multiple levels recursively.{comment:1}
System Of Systems
System Pillar baseline
A "System Pillar baseline" is a baseline covering whole or part of the deliverables identified for the System Pillar project. See the System Pillar Configuration Management Plan for more information.
System Pillar Core Group
System Pillar Core Group Manages the common business objectives and deliverables from the Tasks
SPC
System Pillar Coregroup
System Pillar deliverables
The main output documents of the System Pillar are described in List of System Pillar deliverables.{comment:68}
SPDT
System Pillar Domain Team
SPSG
System Pillar Steering Group monitoring the progress of the System Pillar
System Pillar Steering Group
System Pillar Unit
System Pillar Unit Chairs the System Pillar Core Group
System Pillar
System Requirements Specification
System Requirement
System requirements are precise functional or non-functional requirements that are derived from system analysis or system architecture. They are recursively used on system level and subsystem level, where a subsystem is specified as system.
SuC
The defined scope of components and its interrelation the security analysis and security specifications are made for. The system under consideration is defined in Security Architecture. The red rectangle displays the scope. These are the components in the system under consideration (SuC).
System under Consideration (from SPPRAMSS-334 - [EN 50129:2018/AC:2019-04])
System under Consideration [SOURCE: SPPRAMSS-4697 - [EN IEC 62443-3-2:2020]]
System under consideration
System
Arrangement of system elements, that together exhibit a stated behaviour or meaning that the individual constituents do not. According to ISO 15288 a system is “a combination of interacting elements organised to achieve one or more stated purposes. “. In terms of this document, a system in black box view is furthermore defined by: * interfaces to actors outside the system, defining the system boundary * at least one function allocated to it * at least one capability that the system delivers as a service to the actors A system in white box view can be further refined into (exclusive or): * into a more granular systems, hence making itself to a system of systems * into subsystems on the lowest level of system of systems refinement In both cases, a system is a conceptual entity that aggregates the properties of its constituents but is not the element that defines the properties itself. A system is hence subject to the emerging properties of its constituents. Usage context definitions of term „system“: * Constituent system: according to ISO 21839, a system that forms part of a system of systems * System of interest: according to ISO 21839, a system whose life cycle or properties are under consideration in a given context
Subject of interest of the engineering activities described by ARCADIA, which is also an organized collection of elements working as a whole.
T2OD - Task 2: Operational Design Domain
Task 2: Operational Design Domain can be abbreviated as 'T2OD'.
Tailoring of requirement breakdown
SoS engineering can go wrong (quite often) if done in an overengineered and abstract way. If every artefact is created on every System Level (e.g. 5-7 levels and types or requirements that are broken down), the workload is artificially multiplied without need, and this policy is not creating a really good work split. To avoid this, every work process uses a tailoring approach which means * “Copy” (reference) things from a higher level, if possible like they are * Break up and translate through the levels that you really need, and not more. * Be sure that the right requirements are broken down to System Level 5 specification and to support concept definition in projects and manage the system, its performance and standards management. * Operational rulebooks include all that is needed. * Support design phases in managing requirement allocation, interfaces managements, testing planning. Engineering rules are complete and fulfilling the requirements * Support integration phase supporting data analysis, simulation process, anomaly resolution Programs can fail (cost, duration, time to market) because of too long and intense workout on System Level 1-4 (overengineered analytical architecting) without getting to real implementation specification and questions. If for example a high level requirement coming from the stakeholders can be addressed directly to System Level 5 without risk, this should be done. This is a (workflow) “tailoring” decision to be taken in the functional teams. Wrong approach: Breakdown every work item on every level. Right approaches: * Specific workflow tailoring, and * Generic workflow tailoring “Specific (workflow) tailoring” (intelligent work assignment per work item) = Single work items are only assigned on levels, where work is really needed (image: 1-image1.png) Second example for specific workflow tailoring: Two different process break downs * Op. process “Emergency stop of a train”, splits up “untailored” into work assignments… * System level 1/2: Define generic roles of CCS and TMS in this case * System Level 3 TMS: Define TMS process for it * System Level 3 CCS: Define generic roles and basic information flow of Level 4 CCS Systems for it * …. * System Level 4/5 Traffic CS: …. * System Level 4/5 Train CS: … * … * Operational process “Reset object controller” shall be tailored into these work assignments * System Level 1/2: Skipped * System Level 3: Delegate interface coordination to Traffic CS / Trackside Asset CS * System Level 4/5 Traffic CS: Define process for the remote reset * System Level 4/5 Traffic CS: Define process for the local OC reset * System Level 4/5 Trackside Asset CS: Define process for the remote OC reset * System Level 4/5 Trackside Asset CS: Define process for the local OC reset Consequence: With specific workflow tailoring, the analytical system levels are incomplete (see table above). “Generic (Workflow) Tailoring” = Certain work item types are worked out only on certain layers Example: Examples: | CBO | Requirements | Operational Processes | Logical Components System Level 1/2 | X | X | Business process | System Level 3/4 | | X | X | System Level 5 | | X | X | X Coordination of “tailoring” is the main role of all “functional teams” (see chapter later in the document). A good tailoring fulfils the following requirements * Work is parallelized early and in a precise way (independent work) * No “dummy” work items just for the sake of symmetric work item break downs in the system of systems * The derivation process does not “block” everything because of sequential working dependencies * The level of details of the specification is always only as good as needed on System Level 1-4 (analytical clarification = work preparation) so that the teams working on System Level 5 know what to do. * A domain team on System Level 5 – the real specification level – can concentrate on its local work functions, engineering rules, and the collaboration with other domain teams concerning concrete interfaces * A task level architecture team (ARC, OD, MIG) just focusses on the role to provide all needed specifications (especially requirements, process definitions, functional allocation) that enables the work on System Level 5 Team - without already creating too much design “Tailoring” is the work to dynamically assign work items to the system level that shall work on them. A tailoring process is executed by a functional team. The typical workflow for tailoring is * An “inbox” (automated workflow, state driven) for new/changed work items is automated (e.g. inbox for new requirements, or for a proposal of process design change) * Some work items can be assigned automatically by rules (generic tailoring) * Else: The responsible person (role owner in the functional team) checks (evtl. discusses) the new work item * The new work item is assigned to a system level and team. This happens to all types of inputs and changes. Conclusions: * Do only the minimal needed work on System Level 1-4, needed to get good Level 5 specifications, rulebooks, etc. * Apply a generic tailoring to avoid that everybody is working on the same things * Design a workflow that assigns work items dynamically to the right level.
TAP - Telematics Application for Passenger Service
target picture
The following are considered minimum characteristics (baseline) for the targeted solution: * Operational production processes directly related to the railway traffic commercial production are harmonised. This includes ETCS related processes, processes for securing and releasing railway lines/areas to/from maintenance and commissioning, operating through and recovering from degraded (non-regular) operations, reacting to and managing emergency situations (from operational perspective). * Railway system operates ETCS L2, without signals. * Railway system operates EULYNX type equipment.
Target System
the target architecture of the signalling system as a whole
A Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as Task Replicas. Previous definition: A Functional Application Task implements part of the functionality provided by a Functional Application. Depending on its role in the overall function provided by the Functional Application, it has a specific SIL assigned (in-line with total FA SIL definition). It may run replicated in multiple Compartments as FA Task Replicas.
Task
TCMS - Train Control & Management System
TCO
Total Cost of Ownership
TDS - Train Display System
Technical Committee
technical delay
delay incurred in performing auxiliary technical actions associated with, but not part of, the maintenance action EXAMPLE Rendering the equipment safe (such as immobilising, cooling, isolation and grounding). [SOURCE: IEC 60050-192:2015,192-07-15]
TRL
TRL 1: Basic Principles Observed TRL 2: Technology Concept and/or Application Formulated TRL 3: Experimental Proof of Concept TRL 4: Technology Validated in Laboratory TRL 5: Technology Validated in Relevant Environment TRL 6: Technology Demonstrated in Relevant Environment TRL 7: System Prototype Demonstration in Operational Environment TRL 8: System Complete and Qualified Through Test and Demonstration TRL 9: Actual System Proven in Operational Environment
Technical readiness levels
TSI
Technical Specification for Interoperability
Technical Specifications for Interoperability
Technical user
A technical user is either a software process or device
TAF/TAP
Telematics Applications for Freight/Passenger Services
TAF
Telematics Applications for Freight
TAP
Telematics Applications for Passenger Services
TCR
Temporary Capacity Restrictions
Temporary Shunting Area (TShA)
Temporary Shunting Area (TShA) A temporary shunting area is an interlocked area{comment:15} temporarily set up to allow shunting operations. A temporary shunting area is always under the responsibility of a Shunting area manager. (OR.DEF.161 - Banedanmark)
Terminal operator
Test Case.
Defines a setup for a test run
Testability
A sub-system that is designed for testability will be ready to show that it fulfils the requirements needed by the overall system. Testability is not an attribute of the sub-system/module itself but has to be designed into architecture and interfaces.{comment:1299}
Text.
Used for any type of sketching, non-papers, protocols, etc.
The set of all traces together is called a “model”.
The "Trace" for a work item chain/tree/graph
* A Trace is a chain of all linked work items (a “directed graph” of nodes and links), that resolve all dependencies of a single work item * Example trace (in this case a “simple tree of nodes”, but can also be more complex): * A common business objective is solved by * a list of operational capabilities and requirements which are implemented in * a list of operational processes which need * a list of system capabilities and functions which are allocated in * logical components that are implemented in * physical subsystems which have * a list of precisely defined interfaces and * engineering rules.. * A trace is valid if all derivations are complete and correct. * A trace is complete if all dependencies are resolved by specified and verified work items (down to the implementation of detailed operational rulebooks and system handbooks, engineering rules and FFFiS interface specifications) * The overall specification is complete when all objectives, operational capabilities, and operational requirements are resolved by complete traces. * Example of the trace of one requirement (red node) down to functions, processes and components (other colours) (image: 1-Grafik_1780564629.png)
Threat landscape
Threat landscape is used in this document as synonym for threat environment. Threat environment (definition from CENELEC TS 50701, IEC PT 63452) environment summary of information about threats, such as threat sources, threat vectors and trends, that have the potential to adversely impact a defined target (for example a company, facility or SuC)
Timeframe
amount of years for a certain level of equipment or migration phase
Timestamp
The date and time formatted in YYYY-MM-DD hh:mm:ss.SSSZ as per ISO 8601{comment:74}
TIMS - Train Integrity Management System
TLS endpoint
The TLS endpoint is a Secure Component using TLS-protected communication (client and server).
TLS
Transport Layer Security (source: SPPRAMSS-1705 - [UNISIG Subset-146] )
TO BE REUSED
Tool Requirement.
Used to store issues for the optimisation of Polarion
Tool
An instrument that, when applied to a particular method, can enhance the efficiency of the task, provided it is applied properly and by somebody with proper skills and training.{comment:409}
TWG
Topical Working Group
Touch Controller
Touch Controller Controller which manages the states and failures of a Touch Panel.
Track Change
To change the assigned track to a train while maintaining the same journey stops
Track Topology
The 'Track Topology' is part of the railway infrastructure and defines the tracks and connections that allow trains to travel from one track to the next.
TACS
The scope of the system Trackside assets control and supervision is the layer with trackside assets and respective objects controllers. The system is responsible for the control and supervision of the trackside assets to ensure safe track usage as required by the system Traffic Control and Supervision. The system supports diagnostic, maintenance and security functions as required by the system Transversal CCS.
Trackside Assets Control and Supervision
Trackside Assets
All technical systems and products that are necessary for safe train operation from infrastructure perspective that are not located in the train.
Trackside Assets are elements on or near the track which are used to monitor (using sensors) and/or control (using actuators) the movement of vehicles through the railway network. to provide a safe route through the railway network. They can be switchable or non-switchable and are controlled by the actors Trackside Asset Control and Supervision.
Trackside Asset
Trackside Protection System
The Trackside Protection System is the core system of Traffic CS, implementing the safety critical functions.{comment:16}{comment:25}{comment:68}
TTD
The proof of the presence or absence of trains on a defined section of line
Trackside Train Detection
Trade-space factor
"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).
Tradeoff points
Tradeoff points are architectural elements that affect different quality attributes simultaneously or architectural element to which multiple quality attributes are sensitive.
Traffic CS
TBD - Traffic Control and Supervision is the CSS Trackside System in charge of the control and supervision of the Railways Traffic. It includes ETCS Trackside and ATO Trackside.
Traffic Control and Supervision
TMS
Traffic Management System
Traffic Management System (double, needs to be deleted)
Traffic Management System is used to manage the operation of the railway system and to ensure efficient recovery when unexpected traffic disruptions occur.
Traffic Manager Operational Area of Control defines the region under the respons...
Traffic Manager Operational Area of Control defines the region under the responsability of only one Traffic Manager
Train Activate
Activate a deactivated train
Train Consist Change
Add and/or remove wagons from the train or any other attribute in the train consist
TCMS
implicit-from-entry-label: Train Control and Monitoring System
Train Control and Monitoring System
Train Deactivate
Deactivate an active/ standby train
Train Dispatcher: A Train Dispatcher is an Infrastructure Manager operator that...
Train Dispatcher: A Train Dispatcher is an Infrastructure Manager operator that acts from a workstation in the Control Room in order to direct and facilitate the movement of trains over an assigned territory, which is usually part, or all, of a railroad operating division. The dispatcher is also responsible for cost effective movement of trains and other on-track railroad equipment to optimize physical (trains) and human resource (crews) assets.”
Train Display System Controller
Train Display System Controller The TDS Controller interacts with system (CCS, TCMS,CVR) and manages the Desk Display Area.
Train Display System (TDS)
Train Display System (TDS) The Train Display System is the train cab display system that comprises and manages one or more displays on the driver desk and a driver interface. It is composed of at least one display with the associated input devices, at least one loudspeaker and at least one Train Display System Controller. It offers a standardised communication interface to systems that need driver interaction.
Train dynamic data
Train axles, train length, train size and train wagons are considered train dynamic data.
Train front end
It is represented by a point on the carriage floor along the longitudinal axis. This point is the most forward element belonging to the engine with regards to the train orientation.  For the absolute position it is expressed in a geocoordinate reference frame . Note: if the ASTP is not installed in the first vehicle, the absolute position is given from carriage front end where the ASTP is installed.  For the 1D train front end position it is derived from the bogie pin 1D position by adding the distance between the bogie pin and the train front end. Rationale: Thanks to the absolute positioning of the ASTP and the Map Data, the absolute position of the bogie is determined. From this absolute position the bogie pin 1D position can be derived. Note the absolute error between the bogie and the train front end, and the bogie and the train front end on the track centreline is negligible (less than 0,02cm for curve with a radius of 150m).
Train Integrity Monitoring
Onboard monitoring system that makes sure that during a train ride the train is still complete and has not accidentally split. Function of ETCS Level 3
TLM
The Train Length Master (TLM) is the OTL device located in the driving cab. It is in charge of collecting from all the OTLs{comment:12} information related to the train length. For each OTL, the Train Length Master is expected to receive: * Couplers status of the wagon * Consist ID * Wagon Length It is important to highlight that the couplers status identifies if that node is on the head or in the tail of the train. How the OTL recognizes the couplers status is linked to the LCDF function embedded in the DAC. A similar solution can be implemented in case of classical couplers adoption. Moreover, the TLM shall: * calculate the train length by summing the single lengths received * store the composition of the train by using the vehicle IDs received * store the HoT and the EoT by identifying the IDs of the OTL which have one free coupler The last task of the TLM is to send the information to the TLMF. This list of information is described in [2]. It is trivial that all these information will be managed on channel A and channel B.
Train Length Master
TLMF
The Train Length Merging Function (TLMF) receives information from TLM-A and TLM-B.{comment:23} The main task of the TLMF consists of comparing the information received. If the both paths are sending coherent information, then the TLMF shall forward the data to the ETCS-OB. At least following checks are required: * Train length A (TLM-A) is equal to Train length B (TLM-B){comment:22} * List of vehicle IDs on path A is equal to List of vehicle IDs on path B * (optional) HoT A and EoT A correspond to HoT B and EoT B Once the checks are passed for the first time, during the train inauguration, the TLMF shall send the train length to the ETCS-OB and then starting a continuous monitoring of the information consistency. The TLMF shall inform the ETCS-OB when the train length information is no more available (e.g., the information is not coming from one channel, there is a misalignment between the two channels, etc.) and shall stop the monitoring when a reset takes place (e.g., end of mission).
Train Length Merging Function
Train Object
Train Object is the object needed by the Traffic CS to manage the connected trains currently performing their mission. Note: This Train Object could nevertheless correspond to a train not (yet) localised by MBS. If a Train Object is referenced as a geometric extent, the extent is the extent of the Train Location. RCA source: (rMOB)
Train Running Number
A number under which the train is operated. Reference: Glossary of Terms and Abbreviation. SUBSET-023. Issue 4.0.0
Train Sequence Change
Change in the train sequence among the other trains on the network
Train Splitting
Train Splitting is the physically separation of one train into two or more trains possible anywhere on the network{comment:51} and normally based on the timetable as planned splitting. New trains after splitting can continue moving in the following directions: - move in the same direction as approached, but splitted - move in the opposite direction as approached, but splitted - move in two different directions.{comment:5}{comment:52} Specific procedures of the Railway Undertaking describe (train specifc) details to perform the splitting. Unplanned splitting needs the communication with the signaller.
Train Standby
Change the status of a train to standby (on hold until the train run starts)
Train true acceleration
The real signed acceleration of the train along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame.
Train true position
The real position of the train front-end along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame or a geocoordinate reference frame .
Train true speed
The real absolute speed of the train along the track centreline. It is expressed using the 1D reference frame defined by the bogie reference frame.
Train-centric Track Occupancy
With train-centric approach the trackside focus is on representing a railway vehicle with an extent in a topology rather than on representing anonymous occupancy states of fixed sizes reported by TTD systems as in today's conventional block-centric signaling systems. In other words, the term "train-centric" refers to a "train-oriented" view of the trackside system about the track occupation caused by a railway vehicle, e.g., an ETCS-equipped train. This view is achieved by fusion of localisation information from both train and trackside. A train-centric track occupancy determination is based primarily on localisation information received from the railway vehicle, e.g., from trains sent via ETCS Train Position Reports. The trackside system will also take into account additional trackside localisation information if available such as Trackside Train Detection (TTD) inputs, for example to: * Adjust the trackside view of track occupancy by train, based on clear TTD sections at the front or rear of the train * Detect movement of non-communicating railway vehicles, e.g., trains/wagons not equipped with ETCS and trains equipped with ETCS that have lost communication * Handle degraded situations, such as loss of train integrity.
“Train” something
Create Training material, provide training, support trained people
TEN-T
Trans-European Transport Network based on EU-Regulation No 1315/2013
Trans-European Transport Network
Transport Layer Security [TLS]
TLS is normally implemented on top of TCP in order to encrypt Application Layer protocols such as HTTP, FTP, SMTP and IMAP, although it can also be implemented on UDP, DCCP and SCTP as well (e.g. for VPN and SIP-based application uses). This is known as Datagram Transport Layer Security (DTLS) and is specified in RFCs 6347, 5238 and 6083.
Transport Layer Security
TCCS
Transversal CCS domain
TRD - Train Data
Basic parameters
In accordance with the relevant essential requirements, the Control-Command and Signalling Subsystems are characterised by the following basic parameters: (1) Control-Command and Signalling reliability, availability and safety characteristics relevant to interoperability (point 4.2.1); (2) On-Board ETCS functionality (point 4.2.2); (3) Trackside ETCS functionality (point 4.2.3); (4) Mobile communication functions for railways RMR (point 4.2.4); (5) RMR, ETCS and ATO air gap interfaces (point 4.2.5); (6) On-Board Interfaces Internal to Control-Command and Signalling (point 4.2.6); (7) Trackside Interfaces Internal to Control-Command and Signalling (point 4.2.7); (8) Key Management (point 4.2.8); (9) ETCS-ID Management (point 4.2.9); (10) Trackside Train Detection Systems (point 4.2.10); (11) Electromagnetic Compatibility between Rolling Stock and Control-Command and Signalling trackside equipment (point 4.2.11); (12) ETCS DMI (Driver-Machine Interface) (point 4.2.12); (13) RMR DMI (Driver-Machine Interface) (point 4.2.13); (14) Interface to Data Recording for Regulatory Purposes (point 4.2.14); (15) Trackside Control-Command and Signalling objects (point 4.2.15); (16) Construction of equipment used in CCS subsystems (point 4.2.16); (17) ETCS and Radio System Compatibility (point 4.2.17); (18) On-Board ATO functionality (point 4.2.18); (19) Trackside ATO functionality (point 4.2.19); (20) Technical documentation for Maintenance (point 4.2.20).
TSI CCS 2023 - 4.1.1. Basic parameters
‘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]
TTD - Trackside Train Detection
UML
Unified Modeling Language
UNIFE
Union des Industries Ferroviaires Européennes
UNISIG
Union Industry of Signalling
UNITEL
Union Industry of Telecommunications
UNISIG - Union Industry of Signalling
UTO
Unresolved Trackbound Object is the object needed by the Traffic CS to manage a contiguous track area where track vacancy is not proven and cannot be linked to any connected train (Train Object). RCA source: uMOB X2R5 source: Unknown Track Status Area (part
Unresolved Trackbound Object
Updateability
Updateability refers to the ability of a system to receive and incorporate updates or patches, e.g. to address security vulnerabilities. Updates are often provided to improve the performance of the system, stability, or security without introducing significant changes to its functionality.
Upgradeability
Upgradeability refers to the ability of a system to undergo significant enhancements or improvements in terms of its features, functionality, or performance. Upgrades typically involve the installation of a newer version or release of the system that offers new capabilities or improved performance compared to the previous version.
Uplinking
To handle deviated new designs or new/changed external inputs the whole “engineering” has to be understood as * Work items with type, versions, and state * Their links with versions, link roles and state The engineering database is in the end a “directed graph” with “nodes” (work items) and links (graph just indicated in the picture):{comment:13} (image: 3-image3.png) The basic principle for continuous integration using an ALM+MBSE system is based on the mathematical process of “adding a directed graph to another directed graph which can overlap in certain nodes”. This is called “Uplinking” in the System Pillar. Existing graph (e.g. ALM master database) New graph fragment (external contribution) “Merging these graphs” ="uplinking" (of conceptual, requirement and modelling work items) is the most feared job to do in system engineering when done manually. A strong system support is necessary. This merge can happen when * A daughter-system graph is “uplinked” to the mother-system (master) graph * An external contribution is integrated (perhaps again and again) * An external editor was used to edit elements in the mater database (e.g. ALM= master database, MBSE-Tool = editor for a part of the work items) * A bottom-up process is faster (domain team) then the top-down process (Level 3) * The architecture teams is faster concerning functional design then the operational design team with the process design. Or both are fast then the requirement feedback from the migration team is coming. * Etc. A lot of isolated (time, team, engineering tool) asynchronous designs will occur in the System Pillar. They lead to these synchronization needs: This does not mean, that “synchronization” is the standard choice to integrate work. The preferred choice is top-down design and working in the same system whenever possible. But synchronization will anyway be needed very often. The sync process of these integration steps is the same. All integration work (conceptual level, system models, requirements, etc.) is about this merging process. The following things can happen: * A new node (work item) is added and linked to 0-n{comment:14} old nodes * An old node is changed or deleted or relinked in another way The indirect effect of such a change/add process can be * In a “trace” (chain of work items) links can get{comment:15} “suspect” if earlier links or nodes were changed (through partially-automated impact analysis) * New workflows are triggered by new work item states. If a new node is created with the state “draft”, it is because of this assigned by a tailoring process in a certain way. To add the new fragment{comment:16} to the exiting master database (can only be done efficiently with automated ALM systems) the following work steps are executed * Convert contribution to graph structure (work items/links), check consistency * Analyse and assess new contribution * Perhaps adapt/change contribution before synchronisation * Create difference to master database automatically * Assess difference and indirect impacts * Replace/link fragment in database (fully or partially) or revoke it * Check and analyse the new state of the master database Simplification of synchronization * Assigned designated areas to be designed only in certain teams/tools/places (only connecting links to be synchronized) * Check separated designs together frequently to avoid large deviations How often synchronize/integrate? * Best: Directly work on the master model (possible with ALM, performance problems with MBSE tools) * Second best: Do the sync/integration very frequently (daily, weekly, or monthly) * Worst: do it once in 6 months --> Risk of unsolvable incompatibility and lost work is increased Conclusion: * We need a very efficient and sophisticated tool support for the synchronization/integration process * The integration/synchronization process will create large efforts in the Modelling Service Team The concrete rules, when and how “uplinking” is done, are defined in chapter 20.
URA
A Usage Restriction Area (URA) limits or constraints operation on a part within the Area of Control. URAs can be created according to an Operational Plan (e.g. for enabling construction works) or in response to an incident (e.g. as a mitigation measure). There are various limitations possible for a URA, e.g. speed restriction, full track closure or deactivate automatic operation.
Usage Restriction Area
Usage Restriction
All dynamic operational track properties (i.e. every temporary deviation from static track properties), which have an impact on operations, result in a usage restriction, which has to be considered by operational systems and/or staff.
User Interface refers to a hardware or software device that allows a user to interact with a computer product. The interaction is into the graphical environment in which the user of an application, software or website navigates.
User Interface
User
A user is either a human, software process or device
Valid localisation information
Localisation information processed and validated by the ASTP achieving safety requirements for safe relevant data (e.g., valid position, valid speed…). Note: this valid position is the view from the ASTP, there is no link with the position status (unambiguous, ambiguous, valid, invalid…) at the ETCS system level.
Validator Finding.
Result of a validation
Variant
A Variant is a subset of features
Vehicle data
Vehicle Data is a detailed definition of the train/vehicle {comment:4}characteristics i.e., max acceleration, Traction efforts, rolling coefficients, of the train, wagons, locomotives used for railway operations.
Velocity
Train speed expressed in a 3D reference frame defined by the carriage reference frame.
View Controller
View Controller The View Controller aggregates the View, the output devices and the controller of each input device.
View
View Aggregation of Areas required for systems (CCS, TCMS, CVR...). A View can represent Areas of different systems at the same time.
A view is a filter that restricts the set of data types to a subset that is of interest in the context of a use case. Filtering is by discipline and spatially.
Virtual Block
VCE
The Virtual Computing Element refers to virtually provided compute resources with computing resource guarantees.
Virtual Computing Element
The Virtualisation Environment contains all software needed to provide (multiple) Virtual Computing Elements on a single Physical Computing Element.
Virtualisation Environment
The Virtualization Interface I3 (Interface 3) is used to provide a standardized interface above the virtualisation layer so that applications or higher platform layers are independent of a specific implementation of the computing hardware.
Virtualisation Interface
The Virtualisation Layer contains mechanisms that are able to provide Virtual Computing Elements needed to run multiple Compartments on a single physical hardware underneath.
Virtualisation Layer
VLAN - Virtual Local Area Network
VLAN - Virtual Local Area Network{comment:49}
WMS
Wayside Monitoring Systems are used for diagnostic and maintenance purposes as well as for hazard identification. In this context WMS Systems are applied for monitoring of rolling stock (vehicles) and/or the wayside infrastructure. Some examples include (not exhaustive): Acoustic Bearing Defect Detectors Avalanche detection Hot axle box detection.
Wayside Monitoring System
WAF
Web Application Firewall
WSDL
Web Services Description Language
White Box View
The white box view reveals structural decomposition of a system. In case of the terminology of this document, it can be differentiated between systems that are refined into a system of systems or into subsystems.
Wider System of Interest
The set of all operational entities defining then scope of the operational analysis.
Wireless Communication
Wireless Communication refers to the requirements for Wireless Communication from IEC 62443-3-3 mentioned in SR 1.6, SR 1.6 RE1 and SR 2.2, SR 2.2 RE1. Note: Secure Components are only seen as connected to Wireless Communication, if the Secure Component itself has Wireless Communication abilities implemented. This may count for Work Force Warning systems, for example. This explicitly does exclude Secure Components like Field element controllers, Euro radio, Interlockings and many more according to today's definitions.
Wireless Component
A Secure Component or Network Component with a wireless communication interface. Examples of Wireless Components are handheld devices, WLAN access points, WLAN/5G/FRMCS/... routers, modems and wireless object controllers. Note: additional requirements apply to Wireless Components (as IEC 62443-4-2 SR 1.6, SR 1.6 RE1 and SR 2.2, SR 2.2 RE1)
Work item editor
* The basic system and workflow management tool is the ALM system (currently Polarion). * The ALM offers different frontend types to create/edit/change work items (document editors, database frontends, graphical design, etc.) * Additional editors (like graphical modelling tools for ARCADIA and SysML) can be used to edit elements of the engineering database in the ALM System (synchronized data) as far as a synchronisation software is available (see chapter data management)
Polarion work item.
* Work items examples: “A requirement”, or “a function”, or “a concept aspect” * Work items are objects in the “engineering database” (ALM) that represent the result of a design step. * The structure of the work items is defined by the SEMP process definition documents (overview in the maps), that also make use of modelling standards like ARCADIA or SysML * The master-engineering database is the ALM System (currently Polarion) which contains all work items and their links.
Work Item
Work Package.
Work Product
An artefact associated with the execution of a process.
Workflow and workflow rules
* A workflow describes the rules (processes) how a “trace” shall be created step by step. * A workflow includes a set of rules that define, how * work items must be broken down and linked (link rules) * work item types must be resolved * certain work item types are assigned to certain teams in the organisation * Every work item, that is not compliant to a workflow is marked as invalid * There are optional workflow steps in a workflow. E.g. a requirement can be directly resolved by multiple functions (that are always explained with a rational attribute) without having a “solution concept” work item, which is optional.
Workflow Prioritisation strategy to be decided per area
In general, there are two directions for prioritisation, which are “horizontal” or “vertical” * Horizontal prioritisation means for example “which of all operational capabilities do we break down first down to their operational processes (just the next derivation step per capability)” * Vertical prioritisation means for example “which operational capability do we resolve down to the physical architecture before we start to resolve the next * capability” (image: 1-Grafik_1.png) * Both prioritisation methods are mixed to reach two targets in parallel: a) Use the capacity of all teams in parallel with different roles (vertical prioritisation), b) get a more and more full picture top-down (horizontal prioritisation). * A “mix” can for example be: “At first only all operational capabilities for standard train movements (no shunting etc.) and only the processes related to ETCS Level R without ATO are traced down to the physical architecture in the first step”. For the prioritisation these aspects are important: * As much as possible early usable results shall be created (year by year). * Example 1 (“bottom-up”): All traces, that lead to the EULYNX interfaces shall be resolved and approved fast. EULYNX interfaces should be standardized soon. * This means to import and resolve all traces, and to connect all interfaces to the overall architecture “upwards” (connecting workflow) * Example 2 (“top-down”): All traces for DAC shall be resolved fast, but there are not so much complete (resolved) traces to import in terms of processes and architecture. All operational capabilities and operational requirements for DAC need to be created and broken down and resolved down to the implementation (=vertical prioritisation). * Important decisions shall be decided early as a basis for all work * Example 3: (“horizontal prioritisation”): The process standardisation scope and depth shall be decided as early as possible. This means to create all operational capabilities, derive them town to operational processes, and assess every process impact on the later grade of standardisation of products. * Example 4 (“horizontal + vertical prioritisation”): The functional allocation and ambition in the logical architecture shall be decided as early as possible. For this, all operational capabilities need to be derived down to the logical architecture, and every logical component needs to be designed concerning the external dependencies that it has for other logical components (e.g. delegation of safety requirements from one to other components get only visible with the deep dive in the functional design).
Workflow step (on step in a workitem trace)
A workflow step includes some of the following actions * “Create a trace”: The work item on the “top/start” of a trace is created based on external decisions. These are typically * Steering group decisions about system capabilities, common business objectives, improvement targets or problem descriptions, operational requirements, new safety requirements, etc. (see chapter below). * Technical regulations * “Derive” a work item: A team that is responsible for a derivation step in a trace for work items of a specific type looks for all unresolved work items and derives the resolving work items that are part of the own team scope. E.g., an ARC team sees unresolved actions in an operational process an derives all needed system requirements and functions that need to be worked out. * “Propose” a work item: A team or person receives (assignment) a work item with the status “proposed” from another team, that wants to resolve a dependency. E.g., an OD team designed an action in an operational process and “proposes” (“push”) a system requirement to an ARC team. * “Design / engineer / work out” a work item: The content of the work item is worked out. (e.g. an operational process with all actions) * “Break down” (“dependencies defined/delegated”) a work item: All necessary next work items are derived (as proposals) and linked. * “Resolve” a work item: All necessary next/downwards work items are derived, linked, designed, approved and resolved. E.g., all system functions to fulfil (resolve) an operational requirement are completed. * “Assign” a work item: The work item is assigned to a team or person that shall design it. * “Uplink” a work item. A “free floating” (not linked top-down, completely unlinked, or currently invalid) work item (e.g. coming from a bottom-up process or external contributor) is linked “upwards” to a “traced/valid” work item as if it had been derived from it before (e.g. a process is linked ex post to a capability). This is only done if this new link is really needed to resolve the traced work item in a correct way. Afterwards, the following “change action” is executed. * “Change a work item or link in an existing trace”: Because of a change of a work item or link in a trace the trace gets invalid in some parts(has “suspect links”). It must be reassured that the derivation process in all directions of the trace is correct, or otherwise further work items need to be adapted until all work items are resolved again. E.g., a system requirement lead to 5 system functions that are needed. One system function cannot be implemented. Therefore, all 5 derivations need to be reworked and perhaps all functions need to be deleted and the resolving process starts again. Other example for a suspect link: A function was derived from a requirement. Later the requirement is changed, and the link gets automatically suspect because it is not clear if the function is still implementing the requirement. * “Approve” a work item (see chapter below). An approval step is done in the ALM on work item level by experts based on their knowledge. The group of approvers is assigned depending on the work item type and content. A single approver agrees with an approval that a work item is correctly derived, designed, and broken. Approvals are done per single work items like requirements, concept paragraphs or operational requirements. Approval sessions are typically done for a selected set of work items. * “Decide a deliverable”. When all work items for a certain work area / release are resolved and approved, a document is generated for a formal decision process (e.g. an interface specification or a rulebook). * The typical sequence of actions in a work step is * Pull a work item or check proposed work items * Design the work item * Resolve the work item * Assign resolving work items to a team or person
Workstep "workitem check"
* Is the workitem content correct and without inner contradictions? * Does the workitem content fit to the wokitem type? * Are all standard or custom workitem fields filled? * Does the workitem content implement the demands coming to it by existing links? * Do all mandatory links exist and are they completely fulfilling their role? Does the content fit to them? E.g. a system requirements can be implemented by a function... but it needs to be completely implemented and not partly.
XSD
XML Schema Definition
yLoS
Yearly Letter of Support
ARCADIA Method
Polarion Workitem
Railway Infrastructure