Autonomes Fahren: Software tötet Menschen

Letzte Woche ist etwas sehr Wichtiges passiert: Der erste tödliche Unfall unter Beteiligung eines autonomen Fahrzeugs. Abgesehen von der Trauer um einen Menschen wirft der Unfall viele Fragen auf, die die Zukunft des Automobils und des Autonomen Fahrens betreffen – oder zumindest die zukünftige Entwicklungsrichtung. Nebenbei wirft das Geschehen die Frage nach der Arbeitsweise von Software- und Mechanikentwicklern auf.

Dass wir Maschinenbauer oft nicht das allerbeste Image haben, daran haben wir uns seit Studienzeiten gewöhnt. In den letzten Jahren ist der Druck von außen allerdings noch einmal stärker geworden, es geht nicht mehr nur um fragwürdigen Kleidungsgeschmack und Frisuren: Immer stärker gewinnt die Software an Wichtigkeit gegenüber der Mechanik und nicht nur das, auch die Arbeitsweise des Softwareentwicklers wird dem Maschinenbauer als Vorbild vermittelt.

Entwicklungsphilosophien wie Scrum und Agile sollen in den Mechanikbereich übernommen werden, das Bild ist klar: Auf der einen Seite die langsamen, übervorsichtigen Mechanikentwickler, auf der anderen Seite die Softwareprogrammierer, die schnell vorangehen, „einfach mal einen Prototypen raushauen“ und sich dann erst später um Fehlerbeseitigung kümmern. In der Mechanik ist jede Revision ein großer Akt, in der Softwareentwicklung werden Versionen in schnellem Takt produziert.

Doch es hat schon seinen Sinn, wenn man in der Mechanik etwas ruhiger und bedachter an die Entwicklung eines Produkts herangeht. Die Folgen, wenn eine Maschine oder ein Produkt nicht so funktioniert, wie man es erwartete, sind im günstigsten Fall hohe Kosten, im ungünstigsten Fall sterben Menschen. Während eine fehlerhafte Software üblicherweise nicht viel mehr nach sich zieht als etwas Ärger beim Benutzer und einen Neustart des Rechners.

Seit der Erfindung des Rads müssen sich Maschinenbauer beziehungsweise Techniker oder Erfinder mit diesen doofen Naturgesetzen herumschlagen und damit, dass Maschinen explodieren, zerbrechen, Unfälle verursachen und so weiter. Die Softwareentwicklung dagegen hatte lange Zeit wenig Verbindung zur realen Welt – wie gesagt hatten Softwarefehler wenig physische Konsequenzen.

So bildeten sich zwei unterschiedliche Entwicklungskulturen heraus, die dem jeweiligen Produkt angepasst sind: Im Maschinenbau wird mit Sicherheitsfaktoren gearbeitet, die immer größer 1 sind – was zur bewussten Überdimensionierung führt und eben auch zur Ausbildung redundanter Sicherheitssysteme. Das Produkt wird in der idealen Welt des Maschinenbauers so lange entwickelt, analysiert und getestet, bis es – nach menschlichem Ermessen – fehlerfrei ist.

In der Softwareentwicklung, vor allem in den modernen Entwicklungsphilosophien, werden möglichst schnell Prototypen zusammengeklatscht und diese in der Realität getestet. Mit den Jahren wurde der Umgang mit diesen Prototypen immer laxer, Firmen veröffentlichten Betasoftware, „Labs“ gaben dem Anwender bewusst Zugriff auf diese Betaversionen. Damit wurden unfertige Softwareversionen vom Ruch des Unfertigen befreit – wer ganz vorn sein will, arbeitet mit der Betaversion.

Das ist vielleicht etwas übertrieben, Fakt ist jedoch, dass in sehr vielen Fällen Software auf den Markt kommt, die die Grundanforderungen nicht erfüllt, es muss den Entwicklern also klar sein, dass die Software noch Fehler aufweist. Kein Problem, ein Update ist ja schnell verteilt.

Softwarephilosophien in der Mechanikentwicklung? Das kann ins Auge gehen.

Doch derzeit ändert sich die Welt, in der Maschinenbauer, aber auch Softwareentwickler sich bewegen, radikal: Industrie 4.0, IoT und eben auch das selbstfahrende Auto bringen Software in die reale Welt und damit auch die Softwareentwickler in eine Verantwortung, in der sie bisher nicht waren.

