So nutzen Sie Standards für die Entwicklung von Automobilsoftware, um Risiken zu minimieren

Einige Unternehmen betrachten die Einhaltung von ISO 26262, MISRA und anderen Standards als eine Belastung, die den Aufwand erhöht. Die Wahrheit ist jedoch, dass die mit Softwarefehlern verbundenen Ausfallkosten viel, viel höher sind als die Kosten für die Qualitätssicherung.

Wenn durchschnittliche Nicht-Ingenieur-Verbraucher an elektronische Systeme in Kraftfahrzeugen denken, denken sie wahrscheinlich an integriertes GPS, Infotainment-Systeme und wahrscheinlich an eine vage Vorstellung, dass sich irgendwo im Auto ein Computer befindet, der einige der Sicherheitsmerkmale steuert. Die Realität ist natürlich, dass moderne Autos wesentlich komplexer sind und Software in allen Facetten der Funktionalität, einschließlich vieler sicherheitskritischer Funktionen, eine immer größere Rolle spielt.

Tatsächlich nutzen Autos seit Jahrzehnten elektronische Systeme für kritische Funktionen, und Marktveränderungen wie der Vorstoß zu einem „Internet der Dinge“ haben die Autohersteller dazu veranlasst, eine größere Anzahl komplexer Computersysteme einzubetten, die die Bandbreite der Kritikalität abdecken.

Die mit der Systementwicklung verbundenen Geschäftsstrukturen und Lieferketten tragen weiter zur Komplexität bei. Es kommt selten vor, dass ein Hersteller alle Komponenten und Subsysteme in seinen Autos von Grund auf konstruiert und baut, was zu potenziellen Integrationsproblemen führt. Von diesem Modell stammt ein Getriebe, von diesem ein gutes Bremssystem. Während sie in ihrer vorherigen Umgebung möglicherweise gut funktioniert haben, können sie in einem völlig neuen komplexen System unbeabsichtigte und unerwartete Ergebnisse erzielen. Infolgedessen ist Automobilsoftware häufig eine komplexe Ansammlung von Systemen, die möglicherweise ausreichend getestet wurden oder nicht. Die ad-hoc-Implementierung von Komponenten ohne ordnungsgemäße Prüfung, insbesondere in sicherheitskritischen Anwendungen, kann äußerst kostspielig sein.

Der Vorteil ist jedoch, dass es bekannte Methoden gibt, um Autoherstellern dabei zu helfen, das Ausfallrisiko zu verringern, indem sie die Softwarequalität in ihre Entwicklungsprozesse integrieren. In diesem Artikel werden einige der Probleme erörtert, die zur Komplexität von Automobilsoftware beitragen, sowie die mit der Entwicklung von Automobilsoftware verbundenen Risiken. Wir werden auch diskutieren, wie die Implementierung bekannter Best Practices für die Entwicklung, wie z. B. ISO 26262, Organisationen dabei hilft, diese Risiken zu minimieren.

Injiziert mehr Code mehr Risiko?

Nach einigen Schätzungen kann ein Standard-Mittelklasse-Auto weit über hundert elektronische Steuergeräte (ECU) haben, die Millionen von Codezeilen verarbeiten - und diese Zahl steigt. Es ist nicht ungewöhnlich, dass ein Hersteller mehrere Automodelle mit über hundert Millionen Codezeilen hat.

Es wird davon ausgegangen, dass je teurer das Auto ist, desto mehr Software eingebettet ist - und dass der größte Teil der Software für High-End-Infotainment-Komponenten bestimmt ist. Zwar werden diese Systeme mit zunehmender Modellreihe immer komplexer, doch selbst in einführenden Fahrzeugreihen wird Software zur Steuerung von Lenkung, Bremssystemen, elektrischer Energieverteilung usw. verwendet. Und selbst scheinbar geringfügige Änderungen an Funktionen wie Bluetooth, Klimatisierung, Tempomat usw. führen zu einem exponentiellen Wachstum des Codes.

