EN 50128: EN 50128 – Tutorial (about 60 minutes)

EN 50128 is the European standard that, for about twenty years, defined how railway suppliers develop, verify, validate and maintain software for signalling, train control and other railway control and protection systems, with more rigour the more dangerous a software failure would be. It was used by software engineers, testers, safety managers, independent assessors and railway authorities, and it has now been superseded by EN 50716. After this tutorial you will be able to explain what EN 50128 requires, read its structure, recognise its roles and documents, and handle legacy EN 50128 evidence sensibly while the industry moves to its successor.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the last edition is EN 50128:2011, Railway applications – Communication, signalling and processing systems – Software for railway control and protection systems, prepared by CENELEC technical committee CLC/TC 9X. It was corrected by a corrigendum in 2014 (EN 50128:2011/AC:2014) and changed by two amendments approved in 2020: A1, which added an informative Annex ZZ relating the standard to the EU railway interoperability directive, and A2, which aligned it with EN 50126-1:2017, EN 50126-2:2017 and EN 50129:2018 and renamed "SIL 0" to "Basic Integrity". The first edition was EN 50128:2001. EN 50128 is superseded: EN 50716:2023 replaces both EN 50128 and the rolling-stock standard EN 50657, and the latest date for withdrawing conflicting national standards was set at 30 October 2026, so the transition period ends at the end of October 2026. National bodies such as DIN already list their adoption of EN 50128 as withdrawn and replaced by the national edition of EN 50716. The international twin, IEC 62279:2015, is a separate IEC publication; check its own status with IEC. This course teaches EN 50128:2011 including A1 and A2, because many products in service, contracts and safety cases still refer to it, and it points out where EN 50716 differs. Verified 2026-10-29 against catalogue entries of CENELEC national adoptions (DIN Media, iTeh Standards, EVS) and practitioner sources listed at the end.

Who it is for: software and test engineers, verification and validation staff, quality and safety managers, project managers, buyers and auditors who meet EN 50128 on railway projects – often because they maintain a product that was assessed against it, inherit documents written to it, or must plan the move to EN 50716. It also suits engineers from automotive, aerospace or industrial automation who are new to rail.

Prerequisites: none. A general idea of how software is specified, coded and tested helps. Every railway and safety term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why railway software needed its own standard and what EN 50128 covered and did not cover.
You will be able to define the core vocabulary: software safety integrity level, Basic Integrity, verification, validation, assessment, tool classes, generic software and application data.
You will be able to describe the structure of EN 50128 from its organisational clauses to the normative technique tables of Annex A and the role definitions of Annex B.
You will be able to walk through the software lifecycle the standard expects and name the main plans, specifications and reports.
You will be able to explain how independence of roles, independent assessment and the system safety case worked together.
You will be able to apply the standard to a realistic interlocking product and decide how to treat legacy EN 50128 evidence during the move to EN 50716.
You will be able to place EN 50128 next to EN 50126, EN 50129, EN 50657, EN 50716, IEC 62279 and IEC 61508.

Lesson 1 – Origins, purpose and scope

Why railway software needs discipline

A modern railway is controlled by computers. An interlocking – the safety system that decides whether points may move and whether a signal may show a proceed aspect – is now usually a computer running software rather than a cabinet of relays. Automatic train protection equipment watches the speed of each train and brakes it if the driver fails to respond. Level crossing controllers decide when barriers come down. If any of these programs gives a wrong answer at the wrong moment, trains can collide or derail and people can die.

Hardware and software fail in different ways. A relay or a power supply fails at random as parts age, and engineers can estimate how often that happens and add redundancy. Software does not age. It fails because of systematic faults: mistakes in the requirements, design, code, data or tools that are present in every copy and lie dormant until a particular combination of inputs triggers them. No realistic amount of testing can exercise every combination, so a measured failure rate cannot prove that safety software is good enough. What engineers can control is the process: how clearly requirements are written, how carefully the design is structured, which techniques are used, how thoroughly the work is checked and how independent the checkers are. EN 50128 is a rulebook for that process, scaled to the risk.

A short history

