Ein Angebot von

Embedded Clean Code im A-SIL-Serien-Entwicklungsumfeld

| Autor / Redakteur: Thomas Winz* / Sebastian Gerstl

Bild 1: Kontinuierliche Innovation
Bild 1: Kontinuierliche Innovation (Bild: softwareinmotion)

Viele Softwaretests für sicherheitskritische Systeme werden so angelegt, dass sie Alarm schlagen, wenn bestimmte erwartete Probleme auftreten. Was aber, wenn man darüber die unerwarteten Sicherheitslücken aus den Augen verliert? Wie kann man sich agil und flexibel auf überraschende Probleme vorbereiten?

Jurassic Park: „Sie haben befürchtet, Tiere zu verlieren, und das Programm ist deshalb so ausgelegt, dass es sofort Alarm schlägt, wenn es weniger als die erwartete Anzahl sind. Aber das ist gar nicht das Problem. Das bei weitem größere Problem ist, dass Sie mehr als die erwartete Anzahl haben.“1 Wer kennt nicht unbedachte systementscheidende Anforderungen?

Das zugrundeliegende Referenzprojekt ist die erste selbständige inhouse Produktentwicklung eines ASIL-Steuergeräts des Unternehmens softwareinmotion. Als gleichwertige Stakeholder wurden die Vertriebspartner und externen ISO Assessoren aufgestellt.

Die Produktentwicklung erfolgte nach Scrum. Unter dem Begriff „additiver Architekturstil“ wurden die umfangreichen agilen Tailorings-Maßnahmen der ISO 26262 zusammengefasst, u. a.: „Anforderungen als Test“, Risikoarchitektur, TDD, Code Hygiene, continuous Test, Deploymentchain und agile Hardware. Die notwendige Güte des Quellcodes wurde durch embedded Clean code gewährleistet. Zusätzlich musste Infrastruktur geschaffen und ISO-Safety-Argumente beschrieben werden. Da alle Tätigkeiten nur der Produktbacklogpriorisierung folgen, ermöglicht unsere agile Einstellung ein erfolgreiches Projekt. Wir konnten unseren extrem unsicheren Projektalltag als lebenswerten und planbaren Raum gestalten.

Extreme Unsicherheiten

Mit der „lean Startup/Startup Way“ Methode stellte Eric Ries fest, dass die Arbeit am Produkt in einer Entwicklungsabteilung „unter extremen Unsicherheiten“ leidet.2 Das Verfahren der kontinuierlichen Innovation (Bild 1) besagt, dass Aufwände nur erbracht werden, wenn diese im Projekt die allgemeine „Unsicherheit“ verringern. Das klassische V-Modell wird erweitert. Diese Bewertungsmethode für Erfolg bedeutet einen fundamentalen Unterschied zu „agile aber“- oder klassischen Projektbewertungsmethoden.

Mentale Modelle3 hochqualifizierter Spezialisten kompensierten Projektunsicherheiten, da bei embedded Produkten technische Anforderungen dominieren. Moderne Konsumerbenutzererlebnisse lassen aber im industriellen Umfeld die Wichtigkeit von fachlichen Anforderungen steigen (siehe Tabelle 1). Damit wächst das unternehmerische Risiko für technisch versteifte Unternehmen gegenüber agilen Konkurrenten.4

Prototypen sind funktionale Hilfsmuster, die vor Entwicklungsbeginn genutzt werden, um Unsicherheiten zu klären (siehe Bild 1). Bei der Validierung täuschen diese Platzhalter das Produktverhalten vor. Im hochsicherheitskritischen Umfeld beginnt der Lebenszyklus eines ASIL Produktes als abstraktes Systemmodell der Sicherheitsanalyse. Der Prozess SPRINT beschreibt, wie projektkritische Unsicherheiten innerhalb von fünf Tagen beantwortet werden.5

Im Referenzprojekt wurden Prototypen intensiv genutzt, beispielsweise: Excel, VBA Skripte, Arduino Sketch, Dev. Kits, QT und Paint. Die Formulierung einer soliden Frage war dabei die größte Herausforderung, gefolgt von verständlicher Dokumentation. Unklarheiten in der Fragestellung führten zu aufwendigen Prototypen, die dadurch in der verfügbaren Zeit keine konkrete Antwort lieferten.

Agile Hardware-Entwicklung

