What is Safety Integrity Level and how is SIL 4 different from SIL 1?

Safety Integrity Level is a measure of the risk reduction required from a safety function, expressed as a Tolerable Hazard Rate. SIL 4 (THR below 10⁻⁹ per hour) applies to software whose failure could directly cause a catastrophic accident — computer-based interlocking and vital ATP software. SIL 1 (THR below 10⁻⁶ per hour) applies to less critical functions. The practical difference is significant: SIL 4 requires formal verification methods, full independence between development and verification, restrictive coding standards (no dynamic memory allocation, no recursion), and a much larger evidence set. SIL flows from the system hazard analysis to software components.

What is a safety case and how is it modeled 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 claim into sub-claims, strategies, and evidence. Goal Structuring Notation (GSN) is the most widely used formalism in railway. In Sparx EA, the safety case is modeled with GSN-stereotyped elements: Goal elements for claims, Strategy elements for decomposition rationale, Solution elements referencing evidence, and Context elements scoping the claims. The GSN diagram is linked to the hazard log, system requirements, and verification evidence it references.

How does the hazard log work in Sparx EA for railway programs?

The hazard log is a Risk package of Hazard elements with tagged values: hazard ID, description, operational phase, cause, severity (Catastrophic/Critical/Marginal/Negligible), likelihood, and risk level before and after control. Each hazard links to the Risk Control elements that mitigate it and the system components that contribute to it. HAZOP and FMEA results are entered as hazard elements. When a change is proposed, the team can query which hazards the changed component contributes to — 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?

It is the technical boundary between train-borne signaling and control equipment (the on-board unit, odometry, braking interfaces) and trackside infrastructure (the RBC, Eurobalises, interlocking). It is safety-critical and governed by the ETCS Subset-026 specification for ETCS systems and by national legacy ATP specifications for older systems. It matters for EA because it sits between two organizations — rolling stock owner/operator and infrastructure manager — with different governance, safety-case ownership, and change processes. Modeling it explicitly lets both parties identify dependencies and manage interface changes with appropriate safety rigor.

How does Sparx EA support ETCS/ERTMS migration program management?

Sparx EA models the complete application-portfolio transition: legacy installations (relay interlocking, national ATP) 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 phase and the sequencing constraints — is modeled as transformation relationships between current and target elements, tagged to program workstreams. The model can feed a migration-program dashboard showing which sections are in design, in testing, and commissioned, and the remaining scope 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, operators must plan migration to FRMCS. In Sparx EA, this is modeled as a technology-infrastructure transition: the GSM-R element is tagged with end-of-support dates and the FRMCS target is modeled with planned rollout schedules. The RBC-OBU communication interface carries a tagged value for whether it requires GSM-R, FRMCS, or dual-mode capability — driving the rolling-stock adaptation scope.

Insight · Industry

Railway Signaling and Safety-Critical Architecture in Sparx EA: EN 50128 and SIL Compliance

Q: 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 software in systems that perform safety functions in railway signaling, train control, and protection — interlocking software, ATP/ATC systems, ETCS on-board and trackside software, level crossing control, and other safety-critical signaling applications. Compliance is required by the relevant railway safety authority in each EU member state and is assessed by an Independent Safety Assessor as part of the EN 50126 lifecycle. The international equivalent is IEC 62279.

By Sparx Services · November 15, 2025

The short version: Railway signaling architecture in Sparx EA is built around Safety Integrity Level (SIL) allocation flowing from the system safety analysis down to software components, with EN 50128 traceability held from safety requirements through design to verification evidence. The safety case is modeled with Goal Structuring Notation in SysML and requirements elements; hazard logs from HAZOP and FMEA become queryable Risk elements linked to controls and system elements; and EN 50128's bidirectional traceability requirement is met by the Relationship Matrix and baseline management. The result is a safety argument an assessor can navigate, not a binder they have to reconcile.

Railway safety standards

EN 50128 and IEC 62279

