The new EN 50716:2023 'Requirements for Software Development' Part 1

In November 2023, CENELEC released the new EN 50716:2023 "Railway Applications - Requirements for software development" (DAV: 2023-11-17). This replaces the previous standard EN 50128. In our work at CSA Engineering, with customer mandates and projects in the safety-critical domain, this replacement and the associated changes are relevant to our work. Based on the Swiss edition of the new EN 50716:2023, we focus in this article on some major changes compared to the predecessor standard EN 50128:2011.  

Initial Situation Comparison

For the comparison, we use the Swiss editions [SN EN 50716:2013] and the [SN EN 50128:2011]

The sidebar of the *.pdf Compare Tools is predominantly red, indicating that many sections have been revised. 
 
It is worth highlighting positively that the chapters of [SN EN 50128:2011] have been adopted in the new standard. Only some subchapters have been omitted. To maintain the chapter numbering, they are marked as "Intentionally left blank." This significantly facilitates navigation in the new standard. 

Figure: Changed text sections between EN 50716:2023 and EN 50128:2011

The following major changes result in the individual chapters

1. Scope 

The [SN EN 50716:2013] replaces the [SN EN 50128:2011] and the [EN 50657:2017] including their amendments. The division of software development requirements into a standard for signaling systems and one for vehicles is eliminated. Additionally, the standard is now also applicable to software with Basic Integrity (formerly SIL0). The restriction in 1.3 that the standard has no significance for non-safety-related software has been deleted. 

2. Normative references 

No normative references are listed in the chapter anymore. 

3. Terms, definitions and abbreviations 

Some terms have been aligned with other standards and supplemented with source references from ISO and IEC. The abbreviation INT "Integrator" has been deleted. 

4. Software integrity levels conformance 

For all non-safety-related functionalities of the software, at least one quality assurance process should be applied. One of the recommendations is the "Basic Integrity" requirements of [SN EN 50716:2023]. 

An important point is listed in 4.1 NOTE 2: The term "System Requirements Specification" in the standard encompasses the entire system requirements, including safety requirements. The question of whether the requirements must be divided into two separate documents (safety and non-safety) is, in our opinion, definitively settled. 

5. Software management and organization 

The aim in 5.1.1 to ensure the organizational independence of the various roles is now described in greater detail instead of in one sentence. Particularly, 5.1.1 b) refers to the pressure from colleagues or superiors as well as profit thinking, which could affect safety. 

The challenge for individual managers will be to not only focus on key figures but to embody the principles of their own safety policy. ERA has published good information on "Safety Culture."

To the publication >

5.1.2.4 now only requires that an assessor must be assigned for SIL 1 to SIL 4 systems. No assessor is required for Basic Integrity.

In the organizational chart, the integrator has also been deleted. 

6. Software assurance 

In 6.3.4.12, it is noted that the validator can now conduct additional audits. However, audits were already included in the role description B6.12 in the [SN EN 50128:2011]. This difference has now been rectified.

6.4.1.2 reiterates that no assessment is needed for Basic Integrity.

What documents are required for Basic Integrity? In the table "A.1 — Lifecycle issues and documentation," it is noted that the SW architecture and design specification are now only recommended (R) and no longer (HR). Also, the SW Component Design and Test have been downgraded from (R) to (-). However, the interface of Basic Integrity modules must still be "Fully defined interface" (HR).

Regarding tool selection, 6.7.1 describes in detailed text that a tool used as a functional part of software must be developed according to the corresponding SIL. The [SN EN 61508-3:2010] describes this more elegantly in our opinion; in chapter 7.4.4, there are online software tools and offline tools with the respective requirements. 

7. Software development 

The Integrator role has been replaced by Tester.

According to 7.3.4.25, an appropriate programming language should be chosen based on the criteria of table A.15. The table no longer lists languages like ADA, BASIC, C, PL/M, etc., but instead lists 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 chapters "Development of application data or algorithms" and "Software deployment and maintenance" are examined in more detail in the second part of the blog "Standard Replacement EN 50716." This is partly due to the high importance of these topics for the successful implementation of the standard and partly due to the extensive content that requires separate consideration. 

8. Development of application data or algorithms: systems configured by application data  

The development of application data and algorithms plays a central role in configuring 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 must be established that ensure the quality and safety of the software.

The extensive content of these two chapters makes it necessary to consider them separately in the second part of the blog. This allows complex topics to be given the necessary attention, providing readers with a deeper insight into the requirements of the standard. 

Conclusion 

An initial analysis showed that the new [SN EN 50716:2023] is structurally aligned with the predecessor standard [SN EN 50128:2011], achieving easy familiarization and findability. With the adjusted points, the [SN EN 50716:2023] is, in our opinion, a successful update that uniformly describes how software for railway applications, regardless of whether for infrastructure or vehicles, must be developed. Chapters 8 and 9 require a detailed analysis, which will be conducted in a second part. A detailed analysis is also necessary for adapting templates, checklists, and the preparation of specifications.

Are you planning normative or general Requirements Engineering tasks?

We at CSA Engineering AG are happy to support you in your endeavor. Contact us for a non-binding conversation about the possibilities and the most suitable support.

References

[SN EN 50716:2023] SN EN 50716:2023, Railway Applications - Requirements for software development, Cross-sector software standard for railways, Applications ferroviaires - Exigences pour le développement de logiciels

[SN EN 50128:2011] SN EN 50128:2011, Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems

[SN EN 50128:2011/A1] SN EN 50128:2011:A1:2020, Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems,  Amendment A1

[SN EN 50128:2011/A2] SN EN 50128:2011:A2:2020, Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems, Amendment A2

[EN 50657:2017] Railways Applications - Rolling stock applications - Software on Board Rolling Stock, CENELEC https://standards.cencenelec.eu/dyn/www/f?p=CENELEC:110:::::FSP_PROJECT,FSP_ORG_ID:61081,1257173&cs=1BBC9EC922AB97226B550F1C598F5BE6D 

[SN EN 61508-3:2010] SN EN 61508-3:2010, Functional safety of safety-related electrical/electronic/programmable electronic systems - Part 3: Requirements for software