Wir können davon ausgehen, dass mehr Code zu mehr Komplexität und damit zu mehr Risiko führt, aber die Auswirkungen sind möglicherweise nicht unbedingt signifikant. Ein größerer Beitrag zum Geschäftsrisiko im Zusammenhang mit Automobilsoftware ist die Integration von Code, der aus verschiedenen Quellen über mehrere Ebenen hinweg entwickelt wurde. Die meisten Komponenten, einschließlich ECU-basierter Komponenten, werden an Anbieter der zweiten Ebene vergeben, die an Anbieter der dritten Ebene vergeben, und so weiter. Jede vorhergehende Schicht hat spezifische Anforderungen an die Komponente, die sie entwickelt. Unternehmen verfügen häufig (aber nicht immer) über Verfahren zur Analyse des eingehenden Codes, um sicherzustellen, dass die Komponenten wie erwartet funktionieren.

Dies setzt jedoch voraus, dass jede Komponente entlang der Lieferkette eine Neuentwicklung ist. In der Realität verzweigen nachgelagerte Ebenen Code, der für eine bestimmte Marke, ein bestimmtes Modell und ein bestimmtes Jahr geschrieben wurde. Die Mutation und Wiederverwendung von Code erfolgt in der gesamten Lieferkette, was zu einem Testproblem führt. Wie implementiert der Hersteller End-to-End-Tests in einem solch chaotischen Ökosystem der Softwareentwicklung? Wenn das Steuergerät im Lenkrad ursprünglich für ein Fahrzeug und das Steuergerät im Armaturenbrett für ein anderes Fahrzeug entwickelt wurde und keines der Steuergeräte für das Fahrzeug ausgelegt ist, in das sie derzeit eingebettet sind, wie wirkt es sich aus? Wie können Sie sicherstellen, dass das gesamte System wie erwartet funktioniert? Es ist durchaus möglich, dass beide Systeme die Tests als funktionsfähig bestehen, jedoch nicht in allen Situationen ordnungsgemäß kommunizieren können. Welches Risiko ist mit dieser Lücke verbunden?

Die Kosten für Softwarequalität

Wenn Unternehmen versuchen, die Kosten für die Softwareentwicklung zu messen, tendieren sie dazu, allgemeine Kennzahlen zu betrachten: Entwicklungszeit für die Ingenieure; Testzeit für QS; „Baumaterialien“ in Form des Erwerbs von Werkzeuglizenzen, Compilern und anderen Infrastrukturkomponenten. Dies sind wichtige Kennzahlen, die jedoch häufig übersehen werden, sind die Ausfallkosten.

Wenn die Software im Bremssystem ausfällt, was kostet das Unternehmen in Bezug auf Nacharbeit, Rückrufe, Audits, Rechtsstreitigkeiten und Wertverlust? Was ist, wenn es einen Verlust von Leben gibt? Wir argumentieren, dass die Qualitätskosten die Kosten für die Entwicklung und das Testen der Software sind, einschließlich aller normalen Metriken, die wir identifiziert haben, sowie der sehr greifbaren Kosten, die mit einem Ausfall vor Ort verbunden sind.

Defekte kosten Autohersteller viel Geld. Die NHTSA schätzt, dass Rückrufe und Korrekturen in der gesamten Branche die Autohersteller jährlich 3 Milliarden US-Dollar kosten. Wenn es um die Kosten für Softwareprobleme geht, wird eine Schätzung von 2005 von IEEE bezifferte die Kosten für Hersteller auf 350 USD pro Auto. Wenn man die niedrigen Gewinnspannen in einer Reihe von Fahrzeugen berücksichtigt, ist es denkbar, dass ein ausreichend schwerwiegender Softwarefehler das Geschäft ernsthaft beeinträchtigen kann.

Das Endergebnis ist wichtig, aber noch wichtiger ist, dass Menschen ernsthaft verletzt werden oder sogar infolge eines Softwarefehlers sterben können. Dabei spielt es keine Rolle, wie weit in der Lieferkette der Fehler entstehen kann. Fehler und alle damit verbundenen Folgen liegen in der Verantwortung des Autoherstellers. Daher muss bei jeder Kostenanalyse im Zusammenhang mit der Softwareentwicklung die potenziellen Ausfallkosten berücksichtigt werden.