The European railway safety standards grew out of the generic functional safety standard IEC 61508. CENELEC, the European committee for electrotechnical standardisation, produced a rail-specific family in which EN 50126 covers reliability, availability, maintainability and safety (RAMS) across the whole system lifecycle, EN 50129 covers safety-related electronic systems for signalling and the safety case, and EN 50128 covers the software. EN 50128 was first published in 2001 and was substantially revised in 2011. The 2011 edition reorganised the text and introduced, among other things, a formal classification and qualification scheme for software tools.

In 2017 CENELEC published EN 50657, a derived standard for software on board rolling stock (for example traction, brake and door control), because the rolling stock industry wanted a version better suited to its products. Suppliers who built both trackside and on-board equipment then had to work to two very similar standards. In 2023 CENELEC merged them into EN 50716, and EN 50128 entered its transition period. Figure 1 shows the timeline.

Figure 1 – The life of EN 50128, from its first edition to its replacement by EN 50716.

What EN 50128 covers

The scope of EN 50128 is the software of programmable electronic systems used in railway control and protection applications: signalling, interlocking, train protection, traffic control centres, level crossing protection and similar. It sets process and technical requirements for developing, deploying and maintaining that software. It applies to application software, operating systems, support tools and firmware, and it covers software whose failure has a safety impact as well as software at the lowest integrity level. It deals only with the software and its interaction with the wider system; the hardware and the system-level safety argument are handled by EN 50129, and the overall RAMS process by EN 50126.

EN 50128 does not tell a supplier how safe a particular function must be. That decision comes from the system-level hazard analysis. Nor does it cover cybersecurity directly; security threats that could affect safety are treated as hazards through the system process, and dedicated guidance such as CLC/TS 50701 and IEC 62443 deals with security engineering.

Why it still matters after being superseded

A superseded standard does not vanish from the railway. Interlockings and train protection products stay in service for decades. Their safety cases, assessment reports and type approvals were written against EN 50128, contracts signed years ago may still name it, and maintenance changes to these products must be argued against the evidence that already exists. Understanding EN 50128 is therefore essential for anyone who maintains such products, audits them, or plans their migration to EN 50716.

Lesson 2 – Key concepts and vocabulary

EN 50128 has a precise vocabulary. The terms below are explained in plain language; the standard's own definitions are more formal.

Software safety integrity level (SIL) – a classification from 1 to 4 that expresses how much confidence is needed that the software performs its safety functions correctly. SIL 4 is the most demanding. The level is allocated by the system safety process and the software team inherits it.
Basic Integrity (formerly SIL 0) – the lowest level, for software whose functions have a safety impact below SIL 1 or no safety impact. The 2011 text called it SIL 0; amendment A2 renamed it to match EN 50126. It still requires a controlled, quality-managed process.
Systematic fault – an error built into the software or its data through a human or tool mistake; it is present in every copy and is triggered by particular conditions.
Verification – checking that the output of each lifecycle phase correctly and completely reflects its inputs and meets the requirements for that phase. It asks: did we build each piece right?
Validation – demonstrating that the complete software, as integrated on its target, meets its requirements and is fit for its intended use in the railway environment. It asks: did we build the right thing?
Assessment – an independent judgement, by a competent assessor, of whether the software, its process and its evidence conform to the standard and are fit for purpose. It is separate from verification and validation and looks at both.
Independence – a requirement that certain roles are performed by different people, sometimes in different parts of the organisation, so that a person does not check their own work and is not under pressure from schedule owners.
Generic software – software that can be used in many installations without change, such as the core program of an interlocking product.
Application data – the data that adapts generic software to a specific installation, such as the track layout, signal routes and locking rules of one station. Errors in it are as dangerous as errors in code.
Support tool – any software tool used in development or verification: compilers, code generators, test tools, static analysers, configuration management systems. EN 50128 classifies them as T1, T2 or T3 by their potential impact on the executable software.
Technique or measure – a named engineering method, such as structured programming, a coding standard, static analysis or boundary value testing, listed in Annex A and described in Annex D.
Recommendation levels – the labels Annex A gives each technique per SIL: M (mandatory), HR (highly recommended; not using it needs a justification), R (recommended), "–" (no recommendation for or against) and NR (not recommended; using it needs a justification).
Software Quality Assurance Plan (SQAP) – the plan that defines the lifecycle, activities, documents, techniques and responsibilities for the software project.
Safety case – the structured argument, with evidence, that a system is acceptably safe. In rail it is defined by EN 50129; software evidence from EN 50128 feeds into it.

