Ein Angebot von /

Functional Safety Software Engineering: Problemfälle Prozesse & Qualität

| Autor / Redakteur: Dr. Joachim Schlosser* / Sebastian Gerstl

Automotive SPICE und die ISO 26262

Mit Automotive SPICE, seit jüngstem vorliegend in der Fassung 3.1 [2] und gemessen anhand der ISO 33020 [3], liegt ein Prozessreifegradmodell (engl. Process Maturity Model) vor, das bei der Bewertung von Entwicklungsprozessen hilft. Wer produktiv im Automobilsektor verwendete Systeme entwirft, kommt um Lektüre und Umsetzung dieser Norm nicht herum – eigentlich.

Die ISO/IEC 33020 legt bestimmte capability levels, also Ebenen der einzelnen Fähigkeiten fest, die in Summe zu einem bestimmten Reifegrad führen sollen. Dabei kommen in verschiedensten Entwicklungsprozess-Schritten eine Vielzahl von Forderungen zum Tragen.

Schon allein die Prozesslandkarte in Abbildung 1 (siehe Bildergalerie) macht deutlich, dass der Wirkungsbereich von Automotive SPICE nach ISO 33020 sehr weit reicht. Tatsächlich alle acht Arbeitsfelder ACQ, SYS, SWE, SUP, SPL, MAN, REU, PIM sind direkt relevant für die Qualität des auszuliefernden Systems. Dazu kommen in Automtive SPICE 3.1 noch zwei weitere Felder für Hardware und Mechanik.

Wer in die Übersicht der ISO 26262 in der 2018 erscheinenden zweiten Ausgabe in Abbildung 2 blickt, stellt fest, dass auch hier einige ähnlich lautende Prozessfelder verortet sind. Die für die System- und Softwareentwicklung relevanten Teile lassen sich nun in Überdeckung bringen, im ersten Schritt auf der Prozess- bzw. Kapitelebene.

Die Ergebnisse der tiefergehenden Abbildung von Automotive SPICE auf ISO 26262 und in Gegenrichtung zeigen eine mittlere bis gute Abdeckung für alle For-derungen der ISO 26262, bei denen „Funktionale Sicherheit“ nicht vornehmlich auf Architektureigenschaften abzielt.

Dass die Abbildung von ISO 26262 und Automotive SPICE aufeinander sinnvoll ist, weil erhebliche Überschneidungen bestehen, zeigen auch die Arbeiten im Rahmen des SOQRATES-Projekts [5] oder vergleichenden Studien [6].

Pragmatische Wirksamkeit: Prozessfelder unterscheiden

Ein Großteil dessen, was in der ISO 26262 steht, sind also eher allgemeine Qualitätsanforderungen, die sich so auch in Automotive SPICE finden.

Um was es hier größtenteils geht, ist „QM-Software“, die einfach nur ordentlich entwickelt werden soll. Entwicklung besteht eben nicht nur darin, Code hinzuschreiben, der etwas tut, sondern die wohldefinierte Vorgehensweise von Erfassung und Analyse der Anforderungen bis zu Integration und Test, und das ganze so nachvollziehbar, dass auch Jahre später noch herausgefunden werden kann, wie die Software und das System zustande kamen, mit welcher Qualität und auf Basis welcher Anforderungen und Entscheidungen.

Deshalb empfiehlt dieser Beitrag, die Anforderungen der ISO 26262 in zwei Prozessfelder zu unterscheiden.

1. Anforderungen hinsichtlich Funktionalität und Architektur

Hier geht es um funktionale Anforderungen und die Architektur des Systems. Dies beinhaltet eben nur die Anteile, die sich aus den besonderen sicherheitsrelevanten Anwendungsfällen ergeben. Hier sind Methoden zu verorten wie ASIL-Einstufung und sich daraus ergebende Sicherheitsanforderungen, verbunden mit den sich daraus ergebenden Anforderungen an die System- und Softwarearchitektur.

Die ISO 26262 fordert also inhaltliche Arbeit. Analysen sind vorgeschrieben, ein intensives Sich-Gedanken-Machen, wie denn das System bei Ausfall wichtiger Komponenten reagieren soll. Als Nachweis dieser Analysen und Gedanken stehen die „Work Products“ im Fokus, und positiv betrachtet als Arbeitshilfen.

Statt sich also zu beschweren, man müsse jetzt nur wegen der ISO mehr machen, lohnt es sich, oben nochmal nachzusehen, wozu wir Funktionale Sicherheit machen.

