Die neue EN 50716:2023 «Anforderungen für Software Entwicklung» Teil 1

Folgende Hauptänderungen resultieren in den einzelnen Kapiteln

1. Scope 

Die [SN EN 50716:2013] löst die [SN EN 50128:2011] und die [EN 50657:2017] inkl. ihre Amendments ab. Die Aufteilung der Softwareentwicklungsvorgaben in eine Norm für Sicherungsanlagen und eine für Fahrzeuge entfällt. Zudem ist die Norm auch für Software mit Basic Integrity (vormals SIL0) anwendbar. Die Einschränkung in 1.3, dass die Norm keine Bedeutung für nicht sicherheitsbezogene Software habe, wurde gelöscht. 

2. Normative references 

Im Kapitel sind keine normativen Referenzen mehr aufgelistet. 

3. Terms, definitions and abbreviations 

Einige Begriffe wurden an andere Normen angeglichen und mit den Quellenverweisen aus ISO und IEC ergänzt. Die Abkürzung INT «Integrator» wurde gelöscht. 

4. Software integrity levels conformance 

Für alle nicht sicherheitsbezogenen Funktion der Software soll mindestens ein qualitätssichernder Prozess angewendet werden. Eine der Empfehlungen sind die “Basic Integrity” Anforderungen der [SN EN 50716:2011]. 

Ein wichtiger Punkt ist in 4.1 NOTE 2 aufgeführt: Der Begriff «System Requirements Specification» umfasst in der Norm die gesamten Systemanforderungen inklusive der Safety Anforderungen. Die Frage ob die Anforderungen in zwei separate Dokumente aufgeteilt werden müssen (Safety und nicht Safety) ist damit unseres Erachtens endgültig geklärt. 

5. Software management and organization 

Das Ziel in 5.1.1, die organisatorische Unabhängigkeit der verschiedenen Rollen sicherzustellen, wird statt in einem Satz nun umfangreicher beschrieben. Insbesondere 5.1.1 b) verweist auf Druck von Kollegen oder Vorgesetzten sowie Gewinndenken hin, der sich auf die Safety auswirken könnte. 

Die Herausforderung für einzelne Manager wird sein, sich nicht nur auf Kennzahlen zu fokussieren, sondern die Grundsätze der eigenen Safety Policy vorzuleben. ERA hat dazu gute Informationen zu “Safety Culture” publiziert.

Zur Publikation >

5.1.2.4 verlangt nur noch, dass ein Gutachter für SIL 1 bis SIL 4 Systeme zugewiesen werden muss. Für Basic Integrity wird kein Gutachter mehr benötigt.

Im Organigramm ist zudem der Integrator gelöscht. 

6. Software assurance 

Bei 6.3.4.12 fällt auf, dass der Validierer nun zusätzliche Audits durchführen kann.  In der Rollenbeschreibung B6.12 waren Audits allerdings schon in der [SN EN 50128:2011] enthalten. Dieser Unterschied wurde nun bereinigt.

6.4.1.2 beschreibt nochmals, dass für Basic Integrity keine Begutachtung benötigt wird.

Welche Dokumente werden für Basic Integrity benötigt? In der Tabelle «A.1 — Lifecycle issues and documentation» fällt auf, dass die SW Architektur und Design Spezifikation nur noch empfohlen ( R ) und nicht mehr ( HR ) sind. Auch sind die SW Component Design und Test von ( R ) auf ( - ) herunter gestuft worden. Das Interface von Basic Integrity Modulen muss weiterhin «Fully defined interface» (HR) sein.

Zur Werkzeug Auswahl wird in 6.7.1 in ausführlichem Text beschrieben, dass ein Tool das als funktionaler Bestandteil einer Software benutzt wird, nach dem entsprechend SIL entwickelt werden muss. Die [SN EN 61508-3:2010] beschreibt dies unseres Erachtens eleganter, in Kapitel 7.4.4 gibt es Online-Software-Werkzeuge und Offline-Werkzeuge mit den entsprechenden Anforderungen. 

7. Software development 

Die Rolle Integrator wurde durch Tester ersetzt.

Gemäss 7.3.4.25 soll eine geeignete Programmiersprache nach den Kriterien von Tabelle A.15 gewählt werden. In der Tabelle sind nicht mehr Sprachen wie ADA, BASIC, C, PL/M, etc. aufgeführt, sondern die Anforderungen an die Sprache wie z.B.: modulare Programmierung, Unterstützung der Kommentierung, strenge Typisierung oder Testbarkeit. In der referenzierten Tabelle D.54 sind die Anforderung an die Programmiersprache überarbeitet worden. Somit wird es möglich werden neuere Sprache wie zum Beispiel Rust zu qualifizieren.

Kapitel 8 und 9 

Die Kapitel «Entwicklung von Anwendungsdaten oder Algorithmen» und «Softwarebereitstellung und -wartung» werden im zweiten Teil des Blogs «Normenablösung EN 50716» genauer betrachtet. Dies liegt zum einen an der hohen Bedeutung dieser Themen für die erfolgreiche Umsetzung der Norm und zum anderen am umfangreichen Inhalt, der eine separate Betrachtung erfordert. 

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

Die Entwicklung von Anwendungsdaten und Algorithmen spielt eine zentrale Rolle bei der Konfiguration von Systemen nach EN 50716. 

9. Software deployment and maintenance 

Die Softwarebereitstellung und -wartung ist ein weiterer wichtiger Aspekt der Norm. Um die Sicherheit und Zuverlässigkeit von Bahnsystemen zu gewährleisten, müssen Softwareprozesse und -verfahren etabliert sein, die die Qualität und Sicherheit der Software sicherstellen.

Der umfangreiche Inhalt dieser beiden Kapitel macht es notwendig, sie im zweiten Teil des Blogs separat zu betrachten. So kann den komplexen Themen die nötige Aufmerksamkeit gewidmet werden und die Leser erhalten einen tieferen Einblick in die Anforderungen der Norm. 

Fazit 

Eine erste Analyse hat gezeigt, dass die neue [SN EN 50716:2023] strukturell der Vorgängernorm [SN EN 50128:2011] angeglichen ist und dadurch eine einfache Einarbeitung und Auffindbarkeit erreicht wurde. Mit den angepassten Punkten ist die [SN EN 50716:2023] unserer Meinung nach ein gelungener Wurf und beschreibt einheitlich wie Software für Eisenbahnanwendungen, unabhängig ob für Infrastruktur oder Fahrzeuge, entwickelt werden muss. Kapitel 8 und 9 erfordern eine detaillierte Analyse, welche in einem zweiten Teil durchgeführt wird. Für die Anpassung von Vorlagen, Checklisten und der Erarbeitung von Spezifikationen ist ebenfalls eine detaillierte Analyse notwendig.

Stehen bei Ihnen normative oder allgemeine Requirements Engineering Arbeiten an?

Wir als CSA Engineering AG unterstützen Sie gerne bei Ihrem Vorhaben. Kontaktieren Sie uns für ein unverbindliches Gespräch über die Möglichkeiten und den geeignetsten Support.