Stand der Überarbeitung in der IEC SC 65A/MT 61508-3...

Stand der Überarbeitung in der IEC SC 65A/MT

61508-3,

Vorbereitung 3. Ausgabe der IEC 61508

GAK 914.0.3

Frankfurt, 1.03.2017

Einordnung der vorbereitenden Maßnahmen zur 3. Ausgabe der IEC 61508

28.03.2017 © 2016 DKE Deutsche Kommission Elektrotechnik Elektronik Informationstechnik in DIN und VDE 2

- Im November 2014 starteten die Arbeiten zur Ermittlung des Änderungsbedarfs für die IEC 61508-

3:2010.

- Die dabei identifizierten Themen werden in diesem Vortrag präsentiert.

- Ein Beschluss zur Überarbeitung der IEC 61508-3 liegt derzeit nicht vor.

- Aktuell ist DKE aufgefordert Änderungsvorschläge zur IEC 61508:2010 bis zum 7.4.2017 offiziell bei

IEC einzureichen.

- Nur diese offiziell eingereichten Änderungsvorschläge werden bei der Überarbeitung ggf.

berücksichtigt.

- Insbesondere müssen die offiziell eingereichten Änderungsvorschläge nicht alle hier vorgestellten

Themen adressieren.

Themengebiete

Software Sicherheitslebenszyklus

Software Architektur und Design

Multi-Core

Definition „formale Methoden“

Verbesserungen V&V

Hardware / Software Schnittstelle

Unabhängigkeit zwischen Entwurf/Implementierung und Test/Verifikation

Toolqualifikation

Änderungen und Regressionstests/Validierung

Software-Metriken

Integration der IEC TS 61508-3-1


Themengebiete

Referenzen zur IEC 61508-1, IEC61508-2

Systematische Eignung von Softwareelementen

Objektorientierter Entwurf

Security

Modell basierte Entwicklung

Verfolgbarkeit


Software Sicherheitslebenszyklus


- Die aktuelle Version der IEC 61508-3 vermittelt dem Leser den Eindruck, dass der

Softwareentwicklungsprozess dem klassischen V-Modell folgen soll.

- Aus Entwicklungsprojekten ist bekannt, dass eine Entwicklungsphase Rückwirkungen auf

vorhergehende Entwicklungsphasen haben kann. Dieses entspricht nicht dem Vorgehen nach dem

klassischen V-Modell.

- Es ist vorgeschlagen, dass moderne iterative/inkrementelle Entwicklungsprozesse eingeführt

werden.

- Diese modernen Entwicklungsprozesse werden seit Jahren in angepasster Form für die Entwicklung

von Sicherheitsfunktionen genutzt.

- Unabhängig von der gewählten Entwicklungsmethode sind die Anforderungen der IEC61508-3 zu

erfüllen.

Software Architektur und Design


- Die negativen Auswirkungen eines unangemessenen Softwarearchitekturentwurfs oder eines

Softwareversagens auf die Sicherheitsintegrität des Systems werden lediglich in der Note 5 in IEC

61508-3:2010 7.4.3 behandelt und sollen adressiert werden.

- Es ist vorgeschlagen in die IEC 61508-3 eine Anforderung aufzunehmen, die eine Darstellung fordert,

dass der Softwarearchitekturentwurf oder Softwareversagen keinen negativen Einfluss auf die

Sicherheitsintegrität des Systems haben.

- Die Anforderungen in der IEC 61508-2 für die Ableitung der Softwareanforderungen von den

Hardwareanforderungen bedürfen einer Verbesserung (siehe Thema „Hardware/Software Interface“

oder „Referenzen zur IEC 61508-1, IEC61508-2“).

Multi-Core


- IEC 61508-3:2010 Anhang F “Verfahren zum Erreichen der Nicht-Beeinflussung zwischen

Softwareelementen auf einem einzelnen Rechner” soll überarbeitet werden um die Erfordernisse bei

dem Einsatz von multi-core Prozessoren zu berücksichtigen.

- Einige Probleme des Einsatzes von multi-core Prozessoren betreffen die Synchronisation von parallel

laufenden Prozessen mit Zugriff auf gemeinsame Ressourcen.