Where the SIL comes from

Beginners often assume the software team chooses its SIL. It does not. Under EN 50126 and EN 50129, the railway system is analysed for hazards: events such as two trains being given conflicting routes. Each hazard receives a tolerable hazard rate, and safety functions that protect against it receive a tolerable functional failure rate, from which a SIL is allocated to the function and to the subsystems that implement it. When software implements part of a function, it inherits the corresponding software SIL. EN 50128 then says what the development process must look like for that level. Figure 2 shows this flow.

Figure 2 – The software integrity level is an input from the system safety process, and the software evidence flows back into the safety case.

Two consequences follow. First, a software team cannot lower its workload by declaring a lower SIL; the allocation must be traceable to the system analysis. Second, if the system architecture changes – for example, a hardware monitor is added that catches certain software errors – the SIL allocated to a software component might change, but only through the system safety process.

Lesson 3 – Structure of the standard

EN 50128:2011 is organised so that the general rules come first, then the assurance activities that span the whole lifecycle, then the development phases themselves, and finally deployment and maintenance. The annexes hold the technique tables, role definitions and supporting guidance. The map below paraphrases each part; the clause numbers are the ones practitioners use to find their way.

Clauses

Clauses 1–3 – scope, normative references, and terms, definitions and abbreviations.
Clause 4 – objectives, conformance and software safety integrity levels – how conformance is claimed, how the SIL is taken from the system process, and the principle that every applicable requirement must be shown to be satisfied at the given level, with evidence.
Clause 5 – software management and organisation – the organisation, roles and responsibilities (5.1), personnel competence (5.2), and lifecycle issues and documentation (5.3), including the need to select and document a lifecycle model.
Clause 6 – software assurance – the activities that run across the lifecycle: testing (6.1), verification (6.2), validation (6.3), assessment (6.4), quality assurance (6.5), modification and change control (6.6), and support tools and languages (6.7).
Clause 7 – generic software development – the phases from software requirements (7.2) through architecture and design (7.3), component design (7.4), component implementation and testing (7.5), integration (7.6), to overall software testing and final validation (7.7).
Clause 8 – development of application data or algorithms – requirements for systems configured by application data, covering how the data is specified, prepared, verified, validated and controlled, at the same integrity level as the software it configures.
Clause 9 – software deployment and maintenance – how released software is installed in the field (9.1) and how it is changed during its service life (9.2).

Annexes

Annex A (normative) – criteria for selecting techniques and measures. It contains tables for each lifecycle activity (for example requirements, architecture, design and implementation, verification and testing, integration, overall testing, quality assurance, maintenance and data preparation) and more detailed tables on topics such as coding standards, programming languages, static analysis, dynamic analysis and testing, and test coverage.
Annex B (normative) – key software roles and responsibilities: requirements manager, designer, implementer, tester, verifier, integrator, validator, assessor, project manager and configuration manager, with the competence each needs.
Annex C (informative) – a document control summary that lists the documents normally produced in each phase and who writes, verifies and validates them.
Annex D (informative) – a bibliography of techniques that briefly describes each method named in Annex A.
Annex ZZ (informative, added by A1:2020) – the relationship between the standard and the essential requirements of the EU railway interoperability directive (EU) 2016/797.

How to read an Annex A table

Annex A is where the SIL becomes concrete. Each table lists techniques in rows and integrity levels in columns, and each cell carries a recommendation level. A project chooses a set of techniques for each activity and records the choice, with reasons, in its plans. Some illustrative points from the 2011 text as amended (always confirm against your licensed copy):

A modular approach to design is mandatory from SIL 1 upwards, and design and coding standards become mandatory at SIL 3 and SIL 4.
Traceability and functional, black-box testing are mandatory at SIL 3 and SIL 4 and highly recommended at SIL 1 and SIL 2.
Formal methods and formal proof are highly recommended at SIL 3 and SIL 4 and recommended at SIL 1 and SIL 2.
Static analysis, dynamic analysis and testing, and interface testing are highly recommended at every SIL from 1 to 4.

Some tables also define approved combinations of techniques: groups that, used together, are considered sufficient for a given level. Two rules matter in practice. First, an HR technique that is not used needs a written justification showing that an alternative gives equivalent confidence; "we did not have time" is not a justification. Second, a technique marked M must be used. The assessor later checks that the chosen set is appropriate and was really applied, not just written in a plan.

