Weiterentwicklung der EN (VDE ) 128) Umsetzung im Bahnbereich

Transkript

1 Weiterentwicklung der EN (VDE ) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, Dezember 2009

2 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung für den Nah- und Fernverkehr: Stellwerke und Leitsysteme Fahrzeugsteuerungen Stellwerke Leitsysteme Fahrzeugsteuerungen Komponenten Telekommunikationssysteme für den Bahnbereich Komponenten Telekommunikationssysteme für den Bahnbereich Seite Dezember 2009 Andreas Armbrecht

3 Was wird entwickelt? Software für elektronische Stellwerke, Leitsysteme, Fahrzeugsteuerungen, Komponenten und Telekommunikationssysteme Die durch die Software realisierten sicherheitskritischen Funktionen laufen auf spezieller eigenentwickelter sicherheitsrelevanter Hardware müssen häufig die Anforderungen für die höchste Sicherheitsanforderungsstufe SIL4 der EN50128 erfüllen SIL Safety Integrity Level Seite Dezember 2009 Andreas Armbrecht

4 Themen des Vortrages Termine Anwendungsbereich Struktur Dokumentation und Entwicklungsprozess Sicherheitsanforderungsstufe (SIL) Rollen/Unabhängigkeiten Prototyping Tools Kompetenz Schnittstellenbeschreibung Codierstandard Bereitstellung der Software (Deployment) Techniken/Maßnahmen Testabdeckung Objektorientierte Entwicklung Seite Dezember 2009 Andreas Armbrecht

5 Termine Sekretariats-Umfrage: Abschluss 04/2009 Fünf-Monats-Umfrage: Bearbeitung der Kommentare aus der Fünf-Monats-Umfrage: seit Anfang 08/2009 Abschluss Ende 12/2009 ab 02/2010 Abschluss: Ende 2010 / Anfang 2011 Seite Dezember 2009 Andreas Armbrecht

6 Anwendungsbereich Die Norm wird nicht angewendet, für Software die keinen Einfluss auf die Sicherheit hat. Fehlfunktionen dieser Software haben keinen Einfluss auf die spezifizierten Sicherheitsfunktionen. Software die nach der Vorgängerversion entwickelt wurde, wird als konform betrachtet. Diese Software unterliegt nicht den Anforderungen bezüglich pre-existing software. Seite Dezember 2009 Andreas Armbrecht

7 Struktur Klare Zuordnung der verantwortlichen Rolle und der inhaltlichen Anforderungen zu den zu erstellenden Dokumenten definiert Beispiel: Eine Software-Anforderungsspezifikation ist unter der Verantwortung des Requirement Managers auf der Grundlage der Eingangsdokumente nach zu erstellen. Die Anforderungen in bis beziehen sich auf die Software- Anforderungsspezifikation. Seite Dezember 2009 Andreas Armbrecht

8 Struktur Einbinden aller relevanten Teile über Referenzen auf die entsprechenden Anforderungen aus der EN50128 Beispiel: Die Software-Anforderungsspezifikation wird durch Techniken und Maßnahmen aus Tabelle A.2 unterstützt. Die ausgewählte Kombination wird als eine Menge von Techniken und Maßnahmen begründet, die die Abschnitte 4.10, 4.11 und 4.12 erfüllen. Seite Dezember 2009 Andreas Armbrecht

9 Struktur Integration der im Rahmen der Verifikation eines Dokumentes durchzuführenden Reviews in das Kapitel, in dem auch die Anforderungen an das Dokument definiert werden Seite Dezember 2009 Andreas Armbrecht

10 Struktur Klare Definition der im Rahmen der Verifikation eines Dokumentes zu klärenden Fragestellung festgelegt Beispiel: Wenn die Software-Anforderungsspezifikation aufgestellt worden ist, muss sich die Verifikation darauf richten dass: a) die Eignung der Software-Anforderungsspezifikation zur Erfüllung der Anforderungen, die in den Eingangsdokumenten nach festgelegt worden ist, b) die Software-Anforderungsspezifikation die allgemeinen Anforderungen an Lesbarkeit und Rückverfolgbarkeit, gemäß bis und die spezifischen Anforderungen, die in bis angegeben sind, erfüllt. Seite Dezember 2009 Andreas Armbrecht

11 Dokumentation Geänderte Regelung für das Zusammenfassen von Dokumenten Wenn Dokumente, die von unabhängigen Rollen erstellt wurden, in einem einzigen Dokument zusammengefasst werden, muss die Beziehung zu den von den unabhängigen Rollen erstellten Teilen innerhalb des Dokuments verfolgbar sein Wird eine alternative Dokumentationsstruktur aufgestellt, muss nachgewiesen werden, dass alle Ziele und Anforderungen dieser entsprechenden Europäischen Norm erfüllt werden. Seite Dezember 2009 Andreas Armbrecht

