EN 50128, the EN 5012x series, CENELEC, IEC 62278, SIL, and functional safety – what they all mean, how they are used, and how automated tools can help to achieve compliance

Software is no longer a bit-part contributor to electro-mechanical systems but is now the underlying technology providing functional safety for products in many market segments. The requirement for software functional safety has therefore become a critical topic in Guided Transport Systems (GTS) in general, and rail in particular. Like the automotive, medical device and process industries, the railway sector based their functional standard on the industry agnostic functional safety standard IEC 61508. The resulting EN 5012x series of standards has become dominant in railway functional safety and the software related objectives and processes of EN 50126-1, EN 50126-2, EN 50128, and EN 50129 are becoming increasingly familiar across the world.

The EN 5012x series standards and functional safety

Functional safety is concerned with the management of the level of risk in a piece of equipment or a system.

Functional safety development processes aim to identify potentially harmful conditions and to identify corrective actions to avoid or reduce the impact of an incident such that the response is proportionate to the risk. In practice, functional safety relies on active systems that can respond to a potentially dangerous situation. Examples include the initiation of sprinkler systems in response to a smoke detector being triggered, and the vital output of an axle counter limiting access to a track section.

The EN 5012x series (particularly EN 50128) is applicable to both such situations because both rely on electrical/electronic/programmable electronic safety-related systems.

Software in the context of the EN 5012x series: EN 50126-1, EN 50126-2, EN 50128, and EN-50129

Each of the EN 5012X series of standards has an impact on the software development lifecycle for EN 50128 railway applications.

EN 50126 is relevant to software systems, but not specifically focused upon them. It defines the four terms Reliability, Availability, Maintainability and Safety, and describes their interaction and their management.

It also defines a systematic process for specifying requirements for RAMS and demonstrating that those requirements are achieved.

EN 50126-1 Railway Applications. The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS). Generic RAMS Process

EN 50126-2 Railway Applications – The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS) – Part 2: Systems Approach to Safety

EN 50128 Railway applications – Communication, signalling and processing systems – Software for railway control and protection systems

EN 50128 focuses specifically on software systems and their environment. It specifies procedures and technical requirements for the development of safety related programmable electronic systems for use in railway control and protection applications.

EN 50129 Railway applications – Communication, signalling and processing systems – Safety related electronic systems for signalling

EN 50129 is relevant to software systems, but not specifically focused upon them. EN 50129 specifies the lifecycle activities which are to be completed before the acceptance stage, and the activities to be carried out after it. It is primarily concerned with the evidence to be presented for the acceptance of safety-related systems.

EN 50126-1:2017 Railway Applications. The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS). Generic RAMS Process

What are EN 50129 SILs (Safety Integrity Levels)?

Embedded software developers will be primarily concerned with EN 50128 with its focus on “Software for railway control and protection systems”. However, the level of effort required to complete each objective in the standard is dependent on the Safety Integrity Level (or “SIL” – not “SIL level”) of the safety functions implemented by the system. The derivation of the SIL is covered in more detail in EN 50129.

Briefly, a SIL can be assigned to any safety-related system, sub-system or component performing a safety relevant function. The process starts with the identification of potential hazardous events. Then a Tolerable Hazard Rate (THR) is assigned for each hazardous event that might occur because of a malfunction or failure of function, expressed as a probability per unit of time and considering risk reduction measures designed to reduce the rate of occurrence.

Each hazard is then associated with a functional failure of a function or set of functions, and the THR used to derive a Tolerable Function Failure Rate (TFFR). The table below shows how a SIL is derived from the TTFR.



From the specific perspective of software development, the SIL assigned to each software component has a considerable impact on its verification and validation activity and the overhead associated with it.

What other standards are related to EN 50128 and the EN 5012x series?

EN 50128 and IEC 62278, IEC 62779, and IEC 62280

The international standards IEC 62278, IEC 62779, and IEC 62280 very largely mirror EN 50126, EN 50128 and EN 50129 respectively and can be considered to be identical in the context of software development.

EN 50128 and IEC 61508

EN 50128 and the other EN 5012x series standards are examples of sector-specific functional safety standards derived from IEC 61508,“Functional safety of electrical/electronic/programmable electronic safety-related systems”. Other examples include ISO 26262 for motor vehicles, and IEC 62304 for medical devices.

Examples of the influence of IEC 61508 include the use of Safety Integrity Levels, and more generally a phased development approach with processes and evidential artefacts relating to each phase with a requirement for traceability between those phases.

