On this page
- Buy the published EN 50716:2023 document
- Scope: signalling and onboard software
- EN 50716, EN 50128 and EN 50657: avoid a numbering mistake
- Build a software purchasing boundary
- Example: updating an onboard software application
- How this fits the wider railway library
- Questions before buying
- Sources and edition check
The published product on Genorma is EN 50716:2023. A separate record labelled EN 50716:2023/prA1:2026 is a draft amendment, not a published A1 amendment. Keep those two document statuses separate when specifying an order or updating a software development plan. Published standard; draft amendment record.
Buy the published EN 50716:2023 document
DIN Media lists DIN EN 50716:2024-09 as the German adoption of EN 50716:2023, with national corrections from 2025. If your contract requires that adoption, check those correction records; do not relabel them as a European A1:2025. DIN Media adoption and corrections.
Scope: signalling and onboard software
The published scope covers software for programmable electronic systems used in signalling control and command, and in onboard rolling-stock applications. Its focus is software and the interaction with its system. Application programming, operating systems, support tools and firmware are included; fixed traction power supply and conventional station power applications are outside its stated intended application. DIN Media scope overview. Genorma's fuller scope also addresses pre-existing software and application configuration data. Genorma scope.
Before selecting the document or supplier, identify the intended use of the software. A package installed on a train, a signalling application and ordinary software serving a station office are different starting points. Then separate software-development evidence from hardware qualification and the overall system decision. A software document does not make those other work packages disappear.
EN 50716, EN 50128 and EN 50657: avoid a numbering mistake
Genorma identifies EN 50128 and EN 50657 and associated documents as predecessors. DIN records the replaced national publications. Check this history before reusing an older purchasing template headed EN 50128. Genorma predecessor history; DIN replacement history.
An older contractual reference still needs an explicit project decision. Do not silently replace the standard number on an existing evidence package, or invent a universal date when every legacy application must change. Identify the applicable edition, the proposed change and the person responsible for agreeing the development basis.
Build a software purchasing boundary
The following original comparison helps turn a broad software quotation into questions that can be answered before ordering.
| Item to identify | Practical purchasing question |
|---|---|
| Application code and firmware | Which versions and functions are included in the offer, and who maintains them? |
| Operating system and reused components | What third-party or pre-existing software does the application depend on? |
| Development and support tools | Which tools affect the delivered result, and what supporting evidence is available? |
| Application data and configuration | Who creates, checks and releases the data that makes the software specific to this installation? |
| System interfaces | Which hardware and system assumptions limit the supplier's development scope? |
This table is a buyer's inventory, not a claim that each item has the same requirements. Use the licensed document to determine the provisions applicable to the identified software and tools.
Example: updating an onboard software application
Imagine a fleet operator procuring an update to an onboard application. One bidder offers a code change and a brief test report; another includes updated configuration records, third-party software information and a plan for maintaining the delivered version. The prices cannot be compared meaningfully until the operator knows which responsibilities are included.
The operator could prepare a baseline listing the existing application version, hardware interfaces and configuration data. Each bidder could then describe the proposed changes, the evidence it will deliver and the information it needs from the operator. The buyer should also ask how future patches or replacement components will be handled. This example is a way to clarify procurement scope, not an assurance that either proposal meets EN 50716.
The scope distinguishes new development and changes to existing software. Ask the responsible reviewer to record how the proposed change will be treated; the size of a patch is not a sufficient purchasing specification. Published change scope.
How this fits the wider railway library
- EN 50126-1 is the guide to the overall RAMS process.
- EN 50126-2 addresses the system approach to safety.
- EN 50129 addresses the functional safety of electronic signalling systems.
The railway standards family overview remains the starting point for the combined library. When applying EN 50716, check the dated references actually contained in that document; the appearance of a newer related standard does not automatically rewrite them.
Questions before buying
Is EN 50716 only for signalling software?
No. Its published scope also includes onboard rolling-stock applications. Match the software's intended railway use to the scope before making a purchase.
Is prA1:2026 the latest published amendment?
The checked Genorma record labels it as a draft in development. Monitor it for change, but do not describe it as a final amendment to the published 2023 standard. Draft status record.
Does this cover the whole electronic product?
Its focus is software and its interaction with the system. Plan separately for the relevant hardware, system safety and other application requirements.
Sources and edition check
- Genorma: EN 50716:2023 scope and predecessor history.
- Genorma: draft EN 50716:2023/prA1:2026.
- DIN Media: DIN EN 50716:2024-09, replacement and correction records.
Catalogue records and purchase links checked on 7 October 2026. The inventory and scenario are original purchasing guidance; they do not replace the applicable development requirements or a project-specific assessment.