Das, was hier gemacht wird, ist tatsächlich eine direkte Folge der Einführung der Norm zur Funktionalen Sicherheit für bestimmte Funktionalitäten im Automobil, und bedeutet im Vergleich zu Entwicklung nicht sicherheitsgerichteter Systeme einen Mehraufwand.

Der Mehraufwand fällt zum großen Teil in der frühen Phase eines Systems an, in der Architektur und Design entworfen werden. Außer, und das ist ein großes „außer“, wenn die leider immer wieder anzutreffende „nachgelagerte Dokumentation“ oder noch härter „nachgelagerte FuSi“ praktiziert werden. Dann ist die ISO 26262 für alle Entwickler ein Riesenstress.

2. Anforderungen hinsichtlich Prozess und Qualität

Ein großer Teil der ISO 26262 verlangt jedoch Prozesse und deren Dokumentation, die sich nicht direkt mit der Funktionalität eines Systems auseinandersetzen. Stattdes-sen steht die Qualität im Fokus, und der Weg dahin. Den Forderungen liegen folgende Paradigmen zugrunde:

  • Absichtlichkeit (Intentionality),
  • Wiederholbarkeit (Reproducibility),
  • Nachverfolgbarkeit (Traceability).

Wie strikt die Paradigmen einzuhalten sind, hängt auch vom ASIL, dem Safety Integrity Level ab, also wie sicherheitskritisch ein System eingestuft ist.

Was sich in Entwicklungsorganisationen nach wie vor häufig findet, sind Vorgehensweisen, die eben mehrere oder gar viele der Paradigmen verletzen:

Da werden Softwarereleases mit viel manueller Arbeit aus schlecht gepflegten Versionierungssystemen erstellt, und wenn der Kunde einige Wochen später einen Fehler in einem bereits ausgelieferten Release meldet, schafft man es schwer bis gar nicht, das damalige Release nochmal exakt nachzubauen. Da werden Tests durchgeführt oder auch nicht, ohne Aufzeichnung welche gelaufen sind und mit welchem Ergebnis. Da ist ohne erheblichen Invest von Lebenszeit nicht mehr herauszufinden, wie sich die Ergebnisse und die Abdeckung durch Tests im Verlauf der Entwicklung verändern. Da werden Programmierregeln missachtet, aber entweder kein Werkzeug zur Codeanalyse eingesetzt oder die Regelverletzungen nicht systematisch ausgewertet. Da wer-den neue Features eingebaut auf Zweigen in der Versionierung, die auf einem zweifelhaften Stand der Softwareentwicklung aufbauen. Da werden Algorithmen und Strukturen im Code verwendet, ohne dass ersichtlich wäre, auf Basis welcher Anforderungen dies geschieht und ohne Chance herauszufinden, welche Tests diese abprüfen.

Das alles hat jedoch nur bedingt mit der funktionalen Sicherheit zu tun, hier geht es um Software Craftsmanship. Im Software Craftsmanship Manifesto [7], das auf die Aspekte des Handwerks von Software hinweist, heißt es beispielsweise: „Nicht nur funktionierende Software, sondern auch gut gefertigte Software.“

Nicht zufällig finden sich sowohl in Automotive SPICE als auch ISO 26262 Anforderungen an den Entwicklungsprozess, die auf gut gefertigte Software abzielen.

Software, bei der jeder Entwickler, jeder Tester, jeder daran beteiligte Ingenieur stolz sagen kann: „Ja, das habe ich gemacht. Heben Sie ruhig den Teppich hoch, auch darunter ist ordentlich gearbeitet. Ich bin stolz darauf und mir sicher, dass Sie, lieber Kunde, lange Freude daran haben werden.“

Was die Qualitätsanforderungen bringen sollen, ist nicht weniger als genau das: Qualität. Qualität, die Folgekosten in der Wartung reduziert. Qualität, die die Beteiligten strahlen lässt. Qualität, die sich im Kontext funktional sicherheitsgerichteter Systeme als risikomindernd für Anwender und Unternehmen auswirkt.

Handlungsempfehlungen für Entwicklungsorganisationen

Wenn Ihre Organisation vor der Herausforderung steht, nun nach ISO 26262 zu entwickeln, dann lohnt es, sich für die Umsetzung in Entwicklungsprozesse auch nach Automotive SPICE anzusehen. Speziell als Zulieferer werden Sie sich ohnehin mit dem Wunsch des OEM konfrontiert sehen, das Projekt oder gleich die ganze Entwicklungsorganisation nach Automotive SPICE gemäß ISO 33020 Level 1, 2 oder 3 prüfen zu lassen, und zwar für alle Gewerke, auch diejenigen, die nicht sicherheitsgerichtet sind.

