Phoenix Contact Electronics GmbH - Deutschland

Präsentation zum Thema: "Phoenix Contact Electronics GmbH - Deutschland"—  Präsentation transkript:

1 Phoenix Contact Electronics GmbH - Deutschland
Nachverfolgbarkeit von Anforderungen und "konforme Objekte"? Requirement-Traceability and „compliant Item“? Dr. Stefan Benk Phoenix Contact Electronics GmbH - Deutschland THEMA In diesem Vortrag geht es um das Thema der Nachverfolgbarkeit (Traceability) im Zusammenhang mit der Vorwärts- und Rückwärtsverfolgbarkeit. Thematisiert werden vor Allem die Spannungen von Rückwärtsverfolgbarkeit und Wiederverwendbarkeit der Komponenten. Diese Aspekte werden hinsichtlich ihrer Konformität zur IEC untersucht und widersprüchliche bzw. wenig praktikable Denkweisen werden aufgedeckt. Felix Bangemann Otto-von-Guericke-Universität Magdeburg - Deutschland

2 Einleitung und Vorstellung
Dr.-Ing. Stefan Benk Phoenix Contact Electronics GmbH Produktlinie Safety – Fachreferent „Functional Safety“ „Entwicklungsprozesse im sicherheitstechnischen Umfeld“ Lehrstuhl für Integrierte Automation – Prof. Diedrich Otto-von-Guericke Universität Magdeburg M.Sc. Felix Bangemann VITA – Motivation Herr Dr.-Ing. Stefan Benk seit 2008 ist er bei Phoenix Contact Electronics als Fachreferent zur Funktionalen Sicherheit in der Abteilung Safety angestellt. Zuvor war er als Consultant in der FW-Entwicklung der Automobilindustrie tätig. In seinen Positionen als Projektleiter und Firmware-Architekt war er bei zahlreichen kleinen und mittleren Projekten rund um embedded Development Teammitglied. Dabei hatte er mit den Fragestellungen rund um das Thema Traceability mit den Tools DOORS und Polarion, sowie einer Vielzahl händisch gepflegter Office-Dokumente zu tun. Die häufigsten dabei auftauchenden Probleme resultierenden auf der Auslegung der Nachverfolgbarkeit von Anforderungen sowie den langen Einarbeitungszeiten, bzw. wenig vorhandener Tools-Akzeptanz bei („erfahrenen“) Mitarbeitern. Herr Felix Bangemann ist wissenschaftlicher Mitarbeiter und Doktorand an der Otto-von-Guericke-Universität Magdeburg. Am Lehrstuhl für Integrierte Automation bei Prof. Diedrich liegen seine Schwerpunkte bei der Funktionalen Sicherheit nach IEC und deren Auswirkungen auf die Produktentwicklungen. Sie beide verbindet das Thema der Entwicklungsprozesse für eingebettete Geräte im Umfeld der Funktionalen Sicherheit. In diesem Sinne vertritt Stefan Benk eine praxisnahe Mittelstands-Sicht und Felix Bangemann im Kontrast dazu die akademische Sicht.

3 Verifikation im V-Modell
Einleitung Die klassische Nachverfolgbarkeit wird häufig am V-Modells ausgerichtet, wie es in der IEC z.B. bei der SW-Entwicklung beschrieben ist. Hierbei stellt sich die Nachverfolgbarkeit entlang der Verifikation im V-Modell dar. Diese Interpretation spiegelt ein simples Vorgehen wieder. Dabei erfolgt die Nachverfolgbarkeit auf der Realisierungsseite vom jeweils unteren detaillierteren zum oberen generalisierten Block und auf Testseite von den Tests zum realisierenden Block in der gleichen Detaillierungsebene. Wie sich noch zeigen wird, ist dieses Vorgehen zwar pragmatisch und für einfache Projekte durchaus praktikabel, schadet jedoch der Wiederverwendbarkeit und der damit verbundenen notwendigen Isolation von konformen Objekten. Wie kann ein Objekt universell konform sein, wenn seine Nachverfolgbarkeit nachträglich produktspezifisch integriert werden muss?

4 Verifikation im V-Modell
Vereinfachung Zur Förderung der Übersichtlichkeit fassen wir hier einige Blöcke des V-Modells zusammen. Die System- und Software-Architektur  zu einer Geräte-Architektur. Der Software-System-Entwurf und der Modul-Entwurf  zum Software-Entwurf Der Modul- und Integrationstest der Software  zum Software Modul- und Integrationstest Diese Zusammenfassungen dienen allein der Handhabbarkeit der Objekte und stellen keinen Verlust des Detailgrades im Inneren dar. Die folgenden Konzepte und Erläuterungen benutzen dieses leicht vereinfachte V-Modell als Anhaltspunkt.

