Direct Answer
Railway signalling and safety-critical architecture in Sparx EA is built around Safety Integrity Level (SIL) allocation from the system safety analysis down to software components, with EN 50128 requirements traceability maintained from safety requirements through design to verification evidence. The safety case — the structured argument that the system is acceptably safe — is modelled in Sparx EA using Goal Structuring Notation represented in SysML and ArchiMate requirements layers, with safety claims decomposed into sub-claims and ultimately into evidence requirements. Hazard logs from HAZOP and FMEA analyses are modelled as Risk elements linked to mitigating controls and system elements. SIL allocation from system level to subsystem is captured using tagged values on SysML Block elements. For EA programme work — ETCS/ERTMS migration, rolling stock fleet management, legacy interlocking replacement — Sparx EA models the application portfolio and interface control documents that govern the rolling stock–infrastructure boundary. EN 50128’s bidirectional traceability requirement is met by Sparx EA’s Relationship Matrix and baseline management. Platform Support from Sparx Services embeds Sparx EA expertise in safety-critical programme delivery teams.
Railway Safety Standards
EN 50128 and IEC 62279
EN 50128 (Railway Applications — Communication, Signalling and Processing Systems — Software for Railway Control and Protection Systems) is the European standard for software in railway safety-related systems. Its international equivalent is IEC 62279. EN 50128 defines:
- Software Safety Integrity Levels (SIL 0–4) mapped to the tolerable hazard rate of the software’s failure
- Lifecycle activities required at each SIL, from requirements through design, coding, testing, and validation
- Techniques and Measures (T&M): mandatory and recommended techniques for each lifecycle phase at each SIL — for example, formal methods are highly recommended at SIL 3/4, while they are optional at SIL 1/2
- Independence requirements: the degree to which verification activities must be conducted by personnel independent of the development team
- Documentation requirements: the software plans, design documentation, test specifications, and validation evidence that must be produced
EN 50128 does not mandate specific design notations or tools. However, its requirements for documented software architecture, requirements traceability, and verification evidence maps directly to what Sparx EA provides.
EN 50129: Safety-Related Electronic Systems
EN 50129 (Railway Applications — Communication, Signalling and Processing Systems — Safety Related Electronic Systems for Signalling) is the companion standard to EN 50128, addressing the electronic system level rather than software specifically. EN 50129 requires a System Safety Case — the structured safety argument — supported by a Technical Safety Report, Hazard Log, Safety Plan, and Verification and Validation records. Sparx EA supports the EN 50129 evidence suite through safety case modeling, hazard log management, and traceability between system requirements and verification evidence.
Safety Integrity Levels in Railway
The SIL hierarchy in railway signalling, from highest to lowest integrity requirement:
| SIL | Application Examples | THR (Tolerable Hazard Rate) |
|---|---|---|
| SIL 4 | Computer-based interlocking software, ATP/ATC vital software | < 10⁻⁹ per hour |
| SIL 3 | Train protection system software, level crossing control | < 10⁻⁸ per hour |
| SIL 2 | Non-vital signalling software with safety function | < 10⁻⁷ per hour |
| SIL 1 | Lower criticality control systems | < 10⁻⁶ per hour |
| SIL 0 | Non-safety-related software | No THR requirement |
SIL allocation begins at the system hazard analysis (HAZOP/FMEA), flows through the Preliminary Hazard Analysis (PHA) and System Hazard Analysis (SHA), and results in SIL targets allocated to each subsystem and ultimately to software components.
Safety Case Modeling in Sparx EA
Goal Structuring Notation in Sparx EA
The safety case — the structured argument that a system is acceptably safe for a defined operational context — is most formally expressed using Goal Structuring Notation (GSN). GSN provides a graphical syntax for decomposing a top-level safety claim into sub-claims (goals), supported by evidence (solutions), with strategies connecting goals to sub-goals and context elements scoping the claims.
In Sparx EA, GSN is implemented using a combination of SysML requirements diagrams and ArchiMate requirements elements with GSN-specific stereotypes applied via MDG:
- Goal elements: the safety claims at each level of the argument
- Strategy elements: the decomposition rationale that justifies how sub-goals address the parent goal
- Solution elements: references to evidence (test results, analysis reports, operational data) that support leaf-level goals
- Context elements: the operational context, assumptions, and constraints that scope the claims
- Undeveloped markers: goals not yet supported — the tracking mechanism for safety argument gaps
The resulting GSN diagram in Sparx EA is the primary safety case artefact, linked to the hazard log, system requirements, and verification evidence that the goals reference.
Hazard Log in Sparx EA
The hazard log is the central safety management artefact — a living record of identified hazards, their causes, severity, and the risk controls that reduce them to tolerable levels. In Sparx EA, the hazard log is implemented as a Risk package containing:
- Hazard elements with tagged values: hazard ID, hazard description, phase of operation, identified cause, severity classification (Catastrophic/Critical/Marginal/Negligible), likelihood, risk level before control, risk level after control, and hazard status
- Risk Control elements: linked to hazard elements via mitigation relationships, representing the system design features, operational procedures, or software controls that address each hazard
- System element links: hazard elements linked to the system components (SysML Blocks or ArchiMate Application/Technology elements) that contribute to the hazard, enabling impact analysis when system changes are proposed
HAZOP and FMEA results feed the hazard log directly: HAZOP deviation/cause/consequence/safeguard tables map to Sparx EA hazard elements with their linked controls. FMEA failure mode/effect/criticality entries map to hazard elements with severity classification. The hazard log in Sparx EA is a queryable, linkable model — not a static spreadsheet — meaning that when a system change is proposed, the architecture team can identify which hazards the changed element contributes to.
SIL Allocation and Decomposition
SIL allocation in Sparx EA follows the decomposition from system safety analysis to subsystem. A SysML Block Definition Diagram shows the system decomposed to subsystem level, with each block carrying a siltarget tagged value derived from the hazard analysis. For subsystems implemented in software, the softwaresil tagged value on SysML Block elements drives the EN 50128 compliance requirements — the required lifecycle techniques and measures, independence requirements, and documentation obligations.
SIL decomposition — where a system SIL 4 requirement can be met by multiple SIL 3 subsystems with independent failure modes — is modelled explicitly in Sparx EA: a SIL decomposition element references the component SIL assignments and captures the independence assumption that justifies the decomposition.
Sparx EA for Railway EA Programme Work
Application Portfolio: Legacy to ETCS Migration
Many railway network operators are managing the migration from legacy relay-based interlocking technology to computer-based interlocking and European Train Control System (ETCS) / European Rail Traffic Management System (ERTMS). This is a multi-decade, multi-billion programme with complex sequencing constraints.
Sparx EA models this migration in the Application Portfolio layer:
- Legacy applications: relay interlocking installations modelled as Application Component elements with tagged values for technology type (relay, solid-state, first-generation processor-based), commissioning year, expected replacement year, geographic location, and lines/stations controlled
- Target applications: ETCS Level 2 or Level 3 target state modelled as the future Application Component elements with tagged values for ETCS specification version (Baseline 3, Baseline 4), planned commissioning year, and interface requirements
- Migration artefacts: transformation relationships between legacy and target elements, with programme workstream tags linking to the specific infrastructure investment programmes that fund each migration wave
The capability map for the programme — the structured view of what railway operational capabilities exist today and what the target capability model looks like under full ETCS deployment — provides the business architecture layer that justifies investment prioritisation.
Interface Control Documents for Rolling Stock–Infrastructure
The rolling stock–infrastructure interface is one of the most complex managed boundaries in railway systems engineering. The Train Interface Document (TID) or specific Interface Control Document (ICD) governs the technical interface between the on-board (rolling stock) train control system and the trackside (infrastructure) signalling system. For ETCS, this interface is governed by the ETCS specification (Subset-026 and related SRS documents).
In Sparx EA, the rolling stock–infrastructure interface is modelled as a Technology Interface element between the on-board ETCS Equipment (OBU) and the Radio Block Centre (RBC), with the Subset-026 specification reference tagged on the interface. Where specific interface control documents exist for a fleet-to-infrastructure combination, they are attached as artefact links to the interface element, creating a complete interface control document registry within the EA repository.
ETCS Architecture in Sparx EA
The ETCS architecture at Level 2 (the most widely deployed ETCS level) is modelled in Sparx EA’s ArchiMate Technology layer:
- On-board subsystem: OBU (On-board Unit), Juridical Recorder (JRU), STM (Specific Transmission Module) for national legacy ATP compatibility
- Trackside subsystem: RBC (Radio Block Centre), Eurobalise, Euroloop (for Level 1 applications), LEU (Lineside Electronic Unit)
- Communication infrastructure: GSM-R radio network (or FRMCS — Future Railway Mobile Communication System — for next-generation deployments)
- Interlocking interfaces: RBC-interlocking interface (governed by the relevant supplier interface specification)
Each element carries ETCS-specific tagged values: ETCS level, specification baseline version, functional safety classification, and the relevant Test Specification references. Interface elements carry the Subset specification reference governing each interface.
EN 50128 Traceability with Sparx EA
Bidirectional Traceability Requirement
EN 50128 requires complete bidirectional traceability between safety requirements and verification evidence — from the top-level safety requirement down to the test case that verifies it, and back up. This traceability must be demonstrable to the assessment body (the Independent Safety Assessor — ISA — under EN 50126) at each formal review stage.
Sparx EA’s Relationship Matrix generates this bidirectional traceability as a matrix artefact. The matrix is configured to show safety requirements in rows and test specifications (or other verification evidence) in columns, with traceability relationships populating the cells. The matrix is regenerated from the live repository at each review stage — PDR, CDR, FDR (Final Design Review) — and can be generated against a named baseline to show the traceability state at a specific programme gate.
Baseline Management for Safety Programme Gates
EN 50128 requires that software lifecycle data is placed under configuration management. Sparx EA’s baseline management creates immutable repository snapshots at safety programme gates — Preliminary Design Review, Final Design Review, Factory Acceptance Test, Site Acceptance Test — capturing the complete safety case, hazard log, SIL allocation model, requirements hierarchy, and verification traceability. These baselines provide the configuration identification evidence that the ISA requires to assess the safety programme’s compliance with EN 50128.
FAQ
What is EN 50128 and who must comply with it?
EN 50128 (Railway Applications — Software for Railway Control and Protection Systems) is the European standard for software in railway safety-related applications. It applies to the development of software used in systems that perform safety functions in railway signalling, train control, and protection systems — including interlocking software, ATP/ATC systems, ETCS on-board and trackside software, level crossing control, and other safety-critical signalling applications. Compliance is required by the relevant railway safety authority in each EU member state (under the Railway Safety Directive), and is assessed by an Independent Safety Assessor (ISA) as part of the EN 50126 safety lifecycle process. The international equivalent is IEC 62279.
What is Safety Integrity Level and how is SIL 4 different from SIL 1?
Safety Integrity Level (SIL) is a measure of the risk reduction required from a safety function, expressed as a Tolerable Hazard Rate (THR): the maximum frequency of dangerous failures permitted. SIL 4 (THR < 10⁻⁹ per hour) applies to software whose failure could directly cause a catastrophic accident — computer-based interlocking software and vital ATP software are the primary SIL 4 applications in railway signalling. SIL 1 (THR < 10⁻⁶ per hour) applies to software with a less critical safety function. The practical difference for development teams is significant: SIL 4 requires formal verification methods, full independence between development and verification, specific coding standards (no dynamic memory allocation, no recursion), and a much larger evidence set than SIL 1. SIL assignment flows from the system hazard analysis to software components.
What is a safety case and how is it modelled in Sparx EA?
A safety case is a structured argument, supported by evidence, that a system is acceptably safe for a defined operational context. It decomposes a top-level safety claim — “the signalling system is safe” — into sub-claims, strategies, and ultimately evidence. Goal Structuring Notation (GSN) is the most widely used formalism for safety case representation in railway. In Sparx EA, the safety case is modelled using GSN-stereotyped elements: Goal elements for claims at each level, Strategy elements for decomposition rationale, Solution elements referencing evidence artefacts, and Context elements scoping the claims. The GSN diagram in Sparx EA is linked to the hazard log, system requirements, and verification evidence it references, creating a navigable safety argument that the ISA can assess.
How does the hazard log work in Sparx EA for railway programmes?
The hazard log in Sparx EA is a Risk package containing Hazard elements with tagged values: hazard ID, description, operational phase, identified cause, severity (Catastrophic/Critical/Marginal/Negligible), likelihood, and risk level before and after control. Each hazard is linked to the Risk Control elements (system design features, software controls, or operational procedures) that mitigate it, and to the system component elements that contribute to the hazard. HAZOP and FMEA results are entered as hazard elements during analysis phases. When a system change is proposed, the architecture team can query which hazards the changed component contributes to, and whether the change affects the validity of any safety controls — making Sparx EA a hazard impact analysis tool, not just a documentation store.
What is the rolling stock–infrastructure interface and why does it matter for EA?
The rolling stock–infrastructure interface is the technical boundary between the train-borne signalling and control equipment (the on-board unit — OBU, odometry, braking interfaces) and the trackside signalling infrastructure (the RBC, Eurobalises, interlocking). This interface is safety-critical — failures in the interface can cause unsafe behaviour — and is governed by the ETCS Subset-026 specification for ETCS-compliant systems, and by national legacy ATP interface specifications for older systems. It matters for EA because it is the boundary between two organisations (rolling stock owner/operator and infrastructure manager) with different technical governance, different safety case ownership, and different change management processes. EA models this interface explicitly, enabling both parties to identify dependencies and manage interface changes with appropriate safety rigour.
How does Sparx EA support ETCS/ERTMS migration programme management?
Sparx EA supports ETCS/ERTMS migration by modelling the complete application portfolio transition: legacy signalling installations (relay interlocking, national ATP systems) as current-state application components with lifecycle tagged values, and ETCS target-state components with planned commissioning dates. The migration roadmap — which routes migrate in which programme phase, what the sequencing constraints are (commissioning one section before adjacent sections is possible, but requires careful interface management at the boundary) — is modelled as transformation relationships between current-state and target-state elements, tagged to programme workstreams. EA GraphLink surfaces this as a migration programme dashboard: which sections are in design, which are in testing, which are commissioned, and what the remaining scope looks like by year.
What is FRMCS and how does it affect ETCS architecture in Sparx EA?
FRMCS (Future Railway Mobile Communication System) is the 5G-based successor to the GSM-R radio network that carries ETCS communications in Level 2 and Level 3 deployments. As GSM-R networks approach end-of-life in the 2030s, railway operators must plan the migration from GSM-R to FRMCS. In Sparx EA, FRMCS migration is modelled as a technology infrastructure transition: the GSM-R network element in the Technology layer is tagged with end-of-support dates, and the FRMCS target infrastructure is modelled with planned rollout schedules. The RBC-OBU communication interface carries a tagged value indicating whether it requires GSM-R, FRMCS, or dual-mode capability — driving the rolling stock adaptation scope that FRMCS migration requires.
What is the recommended Sparx Services engagement for railway safety programmes?
For railway safety-critical programmes, the recommended engagement is Platform Support — Sparx Services provides embedded Sparx EA expertise within the safety programme team, managing the EN 50128 requirements hierarchy, safety case model, hazard log, SIL allocation, and traceability evidence through programme gates. Platform Support is the most appropriate model because railway safety programmes run for years and require sustained repository management rather than a one-time configuration engagement. For infrastructure operators planning ETCS/ERTMS migration, a Connect engagement builds the migration architecture model and programme management dashboard before Platform Support begins. Contact Sparx Services to scope Platform Support for your programme phase and SIL profile.
Next Step: Safety-Critical Programme Repository Support
Railway signalling and safety-critical programme architecture requires sustained expertise — not a configuration engagement followed by handover. The SIL 4 evidence that an ISA accepts is built over years of disciplined repository management.
Platform Support from Sparx Services embeds Sparx EA expertise in your safety-critical programme team through design review gates and into commissioning.
Talk to Sparx Services about Platform Support for your railway programme
Platform Support starts at $30K. Structured around your programme gates — PDR, CDR, FDR, and FAT — not a generic retainer.
