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.
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 |