„In modernen Autos wird die Software Teil des Primärprozesses des Autofahrens und das Digitale Ökosystem zur Basis für die Funktion und die Fähigkeiten.“

Die Transformation der individuellen Mobilität hin zu alternativen Antrieben macht nur Sinn mit einer digitalen Infrastruktur und Apps, damit Informationen über Software zugänglich und abrufbar sind. Zugleich treiben Maschinelles Lernen (ML) und Künstliche Intelligenz (KI) das autonome Fahren voran. Welchen Stellenwert die Software in der neuen Automobilära einnimmt, erläutert Dirk Giesen, Vice President Sales EMEA bei Parasoft.

Wohin geht die Reise der Automobilindustrie und insbesondere bei autonomen Fahrzeugen?
Dirk Giesen: Durch die andauernde Klimadiskussion findet gerade eine massive Transformation der individuellen Mobilität hin zu alternativen Antrieben statt. Die Automobilindustrie musste sehr kurzfristig in das Thema Elektromobilität einsteigen. Allerdings lassen sich Elektrofahrzeuge nur sinnvoll betreiben, wenn sie vernetzt und in ein System eingebunden sind, sodass bestimmte Informationen (z. B. die Position des Fahrzeugs oder die Lage von Ladestationen) per App erreichbar sind. Dafür braucht es eine digitale Infrastruktur.
In bestimmten Situationen werden Autos mit ML und KI bald autonom fahren können, was Auswirkungen auf unser Gesellschaftssystem haben wird. Schon heute zeichnet sich die Verlagerung vom Besitz eines Fahrzeugs hin zum ‚Zugang‘ ab, also der Nutzung durch Leasing bis hin zu ‚Mobility-as-a-Service‘-Konzepten. Ohne Software klappt das nicht.
Das bestätigt eine Studie von McKinsey¹, nach der sich der Markt für Automobilsoftware in den nächsten zehn Jahren mehr als verdoppeln und der Markt für Verifikations- und Validierungswerkzeuge sogar verdreifachen wird. Die Entwicklung von Software wird damit zum größten Kostentreiber und eventuell sogar zur größten Bremse bei der Entwicklung neuer Fahrzeuge.

Wenn Software zum entscheidenden Teil der Wertschöpfungskette wird - wie ändert dies die Verfahren zur Qualitätssicherung und Qualitätskontrolle?
Ob Klimasteuerung, ABS oder Airbag - alle höheren Funktionen in Fahrzeugen basieren auf Software auf Komponentenebene. In modernen Autos wird die Software jedoch Teil des „Primärprozesses“ des Autofahrens und das Digitale Ökosystem zur elementaren Basis für die Funktion und die Fähigkeiten des Produkts. Dadurch wirkt sich ein Software-Problem massiv auf das Auto aus, mit noch schlimmeren Folgen für das Image des Herstellers und den Ruf des Modells. Um den Fehler zu beseitigen, braucht es dann nicht einen einfachen „Produktrückruf“ in die Werkstatt, sondern eine Operation am offenen Herzen – und damit eine geänderte Qualitätssicherung. Wenn immer mehr Komponenten Informationen austauschen, verlangt dies neue Entwicklungsparadigmen und auch unterschiedliche Testmethoden. Safety und Security by Design sind damit unerlässlich, und Sicherheit muss das zentrale Motiv im Softwarelebenszyklus und damit im Qualitätsprozess sein. Durch die Einführung von immer mehr Funktionalität sind die klassischen Ansätze zur Softwarequalität nicht mehr ausreichend.

Werfen wir einen Blick auf die Software-Architektur und -Produktionslinie – welche Veränderungen kommen hier auf?
Aus Software-Sicht sehen wir ähnliche Entwicklungen, wie sie die Enterprise Software in den letzten zehn Jahren verändert haben. Software-Architekturen auf API-Basis und moderne Betriebssysteme (Linux), die IP-basierte Kommunikation verwenden (wie SOME/IP und DDS), bilden die Grundlage der neuen Software-Architektur. Neben dem Plattformwechsel geht auch die Software-Entwicklung selbst von der Wasserfall- und V-Modell-basierten Verifikation zu den modernen agilen und testgetriebenen Entwicklungsmethoden über. Dazu gehören die modernen Konzepte wie CI (Continuous Integration) und eventuell sogar CD (Continuous Deployment) von SW-Komponenten.