Und so konnte es zum ersten tödlichen Unfall eines selbstfahrenden Autos kommen. Die Autopilot-Funktion wird von Tesla selbst als „Beta“ bezeichnet, andererseits aber per Over-the-Air-Update automatisch in allen Tesla-Fahrzeugen installiert. Doch wie Auto-Papst Ferdinand Dudenhöffer in einem sehenswerten ARD-Interview sagt: „Autos sind keine Spielzeuge!“

Doch Tesla und sein Gründer Elon Musk scheinen in der Software-Denkweise gefangen zu sein. Tragisch, dass jemand sterben musste, aber wir haben doch darauf hingewiesen, dass man bei Autopilot-Fahrt trotzdem aufmerksam sein muss. Und Tesla-Zulieferer Mobileye, der die Autopilot-Funktion entwickelt, erklärt, „dass seine aktuellen Systeme für Verkehrssituationen wie bei dem Crash nicht ausgelegt seien. Mobileye-Technologie solle querende Fahrzeuge erst ab 2018 erkennen, erklärte ein Sprecher“.

Da wendet sich der Maschinenbauer mit Grauen ab – eine grundlegende Sicherheitsfunktion wird nachgeliefert? Und bis dahin sterben Menschen, die das Produkt nicht den Richtlinien gemäß bedienen? Der Nutzungsfall „Unsachgemäße Bedienung“ ist ein Kernrequirement jeder verantwortlichen Produktentwicklung, Sicherheitsfunktionen wie Lichtschranken, Zweihandbedienung und anderes werden genau deshalb in Maschinen eingebaut. Wenn jeder Mensch den Richtlinien folgen würde, bräuchte man keine Lichtschranken.

Offensichtlich erkannte der Autopilot einen LKW, der quer über die Straße fuhr, nicht. Der Wagen prallte ungebremst in den Anhänger des LKW – beziehungsweise fuhr unten hindurch. Dabei wurden alle Teile des Autos und des Fahrers ab Windschutzscheiben-Unterkante abgetrennt.

Zunächst hieß es, die Kamera, habe die weiße Seitenwand vor dem hellen Himmel nicht erkannt. Später sagte Tesla: „Bei diesem Unfall führte die hohe weiße Seitenwand des Anhängers zusammen mit einer Radar-Signatur, die der eines hochhängenden Straßenschilds sehr ähnlich war, dazu, dass keine automatische Bremsung ausgelöst wurde.“ Nun sind weiße, hohe LKW nicht gerade selten im Straßenverkehr. Noch nachdenklicher macht mich, dass Redundanz bei Tesla offensichtlich falsch verstanden wird: Wenn die Frontkamera sagt „alles frei, ich sehe nichts“ und das Radar sagt: „Ich sehe eine Schilderbrücke“, ist das eine Diskrepanz zwischen den Sensordaten. Diese sollte den Steuerrechner eigentlich zum Schluss bringen, dass irgendetwas nicht stimmt. Dann sollte er eine Bremsung einleiten oder wenigstens einen Warnton auslösen, um dem Fahrer zu signalisieren, dass etwas nicht stimmt. Und nicht mit sich selbst einen Kompromiss aushandeln nach dem Motto „…wird schon nichts passieren.“

Die deutsche Automobilindustrie wird von Firmen wie Tesla und Google gern als altmodisch, träge und übervorsichtig angesehen. Vor dem Hintergrund des Unfalls zeigt sich, dass diese Vorsicht ihre Berechtigung hat. Ich bin der Ansicht, dass die Vorgehensweise beispielsweise von Daimler – Forschung am autonomen Fahren, aber Beschränkung auf bestimmte Einsatzszenarien wie das Kolonnenfahren von LKW auf der Autobahn – viel mehr Sinn mach – und sicherer ist – als einfach selbstfahrende Autos auf die Menschheit loszulassen.

Leute, überlegt Euch das mit dem Scrum und Agile im Maschinenbau bitte nochmal!

P.S.: Softwareingenieure, lest Euch bitte mal diesen Artikel genau durch: Das selbstfahrende Auto öffnet ein Büchse der Pandora, die den Softwareentwickler zum Herren über Leben und Tod macht – was dieser sicher auch nicht sein möchte. Aber dazu muss ich demnächst einen eigenen Artikel schreiben.

P.P.S. Vielleicht sollte man sich in den USA mal die Unterfahrschutzeinrichtungen ansehen, die solche tödlichen Unfälle bei uns verhindern.