Startseite > Automotive > Software + Tools > Entwicklungsstandards minimieren Risiko von Fehlfunktionen

Automotive Software

Entwicklungsstandards minimieren Risiko von Fehlfunktionen

10. Oktober 2017, 10:28 Uhr | Von Arthur Hicken

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Die Kosten der Software-Qualität

Wenn Unternehmen die Kosten der Software-Entwicklung zu messen versuchen, neigen sie zum Blick auf allgemeine Maßzahlen: die von den Ingenieuren aufgewendete Entwicklungszeit, die Prüfzeit für die Qualitätssicherung, das „Baumaterial“ in Form der Werkzeuglizenzen, Compiler und andere Infrastruktur-Komponenten. Natürlich sind dies wichtige Faktoren, jedoch werden dabei die durch Ausfälle entstehenden Kosten glatt übersehen.
Was passiert, wenn die Software im Bremssystem versagt? Welche Kosten entstehen dem Unternehmen dadurch für Nacharbeiten, Rückrufe, Audits, Schadenersatz und den Einbruch des Börsenkurses? Was, wenn Menschen zu Tode kommen? Parasoft vertritt die Auffassung, dass die Kosten für Qualität die Aufwendungen Entwickeln und Testen der Software zuzüglich der zuvor erwähnten normalen Kostenfaktoren und der durchaus konkreten Ausgaben durch einen Ausfall im Feld beinhalten (Bild 2).

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Software-Fehler verschlingen viel Geld der Automobilhersteller. Laut Schätzungen der National Highway Traffic Safety Administration (NHTSA) entstehen den Kfz-Herstellern durch Rückrufe und Abhilfemaßnahmen jährlich Kosten in Höhe von 3 Mrd. US-Dollar. Wie sieht es mit den Aufwendungen für Software-bezogene Probleme aus? Eine Schätzung des Institute of Electrical and Electronic Engineers (IEEE) aus dem Jahr 2005 setzte die Kosten für die Hersteller mit 350 US-Dollar pro Fahrzeug an. Bedenkt man die niedrige Gewinnspanne über eine Modellpalette hinweg, ist es vorstellbar, dass ein hinreichend

ernster Software-Fehler ein Unternehmen empfindlich schädigen kann. Die Bilanz ist natürlich wichtig, aber einen noch höheren Stellenwert hat die Tatsache, dass Menschen durch einen Software-Fehler ernsthaft verletzt oder gar getötet werden können. Dabei spielt es keine Rolle, wo in der Lieferkette der Fehler seinen Ursprung hat, denn letztendlich liegen Fehler und die aus ihnen erwachsenden Konsequenzen in der Verantwortung des Automobilherstellers. Deshalb müssen alle Kostenanalysen im Kontext der Software-Entwicklung auch die potenziellen Kosten berücksichtigen, die sich aus Fehlern ergeben.

Stand der Software-Entwicklung

Parasoft argumentiert, dass die in mehrere Ebenen gegliederte Lieferkette für Automotive-Software das Gesamtrisiko im Zusammenhang mit sicherheitskritischen Systemen verschärft. Ebenso wurden die potenziellen Kosten für Automobilhersteller angesprochen. Allerdings hat dieses Thema noch eine weitere Dimension, die sich aus dem kulturellen Unterschied zwischen Technik und Software-Entwicklung ergibt:
Die Software-Entwicklung hat so gut wie nichts mit der Technik gemein. Bestimmte technische Prinzipien wie Reproduzierbarkeit, bewährte Methoden und die Nutzung von Baunormen müssen sich in der Software-Entwicklung erst noch etablieren. Darüber hinaus kommt hinzu, dass die Ausbildung von Software-Entwicklern uneinheitlich oder womöglich gar nicht existent ist, und Unternehmen nur schwer verifizieren könnten, dass ihre Entwickler hinreichende Kenntnisse für die Herstellung sicherheitskritischer Software aufweisen.

Das steht im totalen Gegensatz zur Technik. Dort erzwingen die Einstellung und der Werdegang der gesamten Disziplin eine Arbeitsweise, die verglichen mit der Software-Entwicklung weniger defektanfällig ist. Das soll keineswegs heißen, dass Ingenieure wissen, was sie tun, und Software-Entwickler nicht. Vielmehr soll damit ausgesagt werden, dass die Automobiltechnik als Disziplin doppelt so ausgereift ist wie die Software-Entwicklung, und, dass sich durch das nicht greifbare, zeitweilige Wesen der Software die ungezwungene Einstellung festsetzt, Software sei dann fertig, wenn sie funktioniert.

Die Betonung bei der Software-Entwicklung liegt auf einer schnelleren Ablieferung und den funktionalen Anforderungen: Wie schnell ist diese Funktion verfügbar? Seitens des Managements gibt es nur wenig Anreize, solide technische Methoden in den Lebenszyklus der Software-Entwicklung einzubringen.

Aber, um in Software für funktionale Sicherheit zu sorgen, ist es notwendig, bestimmte technische Prinzipien in den täglichen Betrieb einzuführen:

Proaktive funktionale Sicherheit
Prozesse müssen kontrolliert und gemessen werden sowie reproduzierbar sein
Fehlervermeidung durch die Umsetzung von Standards
Tests müssen effektiv und deterministisch sein
Tests sollten für komplexe Speicherprobleme durchgeführt werden.

Standardisierung erhöht Sicherheit

Die Einstellungen in puncto Software-Entwicklung haben sich weiterentwickelt. Mit ISO 26262, MISRA und anderen Standards wird eine Normierung der Software-Entwicklung für Automotive-Anwendungen angestrebt, indem man eine Grundlage für die Umsetzung technischer Konzepte in Software-Entwicklungsprozessen schafft. Ebenso wie Normen in der Elektrotechnik einen bestimmten Leiterquerschnitt für einen bestimmten Strom vorschreiben, enthalten Kodierungstandards Leitlinien, die helfen, Sicherheitsrisiken und Unfälle aufgrund des Ausfalles sicherheitskritischer Systeme zu vermeiden. Sie bieten Herstellern eine Art von Akzeptanztests, um die Software von nachgelagerten Lieferanten zu zertifizieren. Einige Organisationen betrachten zwar die Konformität zu ISO 26262 und anderen Standards als eine Belastung, die nur den Aufwand erhöht, aber keinen unmittelbaren Nutzen bringt. In Wirklichkeit aber sind die durch einen Fehler entstehenden Kosten erheblich höher als der finanzielle Einsatz zur Gewährleistung der Qualität.

Wenn der Entwicklungsansatz Richtlinien zur Nutzung und Durchsetzung von Industriestandards und bewährten Praktiken enthält, lässt sich die Sicherheit der Software gleich beim Entwickeln und Kodieren gewährleisten.

Der Autor