Startseite > Automotive > Mutig oder naiv?

ELIV 2019

Mutig oder naiv?

13. November 2019, 14:20 Uhr | Iris Stroh

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Software und Daten ebenfalls enorm wichtig

In einer interaktiven Live-Umfrage wurden die Teilnehmer im Saal befragt, wie wichtig die verschiedenen Software-Technologien im Transformationsprozess der Branche sein werden. Bei der Mehrfachabstimmung konnten die Besucher je ihre drei Favoriten benennen. Hier ist das Ergebnis: Demnach glauben 59 Prozent der Teilnehmer, dass Cyber-Security der höchste Stellenwert im Veränderungsprozess zukommen wird, dicht gefolgt von KI (45 Prozent) und OTA-Updates (40 Prozent). Nach wie vor wichtig, so die Expertenmeinung, bleiben Big Data/Cloud-Computing sowie Connected Car/IoT (jeweils 32 Prozent) und Embedded Software (31 Prozent). Deutlich weniger Bedeutung messen sie der Blockchain-Technologie (9 Prozent) bei dem Veränderungsprozess bei.

Fehlerfreie Software, gibt es das überhaupt?

Es gibt berühmte Software-Fehler, die viel Geld gekostet haben – Prof. Thomas Huckle, Institut für Informatik TU München, hat dieser Thematik eine Webseite gewidmet, in der viele Fehler aufgeführt und beschrieben werden. Ein Fehler, den wahrscheinlich viele kennen, führte zum Absturz der Ariane 5. Bei Huckle steht als Ursache für den Absturz folgendes: Der Bordcomputer stürzte 36,7 Sekunden nach dem Start ab, als er versuchte, den Wert der horizontalen Geschwindigkeit von einer 64-bit-Gleitkommadarstellung in eine 16-bit-signed-Integer umzuwandeln: Die entsprechende Zahl war größer als 32.768 (215) und erzeugte einen Overflow. Das Lenksystem brach zusammen und gab die Kontrolle an eine zweite, identische Einheit ab. Die Selbstzerstörung wurde ausgelöst, da die Triebwerke abzubrechen drohten. Besonders bitter aber auch die folgenden Punkte, so Huckle:

Die Software stammte von der Ariane 4, aber die Ariane 5 flog schneller!
Die Software war für den eigentlichen Flug überflüssig und diente nur den Startvorbereitungen. Um einen möglichen Restart im Falle einer kurzen Unterbrechung des Countdowns zu ermöglichen, blieb das Programm 40 s lang während des Flugs aktiv.
Der Backup-Rechner verwendete exakt das gleiche Programm.
Die Umwandlung war nicht abgesichert, da man glaubte, dass die Zahl nie so groß sein könnte.

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

Jetzt sollte man sich überlegen, ob ähnliche Fehleinschätzungen/Fehler auch in der Automobilindustrie passieren könnten. Außerdem kann man sich fragen, inwieweit überhaupt eine Fehlerfreiheit bei Software erreicht werden kann. Im Buch von Steve McConnell (Code Complete, 1993 erschienen) sind folgende Angaben bezüglich der Fehlerrate in der Software zu finden: Industriedurchschnitt – 15 bis 50 Fehler pro 1000 Zeilen ausgeliefertem Code; Microsoft-Anwendungen: 10 bis 20 Fehler pro 1000 Zeilen während des Tests im eigenen Unternehmen und 0,5 Fehler pro 1000 Zeilen in der Produktion. Aber er erklärte auch, dass es möglich sei, 0 Fehler zu erreichen, allerdings sei dies sehr kostspielig. Als Beispiel verwies er auf die NASA, die bei ihrer Software für Space-Shuttles 0 Fehler realisieren konnte, allerdings für »1000 Dollar pro Zeile Code«.

Über Jahre hinweg hat die in der Automobilindustrie aktive Halbleiterindustrie daran gearbeitet, die Fehler bei den eigenen ICs zu reduzieren, mit beachtlichem Erfolg. Vielleicht lässt sich eine ähnliche Entwicklung im Software-Bereich erreichen, allerdings sicherlich nicht zu den Kosten, die die NASA bereit war, springen zu lassen.

Ist die Komplexität überhaupt beherrschbar?

