New standard EN 50716:2023 «Requirements for software development» Part 1
In November 2023, CENELEC issued the new EN 50716:2023 «Railway Applications – Requirements for software development» (DAV: 2023-11-17).
This replaces the previous standard EN 50128. This replacement and the associated changes are relevant to our work at CSA Engineering, which involves customer mandates and projects in the domain of safety. Based on the Swiss version of the new standard EN 50716:2023, this article focuses on a few main changes to its predecessor EN 50128:2011.
A comparison for context
For the comparison, we have used the Swiss versions of the standards [SN EN 50716:2013] and [SN EN 50128:2011]
The sidebar of the PDF comparison tool is predominantly red, which means that a large amount of text has been revised.
However, one notable positive aspect is that the chapters of [SN EN 50128:2011] have been included in the new standard. Only individual sub-chapters have been omitted. In order to make sure that the chapter numbering remained the same, these sub-chapters have been designated as “intentionally left blank”. This makes it much easier to find your way around the new standard.
Figure: Amendments to the text in EN 50716:2023 compared to EN 50128:2011
The following main changes have been made to the individual chapters
1. Scope
[SN EN 50716:2013] replaces [SN EN 50128:2011] and [EN 50657:2017] including their amendments. It is no longer necessary to divide up the software development specifications into a standard for signalling installations and one for vehicles. The standard can also be applied to software with basic integrity (formerly SIL0). The restriction in 1.3 stating that the standard is not applicable to non-safety-related software has been deleted.
2. Normative references
This chapter no longer lists the normative references.
3. Terms, definitions and abbreviations
Some terms have been aligned with other standards and supplemented with references from ISO and IEC. The abbreviation INT “Integrator” has been deleted.
4. Software integrity levels conformance
The use of least one quality assurance process is stipulated for all non-safety-related functions of the software. One of the recommendations is the “basic integrity” requirements of [SN EN 50716:2011].
An important point is listed in 4.1 NOTE 2: In the standard, the term “System Requirements Specification” encompasses all system requirements, including safety requirements. In our opinion, this definitively answers the question of whether the requirements need to be divided into two separate documents (safety-related and non-safety-related).
5. Software management and organization
The objective set out in 5.1.1 of ensuring the organisational independence of the different roles was previously given a single sentence but has now been described in more detail. In particular, 5.1.1 b) refers to pressure from peers or supervisors and profit-focused thinking that could impact safety.
The challenge for individual managers will be not only to focus on key figures, but also to exemplify the principles of their own safety policy. ERA has published good information about safety culture.
5.1.2.4 only requires that an assessor be assigned for SIL 1 to SIL 4 systems. An assessor is no longer required for basic integrity.
The integrator has also been removed from the organisational chart.
6. Software assurance
A notable change in 6.3.4.12 is that the validator can now carry out additional audits. However, audits were already included in the B6.12 role description in [SN EN 50128:2011]. This difference has now been corrected.
6.4.1.2 reiterates that no assessment is required for basic integrity.
Which documents are required for basic integrity? In the table “A.1 – Lifecycle issues and documentation,” one notable difference is that the software architecture and design specifications are now only recommended (R) and no longer highly recommended (HR). In addition, the software component design and test have been downgraded from (R) to (–). However, the standard still stipulates that the interface of basic integrity modules must be a “fully defined interface” (HR).
With regard to tool selection, 6.7.1 goes into some detail about how a tool that is used as a functional component of software must be developed according to the relevant SIL. In our opinion, [SN EN 61508-3:2010] handles this more elegantly; chapter 7.4.4 describes online software tools and offline tools with the corresponding requirements.
7. Software development
The role of integrator has been replaced by that of tester.
According to 7.3.4.25, a suitable programming language should be selected according to the criteria of Table A.15. The table no longer lists languages such as ADA, BASIC, C, PL/M, etc., but rather the requirements for the language such as modular programming, support for commenting, strict typing or testability. In the referenced Table D.54, the requirements for the programming language have been revised. This makes it possible to qualify newer languages such as Rust.
Chapters 8 and 9
The second part of the blog on the replacement of the EN 50716 standard will take a closer look at the chapters “Development of application data or algorithms” and “Software deployment and maintenance”. This is partly because these issues are crucial to successful implementation of the standard, and partly because they encompass a large amount of content that merits being looked at separately.
8. Development of application data or algorithms: systems configured by application data
The development of application data and algorithms plays a key role in the configuration of systems according to EN 50716.
9. Software deployment and maintenance
Software deployment and maintenance is another important aspect of the standard. To ensure the safety and reliability of railway systems, software processes and procedures need to be established that guarantee safe and high-quality software.
The extensive content of these two chapters makes it necessary to consider them separately in the second part of the blog. This allows the necessary attention to be paid to the complex issues and gives readers a deeper insight into the requirements of the standard.
Conclusion
An initial analysis has shown that the new [SN EN 50716:2023] is structurally aligned with the predecessor standard [SN EN 50128:2011], making it easy to navigate and get to grips with the content. We believe that the aspects that have been adapted in [SN EN 50716:2023] make it a successful project that uses a standardised framework to describe how software for railway applications has to be developed, regardless of whether it is intended for infrastructure or vehicles. Chapters 8 and 9 require a detailed analysis, which will be covered in a second part of the blog. The adaptation of templates, checklists and the development of specifications also need to be looked at in detail.
Are you planning normative or general requirements engineering work?
We at CSA Engineering AG would be happy to help you with your project. Contact us for an informal discussion about the options available and how we can support you.