Qualitätssicherung für die Software im Auto mit Automotive SPICE 3.0

Inhaltsverzeichnis

Automotive SPICE^® 3.0 wurde im Juli diesen Jahres vom Arbeitskreis 13 des VDA (Verband der Automobilindustrie) veröffentlicht. Große Erwartungen wurden an diese neue Hauptversion gestellt. Aber was ist darin nun wirklich neu? Für wen stellt die neue Version eine große Umstellung dar? Oder bleibt doch vieles beim Alten?

Seit Beginn dieses Jahrtausends wird zunehmend mehr Software in unseren Autos verbaut. Das war und ist für die Automobilhersteller eine Herausforderung – zumal die meiste Software nicht vom Hersteller selbst stammt, sondern von Zulieferern. Das veranlasste die HIS (Hersteller-Initiative Software) der deutschen Automobilhersteller (Audi, BMW, Daimler, Porsche und Volkswagen) am Anfang des letzten Jahrzehnts, sich auf ein Reifegradmodell für die Softwareentwicklung zu einigen, mit dem sie die Entwicklungsprozesse der Zulieferer beurteilen und verbessern können.

Die Wahl fiel auf die ISO/IEC 15504, bekannt auch unter dem Projektnamen SPICE (Software Process Improvement and Capability dEtermination). Dieser Standard definiert ein allgemein verwendbares Modell zur Prozessbewertung und erlaubt unter anderem das Erstellen branchenspezifischer Ableitungen. Die HIS-Unternehmen zusammen mit anderen Herstellern wie Jaguar/Land Rover, Ford, Fiat und Volvo machten sich daran, Automotive SPICE^® nach dem Vorbild der ISO/IEC 15504 zu definieren. Diese Gruppe veröffentlichte mehrere Versionen in den Jahren 2005 bis 2010, zuletzt die Version 2.5 des Prozess-Assessment-Modells (PAM). Inzwischen kümmert sich die Arbeitsgruppe 13 des VDA um die Weiterentwicklung. Dieser Arbeitsgruppe gehören heute neben den Herstellern auch Zulieferer wie Bosch, Continental, Knorr-Bremse und ZF an.

Nachdem die ISO (International Organization for Standardization) im November 2013 begonnen hat, die ISO/IEC 15504 durch die ISO/IEC-330xx-Serie abzulösen, war jeder darauf gespannt, was sich bei Automotive SPICE^® 3.0 ändern würde.

Aus Alt mach Neu – von der ISO/IEC 15504 zur ISO/IEC 330xx

Im März 2015 wurden die Teile 2 und 7 der ISO/IEC 15504 außer Kraft gesetzt (Abb. 1). Sie beschrieben unter anderem, wie eine Beurteilung im Allgemeinen beziehungsweise für eine Organisation erfolgen soll. In der neuen Normenreihe wird auf diese Themen nun in den Veröffentlichungen ISO/IEC 33001, 33002, 33003, 33004 und 33020 eingegangen (Abb. 2).

Darin sind die wichtigsten Neuerungen eine neue Definition der Prozessattribute und der generischen Praktiken für die Reifegradstufen 4 und 5. Da Assessments in der Automobilindustrie sich aber fast ausschließlich auf die Projektebene bis Level 3 begrenzen, dürfte das zunächst keine große Auswirkungen haben.

Weiterhin erlaubt die neue ISO/IEC 33020 ein detaillierteres Rating bei der Bewertung "Partially achieved" (teilweise erreicht) und "Largely achieved" (weitgehend erreicht) (Abb. 3). Statt vier ungleichmäßig verteilter Abstufungen (0-15 % (N), >15-50 % (P), >50-85% (L), >85-100% (F)) sind nun sechs weitgehend gleichmäßig verteilte Stufen entstanden. Es bleibt abzuwarten, ob sich dieser optional anwendbare Detaillierungsgrad gegenüber dem gewohnten und bewährten Schema durchsetzen wird.

V-Modell

Endlich ein symmetrisches V-Modell