EN 50128 (Railway Applications — Communication, Signaling 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. It 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: mandatory and recommended techniques per lifecycle phase per SIL — formal methods are highly recommended at SIL 3/4, optional at SIL 1/2
Independence requirements: the degree to which verification must be conducted by personnel independent of the development team
Documentation requirements: the plans, design documentation, test specifications, and validation evidence that must be produced

EN 50128 does not mandate specific design notations or tools — but its requirements for documented software architecture, requirements traceability, and verification evidence map directly to what Sparx EA provides.

EN 50129: safety-related electronic systems

EN 50129 is the companion standard, addressing the electronic system level rather than software specifically. It requires a System Safety Case 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 signaling, 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 signaling 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 and System Hazard Analysis, and results in SIL targets allocated to each subsystem and ultimately to software components.

Safety case modeling in Sparx EA

Goal Structuring Notation

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), which 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 justifying how sub-goals address the parent goal
Solution elements — references to evidence (test results, analysis reports, operational data) supporting leaf-level goals
Context elements — the operational context, assumptions, and constraints scoping the claims
Undeveloped markers — goals not yet supported, the tracking mechanism for safety-argument gaps

The resulting GSN diagram is the primary safety-case artifact, linked to the hazard log, system requirements, and verification evidence its goals reference.

The hazard log

The hazard log is the central safety-management artifact — a living record of identified hazards, their causes, severity, and the risk controls that reduce them to tolerable levels. In Sparx EA it is a Risk package containing Hazard elements (with tagged values for ID, description, operational phase, cause, severity classification, likelihood, and risk level before and after control), Risk Control elements linked via mitigation relationships, and links from hazards to the system components that contribute to them. HAZOP deviation/cause/consequence/safeguard tables and FMEA failure-mode/effect/criticality entries feed the log directly. Because it is a queryable, linkable model rather than a static spreadsheet, when a change is proposed the team can immediately identify which hazards the changed element contributes to.

SIL allocation and decomposition

SIL allocation follows the decomposition from system safety analysis to subsystem. A SysML Block Definition Diagram shows the system decomposed to subsystem level, each block carrying a sil_target tagged value derived from the hazard analysis. For software subsystems, the software_sil tagged value drives the EN 50128 compliance requirements — the required techniques and measures, independence requirements, and documentation obligations. SIL decomposition — where a system SIL 4 requirement is met by multiple SIL 3 subsystems with independent failure modes — is modeled explicitly: a decomposition element references the component SIL assignments and captures the independence assumption that justifies it.

Sparx EA for railway program work

Application portfolio: legacy to ETCS migration

Many railway network operators are managing the migration from legacy relay-based interlocking to computer-based interlocking and the European Train Control System (ETCS) / European Rail Traffic Management System (ERTMS) — a multi-decade, multi-billion program with complex sequencing constraints. Sparx EA models this in the application portfolio layer:

Legacy applications — relay interlocking installations as Application Component elements tagged with technology type, commissioning year, expected replacement year, location, and lines/stations controlled
Target applications — ETCS Level 2 or Level 3 target-state components tagged with ETCS specification version (Baseline 3, Baseline 4), planned commissioning year, and interface requirements
Migration artifacts — transformation relationships between legacy and target elements, with program-workstream tags linking to the infrastructure investment programs that fund each migration wave

The capability map for the program — what railway operational capabilities exist today versus the target under full ETCS deployment — provides the business architecture layer that justifies investment prioritization.

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 or specific Interface Control Document governs the technical interface between the on-board train control system and the trackside signaling system; for ETCS, this interface is governed by the ETCS specification (Subset-026 and related SRS documents). In Sparx EA, it is modeled as a Technology Interface element between the on-board ETCS Equipment (OBU) and the Radio Block Centre (RBC), with the Subset-026 reference tagged on the interface. Where specific ICDs exist for a fleet-to-infrastructure combination, they are attached as artifact links, creating a complete ICD registry within the repository.

ETCS architecture in Sparx EA

