Ich fahre Auto, höre über die Bluetooth-Verbindung zwischen Handy und Autoradio einen Podcast. Es klingelt. Ich telefoniere. Auf einmal ist das Gespräch weg.
Verbindung unterbrochen. Ich versuche, wieder anzurufen. Die Bluetooth-Verbindung zwischen Autoradio und Smartphone ist abgerissen. Der Podcast lässt sich starten, aber ich höre nichts davon durch die Lautsprecher des Autos.
Dank der Spracherkennung, denke ich, rufe ich wieder an, doch ich höre die Stimme des Smartphones nur auf dessen kleinen Lautsprecher.
An der nächsten Ampel schalte ich Bluetooth am Smartphone aus und wieder an. Keine Verbesserung. Ich schalte das Autoradio aus und wieder ein. Keine Verbesserung.
Die Ampel wird grün, ich fahre weiter, immer noch ohne Verbindung zwischen Smartphone und Autoradio. An einem Rastplatz an der Autobahn fahre ich kurz raus, halte und schalte den Motor ab und ziehe den Zündschlüssel.
Nachdem ich den Motor neu gestartet habe, ist der Spuk vorbei. Autoradio und Smartphone vertragen sich wieder.
Wo ist Ihnen schon einmal vergleichbares passiert?
Enge Verzahnung von Systemen
Das Erlebte finde ich… beunruhigend. Als Informatiker kenne ich durchaus den Lösungsansatz, ein nicht mehr funktionierendes Programm neu zu starten, und gegebenenfalls auch den ganzen Computer neu zu starten.
Doch ich möchte nicht das Auto neu booten müssen.
Es reicht offensichtlich bei manchen Systemzuständen nicht aus, das Autoradio auszuschalten, weil es dadurch nicht wirklich ausgeschalten ist, sondern nur so tut als wäre es aus. Das Autoradio ist wohl ein ganz elementarer Bestandteil des Autos und kann während der Fahrt nicht vollständig abgeschaltet werden. Warum?
Ich habe also mein Auto neu gebootet. Dazu musste ich aber eben anhalten, denn das einfach so auf der Autobahn zu tun ist eher keine gute Idee.
Wie stark interagieren die Systeme im Auto heute schon, und wie wird das erst, wenn es eben nicht nur eine Komfortfunktion wie das Audiosystem betrifft, sondern eine autonome Steuerung des Fahrzeugs?
Sicherheitsrelevanz
Sie kennen vielleicht die verschiedenen Kritikalitätslevel der ISO 26262, der Norm, die sich mit funktionaler Sicherheit im Automobil beschäftigt. Da bleibt nur zu hoffen, dass die Systeme dann auch wirklich gut voneinander getrennt und abgeschirmt werden. Wie wird es jedoch, wenn viele Teile der Infrastruktur im Auto, die derzeit nur für Komfortfunktionen verwendet werden, in Zukunft auch für essentielle Steuerungsaufgaben benötigt werden?
Das erfordert, dass mehr und mehr Teile des Systems eben nach ISO 26262 betrachtet und entwickelt werden. Der Umfang und damit die Komplexität des sicherheitsrelevanten Teils der Fahrzeugsoftware werden deutlich zunehmen.
Das Auto als »Cyber-Physisches System«, wie es derzeit gern postuliert wird, verknüpft Technologien, die bislang in ganz unterschiedlichen Zusammenhängen gewirkt haben, und deshalb auch ganz unterschiedliche Stabilität aufweisen.
Dies ist ja eben schon am Zusammenspiel Autoradio und Motorsteuerung zu sehen: Das Soundsystem hat sich seltsam verhalten und nicht mehr die ihm zugedachte Funktion korrekt erfüllt.
Dies hat sich aber nicht auf das Fahrverhalten ausgewirkt. So gesehen sind die Systeme funktional entkoppelt, wie es sein soll. Und dennoch konnte ich das Soundsystem nicht vollständig aus- und wieder anschalten.
Auto-Funktionen im Smartphone?
So schwer kann das nicht sein, eine App aufs iPhone laden und schon kann das Auto mehr – das mag für Infotainmentaufgaben zutreffen, und selbst da ist, wie ich am eigenen Leib erfahren durfte, das Risiko gegeben, dass eine Fehlfunktion dieses Zusammenwirkens vom eigentlichen Fahren ablenkt.
Wer aber denkt, er könne dem Smartphone auch Navigationsaufgaben übertragen, die vielleicht dann auf ein Fahrerassistenzsystem wirken, liegt eher falsch. Weil Software nicht gleich Software ist.
Verschiedene Arten der Entwicklung
Eine Smartphone-App kann binnen weniger Wochen entwickelt werden, ein Auto braucht auch heute noch viele Monate. Zwar sinkt dank Model-Based Design die Dauer immer weiter , ein deutlicher Unterschied bleibt aber bestehen.
Das liegt nun weniger an der reinen Funktionalität, sondern am Entwicklungsprozess.
Eine App lassen Sie üblicherweise nicht zertifizieren, und auch die Hardwareplattform darunter ist nicht zertifiziert hinsichtlich funktionaler Sicherheit. Getestet, ja. Hoffentlich auch gut getestet. Doch wenn die App eben in einem bestimmten Kontext abschmiert, dann ist das eben so und keiner wird verletzt.
Ein Auto wird Teilsystem für Teilsystem intensiv geprüft. Zuerst auf Modellebene, dann auf Softwarebene, dann auf dem Zielprozessor, dann im Zielsystem, dann im Netzwerkverbund. Hersteller und Zulieferer nutzen Methoden wie Model-Based Design, um die Funktionalität zu isolieren und korrekt zu implementieren. Es gibt Design Reviews und begleitende Artefakte, die sicherstellen sollen, dass das Entwicklungsteam an alles gedacht und alle geplanten Schritte durchlaufen hat.
Das bedingt auch, dass ein Steuergerät nicht mehr von einem oder wenigen Ingenieuren entwickelt wird, sondern von einer ganzen Armada.
Appifizierung
Architekturen für automobile Steuergeräte wie AUTOSAR sollen mehr Portabilität und vor allem Flexibilität bringen beim Integrieren von Funktionen – Apps – auf Steuergeräte.
Es soll leichter möglich werden, neue Funktionen, Anwendungen auch nach Auslieferung des Fahrzeugs einzuspielen, indem die Anwendungen besser von der Hardware getrennt werden. Weiter gedacht sind dies die Apps für Steuergeräte. Dass dafür massiv von Simulation gebrauch gemacht wird, wird immer deutlicher.
Wir (=die Gemeinschaft der Embedded-Software-Entwickler und Toolhersteller) werden uns noch einige Gedanken machen und Lösungen entwickeln dürfen, wie diese neu und nachträglich in den Steuergeräteverbund eingebrachten Software-Bausteine bei aller Kommunikation so voneinander getrennt werden, dass die Fehlfunktion einer Komponente keine oder zumindest nicht größere Auswirkungen auf andere Komponenten hat.
Dazu – um den Kreis zu schließen – gehört auch, dass ich eine Anwendung auch wieder neu starten kann oder sie noch besser automatisch neu gestartet wird, ohne das gesamte Fahrzeugsystem neu starten zu müssen. So wie ich möchte, dass mein Autoradio bei einem Bluetooth-Fehler nach zweimaligem Druck auf den Ein/Aus-Knopf wieder funktioniert, ohne rechts ranfahren und Zündschlüssel drehen.
5 Fragen, die Sie sich beim Entwickeln von Systemen stellen sollten
Sie Entwickeln ein System. Vielleicht nicht als Programmierer, vielleicht nichteinmal in Software. Aber ein System. Oder ein Teil eines Systems. Das kann auch eine (Unter-)Organisation sein, ein Prozess, eine Schulung, ein Buch. Irgendeine Art von abgeschlossenem Projekt.
Um nicht zu Resultaten zu kommen wie ich mit Bluetooth im Auto erleben durfte, könnten folgende 5 Fragen helfen:
- Inwieweit ist Ihr Teilsystem abhängig von anderen Systemteilen? Kann irgendein externer Umstand dazu führen, dass Ihr System nicht mehr in einen definierten Zustand zurückkehren kann?
Diese Frage soll klären, wie gut Ihr System von der Außenwelt entkoppelt ist, und inwieweit externe Signale plausibilisiert, also auf Sinnhaftigkeit geprüft werden.
- Inwieweit wirkt Ihr System auf andere Teile des Systems? Kann eine Fehlfunktion Ihres Systems zu einer Fehlfunktion eines anderen Systems führen?
Die Antwort auf diese Frage erörtert, wie »rüpelhaft« Ihr System beschaffen ist. Welche Fehler werden innerhalb abgefangen, welche Fehler gelangen nach draußen?
- Kann Ihr System lokal neu initialisiert werden? Können Sie einen Grundzustand des System aus sich selbst heraus wieder herstellen, oder braucht es dazu einen Impuls von außen?
Es geht immer etwas schief. Ihre Software-Komponente hängt sich auf. Kann sie sich selbst neu starten, und kann sie isoliert vom Rest des Systems neu gestartet werden? Ihr Team möchte einen Prozess-Schritt erneut durchführen. Darf es das, oder müssen andere Teams involviert werden, obwohl nicht wirklich betroffen?
- Was kann in der Kommunikation Ihres Systems mit der Außenwelt falsch laufen? Wie merken Sie das, und wie können Sie den Fehler lokal behandeln und die Kommunikation neu aufsetzen?
In jeglicher Kommunikation können Missverständnisse entstehen. Dies gilt sowohl in formaler, elektronischer Kommunikation zwischen zwei technischen Systemen, als auch zwischen Menschen (da besonders) und allen anderen Kombinationen.
Wie merkt Ihr System, Ihr Prozess, Ihr Projekt das? Wie setzen Sie die Kommunikation dann neu auf oder klären das Missverständnis? Brauchen Sie einen externen Schiedsrichter oder geht es intern?
- Letztendlich geht es um eine Frage: Wie robust ist Ihr System, sowohl gegenüber internen als auch externen Einflüssen?
Robustheit ist eine Systemeigenschaft, eine Prozesseigenschaft, die ein System unanfällig macht. Bei Menschen oder Organisationen kennen Sie vielleicht auch den Begriff Resilienz, also Widerstandsfähigkeit.
Wie sehen Sie das? Bekommen wir das hin?
Und wo ist Ihnen schon seltsames, scheinbar unerklärliches mit elektronischen Geräten passiert?
Lassen Sie die anderen Leser ebenso wie mich teilhaben an Ihren Gedanken und kommentieren Sie!
Photo: Joachim Schlosser, License Creative Commons Attribution Share-Alike
Disclosure: Ich arbeite bei MathWorks, dem Hersteller von MATLAB & Simulink, und verdiene meinen Lebensunterhalt durch die Fähigkeit der Software, bei der Lösung einiger der beschriebenen Aufgabenstellungen zu helfen. Dieser Artikel gibt meine persönliche Meinung wieder und stellt keine offizielle Verlautbarung dar.
Schreiben Sie einen Kommentar