At a conceptual level EN 50128 life cycle processes are very similar to IEC 61508, but the standard uses terminology and contextual examples that are directly relevant to the rail and GTS industries.

EN 50128 and CENELEC EN 50128, et al.

CENELEC is the organisation that was responsible for writing the EN 50126-1, EN 50126-2, EN 50128 and EN 50129 standards, and as a result they are still often known as CENELEC EN 50126, CENELEC EN 50128 and CENELEC EN 50129 standards across European countries.

EN 50128 and EN 50657

EN 50657 is similar in nature to EN 50128. EN 50128 is focused on software for railway control and protection systems, and the EN 50657 standard fulfils a similar role the development of software for use in rolling stock applications.

EN 50128 and IEC 62443

In the rail and GTS industry, the evolution from closed, wired isolated networks to open, interconnected networks has led to a new generation of threats. EN 50128 and the EN 5012x series only deal with cybersecurity indirectly (when such threats have implications for safety), and they provide no specific guidance on how to address them.

For that reason, many GTS and rail projects have specified adherence to the IEC 62443 standard, particularly IEC 62443-4-1. The IEC 62443 series is a series of multi-industry standards defining cybersecurity protection methods and techniques categorised to apply to all stakeholders including manufacturers, asset owners and suppliers. The fourth in the series, IEC 62443-4:2018, specifies the requirements for the secure development of systems used in industrial control and automation. Rail and GTS systems can be viewed as a niche example of this general case.

EN 50128 and CLC/TS 50701

June 2021 saw the publication of CLC/TS 50701, “Railway applications – Cybersecurity”. CLC/TS 50701 aims to ensure that bad actors cannot compromise the RAMS characteristics of railway systems. The security models, the concepts, and the risk assessment process it describes are based on or derived from IEC 62443 series standards (above), adapted to a rail-specific context. CLC/TS 50701 covers several key topics, the most relevant here being cybersecurity during a railway application life cycle.

How does LDRA help with EN 50128/EN 5012x compliance?

This V-model maps the capabilities of the LDRA tool suite and complementary tools to the EN 50128 development lifecycle.

For each phase, EN 50128 identifies several items of required evidential documentation. Automating traceability between these different artefacts can help to make the process easier to manage and less error prone.

System development (EN 50126) phase & Software requirements (EN 50128 §7.2) phase

In the early part of the development lifecycle requirements are handled within one development process whether they impact software, hardware, or both.

The ideal tools for requirements management depends largely on the scale of the development. If there are few developers in a local office, a simple spreadsheet or Microsoft Word document may suffice. Bigger projects, perhaps with contributors in geographically diverse locations, are likely to benefit from an Application Lifecycle Management (ALM) tool.

The software requirements phase details the process of evolution of lower-level requirements as they relate specifically to the software system. That demands traceability between the system and software-specific requirements artefacts to demonstrate that all system requirements have been allowed for.

Bidirectional traceability

This notion of traceability between phases and back to requirements is referenced throughout the standards. It would be easy to assume that if the requirements are all shown to be catered for in design documentation and implemented and tested in the code, then the objective of the standard is satisfied. However, it is just as important to show that there is no code present that is surplus to the requirements. To achieve that requires “bidirectional traceability”.

Challenges arising during a project mean that traceability between project phases can become difficult to achieve. The TBmanager component of the LDRA tool suite automates traceability to both the project requirements and the standards’ objectives and highlighting inconsistencies, removing a major project management headache.

Software architecture and design phase (EN 50128 §7.3)

There are many tools available for the generation of the software architectural design, with graphical representation of that design being an increasingly popular approach.

Table A.3 describes characteristics that are to be part of the architecture of the system. The TBmanager component of the LDRA tool suite could be used to show that such objectives are being fulfilled. The TBvision component of the LDRA tool suite includes control and data flow analysis facilities, which aid verification of the correct interpretation of that design.

Software component design phase (EN 50128 §7.4)

This phase is when the activities are defined that are to take place in the software component implementation and testing, software integration phase, and software validation phases (EN 50128 §7.5, §7.6, and §7.7). These activities are covered in the each of those sections below. The “requirements for readability and traceability” specified in §7.5 are supported by the TBmanager component of the LDRA tool suite, as discussed previously.

Software component implementation and testing (EN 50128 §7.5)

The Software Component Design Specification is required to nominate techniques and measures. The recommendations in the standard leverage static analysis and dynamic analysis techniques in combination. Static analysis involves “examining” source code. Dynamic analysis involves executing programs, whether in part or as complete applications, on a real or virtual processor.