Der aktuelle Stand der Softwareentwicklung

Wir haben argumentiert, dass die Komplexität der abgestuften Lieferkette für Automobilsoftware zum Gesamtrisiko sicherheitskritischer Systeme beiträgt. Wir haben auch die potenziellen Kosten für das Automobilgeschäft bekräftigt. Dieses Problem hat jedoch eine andere Dimension, die im kulturellen Unterschied zwischen Engineering und Softwareentwicklung liegt.

Softwareentwicklung ist fast nie Engineering. Das heißt, bestimmte Konzepte aus technischen Prinzipien wie Wiederholbarkeit, gut ausgeübte Best Practices und das Vertrauen in Gebäudestandards haben sich in der Softwareentwicklung noch nicht fest etabliert. Darüber hinaus kann die Schulung für Softwareentwickler inkonsistent sein - auch wenn sie nicht vorhanden ist - und Unternehmen müssten große Anstrengungen unternehmen, um zu überprüfen, ob ihre Entwickler über ausreichende Kenntnisse zum Erstellen sicherheitskritischer Software verfügen.

Dies steht im Gegensatz zum Engineering, bei dem die Einstellungen, Denkweisen und die Geschichte der Disziplin einen Prozess erzwingen, der im Vergleich zur Softwareentwicklung weniger fehleranfällig ist. Das heißt nicht, dass Ingenieure wissen, was sie tun, und Softwareentwickler nicht. Es ist vielmehr zu sagen, dass die Automobiltechnik als Fachgebiet doppelt so ausgereift ist wie die Softwareentwicklung, und dass die immaterielle, zeitliche Natur von Software eine unbekümmerte Haltung beibehält, in der, wenn es funktioniert, es getan wird.

Der Schwerpunkt in der Softwareentwicklung liegt auf einer schnelleren Bereitstellung und funktionalen Anforderungen - wie schnell können wir diese Funktionalität haben? Das Management hat kaum einen Anreiz, fundierte technische Verfahren in den Softwareentwicklungszyklus zu implementieren. Um funktionale Sicherheit in Software zu erreichen, müssen bestimmte technische Prinzipien operationalisiert werden:

• Die funktionale Sicherheit muss proaktiv sein
• Prozesse müssen kontrolliert, gemessen und wiederholbar sein
• Mängel sollten durch die Umsetzung von Normen verhindert werden
• Das Testen muss effektiv und deterministisch sein
• Es sollten Tests für komplexe Speicherprobleme durchgeführt werden

Die gute Nachricht ist, dass sich die Einstellungen zur Softwareentwicklung weiterentwickelt haben. ISO 26262, MISRA und andere Standards zielen darauf ab, die Softwareentwicklung für Automobilanwendungen zu normalisieren, indem sie eine Grundlage für die Implementierung technischer Konzepte in Softwareentwicklungsprozessen bilden. Einige Unternehmen betrachten die Einhaltung von ISO 26262 und anderen Standards als eine Belastung ohne direkten Wert, aber die Wahrheit ist, dass die mit Softwarefehlern verbundenen Ausfallkosten viel, viel höher sind als die Kosten für die Qualitätssicherung. Wie bei elektrischen Normen, die eine bestimmte Drahtstärke für eine bekannte Spannung festlegen, können Kodierungsnormen Richtlinien enthalten, die zur Vermeidung von Katastrophen beitragen.

ISO 26262 , MISRA und andere Standards zielen darauf ab, die Softwareentwicklung für zu normalisieren Automobilindustrie Anwendungen durch Bereitstellung einer Grundlage für die Implementierung von Engineering-Konzepten in Softwareentwicklungsprozessen. Einige Unternehmen betrachten die Einhaltung von ISO 26262 und anderen Standards als eine Belastung, die den Aufwand erhöht. Die Wahrheit ist jedoch, dass die mit Softwarefehlern verbundenen Ausfallkosten viel, viel höher sind als die Kosten für die Qualitätssicherung.

„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.