As Europe’s railways expand, their safety and efficiency depend increasingly on knowing every train’s position....
Satellite positioning set to enhance train localisation
read more
The architectural process comprises four steps, each dealing with a separate concern. The general concept implements a function-based architecture and a layered architecture approach. Both concepts can be realised with the architectural principles described herein.
- Operational analysis (OA): The operational analysis is usually performed on an abstraction layer above the topmost system in the systems of systems hierarchy and performed only once. This analysis should focus as purely as possible on the processes and ideally does not take any specific technical system architecture into account.
- System analysis (SA): 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): This step defines, with which solution concepts (e.g. ETCS and ATO) and which architectural patterns (layered architecture) the system needs shall be fulfilled. It 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.
- Subsystem architecture (SSA): 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.
The optimization task of the System Pillar is to design an architecture that on the one hand standardizes the interaction of new and advanced methods and technologies, while also improving several architecture qualities, of which examples are described below:
| Quality Attribute | Description | Scenario/Measure | |
|---|---|---|---|
| Q1 | Safety | The functions for securing movements on the railway network must meet very high “functional safety” requirements. At the same time the safety assurance shall be possible at lower cost based on modern control algorithms. | Methods for safe control, development of modular safe components and their homologation shall be supported by improved architecture support. |
| Q2 | Availability | Railway systems must be highly available, since in the event of a failure, rail traffic can be immediately restricted. This includes the RAM “Reliability”, “Availability” and “Maintainability” from EN 50126. | The cost of high availability shall be reduced by making use of modern IT strategies for redundancies and recovery. |
| Q3 | Security | Very high security requirements apply, since security indirectly affects availability and safety. | “Security by design” Standards for security supervision functions in the products. Structural security support in the architecture Standardised requirements for component security and their life cycles |
| Q4 | Performance and its scalability (latency and throughput) | The system must be powerful enough to handle the growing rail traffic of the future and to be able to perform the computation within fractions of a second. | A high grade of automation and digitization increases the amount of network messages and computing cycles. Modern communication and computing structures shall support this increase. |
| Q5 | Modifiability | Digital systems change in the life cycle more often because additional information flows are needed that run through the overall system. So, changes and updates need to be very efficient and need a support by the architectural functionalities. | Allowing to update (release) components independently Replace components with different longevity independently with a product of a new generation. |
| Q6 | Modularity / Extensibility | It must be possible to select configurations within the modular framework to facilitate migration strategies, independent life cycles, and adaptations to specific business challenges. This includes that the products are exchangeable. | Use only part of the components Replace some component with other implementation (GoA2 vs. GoA4) Extend the system with additional components to implement new functionalities not yet contained. |
| Q7 | Scalability | The overall quality of the CCS system landscape shall be measured in “cost/ (Q1 to Q6)”. For this lowest quotient, lower values should also be possible for the costs. | “Low cost for low capacity” as well as “higher cost for high capacity” “Low cost for lower availability” as well as “higher cost for higher availability” |
| Q8 | Cost | The system should be designed considering the overall cost to deploy and update with a view to increasing the productivity of the system overall | Overall cost of implementation Benefits associated with implementation/upgrade |