Wo Sie CI/CD-Integration nennen – was meinen Sie, wie diese den Software-Entwicklungsprozess beeinflussen?
CI/CD wirken wie „Steroide“ für den SW-Entwicklungsprozess. Der Einsatz von Code-Analyse, Unit-Testing und Coverage wird zu kontinuierlich durchgeführten Standardschritten. Das macht es für die Teams viel einfacher, sich mit den Reports auseinanderzusetzen und schrittweise Verbesserungen zu erzielen (statt sich mit großen Teilen der Ergebnisse erst in bestimmten Schritten des klassischen SW-Prozesses auseinanderzusetzen). So wie die Serienproduktion der Schlüssel zur Herstellung qualitativ hochwertiger Autos war, so tut CI/CD dasselbe für die SW-Produktion. Wir haben das in unseren Tools bereits implementiert, sodass Parasoft für diese neuen Zeiten gut gerüstet ist und die nötigen Werkzeuge zur Sicherstellung der Softwarequalität für die Automobilindustrie und ihre Zulieferer anbieten kann.

Wie schätzen Sie die Entwicklung in der Automobilbranche in Bezug auf autonome Fahrzeuge und Standards wie AUTOSAR, SOTIF, SAE 21434, UL 4600 und ISO 26262 ein?
Ganz offensichtlich erlebt die Automobilindustrie eine rasante Evolution. Es ist heute normal, dass Autos, die bereits verkauft und auf der Straße unterwegs sind, Software-Updates Over-the-Air erhalten. Diese Art der Entwicklung und insbesondere die von fortschrittlichen Fahrerassistenzsystemen (ADAS) bringen neue Herausforderungen in Bezug auf Sicherheit und Schutz mit sich. Es beruhigt mich, dass es unterschiedliche Standards je nach Einsatzbereich gibt, um die Gefahren im Vorfeld bestmöglich zu vermeiden. Darunter adressieren Normen wie die ISO 26262 die funktionale Sicherheit bei der Entwicklung elektrischer und elektronischer Systeme (E/E), die Antrieb, dynamische Regelsysteme sowie Fahrerassistenzsysteme umfassen. Zusätzlich bieten Plattformen wie AUTOSAR eine offene, standardisierte Software-Layer-Architektur, die die Sicherheit weiter verbessert, einschließlich Richtlinien für die Verwendung der Sprache C++14 bei der Entwicklung von kritischen und sicherheitsrelevanten Systemen.
Die zunehmende Komplexität und Unbekanntheit der neuen Technologien, zusammen mit Veränderungen in der internen und externen Umgebung, haben zu Sicherheitsbelangen geführt, die diese Standards nicht abdecken. Daraus entstanden weitere Ausprägungen von ISO 26262 wie SOTIF (Safety of the Intendedly Functionality). SOTIF hilft dabei, den Missbrauch der beabsichtigten Funktionalität zu analysieren und zu verhindern, sofern dadurch ein unsicheres Szenario entsteht. Beispielsweise eine Situation, in der sich das Fahrzeug während der Fahrt aufgrund eines initiierten Software-Updates abschaltet.
Standards wie SAE J3061, die durch ISO/SAE 21434 ersetzt wurden, verlangen die Durchführung einer ersten Bedrohungsanalyse und Risikobewertung (TARA Thread Analysis and Risk Assessment) zur Bewertung von potenziellen Bedrohungen in Bezug auf den Betrieb, die Privatsphäre und andere Faktoren, von denen ein Verkehrsteilnehmer/Fahrer betroffen sein kann. Ist das Risiko für eine bestimmte Bedrohung ausreichend hoch, ist ein Cybersicherheitsprozess erforderlich.
Schließlich gibt es speziell für den vollautonomen Fahrzeugbetrieb Normen wie die UL 4600. Sie konzentriert sich auf die Erstellung eines Sicherheitsnachweises für den Einsatz von Fahrzeugen des SAE Levels 4/5. Wie die Sicherheit von autonomen Fahrzeugen auf öffentlichen Straßen getestet werden kann, unterliegt wieder einer anderen Norm.