Eine gute Faustregel lautet: Wer SPICE Level 2 erreicht hat, der ist für ISO 26262 in Sachen Qualität schon ganz brauchbar aufgestellt. Wer SPICE Level 3 erreicht hat, steht gut da. Falls Ihre Organisation bislang noch gar nichts in Sachen ASPICE unternommen hat, dann wäre jetzt ein guter Zeitpunkt, um damit zu beginnen. Das Schöne an den qualitätsgerichteten Forderungen von ASPICE und ISO 26262 ist ja, dass das kein Hexenwerk ist.

Für viele Menschen in der Organisation bedeutet es auch, umzudenken. Die Erkenntnis, dass Programmieren für sich selbst eben etwas anderes ist als Software zu entwickeln für Maschinen von zwei Tonnen Gewicht, die mit mehr als hundert Kilometern pro Stunde im ungesicherten Straßenraum unterwegs sind. Und wenn diese Erkenntnis bei den Menschen gereift ist – und das tut sie bei den Allermeisten sehr rasch – dann braucht es eine Organisation, die das Qualitätsbewusstsein mit Infrastruktur unterstützt anstatt mit überstürzter Hast zu torpedieren.

Handlungsempfehlungen für OEMs als Beauftragende

Sind Sie Teil eines OEMs, der selbst entwickelt, gelten vorstehende Empfehlungen. Sind Sie in der Rolle des Beauftragenden, dann lohnt es sich, qualitativ und im Sinne der pünktlichen Einlieferung der Gewerke, so früh als möglich auf die Prozessarbeit hinzuweisen und diese einzufordern.

Letztendlich bekommt Ihre Organisation als Kunde Ihrer Zulieferer das, was sie bezahlt. Werden also Zulieferer stets noch weiter im Preis gedrückt, wird die Lieferantenorganisation eher früher als später so unter Kostendruck stehen, dass eben unter dem Teppich das Parkett nicht mehr sauber und kleinteilig verlegt ist. Rohe dünne Bretter müssen dann herhalten. Drücken Sie noch weiter, kann unter dem Teppich dann gar kein Parkett mehr vorhanden sein.

Die Kosten für die nächste Entwicklung, die auf einem bestehenden System auf-baut, hängen auch von der Erstellungsqualität ab. Musste aus Kostengründen das Gewerk schneller erstellt werden, als der Qualität zuträglich war, dann werden Sie mehr Mühen und Aufwand bezahlen müssen, bestehendes auf den aktuellen Stand zu bringen und wiederzuverwenden. Hier geht es nicht nur um den Aufwand, sondern auch um die „geerbten“ Schwächen oder Fehler und damit verbundenen Gefahren und Risiken.

Software Engineering als Grund-Disziplin

Wir alle haben mal gelernt, wie das geht. In jedem Studiengang Informatik gibt es – sei es im Grundstudium oder Hauptstudium – eine Vorlesung „Software Engineering“ oder „Software-Technik.“ In der Definition nach Balzert heißt es: „Software-Technik: Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Software-Systemen.“ [8, p. 17]

Software Engineering ist eben nicht „ich setz mich mit zwanzig anderen hin und klopfe Code auf ein Steuergerät“. Die Qualitätsanteile aller Normen und Modelle wie ISO 26262, SPICE [9], Automotive SPICE, CMMI [10] fordern letztendlich nur, dass wir ordentlich entwickeln, und dass wir dokumentieren, wie wir vorgehen.

Eine Verletzung dieser Prinzipien und daraus folgenden Praktiken in professionellen Softwaresystemprojekten ist Problem der Selbstwirksamkeit einzelner wie auch ein systematisches Problem von Organisationen. Jeder, als einzelne Person der Entwicklungsmannschaft, wie auch als Führungspersonal in allen Hierarchieebenen, ist aufgerufen, selbst Teil der Lösung zu sein und sich die Prinzipien ordentlichen Arbeitens wieder vor Augen zu führen und diese mit sinnvollen Maßnahmen in der Organisation fest zu verankern.

Eliminieren und Automatisieren

In diesem Abschnitt finden sich geordnet nach den obigen Prinzipien einige minimal erforderliche Prozess- und Vorgehensfelder, über die Sie sich in Ihrer Organisation Gedanken machen müssen, wenn Sie wieder die Grundlagen qualitativer Arbeit berücksichtigen wollen, und wenn die ISO 26262 kein Schock sein soll.

Die Auflistung ist angelehnt an [11] (siehe Bildergalerie).

