Original-URL des Artikels: https://www.golem.de/news/agl-meeting-in-muenchen-einheitliches-linux-im-auto-hilft-den-herstellern-1609-123253.html    Veröffentlicht: 15.09.2016 12:00    Kurz-URL: https://glm.io/123253

AGL-Meeting in München

Einheitliches Linux im Auto hilft den Herstellern

Bereits heute setzen viele Pkw-Hersteller auf Linux. Mit dem AGL-Projekt möchte die Linux-Foundation helfen, den fragmentierten Markt zu vereinheitlichen sowie Kosten und Entwicklungszeiten zu sparen. Golem.de war auf dem Herbsttreffen vom 7. bis 8. September 2016 in München dabei.

"39 Monate", gibt Dan Cauchy auf dem vergangenen Treffen des Projekts Automotive Grade Linux (AGL) in München zu bedenken, "in dieser Zeit kommen drei Smartphone-Generationen auf den Markt!". Doch solange dauere derzeit die Entwicklung eines In-Vehicle-Infotainment-Systems (IVI) von der finalen Spezifikation bis zum ausgelieferten Fahrzeug. Cauchy, der Koordinator des Projekts bei der Linux Foundation, möchte diese Zeit jedoch mehr als halbieren. Nur noch 18 Monate bis zum fertigen Produkt soll die Zeitspanne künftig betragen.

Bekannte Firmen der Automobilbranche sind bereits Mitglied in der AGL-Arbeitsgruppe, etwa Toyota, Mazda, Ford, Honda, Nissan, Tata-Jaguar-Land-Rover, Mitsubishi, Subaru, Continental oder auch Visteon. Zudem delegieren viele weitere Zulieferer, Pkw-Hersteller und Elektronikkonzerne ihre Entwickler und Entscheider zu den Treffen der AGL. Oft nutzen diese bereits Linux, sind aber mit der mangelnden Flexibilität und Aktualität der häufig mit proprietären Komponenten durchmischten Embedded-Systeme unzufrieden.

Gemeinsame Basis für die Automobilindustrie

Ziel der AGL ist es daher, eine gemeinsame Linux-Basis, ein Framework für Apps und eine Sicherheits- und Update-Infrastruktur zu schaffen. Hacks wie beim Jeep Cherokee im vergangenen Herbst, der übrigens auch ein Linux-System nutzt, sollen damit deutlich erschwert, Updates im Falle von Sicherheitslücken erleichtert und deren Auswirkungen minimiert werden.



Als kleinen Bonus arbeitet AGL an einem Sortiment von Demo-Apps für Komfortfunktionen wie Klimaanlage, Heizung, Radio, Connectivity, Rückfahrkamera oder Mediaplayer. Cauchy erwartet, dass einige der in der Gruppe vertretenen Hersteller die Standard-Apps austauschen werden, andere lediglich Skins anpassen. Zumindest unter den anwesenden Entwicklern ist aber Konsens, dass einfache Schnittstellen wie für die Klimaregelung nicht ohne Not und zusätzlichen Mehrwert durch eigene ersetzt werden sollten.

Bereits die Demos der im Juli vorgestellten Version 2.0 "Brilliant Blowfish" machen einen weit fortgeschrittenen Eindruck, doch beim näheren Hinsehen, beim Besuch von Vorträgen und dem Gespräch mit Entwicklern fallen Baustellen auf und wichtige APIs, die noch in der RFC-Phase diskutiert werden, beispielsweise für Navigation oder Text-to-Speech. So steht das Treffen in München ganz im Zeichen der Arbeit an der zur CES 2017 geplanten Version 3.0 Charming Chinook und es entsteht der Eindruck, dass die zur CES geplante dritte große Veröffentlichung tatsächlich das Zeug dazu hat, von ersten Automobilherstellern als Grundlage eigener Systeme adaptiert zu werden. Doch bis dahin müssen noch einige Probleme gelöst werden.

Grundlage Tizen ist Segen und Fluch zugleich