Von einzelnen Fehlern in bestimmten Programmteilen einmal ganz abgesehen, wie sieht es mit den Abhängigkeiten zwischen den Programmen aus, können die Zusammenhänge und deren Auswirkungen aufeinander überhaupt noch überblickt werden? Ist es bei einem hohen Grad an Vernetzung, die im Fahrzeug angestrebt wird, überhaupt möglich, das Verhalten aller verschiedenen Software-Module abzuschätzen, wenn nur ein einziges neues Software-Modul hinzu kommt oder ein bestehendes durch ein Update verändert wird?

Die Automobilbranche ist sich der Problematik durchaus bewusst, was die bereits beschriebenen Aussagen von Matschi oder Michael deutlich machen. Dass dennoch in Zukunft verstärkt auf Software gesetzt werden soll, erklärt Eckstein damit, dass mit der Software die Chance besteht, die Mobilität der Zukunft zu verändern. Dazu kommt natürlich noch ein weiterer wichtiger Punkt: Software-Fehler können durch Patches Over the Air behoben werden, bei eingebauter Hardware sind Fehler deutlich schwieriger auszumerzen.

Eckstein beurteilt die Software-Problematik nicht so hoch. Er ist der Überzeugung, dass die Automobilindustrie in dieser Hinsicht von der IT-Branche lernen kann. Denn in diesem Bereich ist es seit Langem üblich, große Projekte zu meistern, zum Teil einfach damit, dass neue Testmodelle und -prozesse etabliert wurden und deutlich mehr Aufwand in den Test gesteckt wird. »Dort sind die Fehlerraten mittlerweile akzeptabel, also können wir dieses Prozesswissen in unsere Industrie übertragen.

Michael fügt hinzu, dass die Konzerne bereits auf dieses Problem reagiert haben. Beispielsweise würden im VW-Konzern mit allen Marken wöchentlich Fehlermetriken an die Vorstände gemeldet, das heißt: »Wir kennen die Fehler. Diese Maßnahmen wurden eingeführt, um die Übersicht zu behalten, denn es ist schon richtig: Fehler ist ein Riesenthema«, so Michael. Um diese Fehlerrate zu senken, seien eben neue Architekturen notwendig, die es erlauben, wiederverwendbare Elemente zu nutzen. Außerdem darf man nicht vergessen, dass beim Übergang von einem Fahrzeugtyp auf den nächsten natürlich nicht 100 Prozent der Software neu geschrieben wird, sondern maximal 10 Prozent an neuer Software hinzukommt, weil dann auch klar ist, wo die kritischen Punkte liegen und wo besonders viel Aufwand betrieben werden muss, um mögliche Fehler zu finden. Und Steiner: »Deshalb plädieren wir für eine Software-Plattform, denn es geht nicht, dass ich von Fahrzeug zu Fahrzeug immer alles neu mache. Das macht ein Unternehmen wie Apple ja auch nicht.«

Die Komplexität kann verringert werden

Martin Schleicher, Executive Vice President der Conti-Tochter Elektrobit, beurteilt die Software-Frage differenziert. Er ist überzeugt, dass die Software, die im Auto läuft, heute deutlich besser ist als noch vor Jahren, und zwar dank Maßnahmen wie Spice, einer besseren Ausbildung und einem Entwicklungsprozess, der es möglich macht, Fehler frühzeitig zu erkennen. Schleicher weiter: »Die Entwicklungs-Tools sind viel besser geworden, einschließlich intelligenter Versionsverwaltungen, die selbst beim Test eingesetzt werden.« Kritischer steht er aber den Problemen gegenüber, die durch nicht überschaubare Auswirkungen neuer Anforderungen auf bestehende Software oder durch die extreme Variantenvielfalt bei den OEMs entstehen. Er ist aber überzeugt, dass sich zumindest hinsichtlich der Varianten die Komplexität eindämmen lässt. Allerdings sind hier die Autohersteller gefordert, entweder indem sie sich von der Variantenvielfalt verabschieden oder indem sie auch über die verschiedenen Fahrzeugvarianten hinweg dieselbe Software einsetzen. So oder so, das Problem der Komplexität muss gelöst werden, denn auch wenn sich Software-Fehler vergleichsweise einfach beheben lassen: haben sie fatale Auswirkungen, nutzt das auch nicht viel.