Welche Bedeutung haben diese Normen für das Verhältnis zwischen OEM und Zulieferer?
Generell spielen die Standards eine ganz entscheidende Rolle für die Sicherheit in der Automobilindustrie. OEMs tragen die Haftungskosten für die Auslieferung von unsicheren Fahrzeugen an die Massen. Zur Risikominimierung müssen die OEMs diese Standards übernehmen und einhalten – und sie sollten die gleiche Qualität und Einhaltung von ihren Zulieferern verlangen. Denn eine Schwachstelle in einer Komponente kann die Sicherheit des gesamten Systems untergraben, die möglichen Folgen können unter Umständen verheerend sein. Darum haben wir in Zusammenarbeit mit einigen unserer Kunden aus der Automobilbranche kundenspezifische Programmierstandards entwickelt, die MISRA, AUTOSAR C++14, CERT, CWE und andere kundenspezifische Regeln beinhalten – diese sind vom OEM und seinen Zulieferern anzuwenden. So stellen wir sicher, dass über die gesamte Lieferkette hinweg das gleiche Qualitätsniveau der Software besteht.
Zusätzlich bieten wir mit C/C++test eine einheitliche Testlösung, die Unit-Tests und strukturelle Code-Coverage-Funktionalität beinhaltet. Als Besonderheit unterstützt diese Lösung einen breiten Satz von Hardware-Targets und Entwicklungs-Ökosystemen, die Zulieferer und OEMs mit unterschiedlichen Entwicklungsinfrastrukturen nutzen können. Vorteilhaft ist auch, dass C/C++test vom TÜV SÜD für den Einsatz auf sicherheitskritischen Systemen zertifiziert wurde.

Die Anforderungen an Audits und Konformitätsreports steigen zusehends für viele Firmen. Das ist eine enorme Herausforderung. Welche Unterstützung bietet Ihr Unternehmen?
Für uns, die wir mit unseren Tools und Lösungen sicherheitskritische Märkte wie die Automobilindustrie adressieren, ist die Unterstützung für Programmierstandards und Sicherheitsanforderungen eine Kernkompetenz. Wir sind führend bei Technologien für Coding-Standards, Unit-Testing, Coverage-Messung und Traceability des Codes als auch der Anforderungen. Entwickler erhalten bei uns auch neuere Tools für die interne als auch externe API-Validierung. Unsere C/C++-Entwicklungstestlösung integriert mehrere Testtechnologien in einem Tool. Teams können das Parasoft-Tooling einfach übernehmen, um Automobilstandards wie AUTOSAR, MISRA und ISO 26262 zu erfüllen. Benutzerdefinierte Konformitätsberichte und fortschrittliche Analysen zeigen genau auf, worauf sich die Entwicklungsanstrengungen konzentrieren müssen. Wie erwähnt, sind die Tools hierfür TÜV-zertifiziert und sie werden mit einem Tool-Qualifizierungs-Kit geliefert.

Noch ein Ausblick: Wie bewerten Sie den „eigenen“ SW-Entwicklungsprozess im Vergleich zum „Zukauf“ von SW-basierten Komponenten von Lieferanten?
Es zeigt sich heute schon: In den kommenden Jahren wird die Software zum wichtigsten Teil eines modernen Fahrzeugs und seines digitalen Ökosystems – und damit zum entscheidenden Faktor. Tatsächlich bauen sich die Hersteller das Wissen und das geistige Eigentum für die SW-Entwicklung selbst auf. So wie der Bau des Motors oft als Kernkompetenz angesehen wurde, wird dies im nächsten Jahrzehnt für die Software gelten. Ein sicheres Zeichen dafür ist, dass Volkswagen den Anteil der In-House entwickelten Software in den nächsten 5 Jahren von 10% auf 60% erhöhen möchte.

Vielen Dank für das Gespräch!

_____

¹ Automotive software and electronics 2030. Mapping the sector’s future landscape. McKinsey & Company. 2019