Software-Qualität im Blick.PRQA
Seit vielen Jahren engagiert sich die Automobilindustrie für die Verbesserung der Produktqualität. Ein durchschnittliches Fahrzeug enthält heute immer mehr Software-Anwendungen. Zudem haben diese Software-Elemente erheblich an Größe, Umfang, Interaktion und Interoperabilität zugenommen. Dabei stellt sich das Problem, alle diese Entwicklungen in einer kontrollierten und robusten Umgebung anzuordnen. OEMs und Lieferanten müssen sicherstellen, dass sie die Qualität der gesamten Software besser überwachen und steuern können. Dazu verlassen sie sich immer häufiger auf Werkzeuge und Codierungsstandards als Mittel der Qualitätssicherung, und vermeiden damit das Risiko kostspieliger Rückrufaktionen und Entwicklungsverzögerungen.
Alle Beteiligten von führenden Automobilherstellern bis hin zu vielen Marktteilnehmern unter den Zulieferern, müssen ihren Kunden neben der Bereitstellung qualitativ hochwertiger und normkonformer Systeme beziehungsweise Komponenten auch ein gesichertes Qualitätsversprechen bieten. Mit der Freigabe von MISRA C:2012 entwickelt sich der vorherrschende Codierungsstandard für die Automobilbranche weiter zu einem leistungsfähigen und robusten Container für die Programmiersprache C.
Qualitätssicherungsverfahren
Parallel dazu werden, mehr auf regionaler Basis, etablierte Software-Qualitätssicherungsverfahren immer ausgereifter. Ein Beleg dafür ist das Engagement japanischer Industrie- und Normungsorganisationen bei der Suche nach Möglichkeiten für eine kontrollierte Abmilderung der strikten Richtlinien für die MISRA-Codierungsregeln. Entsprechend der immer größeren Komplexität bei Embedded-Software werden automatisierte Werkzeuge zur Überprüfung und Überwachung der Softwarequalität immer leistungsfähiger und decken gleichzeitig die Anforderungen einer größeren Gruppe von Prozessbeteiligten ab.
Auf einen Blick
Software-Qualität: Der Automotive-Sektor verzeichnet aktuell eine Periode schnellen Wachstums und zunehmender Verfeinerung bei Software-Anwendungen. Dabei ist man sich bewusst, dass Erweiterungen des Funktionsumfangs mit Qualitätsinitiativen begleitet werden müssen, und dass diese Philosophie auch die gesamte Lieferantenkette abdecken muss. Angesichts der Risiken beim Einsatz eines solchen Systems lässt sich eine Antwort nur mit leistungsfähigen, umfassenden automatisierten Werkzeuglösungen finden, die für alle Prozessbeteiligten Qualitätsanalysedaten liefern können.
Der vorliegende Artikel präsentiert weltweite Trends und Erfahrungen aus dem Bereich der Automobilindustrie, sowie die neuesten Techniken und Werkzeuge zum Aufbau robuster Softwarequalitätssysteme für diese moderne, schnell voranschreitende Industrie.
Softwarequalität in der Automobilindustrie
Die Automobilindustrie orientiert sich heute an zwei Normungs-Initiativen: der Norm ISO 26262 für Funktionssicherheit und dem Codierungsstandard MISRA-C. Diese beiden Standards bieten eine solide Basis zur Sicherung der Softwarequalitäts-Ziele im Automobilsektor.
Bild 1: Direktiven und Regeln für unterschiedliche Klassifikationen im Rahmen von MISRA C:2012.PRQA
Die ISO 26262 wurde erst vor relativ kurzer Zeit (November 2011) ratifiziert und ist eine Anpassung von IEC 6158. Die Norm befasst sich mit Funktionssicherheit in der Produktion von Personenkraftwagen und wurde von der gesamten Automobilindustrie auf breiter Basis übernommen. Der Standard schreibt den Einsatz von äußerst konservativen Codierungsstandards wie MISRA-C vor.
Die MISRA-C-Codierungsregeln, die entweder als Untermenge oder in ihrer Gesamtheit zum Einsatz kommen können, haben sich seit ihrer Einführung im Jahre 1998 und einer kürzlichen zweiten Revision im Jahre 2012 zum De-Facto-Standard entwickelt. MISRA-C wird zur Sicherung der Codequalität und der Normerfüllung innerhalb der Entwicklungsgruppen von Organisationen und zwischen Lieferanten, Zulieferern und Kunden eingesetzt.
Infokasten
Die Neuerungen in MISRA C:2012 (siehe auch Bild 2):
- Sprachversionen: Der Codierungsstandard unterstützt nun C99 sowie C90.
- Regeln: Zur Beschränkung des Einsatzes einiger potenziell gefährlicher C99-Sprachmerkmale wurden elf neue Regeln eingeführt.
- Regel-Klassifizierung: Es wurde eine neue „Mandatory“-Regelklasse definiert. Dabei handelt es sich um nicht-verhandelbare Regeln, von denen keine Abweichungen erlaubt sind.
- Regel-Konformität und -Durchsetzbarkeit: Erweiterungen, die wo immer möglich gewährleisten, dass sich die Regeln für eine automatische Durchsetzung eignen.
- Verbesserte Regeldefinition: präzisere Definitionen mit umfassenden Erläuterungen und Begründungen.
Bild 2: Die Neuerungen in MISRA C:2012PRQA
Die neue Revision von MISRA-C unterstützt in erster Linie den Einsatz des Standards C99 der Programmiersprache C sowie des Standards C90. Für Softwareentwickler bringt dies den Vorteil, dass sie jetzt in ihren Produkten die verbesserten Datenhandling-Funktionen von C99 nutzen können. Mit der Unterstützung von C99 wurde der Standard um neue Regeln, verbesserte Erläuterungen und Definitionen erweitert, so dass er damit eine bessere Einbindung der Programmiersprache C sowie Konformität zum Standard gewährleistet.
Die Sicht der Prozessbeteiligten
Die verschiedenen Gruppen der Prozessbeteiligten betrachten Softwarequalität oft aus verschiedenen Blickwinkeln und gehen unterschiedlich damit um. In einem zunehmend diversifizierten Software-Ökosystem ist die Nutzung einer gemeinsamen Basis zur Messung der Qualität daher eine zwingende Anforderung.
Bei leitenden Managern in Automobilunternehmen ist die Wahrnehmung des Begriffs Qualität stark bestimmt durch behördliche Anforderungen und treuhänderische Verantwortung, so dass die Überwachung der Qualität eine ähnliche Bedeutung erlangt hat wie Kosten und Termintreue. Auf dieser Ebene ist also eine übergreifende Sicht auf die Softwarequalität erforderlich, plus gemeinsame und konsistente Bewertungsstandards sowie eine Trendüberwachung für aktuelle und vergangene Projekte mit besonderer Konzentration auf bevorstehende Freigabe-Meilensteine.
Softwareentwicklergruppen müssen sich detaillierter und tiefergehend auf Qualität konzentrieren; es ist hierbei entscheidend, dass die dabei genutzten Kriterien kompatibel sind mit den übergeordneten wirtschaftlichen Zielen.
Für Projektleiter und Manager muss der detaillierte Konformitätsstatus in Bezug auf anwendbare Normen und auf übergreifende Qualitätsziele frei verfügbar und aufgeschlüsselt nach Entwickler und Projekt zugänglich sein.
Für Entwickler müssen sich die Qualitätswerkzeuge direkt in die Software-Entwicklungsumgebung eingliedern und präzise Qualitätsinformationen in Bezug auf die neusten Codeänderungen liefern.
Die Qualitätssicherungsgruppe musste sich oft auf externe verzögerte Bewertungskriterien wie die Überprüfung von Fehlern und die Sammlung von Bug-Daten verlassen. Im Gegensatz dazu bräuchten sie allerdings ein Qualitätssystem, das sich auf vorausschauende Maßnahmen wie detaillierte Angaben zur Einhaltung von Codierungsstandards, Bewertungsmaßstäbe für Codekomplexität und andere damit verbundene Softwarequalitätsmerkmale konzentriert.
Einsatzrisiken
Aus unseren Erfahrungen bei der Unterstützung großer Kfz-Zulieferer und Hersteller weltweit gibt es eine Reihe von gängigen Fallen und Fehlern, die beim Einsatz einer Qualitätssystemlösung auftreten können:
- Eine Lösung, die für einen Entwickler an isoliertem Code funktioniert, lässt sich nicht automatisch auf ganze Projekte beziehungsweise für eine gesamte Organisation hochskalieren.
- Der Prozentsatz falscher positiver Ergebnisse bei der Analyse muss nahe Null liegen; alle Diagnose-Ausgabedaten müssen sich auf reale adressierbare Zustände beziehen.
- Dementsprechend darf kein Bereich der Qualitätsüberwachung ignoriert oder ausgelassen werden; jede Codierungsregel muss mit sinnvollen Diagnoseroutinen abgedeckt werden.
- Realistische Einschränkungen beim Erreichen einer vollen Normkonformität müssen berücksichtigt werden. Dies erfordert komplexe und kontrollierte Abweichungen von der Einhaltung der Regeln. Transparenz auf höheren Organisationsebenen muss zu den detaillierten Normerfüllungs-Anstrengungen auf unteren Ebenen passen. Jeder Bruch zwischen den einzelnen Prozessbeteiligten führt zu gegenseitiger Benachteiligung.
Trends in der Automobilelektronik
In den letzten zehn Jahren hat der Software-Einsatz im Automobil-Sektor stark zugenommen, und in letzter Zeit sind einige tiefgreifende Trends im Bereich der Qualitätssicherung zu beobachten.
Obwohl Analysewerkzeuge wie QA•C bisher zur Validierung und Verifikation im Anschluss an die Codeerstellung zum Einsatz kamen, haben sich Entwickler in den letzten Jahren intensiv dafür eingesetzt, diese Werkzeuge direkt während der Erstellung des eigentlichen Codes zu nutzen – ein klarer Beleg dafür, dass Vorbeugen besser als Heilen ist. Dies ist einerseits darauf zurückzuführen, dass Kunden von ihren Lieferanten einen sehr frühen Nachweis der Einhaltung von Best Practices in der Branche fordern, andererseits aber auch auf den Wunsch vieler unterschiedlicher Zulieferer von hauptsächlich software-gestützten Komponenten, die zeitraubende Auswirkungen einer Überarbeitung von nicht-konformem Code verringern wollen.
Eine interessante Erweiterung des Prinzips einer Abweichung von einer vollen Normerfüllung zeichnet sich auf dem japanischen Automobilelektronik-Markt ab. Hier hat sich die Branche zusammengetan, um einen sehr streng kontrollierten Satz von Ausnahmefällen gegenüber einer vollen MISRA-Konformität zu definieren. Jeder Fall, für den eine Ausnahme gemacht werden soll, muss abgestimmt werden; ergänzend dazu müssen vorab eine Begründung, eine Sicherheitsbeschreibung sowie weitere Hintergrundinformationen formuliert werden. Nur dieser Satz abgestimmter Abweichungen darf anschließend für die gesamte japanische Automobilindustrie zum Einsatz kommen. Dementsprechend ist dies eine Erweiterung der Komplexität für die Code-Normkonformität. Firmen mit weltweiter Vermarktung müssen daher in der Lage sein, ihre Codebasis für einzelne Marktbedingungen zu validieren.
Automatisierte Werkzeuglösungen
Die Statische Codeanalyse ist als entscheidende Komponente zum Erreichen hoher Codequalität ein integraler Bestandteil der Entwicklungsumgebung. Will man diese Umgebung auf das gesamte Unternehmen ausweiten, so erfordert dies ein Vorgehen, das die verschiedenen Grade der Benutzerbeteiligung berücksichtigt. Mit QA•Verify hat PRQA ein Werkzeug entwickelt, das die Analyse-Ausgabedaten von statischen Analysewerkzeugen wie QA•C und QA•C++ in einen Satz verschiedener Darstellungen umwandelt, die sich für einen breiteren Benutzerkreis eignen.
Welche Fähigkeiten benötigt ein gutes Qualitätsmanagement-Berichtssystem? Zunächst ist eine Darstellung der Diagnosedaten passend für Betrachter außerhalb der Entwicklungsumgebung dringend erforderlich. Die Untersuchung zugrundeliegender Normkonformitätsmängel und Codefehler ermöglicht eine bessere Zusammenarbeit zwischen den verschiedenen Prozessbeteiligten. Eine entscheidende Fähigkeit ist die Präsentation von Trendgrafiken und Bewertungskriterien auf Projektebene mit einer Darstellung von Normkonformität, Komplexität und anderen geeigneten Kriterien, die Vergleiche zwischen Projekten ermöglichen und Warnsignale vor der Projektfreigabe liefern. Leistungsfähige Kollaborationsfunktionen müssen eine Kommentierung von Codierungs-Entscheidungen enthalten; dies ermöglicht ein besseres gemeinsames Verständnis aller Prozessbeteiligten. Diese Funktionen erfordern eine umfassende integrierte Code-Inspektionsumgebung mit leistungsfähigen Funktionen zur Aufdeckung von Quellcode-Details.
Die Nutzung eines solchen ganzheitlichen Konzepts für den Test mit automatisierten Werkzeugen ermöglicht ein höheres Maß an Produktivität, Codequalität und Code-Wiederverwendung. Dies wiederum gewährleistet eine kürzere Time-to-Market für neue Projekte sowie Reduzierungen bei Terminüberschreitungen und Nacharbeiten.
Infokasten
MISRA in der Automobilindustrie – ein historischer Abriss
Die Entstehungsgeschichte der Software in der Automobilelektronik begann vor etwas mehr als 15 Jahren, als Kfz-Ingenieure von mechanischen auf softwaregestützte Steuerelemente umstellten. Diese wurden zunächst in Assembler implementiert; anschließend wechselte man schnell zur Programmiersprache C, da es für sie viele ausgebildete Programmierer gab und die Sprache ein hohes Maß an Flexibilität bot.
Angesichts der Schwierigkeiten und Risiken beim Einsatz der Programmiersprache C speziell für Automotive-Entwicklergruppen mit mehr Erfahrung auf dem Bereich Mechanik als dem von Software stieß die Motor Industry Research Association eine Initiative zur Lösung der damit verbundenen Probleme an. Die Organisation förderte ein Komitee aus Experten aus der Branche und von Software-Toolherstellern, die anschließend den ersten öffentlichen Codierungsstandards für C erstellten: MISRA-C (1998).
Die ursprünglich in Großbritannien entstandene Initiative dehnte sich schnell auf den weltweiten Automobilsektor aus und überschritt sogar die Grenzen der Branche mit vielen unterschiedlichen Anwendungen für andere Einsatzgebiete. Aus dem ursprünglichen Standard MISRA C entwickelten sich zwei Nachfolger: ein Update im Jahre 2004 und eines in 2012. Beide belegen das umfassende Interesse an dieser Initiative und deren Erfolg.
Zusammen mit der Einführung äußerst konservativer Codierungspraktiken befasste sich die Automobilindustrie auch mit Funktionssicherheit und definierte den neuen ISO Standard 26262 als Anpassung der IEC-Norm 61508. Dieser im November 2011 ratifizierte Standard wurde für die Kfz-Fertigung konzipiert und auf breiter Basis von der Automobilindustrie übernommen. Der Standard erfordert die Nutzung von äußerst konservativen Codierungsstandards wie MISRA C.
Fergus Bolger
(av)
