EN 50128 is the European standard for software in railway control and protection systems. It sits inside the CENELEC family alongside EN 50126 (the overall RAMS lifecycle) and EN 50129 (safety-related electronic systems hardware). Where 50126 defines how you allocate safety across the whole system and 50129 covers the hardware safety case, 50128 is specifically about the software: how it is specified, designed, coded, verified, and validated, and how much of each you must do. The dial that sets the amount is the Safety Integrity Level, or SIL.
Rail uses five levels: SIL 0 through SIL 4. SIL 0 is software with no safety responsibility — it still needs sound engineering, but the heavy safety machinery does not apply. SIL 4 is the most demanding, reserved for functions whose failure could cause catastrophic harm, such as a signalling interlocking that must never grant conflicting movement authorities. Each step up the SIL ladder tightens the techniques you must apply, the independence of the people who verify and validate, and the depth of evidence you must produce. The standard does not let you pick a SIL by taste. It is allocated by the system safety process (per EN 50126 and EN 50129) from the tolerable hazard rate for each function, and 50128 inherits that allocation for the software that implements it.
The SIL is not a label you attach at the end — it is an input at the very start that shapes the entire software lifecycle. EN 50128 defines a V-model of phases: software requirements, architecture and design, component design, coding, and then the ascending verification side with component test, integration, and overall software validation. At each phase the standard provides tables of techniques and measures, each marked as Mandatory, Highly Recommended, Recommended, or discouraged for a given SIL. At SIL 4, formal methods, static analysis, defensive programming, and structure-based (structural coverage) testing move from optional to expected. At SIL 1 or 2, many of the same techniques are recommended rather than mandatory. The SIL is the index into those tables — it tells you which row of rigor you must satisfy.
Independence is one of the sharpest ways the SIL shows up. EN 50128 defines organizational roles — the requirements manager, the designer, the implementer, the tester, the verifier, the validator, the assessor — and specifies how independent each must be from the others as a function of SIL. At low SILs, one person can hold several roles. At SIL 3 and SIL 4, the verifier and validator must be independent of the designers and implementers, and the assessor must be independent of the entire project organization. This is not bureaucracy for its own sake: the whole point is that the people who judge whether the software is safe are not the same people who have an interest in declaring it done.
Traceability is the connective tissue of a 50128 safety case, and it is bidirectional. Every software safety requirement must trace up to the system safety requirements that spawned it and down to the design element, the code, and the verification evidence that satisfies it. When an assessor asks "show me that this braking-curve requirement is implemented and tested," you must produce the design that realizes it, the code that implements it, and the test and analysis results that demonstrate it — with the coverage the SIL demands. When a requirement changes, every downstream artifact it touches becomes suspect until re-verified. On a signalling program with thousands of software requirements at mixed SILs, maintaining this web by hand in documents and spreadsheets is where teams quietly lose confidence in their own trace.
A recurring pitfall is treating the SIL as a project-wide setting. In practice a rail application is a mix. The vital signalling logic may be SIL 4, the diagnostics and logging SIL 0, and a driver advisory function somewhere in between. EN 50128 expects you to segregate functions of different SILs so that lower-integrity software cannot corrupt higher-integrity software — through partitioning, independence of execution, and demonstrated non-interference. If you cannot demonstrate that separation, the standard makes you treat the whole assembly at the highest SIL present, which is expensive. Getting the architecture right so that SIL 4 logic is genuinely isolated is one of the highest-leverage decisions on a rail software program.
Another trap is the tool qualification question. EN 50128 classifies tools as T1 (no effect on the executable, e.g. a text editor), T2 (verification tools that could fail to detect an error, e.g. a static analyzer or test harness), or T3 (tools that can introduce errors into the executable, e.g. a compiler or code generator). T2 and T3 tools carry their own qualification obligations, because a defect in the tool can undermine every claim you make with it. Teams that adopt a code generator or a model-based toolchain late in a program, without accounting for its tool class, discover the qualification burden at the worst possible time.
Validation, in the 50128 sense, is the final confirmation that the integrated software meets its requirements in its intended environment. It is distinct from verification, which confirms each phase output is correct with respect to its input. Verification asks "did we build the software right at each step?" Validation asks "did we build the right software, and does it do what the safety requirements demanded, end to end?" The validator signs off only when the evidence chain is complete: requirements traced, design verified, code verified, coverage achieved to the SIL, and the software validation test suite passed against the requirements. A gap anywhere in that chain is a gap in the safety argument.
Hitt Hosting SE's Rail pack is organized around the CENELEC lifecycle. Software safety requirements carry their allocated SIL, and the technique and independence expectations for that SIL are surfaced at each phase rather than looked up in a separate binder. Requirements link to design elements, to the code that implements them, and to the verification and validation evidence, so the bidirectional trace an assessor expects is generated from the live data instead of assembled before a review. When a requirement or a hazard allocation changes, the affected design, code, and test artifacts are flagged as suspect for re-verification. The validation record — requirements at their SILs, coverage evidence, independence and role assignments, and the assessor trail — reflects what the data actually supports, which is exactly what a rail safety case has to withstand.