5 Richtungen/Beziehungen der Nachverfolgbarkeit
Abstraktion Dieses Folie zeigt Möglichkeiten/Beziehungen der Nachverfolgbarkeitsrichtung von Verweisen zwischen einzelnen Dokumenten. Die Blöcke <A>, <B>, [a] und [b] repräsentieren Dokumente, zwischen denen eine Nachverfolgbarkeitsbeziehung besteht. Typischerweise bildet sich die Beziehung der Nachverfolgbarkeit durch die Definition <> und das Referenzieren [] eindeutiger IDs heraus. Diese Beziehung lässt sich auf vier verschiedene Arten darstellen. In Variante (a) wird in Dokument [a] auf Dokument <B> verwiesen. Das heißt, die Existenz von Dokument [a] ist von der Existenz von <B> abhängig. Dokument [a] kann ohne <B> also nicht gültig/freigegeben sein. Die Variante (b) stellt den umgekehrten Fall dar. Hier muss <A> vor [b] existieren. Eine dritte Variante (c) stellt die Einführung einer Referenztabelle dar. In dieser Tabelle wird auf die Anforderungsdefinitionen aus Dokument <A> und <B> verwiesen. Das bedeutet, dass <A> und <B> unabhängig voneinander existent sind und nur über die Referenztabelle miteinander verknüpft sind. Auf diese Weise können die Dokumente getrennt voneinander geschrieben und gültig gesprochen werden. Auch eine Wiederverwendbarkeit der Dokumente wäre möglich, da sie von keinem anderen Dokument abhängen. Zum Schluss noch die vierte Variante (ab), die eine vollständige Abhängigkeit der Dokumente darstellt, da diese in einer einzigen Tabelle bzw. einem einzigen Dokument beschrieben sind. Sie können somit nur zusammen bearbeitet werden und sind nur zusammen gültig. Daraus ergibt sich natürlich ein erhöhter Aufwand bei der Pflege der Dokumente. Die Variante (b) wird häufig als Lösung verstanden, die in Analogie zur Verifikationsrichtung zum eingangs gezeigtem V-Modell als verwendet wird. Aus reiner Projektsicht ist dies auch eine gute normativ gültige Lösung. Die Variante (a) wird gerne angestrebt, wenn man „Vorwärtsverfolgbar“ Anforderungen nachverfolgen können möchte. Dies ist aber schwerlich möglich, da man dann ja „B“ vor „a“ haben müsste und „B“ schwerlich eine Dekomposition von Anforderungen aus „a“ darstellen könnte. Die Variante (ab) kommt heute immer noch in Teilbereichen vor, in denen eine „1:1“-Abbildung von Anforderung und Umsetzung sinnhaft ist, z.B. in Test-Anforderungsdokumenten, die zu Testberichten werden, indem eine Spalte für die Durchführung und das Ergebnis ergänzt wird. Die Variante (c) wird offensichtlich beim toolgestütztem Anforderungsmanagement zumindest teilautomatisiert verwendet. Hier werden beim Schreiben von <A> oder <B> mehr oder weniger händisch Referenzen zugewiesen, die dann an den Stellen <A> und <B> als nachverfolgbare Quer-Referenz automatisiert eingeblendet werden können, ohne das <A> oder <B> modifiziert werden müssen. ANMERKUNG Die Variante (c) kann aus Variante (a) und Variante (b) automatisiert abgeleitet werden z.B. mittels eines simplen ID-Scanner-Makros, welches einfache Erkennungsmerkmalen von <definierenden> und [referenzierenden] Identifiern erkennen und unterscheiden kann.