The ETCS architecture at Level 2 (the most widely deployed level) is modeled in the 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), 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 Test Specification references. Interface elements carry the Subset specification reference governing each interface.

EN 50128 traceability with Sparx EA

The 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 — demonstrable to the Independent Safety Assessor (ISA) under EN 50126 at each formal review stage. Sparx EA's Relationship Matrix generates this as a matrix artifact, configured to show safety requirements in rows and test specifications in columns with traceability relationships in the cells. It is regenerated from the live repository at each stage — PDR, CDR, FDR — and can be generated against a named baseline to show the traceability state at a specific gate.

Baseline management for safety program gates

EN 50128 requires that software lifecycle data is placed under configuration management. Sparx EA's baseline management creates immutable repository snapshots at safety program 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 the ISA requires to assess the program's compliance with EN 50128.

Frequently asked questions

What is EN 50128 and who must comply with it?

EN 50128 is the European standard for software in railway safety-related applications (international equivalent IEC 62279). It covers software in signaling, train control, and protection systems — interlocking, ATP/ATC, ETCS, level crossing control. Compliance is required by the national railway safety authority and assessed by an Independent Safety Assessor as part of the EN 50126 lifecycle.

How is SIL 4 different from SIL 1?

SIL is the risk reduction required from a safety function, expressed as a Tolerable Hazard Rate. SIL 4 (THR below 10⁻⁹/hr) covers software whose failure could directly cause a catastrophic accident and requires formal verification, full development/verification independence, and restrictive coding standards. SIL 1 (THR below 10⁻⁶/hr) covers less critical functions with a much smaller evidence set.

How is a safety case modeled in Sparx EA?

Using Goal Structuring Notation: Goal elements for claims, Strategy elements for decomposition rationale, Solution elements referencing evidence, and Context elements scoping the claims. The GSN diagram is linked to the hazard log, system requirements, and verification evidence it references, creating a navigable safety argument the ISA can assess.

How does the hazard log work in Sparx EA?

It is a Risk package of Hazard elements with tagged values for ID, description, phase, cause, severity, likelihood, and risk before and after control, each linked to its Risk Controls and the system components that contribute to it. HAZOP and FMEA results feed it directly, and because it is a model, a proposed change can be checked for which hazards it affects.

Why does the rolling stock–infrastructure interface matter for EA?

It is the safety-critical boundary between train-borne and trackside equipment, governed by ETCS Subset-026 or national ATP specifications. It sits between two organizations with different governance and change processes, so modeling it explicitly lets both identify dependencies and manage interface changes with proper safety rigor.

How does Sparx EA support ETCS/ERTMS migration?

By modeling the full portfolio transition: legacy installations as current-state components with lifecycle tags, ETCS target components with planned commissioning dates, and the migration roadmap as transformation relationships tagged to program workstreams. The model can feed a migration dashboard showing sections in design, testing, and commissioned, and the remaining scope by year.

What is FRMCS and how does it affect ETCS architecture?

FRMCS is the 5G successor to GSM-R for ETCS communications. As GSM-R approaches end-of-life in the 2030s, operators plan migration. In Sparx EA, the GSM-R element is tagged with end-of-support dates, the FRMCS target with rollout schedules, and the RBC-OBU interface with whether it needs GSM-R, FRMCS, or dual-mode — driving rolling-stock adaptation scope.

Sustained support for safety-critical programs

Railway signaling and safety-critical program architecture needs sustained expertise — not a configuration engagement followed by handover. The SIL 4 evidence an ISA accepts is built over years of disciplined repository management. Sparx Services embeds Sparx EA expertise in your safety-critical program team through design-review gates and into commissioning, structured around your program gates — PDR, CDR, FDR, and FAT. For the platform underneath that work, see why Sparx EA; to scope the engagement, start with Configure the Solution.

Build a safety case your assessor can navigate.

Talk to a practitioner about modeling SIL allocation, the hazard log, and EN 50128 traceability as one governed Sparx EA model — maintained through every gate.

Book a call →

Keep reading