Das Erstellen und Dokumentieren einer Prozessinfrastruktur ist nichts, was ein Entwickler und Qualitätsbeauftragter eben mal an einem Nachmittag erreicht. Zusammen genommen ergibt die Build-Infrastruktur mit allem, was dazu gehört, die Development Operations, kurz DevOps [23].

Für alle Felder gilt: Eliminieren vor Automatisieren. Die ISO 26262 schreibt vieles vor, was prinzipiell sicherzustellen ist. Das heißt jedoch nicht, dass dies stets von Menschen gemacht werden muss. Während Prozesse eher nicht eliminiert werden können, ist das für einzelne manuelle Arbeitsprodukte schon der Fall. Niemand hat etwas von manuell erstellten Reports in Folienform. Reporting an und für sich, um beim Beispiel zu bleiben, kann dann weitgehend automatisiert werden, so dass die relevanten Kennzahlen automatisch aus Projekt- und Buildsystem gezogen und in menschenlesbare Form gebracht werden.

Eliminieren beschreibt also die Prozessveränderung, in der die Organisation prüft, inwieweit Templates tatsächlich als solche befüllt werden müssen, oder die ISO 26262 im Geiste auch mit anderen, einfacheren Darreichungsformen erfüllt werden kann.

Automatisieren umfasst dann die Prozessveränderung, in der die verbleibenden Schritte von manueller Bearbeitung soweit als möglich in automatische Prozesse über-führt werden. Dies ist vor allem bei Reporting auf allen Ebenen von Softwaremetriken bis zur Zusammenfassung von Konformitätsbetrachtungen und Release Management möglich, bei der Verifikation und Test, bei Change Management, aber auch unterstützend bei Reviews. Ebenso kann „Automatisieren“ Methoden der Modellbasierten Softwareentwicklung enthalten, bei denen Algorithmik direkt aus Verhaltensmodellen erzeugt wird.

Vor allem beim Automatisieren gilt es, mit Augenmaß vorzugehen. Nicht alles muss sofort automatisiert werden. Manche Tätigkeiten finden so selten statt, dass eine Automatisierung mehr Aufwand verbraucht, als sie einspart. Zwar sind die besten Menschen, die das einschätzen können, diejenigen, die die Tätigkeit durchführen. Jedoch gilt es sich bewusst zu machen, dass diese Menschen teilweise ihre Identität aus diesen Tätigkeiten beziehen und somit einer Automatisierung eher ablehnend gegenüberstehen. Um das Dilemma der Automatisierung und Eliminierung aufzulösen, braucht es eine ehrliche Diskussion über Identitäten und höhere Wertschöpfung. Keiner will einfach wegautomatisiert werden, jedoch wollen die meisten Mitarbeiter eine höhere Wertschöpfung erreichen, wenn man mit ihnen offen darüber spricht.

Literaturverzeichnis

[1] ISO, "ISO 26262: Road Vehicles – Functional Safety. Part 1-7," ISO Copyright Office, Geneva, 2011.

[2] VDA QMC Working Group 13 / Automotive SIG, Automotive SPICE Process Reference Model / Process Assessment Model, 3.1 Hrsg., VDA Quality Management Center, 2017.

[3] ISO/IEC JTC 1/SC 7 Software and systems engineering, Information technology -- Process assessment -- Process measurement framework for assessment of process capability, ISO, 2015.

[4] Kugler Maag CIE, „Automotive SPICE v3.1 Pocket Guide,“ Kornwestheim, 2018.

[5] R. Messnarz, I. Sokic, S. Habel, F. König und O. Bachmann, „Extending Automotive SPICE to cover Functional Safety Requirements and a Safety Architecture,“ in EuroSPI 2011: Systems, Software and Service Process Improvement, Berlin-Heidelberg, 2011.

[6] E. Petry, „Automotive SPICE® & ISO/CD 26262: Their Mutual Relationship,“ in Fifth Automotive SPIN Italia Workshop, Milano, 2009.

[7] „Manifesto for Software Craftsmanship,“ 2009. [Online]. Available: http://manifesto.softwarecraftsmanship.org/.

[8] H. Balzert, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, 3. Auflage Hrsg., Heidelberg: Springer Akademischer Verlag, 2009.

[9] ISO/IEC JTC 1/SC 7 Software and systems engineering, ISO/IEC 15504 Information technology – Process assessment: Part 5 – „An exemplar software life cycle process assessment model“, ISO, 2012.

[10] CMMI Product Development Team, CMMI for Systems Engineering/Software Engineering. Version 1.1 Continuous Representation, Pittsburgh: Software Engineering Institute, Carnegie Mellon University, 2002.

[11] J. Schlosser und M. Hillbrand, „Scrum für Embedded-Software. Gut – aber aus anderen Gründen, als Ihr Manager glaubt,“ in Embedded Software Engineering ESE Kongress, Sindelfingen, 2017.