6 Klassische Nachverfolgbarkeit
IEC , : Zur Verifikation des Entwurfs und der Entwicklung des E/E/PE-Systems muss, nachdem Entwurf und Entwicklung des E/E/PE-Systems (siehe 7.4) fertiggestellt worden sind und bevor die nächste Phase (Integration) beginnt, die Verifikation: ... b) Konsistenz und Vollständigkeit (hinunter bis auf und einschließlich Modulebene) von Entwurf und Entwicklung des E/E/PE-Systems hinsichtlich der Anforderungen an die Sicherheit des E/E/PE-Systems (siehe IEC , 7.10) feststellen ... IEC , Tabelle A.1: Verfahren/Maßnahme Siehe SIL 1 SIL 2 SIL 3 SIL 4 2 Vorwärtsverfolgbarkeit von den Anforderungen an die Sicherheit des Systems zu den Anforderungen an die Sicherheit der Software C.2.11 + ++ 3 Rückwärtsverfolgbarkeit von den Anforderungen an die Sicherheit zu den wahrgenommenen Sicherheitsbedürfnissen Normativer Bezug I In der IEC wird die Vollständigkeit der Anforderungen, die wir als klassische Nachverfolgbarkeit interpretieren, an mehreren Stellen gefordert. Im Band 3 der Norm (Software) wird dies allerdings besonders detailliert gefordert. So wird dort vor allem zwischen einer Vorwärts- und Rückwärtsverfolgbarkeit der Anforderungen differenziert. Ab SIL 3 wird die Vorwärts- und Rückwärtsverfolgbarkeit sogar hochgradig empfohlen. Eine Unterscheidung in Vorwärts- und Rückwärtsverfolgbarkeit detailliert die klassische Frage der Nachverfolgbarkeit um Fragestellungen wie „Wird alles umgesetzt?“ (Vorwärts) und „Ist die Implementierung gefordert?“ (Rückwärts). FRAGE Doch welche Nachverfolgbarkeitsrichtung hat die Vorwärts- und Rückwärtsverfolgbarkeit? (a), (b), (c) oder (ab)?

7 Rückverfolgbarkeit und Wiederverwendbarkeit im Konflikt
IEC , C.2.11 Rückwärtsverfolgbarkeit ist weitgehend mit der Überprüfung beschäftigt, dass jede Implementierungsentscheidung (in einem breiten Zusammenhang und nicht auf die Implementierung des Codes begrenzt zu interpretieren) durch irgendeine Anforderung klar gerechtfertigt wird. Wenn diese Rechtfertigung fehlt, dann enthält die Implementierung etwas Unnötiges, das zur Komplexität beiträgt, sich aber nicht notwendigerweise an irgendeine tatsächliche Anforderung des sicherheitsbezogenen Systems richtet. Rückwärtsverfolgbarkeit ist an mehreren Stellen … nützlich: vom Software Code zum detaillierten Softwareentwurf? Müssen alle Teile der Software in den Anforderungen gefordert sein?? ABER: Wie sind dann wiederverwendbare Komponenten möglich?!? ANMERKUNG Alle Teile einer Software müssen getestet sein! Normativer Bezug II Rückwärtsverfolgbarkeit ist in der IEC beschrieben als Überprüfung der Sinnhaftigkeit der Anforderungen und damit der Rechtfertigung einer jeden Implementierungsentscheidung. Dabei ist zu beachten, dass dies im Wesentlichen nicht nur die Implementierung des Codes, sondern alle Software-Entwurfsschritte betrifft. PROBLEM Häufig wird die Rückwärtsverfolgbarkeit so verstanden, dass in Detaildokumenten wie auch im Code Anforderungsreferenzen auf vorhergehende Entwurfsdokumente enthalten sein müssen, also quasi ein „Rückwärtsverweis“ existiert. Doch durch diese Interpretation wird die Wiederverwendbarkeit der Komponenten stark eingeschränkt. Denn der Sinn der Wiederverwendbarkeit ist es, bereits entwickelte und getestete Komponenten ohne erneute Anpassungen in neuen Systemen verwenden zu können. Eine Anforderungsreferenz im Detaildokument bzw. Source Code müsste bei Wiederverwendung jedoch überarbeitet werden. FRAGE Es stellt sich also die Frage, wie Rückwärtsverfolgbarkeit und Wiederverwendbarkeit in Einklang miteinander gebracht werden können.