Basis für die technische Plattform Automotive Grade Linux ist das von Samsung und Intel an die Linux Foundation übergebene Tizen IVI. Die primäre Methode, Apps für diese ursprünglich für Smartphones entwickelten Plattformen zu erstellen, sind Web-Apps mit HTML. Native Apps werden mit den Enlightenment Foundation Libraries (EFL) programmiert, die für den Enlightenment-Desktop entstanden sind. Dadurch wird, etwas überspitzt ausgedrückt, geringer Speicherbedarf mit komplizierter Programmierung erkauft.

Benötigt eine App über die vom Browser bereitgestellten Schnittstellen hinaus Zugriff auf Geräte oder Dienste, müssen Programmierer bei Tizen allerdings notgedrungen zu den schwieriger umzusetzenden nativen Apps greifen. Mit dem in München von Fulup Ar Foll und José Bollo vom bretonischen Unternehmen iot.bzh vorgestellten neuen App-Framework ist jedoch eine geschichtete Implementierung möglich: Die Oberfläche kann in HTML entwickelt werden, Hintergrunddienste werden als Binärkomponente bereitgestellt. Diese Trennung erleichtert auch die Zusammenarbeit zwischen den Designern der Oberfläche, die zunächst Dummy-Anwendungen in HTML und etwas Javascript entwickeln können, und den Entwicklern der Hintergrunddienste.

Als weiteres Grafiktoolkit für native Anwendungen wird Qt verwendet, das in der Automobilbranche seit Jahren recht weit verbreitet ist. Von vielen Entwicklern wird dies eher als Kompatibilitätslösung betrachtet, als Brücke zur leichteren Portierung bereits vorhandener Programme - und damit schnellerer "Time to market" für AGL-basierte Systeme. Letztlich ist es jedoch den Fahrzeugherstellern selbst überlassen, langfristig auf ein bestimmtes Framework zu setzen.

Kein Appstore

Trotz App-Infrastruktur, Signaturmöglichkeit und Konsens über das Paketformat für Apps, das eine Erweiterung des W3C-Widget-Archivformats ist, stößt die Frage nach einem einheitlichen Appstore auf Schulterzucken. Dafür seien letztlich die Fahrzeughersteller und -zulieferer zuständig. Immerhin, die Sicherheitsarchitektur des Anwendungsframeworks würde es zulassen, dass bestimmte Funktionen außer der vom Hersteller des Fahrzeugs signierten Apps zugänglich sind. Bei anderen Funktionen könnte der Zugriff laxer sein, so dass beispielsweise die App eines neuen Webradios schneller für verschiedene Fahrzeughersteller verfügbar sein kann.

Sicherheit wird großgeschrieben

Sehr durchdacht ist die nun festgeschriebene Sicherheitsinfrastruktur, die mit dem Mandatory-Access-Control-Framework Smack (Simple Mandatory Access Control Kernel) einen einfach zu konfigurierenden und dennoch fein granulierten Zugriff auf Daten, Gerätedateien, Sockets, aber auch Netzwerkverbindungen erlaubt. Busse wie CAN und MOST werden über eigene Proxies angesprochen, die exklusiven Zugriff auf die jeweiligen Geräte haben - dank Smack gibt es kein Vorbeikommen an diesem Proxy. Zusätzlich sorgt die Verwendung von Control-Groups (Cgroups) dafür, dass priorisierte Anwendungen nicht durch den Ressourcenbedarf von Apps ausgebremst werden. Künftige virtuelle Dashboards werden also Tacho, Drehzahl und wichtige Informationen zu Fehlfunktionen flüssig genug aktuell halten können, während eine gleichzeitig dargestellte Navigations-App auch ausgebremst werden darf.

Als weitere Lösung für das Prioritätsproblem präsentierte Woosung Kim bereits auf dem letzten AGL-Gipfel im Juli in Tokio, wie zwei virtualisierte Linux-Instanzen auf ein gemeinsames Display schrieben, korrekt überlagert mit einem Compositor. Zu diesem Szenario passt gut, dass die Spezifikationen des AGL die Verwendung eines Hypervisors explizit erwähnen, als weiteres Einsatzszenario wird hier der Start eines unprivilegierten Android-Systems erwähnt, das beispielsweise dazu dienen könnte, Medienplayer oder Social-Media-Apps anzuzeigen, während die Steuerung der Klimaanlage oder die Anzeige der Rückfahrkamera beim AGL verbleibt.

