Interview über Sicherheit bei Fahrzeugen: Weniger Software einsetzen?

Falls Sie kürzlich ein Auto gekauft haben: Können Sie einschätzen, wie es um dessen Sicherheit bestellt ist? Wir wollten in einem Interview mehr über Computersysteme und Softwarefehler in Fahrzeugen und den Umgang mit immer mehr Software in der Automobilbranche erfahren.

In Behörden und Ministerien liegen Zahlen über die Folgen des vermehrten Einsatzes all der Staufolgeassistenten, Abstandsregeltempomaten, Abbiegeassistenten und vieler weiterer softwaregesteuerter Komponenten nicht vor, obwohl das Wettrennen um mehr Vernetzung und Automation in Fahrzeugen in vollem Gange ist.

Die Datenlage bei Softwarefehlern in Fahrzeugen ist aber Gegenstand von wissenschaftlicher Forschung. Wir sprachen mit Klaus Rüdiger Bährle, der am Karlsruher Institut für Technologie (KIT) Wirtschaftsingenieurwesen studiert hat und sich mit Fragen von Fehlern in Software von Fahrzeugen und softwarebedingten Rückrufen auseinandersetzt.

Funktionale Sicherheit in Fahrzeugen

netzpolitik.org: Herr Bährle, Sie haben jüngst Ihre Masterarbeit mit dem Titel „Marktanalyse zu sicherheitskritischer Software in der Automobilbranche“ geschrieben. Sie untersuchen darin Fragen zur „safety“ bei Fahrzeugen. Was ist bei sicherheitskritischer Software in Autos der Unterschied zwischen „safety“ und „security“? Und welche Probleme in Bezug auf Software haben Sie überhaupt betrachtet?

Klaus Rüdiger Bährle: Im Deutschen gibt es nur einen Begriff, nämlich „Sicherheit“. Er ist für den Bereich der Automobilindustrie oder auch in anderen Industriezweigen bisher nicht ausreichend klar definiert. Man muss unterscheiden zum einen zwischen der funktionalen Sicherheit, die alle Gefahrenmuster betrachtet, die durch das System verursacht werden, und zum anderen die IT-Sicherheit, wo es um Angriffe auf das System selbst geht. Die meisten Leute haben die IT-Sicherheit im Kopf, wenn sich etwa jemand in Computersysteme einhackt. Die funktionale Sicherheit geht aber in eine ganz andere Richtung: Es geht darum, dass die Software von sich aus keine sicherheitskritischen Fehler verursacht, damit also keine Menschen gefährdet.

netzpolitik.org: Aktuell wird über einen Tesla-Unfall berichtet, bei dem der Fahrer starb. Die Einordnung, ob es ein „safety“- oder „security“-Fehler war, ist wahrscheinlich ziemlich klar?

Klaus Rüdiger Bährle: So wie es berichtet wurde, ist es ziemlich klar eine Frage der funktionalen Sicherheit, also „safety“. Es wurde nichts darüber berichtet, dass jemand das Auto gehackt hätte, das wäre dann ein Zusammenspiel zwischen „safety“ und „security“. Gerade bei Tesla ist dieses Zusammenspiel durchaus eine Frage: Tesla führt Over-The-Air-Updates aus, während das in der gesamten Branche noch kein Thema ist. Updates werden sonst klassisch per Stecker eingespielt.

netzpolitik.org: Nun wurde um diesen Vorfall zwar viel Brimborium gemacht, aber können wir festhalten, dass das auf keinen Fall der erste Todesfall von einem Menschen ist, der im Laufe der Jahre auf Softwarefehler in Autos zurückzuführen ist?

Klaus Rüdiger Bährle: Ja, wobei es da keine Zahlen gibt …

netzpolitik.org: … natürlich nicht, das ist ja gerade Teil des Problems …