- Die Synchronisation von parallel laufenden Prozessen mit Zugriff auf gemeinsame Ressourcen stellt

keinen neuen Aspekt für die Softwareentwicklung dar.

Definition „formale Methoden“


- Es wird vorgeschlagen die Definition in IEC 61508-7 B 2.2 “Formale Methoden” zu erweitern. Die Nutzung

von formalen Methoden kann unvermeidlich sein in Abhängigkeit von der Komplexität und der Höhe des

Vertrauens.

- Es ist vorgeschlagen die Definition in IEC 61508-7 B 2.3 “Semi-formale Methoden” zu löschen, weil semi-

formale Methoden durch IEC 61508-3 Anhang B Tabelle B.7 “Semi-formal Methoden” abgedeckt sind.

- Ein “new work item proposal” für eine technische Spezifikation zur Nutzung von mathematischen und

logischen Techniken, um bestimmte Eigenschaften der Software in sicherheitsbezogenen Systemen zu

gewährleisten, wird durch DKE/GAK 914.0.3 erstellt.

Verbesserungen V&V


- Verifikation und Validierung sind Maßnahmen gegen systematische Fehler in der Software. Zur

Auswahl adäquater Methoden, die die unterschiedlichen Arten von Fehlern adressieren, ist ein klares

Verständnis der unterschiedlichen Arten von systematischen Fehlern erforderlich.

- Es ist vorgeschlagen IEC 61508-3:2011 Absatz 7.3.2.2 (betrifft Validierungsplanung) zu ändern um die

Verifikationsmethoden für funktionale, strukturelle und regressions-Tests zu adressieren.

- Es ist vorgeschlagen eine neue Tabelle in IEC 61508-3:2010 Annex B aufzunehmen, die die Methoden

aus IEC 61508-3 Anhang A und B, in die unterschiedlichen Arten von Methoden wie „statisch“,

„dynamisch“, „funktional“, „strukturell “, „Existenz von Fehlern“, „Abwesenheit von Fehlern“ und

„Übereinstimmung“ die in IEC 61508-3:2010 Absatz 7.3.2.3 gefordert sind, einordnet.

Hardware / Software Schnittstelle


- Anforderungen an die Hardware/Software Schnittstelle werden definiert, die folgendes adressieren:

Die Konsistenz der Hardware/Software Schnittstelle zum Systemdesign

Die Betriebsmodes und Konfigurationsparameter der Hardware.

Die Merkmale der Hardware die die Unabhängigkeit zwischen Elementen sicherstellen oder das

partitionieren der Software unterstützen.

Die gemeinsame/exklusive Nutzung der Hardwarebestandteile und die Methoden der

Synchronisation des Zugriffes.

Die Hardwarediagnosefeatures die durch die Software implementiert oder konfiguriert werden

müssen.

Die Spezifikation aller transferierten Daten sowie ihre Funktion und Werte.

- Es ist vorgeschlagen die Anforderungen an das Hardware/Software Interface in IEC 61508-2:2010

aufzunehmen.

- Parallel mit der Definition der Hardware/Software Schnittstelle werden die Absätze der IEC 61508-

1:2010, IEC 61508-2:2010 und IEC 61508-7:2010 identifiziert, die zu aktualisieren sind, in Bezug auf

die Einführung der Hardware/Software Schnittstelle.

Unabhängigkeit zwischen Entwurf/Implementierung und Test/Verifikation


- Es wird diskutiert Anforderungen an die Unabhängigkeit in Abhängigkeit vom SIL zwischen den

Design/Implementierungs-Aktivitäten und Test/Verifikations-Aktivitäten zu definieren.

- Grundlage für die Diskussion sind Anforderungen bezüglich der Unabhängigkeit von Aktivitäten/Rollen

die in anderen Standards (DO-178C, ISO 26262-2:2011, EN 50128:2011) definiert sind.

Toolqualifikation


- Es ist vorgeschlagen IEC 61508-3:2010 Kapitel 7.4.4 „Anforderungen an Werkzeuge einschließlich

Programmiersprachen“ zu überarbeiten.

- GAK914.0.3 hat hierzu Änderungsvorschläge formuliert.

