EN 50716 vs EN 50128: what changed for railway software

One standard for railway software

For more than a decade, railway software had two homes. EN 50128 covered software for communication, signalling and processing systems, and EN 50657, published in 2017, covered software on board rolling stock. EN 50657 was itself modelled closely on EN 50128, so projects spanning both domains were working to two very similar but separately maintained standards.

CENELEC published EN 50716:2023, Railway applications – Requirements for software development, in November 2023. It supersedes both EN 50128:2011 (with its amendments) and EN 50657:2017, giving signalling and rolling stock software a single, harmonised set of requirements.

What stays the same

If your team is fluent in EN 50128, most of EN 50716 will feel familiar. Published analyses of the new standard estimate that roughly 30–40% of requirements were touched, but mostly through rewording and added precision rather than new obligations. The fundamentals carry over:

• A defined software lifecycle with planning, requirements, architecture and design, implementation, verification, integration, validation, assessment and maintenance.
• Software safety integrity levels SIL 1 to SIL 4, with basic integrity for software with low safety relevance. (Basic integrity had already replaced "SIL 0" through the EN 50128 amendment, aligning with EN 50126 and EN 50129.)
• Technique and measure tables in Annex A, graded by integrity level.
• Independence requirements between roles, scaled by integrity level.
• Tool classification and the need to justify confidence in tools that can affect the executable software.

What changed

Roles and organisation

The organisation clause has been simplified, but its independence constraints are largely unchanged. The most visible change is the removal of the separate integrator role, with integration testing absorbed by the tester. Review your software quality assurance plan and organisation chart so role names and responsibilities match the new text.

Application data and algorithms

Data-driven systems such as interlockings and train control depend heavily on configuration and application data. EN 50716 revises the clause on application data and adds documents to it, while application algorithms are now expected to follow the complete software lifecycle rather than the lighter data process. If your system's behaviour is defined partly through configurable logic, check which side of that line it falls on.

Modelling, iterative development and machine learning

The informative annex now discusses iterative lifecycles, which repeat phases without removing them, and model-based development, where models can stand in for phase outputs provided the Annex A techniques are adapted. This gives teams using iterative or model-based approaches clearer footing, although the standard does not explicitly endorse "agile" as such. Machine learning remains not recommended for safety functions, reflecting unresolved questions about training data, verification and robustness.

Transition: which standard applies to your project?

The answer depends on your contract and the regulatory regime, not only on the publication date. Published summaries indicate that EN 50128, EN 50657 and EN 50716 can coexist until the end of October 2026, after which EN 50716 becomes the reference for new work. Projects already under way may remain on their original baseline if the contract and approval body agree.

Practical steps:

1. Confirm the baseline. Check which edition your contract, safety plan and approval body specify, and record the decision.
2. Run a gap analysis. Map your existing software plans and procedures against EN 50716 clause by clause, focusing on roles, application data and Annex A techniques.
3. Update plans, not just references. Changing the standard number in a document is not compliance. Update roles, processes and technique selections where the text has changed.
4. Brief the assessor early. Agree how the transition will be argued in the software and system safety cases before evidence is produced.
5. Align with the system level. Make sure software integrity requirements still trace cleanly to SIL allocations made under EN 50126-2 and EN 50129.

Looking ahead

EN 50716 is due for review five years after publication. For now, the most useful thing most teams can do is treat the transition as a short, planned gap analysis rather than a rewrite: the engineering discipline it demands is largely the one good EN 50128 projects already practise.