The standard references many appropriate solutions, including:

  • a modular approach to limit the complexity of software
  • adherence to the rules of structured programming
  • structured programming
  • the selection of coding standards, and adherence to the coding rules
  • the avoidance of specific programming language features
  • boundary value analysis

The LDRA tool suite supports the validation and verification of all these activities. The TBvision component calculates quality metrics to measure the complexity, loop nesting depth, procedure count, and other parameters, and compares them to configurable threshold values. It is also used to verify adherence to the coding rules specified by the coding standard, style guide, and/or language subset.

The TBrun unit test component of the LDRA tool suite provides boundary value analysis to detect software errors occurring around parameter limits, and structure-based testing and test coverage expose the completeness of testing. The level of coverage required is dependent on the applicable SIL – statement, branch/decision, MC/ DC (Modified Coverage/Decision Coverage), etc.

TBrun automatically generates test drivers and harnesses (wrapper code), enables tests to be easily and efficiently executed, and stores both test data and results. These tests can be automatically regressed. The test data maintenance process is streamlined through the automatic detection of changes in source code, prompting repeats of tests as necessary. The TBextreme option supplements TBrun, offering the option to automatically generate test cases the nature of which is user configurable.

The checklists recommended by the standard are provided by the TBmanager component of the LDRA tool suite, with many of the elements maintained automatically.

Software integration phase (EN 50128 §7.6)

Integration testing is designed to ensure that when the units are working together in accordance with the software architectural design, they meet the related specified requirements.

The illustration below shows how the software interface is exposed by TBrun at the function scope, allowing the user to enter inputs and expected outputs. The tool suite then generates a test harness, which is compiled and executed on the target hardware. Actual outputs are captured, along with structural coverage data, and then compared with the expected outputs specified in the test cases.

Whether that test harness encompasses a single function (unit test) or a call tree (integration test), the mechanism remains the same and hence includes all the same functionality (structural coverage analysis, auto-generated test cases, etc.) related to EN 50128 §7.5 (above).

Software validation phase (EN 50128 §7.7)

The validation phase represents the ultimate integration, where all parts of the system come together. It represents a continuation of the component implementation and integration phases (§7.5 and §7.6 above).

Arguably the software validation phase is therefore simply the last step in the integration phase, where all software and hardware components have been integrated into a complete system. It does however demand more complete tracing back to requirements and intermediate evidential artefacts, as reflected in the six input documents. Automating that traceability by using the TBmanager component of the LDRA tool suite will help to alleviate the project management burden.

Software maintenance phase (EN 50128 §9.2)

The software maintenance phase section of the standard references impact analysis. Impact analysis aims to determine the extent to which a change or an enhancement to a software system will impact upon the existing system, and the resulting verification of the modified software system. Possible decisions are:

  • Only the changed software module is re-verified
  • All affected software modules are re-verified
  • The complete system is re-verified

The analysis facilities provided by the TBmanager of the LDRA tool suite throughout the development life cycle are equally valuable during maintenance.

Support tools (EN 50128 §6.7)

The standard defines a mechanism to provide evidence that the software tool chain can be relied upon.  The required level of confidence in a software tool depends upon the circumstances of its deployment, with reference to the possibility that the malfunctioning software tool and its corresponding erroneous output can introduce or fail to detect errors in a safety-related development, and the confidence in preventing or detecting such errors in its corresponding output.

Tools are categorised into one of three categories. The LDRA tool suite is placed in the T2 (Tool Class 2) category because it “supports the test or verification of the design or executable code, where errors in the tool can fail to reveal defects but cannot directly create errors in the executable software” (EN 50128 §3.1.42). That differentiates tools like the LDRA tool suite from (say) auto code generators which have the potential to introduce errors into an application.

The LDRA tool suite has been certified as “fulfilling the requirements of support tools according to EN 50128” by two separate TÜV organisations.  For all but the most critical of applications existence of such a certificate is sufficient to establish confidence in the tool, saving considerable overhead in establishing that independently.

Where proof of fitness-for-purpose within a specified tool chain is required, the LDRA Tool Qualification Support Packs (TQSPs) contain the test cases to demonstrate both the structural coverage analysis and programming rules checking capabilities of the tool suite itself. In addition, associated documentation for the development and verification of the product is provided, including plans, procedures, and expected results.

Additional information and EN 50128/EN5012x training materials

EN 50128 PDF free downloads

EN 50128 further information

FREE 30 Day

Email Us

Email: info@ldra.com

Call Us

EMEA: +44 (0)151 649 9300

USA: +1 (855) 855 5372

INDIA: +91 80 4080 8707

Connect with LDRA