8 Rückwärtsverfolgbarkeit und konforme Objekte
Konforme Objekte sind Lösungen, die nachverfolgbar sein müssen Problem: Anforderungsreferenzen in Lösungen/Codierung schaden der Wiederverwendbarkeit Die Richtung der Nachverfolgbarkeit ist nicht entscheidend die Rechtfertigung einer Anforderungen sehr wohl!  in wiederverwendbaren Lösungen dürfen keine Anforderungsreferenzen auftauchen! Nebenbedingungen Wie bemerkt wurde, sollte der Code frei von Anforderungsreferenzen sein, da die Referenzen der Wiederverwendbarkeit schaden. Dennoch sollte für diese Objekte eine Rückwärtsverfolgbarkeit etabliert sein! Das heißt, die Frage nach der Sinnhaftigkeit der Anforderungen und nach der Notwendigkeit der Implementierungen muss beantwortet werden, ohne dass von den Lösungen auf die Anforderungen verwiesen wird. Konforme Objekte werden hier als Realisierungen, Implementierungen, Codierung oder besser gesagt als Lösungen verstanden. Ein konformes Objekt ist also eine Lösung, die in keinem Widerspruch zur Norm stehen sollte. Wenn eine Abweichung zu der Norm bestehen sollte, so muss diese entsprechend begründet sein. Folgende Nebenbedingungen an die Nachverfolgbarkeit von Lösungen können hier festgehalten werden: Um die Wiederverwendbarkeit zu gewährleisten, sollen Lösungen für sich allein existent sein. Für die Rückwärtsverfolgbarkeit soll es zu jeder Lösung mindestens eine geeignete Anforderung geben. Aufgrund der Wiederverwendbarkeit müssen Teile von Lösungen vorhanden sein dürfen, die nicht gefordert sind. Wenn es für einige Teile der Lösung keine Anforderung gibt, sollte dieser Teil der Lösung die Komplexität des Systems nicht nachteilig beeinflussen. WEITERGEHENDE PROBLEMATIK In wiederverwendbaren Lösung dürfen keine Anforderungsreferenzen auftauchen!

9 Rückwärtsverfolgbarkeit im V-Modell
Normativer Bezug III In dieser Abbildung wurde das vereinfachte V-Modell um die Vorwärts- und Rückwärts-verfolgbarkeit, wie sie im Anhang A der Norm Teil 3 gefordert wurde, erweitert. Dabei fällt auf, dass die Richtung der Verifikationspfeile entgegengesetzt zur Richtung der Vorwärtsverfolgbarkeit ist. Des Weiteren ist die Rückwärtsverfolgbarkeit nur an einigen wenigen Stellen normativ gefordert. FESTSTELLUNG Die Richtung der Vorwärts-, Rückwärtsverfolgbarkeit sagt nichts über die Richtung der Nachverfolgbarkeit aus. Auffällig ist, dass für den Quellcode gar keine „Verbindungspfeile“ aus dem Anhang A der Norm Teil 3 bedingt durch die Vorwärts- und Rückwärtsverfolgbarkeit gefunden wurden. Dies verwundert insbesondere, da in der vorherigen Folie (IEC , C.2.11), bei der Rückwärtsverfolgbarkeit „vom Code zum detaillierten Softwareentwurf“ dies scheinbar gefordert wurde.  Das wird von uns derart interpretiert, dass es natürlich einen Zusammenhang zwischen einem Detailentwurf und einer Codierung geben muss, dies jedoch nicht durch Nachverfolgbarkeit in den Code nachgewiesen werden muss. Die richtige Codierung von Anforderungen muss durch den Modul- und Integrationstest nachgewiesen werden! Dies wird dann wohl für die Codierung auch als ausreichender Nachweis angesehen (ANALOGIE: HW-Anforderung <-> Schaltplan <-> HW-Test). Durch eine derartige Interpretation der Vorwärts- und Rückwärtsverfolgbarkeit kann es durchaus Realisierungen (Code-Segmente) geben, die keine Anforderung haben. Das erscheint zunächst unsinnig für ein einzelnes Projekt, zumal dadurch der Code umfangreicher ist als gefordert. Dieser Freiheitsgrad macht aber im Kontext der Wiederverwendbarkeit absolut Sinn, wo durchaus nicht immer alle Funktionalitäten gleichermaßen benötigt werden. FESTSTELLUNG In wiederverwendbaren Lösung brauchen keine Anforderungsreferenzen aufzutauchen!