Ein Punkt, der bei vielen Entwicklern mit großer Zustimmung aufgenommen wurde, ist die Verwendung von OSTree für Updates und möglicherweise notwendige Rollbacks des Basissystems. Das Basissystem ist prinzipiell monolithisch, also ein als ganzes gebautes Dateisystemimage, wie es im Embedded-Bereich üblich ist. Daher ist wichtig, dass nur geänderte Dateien identifiziert und lediglich deren Unterschiede als binäres Delta ausgeliefert werden - aus dem alten Image und den bekannten Abweichungen kann so das neue Image aufgebaut werden. OSTree wird sonst häufig im Container-Bereich eingesetzt, zum Beispiel bei Updates von Docker-Containern. Im Automobilbereich erleichtert das Konzept die Auslieferung von oftmals nur wenigen Megabyte großen Updates "Over the Air" auch über schlechte Mobilfunkverbindungen.

Updates erfordern ein Umdenken

Trotz Sicherheitsmechanismen wie Smack bedeutet die Zusammenfassung vieler Steuerungsfunktionen eines Pkw, dass eingesetzte Systeme gepflegt und gegebenenfalls schnell mit Updates versorgt werden müssen. Die Generation von Softwareentwicklern, die an AGL mitarbeitet hat, ist sich dessen bewusst, fraglich ist allerdings, ob die Führungen großer Fahrzeughersteller unter Kosten- und Kursdruck genügend Kapazitäten für Updates von Modellen bereitstellen, die möglicherweise schon einige Jahre aus dem Verkauf sind oder gar bereit sind, Updates mit neuen Funktionen auszuliefern.

Dan Cauchy weiß um die Herausforderung, ist sich aber sicher: "Sie werden." Viele Hersteller hätten verstanden, dass Autos rollende Smartphones werden, daher sei die Bereitschaft gereift, Software selbst zu pflegen oder dies Zulieferer machen zu lassen. Auf unser Nachhaken, ob eine bei AGL angesiedelte Variante mit Langzeitpflege (LTS) und vertiefte Zusammenarbeit mit der Initiative zur Langzeitpflege (LTSI) des Kernels geplant sei, betont Cauchy, dass derzeit das Hauptziel auf "Rapid Innovation" liegt und dass das Ziel von AGL nicht ist, Geschäftsmodelle zu zerstören, sondern eine gemeinsame Basis für individuelle Entwicklungen zu liefern - künftige LTS-Versionen des gemeinsamen Basissystems schließt diese Aussage natürlich nicht grundsätzlich aus.

Gute Zusammenarbeit mit Kernel-Hackern

Einen weiteren für Updates relevanten Aspekt der Kernelentwicklung stellt Michael Fabry heraus, Produktmanager bei dem Unternehmen Microchip. AGL hilft demnach intensiv dabei, Treiber für Embedded-Hardware, die im Automotive-Bereich zum Einsatz kommt, in den Mainline-Kernel zu übernehmen. So sollen mittelfristig die teils sehr lax gepflegten Hersteller-Kernel durch Mainline-Kernel abgelöst werden. Fabry, der die Entwicklung von Linux-Treibern für seinen Arbeitgeber verantwortet, zeigt sich darüber begeistert: "Es ist faszinierend, wie schnell und zielführend die Integration unserer MOST-Treiber in den Kernel vonstattenging, nachdem Walt Miner [von AGL] den Kontakt zu Greg Kroah-Hartmann hergestellt hatte."

Dennoch bleibt die Frage nach der praktischen Umsetzung von Updates spannend. Egal, ob es eine LTS-Variante geben wird oder Pkw-Hersteller und Zulieferer für Updates sorgen. Während Smartphones und Tablets durchschnittlich nach etwa zwei Jahren ausgetauscht und sogar Router eher fünf bis sechs Jahre eingesetzt werden, liegt das Durchschnittsalter von Pkw in Deutschland derzeit bei 9,2 Jahren. Nutzungsdauern von 12 bis 15 Jahren sind demnach keine Seltenheit. Bislang konnte kein anderes mit Linux betriebenes Gerät derart lange Einsatzzeiten vorweisen. Aber: Linux-basiertes IVI ist seit etwa zwei Jahren Realität im Pkw, die Sicherheitsbilanz derzeit eher durchwachsen, das Update-Konzept schlecht bis schlicht nicht vorhanden, die Fragmentierung soft- und hardwareseitig enorm. Schlimmer werden kann es mit AGL immerhin nicht.