Lesson 4 – How it works in practice

Planning before coding

EN 50128 starts with planning. Clause 5.3 requires the project to select a lifecycle model and document it. The standard shows a V model as an example and accepts iteration between phases, but it does not force one particular model. The chosen lifecycle, the activities in each phase, the documents to be produced, the techniques selected from Annex A and the responsibilities of each role are written into the Software Quality Assurance Plan. Alongside it the project writes a Software Configuration Management Plan, a Software Verification Plan and a Software Validation Plan. These plans are drawn up at the start and kept up to date. The organisation is also expected to operate a quality management system; EN ISO 9001 is the usual reference.

The development phases

Figure 4 shows the V model used as the example in EN 50128. On the left the software is specified and designed in increasing detail; on the right it is tested and integrated in the reverse order. Each design document on the left produces a matching test specification that is executed on the right.

Figure 4 – The V-model example used in EN 50128: each specification on the way down defines the tests that are run on the way up.

Software requirements (7.2) – the Software Requirements Specification states what the software must do, including safety functions, interfaces, performance and constraints, in a form that can be verified and tested. The Overall Software Test Specification is written from it.
Architecture and design (7.3) – the Software Architecture Specification divides the software into components, identifies which ones are safety-related and records the architectural techniques from Annex A; the Software Design Specification and interface specifications add detail. Integration test specifications are written here.
Component design (7.4) – each component receives a design specification and a component test specification.
Implementation and component testing (7.5) – code is written to the design and to the project's coding standard, then tested at component level; results go into component test reports.
Integration (7.6) – components are integrated into the software and then with the target hardware, and the integration tests are run.
Overall testing and final validation (7.7) – the complete software is tested on its target against the requirements, and the validator writes the Software Validation Report and decides whether to agree to release.

After each phase the verifier checks the outputs and writes a verification report: requirements verification, architecture and design verification, component design verification, source code verification, integration verification. These reports are the backbone of the evidence. Bidirectional traceability ties it together: every requirement must lead to design, code and tests, and every piece of design and code must lead back to a requirement, so that nothing required is missing and nothing unrequested has crept in.

Roles and independence

Annex B defines the roles and clause 5.1 defines which roles may be combined in one person. The idea is simple: the people who create the software should not be the only people who judge it, and the person who decides whether the software is fit for release should not be under the authority of the person who owns the schedule. Independence requirements grow with the SIL. Figure 5 shows the preferred arrangement at SIL 3 and SIL 4.

Figure 5 – Preferred organisation at SIL 3 and SIL 4: developers report to the project manager, the verifier checks their work, the validator stays outside the project manager's line and decides on release, and the assessor is independent of the whole project.

In summary, as practitioner guides describe the 2011 text: from SIL 1 upwards, the people who write a piece of software should not be the only ones who verify or test it; the assessor must be independent of the project; and at SIL 3 and SIL 4 the validator must not report to the project manager, while verifier and validator are normally kept separate from the developers. At lower levels more roles may be combined. The exact combinations allowed at each SIL are set out in clause 5.1 – check them in your licensed copy before drawing the chart. These rules are why EN 50128 projects need a deliberate organisation chart, not just a team list.

Competence

Clause 5.2 requires each person in a role to be competent for it, and the organisation to record that competence: education, experience, training and knowledge of the techniques used. Annex B lists the competences expected of each role. An assessor will ask to see the evidence, not just a statement that staff are experienced.

Support tools

Tools can introduce or hide errors, so clause 6.7 classifies them by their potential impact:

T1 – tools whose output cannot contribute directly or indirectly to the executable code or data, such as a text editor or a requirements tool used only for documentation.
T2 – tools that support verification or testing, where a fault in the tool could fail to reveal an error but cannot create one in the executable, such as a static analyser, a coverage tool or a test harness.
T3 – tools whose output contributes directly or indirectly to the executable code or data, such as a compiler, linker or code generator, or a tool that builds application data.

Obligations grow with the class. T2 and T3 tools need a specification or manual and justified selection; T3 tools additionally need evidence that their output conforms to its specification or that errors in it would be detected, for example through a record of successful use, tool validation, diverse redundancy or checks on the output. The project records these justifications, and the validator considers them.

