EN 50716: Railway Safety Software

22/07/2025

A few years ago, at LEEDEO we were already anticipating the much-needed update of the CENELEC standard UNE-EN 50128:2012. Firstly, due to the need to align the standard with the relatively recent updates to CENELEC UNE-EN 50126:2018 and CENELEC UNE-EN 50129:2020. Secondly, because of the corrections that UNE-EN 50128:2012 itself had begun to accumulate. And most importantly, to keep pace with a software industry that has evolved substantially over the past decade and urgently required a corresponding revision of the related standard.

Finally, this update has materialized with the publication of CENELEC UNE-EN 50716:2023, which will supersede CENELEC UNE-EN 50128:2012 and CENELEC UNE-EN 50657:2017 in two years (the latter being very similar to 50128 but specifically addressing embedded software in rolling stock). Thus, the new standard consolidates software requirements for railway applications, regardless of their specific use.



The main changes introduced compared to its predecessor standards are as follows:

  • Improved alignment with CENELEC UNE-EN 50126:2018.

  • Some requirements have been simplified to enhance clarity.

  • Annex A has been updated to better align with the lifecycle phases.

  • Clauses C.1 and C.2 have been added to Annex C as informative guidelines on lifecycle models and software development "modelling".

  • Guidance has been added for software components according to their SIL level.

  • Requirements related to programming languages have been generalized.

However, beyond these changes, there are several aspects that we at LEEDEO believe should be highlighted in summary:

First, the improved alignment with the new CENELEC 50126 was a critical point to address, since that standard had already been updated and had therefore become misaligned in certain aspects with the other safety standards. It is important to note that CENELEC 50126 is mandatory in all projects, and thus CENELEC 50716 assumes, as a baseline, that both standards are applied together (just as 50128 did). As such, the existence of misaligned points between them was problematic (despite the corrections later introduced to CENELEC 50128). With the implementation of the new standard, however, this issue has been resolved.

Another highly significant point is the minimum requirements that must be considered for software requirements not deemed safety-related. The new standard establishes that such requirements must comply with a quality assurance process, either through adherence to the requirements for basic integrity (ISO/IEC/IEEE 90003) or through the application of relevant good practice codes. Furthermore, compliance with ISO 9001 alone is no longer sufficient to justify basic integrity requirements. Therefore, it is important to recognize that the new standard generally raises the bar for requirements with a SIL lower than 1 or with no safety impact—something highly relevant for quality and safety management in projects. As a result, the new standard clarifies, for many requirements, whether they apply to all software requirements or only to SIL levels 1 through 4.

Below is shown the most relevant timeline of European Safety Software Standards in the railway sector


Railway Software Standard Timeline
Railway Software Standard Timeline


At the organizational level, the new standard does not introduce major changes. However, it does provide clarifications and is easier to understand than its predecessors. That said, two important points should be highlighted:

First, the independence of the Validator and their requirements is now much more clearly defined—this role is often mistakenly assumed to require independence from RAMS engineers, which is not actually necessary.

Second, the role of the Integrator has been removed.

Additionally, guidance is included on how to proceed when a single project is developed by multiple organizations, which helps clarify the scope of the standard's application in such cases.

In addition, it is not possible to update the standard at a technical level without considering the use of new Artificial Intelligence technologies. The new standard introduces the possibility of using AI, providing very general guidelines as a foundation for its application in the railway sector.

Beyond these points, it is true that the standard introduces clarifications and new requirements that significantly support its correct application and understanding, bringing it up to date with the current context of software usage and development. As is well known, software has evolved considerably since the publication of the previous standards. Therefore, the release of this new standard successfully achieves its purpose and effectively renews the application procedures for railway software.





The technical requirements of each product are primarily derived from the potential threats created by the technology and regardless of its intended function. It is a good "trick" to use international regulations and standards to ensure that the technical solution adopted does not generate failures against security. In most cases, we will see that we correctly define a requirement of this type if it represents a limitation or obligation for the design, installation or use.

Contextual Security Requirements

The contextual requirements can be considered as a further classification of requirements of the relationship between the system and its environment (beyond the system itself) through contextual requirements. The contextual requirements would therefore address issues such as modes of operation and maintenance; operational restrictions related to safety, the training received by the personnel responsible for the operation and maintenance of the system, the profile of the specific mission, the particular logistics of the project, the particular characteristics, for example, of a given railway line, etc. Let's take some example:

  • In a certain line the maximum speed of the train must be limited due to the physical characteristics of the railway section.
  • The training of the personnel that operates with the system must be of certain characteristics to ensure the correct use of the system.

At Leedeo Engineering, we specialize in the development of RAMS projects, railway software, and the validation of systems with safety-critical software, providing support at any required level for RAM and Safety tasks in any project.




Are you interested in our articles about RAMS engineering and Technology?

Sign up for our newsletter and we will keep you informed of the publication of new articles.