Änderungen und Regressionstests/Validierung


- Es ist vorgeschlagen eine Definition von „Regressionstest“ in IEC 61508-4:2010 basierend auf der

Definition aus ISO/IEC 90003:2014 aufzunehmen, da Regressionstests bei Anwendung moderner

iterativer/inkrementeller Entwicklungsprozesse mehr Relevanz besitzen (siehe Thema „Software

Sicherheitslebenszyklus).

- Parallel mit der neuen Definition für „Regressionstest“ ist vorgeschlagen IEC 61508-7 C.5.25

”Regression validation” zu aktualisieren um „Regressionstest“ in Beziehung zu “Regression validation”

einzuführen.

- Parallel mit der neuen Definition für „Regressionstest“ werden die Absätze und Tabelle der IEC 61508-

3 identifiziert die zu aktualisieren sind um „Regressionstests“ und die Nutzung in Bezug zur Anwendung

moderner iterativer/inkrementeller Entwicklungsprozesse einzuführen.

Software-Metriken


- Wie Software-Metriken in die IEC 61508-3 eingeführt werden wird diskutiert.



- Die IEC TS 61508-3-1:2016 definiert die Anforderungen für die Wiederverwendung von bereits

existierender Software zur Realisierung von Teilen oder ganzen Sicherheitsfunktionen als neue

Definition für „Pfad 2s“ in IEC 61508-3 Absatz 7.4.2.12 a) “ Pfad 2s”.

- Das Prinzip der Wiederverwendung in Sicherheitsfunktionen bis SIL 2 basiert auf:

Dem vollständig dokumentierten Nachweis der korrekten Funktion aller Kombinationen der:

Kombinationen von Eingangsdaten

Abfolgen der Ausführung von Funktionen.

zeitliche Beziehungen innerhalb der Abfolgen der Ausführung von Funktionen.

Der Bewertung von Differenzen zur vorhergehenden Nutzung in Bezug auf das Betriebsprofil, die

Umgebung und der Funktionalität zusammen mit der Definition von Maßnahmen um die korrekte

Funktion sicherzustellen.

Dem Nachweis das Funktionen bei denen die korrekte Funktion nicht nachgewiesen ist, keinen

negativen Einfluss auf die Sicherheitsintegrität des sicherheitsrelevanten Systems haben.



- Die IEC TS 61508-3-1:2016 soll integriert werden als neuer Absatz in IEC 61508-3:2010 Kapitel 7.4.2.

- Mit der Integration sollen die Anforderungen aktualisiert werden, sodass die Wiederverwendung für SIL

3 und SIL4 abgedeckt wird. Diese wird erreicht durch Erweiterung der genutzten Kombinationen der:

Kombinationen von Eingangsdaten

Abfolgen der Ausführung von Funktionen.

zeitliche Beziehungen innerhalb der Abfolgen der Ausführung von Funktionen.

um den internen Zustand des wiederverwendeten existierenden Softwareelements.



- Alle Referenzen in IEC 61508-3:2010 auf IEC 61508-1:2010 und IEC 61508-2:2010 wurde überprüft

in Bezug auf ihre Gültigkeit in Beziehung zur Entwicklung von Software.

- Nach IEC 61508-3:2010 Absatz 7.2.2.1 kann die Spezifikation der Anforderungen an die Sicherheit

der Software enthalten sein in der Spezifikation der Anforderungen des E/E/PE-Systems (IEC 61508-

2:2010 Kapitel 7 “Anforderungen des Sicherheitslebenszyklus des E/E/PE-Systems”).

- Bei dem Vergleich der Anforderungen definiert in IEC 61508-3:2010 Kapitel 7.2 “ Spezifikation der

Anforderungen an die Sicherheit der Software” gegen die Anforderungen definiert in IEC 61508-

2:2010 Kapitel 7 wurde Lücken identifiziert in der Erfüllung von IEC 61508-3:2010 Absatz 7.2.2.1.

- Es ist vorgeschlagen die Lücken in der Erfüllung von IEC 61508-3:2010 Absatz 7.2.2.1 zu schließen.

Die erforderlichen Änderungen um die Lücken zu schließen sind vorgeschlagen.