Application data

Many railway products are generic software configured for each site. Clause 8 treats the production of that configuration as an engineering process of its own: there are application requirements, a plan for preparing the data, rules for how data is produced (often by tools, which are then T3), verification of the data and its tools, testing of the configured system, and validation. A wrong entry in an interlocking's route table can be as dangerous as a coding error, so the data inherits the SIL of the software it configures.

Deployment and maintenance

Clause 9 requires releases to be identified and recorded and deployment to follow a plan, with records showing what was installed where; a tested way back to the previous version is good practice. In maintenance, every change goes through an impact analysis that decides which lifecycle phases must be repeated, and the change is verified, validated and, where needed, assessed at the original SIL. Change control under clause 6.6 and configuration management keep the evidence consistent with the delivered software.

Lesson 5 – Assessment, certification and compliance

Who decides that software conforms

There is no "EN 50128 certificate" issued by CENELEC. CENELEC writes the standard; it does not certify companies or products against it. Conformity is shown through evidence and judged by people with defined independence:

Verifiers check each phase's outputs and record the results in verification reports.
The validator checks the complete software against its requirements and intended use and gives agreement or disagreement for release.
The assessor, often called an independent safety assessor, judges whether the process, the techniques chosen and the evidence conform to the standard and are adequate for the SIL. The assessor writes a Software Assessment Plan at the start and a Software Assessment Report at the end, and also checks that the selected Annex A techniques suit the development and were actually applied.

The assessor is normally independent of the supplier, typically from a specialist assessment company; at the discretion of the safety authority the assessor may sit within the supplier's or the customer's organisation – but always independent of the project. Assessment companies often issue certificates or assessment reports stating that a product or a process was found to conform to EN 50128 at a given SIL. These are valuable evidence, but they are statements by that company, not an official CENELEC status, and their scope must be read carefully: which product version, which configuration, which SIL, which conditions of use.

How software evidence reaches approval

Software conformity alone does not put a system into service. The software assessment report and verification and validation evidence feed the generic product safety case and, later, the specific application safety case defined in EN 50129. Those safety cases are in turn assessed and accepted through the railway approval process. In the European Union this involves, depending on the case, assessment bodies under the common safety method for risk assessment, notified bodies for interoperability requirements, and the national safety authority or the EU Agency for Railways. Outside Europe, railway authorities and infrastructure managers often require EN 50128 or IEC 62279 conformity by contract.

What assessors look for

A coherent set of plans that match what the project actually did.
Justified technique choices for every Annex A table that applies, with reasons for any HR technique not used.
An organisation chart that respects the independence rules for the SIL, and competence records for every role.
Complete, bidirectional traceability and verification reports for every phase.
Tool classifications and the required justification for each T2 and T3 tool.
Controlled configuration: the evidence must refer to the exact software and data versions released.

Compliance during the transition

With EN 50716 now the current standard, a common question is what happens to products already assessed against EN 50128. The standard itself does not void existing approvals; a product accepted into service does not become unsafe on the withdrawal date. What changes is the reference for new work. New developments should normally be planned against EN 50716. For modifications to legacy products, the project should agree in its safety plan, with its assessor, its customer and, where relevant, the safety authority, which standard applies and how existing EN 50128 evidence will be reused. Contracts may also name a specific edition. Write that decision down early; discovering it during assessment is expensive.

Lesson 6 – Worked example: maintaining a computer-based interlocking

RailNova (a fictional company) supplies a computer-based interlocking. Its generic software was developed and assessed against EN 50128:2011 at SIL 4 in 2016; each station is configured with its own application data. In 2026 a customer asks for a new feature – support for a new type of axle counter interface – and three new stations. Follow how RailNova applies the standard.

Step 1: confirm the reference standard

The customer contract, signed in 2019, names EN 50128:2011. RailNova's safety manager raises the transition question with the customer and the independent assessor. Together they agree that the generic product change will be carried out under EN 50128:2011 with A1 and A2, because the existing evidence base is built on it, and that a gap analysis against EN 50716 will be prepared for the next major release. The decision and its reasons are recorded in the safety plan and the SQAP.

Step 2: impact analysis