[12] B. Collins-Sussman, B. W. Fitzpatrick and C. M. Pilato, "Version Controll with Subversion," 2017. [Online]. Available: http://svnbook.red-bean.com/index.de.html.

[13] S. Chacon and B. Straub, Pro Git book, US: Apress, 2009.

[14] "Jenkins Handbook," [Online]. Available: https://jenkins.io/doc/book/. [Accessed 11 10 2017].

[15] „GoCD: Open Source Continuous Delivery and Automation Server,“ [Online]. Available: https://www.gocd.org/. [Zugriff am 11 10 2017].

[16] „Polyspace. Making Critical Code Safe and Secure,“ MathWorks, [Online]. Available: https://de.mathworks.com/products/polyspace.html. [Zugriff am 11 10 2017].

[17] „Klocwork: Source Code Analysis Tools for Security & Reliability,“ [Online]. Available: https://www.klocwork.com/. [Zugriff am 11 10 2017].

[18] „BullseyeCoverage Code Coverage Analyzer,“ [Online]. Available: http://www.bullseye.com/. [Zugriff am 11 10 2017].

[19] M. Doar, Practical JIRA Administration, UK: O'Reilly, 2011.

[20] P. Hodgson, „Feature Branching vs. Feature Flags: What’s the Right Tool for the Job?,“ 23 05 2017. [Online]. Available: https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/. [Zugriff am 11 10 2017].

[21] W. Buchwalter, „A Git Workflow for Continuous Delivery,“ 21 06 2016. [Online]. Available: https://blogs.technet.microsoft.com/devops/2016/06/21/a-git-workflow-for-continuous-delivery/. [Zugriff am 11 10 2017].

[22] "Docker - Build, Ship, and Run Any App, Anywhere," [Online]. Available: https://www.docker.com/. [Accessed 11 10 2017].

[23] G. Kim, J. Humble, P. Debois, J. Willis and T. Demmig, Das DevOps-Handbuch, Heidelberg: O'Reilly / dpunkt.verlag GmbH, 2017.

[24] B. Gloger, Scrum: Produkte zuverlässig und schnell entwickeln, 5. Auflage Hrsg., München: Carl Hanser Verlag, 2016.

[25] W. Cunningham, „Manifest für Agile Softwareentwicklung,“ 2001. [Online]. Available: http://agilemanifesto.org/iso/de/manifesto.html.

[26] J. Schlosser und G. Sandmann, „Keine Angst vor Autosar – Leitfaden und nutzenbetrachtung für Funktionsentwickler,“ ATZelektronik, Bd. 4, Nr. 2, pp. 66-72, 2009.

[27] T. Schneider, „Achieving Cloud Scalability with Microservices and DevOps in the Connected Car Domain,“ in Software Engineering (Workshops), Wien, 2016.

[28] W. Cunningham and others, "Manifest für Agile Softwareentwicklung," 2001. [Online]. Available: http://agilemanifesto.org/iso/de/manifesto.html.

[29] J. Sutherland and J. Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, UK: Random House Business Books, 2014.

[30] J. Schlosser, „Frühe Verifikation von Regelungssystemen mit Model-Based Design,“ in Embedded Software Engineering Konress, Sindelfingen, 2011.

[31] J. Schlosser, Architektursimulation von verteilten Steuergerätesystemen, Berlin: Logos Verlag, 2006.

[32] M. Hillbrand, „Agile Methoden skalieren, aber bitte nicht dogmatisch! Erfolgreich skalieren!,“ OBJEKTspektrum, Nr. 2, 2017.

[33] E. Petry, „How to Upgrade SPICE-Compliant Processes for Functional Safety,“ in Tenth International SPICE Conference, Pisa, 2010.

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2018 entnommen.)

Der Autor

Dr. Joachim Schlosser: Informatiker und Autor
Dr. Joachim Schlosser: Informatiker und Autor (Bild: www.joachimschlosser.de)

* Dr. Joachim Schlosser arbeitet bei Elektrobit Automotive, einem Softwarehaus für die Automobilbranche, als Manager im Consulting. Er führt Informatiker und Ingenieure, die Automobilhersteller und Zulieferer zu Agilen Entwicklungsmethoden, Funktionaler Sicherheit und Software-Architektur beraten.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben
Super Beitrag. Sehr praxisnahe und offen geschrieben. Mir kommt vieles sehr bekannt vor, auch...  lesen
posted am 08.03.2019 um 09:15 von Unregistriert


Mitdiskutieren
copyright

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