Klaus Rüdiger Bährle: … aber es gibt einen Fall, der bekannt ist: Das ist der Fall Toyota mit dem Gaspedal und der unbeabsichtigten Beschleunigung. Das war eine große Rückrufaktion, die für einiges an Aufregung gesorgt hat in der Presse wegen der Fußmatten. Toyota hatte falsche Fußmatten eingebaut und deshalb klemmte das Gaspedal. Das war aber nur der erste Fehler, denn nachdem die Fußmatten ausgewechselt waren, gab es wieder Probleme: Da waren es dann die Gaspedale selbst, die sich verklemmt hatten. Das war aber nur die nächste Ursache, die man vermutet hatte. Dann hatte man die Gaspedale gewechselt, danach liefen die großen Schadensersatzklagen. Als die vorbei waren, gab es aber noch weitere Fehler. Und da kam dann raus, dass es Softwarefehler waren. Allerdings handelte es sich dann nur noch um Einzelfälle, weshalb es nicht mehr so groß durch die Medien ging. Da gab es lange Gutachten von der NASA, die beauftragt wurde, die Fehler zu analysieren, und auch Stellungnahmen von Privatgutachtern. Dadurch kam heraus, dass die Toyota-Software ziemlich viele Fehler hat, so dass man davon ausgehen kann, dass tatsächlich die Software diese unbeabsichtigte Beschleunigung hervorgerufen hat, die zu mindestens einem Toten und einem Schwerverletzten führte. Wieviel von den vorherigen Todesfällen wirklich auf die Fußmatten zurückzuführen sind und wieviele Softwarefehler waren, das weiß man natürlich nicht mit Sicherheit. Zu vergleichbaren Fällen gibt es schlicht und einfach keine Informationen.

Herausfinden, was der Fehler war

netzpolitik.org: In unserer Recherche sind wir auf eine ähnlich schlechte Datenlage gestoßen. Wie würden Sie denn grundsätzlich die Datenlage bei Softwarefehlern in Fahrzeugen einschätzen? Wird sie besser, ist sie gleichbleibend schlecht, können Sie einen Trend ausmachen?

Klaus Rüdiger Bährle: Also einen Trend kann ich man nicht ausmachen. Wenn man sich auf die behördlichen Daten fokussiert, dann sind Rückrufaktionen ein großer Punkt: Da gibts keine sinnvollen Analysen, denn die Auswertungen sind anachronistisch in dem Sinne, dass alle Elektronikfehler in einer Kategorie zusammengefasst werden – unabhängig davon, ob in Europa oder in den USA. Diese beiden Gebiete habe ich untersucht. Das ist also ein großer Block „Elektronikfehler“. Man kann anhand der behördeneigenen Auswertungen nicht genauer herausfinden, was der Fehler sein soll. Es ist nicht immer klar definiert, was Elektronik ist und was die anderen Kategorien sind. Das heißt, dass es nur Rohdaten gibt, die wiederum nur für die USA wirklich brauchbar sind. Für den europäischen Markt sind sie sehr lückenhaft, die Beschreibungen sind kurz und oberflächlich. Da findet man nur heraus, dass es einen Rückruf gab, weiß aber in Europa gar nicht, worum es bei dem Rückruf ging. In den USA ist die Datenlage besser, die haben auch ein längeres Register bei Rückrufen. Schon seit den 1960er Jahren werden die Rückrufe da offiziell durchgeführt. In Deutschland gibt es sowas erst seit 1997, und in der EU ist es seit 2001 verankert.

netzpolitik.org: Sie forschen am Karlsruher Institut für Technologie (KIT) über Software-Qualitätssicherung und haben mehr als zwanzig Unternehmen und Organisationen und deren Experten in Interviews befragt. Welche Fragen haben Sie ihnen gestellt?

Klaus Rüdiger Bährle: Es waren sogenannte Experteninterviews in zwanzig Unternehmen mit insgesamt dreißig Personen. Diese qualitativen Interviews waren aufgrund des Themas sehr breit gestellt, weil wir wissen wollten, wie die generelle Tendenz in der Branche ist. Auch abseits der Rückrufe ist die Datenlage nicht besonders gut. Es gibt zwar viele theoretische Arbeiten bezüglich Normen, die sich auch damit beschäftigen, wie man diese Normen umsetzen kann oder auch wie man die Normen und verschiedenen Standards kombinieren kann. Es gibt aber kaum Forschung darüber, wie und welche Normen und Entwicklungsmethodiken umgesetzt werden. Die vorhandene Forschung hingegen bezieht sich mehr auf die Fragen, wie man es machen sollte.

netzpolitik.org: Sie haben beispielsweise konkrete Fehlerarten und Gefahren, die davon abgeleitet sind, abgefragt. Können Sie die Antworten der Experten zusammenfassen?

Klaus Rüdiger Bährle: Zuerst ist festzuhalten: Die meisten wissen die Fehlerursache selbst nicht, und wenn sie es wissen, dann ist es vertraulich.

Vertrauliche Informationen

netzpolitik.org: Welche Interessen in dieser Branche sind es, die eine Offenheit nicht zulassen?