Hardware-Entwicklungswerkzeuge haben bis vor wenigen Jahren einen agilen Ansatz in der Hardwarerntwicklung verhindert. Im Allgemeinen lassen sich Software-Unsicherheiten/Anforderungen im embedded Bereich ohne Hardware nicht klären. Die als „Big Bang“ bekannte Methodik, die erst spät im Projekt verschiedene Software- und Hardwareelemente in einem großen Schritt zu einer Komponente oder einem Gesamtsystem integriert, gilt als veraltet.

Dr. Tobias Kästner und Mario Bunk6 haben mit ihrem „agilen Hardware-Entwicklungskonzept“ gezeigt, dass jegliches Hardware-Feature vorhersagbar und in wenigen Wochen umsetzbar ist. Dazu wird jedes Feature auf einzelne Featureplatinen ausgelagert und in einen projektspezifischen Entwicklungsrig integriert. Das Hinzufügen, der Austausch und das Refactoring einzelner Hardware-Features sind somit nur noch von der Produktbacklogpriorisierung abhängig.

Bild 2 zeigt den selbst entwickelten Universalteststand. Dieser Teststand nutzt die Entwicklersoftwarewerkzeugkette, um notwendige Fahrzeugeigenschaften wie Bordnetz, K15 Manipulation und weiteres zu emulieren. Auf dieser Basisinfrastruktur setzt der eigenentwickelte Remotelaborplatz (Bild 2) auf. Der Remotelaborplatz bietet die Möglichkeit das „Gerät unter Entwicklung“ gezielt zu manipulieren. Ein PicoScope rundet die Telemetrie-Möglichkeiten ab.

Im Referenzprojekt ermöglichen diese Infrastrukturlösungen Tätigkeiten, die Entwickler im Alltag durchführen, u. a.: Langzeittests, Mock von Hardware-Funktionen. So wurde die Abstimmung des Hardware-Software-Interface wesentlich vereinfacht. Mit Hilfe eines einfachen Arduino Sketch erfolgte die Inbetriebnahme der Referenzfeatureplatine. Somit war bereits vor der Entwicklung der Software-Komponente „Hardwareabstractionlayer“ das Verhalten der Hardware bekannt. Dies führte zu weniger Aufwand in der Entwicklung des darauf aufbauenden Software-Stack. Fehlende Features der Hardware konnten frühzeitig identifiziert und bei der Aktualisierung der Referenzfeatureplatine berücksichtig werden.

Architektur

Alle systemrelevanten Entscheidungen über das Projekt sind in der Architektur zu treffen. Der Architekt hat die Aufgabe, die Erwartungen der Stakeholder an das Projekt so weit wie möglich zu erfüllen.7 Zusammen mit dem Productowner/Projektleitung werden mit Hilfe des Modells „Projektumfeld“ (Bild 3) die Priorisierung im Produktbacklog (Projektplanung) vorgenommen.

Agile Projekte unterscheiden sich auch hier wesentlich zu „agile aber“- oder klassischen Projekten. Einen Grund hat Debbie Madden 2014 genannt: „Ein echtes Agile Software-Entwicklungsprojekt kann nur eine Dreieckskante festgelegen. Die beiden anderen Kanten müssen flexibel bleiben. Ansonsten handelt es sich nicht um ein Projekt, das sich mit der agilen Entwicklung umsetzten lässt.“8 Die Projektplanung kann also immer nur eine Kante festlegen und muss den Umfang der zwei verbleibenden Kanten kontinuierlich mit den Stakeholdern klären.

Im Referenzprojekt wurde diese Einstellung mit dem additiven SW-Architekturstil gelebt. Kontinuierliche Refactoringswartungsarbeiten ermöglichten ein Hinzufügen von fachlichen Anforderungen als zusammenhängende Funktionsmuster. Dabei sind die systemrelevanten Aufwände der Funktionsmusterintegration über die Projektlaufzeit konstant zu halten. Beispiel: Erweiterung der Diagnose um einen Selbsttest zieht kein Rewrite vom Kommunikationstack nach sich. Hinzufügen, Austausch und Refactoring einzelner Software-Features sind somit nur noch von der Produktbacklogpriorisierung abhängig.

Entwicklung

Im Referenzprojekt werden zwei unabhängige Werkzeugketten genutzt (Bild 4). Software-Werkzeuge der oberen Werkzeugkette sind in der automatischen Jenkins-Deploypipeline eingebunden. Die gleiche Instanz von Jenkins wird zudem für die kontinuierliche Testpipeline genutzt.