12 Entwicklungsprozess Die Norm fordert nicht die Anwendung eines bestimmten Entwicklungsprozesses. Es wird kein Entwicklungsprozess vorgegeben. Auszug: Die Norm schreibt keinen Gebrauch für einen bestimmten Software- Entwicklungslebenszyklus vor Das Lebenszyklus-Modell muss die Möglichkeit von Iterationen in und zwischen den Phasen in Betracht ziehen Einige Entwicklungsschritte dürfen kombiniert, aufgeteilt oder nach dem Ermessen des Projektmanagers und mit der Zustimmung des Validierers eliminiert werden Wird eine alternatives Lebenszyklusmodell aufgestellt, muss nachgewiesen werden, dass alle Ziele und Anforderungen dieser Europäischen Norm erfüllt werden. Seite Dezember 2009 Andreas Armbrecht

13 Sicherheitsanforderungsstufe (SIL) Die Bezeichnung SWSIL wurde geändert nach SIL (wie IEC) Definition SIL0 = nicht sicherheitsrelevante Software wurde geändert Die Klassifizierung der Techniken/Maßnahme in Techniken/Maßnahme SIL1 = SIL2 und Techniken/Maßnahme SIL3 = SIL4 nicht geändert (im Gegensatz zur IEC) SWSIL Software-SIL Auszug: Für Software, dessen Sicherheitseinfluss unter SIL 1 liegt, müssen mindestens die Anforderungen für SIL 0 nach dieser Europäischen Norm erfüllt werden. Seite Dezember 2009 Andreas Armbrecht

14 Rollen Die Rolle Designer / Implementer (DI) wurde aufgeteilt in die Rollen Requirements Manager (REQ), Designer (DES) und Implementer IMP Die Rollen Integrator (INT) und Tester (TST) wurden als eigenständige Rollen aus der bisherigen Rolle Verifizierer (VER) abgeleitet Der Rolle Verifizierer sind im wesentlichen die Review-Tätigkeiten zugeordnet worden Seite Dezember 2009 Andreas Armbrecht

15 Unabhängigkeiten PJ M ASR SIL 3 & SIL 4 REQ, DES, IMP INT, TST VER VAL Ausnahmen sind über zusätzliche Anforderungen geregelt SIL 1 & SIL 2 PJM ASR REQ, DES, IMP INT, TST VER, VAL SIL 0 PJ M ASR REQ, DES, IMP INT, TST, VER, VAL Key can be the same person can be the same organization shall be managed by the Project Manager can be managed by the Project Manager shall not be managed by the Project Manager Seite Dezember 2009 Andreas Armbrecht

16 Prototyping Regeln für die Integration von Prototypen wurden aufgestellt In Sonderfällen, z. B. Software-Prototypen, darf die Verfolgbarkeit nach der Implementierung und/oder Dokumentation des Codes noch vor der Verifikation/Validierung festgelegt werden. In diesen Fällen muss gezeigt werden, dass die Verifikation/Validierung genauso effektiv ist wie bei einer Verfolgbarkeit über alle Phasen. Prototypen dürfen in jeder Phase verwendet werden, um die Anforderungen abzuleiten und dadurch eine detaillierte Sicht auf die Anforderungen und ihre Konsequenzen zu erhalten. Der Code eines Prototypen darf im Zielsystem nur dann verwendet werden, wenn nachgewiesen worden ist, dass der Code und seine Entwicklung und Dokumentation die Anforderungen dieser Europäischen Norm erfüllt. Seite Dezember 2009 Andreas Armbrecht

17 Tools In Anlehnung an die IEC wurde das Kapitel Support tools and languages aufgenommen Ziel: Erbringung des Nachweises, dass mögliche Fehler der Werkzeuge das Ausgangsprodukt des integrierten Werkzeugsatzes nicht in einer sicherheitsrelevanten Weise beeinflussen, die durch technische und/oder organisatorische Maßnahmen außerhalb des Werkzeuges unerkannt bleiben. Seite Dezember 2009 Andreas Armbrecht

18 Kompetenz In einem neuen Anhang B wurden die Kompetenzen und Verantwortlichkeiten für jede Rolle zusammengestellt Beispiel: Tabelle B.1 Spezifikation der Rolle Requirements Manager Rolle: Requirements Manager Verantwortlichkeiten: 1. verantwortlich für das spezifizieren der Software-Anforderungen Festlegen und Aktualisieren der Verfolgbarkeit zu den Anforderungen der Systemebene 4. Schlüsselkompetenzen: 1. fachkundig in Requirements Engineering 2. Verständnis für das Gesamtsystem und der Anwendungsumgebung Verständnis der Anforderungen der EN50128 Seite Dezember 2009 Andreas Armbrecht

