Autor: Thomas Winz, softwareinmotion GmbH Jurassic Park [R1]: \u201eSie haben bef\u00fcrchtet, Tiere zu verlieren, und das Programm ist deshalb so ausgelegt, da\u00df es sofort Alarm schl\u00e4gt, wenn es weniger als die erwartete Anzahl sind. Aber das ist gar nicht das Problem. Das bei weitem gr\u00f6\u00dfere Problem ist, dass Sie mehr als die erwartete Anzahl haben.\u201c Wer kennt nicht unbedachte systementscheidende Anforderungen?<\/strong><\/p>\n Das zugrundeliegende Referenzprojekt ist die erste selbst\u00e4ndige Inhouse-Produktentwicklung eines ASIL-Steuerger\u00e4tes der softwareinmotion. Als gleichwertige Stakeholder wurden die Vertriebspartner und externen ISO-Assessoren aufgestellt.<\/p>\n Die Produktentwicklung erfolgte nach Scrum. Unter dem Begriff „additiver Architekturstil“ wurden die umfangreichen agilen Tailoring-Ma\u00dfnahmen der ISO 26262 zusammengefasst, u.a. „Anforderungen als Test“, Risikoarchitektur, TDD, Code-Hygiene, Continuous Test, Deployment Chain und agile HW. Die notwendige G\u00fcte des Quellcodes wurde durch embedded Clean Code gew\u00e4hrleistet. Zus\u00e4tzlich mussten Infrastruktur geschaffen und ISO-Safetyargumente beschrieben werden.<\/p>\n Da alle T\u00e4tigkeiten nur der Produktbacklog-Priorisierung folgen, erm\u00f6glicht unsere agile Einstellung ein erfolgreiches Projekt. Wir konnten unseren extrem unsicheren Projektalltag als lebenswerten und planbaren Raum gestalten.<\/p>\n 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\u00a0PDF<\/a>) besagt, dass Aufw\u00e4nde nur erbracht werden, wenn diese im Projekt die allgemeine „Unsicherheit“ verringern. Das klassische V-Modell wird erweitert. Diese Bewertungsmethode f\u00fcr Erfolg bedeutet einen fundamentalen Unterschied zu „agile aber“- oder klassischen Projektbewertungsmethoden.<\/p>\n 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,\u00a0PDF<\/a>). Damit w\u00e4chst das unternehmerische Risiko f\u00fcr technisch versteifte Unternehmen gegen\u00fcber agilen Konkurrenten.<\/p>\n Prototypen sind funktionale Hilfsmuster, die vor Entwicklungsbeginn genutzt werden, um Unsicherheiten zu kl\u00e4ren (siehe Bild 1,\u00a0PDF<\/a>). Bei der Validierung t\u00e4uschen 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\u00fcnf Tagen beantwortet werden. [R5]<\/p>\n 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\u00f6\u00dfte Herausforderung, gefolgt von verst\u00e4ndlicher Dokumentation. Unklarheiten in der Fragestellung f\u00fchrten zu aufwendigen Prototypen, die dadurch in der verf\u00fcgbaren Zeit keine konkrete Antwort lieferten.<\/p>\n 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\u00e4ren. Die als „Big Bang“ bekannte Methodik, die erst sp\u00e4t im Projekt verschiedene Software- und Hardwareelemente in einem gro\u00dfen Schritt zu einer Komponente oder einem Gesamtsystem integriert, gilt als veraltet.<\/p>\n Dr. Tobias K\u00e4stner 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\u00fcgen, der Austausch und das Refactoring einzelner HW-Features sind somit nur noch von der Produktbacklog-Priorisierung abh\u00e4ngig.<\/p>\n Bild 2 (siehe\u00a0PDF<\/a>) 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\u00f6glichkeit das „Ger\u00e4t unter Entwicklung“ gezielt zu manipulieren. Ein PicoScope rundet die Telemetrie-M\u00f6glichkeiten ab.<\/p>\n Im Referenzprojekt erm\u00f6glichen diese Infrastrukturl\u00f6sungen T\u00e4tigkeiten, die Entwickler im Alltag durchf\u00fchren, 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\u00fchrte zu weniger Aufwand in der Entwicklung des darauf aufbauenden SW-Stacks. Fehlende Features der HW konnten fr\u00fchzeitig identifiziert und bei der Aktualisierung der Referenzfeature-Platine ber\u00fccksichtig werden.<\/p>\n Alle systemrelevanten Entscheidungen \u00fcber das Projekt sind in der Architektur zu treffen. Der Architekt hat die Aufgabe, die Erwartungen der Stakeholder an das Projekt so weit wie m\u00f6glich zu erf\u00fcllen. [R7] Zusammen mit dem Product Owner\/Projektleitung werden mit Hilfe des Modells „Projektumfeld“ (Bild 3, siehe\u00a0PDF<\/a>) die Priorisierungen im Produktbacklog (Projektplanung) vorgenommen.<\/p>\n 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\u00fcssen flexibel bleiben. Ansonsten handelt es sich nicht um ein Projekt, das sich mit der agilen Entwicklung umsetzten l\u00e4sst.“ [R8] Die Projektplanung kann also immer nur eine Kante festlegen und muss den Umfang der zwei verbleibenden Kanten kontinuierlich mit den Stakeholdern kl\u00e4ren.<\/p>\n Im Referenzprojekt wurde diese Einstellung mit dem additiven SW-Architekturstil gelebt. Kontinuierliche Refactoring-Wartungsarbeiten erm\u00f6glichten ein Hinzuf\u00fcgen von fachlichen Anforderungen als zusammenh\u00e4ngende Funktionsmuster. Dabei sind die systemrelevanten Aufw\u00e4nde der Funktionsmuster-Integration \u00fcber die Projektlaufzeit konstant zu halten. Beispiel: Erweiterung der Diagnose um einen Selbsttest zieht kein Rewrite vom Kommunikationstack nach sich. Hinzuf\u00fcgen, Austausch und Refactoring einzelner SW-Features sind somit nur noch von der Produktbacklog-Priorisierung abh\u00e4ngig.<\/p>\n Im Referenzprojekt werden zwei unabh\u00e4ngige Werkzeugketten genutzt (Bild 4, siehe\u00a0PDF<\/a>). \u00a0SW-Werkzeuge der oberen Werkzeugkette sind in der automatischen Jenkins-Deploy-Pipeline eingebunden. Die gleiche Instanz von Jenkins wird zudem f\u00fcr die kontinuierliche Testpipeline genutzt.<\/p>\n Die obere Werkzeugkette besteht aus normqualifizierbaren SW-Werkzeugen, die f\u00fcr Freigabeaufw\u00e4nde 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]<\/p>\n Durch diese Trennung werden untere SW-Werkzeuge nur noch nach ihrem Einfluss auf die Entwicklungsumgebung ausgew\u00e4hlt. Somit konnten Methoden wie TDD und Code-Hygiene die Synergien aktueller Open-Source-Projekte nutzen.<\/p>\n 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.<\/p>\n Der additive SW-Architekturstil setzt gleichbleibende Aufw\u00e4nde der Funktionsmusterintegration \u00fcber die Projektlaufzeit voraus. Carola Lilienthal stellte fest, dass \u00c4nderungen im Sourcecode die technische Schuld erh\u00f6hen (Bild 5, siehe\u00a0PDF<\/a>). [R10]<\/p>\n Technische Schulden sind alle Aufw\u00e4nde, die nicht zu den notwendigen Aufw\u00e4nden der Umsetzung z\u00e4hlen. Die statische Analyse misst diese durch verschiedenste Metriken. Tabelle 2 (siehe\u00a0PDF<\/a>) zeigt die verschiedenen Verursacher technischer Schuld auf. Nach der Analyse leiten sich die verschiedenen Refactoringma\u00dfnahmen ab. Im Unterschied zum inkrementellen Wasserfall-\/V-Modell [R11] werden Refactoring-Wartungsma\u00dfnahmen technischer Anforderungen erwartet.<\/p>\n 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\u00dfnahmen waren somit nur noch von der Produktbacklogpriorisierung abh\u00e4ngig.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2017<\/h3>\n
Extreme Unsicherheiten<\/h2>\n
Agile HW-Entwicklung<\/h2>\n
Architektur<\/h2>\n
Entwicklung<\/h2>\n
Auslieferung<\/h2>\n
Quellenverzeichnis<\/h2>\n