Nachverfolgbarkeit von Anforderungen und deren Realisierungen für wiederverwendbare Software ~ VDE-Tagung zur IEC 61508 und zur IEC 62443 M.Sc. Felix Bangemann.

Präsentation zum Thema: "Nachverfolgbarkeit von Anforderungen und deren Realisierungen für wiederverwendbare Software ~ VDE-Tagung zur IEC 61508 und zur IEC 62443 M.Sc. Felix Bangemann."—  Präsentation transkript:

1 Nachverfolgbarkeit von Anforderungen und deren Realisierungen für wiederverwendbare Software ~ VDE-Tagung zur IEC und zur IEC 62443 M.Sc. Felix Bangemann – Universität Magdeburg Dr.-Ing. Stefan Benk – Phoenix Contact Electronics Prof. Dr.-Ing. Christian Diedrich – Universität Magdeburg Erfurt –

2 Einleitung und Vorstellung
Lehrstuhl für Integrierte Automation – Prof. Christian Diedrich Otto-von-Guericke Universität Magdeburg Felix Bangemann „Entwicklungsprozesse im sicherheitstechnischen Umfeld“ Stefan Benk Phoenix Contact Electronics GmbH Produktlinie Safety – Referent „Functional Safety“ & Entwicklung FW VITA – Motivation Zusammenarbeit mit Dr. Stefan Benk von Phoenix Contact Electronics Seit zwei Jahren gemeinsames Thema: Entwicklungsprozesse für eingebettete sicherheitskritische Geräte, wie sie z.B. von Phoenix entwickelt werden.

3 Anforderungen sind lösungsfrei
Problematik Anforderungen sind lösungsfrei Nachverfolgbarkeit der Anforderungen Lösungen sind anforderungsfrei Problematik Die Definition der Anforderungen an ein Gerät erfolgt idealerweise ohne Kenntnis der späteren Umsetzung, also lösungsfrei. Erst bei der Entwicklung eines Konzepts und der Gerätearchitektur fließen konkrete Lösungsansätze in die Entwicklung ein. Im Umkehrschluss dazu enthalten die konkreten Realisierungen selbst keinerlei Anforderungen an das Gerät. Dies ist vor allem sinnvoll, da das gleiche Softwaremodul in verschiedenen Geräten eingesetzt werden soll. Gerade bei der Entwicklung sicherheitsgerichteter Geräte wird eine durchgehende Nachverfolgbarkeit der Anforderungen benötigt. Das heißt, die Geräteanforderungen und deren Realisierungen werden miteinander verknüpft. Diese Verknüpfung auch für wiederverwendbare Software einfach zu gestalten, ist heute Inhalt meines Vortrags. Was ist mit wiederverwendbaren Modulen? Was ist mit produktspezifischen Anforderungs-ID‘s?

4 Nachverfolgbarkeit nach IEC 61508
Klassische Nachvefolgbarkeit In der IEC detailliert beschrieben Vorwärts- und Rückwärtsverfolgbarkeit: „Ist eine Realisierung geeignet, die Anforderungen zu erfüllen?“ „Wird die Realisierung für eine Anforderung benötigt?“ Ziele: Alle Anforderungen erfüllt! Keine Realisierung ist überflüssig!

5 Klassifizierung der Nachverfolgbarkeit
Requirements Relationships Constraints Klassifizierung Um die Nachverfolgbarkeit später einfacher auf wiederverwendbare Softwaremodule anwenden zu können, möchte ich jetzt drei Nachvollziehbarkeits-Klassen einführen. Diese Klassen unterscheiden sich jeweils in den betrachteten Nachverfolgbarkeits-Objekten. Die erste Klasse beschreibt die Nachverfolgbarkeit der Geräteanforderungen im engsten Sinne, also z.B. zu erfüllende normative Anforderungen. Als zweite Klasse führe ich die Beziehungen zwischen den Modulen an, Diese werden mit Hilfe von Konzept, Architektur und Modulschnittstellen beschrieben. Dabei ist die Architektur eine Konkretisierung der Geräteanforderungen, definiert für die einzelnen Module aber auch neue Anforderungen. Die dritte Nachverfolgbarkeits-Klasse bezieht sich auf Randbedingungen und Parameter der Softwaremodule. Sie sind in der Regel sehr spezifisch und an eine konkrete Realisierung angepasst. Im Folgenden werde ich zeigen, wie die Berücksichtigung dieser Nachverfolgbarkeits-Klassen Vorteile bei der Geräteentwicklung bringen kann. Bildquellen:

6 Abhängigkeiten zwischen Hardware und Software
Klassische Abhängigkeiten HW & SW Zunächst noch einmal zum allgemeinen Vorgehen beim Geräteentwurf. Anhand diesem Bild aus Teil 3 der Norm werde ich meine weiteren Schritte ableiten. Dargestellt sind die Entwicklungsschritte und deren Abhängigkeiten für das System (also das Gerät), die Hardware und die Software. Die Software basiert auf der Hardware, weshalb sie nicht absolut getrennt voneinander betrachtet werden können. Ich lege meinen Fokus aber auf den Software-Entwurf und betrachte die Hardware als Voraussetzung und Randbedingungen für eine funktionierende Software. Quelle: [IEC Bild 5] - Beziehung zwischen IEC und IEC und ihre Anwendungsbereiche

7 Entwicklung mit Gerätespezifischem Modul
Gerätespezifisches Modul Wie also könnte eine Geräteentwicklung ablaufen? Man stelle sich die Entwicklung eines Gerätes mit für das Gerät spezifischen Merkmalen vor. Am Anfang der Entwicklung werden die Anforderungen an das Gerät definiert. Diese können allgemeingültig aus Normen stammen oder spezifische Kundenwünsche sein. Diese System-Anforderungen werden HW und SW zugeordnet und anschließend implementiert. Für die Software bedeutet das, dass die Anforderungen im Konzept konkretisiert und den Software-Modulen zugeordnet werden. Je nachdem wie gerätespezifisch die Anforderungen für ein Modul sind, können fertige Module genutzt werden, oder müssen einzelne Module komplett neu implementiert werden. Dabei spielt natürlich auch die verfügbare Hardware eine Rolle. Aus den allgemeinen Anforderungen ergeben sich dabei keinerlei Probleme, da diese für alle Geräte gleich realisiert werden. Abschließend müssen HW und SW im Gerät integriert werden. Bei den Integrationstests sind dann wieder die Anforderungen an die Software wichtig, da gegen diese getestet wird. Ein Großteil der Gesamtkosten entsteht durch die Neu-Entwicklung, Integration und Verifizierung von sehr spezifischen Software-Modulen, weshalb der Einsatz möglichst vieler bereits vorhandener Module das Ziel sein sollte.

8 Entwicklung mit Gerätespezifischer Parametrierung
Gerätespezifische Parametrierung Und so sieht unser Ansatz zur Vermeidung der Neu-Entwicklung der Software-Module aus. Wenn wir davon ausgehen, dass wir nur bereits vorhandene Module im Gerät verwenden, so ergeben sich daraus einige Konsequenzen. Zunächst werden die Wechselwirkungen zwischen den einzelnen Modulen werden nicht in den Modulen selbst, sondern bereits im Konzept definiert. die Modulschnittstellen müssen also bereits eine Umstrukturierung für ein neues Gerät unterstützen. Des Weiteren müssen die Module so allgemein gestaltet werden, dass sie ohne Veränderungen am Code unter anderen Betriebsbedingungen genutzt werden können. Ermöglicht wird das durch eine Verlagerung der Modul-Spezifika in die Parametrierung des Moduls. Hier werden die Randbedingunen für den Betrieb des Moduls festgelegt. Das Modul muss vorher natürlich für den Einsatz mit diesen Parametern freigegeben sein. Das heißt, die Betriebsbedingungen, die für ein Modul im Konzept beschrieben sind, werden nicht mehr beim Modul-Entwurf berücksichtigt, sondern erst bei der Integration des Moduls. Durch diese Verlagerung der Modul-Spezifika wird der Aufwand zur Entwicklung der Module im Gerät verringert. Zwar wird der Integrationsaufwand leicht erhöht, aber die Freigabetests der einzelnen Module fallen weg, da diese für die Betriebsparameter bereits freigegeben sind! Für die Nachverfolgbarkeit der Anforderungen bedeutet das, dass die Entwicklung von Anforderungen befreit ist, und gemäß der Norm eine Nachverfolgbarkeit auf Spezifikations- und Test-Ebene erfolgt.