19 Schnittstellenbeschreibung Anforderungen an den Inhalt von Schnittstellenbeschreibungen wurden aufgestellt Auszug: Die Beschreibung der Schnittstellen muss behandeln: a) Vor- / Nachbedingungen b) Festlegung und Beschreibung aller Grenzwerte für alle Daten e) Festlegung und Beschreibung aller Äquivalenzklassen für alle Daten f) die Funktion für alle Äquivalenzklassen, ebenso die Funktion für nicht verwendete Äquivalenzklassen g) Laufzeit der zeitkritischen Funktionen, die von den Eingangsdaten und den verwendeten Algorithmen abhängen Seite Dezember 2009 Andreas Armbrecht

20 Codierstandards Berücksichtigung des Themas Fehler bei der Anwendung einer Sprache Auszug: Codierstandards müssen entwickelt und festgelegt werden für: b) Maßnahmen zur Vermeidung oder Erkennung von Fehlern, die bei der Anwendung der Sprache entstehen und die während der Verifikation (siehe Abschnitte 7.5 und 7.6) nicht aufgedeckt werden Seite Dezember 2009 Andreas Armbrecht

21 Bereitstellung der Software (Deployment) Aufnahme des Themas Bereitstellung der Software in einem neuen Kapitel Beispiel: Eine Release-note muss bereitgestellt werden, in der die einzuhaltenden Anwendungsbedingungen festgelegt sind Die Software muss einen eingebetteten Selbst- Identifizierungsmechanismus besitzen, die ihre Identifikation beim Ladevorgang und nach dem Laden in das Ziel zulässt Die Software muss rückverfolgbar auf die ausgelieferten Installationen sein Seite Dezember 2009 Andreas Armbrecht

22 Techniken und Maßnahmen Auszug: Im Anhang A, Tabelle A.20 Testabdeckung für Code neu aufgenommen Auszug: Table A.20 Testabdeckung für Code Technik/Maßnahme Ref SIL 0 SIL 1 SIL 2 SIL 3 SIL 4 1. Anweisung D.58 R HR HR HR HR 2. Verzweigung D.58 - R R HR HR 3. Zusammengesetzte Bedingungen D.58 - R R HR HR 4. Data flow D.58 - R R HR HR 5. Path D.58 - R R HR HR 3) Es dürfen andere Kriterien für die Testabdeckung angewendet werden. Die anderen Kriterien sind zu begründen. Diese Kriterien sind von der Software-Architektur und der Programmiersprache abhängig. Seite Dezember 2009 Andreas Armbrecht

23 Techniken und Maßnahmen Im Anhang A, Tabelle A.21 Objektorientierte Software-Architektur in Anlehnung an die IEC aufgenommen Auszug: Table A.21 Objektorientierte Software-Architektur Technik/Maßnahme Ref SIL 0 SIL 1 SIL 2 SIL 3 SIL 4 1. Verfolgbarkeit der Anwendungsbereiches ais die Klassen der Architektur - R R R HR HR 2. Anwendung geeigneter Rahmen, überlicherweise angewendeter Kombinationen von Klassen und Entwurfsmustern 3. Objektorientierter detaillierter Entwurf Seite Dezember 2009 Andreas Armbrecht - R R R HR HR A.22 R R R HR HR 1) Bei der Anwendung vorhandener Rahmen und Entwurfsmuster sind Anforderungen an pre-existing software zu erfüllen.

24 Techniken und Maßnahmen Auszug: Im Anhang A, Tabelle A.22 Objektorientierter detaillierter Entwurf in Anlehnung an die IEC aufgenommen Auszug: Table A.22 Objektorientierter detaillierter Entwurf Technik/Maßnehme Ref SIL 0 SIL 1 SIL 2 SIL 3 SIL 4 1. Klassen sollen nur ein Ziel - R R R HR HR 2. Vererbung ist nur anzuwenden, wenn die abgeleitete KLasse, eine Verfeinerung seiner Basisklasse ist. - R HR HR HR HR 5. Mehrfachvererbung ist nur für Schnittstellenklassen anzuwenden. A.22 R HR HR HR HR Seite Dezember 2009 Andreas Armbrecht

25 Vielen Dank für f r ihre Aufmerksamkeit! Andreas Armbrecht Siemens AG Darmstadt, Dezember 2009 Seite Dezember 2009 Andreas Armbrecht