Embedded Clean Code im A-SIL-Serienentwicklungsumfeld

Autor: Thomas Winz, softwareinmotion GmbH

Beitrag - Embedded Software Engineering Kongress 2017

 

Jurassic Park [R1]: „Sie haben befürchtet, Tiere zu verlieren, und das Programm ist deshalb so ausgelegt, daß 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.“ Wer kennt nicht unbedachte systementscheidende Anforderungen?

Das zugrundeliegende Referenzprojekt ist die erste selbständige Inhouse-Produktentwicklung eines ASIL-Steuergerätes der 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 Tailoring-Maßnahmen der ISO 26262 zusammengefasst, u.a. "Anforderungen als Test", Risikoarchitektur, TDD, Code-Hygiene, Continuous Test, Deployment Chain und agile HW. Die notwendige Güte des Quellcodes wurde durch embedded Clean Code gewährleistet. Zusätzlich mussten Infrastruktur geschaffen und ISO-Safetyargumente beschrieben werden.

Da alle Tätigkeiten nur der Produktbacklog-Priorisierung 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. [R2] Das Verfahren der kontinuierlichen Innovation (Bild 1, siehe PDF) 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 Modelle [R3] hochqualifizierter Spezialisten kompensierten Projektunsicherheiten, da bei embedded Produkten technische Anforderungen dominieren. Moderne Konsumer-Benutzererlebnisse lassen aber im industriellen Umfeld die Wichtigkeit von fachlichen Anforderungen steigen (siehe Tabelle 1, PDF). Damit wächst das unternehmerische Risiko für technisch versteifte Unternehmen gegenüber agilen Konkurrenten.

Prototypen sind funktionale Hilfsmuster, die vor Entwicklungsbeginn genutzt werden, um Unsicherheiten zu klären (siehe Bild 1, PDF). 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. [R5]

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 HW-Entwicklung

HW-Entwicklungswerkzeuge haben bis vor wenigen Jahren einen agilen Ansatz in der HW-Entwicklung verhindert. Im Allgemeinen lassen sich SW-Unsicherheiten/-Anforderungen im embedded Bereich ohne HW 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 Bunk [R6] haben mit ihrem "agilen HW-Entwicklungskonzept" gezeigt, dass jegliches HW-Feature vorhersagbar und in wenigen Wochen umsetzbar ist. Dazu wird jedes Feature auf einzelne Feature-Platinen ausgelagert und in einen projektspezifischen Entwicklungsrig integriert. Das Hinzufügen, der Austausch und das Refactoring einzelner HW-Features sind somit nur noch von der Produktbacklog-Priorisierung abhängig.

Bild 2 (siehe PDF) zeigt den selbst entwickelten Universal-Teststand. Dieser Teststand nutzt die Entwicklersoftware-Werkzeugkette, um notwendige Fahrzeugeigenschaften wie Bordnetz, K15-Manipulation und weiteres zu emulieren. Auf dieser Basis-Infrastruktur setzt der eigenentwickelte Remote-Laborplatz (Bild 2) auf. Der Remote-Laborplatz 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 und Mock von HW-Funktionen. So wurde die Abstimmung des HW-SW-Interface wesentlich vereinfacht. Mit Hilfe eines einfachen Arduino-Sketch erfolgte die Inbetriebnahme der Referenzfeature-Platine. Somit war bereits vor der Entwicklung der SW-Komponente "Hardware Abstraction Layer" das Verhalten der HW bekannt. Dies führte zu weniger Aufwand in der Entwicklung des darauf aufbauenden SW-Stacks. Fehlende Features der HW konnten frühzeitig identifiziert und bei der Aktualisierung der Referenzfeature-Platine 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. [R7] Zusammen mit dem Product Owner/Projektleitung werden mit Hilfe des Modells "Projektumfeld" (Bild 3, siehe PDF) die Priorisierungen 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." [R8] 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 Refactoring-Wartungsarbeiten ermöglichten ein Hinzufügen von fachlichen Anforderungen als zusammenhängende Funktionsmuster. Dabei sind die systemrelevanten Aufwände der Funktionsmuster-Integration ü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 SW-Features sind somit nur noch von der Produktbacklog-Priorisierung abhängig.

Entwicklung

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

Die obere Werkzeugkette besteht aus normqualifizierbaren SW-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. SW-Werkzeuge der unteren Werkzeugkette sollten den ISO 26262 Tool Confidence Level von TCL 1 besitzen und sind somit von einer Werkzeugqualifikation ausgenommen. [R9]

Durch diese Trennung werden untere SW-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 Sourcecode-Tags erfolgen kann, wurde in Markdown-Dateien ausgelagert. Um auch Anforderungen durch diese Methode zu dokumentieren, muss ein strenger Absichtsnachweis (Verlinkung) erfolgen.

Auslieferung

Der additive SW-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, siehe PDF). [R10]

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 (siehe PDF) zeigt die verschiedenen Verursacher technischer Schuld auf. Nach der Analyse leiten sich die verschiedenen Refactoringmaßnahmen ab. Im Unterschied zum inkrementellen Wasserfall-/V-Modell [R11] werden Refactoring-Wartungsmaß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.

Quellenverzeichnis

 

Beitrag als PDF downloaden

---

Unsere Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Qualität, Safety & Security.

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.

---

Qualität, Safety & Security - Fachwissen

Wertvolles Fachwissen zum Thema Qualität, Safety & Security steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.