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.
The railway sector based their approach to functional standard on the industry agnostic functional safety standard IEC 61508 making it a subset of the broader remit RAMS procedures (Reliability, Availability, Maintainability, and Safety).
The resulting EN 5012x series of RAMS standards soon became dominant in railway functional safety, along with its software related objectives and processes.
EN 50716:2023 is the latest landmark on this landscape. It supersedes safety standards relating to software for railway control and protection systems (EN 50128) and software on board rolling stock (EN 50657), merging them and introducing cybersecurity into the mix.
RAMS (Reliability, Availability, Maintainability, and Safety) ensures system dependability and safety, especially in railways. For instance, a train control system must minimize downtime (availability), reduce maintenance (maintainability), ensure reliability, and prevent unsafe conditions (safety).
Functional safety, a subset of RAMS, manages risk levels in equipment or systems. It identifies harmful conditions and corrective actions to mitigate incidents. Functional safety relies on active systems to respond to dangers. For example, if a sensor fails, the system detects it and takes actions (e.g., halting the train) to prevent accidents.
Historically, EN 50128 dealt with “Railway applications – Communication, signalling and processing systems – Software for railway control and protection systems” while EN 50657 was concerned with “Rolling stock applications – software on board rolling stock”.
Merging the standards simplified the regulatory landscape and eliminated any inconsistencies between the original documents and resulted in EN 50716 which addresses “Railway applications – software development”.
The following table illustrates how recently these changes relate to other standards pertinent to the software development lifecycle for safety related railway software development, from a functional safety perspective.
Helpfully, the chapter numbering of EN 50128 has been retained in the new standard, making it easy to compare the two. Some of the detailed changes in the new document are discussed in the following sections, but the following list serves as an overview:
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.
Given that RAMS principles are a superset of functional safety, it follows that the RAMS standards EN 50126, EN 50129, and EN 50716 are applicable to both such situations because they each rely on electrical/electronic/programmable electronic safety-related systems.
Embedded software developers will be primarily concerned with EN 50716 with its focus on “Requirements for software 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.
The table excludes systems or functions that do not require additional safety measures beyond standard operational controls. Previously categorized under SIL 0, in EN 50716 they are now considered to have “Basic Integrity”.
Unlike EN 50128, EN 50716 requires that least one quality assurance process is applied to all non-safety-related functions. A restriction in EN 50128 §1.3 stating that the standard does not apply to non-safety-related functions does not appear in EN 50716.
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. With roots that predated connectivity, EN 50128 only dealt with cybersecurity indirectly (when such threats had implications for safety) and provided no specific guidance on how to address them.
EN 50716 addresses that limitation and references cybersecurity considerations throughout.
However, it recommends leveraging a cybersecurity-specific standard for the detail. Potential candidates include:
Many GTS and rail projects have concurrently complied with EN 50128 and 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.
August 2023 saw the publication of the second edition 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 the definition of a cybersecurity framework.
EN 50716 covers cybersecurity much more comprehensively than EN 50128, with pertinent information referenced throughout the development lifecycle. For example, EN 50716 §4 “Software Development Lifecycle” includes guidelines on integrating cybersecurity measures throughout the software development process, and EN 50716 §8 “Development of Application Data” emphasizes the need for secure data handling and protection against cyberthreats.
However, it is stressed in the introduction that EN 50716 “…does not specify the requirements for the development, implementation, maintenance and/or operation of security policies or security services needed to meet cybersecurity requirements that may be needed by the safety-related system.” It goes on to recommend the use of appropriate standards for that purpose, including ISO/IEC 27000, ISO/IEC/TR 19791, CLC/TS 50701, and the IEC 62443 series.
EN 50716 and CLC/TS 50701 are therefore crucial and complementary standards for cybersecurity in railway applications. They complement each other such that EN 50716 includes specific references to cybersecurity measures that align with the broader framework provided by CLC/TS 50701.
Many other standards are pertinent to EN 50716 and the RAMS standards in general, several of which are referenced by the standard itself. Some of the most pertinent are detailed below:
The international standards IEC 62278, IEC 62279, 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. For now, IEC 62279 remains valid and active despite EN 50128 having been superseded by EN 50716.
The functional safety aspects of EN 50716, EN 50126 and EN 50129 are derived from IEC 61508,“Functional safety of electrical/electronic/programmable electronic safety-related systems”. Other examples of IEC 61508 influence can be found in ISO 26262 for motor vehicles, and IEC 62304 for medical devices.
Examples of the influence of IEC 61508 in EN 50716 include the use of Safety Integrity Levels, and more generally a phased development approach with processes and evidential artifacts relating to each phase with a requirement for traceability between those phases.
At a conceptual level EN 50716 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.
CENELEC is the organization that was responsible for writing the EN 50126, EN 50716, and EN 50129 standards. As a result, they are still often known as CENELEC EN 50126, CENELEC EN 50716, and CENELEC EN 50129 respectively, across European countries.
The LDRA tool suite underpins the software development processes defined in the EN 50126, EN 50716 & EN 50129 standards.
This V-model maps the capabilities of the LDRA tool suite and complementary tools to the specified development lifecycle.
For each phase, EN 50716 identifies several items of required evidential documentation. Automating traceability between these different artifacts can help to make the process easier to manage and less error prone.
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 artifacts to demonstrate that all system requirements have been allowed for.
This notion of traceability between phases and back to requirements is referenced throughout the standards and enhanced in EN 50716. 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.
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 locally, while LDRAvault could be applied across larger organisations. 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.
Examples of changes in EN 50716 §7.3 compared to EN 50128 include
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 50716 §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 and LDRAvault, as discussed previously.
Examples of changes in EN 50716 §7.4 compared to EN 50128 include
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:
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.
The optional TBjustify module can be specified to manage the documentation of justifications concerning coverage for certification and compliance purposes.
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.
Examples of changes in EN 50716 §7.5 compared to EN 50128 include
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 50716 §7.5 (above).
Examples of changes to EN 50716 §7.6 compared to EN 50128 include
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 artifacts, 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.
Examples of changes to EN 50716 §7.7 compared to EN 50128 include:
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:
The analysis facilities provided by the TBmanager of the LDRA tool suite throughout the development life cycle are equally valuable during maintenance. In particular, if a system is compromised by an aggressor, the capacity to perform impact analysis and focused retest on a system that may have been untouched for years is especially valuable.
This point is highlighted in the introduction to EN 50716, which states that “It may be necessary to balance between measures against systematic errors and measures against security threats. An example is the need for fast security updates of software arising from security threats, whereas if such software is safety related, it should be thoroughly developed, tested, validated and approved before any update.”
Other examples of changes to EN 50716 §9.2 compared to EN 50128 include:
EN 50716 describes how software tools can be used in the development of compliant software.
The standard defines a mechanism to provide evidence that the software tool chain can be relied upon – a process known as tool qualification. 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 50716 §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 organizations. 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.
The concept of tool diversity was introduced into the ultimate version of EN 50128 and has been carried over to EN 50716. It relates to T3 tools which are primarily involved in the creation or transformation of code (such as code compilers and generators) and T2 tools for verifying code or data (typified by the LDRA tool suite). Tool diversity allows T3 tools to delegate some verification tasks to T2 tools. As stated in §6.7.4.4c, tool diversity enables the user to ““Use one tool to perform the function and subject its output to verification of results by an independent tool… for example a rule-checking tool to confirm that the output conforms to all relevant rules.”
A typical example might be the use of the LDRA tool suite to check for the MISRA compliance of code generated by a Model-Based Development (MBD) tool.
Examples of changes to EN 50716 §6.7 compared to EN 50128 include:
EN 50716 references the need for due consideration of response timing for time-critical applications, and memory constraints. Specifically,
EN 50716 §D.45 requires that “An analysis is performed which will identify the distribution demands under average and worst-case conditions”.
The WCET of a computational task is the maximum length of time that the task could take to execute in a specific environment. Hard real-time systems need to satisfy stringent timing constraints imposed by the nature of the functions they fulfil. Unfortunately, it is not possible in general to calculate definitive upper bounds on execution times for programs.
There are further complications in the case of multicore processors. The use of additional cores results in resources being shared between them. Time-related delays occur as users wait for access.
These interference channels cause the execution-time distribution to spread. Instead of a tight peak, the distribution of execution times becomes wide with a long tail.
This page presents a practical, compliant approach to addressing this problem. It involves the optimisation of system configuration by means of interference research through measured execution times using the TBrun component of the LDRA tool suite supported by the optional TBwcet module.
Software has evolved from a minor component to a critical technology underpinning functional safety across various market segments. This shift has made software functional safety a crucial topic in Guided Transport Systems (GTS), particularly in the rail industry.
The railway sector adapted the principles of the industry-agnostic functional safety standard IEC 61508, integrating them into the broader RAMS (Reliability, Availability, Maintainability, and Safety) procedures.
The EN 5012x series of RAMS standards emerged as the dominant framework for railway functional safety, encompassing software-related objectives and processes. The latest development in this area is that EN 50716:2023 has superseded both EN 50128 and EN 50657, merging them and incorporating cybersecurity considerations.
The LDRA tool suite provides a robust foundation for embedded software development for the rail and GTS sector throughout the entire development lifecycle, ensuring compliance with these evolving standards and enhancing the overall safety and reliability of railway systems.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707