Autonomes Fahren? Wenn gewünscht!

Besonders kritisch werden diese Überlegungen vor allem mit dem Blick auf autonomes Fahren. Auf die Frage, ob es schon Ansätze dazu bei AGL gebe, antwortete Cauchy, dass derzeit keine konkreten Diskussionen geführt würden, dass aber "alles, was mit Linux im Auto zu tun habe, bei AGL richtig aufgehoben sei". Derzeit habe aber die Vervollständigung des Grundsystems und die Erweiterung um "Headup Display" und "virtuelles Cockpit" Vorrang. Beides soll bis zum nächsten Release zur CES 2017 im Grundsystem integriert und im aus echten Komponenten aufgebauten Simulator enthalten sein.

Bei der Version 3.0 spricht Cauchy von einem wichtigen Meilenstein, der "den Grad an Komplettheit erreiche, der benötigt werde, um von Pkw-Herstellern als Basis akzeptiert" zu werden. Aus der von Cauchy eingangs erwähnten Halbierung der Entwicklungszeit folgt damit, dass die Entwicklungen der nächsten Monate bereits einen sehr präzisen Ausblick auf die Infotainmentsysteme des Modelljahres 2019 geben.

Die Stimmung bei den beteiligten Automobilherstellern und Zulieferern ist entsprechend sehr gut. Die gemeinsame Basis verspricht eine schnellere Entwicklung, dennoch bleibt viel Platz für eine individuelle Konfiguration. Von der billigen 7-Zoll-Touchscreen-Lösung im Kleinstwagen bis hin zur Oberklasselimousine mit virtuellem Cockpit und Entertainment-System für die Rücksitze. Dennoch behalten Hersteller - und zu einem geringeren Grad auch Fahrzeugnutzer - mehr Autonomie über Datenströme und Ausgestaltung des Systems.

Ein wichtiger Faktor für den Erfolg dürfte jedoch die Tatsache sein, dass viele beispielsweise mit Qt für andere IVI-Systeme entwickelte Anwendungen mit wenig Portierungsaufwand auf AGL-basierte Systeme übernommen werden können. Das stärkt die Position von AGL insbesondere im Vergleich zu Android Auto. Denn kein Pkw-Hersteller kann auf ein Portfolio von Android-Apps beispielsweise zur Sitzverstellung zurückgreifen, AGL hingegen hält den Portierungsaufwand von bestehenden Anwendungen gering, Cauchy hierzu: "Schauen Sie sich Densos Demo an. Sie haben es in gut drei Monaten geschafft, ihre kompletten proprietären Anwendungen auf AGL zu portieren!"

Für einen Blick auf den aktuellen Entwicklungsstand von AGL stehen auf der Webseite des Projekts unter anderem Images zum Betrieb mit Qemu bereit. Der Raspberry Pi gehört mittlerweile zu den "Community Single Board Computers", die generell mit Build-Rezepten unterstützt werden, aber noch nicht mit vollständigen Images.  (mas)


Verwandte Artikel:
Automotive Grade Linux: Das Auto-Linux bekommt ein App-Framework   
(13.07.2016, https://glm.io/122096 )
Automotive Grade Linux: Toyota bringt Auto-Linux auf den Markt   
(01.06.2017, https://glm.io/128156 )
Automotive Grade Linux: Mit Tizen kommt Linux ins Auto   
(02.07.2014, https://glm.io/107614 )
In-Car-Entertainment: Mazda schließt drei Jahre alte Sicherheitslücke   
(15.06.2017, https://glm.io/128398 )
Autofabrik: Elon Musk sucht Trumps Hilfe gegen China   
(09.03.2018, https://glm.io/133240 )

© 1997–2019 Golem.de, https://www.golem.de/