EN 50128 vs EN 50716: What Changed in Railway Software DevelopmentEN 50128 a EN 50716: co się zmieniło w tworzeniu oprogramowania kolejowego
EN 50128:2011 and EN 50657:2017 vs their successor EN 50716:2023: dates, scope, clause-by-clause changes, Basic Integrity, roles, tools, languages, and a transition checklist before the 2026 dow.EN 50128:2011 i EN 50657:2017 a ich następczyni EN 50716:2023: daty, zakres, zmiany rozdział po rozdziale, Basic Integrity, role, narzędzia, języki i lista kontrolna przed dow w 2026 r.
For more than a decade, railway software in Europe had two homes. Signalling and control-command software followed EN 50128. On-board rolling stock software followed EN 50657, which was itself modelled on EN 50128.
In November 2023 CENELEC replaced both with a single standard: EN 50716:2023, “Railway Applications - Requirements for software development”.
The coexistence period is almost over. The date of withdrawal (dow) for conflicting national standards is 30 October 2026, about two weeks after this post. If your plans, compliance matrices and safety cases still say “EN 50128:2011”, now is the time to look at what actually changed.
This post compares the standards topic by topic. I only state specifics I could check against:
the published front matter of EN 50716 (foreword, introduction, scope and table of contents), or
several independent secondary sources.
Where a detail comes from one commentator only, I say so. Where I could not verify it, I tell you to check the published text.
Why EN 50716 Exists
EN 50128:2011 was written for railway control and protection software. When rolling stock needed an equivalent, CENELEC published EN 50657:2017 for on-board software. It was largely derived from EN 50128, with corrections and refinements of its own.
According to Systerel, not all of those refinements made it back into EN 50128 through its 2020 amendments. Suppliers working in both domains ended up maintaining two nearly identical but subtly different process baselines.
EN 50716 removes this split. It was prepared by CLC/TC 9X (“Electrical and electronic applications for railways”) under a European Commission standardisation request.
Its stated aims include better alignment with the RAMS standards EN 50126-1:2017 and EN 50126-2:2017, including their definitions. The foreword says EN 50716 “is read in conjunction with” those two parts. If you need a refresher on the system-level side, see my post on EN 50126.
The foreword lists the significant technical changes compared with EN 50128:2011 and EN 50657:2017:
Better alignment with EN 50126-1:2017 and EN 50126-2:2017, including definitions.
Clause 5 requirements rewritten for readability, with the options for organisation kept broadly unchanged.
Annex A updated to align better with the lifecycle phases.
New clause C.1 (informative): guidance on lifecycle models.
New clause C.2 (informative): guidance on modelling for software development.
Additional guidance for software components with different software integrity levels.
Requirements on programming languages generalised.
That is the official list. Everything else in this post explains what those seven lines mean in practice.
Status and Dates
The table collects the key facts and where each one comes from.
Item
Value
Confidence
Title
Railway Applications - Requirements for software development
Published text
Approved by CENELEC
2023-10-30
Published text
Dated
November 2023
Published text
Technical committee
CLC/TC 9X
Published text
dop: latest date for national implementation
2024-10-30
Published text
dow: latest date for withdrawing conflicting national standards
2026-10-30
Published text
Superseded documents
EN 50128:2011, EN 50128:2011/AC:2014, EN 50128:2011/A1:2020, EN 50128:2011/A2:2020, EN 50657:2017, EN 50657:2017/A1:2023
Published text
EU harmonised standard
Yes, added by Commission Implementing Decision (EU) 2025/424 under Directive (EU) 2016/797
OJ publication
Two details matter here.
Superseded is not the same as withdrawn everywhere. EN 50716 superseded its predecessors at CENELEC level on publication. National standards bodies then had until the dow to withdraw their national versions of EN 50128 and EN 50657. Practice varied:
UK: the listing for BS EN 50716:2023 reportedly says the BS versions of EN 50657 and EN 50128 are withdrawn. That suggests BSI withdrew them on publication. I only saw this in a secondary shop listing.
Austria: a listing from OVE states that the predecessors may still be applied until the dow, 2026-10-30.
Harmonised status. Implementing Decision (EU) 2025/424 of 4 March 2025 amended Implementing Decision (EU) 2023/2584, the list of harmonised standards for rail interoperability, by adding EN 50716:2023.
The presumption of conformity is limited. Within its scope, it covers certain requirements of Regulation (EU) 2016/919, insofar as Article 14 of Implementing Regulation (EU) 2023/1695 applies.
Annex ZZ of EN 50716 still maps to:
the CCS TSI as Regulation (EU) 2016/919 (Table ZZ.1);
the LOC&PAS TSI, Regulation (EU) No 1302/2014 (Table ZZ.2).
The current CCS TSI, however, is Regulation (EU) 2023/1695.
Check the TSI and the current OJ list
I could not confirm whether the 2023/1695 CCS TSI text references EN 50716 or EN 50128 directly.
The list in 2023/2584 has been amended again since 2025/424, for example by a 2026 decision. I did not check whether that touches the EN 50716 entry.
Before you rely on a presumption of conformity in a certification file, read the current consolidated TSI and harmonised-standards list.
Scope Comparison
The table compares the scope of the three standards. Longer explanations follow below it.
Aspect
EN 50128:2011
EN 50657:2017
EN 50716:2023
Application domain
Railway control and protection (signalling, control-command)
On-board rolling stock
Both: “control, command for signalling applications” and “applications on-board of rolling stock”
Explicitly out of scope
Not covered here
Not covered here
Fixed traction power supply; conventional power supply (e.g. station offices and shops)
Lowest integrity level
”SIL 0”
Basic Integrity concept inherited from EN 50126
Basic Integrity, plus SIL 1-4
Software types
Application, operating systems, support tools, firmware
Similar
Application programming (high-level, low-level, special-purpose such as PLC ladder logic), operating systems, support tools, firmware (1.4)
Non-safety-related software
Excluded in 1.3
See standard
1.3 is “Intentionally left blank” (see below)
Pre-existing software and tools
Covered
Covered
1.5: allowed if 7.3.4.7 and 6.5.4.16 (pre-existing software) and 6.7 (tools) are met
FPGA / CPLD
Not covered here
Not covered here
1.10: EN 50129:2018 Annex F (safety-related), EN 50155:2017 (non-safety). Softcore software is in scope
Retrospective?
No
No
No (1.9). Full application only on major modification; “for minor changes, only 9.2 applies”
Normative references
Listed
Listed
None. EN 50126 and others are cited as bibliography
Cybersecurity
Not specified
Not specified
Not specified, but addressed in the Introduction (see below)
A few cells need more words than a table allows:
Power supply. For fixed traction installations, the foreword points to EN 50562.
Non-safety-related software. Commentators report that the old exclusion in 1.3 was deleted. At least one quality assurance process is now expected for non-safety functions.
Normative references. The standard says: “There are no normative references in this document.”
Cybersecurity. The Introduction states that cyber attacks can affect functional safety and points to ISO/IEC and CEN/CENELEC publications.
The scope change for rolling stock teams is the simplest one: EN 50657 no longer exists as a separate baseline. Everything on-board now references EN 50716, including what was added in EN 50657:2017/A1:2023.
Clause-by-Clause Comparison
The table of contents of EN 50716 keeps the familiar skeleton. Introduction NOTE 2 explains that some entries are intentionally left blank. The aim is to keep numbering, as far as reasonably practicable, unchanged compared with EN 50128 and EN 50657, to ease transition.
In practice, most of your compliance matrix can be re-mapped rather than rebuilt. The table goes through the clauses and annexes one by one.
Clause / Annex
EN 50128:2011
EN 50716:2023
What it means in practice
1 Scope
Signalling software
Signalling + on-board; 1.3, 1.6, 1.8 left blank
One scope for both domains; check the power-supply exclusion
2 Normative references
Normative list
None
You still need EN 50126-1/-2 for SIL allocation
3 Terms
Own definitions
Aligned with EN 50126-1/-2
Re-check definitions in your plans and glossary
4
Software integrity levels
”Software integrity levels conformance”
Basic Integrity replaces SIL 0
5 Management and organisation
Roles, independence, lifecycle
Rewritten for readability; options broadly unchanged; no Integrator
Update the organisation chart and role descriptions
Same structure; 6.7 “Support tools and languages” adds a tool-class table
Re-check tool classification and justification records
7 Software development (7.1-7.7)
Lifecycle phases through overall software testing
Same phases; 7.7 “Overall software testing / Final validation”
Mostly rewording; re-trace your documents
8
”Development of application data or algorithms"
"Development of application data”
Algorithms leave Clause 8 (see below)
9
Deployment and maintenance
9.1 Software deployment, 9.2 Software maintenance
9.2 is the entry point for minor changes
Annex A (normative)
Techniques by clause
By lifecycle phase; A.8, A.14, A.16 left blank
Re-check every technique selection
Annex B (normative)
Key roles
B.1-B.9; no Integrator
Integration testing moves to the Tester
Annex C
Documentation control summary
Guidance on lifecycle models (C.1) and modelling (C.2)
Model-based teams get explicit guidance
Annex D (informative)
Bibliography of techniques
Bibliography of techniques
Entries updated, e.g. for languages
Annex ZZ
Relationship to EU legislation
Directive (EU) 2016/797, CCS TSI and LOC&PAS TSI
See the TSI caveat above
Systerel estimates that roughly 30-40% of requirements were affected, mostly by rewording or added precision, with little change to normative substance. That is one author’s estimate, not a figure from the standard. It does match the impression the front matter gives.
The Significant Changes in Detail
Software integrity levels: Basic Integrity instead of “SIL 0”
EN 50716 defines five software integrity levels: Basic Integrity (lowest) and 1 to 4 (highest). Introduction NOTE 1 says the Basic Integrity concept was first introduced in the EN 50126 series.
Systerel notes that EN 50128/A2:2020 had already moved away from “SIL 0”. Teams on the amended EN 50128 have seen this before.
The pairing principle is unchanged:
Required techniques for level 1 are the same as for level 2.
Required techniques for level 3 are the same as for level 4.
As before, the software standard does not tell you which level a function needs. Allocation comes from the system-level risk process in EN 50126-1/-2.
What changes for Basic Integrity in practice is still being discussed. One consultancy (CSA) reports two changes:
The standard no longer requires an assessor for Basic Integrity software.
Some Annex A.1 entries for that level were relaxed, for example architecture and design specifications moving from Highly Recommended to Recommended.
I have not verified these against the full text. Treat them as pointers for your own gap analysis, not as conclusions.
Note
The foreword also mentions “additional guidance for software components of different software integrity levels”. If your architecture mixes integrity levels, for example a SIL 4 kernel next to Basic Integrity diagnostics, read that guidance closely. It is the area where the old standard said least.
Roles and independence
The Annex B role tables in EN 50716 are:
Table
Role
B.1
Requirements Manager
B.2
Designer
B.3
Implementer
B.4
Tester
B.5
Verifier
B.6
Validator
B.7
Assessor
B.8
Project Manager
B.9
Configuration Manager
There is no Integrator. Several independent commentators (Systerel, CSA, Prover) agree on the effect:
integration test specifications and reports go to the Tester;
technical integration sits with the Implementer.
The foreword says the organisational options in Clause 5 are broadly unchanged. The familiar independence patterns between Designer/Implementer, Verifier, Validator and Assessor are still there. Secondary sources also report some refinements:
Organisational independence is described in more detail, including pressure from peers, supervisors and commercial interests.
Switching between Verifier and Validator during a project is reported to be discouraged rather than prohibited. It must be justified and documented.
Appointing the assessor allows more flexibility.
Check these points in the published Clause 5 before you change your organisation chart.
Tip
If your Software Quality Assurance Plan names an Integrator, do not just delete the row. Move each integration duty explicitly to the Tester or Implementer, and keep the independence argument consistent with that move.
Support tools (6.7)
The tool classes are unchanged:
T1: generates no outputs that can directly or indirectly contribute to the executable code (including data) of the software.
T2: supports test or verification of the design or executable code. Errors in the tool can fail to reveal defects but cannot directly create errors in the executable software.
T3: generates outputs that can directly or indirectly contribute to the executable code (including data) of the safety-related system.
EN 50716 includes a table in 6.7 that relates each tool class to the subclauses that apply to it. I could not confirm whether this table is new in EN 50716 or was already added by the 2020 amendments to EN 50128.
Vendor sources describe these detail changes:
Justification scope. The requirement to justify the selection of T2 and T3 tools is stated for SIL 1 to SIL 4. Some justification may therefore not be needed for T2 tools at Basic Integrity.
T3 qualification is described in more detail.
Tool diversity remains an accepted argument.
All of this comes from tool vendors. Read 6.7 yourself before you change a tool qualification strategy.
Application data (Clause 8)
The title change tells most of the story:
EN 50128:2011: “Development of application data or algorithms: systems configured by application data or algorithms”
EN 50716:2023: “Development of application data: systems configured by application data”
According to Systerel, application algorithms no longer get the lighter Clause 8 treatment. They are software and follow the full Clause 7 lifecycle.
The old Table A.16 (diagrammatic languages for application algorithms) is now “Intentionally left blank”, which fits that reading.
The table of contents shows a clear sub-structure in 8.4:
Subclause
Topic
8.4.1
Application development process
8.4.2
Application requirements specification
8.4.3
Architecture and design
8.4.4
Application data production
8.4.5
Application integration and testing
8.4.6
Application validation and assessment
8.4.7
Application preparation procedures and tools
For interlocking and RBC projects with heavy station-specific configuration, this is one of the most relevant changes. Look again at where your generic product ends and your application begins.
Review the boundary between application data and application algorithms against the published Clause 8, and agree the classification with your assessor. Algorithm-like configuration may need to follow the Clause 7 lifecycle.
Pre-existing software
Scope 1.5 allows pre-existing software, as defined in 3.1.16, when the requirements in 7.3.4.7 and 6.5.4.16 are met. Tools are handled under 6.7.
This matters for reuse, but it does not mean every EN 50128-assessed component must be re-argued from scratch. Agree with your assessor how reused components are argued. There are two typical routes:
Carry forward the component through its existing generic product or application safety case and application conditions.
Treat it as pre-existing software under 1.5/7.3.4.7/6.5.4.16, where it is modified or was not developed for this application.
Programming languages
This is one of the most visible changes for developers. Two Annex A tables changed:
Table
EN 50128:2011
EN 50716:2023
A.15
”Textual Programming Languages”, rating named languages
”Suitable Programming Languages”
A.16
”Diagrammatic Languages for Application Algorithms”
Intentionally left blank
The foreword confirms only that “requirements on programming languages have been generalized”. Secondary sources (CSA, Prover) describe what that means:
Languages are selected by criteria such as strong typing, modularity and testability, not from a named list.
Diagrammatic and modelling languages can count as programming languages.
CSA argues this makes it possible to qualify newer languages such as Rust.
Check the exact criteria in the published text. The practical effect is that your language justification has to argue properties, not just point at a row in a table.
Lifecycle models and model-based development (Annex C)
In EN 50128, Annex C was a documentation control summary: for each document, who writes it and who reviews it first and second. In EN 50716, Annex C is informative “Guidance on software development”:
C.1 Lifecycle models, with figures for a waterfall model, a V-model and several iterative models. EN 50716 does not mandate a lifecycle. The Introduction says illustrative lifecycles and document sets are given in 5.3, 7.1 and C.1.
C.2 Modelling, with Tables C.1 to C.3. They show how techniques are typically adapted when modelling is used for architecture and design, for implementation and testing, and for coding standards.
Systerel sums up the approach: a model “is comparable to a document”.
For teams using SCADE, Simulink or similar tools, C.2 is guidance rather than requirements. Still, it is the first time the railway software standard addresses modelling explicitly. LDRA also reports that “source code” in 7.5 now explicitly includes inputs such as models.
In EN 50128:2011, AI appeared only as “Artificial Intelligence – Fault Correction” in the software architecture table (Table A.3), not recommended at SIL 3/4. Commentators report that EN 50716 addresses machine-learned software in general terms. I have not verified the exact wording or rating, so check the published Annex A before relying on it.
Annex A techniques tables
The foreword says Annex A was updated “to align better with the lifecycle phases”. The table titles show it:
Table
EN 50128:2011
EN 50716:2023
A.4
Software design and implementation (7.4)
Software design and implementation (7.3, 7.4 and 7.5)
A.5
Verification and testing (6.2 and 7.3)
Software component analysis and testing (6.2 and 7.4)
A.6
Integration (7.6)
Software integration analysis and testing (7.3 and 7.6)
A.7
Overall software testing (6.2 and 7.7)
Overall software analysis and testing (6.2 and 7.2) – check, see below
A.8
Software analysis techniques
Intentionally left blank
A.10
Software maintenance
Software maintenance (9.2)
A.11
Data preparation techniques
Data preparation techniques (8.4)
A.14
Functional/black box test
Intentionally left blank
A.15
Textual programming languages
Suitable programming languages
A.16
Diagrammatic languages for application algorithms
Intentionally left blank
A.22, A.23
Object-oriented architecture / detailed design
Not present (list ends at A.21)
One reference looks inconsistent. The EN 50716 title of A.7 cites 6.2 and 7.2, while overall software testing itself sits in 7.7. It may be deliberate, because the overall software test specification is written in the requirements phase. It may also be a transcription error in my sources. Check the published text before you map A.7 in your compliance matrix.
Systerel says the techniques were redistributed to follow the lifecycle. I could not verify which tables absorbed the entries from the blanked tables.
Do not assume a technique you relied on simply moved unchanged. Re-derive your technique selection from the new tables, phase by phase, and record any change in recommendation level.
Important
Some posts claim that specific techniques changed rating, for example formal methods for lower SILs or design specifications at Basic Integrity. I have left those out because I could not verify them. Check your compliance matrix against the published Annex A, not against blog summaries, including this one.
Deployment and maintenance (Clause 9)
Clause 9 is split into 9.1 Software deployment and 9.2 Software maintenance, with Table A.10 covering maintenance techniques.
Scope 1.9 says that “for minor changes, only 9.2 applies”. 9.2 is therefore the clause that will govern most changes to fielded EN 50128-era software.
LDRA reports some refinements:
Release note correctness is part of the validation report.
Hardware/software compatibility is stated in release notes.
Maintenance references ISO/IEC/IEEE 90003:2018.
Treat these as pointers to check.
Cybersecurity
EN 50716 still does not contain cybersecurity requirements. Its Introduction is more explicit than before, though:
Cyber attacks can affect functional safety.
Suitable standards should be applied; it points to ISO/IEC and CEN/CENELEC publications.
There may be a need to balance fast security updates against thorough development and validation of safety-related software.
That tension is real for any connected signalling or on-board system. Your change process (6.6 and 9.2) should state how security patches are classified and how fast they can be approved.
Transition Checklist
With the dow two weeks away, this is the minimum gap analysis I would run. It is generic guidance built from the sources above, not a normative list.
Agree the applicable standard per project with your assessor, customer and, where relevant, the safety authority or NSA. Record the decision in the safety plan or SQAP; the dow does not decide this for you.
Update references from EN 50128:2011 or EN 50657:2017 to EN 50716:2023 in the SQAP, verification and validation plans, software configuration management plan and templates.
Re-map the compliance matrix clause by clause. Numbering is largely preserved, but check Clause 5 (rewritten) and Clause 8 (narrowed) with special care.
Rename SIL 0 to Basic Integrity, and check what your process requires at that level, including assessment.
Remove the Integrator role. Reassign integration testing to the Tester and technical integration to the Implementer, then re-check independence.
Review the boundary between application data and algorithms against the published Clause 8. Agree the classification with your assessor.
Re-justify your programming language against the generalised criteria and the new Table A.15.
Re-derive the technique selection from the reorganised Annex A tables, phase by phase.
Re-check tool classification and qualification under 6.7, including T2/T3 justifications and vendor certificates that now reference EN 50716.
Agree how reused EN 50128-assessed components are argued: carried forward through their safety case, or treated as pre-existing software (see above).
For model-based teams, read Annex C.2 and align your modelling standard and review checklists with it.
For rolling stock teams, replace EN 50657 references everywhere, including supplier requirements and purchase specifications.
Update the safety case argument for new developments and major modifications, so that software evidence references EN 50716 and its alignment with EN 50126-1/-2.
Check the current TSI and harmonised standards list before you claim a presumption of conformity.
Common Misconceptions
“EN 50128 and EN 50657 were withdrawn in November 2023.”
They were superseded at CENELEC level when EN 50716 was published. The foreword sets the dow for conflicting national standards at 2026-10-30. Some national bodies withdrew earlier; others allowed use until the dow.
“After the dow, all EN 50128 certified products and safety cases become invalid.”
No. EN 50716 explicitly says it is not retrospective (1.9). The dow obliges national standards bodies to withdraw conflicting national standards; it does not reach into your existing safety case.
Whether a project started under EN 50128 can finish under it is a matter for the contract, the assessor and the safety authority. Write that decision down.
“Every upgrade must now follow EN 50716 in full.”
Full application is triggered by a major modification. For minor changes, only 9.2 applies. Applying the standard during upgrades and maintenance is described as “advisable”, not mandatory.
The standard does not draw the line between major and minor for you. The classification is not a free project choice either: the assessor is required to confirm that the determination of the nature and scope of the change is adequate (see 1.9 in the published text).
“EN 50716 is a new standard that needs new processes.”
The foreword says the organisational options are broadly unchanged, and the numbering was deliberately preserved to ease transition. A disciplined gap analysis is the right tool, not a process rewrite.
“EN 50716 covers all railway software, including traction power.”
Scope 1.1 excludes electric traction power supply (fixed installations) and conventional power supply. The foreword points to EN 50562 for fixed installations.
“Basic Integrity software is out of scope.”
Basic Integrity is one of the five levels EN 50716 addresses, with its own column in the Annex A tables. It may need less rigour (and, according to CSA, no assessor), but it is in scope.
EN 50716:2023, EN 50128:2011 (+A1/A2:2020), EN 50657:2017 (+A1:2023)
EN 50126-1:2017 / EN 50126-2:2017
Commission Implementing Decision (EU) 2025/424
This comparison is based on the published front matter of EN 50716:2023 (foreword, introduction, scope and table of contents), Commission Implementing Decision (EU) 2025/424, and publicly available analyses by Systerel, CSA, Prover, LDRA and QA Systems.
It is not a substitute for the standard itself. Where the text above says “reported” or “according to”, the detail comes from a secondary source. Check it against the full text before you rely on it.
Przez ponad dekadę europejskie oprogramowanie kolejowe podlegało dwóm normom. Oprogramowanie urządzeń sterowania ruchem kolejowym (srk) i systemów control-command – normie EN 50128. Oprogramowanie pokładowe taboru – normie EN 50657, która zresztą powstała na wzór EN 50128.
W listopadzie 2023 r. CENELEC zastąpił obie jedną normą: EN 50716:2023, „Railway Applications - Requirements for software development” (Zastosowania kolejowe – wymagania dotyczące tworzenia oprogramowania).
Okres przejściowy właśnie się kończy. Data wycofania (dow) sprzecznych norm krajowych to 30 października 2026 r., około dwóch tygodni po publikacji tego wpisu. Jeśli plany, macierze zgodności i dowody bezpieczeństwa (safety case) w Twoim projekcie wciąż powołują się na „EN 50128:2011”, to ostatni moment, żeby sprawdzić, co naprawdę się zmieniło.
Porównuję tu obie normy temat po temacie. Podaję tylko te szczegóły, które mogłem sprawdzić:
w opublikowanej części wstępnej EN 50716 (przedmowa, wprowadzenie, zakres i spis treści) albo
w kilku niezależnych źródłach wtórnych.
Jeśli informacja pochodzi tylko od jednego komentatora, zaznaczam to. Jeśli nie mogłem jej zweryfikować, odsyłam do opublikowanego tekstu normy.
Skąd się wzięła EN 50716
EN 50128:2011 powstała z myślą o oprogramowaniu systemów sterowania i zabezpieczenia ruchu. Gdy tabor potrzebował odpowiednika, CENELEC wydał EN 50657:2017 dla oprogramowania pokładowego. W dużej mierze była to kopia EN 50128, z własnymi poprawkami i doprecyzowaniami.
Według Systerel nie wszystkie te doprecyzowania wróciły do EN 50128 wraz ze zmianami z 2020 r. Dostawcy pracujący dla obu branż musieli więc utrzymywać dwie niemal identyczne, ale w szczegółach różne bazy procesowe.
EN 50716 kończy z tym podziałem. Opracował ją komitet CLC/TC 9X („Electrical and electronic applications for railways”) na podstawie wniosku normalizacyjnego Komisji Europejskiej.
Jednym z jej celów jest lepsze powiązanie z normami RAMS EN 50126-1:2017 i EN 50126-2:2017, także w zakresie definicji. Przedmowa wprost mówi, że EN 50716 „is read in conjunction with” (należy czytać łącznie z) tymi dwiema częściami. Stronę systemową omawiam we wpisie o EN 50126.
Przedmowa wymienia istotne zmiany techniczne względem EN 50128:2011 i EN 50657:2017:
Lepsze powiązanie z EN 50126-1:2017 i EN 50126-2:2017, także w zakresie definicji.
Przeredagowanie wymagań Rozdziału 5 dla czytelności, przy w zasadzie niezmienionych wariantach organizacyjnych.
Aktualizacja Załącznika A, tak by lepiej odpowiadał fazom cyklu życia.
Nowy punkt C.1 (informacyjny): wytyczne dotyczące modeli cyklu życia.
Nowy punkt C.2 (informacyjny): wytyczne dotyczące modelowania w tworzeniu oprogramowania.
Dodatkowe wytyczne dla komponentów oprogramowania o różnych poziomach nienaruszalności bezpieczeństwa (SIL).
Uogólnienie wymagań dotyczących języków programowania.
To cała oficjalna lista. Reszta wpisu wyjaśnia, co tych siedem punktów oznacza w praktyce.
Status i daty
Tabela zbiera najważniejsze fakty i ich źródła.
Pozycja
Wartość
Pewność
Tytuł
Railway Applications - Requirements for software development
Opublikowany tekst
Zatwierdzenie przez CENELEC
2023-10-30
Opublikowany tekst
Data wydania
listopad 2023
Opublikowany tekst
Komitet techniczny
CLC/TC 9X
Opublikowany tekst
dop: najpóźniejsza data wdrożenia na poziomie krajowym
2024-10-30
Opublikowany tekst
dow: najpóźniejsza data wycofania sprzecznych norm krajowych
2026-10-30
Opublikowany tekst
Dokumenty zastąpione
EN 50128:2011, EN 50128:2011/AC:2014, EN 50128:2011/A1:2020, EN 50128:2011/A2:2020, EN 50657:2017, EN 50657:2017/A1:2023
Opublikowany tekst
Norma zharmonizowana UE
Tak, dodana decyzją wykonawczą Komisji (UE) 2025/424 na podstawie dyrektywy (UE) 2016/797
Dz.U. UE
Dwie sprawy wymagają komentarza.
Zastąpienie to nie to samo co wycofanie. EN 50716 zastąpiła poprzedniczki na poziomie CENELEC w chwili publikacji. Krajowe jednostki normalizacyjne miały potem czas do dow na wycofanie krajowych wersji EN 50128 i EN 50657. Różnie z tego korzystały:
Wielka Brytania: opis BS EN 50716:2023 podobno podaje, że wersje BS norm EN 50657 i EN 50128 wycofano. Wskazywałoby to, że BSI zrobił to od razu. Widziałem tę informację tylko w opisie w sklepie z normami.
Austria: według opisu austriackiej jednostki OVE poprzedniczki można stosować do dow, czyli do 2026-10-30.
Status normy zharmonizowanej. Decyzja wykonawcza (UE) 2025/424 z 4 marca 2025 r. zmieniła decyzję wykonawczą (UE) 2023/2584, czyli wykaz norm zharmonizowanych dla interoperacyjności kolei, i dopisała do niego EN 50716:2023.
Domniemanie zgodności jest ograniczone. W swoim zakresie obejmuje określone wymagania rozporządzenia (UE) 2016/919, o ile ma zastosowanie art. 14 rozporządzenia wykonawczego (UE) 2023/1695.
Załącznik ZZ normy EN 50716 nadal odwołuje się do:
TSI CCS jako rozporządzenia (UE) 2016/919 (tablica ZZ.1);
TSI LOC&PAS, czyli rozporządzenia (UE) nr 1302/2014 (tablica ZZ.2).
Tymczasem obowiązująca TSI CCS to rozporządzenie (UE) 2023/1695.
Sprawdź TSI i aktualny wykaz w Dz.U. UE
Nie udało mi się potwierdzić, czy TSI CCS 2023/1695 powołuje się bezpośrednio na EN 50716, czy na EN 50128.
Wykaz z decyzji 2023/2584 zmieniano jeszcze po 2025/424, np. decyzją z 2026 r. Nie sprawdzałem, czy dotyczy to pozycji EN 50716.
Zanim powołasz się na domniemanie zgodności w dokumentacji certyfikacyjnej, przeczytaj aktualną skonsolidowaną TSI i wykaz norm zharmonizowanych.
Porównanie zakresu
Tabela zestawia zakres trzech norm. Dłuższe wyjaśnienia są pod nią.
Aspekt
EN 50128:2011
EN 50657:2017
EN 50716:2023
Dziedzina zastosowania
Sterowanie i zabezpieczenie ruchu (srk, control-command)
Tabor (oprogramowanie pokładowe)
Obie: „control, command for signalling applications” i „applications on-board of rolling stock”
Wprost wyłączone z zakresu
Nie omawiam
Nie omawiam
Stacjonarne zasilanie trakcyjne; zasilanie konwencjonalne (np. biura i sklepy na stacjach)
Najniższy poziom nienaruszalności
„SIL 0”
Koncepcja Basic Integrity przejęta z EN 50126
Basic Integrity (podstawowa nienaruszalność) oraz SIL 1–4
Rodzaje oprogramowania
Aplikacyjne, systemy operacyjne, narzędzia wspomagające, firmware
Podobnie
Aplikacyjne (wysokiego i niskiego poziomu, specjalizowane, np. logika drabinkowa PLC), systemy operacyjne, narzędzia wspomagające, firmware (1.4)
Oprogramowanie niezwiązane z bezpieczeństwem
Wyłączone w 1.3
Zob. norma
1.3 ma status „Intentionally left blank” (zob. niżej)
Oprogramowanie istniejące wcześniej i narzędzia
Objęte
Objęte
1.5: dopuszczalne po spełnieniu 7.3.4.7 i 6.5.4.16 (oprogramowanie) oraz 6.7 (narzędzia)
FPGA / CPLD
Nie omawiam
Nie omawiam
1.10: EN 50129:2018 Załącznik F (związane z bezpieczeństwem), EN 50155:2017 (pozostałe). Oprogramowanie na procesorach softcore jest w zakresie
Działanie wsteczne
Nie
Nie
Nie (1.9). W pełni tylko przy istotnej modyfikacji; „for minor changes, only 9.2 applies”
Powołania normatywne
Są
Są
Brak. EN 50126 i inne normy są w bibliografii
Cyberbezpieczeństwo
Brak wymagań
Brak wymagań
Brak wymagań, ale temat pojawia się we Wprowadzeniu (zob. niżej)
Kilka komórek wymaga więcej słów, niż mieści tabela:
Zasilanie. W sprawie stacjonarnych instalacji trakcyjnych przedmowa odsyła do EN 50562.
Oprogramowanie niezwiązane z bezpieczeństwem. Komentatorzy podają, że dawne wyłączenie z 1.3 usunięto. Dla funkcji niezwiązanych z bezpieczeństwem oczekuje się teraz co najmniej jednego procesu zapewnienia jakości.
Powołania normatywne. Norma stwierdza: „There are no normative references in this document.”
Cyberbezpieczeństwo. Wprowadzenie mówi, że cyberataki mogą wpływać na bezpieczeństwo funkcjonalne, i odsyła do publikacji ISO/IEC oraz CEN/CENELEC.
Dla zespołów taborowych zmiana zakresu jest najprostsza: EN 50657 przestaje istnieć jako osobna podstawa procesu. Całe oprogramowanie pokładowe odwołuje się teraz do EN 50716, łącznie z tym, co wniosła zmiana EN 50657:2017/A1:2023.
Porównanie rozdział po rozdziale
Spis treści EN 50716 zachowuje znany układ. Uwaga 2 we Wprowadzeniu wyjaśnia, że część pozycji celowo pozostawiono pustych. Chodzi o to, by numeracja w miarę możliwości odpowiadała EN 50128 i EN 50657 i ułatwiała przejście.
W praktyce większość macierzy zgodności wystarczy przemapować, zamiast budować od nowa. Tabela przechodzi kolejno przez rozdziały i załączniki.
Rozdział / Załącznik
EN 50128:2011
EN 50716:2023
Co to oznacza w praktyce
1 Zakres
Oprogramowanie srk
srk + pokładowe; 1.3, 1.6, 1.8 puste
Jeden zakres dla obu branż; sprawdź wyłączenie zasilania
2 Powołania normatywne
Lista normatywna
Brak
Do przypisania SIL nadal potrzebna jest EN 50126-1/-2
3 Terminy
Własne definicje
Zgodne z EN 50126-1/-2
Sprawdź definicje w planach i słowniku projektu
4
Software integrity levels
„Software integrity levels conformance”
Basic Integrity zastępuje SIL 0
5 Zarządzanie i organizacja
Role, niezależność, cykl życia
Przeredagowany; warianty w zasadzie bez zmian; bez Integratora
Ta sama struktura; 6.7 „Support tools and languages” z nową tablicą klas narzędzi
Sprawdź klasyfikację narzędzi i uzasadnienia
7 Tworzenie oprogramowania (7.1–7.7)
Fazy cyklu życia aż do całościowego testowania
Te same fazy; 7.7 „Overall software testing / Final validation”
Głównie zmiany redakcyjne; odśwież powiązania dokumentów
8
„Development of application data or algorithms”
„Development of application data”
Algorytmy wychodzą z Rozdziału 8 (zob. niżej)
9
Wdrożenie i utrzymanie
9.1 Software deployment, 9.2 Software maintenance
9.2 to punkt wejścia dla drobnych zmian
Załącznik A (normatywny)
Techniki według rozdziałów
Według faz cyklu życia; A.8, A.14, A.16 puste
Zweryfikuj każdy wybór techniki
Załącznik B (normatywny)
Kluczowe role
B.1–B.9; bez Integratora
Testy integracyjne przechodzą do Testera
Załącznik C
Zestawienie nadzoru nad dokumentacją
Wytyczne dla modeli cyklu życia (C.1) i modelowania (C.2)
Zespoły pracujące na modelach dostają konkretne wytyczne
Załącznik D (informacyjny)
Bibliografia technik
Bibliografia technik
Zaktualizowane pozycje, np. o językach
Załącznik ZZ
Związek z prawodawstwem UE
Dyrektywa (UE) 2016/797, TSI CCS i TSI LOC&PAS
Zob. zastrzeżenie dotyczące TSI wyżej
Systerel szacuje, że zmiany objęły mniej więcej 30–40% wymagań, głównie przez przeredagowanie lub doprecyzowanie, a merytorycznie zmieniło się niewiele. To szacunek jednego autora, a nie liczba z normy. Zgadza się jednak z wrażeniem, jakie daje część wstępna.
Najważniejsze zmiany szczegółowo
Poziomy nienaruszalności: Basic Integrity zamiast „SIL 0”
EN 50716 definiuje pięć poziomów nienaruszalności bezpieczeństwa oprogramowania: Basic Integrity (najniższy) oraz poziomy od 1 do 4 (najwyższy). Uwaga 1 we Wprowadzeniu przypomina, że pojęcie Basic Integrity pojawiło się po raz pierwszy w serii EN 50126.
Systerel zauważa, że już zmiana EN 50128/A2:2020 odeszła od „SIL 0”. Zespoły pracujące według znowelizowanej EN 50128 znają więc to podejście.
Zasada łączenia poziomów w pary się nie zmieniła:
Wymagane techniki dla poziomu 1 są takie same jak dla poziomu 2.
Wymagane techniki dla poziomu 3 są takie same jak dla poziomu 4.
Tak jak wcześniej, norma dla oprogramowania nie rozstrzyga, jakiego poziomu wymaga dana funkcja. Wynika to z systemowej analizy ryzyka według EN 50126-1/-2.
Co konkretnie zmienia się dla Basic Integrity, wciąż jest przedmiotem dyskusji. Firma doradcza CSA wskazuje dwie zmiany:
Norma nie wymaga już asesora dla oprogramowania na poziomie Basic Integrity.
Część pozycji tablicy A.1 dla tego poziomu złagodzono, np. specyfikacje architektury i projektu spadły z Highly Recommended do Recommended.
Nie sprawdziłem tego w pełnym tekście. Traktuj to jako punkty do własnej analizy luk, a nie gotowe wnioski.
Note
Przedmowa wspomina też o „additional guidance for software components of different software integrity levels” (dodatkowych wytycznych dla komponentów o różnych poziomach nienaruszalności). Jeśli architektura łączy różne poziomy, np. jądro SIL 4 z diagnostyką na poziomie Basic Integrity, warto te wytyczne przeczytać uważnie. W tym obszarze stara norma mówiła najmniej.
Role i niezależność
Załącznik B normy EN 50716 zawiera tablice dla następujących ról:
Integratora już nie ma. Kilku niezależnych komentatorów (Systerel, CSA, Prover) zgodnie opisuje skutki:
specyfikacje i raporty testów integracyjnych przejmuje Tester;
integracja techniczna należy do Implementera.
Według przedmowy warianty organizacyjne w Rozdziale 5 w zasadzie się nie zmieniły. Znane schematy niezależności między projektantem/Implementerem, weryfikatorem, walidatorem i asesorem zostają. Źródła wtórne wskazują jednak kilka doprecyzowań:
Niezależność organizacyjna jest opisana dokładniej, także w odniesieniu do presji ze strony współpracowników, przełożonych i interesów handlowych.
Przejście między rolą weryfikatora i walidatora w trakcie projektu jest podobno odradzane, ale nie zakazane. Trzeba je uzasadnić i udokumentować.
Powołanie asesora daje więcej swobody co do tego, kto może to zrobić.
Zanim zmienisz schemat organizacyjny, sprawdź te punkty w opublikowanym Rozdziale 5.
Tip
Jeśli plan zapewnienia jakości oprogramowania (SQAP) wymienia Integratora, nie wystarczy usunąć tego wiersza. Przypisz każde zadanie integracyjne jawnie Testerowi albo Implementerowi i sprawdź, czy argumentacja niezależności nadal się spina.
Narzędzia wspomagające (6.7)
Klasy narzędzi się nie zmieniły:
T1: nie generuje wyników, które mogą bezpośrednio lub pośrednio trafić do kodu wykonywalnego (łącznie z danymi) oprogramowania.
T2: wspiera testowanie lub weryfikację projektu albo kodu wykonywalnego. Błąd narzędzia może sprawić, że defekt nie zostanie wykryty, ale nie może bezpośrednio wprowadzić błędu do oprogramowania wykonywalnego.
T3: generuje wyniki, które mogą bezpośrednio lub pośrednio trafić do kodu wykonywalnego (łącznie z danymi) systemu związanego z bezpieczeństwem.
W 6.7 normy EN 50716 jest tablica, która przypisuje każdej klasie narzędzi (T1/T2/T3) właściwe podpunkty. Nie udało mi się ustalić, czy ta tablica jest nowością EN 50716, czy pojawiła się już w zmianach EN 50128 z 2020 r.
Dostawcy narzędzi opisują następujące zmiany szczegółowe:
Zakres uzasadnienia. Wymóg uzasadnienia wyboru narzędzi T2 i T3 dotyczy SIL 1–4. Dla narzędzi T2 na poziomie Basic Integrity część uzasadnień może więc być zbędna.
Kwalifikacja narzędzi T3 jest opisana dokładniej.
Różnorodność narzędzi nadal jest akceptowanym argumentem.
Wszystkie te informacje pochodzą od producentów narzędzi. Zanim zmienisz strategię kwalifikacji narzędzi, przeczytaj 6.7 samodzielnie.
Dane aplikacyjne (Rozdział 8)
Najwięcej mówi sama zmiana tytułu:
EN 50128:2011: „Development of application data or algorithms: systems configured by application data or algorithms”
EN 50716:2023: „Development of application data: systems configured by application data”
Według Systerel algorytmy aplikacyjne nie mogą już korzystać z lżejszej ścieżki Rozdziału 8. Są oprogramowaniem i przechodzą pełny cykl życia z Rozdziału 7.
Pasuje do tego fakt, że dawna tablica A.16 (języki graficzne dla algorytmów aplikacyjnych) ma teraz status „Intentionally left blank”.
Spis treści pokazuje wyraźny podział punktu 8.4:
Podpunkt
Temat
8.4.1
Proces tworzenia aplikacji
8.4.2
Specyfikacja wymagań aplikacji
8.4.3
Architektura i projekt
8.4.4
Przygotowanie danych aplikacyjnych
8.4.5
Integracja i testowanie aplikacji
8.4.6
Walidacja i ocena aplikacji
8.4.7
Procedury i narzędzia przygotowania aplikacji
W projektach urządzeń zależnościowych i RBC, z dużą ilością konfiguracji specyficznej dla stacji, to jedna z najważniejszych zmian. Warto jeszcze raz ustalić, gdzie kończy się produkt generyczny, a zaczyna aplikacja.
Granicę między danymi a algorytmami aplikacyjnymi trzeba sprawdzić z opublikowanym Rozdziałem 8 i uzgodnić klasyfikację z asesorem. Konfiguracja o charakterze algorytmu może wymagać pełnego cyklu życia z Rozdziału 7.
Oprogramowanie istniejące wcześniej
Punkt 1.5 dopuszcza oprogramowanie istniejące wcześniej (pre-existing software, definicja w 3.1.16), jeśli spełnia ono wymagania 7.3.4.7 i 6.5.4.16. Narzędzia obejmuje 6.7.
Ma to znaczenie przy ponownym użyciu, ale nie znaczy, że każdy komponent oceniony według EN 50128 trzeba uzasadniać od zera. Sposób argumentacji warto uzgodnić z asesorem. Typowe są dwie drogi:
Przeniesienie komponentu przez istniejący dowód bezpieczeństwa produktu generycznego lub aplikacji, wraz z warunkami stosowania.
Potraktowanie go jako oprogramowania istniejącego wcześniej według 1.5/7.3.4.7/6.5.4.16, jeśli jest modyfikowany albo nie powstał dla tej aplikacji.
Języki programowania
Tę zmianę programiści zauważą najszybciej. Zmieniły się dwie tablice Załącznika A:
Tablica
EN 50128:2011
EN 50716:2023
A.15
„Textual Programming Languages”, z ocenami konkretnych języków
„Suitable Programming Languages”
A.16
„Diagrammatic Languages for Application Algorithms”
Intentionally left blank
Przedmowa potwierdza jedynie, że „requirements on programming languages have been generalized” (wymagania dotyczące języków programowania uogólniono). Co to oznacza, opisują źródła wtórne (CSA, Prover):
Język wybiera się według kryteriów, takich jak silne typowanie, modułowość i testowalność, a nie z listy nazw.
Języki graficzne i języki modelowania mogą być traktowane jako języki programowania.
Według CSA otwiera to drogę do kwalifikacji nowszych języków, np. Rusta.
Dokładne kryteria trzeba sprawdzić w opublikowanym tekście. W praktyce uzasadnienie wyboru języka musi wykazać jego właściwości, a nie tylko wskazać wiersz w tablicy.
Modele cyklu życia i modelowanie (Załącznik C)
W EN 50128 Załącznik C był zestawieniem nadzoru nad dokumentacją: dla każdego dokumentu podawał autora oraz osoby wykonujące pierwszy i drugi przegląd. W EN 50716 Załącznik C nosi tytuł „Guidance on software development” (wytyczne dotyczące tworzenia oprogramowania) i jest informacyjny:
C.1 Modele cyklu życia – rysunki modelu kaskadowego, modelu V i kilku modeli iteracyjnych. EN 50716 nie narzuca cyklu życia. Według Wprowadzenia przykładowe cykle życia i zestawy dokumentów są w 5.3, 7.1 i C.1.
C.2 Modelowanie – tablice C.1–C.3. Pokazują, jak zwykle dostosowuje się techniki, gdy modelowanie służy do architektury i projektu, implementacji i testowania oraz standardów kodowania.
Systerel streszcza to podejście krótko: model „is comparable to a document” (jest porównywalny z dokumentem).
Dla zespołów pracujących w SCADE, Simulinku lub podobnych narzędziach C.2 to wytyczne, a nie wymagania. Mimo to kolejowa norma dla oprogramowania po raz pierwszy wprost zajmuje się modelowaniem. LDRA podaje też, że pojęcie „source code” w 7.5 obejmuje teraz wprost również dane wejściowe, takie jak modele.
W EN 50128:2011 sztuczna inteligencja pojawiała się tylko jako „Artificial Intelligence – Fault Correction” w tablicy architektury oprogramowania (A.3), niezalecana dla SIL 3/4. Komentatorzy podają, że EN 50716 odnosi się w ogólnych słowach do oprogramowania tworzonego metodami uczenia maszynowego. Nie sprawdziłem dokładnego brzmienia ani oceny, więc zanim się na tym oprzesz, zajrzyj do opublikowanego Załącznika A.
Tablice technik w Załączniku A
Według przedmowy Załącznik A zaktualizowano, „to align better with the lifecycle phases” (by lepiej odpowiadał fazom cyklu życia). Widać to w tytułach tablic:
Tablica
EN 50128:2011
EN 50716:2023
A.4
Software design and implementation (7.4)
Software design and implementation (7.3, 7.4 and 7.5)
A.5
Verification and testing (6.2 and 7.3)
Software component analysis and testing (6.2 and 7.4)
A.6
Integration (7.6)
Software integration analysis and testing (7.3 and 7.6)
A.7
Overall software testing (6.2 and 7.7)
Overall software analysis and testing (6.2 and 7.2) – do sprawdzenia, zob. niżej
A.8
Software analysis techniques
Intentionally left blank
A.10
Software maintenance
Software maintenance (9.2)
A.11
Data preparation techniques
Data preparation techniques (8.4)
A.14
Functional/black box test
Intentionally left blank
A.15
Textual programming languages
Suitable programming languages
A.16
Diagrammatic languages for application algorithms
Intentionally left blank
A.22, A.23
Object-oriented architecture / detailed design
Brak (lista kończy się na A.21)
Jedno odwołanie wygląda niespójnie. Tytuł tablicy A.7 w EN 50716 wskazuje 6.2 i 7.2, choć samo całościowe testowanie oprogramowania jest w 7.7. Może to być celowe, bo specyfikację testów całościowych pisze się w fazie wymagań. Może to też być błąd przepisania w moich źródłach. Zanim przypiszesz A.7 w macierzy zgodności, sprawdź opublikowany tekst.
Systerel podaje, że techniki rozdzielono według faz cyklu życia. Nie udało mi się ustalić, które tablice przejęły pozycje z tablic pozostawionych pustych.
Nie zakładaj, że technika, na której polegałeś, po prostu przeszła do innej tablicy bez zmian. Wybór technik trzeba wyprowadzić od nowa, faza po fazie, i odnotować każdą zmianę poziomu zalecenia.
Important
W niektórych wpisach można przeczytać, że konkretne techniki zmieniły ocenę, np. metody formalne dla niższych SIL albo specyfikacje projektu na poziomie Basic Integrity. Pominąłem te informacje, bo nie mogłem ich zweryfikować. Macierz zgodności sprawdza się z opublikowanym Załącznikiem A, a nie ze streszczeniami na blogach – także z tym.
Wdrożenie i utrzymanie (Rozdział 9)
Rozdział 9 dzieli się na 9.1 Software deployment i 9.2 Software maintenance. Techniki utrzymania zawiera tablica A.10.
Punkt 1.9 mówi, że „for minor changes, only 9.2 applies”. To właśnie 9.2 będzie więc rządzić większością zmian w eksploatowanym oprogramowaniu z czasów EN 50128.
LDRA opisuje kilka doprecyzowań:
Poprawność informacji o wydaniu (release notes) jest częścią raportu z walidacji.
Zgodność sprzętu i oprogramowania podaje się w informacjach o wydaniu.
Utrzymanie odwołuje się do ISO/IEC/IEEE 90003:2018.
To punkty do sprawdzenia, nie pewniki.
Cyberbezpieczeństwo
EN 50716 nadal nie stawia wymagań dotyczących cyberbezpieczeństwa. Wprowadzenie mówi jednak o nim wyraźniej niż wcześniej:
Cyberataki mogą wpływać na bezpieczeństwo funkcjonalne.
Należy stosować właściwe normy; Wprowadzenie odsyła do publikacji ISO/IEC i CEN/CENELEC.
Może być potrzebny kompromis między szybkim wdrażaniem poprawek bezpieczeństwa a starannym tworzeniem i walidacją oprogramowania związanego z bezpieczeństwem.
Ten konflikt dotyczy każdego połączonego z siecią systemu srk lub pokładowego. Proces zarządzania zmianą (6.6 i 9.2) powinien określać, jak klasyfikuje się poprawki bezpieczeństwa IT i jak szybko można je zatwierdzić.
Lista kontrolna przejścia
Do dow zostały dwa tygodnie, więc poniżej minimalna analiza luk, jaką sam bym przeprowadził. To ogólne wskazówki oparte na powyższych źródłach, a nie lista normatywna.
Uzgodnij normę obowiązującą w każdym projekcie z asesorem, klientem i w razie potrzeby z krajowym organem ds. bezpieczeństwa (NSA). Zapisz decyzję w planie bezpieczeństwa lub SQAP – sama data dow tego nie rozstrzyga.
Zaktualizuj powołania z EN 50128:2011 lub EN 50657:2017 na EN 50716:2023 w SQAP, planach weryfikacji i walidacji, planie zarządzania konfiguracją oprogramowania i szablonach.
Przemapuj macierz zgodności rozdział po rozdziale. Numeracja jest w dużej mierze zachowana, ale szczególnie uważnie sprawdź Rozdział 5 (przeredagowany) i Rozdział 8 (zawężony).
Zamień SIL 0 na Basic Integrity i sprawdź, czego proces wymaga na tym poziomie, łącznie z oceną niezależną.
Usuń rolę Integratora. Testy integracyjne przypisz Testerowi, integrację techniczną Implementerowi, a potem jeszcze raz sprawdź niezależność.
Sprawdź granicę między danymi a algorytmami aplikacyjnymi z opublikowanym Rozdziałem 8. Uzgodnij klasyfikację z asesorem.
Uzasadnij ponownie wybór języka programowania według uogólnionych kryteriów i nowej tablicy A.15.
Wyprowadź od nowa wybór technik z przebudowanych tablic Załącznika A, faza po fazie.
Sprawdź klasyfikację i kwalifikację narzędzi według 6.7, łącznie z uzasadnieniami dla T2/T3 i certyfikatami dostawców powołującymi się na EN 50716.
Uzgodnij sposób argumentacji dla komponentów ocenionych według EN 50128: przeniesienie przez dowód bezpieczeństwa albo potraktowanie jako oprogramowania istniejącego wcześniej (zob. wyżej).
Zespoły pracujące na modelach: przeczytajcie Załącznik C.2 i dostosujcie do niego standard modelowania oraz listy kontrolne przeglądów.
Zespoły taborowe: zastąpcie powołania na EN 50657 wszędzie, także w wymaganiach dla dostawców i specyfikacjach zakupowych.
Zaktualizuj argumentację dowodu bezpieczeństwa dla nowych opracowań i istotnych modyfikacji, tak by dowody dotyczące oprogramowania powoływały się na EN 50716 i jej powiązanie z EN 50126-1/-2.
Sprawdź aktualną TSI i wykaz norm zharmonizowanych, zanim powołasz się na domniemanie zgodności.
Częste nieporozumienia
„EN 50128 i EN 50657 wycofano w listopadzie 2023 r.”
Na poziomie CENELEC zostały zastąpione w chwili publikacji EN 50716. Przedmowa wyznacza dow dla sprzecznych norm krajowych na 2026-10-30. Część krajowych jednostek normalizacyjnych wycofała je wcześniej, inne pozwalały je stosować do dow.
„Po dow wszystkie produkty certyfikowane według EN 50128 i ich dowody bezpieczeństwa tracą ważność.”
Nie. EN 50716 wprost stwierdza, że nie działa wstecz (1.9). Dow zobowiązuje krajowe jednostki normalizacyjne do wycofania sprzecznych norm, ale nie dotyka istniejących dowodów bezpieczeństwa.
To, czy projekt rozpoczęty według EN 50128 można według niej zakończyć, zależy od umowy, asesora i organu ds. bezpieczeństwa. Tę decyzję trzeba zapisać.
„Każda modernizacja musi teraz w pełni spełniać EN 50716.”
Pełne stosowanie normy wymusza dopiero istotna modyfikacja. Przy drobnych zmianach stosuje się tylko 9.2. Stosowanie normy przy modernizacjach i utrzymaniu jest opisane jako „advisable” (wskazane), a nie obowiązkowe.
Norma nie wyznacza granicy między zmianą istotną a drobną. Nie jest to jednak dowolny wybór projektu: asesor musi potwierdzić, że określenie charakteru i zakresu zmiany jest adekwatne (zob. 1.9 w opublikowanym tekście).
„EN 50716 to nowa norma, która wymaga nowych procesów.”
Przedmowa mówi, że warianty organizacyjne w zasadzie się nie zmieniły, a numerację celowo zachowano, by ułatwić przejście. Wystarczy rzetelna analiza luk, a nie przepisywanie procesu od nowa.
„EN 50716 obejmuje całe oprogramowanie kolejowe, łącznie z zasilaniem trakcyjnym.”
Punkt 1.1 wyłącza stacjonarne zasilanie trakcyjne i zasilanie konwencjonalne. W sprawie instalacji stacjonarnych przedmowa odsyła do EN 50562.
„Oprogramowanie na poziomie Basic Integrity jest poza zakresem normy.”
Basic Integrity to jeden z pięciu poziomów objętych EN 50716, z własną kolumną w tablicach Załącznika A. Może wymagać mniej rygoru (a według CSA – bez asesora), ale podlega normie.
EN 50716:2023, EN 50128:2011 (+A1/A2:2020), EN 50657:2017 (+A1:2023)
EN 50126-1:2017 / EN 50126-2:2017
Decyzja wykonawcza Komisji (UE) 2025/424
Porównanie opiera się na opublikowanej części wstępnej EN 50716:2023 (przedmowa, wprowadzenie, zakres i spis treści), decyzji wykonawczej Komisji (UE) 2025/424 oraz publicznie dostępnych analizach firm Systerel, CSA, Prover, LDRA i QA Systems.
Nie zastępuje samej normy. Tam, gdzie piszę „podobno”, „podaje” lub „według”, informacja pochodzi ze źródła wtórnego. Zanim się na niej oprzesz, sprawdź ją w pełnym tekście.
A practical guide to EN 50128:2011: SIL 0-4, roles and independence, the software lifecycle and its documents, Annex A techniques (M/HR/R/NR), tool classes T1-T3, and how it relates to EN 50716.Praktyczny przewodnik po EN 50128:2011: SIL 0–4, role i niezależność, cykl życia oprogramowania i jego dokumenty, techniki z Załącznika A (M/HR/R/NR), klasy narzędzi T1–T3 oraz związek z EN 50716.
A practical guide to EN 50126-1/-2:2017: the 12-phase RAMS lifecycle, hazard log, CSM-RA-aligned risk acceptance, roles, independent safety assessment and THR/TFFR/SIL apportionment.Praktyczny przewodnik po EN 50126-1/-2:2017: 12-fazowy cykl życia systemu, rejestr zagrożeń, zasady akceptacji ryzyka zgodne z CSM-RA, role, niezależna ocena bezpieczeństwa oraz podział THR/TFFR/SIL.
How to test what happens when things break: FMEA-driven test cases, fault injection at software and hardware level, and how chaos engineering and property-based testing relate to EN 50128 and ISO 26262.Jak sprawdzić, co się dzieje, gdy coś się psuje: przypadki testowe wyprowadzone z FMEA, wstrzykiwanie uszkodzeń w oprogramowaniu i sprzęcie oraz miejsce inżynierii chaosu i testów opartych na właściwościach wobec EN 50128 i ISO 26262.