Klaus Rüdiger Bährle: Man ist einerseits natürlich darauf bedacht, die Informationen, soweit sie nicht zu Rückrufen geführt haben, vertraulich zu halten, einfach um den eigenen Ruf zu schützen. Das ist auch bis zu einem gewissen Grad verständlich. Bei Rückrufen selbst kann man das natürlich nicht machen. In den USA kann man in diesem Fall sogar den Schriftverkehr zwischen Behörden und Herstellern nachlesen, der bei einem Rückruf geführt wurde. Das ist in Europa nicht der Fall.

netzpolitik.org: Ist auch die Meldekultur eine andere? In den Vereinigten Staaten wenden sich ja viele Besitzer von Autos selbst an die Behörde, was bei uns nicht so üblich ist.

Klaus Rüdiger Bährle: Die Besitzer selbst können in den USA Fehler melden. Das geht bei uns auch, aber wird nicht so oft gemacht. Wobei die Durchführung der Rückrufe in den USA ganz anders ist: Die Rückrufdurchführung ist für den Fahrzeughalter nämlich nicht verpflichtend. Das ist in Europa durchorganisierter. Hier wird – gerade auch in Deutschland – mittels ID über das zentrale Fahrzeugregister (ZFZR) jedes einzelne Fahrzeug zurückgerufen.

netzpolitik.org: Bei welchen Softwarefehlern in Fahrzeugen kommen Rückrufe vor?

Klaus Rüdiger Bährle: Das Problem ist, dass es häufig gar nicht klar ist, was für ein Fehler Ursache ist: Das wissen die Hersteller oft selbst nicht. Das setzt erstmal Ursachenforschung voraus. Wenn man sich nicht einhundertprozentig sicher ist, dass die Software die Ursache ist, wechselt man beispielweise eher das ganze Steuergerät aus, um den Fehler zu vermeiden, und untersucht die ursachen gar nicht erst näher. Wenn man weiß, dass es Software ist, hat man immer noch das Problem, dass man zwar weiß, dass man den Fehler beheben muss, aber noch keine Aussage darüber hat, was es genau war. Zumindest dokumentiert man nach außen nicht, was genau der Fehler war.

netzpolitik.org: Sie haben in Ihrer Arbeit klar herausgearbeitet, dass die softwarebedingten Rückrufe stark zunehmen. Das ist ein Trend, der sich über die letzten dreißig Jahre abzeichnet. Was sind die Ursachen für diesen Trend?

Klaus Rüdiger Bährle: Für die softwarebedingten Fehler ist die Hauptursache der zunehmende Softwareumfang, der ist natürlich durch Assistenzsysteme extrem angestiegen. Aber auch die Komplexität und die Vernetzung der Steuergeräte spielen eine Rolle. Beim autonomen Fahren wird das nochmal mehr, daher werden Rückrufe wegen softwarebedingter Fehler noch stärker ansteigen. Es ist hier kein Ende abzusehen, und die Software hat zudem ihren Stellenwert geändert: Mittlerweile ist die Software auch für das Marketing relevant. Man verkauft ein neues Auto auch wegen des Assistenzsystems. Es gibt keinen Hersteller mehr, der nicht in diese Richtung wirbt.

netzpolitik.org: Wird also sowohl in den Vereinigten Staaten als auch bei europäischen Herstellern bei der Vermarktung eine Kombination aus „safety“ und „convenience“ beworben?

Klaus Rüdiger Bährle: Ja, aber die Abgrenzung, was für die Sicherheit relevant ist, ist schwierig. Einerseits ist ein Assistenzsystem immer sicherheitskritisch, andererseits kann auch ein Navigationssystem sicherheitskritisch sein. Manche Hersteller stufen auch Navis als sicherheitskritisch ein. Für den Käufer wird natürlich beides beworben, allerdings abhängig davon, wer die Zielgruppe und welches Fahrzeugsegment betroffen ist.

netzpolitik.org: Bei den pilotierten Systemen, die in Oberklasse-Fahrzeugen in Deutschland schon dieses Jahr angeboten werden, zielt man auf das teure Marktsegment. Wie wird sich das auswirken auf Softwarefehler, wenn das Fahrzeug selbst die Steuerung übernimmt?