Die größten Änderungen betreffen die früheren Engineering-Prozesse (ENG.x). Sie sind in Automotive SPICE^® 3.0 in die "System-Engineering" (SYS.x) und die "Software-Engineering" (SWE.x) Prozessgruppe aufgegangen (Abb. 4). Durch die Auf- und Umverteilung der früheren ENG.5- und ENG.6-Prozesse in nun SWE.2, SWE.3 und SWE.4 ist im Software-Engineering ein symmetrisches V-Modell entstanden. Dadurch sind Design und Test sauber getrennt. Durch diese Aufteilung wird wohl auch der neue HIS-Scope (Empfehlung der deutschen Hersteller) im Vergleich zu früher einen zusätzlichen Prozess haben. Offiziell ist er noch nicht festgelegt, aber es ist zu erwarten, dass er die gleichen Prozessgebiete wie vorher umfasst: MAN.3 (aus der Management-Prozessgruppe), ACQ.4 (aus der Acquisition-Prozessgruppe), SUP.1, SUP.8 bis 10 (aus der Supporting-Prozessgruppe), SYS.2 bis 5 (aus der System-Engineering-Prozessgruppe und SWE.1 bis 6 (aus der Software-Engineering-Prozessgruppe) .

Die Aufteilung in System-Engineering- und Software-Engineering-Prozesse erlaubt die Erweiterung um zusätzliche Domänen wie Hardware Engineering (HWE) und Mechanical Engineering (MEE) (Abb. 5). Für Letzteres gibt es bereits eine Draft-Version der Prozesse von einer intacs^TM-Arbeitsgruppe (international Assessor Certification Scheme für SPICE-Assessoren), die jedoch nicht Bestandteil von Automotive SPICE^® 3.0 ist. Auf alle Fälle legt die neue Version des Standards die Grundlage, über die Begutachtung von Softwareaspekten hinaus die gesamte Entwicklung von Fahrzeugen und deren Komponenten zu beurteilen.

Richtlinien zur einheitlichen Verwendung englischer Begriffe

Ein Aspekt bei der Überarbeitung der Basispraktiken in den Software- und System-Engineering-Prozessen war die einheitliche Nutzung von Begriffen wie "Element", "Component", "Unit" und "Item" (Abb. 6). Die Begriffe "Element" und "Sub-Element" werden ausschließlich für die Bestandteile der Architektur auf den verschiedenen Hierarchieebenen benutzt. Von "Component" spricht man bei Elementen auf der untersten Ebene der Softwarearchitektur. Für jede Komponente muss ein detailliertes Design existieren, das wiederum aus einem oder mehreren "Units" besteht, den programmierbaren Teilen der Software.

Auf der rechten Seite des V-Modells (Abb. 6), das den Bereich der Verifikation und Tests widerspiegelt, steht der Begriff "Item". Ein Software-Item kann beispielsweise eine Object-Datei, eine Library oder ein Executable sein. Jedes Item korrespondiert mit den Elementen auf der linken Seite, entweder mit 1:1- oder m:n-Beziehungen. Ein Item kann sich also auf mehr als nur ein Architekturelement beziehen.

Für alle System- und Software-Engineering-Prozesse gibt es eine sogenannte Base Practice, die sich mit der Abstimmung und Kommunikation des Erreichten beschäftigt. Auf der linken Seite des V-Modells wird stets von "communicate agreed" gesprochen, auf der rechten Seite heißt es "summarize and communicate". Beide Male geht es hier nicht um die formale Zustimmung, sondern lediglich um umfassende Kommunikation mit allen Beteiligten.

Die Prozessgebiete SYS.4 und 5, SWE.4 bis 6, SUP.1, und SUP.8 bis 10 verlangen jeweils eine Strategie, die in einem Plan niedergeschrieben ist. In Automotive SPICE^® 3.0 geht man davon aus, dass für den Plan auf Level 1 die projekt- und prozessspezifische Strategie gemäß den in den "Work Product Characteristics" angegebenen Informationen definiert ist. Auf Level 2 gelten zusätzlich die Inhalte, die im "Work Product Generic Plan" beschrieben sind. Das verleiht den Informationen, die in den "Work Product Characteristics" enthalten sind, eine höhere Bedeutung bei der Bewertung der Ergebnisse als in der Vergangenheit.

Konsistenz

Auf den Inhalt kommt es an – Konsistenz wichtiger als formale Verknüpfung

In Automotive SPICE^® 3.0 werden Traceability, also Verfolgbarkeit, und Konsistenz wie folgt unterschieden: Während Erstere die formale Verknüpfung von Bestandteilen von Arbeitsergebnissen darstellt und immer bidirektional vorhanden sein muss, handelt es sich bei Letzterer um inhaltliche und semantische Zusammenhänge. In allen System- und Software-Engineering-Prozessen werden Verfolgbarkeit und Konsistenz jeweils durch zwei unterschiedliche Base Practices (BP) verlangt. Die Prozesse auf der rechten Seite des V-Modells fordern zusätzlich die bidirektionale Verknüpfung zwischen Testfällen und Testergebnissen. Ein Change Request muss im neuen Automotive SPICE^® ebenfalls die bidirektionale Traceability zu all den Dokumentstellen aufweisen, die er beeinflusst (Abb. 7). Damit wird der weitaus wichtigeren Bedeutung der Konsistenz mehr Rechnung getragen als im alten Modell, das eher dazu verleitet hat, eine gute Bewertung schon aufgrund der formal vollständigen Traceability zu vergeben.

Automotive SPICE^® 3.0 verlangt bei System- und Softwarearchitekturen eine Evaluierung alternativer Lösungen (Abb. 8), für die definierte Kriterien vorliegen müssen. Beispiele für solche Merkmale sind Qualitätseigenschaften wie Modularität, Zuverlässigkeit, Sicherheit, Benutzbarkeit oder Ergebnisse von Make-or-Buy-Analysen. Die Evaluierung und die Begründung für eine Architekturentscheidung müssen dokumentiert sein.

Verifikationskriterien werden als Eingabe für das Erstellen von Testfällen oder anderen Verifikationsschritten genutzt, die die Erfüllung der Anforderungen nachweisen. Sie werden nur im Zusammenhang mit SYS.2 und SWE.1 genutzt. Verifikationsaspekte, die kein Test abdecken kann, werden in SUP.2 behandelt. So zeigen zum Beispiel Kriterien zur Unit-Verifikation die Compliance von Source-Code zum detaillierten Softwaredesign beziehungsweise zu nichtfunktionalen Anforderungen. Mögliche Kriterien für die Unit-Verifikation umfassen Testfälle, Testdaten, Überdeckungsmaße, Kodierstandards und -richtlinien, wie beispielsweise MISRA-C (Motor Industry Software Reliability Association).

Für Unit-Tests sollten diese Kriterien in einer Unit-Testspezifikation definiert werden, die in Form eines (automatisierbaren) Skripts für eine definierte Testumgebung vorliegen kann. Integrationstests zeigen die Konformität einer Architektur. Sie untersuchen vor allem die Schnittstellen von Units, Software- und System-Items auf das Erfüllen des Architekturdesigns.

Fazit

Für Projekte und Entwickler sollte sich nicht viel ändern. Begründungen für die zu verwendenden Architektur waren auch früher sinnvoll, auch wenn sie nicht explizit gefordert wurden. Ebenso sind Verknüpfungen zu Testergebnissen, Change Requests und weiteren Ressourcen immer empfehlenswert. Jetzt ist lediglich alles klarer formuliert und mit einer einheitlichen Begriffswelt versehen.

Mehr Infos

Weitere Informationen

Automotive SPICE 3.0 ist erhältlich unter www.automotivespice.com und in den App Stores von Apple und Google (ASpiceGuide). Interessierte finden die Informationen rund um Automotive SPICE auch beim VDA oder bei intacs.

Die Prozessverantwortlichen müssen das Compliance Mapping zwischen ihrer Prozesswelt und Automotive SPICE^® 3.0 aktualisieren. Wichtig ist dabei, dass sie die neuen textuellen Formulierungen im Detail beachten und bewerten.

Mittelfristig kommen die Assessoren nicht um eine Upgrade-Schulung herum. Sie müssen die neue Begriffswelt verstehen, das Mapping der Assessment-Ergebnisse zu den umformulierten Anforderungen des Prozessmodells anpassen und eventuell genauer bewerten mit "Partially-" oder "Largely-", falls sich dies durchsetzt.

Es wird auch weiterhin Assessments nach 2.5 oder älteren Versionen von Automotive SPICE^® geben, denn letztlich liegt es in der Entscheidung des Assessment-Sponsors, nach welchem Modell eine Bewertung erfolgt. Der VDA wird innerhalb einer Jahresfrist zusätzlich einen neuen Blau-Gold-Band veröffentlichen, der auf Basis der Version 3.0 Richtlinien für die Durchführung und Bewertung von Assessments enthalten wird. Nach einer Übergangszeit von einem weiteren Jahr soll aus Sicht des VDA-QMC (Qualitäts-Management-Center im Verband der Automobilindustrie) der vollständige Umstieg auf Automotive SPICE^® 3.0 bis Ende 2017 abgeschlossen sein (Abb. 9).

Prof. Dr. Bernd Hindel
ist Vorstandsvorsitzender der von ihm 2001 gegründeten Method-Park-Firmengruppe und Dozent für Software Engineering an der Universität Erlangen-Nürnberg. Er ist Mitgründer des intacs^TM e.V. (international Assessor Certification Scheme für SPICE Assessoren) und war Präsident des intacs e.V. von 2003 bis 2005.

Bernhard Sechser
ist seit sechs Jahren bei Method Park als Principal Consultant für Prozessverbesserung und Funktionale Sicherheit tätig. Er ist Mitglied des intacs^TM Advisory Boards und gehörte zum Review-Team von Automotive SPICE^® 3.0.

Beide Autoren sind intacs-Principal-Assessoren und Trainer für den Provisional und Compentent Level für Automotive SPICE^® und weitere Assessment-Modelle.

Die gezeigten Abbildungen stammen aus dem "Automotive SPICE^® Process Reference Model / Process Assessment Model, Version 3.0", veröffentlicht am 16.07.2015, © VDA Quality Management Center. (rme)