10 Nachverfolgbarkeit in konforme Objekte
Lösung Doch wie lässt sich das realisieren? Am Anfang des Vortrags sind wir auf verschiedene Beziehungstypen zur Verknüpfung von Dokumenten eingegangen. Und von diesen Beziehungsvarianten eignet sich vor Allem die Variante mit der Referenzentabelle (c) für die Lösung dieser Fragestellung. Durch die Einführung einer Verknüpfungstabelle zwischen Anforderungsdefinition und eingesetzter Lösung lassen sich gleichzeitig die Vorwärts- und die Rückwärtsverfolgbarkeit realisieren. Dabei sind sowohl die Anforderungsdefinition, als auch die Lösung getrennt voneinander bearbeitbar, was der Modularisierung und Wiederverwendbarkeit sehr zuträglich ist. Gleichzeitig muss durch das wechselseitige Referenzieren in der Tabelle nicht auf die Wirksamkeit der Vorwärts- und Rückwärtsverfolgbarkeit verzichtet werden. Konforme Objekte / Lösungen können eindeutige Bezeichner (IDs) für die Umsetzung enthalten, die dann über die Methoden (a) bzw. (c) mit einer Anforderung in Beziehung gesetzt werden können. (eindeutige Bezeichner sind z.B. auch Modulnamen, Funktionsnamen, Konstanten, …) Bedingt durch die Anmerkung, dass die Variante (c) aus (a) und (b) erleichternd automatisiert abgeleitet werden kann, erhält man eine generelle Nachverfolgbarkeit, die mehr Nachverfolgen vermag, als normativ gefordert wurde. Beim Einsatz von Anforderungsmanagement-Tools wird man sich dieser Erleichterung kaum bewusst sein. Jedoch bei händisch gepflegten Dokumenten in kleineren Projekten, wie auch bei dem Tool-Chain-Übergang vom Dokument zum Code bzw. Schaltungsdesign, kann einem diese Erkenntnis sehr viel Aufwand ersparen. Lösung: Konforme Objekte / Lösungen können eindeutige Bezeichner (IDs) für die Umsetzung enthalten, die dann über die Methoden (a) bzw. (c) mit einer Anforderung in Beziehung gesetzt werden können. (Bezeichner sind z.B. Modulnamen, Funktionsnamen, Konstanten, …)

11 Verifikation durch die Norm
Wenn Lösungen frei von Anforderungsreferenzen sein können, dann darf dieses auch nirgends gefordert werden! Beispiel ungenutzter Code: Ist nirgendwo in der Norm als Ausschlusskriterium festgelegt Trägt nicht zur Komplexität der Firmware bei Muss aber getestet sein! Linker-Einstellungen sind normativ nicht festgelegt  Ungenutzter Code darf nach eigenem Ermessen entfernt werden! Verifikation Zur Verifikation der genannten Erkenntnisse möchten wir an dieser Stelle noch einmal auf die IEC eingehen. Wenn, wie wir dargelegt haben, die Lösungen frei von Anforderungsreferenzen sein sollen, so darf dies logischerweise an keiner Stelle in der Norm gefordert sein. Diesbezüglich wurde die Norm durchsucht und wie zu erwarten war, wurde nirgendwo eine entsprechende Passage gefunden. Als Beispiel möchten wir hier Code anführen, der von keiner Anforderung gefordert wird, aber auch nicht genutzt wird. Dieser Code ist in der Software vorhanden, wird aber nicht verwendet und trägt somit nicht zur Komplexität des Systems bei. (Klar ist auch, dass ungenutzter Code trotzdem getestet sein muss, um „integriert“ werden zu dürfen.) In diesem Zusammenhang sagt die Norm auch nichts über mögliche Linker-Einstellungen aus, so dass ungenutzter Code nach Linker-Ermessen automatisiert entfernt werden darf oder nicht.

12 Anforderungen sind lösungsfrei Lösungen sind anforderungsfrei
Resümee Anforderungen sind lösungsfrei Nachverfolgbarkeit ist die Assoziation von Anforderungen und Lösungen. Lösungen sind anforderungsfrei Resümee Für den allgemeingültigen Leitsatz der Anforderungserhebung „Anforderungen sind lösungsfrei“ ergibt sich aus der Wiederverwendbarkeit der Umkehrschluss „Lösungen sind anforderungsfrei“. Über die Nachverfolgbarkeit sollen die Anforderungen und Lösungen miteinander verknüpft werden. Am Besten geschieht dies durch den Einsatz von Referenzentabellen, wodurch die definierenden Dokumente unabhängig bearbeitet werden können. Eine Anforderungs-Bezeichner-Referenzierung ist eine Nachverfolgbarkeit im Sinne der Norm und erlaubt konforme Objekte modular und wiederverwendbar zu entwerfen und umzusetzen. Unabhängig von der IEC ist eine generelle Nachverfolgbarkeit von Anforderungen im Projekt immer empfehlenswert, nicht nur bei der Spezifikation der Sicherheit der Software. Eine transparente Nachverfolgbarkeit unterstützt nachhaltig die Qualität, das Vertrauen und die Zufriedenheit für alle Beteiligten, vom Entwickler über den Projektleiter bis hin zum Auftraggeber und Kunden.

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