Klaus Rüdiger Bährle: Die Bedeutung der „safety“ wird zunehmen. Es wird quantitativ immer mehr Software verbaut und daher immer mehr Fehler geben. Der Punkt ist eher auf der juristischen Seite: In dem Moment, in dem das Auto selbständig fährt und der Fahrer nicht mehr eingreift und nicht mehr die Kontrolle hat, muss man sich überlegen, wie man das juristisch abbildet, wenn der Fahrer nicht mehr verantwortlich ist. Das ist aber keine technische Frage. Es wird immer mehr Software in Autos geben, die Entwicklungszyklen werden aber nicht länger. Also muss man mehr Software in kürzerer Zeit entwickeln. Mit dem teilautonomen und autonomen Fahren steigt zudem die Komplexität der Software.

netzpolitik.org: Der Tesla-Fall macht deutlich, dass es um ein nur als pilotiertes System beworbenes Assistenzsystem ging, bei dem rechtlich vollkommen klar ist, dass der Fahrer stetig aufmerksam sein muss. Das System übernimmt zwar die Kontrolle, rechtlich ist der Hersteller aber nicht haftbar, denn die Verantwortung trägt zu jedem Zeitpunkt der Fahrer.

Klaus Rüdiger Bährle: Es ist bei Tesla eine juristische Frage, technisch betrachtet sind vielleicht noch die Sensoren im Lenkrad interessant, die prüfen, ob der Fahrer das Lenkrad regelmäßig anfasst. Es gibt auch andere Tendenzen: Volvo etwa, der in einer Testphase des Autopiloten als Hersteller die Verantwortung übernimmt.

netzpolitik.org: Wie ist eigentlich die Rolle der Zulieferer bei Softwarefehlern? Zulieferer sind ja verantwortlich für verschiedene Komponenten, die dann eingebaut werden.

Klaus Rüdiger Bährle: Das ist eine sehr spannende Frage, weil die Zulieferer einen großen Anteil an der Software haben. Man kann nicht genau sagen, wie hoch der Anteil ist, weil es kaum messbar ist. Niemand weiß genau, wo wieviel Software prozentual herkommt, aber auf jeden Fall herrscht Einigkeit darüber, dass die Zulieferer eine große Rolle spielen. Das Problem bei Software ist natürlich auch, dass Software in zweierlei Form auftreten kann, einmal als Quelltext und einmal als fertig kompilierte Software. Die Tendenz ist: Es wird nur die fertige Software herausgegeben, zusammen mit der Hardware, so dass die Qualitätssicherung des Fahrzeugherstellers bei zugelieferter Software nur als „black box“-Test erfolgen kann. Man schaut also nicht immer in den Quelltext.

netzpolitik.org: Liegt das an den Lizenzen?

Klaus Rüdiger Bährle: Es gibt die Möglichkeit, dass der Vertrag bestimmt, dass der Quelltext mitgeliefert wird. Es gibt aber auch die Möglichkeit, dass dem Hersteller auf Verlangen vor Ort Einsicht gewährt werden muss. Und es gibt die Variante, dass es gar keine Einsicht gibt. In dem Fall, dass die Einsichtnahme vor Ort passiert, gibt es natürlich Zeitdruck: Man kann nicht alles prüfen und muss abwägen, was genau man untersuchen will.

Weniger Software einsetzen?

netzpolitik.org: Generell ist Qualitätssicherung teuer, es besteht ein Zielkonflikt.

Klaus Rüdiger Bährle: Das Besondere bei Software ist, dass man eine Software mit der heutigen Komplexität als „black box“ kaum erfassen kann, man muss auf die richtige Dokumentation hoffen.

netzpolitik.org: Wo sind aus Ihrer Sicht die größten Potentiale, um softwarebedingte Fehler zu verhindern oder zumindest erkennbar zu machen?

Klaus Rüdiger Bährle: Zum einen liegen sie natürlich darin, weniger Software einzusetzen. Das ist aber ein Problem, denn man hat die einfachste Lösung ausgeschlossen: Man will mehr Software, man will Innovation. Das heißt, dass man sich damit abfinden muss, dass es immer mehr Software in Autos gibt. Zwei andere mögliche Ansatzpunkte: Man verlängert die Entwicklungszyklen. Das hat man aber auch ausgeschlossen, man will nicht langsamer werden. Die zweite Variante ist, dass man bei der Qualitätssicherung schneller werden muss. Da ist dann der Stichpunkt Automatisieren, also möglichst automatisiert Fehler ausfiltern und den Rest manuell bearbeiten.

netzpolitik.org: Ist die Incentivierung in den Vereinigten Staaten durch die drohenden hohen Schadensersatzforderungen eine andere als in Europa?