9 Entwicklung mit Gerätespezifischer Parametrierung
Spezifika als Parameter vom generischeren Modul getrennt Entwicklung wird zur Konfiguration bei der Integration Anteil der Modul- Entwicklungen wird reduziert Reduzierung des Entwicklungs- Aufwands Gerätespezifische Parametrierung Und so sieht unser Ansatz zur Vermeidung der Neu-Entwicklung der Software-Module aus. Wenn wir davon ausgehen, dass wir nur bereits vorhandene Module im Gerät verwenden, so ergeben sich daraus einige Konsequenzen. Zunächst werden die Wechselwirkungen zwischen den einzelnen Modulen werden nicht in den Modulen selbst, sondern bereits im Konzept definiert. die Modulschnittstellen müssen also bereits eine Umstrukturierung für ein neues Gerät unterstützen. Des Weiteren müssen die Module so allgemein gestaltet werden, dass sie ohne Veränderungen am Code unter anderen Betriebsbedingungen genutzt werden können. Ermöglicht wird das durch eine Verlagerung der Modul-Spezifika in die Parametrierung des Moduls. Hier werden die Randbedingunen für den Betrieb des Moduls festgelegt. Das Modul muss vorher natürlich für den Einsatz mit diesen Parametern freigegeben sein. Das heißt, die Betriebsbedingungen, die für ein Modul im Konzept beschrieben sind, werden nicht mehr beim Modul-Entwurf berücksichtigt, sondern erst bei der Integration des Moduls. Durch diese Verlagerung der Modul-Spezifika wird der Aufwand zur Entwicklung der Module im Gerät verringert. Zwar wird der Integrationsaufwand leicht erhöht, aber die Freigabetests der einzelnen Module fallen weg, da diese für die Betriebsparameter bereits freigegeben sind! Für die Nachverfolgbarkeit der Anforderungen bedeutet das, dass die Entwicklung von Anforderungen befreit ist, und gemäß der Norm eine Nachverfolgbarkeit auf Spezifikations- und Test-Ebene erfolgt.

10 Trennung von generischen und spezifischen Anforderungen
Zusammenfassung Nachverfolgbarkeit Wieder- verwendbarkeit Konflikt beschreibt beschreibt nutzt Gerätespezifische Anforderungen Generische Anforderungen Resümee Ich möchte das Thema also noch einmal zusammenfassen. Zunächst scheint es, dass die durchgängige Nachverfolgbarkeit der Anforderungen im Konflikt zur ausschließlichen Nutzung von wiederverwendbaren Modulen steht. Wiederverwendbare Module sind allgemeingültig nutzbar, während die Nachverfolgbarkeit vorrangig auf die Abdeckung der spezifischen Anforderungen zielt. In einer Geräte-Entwicklung werden häufig spezifische und allgemeine Anforderungen zusammen behandelt und umgesetzt. Durch die bewusste Trennung der Modulspezifika von der eigentlichen Umsetzung kann die Entwicklung neuer gerätespezifischer Module reduziert werden. Es werden fertige und bereits freigegebene Module verwendet. Bei der Integration dieser Module muss abschließend nur noch die Eignung der spezifischen Parameter überprüft werden. Die Lösung: Trennung von generischen und spezifischen Anforderungen

11 Trennung von generischen und spezifischen Anforderungen
Zusammenfassung vs. ist kein Konflikt Nachverfolgbarkeit Wieder- verwendbarkeit Requirements & Constraints Relationships (Eignung) Requirements Gerätespezifische Anforderungen Generische Anforderungen Resümee Ich möchte das Thema also noch einmal zusammenfassen. Zunächst scheint es, dass die durchgängige Nachverfolgbarkeit der Anforderungen im Konflikt zur ausschließlichen Nutzung von wiederverwendbaren Modulen steht. Wiederverwendbare Module sind allgemeingültig nutzbar, während die Nachverfolgbarkeit vorrangig auf die Abdeckung der spezifischen Anforderungen zielt. In einer Geräte-Entwicklung werden häufig spezifische und allgemeine Anforderungen zusammen behandelt und umgesetzt. Durch die bewusste Trennung der Modulspezifika von der eigentlichen Umsetzung kann die Entwicklung neuer gerätespezifischer Module reduziert werden. Es werden fertige und bereits freigegebene Module verwendet. Bei der Integration dieser Module muss abschließend nur noch die Eignung der spezifischen Parameter überprüft werden. Fazit: Trennung von generischen und spezifischen Anforderungen

12 Vielen Dank für Ihre Aufmerksamkeit!
Felix Bangemann Otto-von-Guericke-Universität Magdeburg - Deutschland The End… © FBA und Dr-SAB 2015 Stefan Benk Phoenix Contact Electronics GmbH - Deutschland