Die Kluft überbrücken
Das Zusammenspiel von agilen Methoden und Sicherheitssystemen
Die Anwendung agiler Methoden auf ein Softwareprojekt, das funktionale Sicherheit erfordert, klingt wie ein Widerspruch. Dennoch gibt es Möglichkeiten, diese beiden Ansätze zusammenzubringen. Dieser Artikel ist ein Erfahrungsbericht, der auf zwei realen Projekten basiert.
Der Entwicklungsprozess für Sicherheitsprojekte ist in verschiedenen Sicherheitsnormen definiert, zum Beispiel IEC 61508 (Funktionale Sicherheit elektrischer/elektronischer/programmierbarer elektronischer sicherheitsbezogener Systeme), ISO26262 (Straßenfahrzeuge - Funktionale Sicherheit) und EN 50128 (Bahnanwendungen). Auf der Grundlage von IEC 61508 »Teil 3: Softwareanforderungen« wird ein Entwicklungszyklus nach dem V-Modell empfohlen, der den logischen Prozess von den Top-Level-Anforderungen bis zur Validierung zeigt (Bild 1).
Jobangebote+ passend zum Thema
Dieser Prozess muss ebenfalls, wie das weit verbreitete Wasserfallmodell, von Anfang bis Ende durchlaufen werden. Die Anforderungen werden vordefiniert, was zu einer darauf basierenden Softwarearchitektur führt. Anschließend werden die Softwaremodule entwickelt, implementiert und getestet, bevor der Gesamtprozess mit der Durchführung von Integrationstests und der endgültigen Validierung abgeschlossen wird.
Im Vergleich dazu gibt es viele verschiedene agile Ansätze und Methoden, die jedoch alle darauf abzielen, schnell auf geänderte Anforderungen zu reagieren und neue Lieferungen an den Kunden vorzunehmen. Wie es im »Agilen Manifest« heißt: »Begrüßen Sie sich ändernde Anforderungen, auch spät in der Entwicklung. Agile Prozesse nutzen den Wandel zum Wettbewerbsvorteil des Kunden.«
Häufige Änderungen können jedes Projekt gefährden
Die Änderung einer Anforderung in einem Sicherheitsprojekt hat jedoch ihren Preis: Man durchläuft das gesamte V-Modell erneut. Daher werden häufige Änderungen, wie im Manifest angegeben, den Aufwand explodieren lassen und möglicherweise das Projekt gefährden. Verbietet dies nun die Anwendung agiler Methoden in Sicherheitsprojekten?
In Wirklichkeit lässt sich diese Frage nicht mit einer allgemeinen Aussage beantworten. In manchen Fällen sind agile Methoden nicht anwendbar, in anderen wiederum bieten sie echte Vorteile. Tatsächlich haben agile Methoden nach einigen Anlaufschwierigkeiten dazu beigetragen, dass das gelieferte Produkt von höherer Qualität ist und den Anforderungen des Kunden genau entspricht. In diesem Artikel werden zwei Projekte aus der Praxis vorgestellt, die die Erfahrungen des Autors bei der Durchführung von Sicherheitsprojekten mit agilen Methoden zeigen.
Sicherheitsmethoden und Umsetzung
Wenn man sich die Sicherheitsnormen ansieht, stellt man fest, dass sie nicht die Reihenfolge vorgeben, in der die verschiedenen Phasen des V-Modells abgeschlossen werden müssen, sondern nur, dass es eine klare Rückverfolgbarkeit geben muss, das heißt der gesamte Weg von den Anforderungen über die Architektur und den Entwurf bis hin zu den Testergebnissen muss schlüssig sein. Sowohl die Anforderungen als auch die Tests müssen für jede Zeile des Codes nachvollziehbar sein. Darüber hinaus verbieten die Sicherheitsnormen nicht die Erstellung von Zwischenlieferungen, die nicht zertifiziert sind.
In den vorgestellten Projekten wurden überwiegend Scrum-Methoden verwendet, und die DevOps-Methoden umfassten kontinuierliche Integration und kontinuierliche Bereitstellung (continuous integration / continuous deployment; CI/CD) sowie Softwarekonfigurationsmanagement (software configuration manager; SCM) unter Verwendung agiler Tools wie Jira, Gitlab und Jenkins. Weitere Tools, die in diesen Projekten eingesetzt werden, sind:
- Green Hills Compiler (hinsichtlich funktionaler Sicherheit zertifiziert)
- Green Hills Debugger (Bild 2)
- Einheit/Modul Test Tool
- UML-Entwurfswerkzeug
- Tool zur Anforderungsverfolgung
Jedes Teammitglied musste zu Beginn des ersten Projekts in den neuen Methoden geschult werden, es sei denn, es hatte diese Methoden bereits zuvor angewendet. Es wurde beschlossen, zwei- oder dreiwöchige Sprints zu verwenden, mit Sprint Planning, Sprint Demo und Sprint Retrospective. Mit Hilfe von Jenkins und Gitlab wurde eine CI-Umgebung eingerichtet, die alle Tests automatisch von Beginn der Projekte an ausführt.
Es wurden klare Rollen für Architekten, Konstrukteure, Tester usw. definiert. Aufgrund der Erfahrungen mit früheren Sicherheitsprozessen wurde für jedes Modul oder jede Komponente die Rolle eines Komponentenmanagers (component manager; CM) festgelegt, der für die jeweilige Komponente verantwortlich war. Dieser CM hatte die vollständige Kontrolle über und die Verantwortung für den unteren Teil des V-Modells. Der Komponentenmanager entwirft, implementiert und testet also eine Komponente in eigener Verantwortung. Diese Entwicklung erfolgte inkrementell, und der Ansatz wurde Mini-V genannt.
Mini-V unterstützt agile Entwicklung
Die Arbeit an diesen Mini-Vs konnte besonders gut auf agile Weise abgewickelt werden. Die Durchführung des Modultests war in diesem Fall nicht unabhängig von der Implementierung, aber da es sich um White-Box-Tests handelt und der Eigentümer der Komponente deren Funktionalität am besten kennt, besteht kein Mehrwert in einer Forderung nach unabhängigen Tests. Ein unabhängiger Tester, der die Idee und das Konzept der Komponente nicht kennt, könnte sogar bestimmte Eckfälle des Moduls nicht erkennen und würde das Modul nicht gut genug testen.
Zusätzlich zum Komponentenmanager hat jede Komponente einen Backup-Komponentenmanager (backup component manager; BCM). Die Aufgabe des BCM besteht darin, jede vom CM vorgenommene Änderung zu überprüfen, sei es in der UML, im Code oder im Test, und bei Bedarf Korrekturen vorzunehmen. Auf diese Weise wird jede Codeänderung vor dem Zusammenführen implizit überprüft, und es gibt immer einen zweiten oder Backup-Experten für jede Komponente, der in der Lage ist, die Komponente im Falle der Abwesenheit des CMs zu warten. Die Tests auf Systemebene und die Validierungstests müssen von unabhängigen Testern durchgeführt werden, die vorzugsweise in einem anderen Büro angesiedelt sind, um die Unabhängigkeit der Tests zu gewährleisten.
Projekt 1: Board Support Package
Das erste Projekt war die Entwicklung eines Board Support Package (BSP) im Auftrag eines Kunden. Das BSP musste nach ISO 26262 ASIL-B zertifiziert werden, aber der Kunde verfügte zu Beginn des Projekts nicht über eine klare Liste von Anforderungen an das Sicherheits-BSP, die als Ausgangspunkt für das V-Modell hätte dienen können. Außerdem verlangte der Endkunde die Anwendung agiler Methoden für dieses Projekt, was zu einer gewissen Skepsis innerhalb des Projektteams führte.
Es wurde beschlossen, dass das Team dem Kunden so schnell wie möglich ein funktionierendes, aber nicht zertifizierbares BSP liefern würde, damit er mit der Entwicklung bzw. Portierung seiner Teile des Systems beginnen konnte. Danach wurden schrittweise mehr und mehr Einzelkomponenten ausgewählt, die dann gemäß den Normen für funktionale Sicherheit entwickelt wurden. Sobald diese aktualisierten Module fertig waren und die zugehörigen Modultests erfolgreich waren, wurden sie im Rahmen eines neuen Sprints an den Kunden ausgeliefert. Der Kunde gab zu jeder Sprintlieferung so schnell wie möglich Feedback, zum Beispiel ob die neue Implementierung des Moduls den Anforderungen des Kunden entsprach. Erst für die endgültige Lieferung, die in die Zertifizierung ging, mussten alle Nachweise gemäß den Sicherheitsstandards vorliegen.
Das Projekt begann im Mai 2018, ein Kick-off-Meeting aller Beteiligten (Kunden, Endkunden/Auftraggeber, Hardware-Lieferanten usw.) fand im Juli 2018 statt, die erste Lieferung des BSP (Sprint 12) wurde im August 2018 durchgeführt und die letzte Lieferung im Juli 2021 (Sprint 87) abgeschlossen. Das Zertifikat und der Bewertungsbericht konnten dann einige Monate später an den Kunden übergeben werden.
Separation Kernel zur Linderung des Zertifizierungsschmerzes
Glücklicherweise verwendete der Kunde einen Separation Kernel, in diesem Fall das INTEGRITY-Echtzeitbetriebssystem von Green Hills Software, mit dem sicherheitskritische und nicht sicherheitskritische Software ohne Interaktion auf derselben Hardware ausgeführt werden können. Daher brauchten viele der Treiber nicht vollständig zertifiziert zu werden, wenn sie nur im unprivilegierten Benutzermodus der CPU ausgeführt wurden. Dies ermöglichte auch die Durchführung weiterer Sprintlieferungen mit Updates der nicht sicherheitskritischen Software, selbst nach dem Einfrieren des sicherheitskritischen Teils.
Im Laufe der Zeit wurden in zweiwöchigen Abständen neue Lieferungen durchgeführt, bei denen neue Komponenten unterstützt wurden oder bei denen einzelne Komponenten schrittweise entsprechend dem Sicherheitsprozess entwickelt wurden.
Nach jeder Lieferung hatte der Kunde Zeit, eine Rückmeldung zu geben, ob die neue Lieferung in das Gesamtsystem passt, ob die Leistungsanforderungen erfüllt wurden und ob ein spezieller Anwendungsfall berücksichtigt werden konnte. Falls erforderlich, wurde das Kundenfeedback genutzt, um Teile des BSP anzupassen oder neu zu implementieren und diese Änderung in den folgenden Sprints zu liefern. Während des Projekts wurden vom Kunden sogar explizit Änderungen an einzelnen Features und die Unterstützung neuer, noch nicht geplanter Hardware gefordert. Da die agile Arbeitsweise inzwischen sehr gut etabliert war, konnte auf diese Änderungen recht gut reagiert werden. Mit anderen Worten: Ohne eine agile Vorgehensweise hätte dies wahrscheinlich viel mehr Aufwand verursacht, und das Feedback wäre nicht so zeitnah gewesen wie hier.
Projekt 2: Echtzeit-Betriebssystem (RTOS)
Aufgrund der guten Erfahrungen, die im Rahmen des BSP-Projekts gemacht wurden, wurde beschlossen, auch beim nächsten großen Sicherheitsprojekt eine agile Methodik anzuwenden. Im Mittelpunkt dieses Projekts stand ein Microkernel-RTOS für Mikrocontroller, das bisher nur in einer nicht zertifizierten Version existierte und nun als Safety Element-out-of-Context (SEooC) bis zur höchstmöglichen Stufe zertifiziert werden sollte. Geplant war, ISO26262 ASIL D und IEC61508 SIL3 zu erreichen. Es gab bereits einen funktionalen Prototyp des RTOS, und es war geplant, während des Projekts Folgendes zu erreichen:
- Hinzufügen von Unterstützung für neue Hardware-Architekturen
- Hinzufügen neuer Funktionen (z. B. MPU-Unterstützung)
- Änderung des API-Umfangs im Vergleich zum Vorgänger-RTOS
- Sicherheitskonforme Entwicklung der (vorhandenen) RTOS-Funktionen
Im Gegensatz zum BSP-Projekt war absehbar, dass es keinen einzelnen Kunden gab, der plötzlich seine Anforderungen ändern würde oder ohne Vorwarnung neue Hardware liefern bzw. anfordern wollte. Dennoch entschied man sich dafür, keinen starren, sequenziellen V-Modell-Prozess zu verwenden, sondern wieder agile Methoden einzusetzen. Mehrere Kunden wollten vor der endgültigen Zertifizierung Engineering-Releases erhalten, und es wurde davon ausgegangen, dass etwa eine Lieferung alle sechs Monate erforderlich sein würde.
Bevor die Zertifizierung des Endprodukts erfolgte, wurden die ersten Releases ohne Zertifizierung durchgeführt. In dieser Hinsicht war der agile Ansatz ebenfalls hilfreich, und die meisten Aspekte der BSP-Projektentwicklung (z. B. CI/CD, DevOps) wurden ebenfalls angewendet. Außerdem wurde das Projekt mit einer nicht zertifizierten Codebasis begonnen, die kontinuierlich durch Code ersetzt wurde, der nach funktionalen Sicherheitsstandards entwickelt wurde.
Als besondere Herausforderung wurden während des Projekts die Sicherheitsprozesse angepasst und optimiert, das heißt es wurden neue Checklisten erstellt und die Dokumentationsanforderungen erweitert, was sich letztlich auch auf die in diesem Projekt angewandten Prozesse auswirkte. Dies verursachte natürlich zunächst zusätzlichen und unerwarteten Aufwand, war aber im Rahmen der agilen Entwicklung leicht umzusetzen.
Agiles Vorgehen kann zum Scheitern führen, nicht-agiles Vorgehen auch!
Ohne den agilen Ansatz wäre das BSP-Projekt wahrscheinlich gescheitert, oder es hätte zumindest große Probleme mit dem Kunden gegeben. Wenn man also mit unklaren Anforderungen oder Kunden, die sehr frühe Lieferungen verlangen, startet, kann ein agiles Vorgehen sehr hilfreich sein. Die Mini-V-Zyklen für die Modulentwicklung und -prüfung haben sich als sehr erfolgreich erwiesen. Insbesondere die Tatsache, dass es einen Komponentenmanager und einen Backup-Manager gibt, hat die Qualität der Lieferungen erheblich gesteigert und die Zahl der Validierungsfehler am Ende des Projekts deutlich verringert.
Beide Projekte begannen mit der Entwicklung eines Prototyps (oder der Prototyp war bereits verfügbar), und dann wurde ein großer Teil des Codes verworfen und neu geschrieben. Was sich wie eine Verschwendung von Ressourcen anhören mag, hat im Nachhinein zu einem besseren Ergebnis geführt. Wenn das Verwerfen und Neuschreiben des Codes zu einer besseren Qualität und damit zu zufriedeneren Kunden führt, dann werden Sie sich diesen zusätzlichen Aufwand gegen Ende des Projekts wahrscheinlich sparen.
Fazit
Die selektive Anwendung agiler Methoden in Projekten zur Zertifizierung der funktionalen Sicherheit funktioniert, wenn man sicherstellen kann, dass das Endprodukt nach dem V-Modell rückverfolgbar ist, das heißt wenn alles von den Anforderungen bis zur Validierung rückverfolgbar ist. Agiles Arbeiten ist jedoch keineswegs eine Rechtfertigung für chaotisches Projektmanagement. Es ist zwingend erforderlich, Trends im Projekt frühzeitig zu erkennen und dafür zu sorgen, dass die richtigen agilen Methoden an den richtigen Stellen eingesetzt werden, um das Chaos unter Kontrolle zu halten.
Der Autor
Andre Schmitz
begann seine Karriere bei der Fraunhofer-Gesellschaft mit der Entwicklung von Steuerungs- und Simulationssoftware für autonome Roboter. Später arbeitete der Diplom-Physiker an UMTS-Kommunikationssystemen bei Infineon Technologies. Seit 2005 ist Schmitz als Senior Field Applications Engineer für Green Hills Software tätig und bietet Schulungen und technischen Support für Kunden an.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Zonenbasierte Power-Architektur
Die Ansteuerung kapazitiver Verbraucher
Timing-Analyse
Software-Tracing-Lösung für Embedded-Systeme
Zertifiziert nach ISO 26262 ASIL D
HighTec-C/C++-Compiler für Infineon Aurix TC4xx und TC3xx