Under clause 9.2 the change starts with an impact analysis. The new interface touches one software component that decodes axle counter messages and the architecture specification that describes external interfaces. The analysis concludes that the requirements, architecture, the affected component's design, code and tests, integration tests and overall validation must be revisited; unaffected components keep their existing evidence, supported by regression testing. The SIL stays at 4 because the system hazard analysis is unchanged.

Step 3: organisation

The project manager assigns a requirements manager and designer for the change, and an implementer. Testing and integration go to a separate team. The verifier is from the same company but not from the development team. The validator belongs to the independent safety department and reports to its head, not to the project manager, as required at SIL 4. The assessor's company confirms it will assess the change. Competence records for the new team members are added to the project file.

Step 4: techniques and tools

The SQAP update lists the Annex A techniques used: the existing coding standard (a language subset of C with project rules), static analysis, boundary value analysis and equivalence classes for the decoder, structural coverage targets for the new code, and a formal model of the message protocol checked with a model checker. The team does not use dynamic memory, which the coding standard forbids. The compiler (T3) has a long record of use on this product, backed by a test suite rerun on each compiler version; the static analyser and coverage tool (T2) have documented specifications and justified selection. A new script that generates message tables from the interface specification is classified as T3 because its output becomes part of the executable; the team adds an independent check that compares generated tables with the specification.

Step 5: development and verification

The requirements manager updates the Software Requirements Specification with six new requirements and two changed ones, each tagged and linked to the system requirement. The architect updates the interface section. The implementer writes the new decoder; the tester runs component tests from the component test specification and records coverage. The verifier reviews each updated document and the code, runs the static analyser, checks traceability in both directions, and writes verification reports. One finding – a timeout requirement with no test – is closed by adding a test case before integration.

Step 6: application data for the new stations

For each of the three stations, the application data team writes an application requirements specification from the track layout and signalling plans, prepares the data with the qualified data tools, and has it checked by an independent data verifier, including automated consistency checks and a review of every route and its locking. The configured interlocking is tested on a simulator against the station's signalling plan, then validated.

Step 7: validation, assessment and release

The tester runs the overall software tests on target hardware. The validator reviews the evidence and test results, confirms that every requirement is traced and tested, and gives agreement to release in the Software Validation Report. The assessor samples the plans, verification reports, tool justifications and organisation records, and issues an assessment report for the new software version and its conditions of use. RailNova updates its generic product safety case; each station's specific application safety case cites it. A release note identifies the exact software and data versions, and deployment follows the deployment plan with records and a rollback procedure.

Step 8: prepare for EN 50716

In parallel, a small team maps RailNova's process to EN 50716. Practitioner commentary highlights differences: EN 50716 drops the separate integrator role, replaces named programming languages with language criteria, adds guidance on iterative lifecycles and modelling, and adjusts the organisation rules. The team identifies which procedures and templates must change, so that the next major release can be planned under the new standard without surprises.

Lesson 7 – Relationship to other standards and frameworks

EN 50128 never worked alone. It was one part of a family of railway standards and a descendant of a generic functional safety standard. The table compares the most important relationships.

Standard	What it covers	Relationship to EN 50128
EN 50716:2023	Requirements for railway software development, for signalling and on-board rolling stock	The successor: supersedes EN 50128 and EN 50657 and keeps much of their structure, with updated organisation rules and lifecycle guidance
EN 50657:2017	Software on board rolling stock	A sister standard derived from EN 50128 for on-board equipment; also superseded by EN 50716
EN 50126-1 and -2:2017	RAMS process for the whole railway system and the systems approach to safety	Provides the overall lifecycle and the hazard analysis from which the software SIL comes
EN 50129:2018	Safety-related electronic systems for signalling, including the safety case	Covers hardware and system safety; EN 50128 evidence feeds its safety case
EN 50159	Safety-related communication in transmission systems	Covers safety of messages over networks; often applied with EN 50128 for interfaces such as the axle counter link
IEC 62279:2015	International railway software standard	The IEC counterpart based on EN 50128:2011; used where contracts cite IEC rather than EN
IEC 61508-3	Software requirements for generic functional safety	The parent concepts: SILs, technique tables and lifecycle discipline, adapted to rail
CLC/TS 50701 and IEC 62443	Railway and industrial cybersecurity	Address security, which EN 50128 does not cover directly; security threats with safety impact go into the hazard analysis