Die obere Werkzeugkette besteht aus normqualifizierbaren Software-Werkzeugen, die für Freigabeaufwände von Auslieferungen genutzt werden. Die Vereinfachung der ISO 26262 Werkzeugqualifikation setzt voraus, dass die obere Werkzeugkette nicht auf Produkte der unteren Werkzeugkette aufbaut. Software-Werkzeuge der unteren Werkzeugkette sollten den ISO 26262 tool confidence level von TCL 1 besitzen und sind somit von einer Werkzeugqualifikation ausgenommen.9

Durch diese Trennung werden untere Software-Werkzeuge nur noch nach ihrem Einfluss auf die Entwicklungsumgebung ausgewählt. Somit konnten Methoden wie TDD und Code Hygiene die Synergien aktueller Open-Source-Projekte nutzen.

Um dem Dokumentationsaufwand sicherheitskritischer Produkte gerecht zu werden, werden alle Architekturinformationen mit dem Werkzeug „Doxygen“ aggregiert. Die Dokumentation, welche nicht in Sourcecodetags erfolgen kann, wurde in Markdown Dateien ausgelagert. Um auch Anforderungen durch diese Methode zu dokumentieren, muss ein strenger Absichtsnachweis (Verlinkung) erfolgen.

Safety@ESE Kongress 2018 Das Seminar Funktionale Sicherheit – Basiswissen und Normen am 7. Dezember 2018 ist eines von zwölf Kompaktseminaren auf dem diesjährigen ESE Kongress. Aktuelle Aspekte zum Thema Safety werden außerdem am Vortrag in einer eigenen, ganztätigen Vortragsreihe betrachtet. Alle Infos zum Programm

Auslieferung

Der additive Software-Architekturstil setzt gleichbleibende Aufwände der Funktionsmusterintegration über die Projektlaufzeit voraus. Carola Lilienthal stellte fest, dass Änderungen im Sourcecode die technische Schuld erhöhen (Bild 5).10

Technische Schulden sind alle Aufwände, die nicht zu den notwendigen Aufwänden der Umsetzung zählen. Die statische Analyse misst diese durch verschiedenste Metriken. Tabelle 2 zeigt die verschiedenen Verursacher technischer Schuld auf. Nach der Analyse leiten sich die verschiedenen Refactoringmaßnahmen ab. Im Unterschied zum inkrementellen Wasserfall-/V-Modell11 werden Refactoringwartungsmaßnahmen technischer Anforderungen erwartet.

Im Referenzprojekt wurde zum Auslieferungszeitpunkt die technische Schuld ermittelt. Der Architekt, Lead Dev und Integrator bewerteten rollenrelevante technischen Schulden. Das Ziel vom gleichbleibenden Integrationsaufwand wird gelebt. Notwendige Refactoringmaßnahmen waren somit nur noch von der Produktbacklogpriorisierung abhängig.

Dieser Beitrag stammt aus dem Tagungsband des Embedded Software Engineering Kongress 2017. Vielen Dank für die freundliche Genehmigung des Autors für die Publikation.

Quellenverzeichnis (Titel, Autor/Link)

[1] Dino Park: Michael Crichton

[2] The Startup Way: http://www.thestartupway.com

Lean Startup: http://theleanstartup.com

[3] Smarter Faster Better: Charles Duhigg, Kapitel 3: „3. Fokus“

[4] Agile in Automotive: http://www.euroforum.de/agile-automotive

[5] SPRINT: http://www.gv.com/sprint/, https://www.amazon.de/Sprint-Tagen-Ideen-testet-Probleme/dp/3868816380

[6] SQ Magazin Ausgabe 44, Agilität: https://www.asqf.de

[7] Stakeholdererwartungen: https://de.wikipedia.org/wiki/Projektmanagement#Stakeholdererwartungen

[8] agile Contract: https://www.stridenyc.com/blog/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams

[9] Confidence in the use of software tools: Confidence in the use of software tools

[10] Langlebige Software-Architekturen: Carola Lilienthal

[11] Wasserfallmodell: https://de.wikipedia.org/wiki/Wasserfallmodell

* Thomas Winz war bis Mitte 2018 bei der softwareinmotion gmbh Softwareentwickler im Automotive-Bereich und Consultant. Nun arbeitet er für die Automotive Lighting GmbH Reutllingen als Projektleiter Software.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45507367 / Agilität)