Klaus Rüdiger Bährle: Nein, würde ich nicht sagen. Es ist allerdings schwer zu sagen, weil man nicht in die vertraulichen Bereiche vordringen kann. Tendenziell werden bei uns Normen und Standards sehr stark betont. In den USA ist das nicht ganz so verbreitet, was aber nicht heißt, dass die Software besser oder schlechter ist. Prinzipiell sehe ich da keine Tendenz.

netzpolitik.org: Befürworten Sie eine Meldepflicht für softwarebedingte Fehler? Wenn ja, wie sollte sie gestaltet sein?

Klaus Rüdiger Bährle: Die Meldepflicht haben wir ja im Grunde durch die Rückrufe schon …

netzpolitik.org: … nach Ihrer Auswertung ist sie allerdings nicht sehr aussagekräftig.

Klaus Rüdiger Bährle: Richtig, wobei die Frage ist, welche Daten man rausgeben sollte. Es sollte eine Beschreibung dazu sein, was wirklich defekt ist. Prinzipiell müsste man auf jeden Fall drei Aspekte abdecken: Was ist das Problem, was ist die Gefahr und was wird unternommen, um das Ganze zu beseitigen? So in der Art ist es in den US-Datenbanken – Problem, Gefahr, Abhilfe. In Europa ist das nicht enthalten, das sollte geändert werden. Meldepflichten bei Softwarefehlern ohne Rückrufaktion halte ich für unrealistisch, denn das würde ja bedeuten, dass Hersteller jeden Fehler, der irgendwo mal auftritt, melden müsste.

netzpolitik.org: Gibt es aus Ihrer Sicht Forderungen an die Autohersteller?

Klaus Rüdiger Bährle: An die Hersteller richtet sich die Forderung, dass sie ihre Qualitätssicherung einhalten. Man müsste weitere Qualitätskriterien für Fahrzeuge entwickeln. Bei Software gibt es ja generell Bemühungen auf wissenschaftlicher Seite, die Qualität von Software besser zu bewerten. Das ist aber noch weit entfernte Zukunft. Das wäre natürlich ein riesiger Schritt, wenn man messen könnte, wie gut Software ist.

netzpolitik.org: Was wären Ihre Forderungen an die Politik?

Klaus Rüdiger Bährle: Bei der Politik gibt es sicherlich Ansatzpunkte, die Qualität stärker zu betonen. Priorität sollte sein, dass Software in Fahrzeugen sicher ist. Politisch lässt es sich aber wohl besser verkaufen, wenn man die Hersteller zu mehr Umweltfreundlichkeit anregt.

netzpolitik.org: Mal angenommen, Sie könnten auf die politische Regulierung Einfluss nehmen,
was konkret würden Sie fordern für die nahe Zukunft, also drei bis fünf Jahre?

Klaus Rüdiger Bährle: Das ist eine sehr gute Frage. Es gibt wohl nicht diese eine Forderung. Die abstrakte Forderung wäre: Wir brauchen Software-Qualität, und das Fahrzeug muss sicher sein für den Fahrer. Das Problem ist, dass man Qualitätsmaßnahmen nur schwer definieren kann, wenn man die Qualität nicht messen kann.

netzpolitik.org: Haben Sie zufällig kürzlich ein Auto gekauft?

Klaus Rüdiger Bährle: Nein.

netzpolitik.org: Wenn Sie eins kaufen würden, was für eins wäre das?

Klaus Rüdiger Bährle: Ein altes.

netzpolitik.org: Heißt das, dass sich durch Ihre Forschung auch Ihre Sicht als Autokäufer verändert hat?

Klaus Rüdiger Bährle: Eigentlich nicht. Ich habe auch einen Hang zu alten Autos. Aber ich warte zumindest so lange ab, bis das Auto nicht mehr ganz neu ist.

netzpolitik.org: Vielen Dank, dass Sie uns für dieses Gespräch zur Verfügung standen.

Klaus Rüdiger Bährle ist Wirtschaftsingenieur. Der Titel seiner Masterarbeit lautet „Marktanalyse zu sicherheitskritischer Software in der Automobilbranche“.

Bährle führte für die Arbeit Experteninterviews mit Personen aus Unternehmen und Organisationen der Automobilbranche sowie deren Versicherer, Zulieferer und Entwicklungsdienstleister, um Trends und Problemfelder zu analysieren. Er wertete zudem vorhandene Daten über Rückrufe in den Vereinigten Staaten und Europa aus.