- Nach IEC 61508-3:2010 Absatz 6.2.1 „Zusätzliche Anforderungen an das Management der

sicherheitsbezogenen Software“ sollten auch die Anforderungen in IEC 61508-1, 6.2 durch die

Software erfüllt werden.

- Einige Anforderungen aus IEC 61508-1, 6.2 sind nicht bezogen auf Software und sollen in 61508-

3:2010 Absatz 6.2.1 ausgenommen werden.

- Die Anforderungen, die ausgenommen werden sollen oder Duplikate sind, sind identifiziert und die

erforderlichen Änderungen werden vorgeschlagen.



- Die Anforderungen in IEC 61508-3:2010 Kapitel 7.7 “Softwareaspekte bezüglich der Validierung der

Sicherheit des System” sollen abgeglichen werden mit den generellen Anforderungen definiert in IEC

61508-2:2010 Kapitel 7.7 “Validierung der Sicherheit des E/E/PE-Systems”.

- Die Erfordernisse für den Abgleich zwischen IEC 61508-3:2010 Kapitel 7.7 und IEC 61508-2:2010

Kapitel 7.7 sind identifiziert und die entsprechenden Änderungen sind vorgeschlagen.

Systematische Eignung von Softwareelementen


- Die Anforderungen in IEC 61508-2:2010 Absatz 7.4.3 „Synthese von Elementen zum Erreichen der

erforderlichen systematischen Eignung“ beziehen sich auf Hardware und sollen verbessert werden um

die Ansprüche von Software abzudecken.

- Die Verbesserungen, um die Ansprüche der Software abzudecken, werden vorgeschlagen.

Objektorientierter Entwurf


- IEC 61508-3:2010 Annex A Table 4 Note 2 gibt an, dass die Eignung des objektorientierten Entwurfs

für die Entwicklung von sicherheitsrelevanter Software diskutiert wird.

- Da der objektorientierte Entwurf für die Entwicklung von sicherheitsrelevanter Software seit Jahren

angewendet wird, wird vorgeschlagen IEC 61508-3:2010 Annex A Table 4 Note 2 zu löschen.

- Anleitung für die Entwicklung von sicherheitsrelevanter objektorientierter Software wird bereits jetzt in

IEC 61508-7:2010 Annex G gegeben.

- Ein “new work item proposal” für eine technische Spezifikation zur Nutzung von objektorientierter

Software in sicherheitsbezogenen Systemen wird durch DKE/GAK 914.0.3 erstellt.

Security


- In der aktuellen Version der IEC 61508 wird Security erwähnt. Eine Anleitung zur Koordinierung von

funktionaler Sicherheit und Security ist beschränkt vorhanden.

- Die Erfordernisse zur Koordinierung von funktionaler Sicherheit und Security werden diskutiert.

Modell basierte Entwicklung


- Es wird vorgeschlagen eine Anleitung für die Nutzung von modell basierter Entwicklung in einem

neuen Anhang zur IEC 61508-3 aufzunehmen.

- Die Anleitung beschreibt die mögliche Nutzung, Vorteile und Schwierigkeiten modell basierter

Entwicklung.

Verfolgbarkeit


- Es besteht eine Inkonsistenz zwischen den Anforderungen zur Verfolgbarkeit in IEC 61508-3:2010

Anhang A Tabelle A.4 und der Beschreibung in IEC 61508-7 C.2.1 bezüglich der Verfolgbarkeit

zwischen der Softwaresicherheitsanforderungsspezifikation und dem Softwarequellcode.

- Es ist vorgeschlagen diese Inkonsistenz dadurch zu lösen, indem die Verfolgbarkeit der

Softwaresicherheitsanforderungsspezifikation und des Softwarequellcodes in IEC 61508-3:2010 Annex

A Tabelle A.4 aufgenommen wird.

Vielen Dank für

Ihre Aufmerksamkeit

DKE – Die Kraft der Normung

Ihr Ansprechpartner:

Ingo Rolle

Abteilung

Phone: +49 69 6308 291

[email protected]

Stand der Überarbeitung in der IEC SC 65A/MT 61508-3...

Documents

Transcript of Stand der Überarbeitung in der IEC SC 65A/MT 61508-3...