Comparing with other sectors

Engineers moving from other industries will recognise the pattern. ISO 26262 in automotive uses ASILs instead of SILs and a similar idea of methods tables; DO-178C in aviation uses design assurance levels and places strong emphasis on structural coverage and tool qualification. The railway family is distinctive in two ways: its explicit role definitions and independence rules, and the central place of an independent assessor and a formal safety case in the approval of each system. These features make it harder to merge an EN 50128 process with a general company process, so organisations usually map their standard procedures to the railway roles explicitly.

From EN 50128 to EN 50716

Because EN 50716 keeps the general clause order of EN 50128, a team that understands EN 50128 already knows most of the concepts in EN 50716: integrity levels, Annex A tables, verification, validation, assessment, tool classes and application data. The migration effort is mostly in procedures and organisation: who does integration, how roles may be combined, which lifecycle models are documented, how programming languages are justified, and how the newer Basic Integrity rules apply. Treat EN 50128 knowledge as the foundation and EN 50716 as the current text to build on.

Common pitfalls and best practices

Pitfalls

Treating the SIL as a software team choice and quietly lowering it to save effort, instead of taking it from the system hazard analysis.
Copying the Annex A tables into a plan without choosing and justifying techniques for this project, then failing to apply them.
Drawing an organisation chart that breaks independence, for example a SIL 4 validator who reports to the project manager under schedule pressure.
Ignoring application data and data-generation tools, as if only code could be dangerous.
Classifying a code or data generator as T2 to avoid the evidence a T3 tool needs.
Writing verification reports after the fact that do not match the versions actually released.
Assuming that an assessment company's certificate covers every later version, configuration or use of a product.
Starting a new development under EN 50128 in 2026 without an agreed reason, when EN 50716 is now the current reference.

Best practices

Agree the reference standard, edition and amendments with the customer and assessor at the start, and record the decision in the safety plan.
Involve the assessor early so that plans, technique choices and organisation are reviewed before work begins.
Maintain bidirectional traceability in a tool from requirements to tests, and check it at every phase.
Use a coding standard with tool-enforced rules and static analysis from the first line of code.
Classify every tool, keep its justification current, and rerun qualification checks when the tool version changes.
Treat application data with the same discipline as code: specification, controlled preparation, independent verification and testing.
Run a gap analysis against EN 50716 for every legacy product and plan the move before the next major release.
Keep competence records and independence arrangements up to date as people join and leave the project.

Summary and key takeaways

EN 50128:2011, corrected in 2014 and amended by A1 and A2 in 2020, was the CENELEC standard for software in railway control and protection systems; EN 50716:2023 supersedes it, with the transition ending on 30 October 2026.
Software fails through systematic faults, so the standard controls the development process and scales its rigour by integrity level rather than relying on measured failure rates.
The software SIL (Basic Integrity, formerly SIL 0, and SIL 1 to SIL 4) comes from the system safety process under EN 50126 and EN 50129.
The structure runs from organisation and lifecycle (clause 5) through assurance (clause 6), development (clause 7), application data (clause 8) and deployment and maintenance (clause 9), supported by the technique tables of Annex A and the role definitions of Annex B.
Verification checks each phase, validation judges the complete software for release, and an independent assessor judges conformity; independence requirements grow with the SIL.
Tools are classified T1, T2 or T3, and application data is engineered and verified at the same level as the software it configures.
Assessment reports and certificates from assessment companies are evidence for the safety case, not an official CENELEC certification.
Legacy EN 50128 evidence stays relevant for products in service, but new work should be planned against EN 50716 after an agreed decision with customer and assessor.

Reflection questions

Your company maintains a product assessed against EN 50128 at SIL 2. A customer asks for a change in 2027. Which people would you involve in deciding whether the change follows EN 50128 or EN 50716, and what would you record?
Draw the organisation chart of a project you know and check it against the independence rules for SIL 3 and SIL 4. Where would it fail, and what would you change?
List the tools your team uses to turn requirements into executable software and data. How would you classify each one as T1, T2 or T3, and what evidence would each need?
Choose one Annex A technique that is highly recommended at your SIL but that your team does not use. What would a convincing justification for an alternative look like?
How would you explain to a project manager why errors in application data deserve the same verification effort as errors in code?