Apex.AI – Was ist das, und wieso ist das so interessant für die Automotive Branche?

Vorab sei gesagt: Wir sprechen heute über Themen, die neu sind. Super neu. So neu, dass es kaum echte Expertise zu diesen Themenfeldern gibt, weil die Branche und deren Experten schlicht noch keine Gelegenheit hatten, sich damit zu befassen, und weil noch gar nicht genug Zeit seit dem Aufkommen neuer Lösungen vergangen ist, um Erfahrungswerte zu sammeln.

Apex.AI ist eine dieser neuen Lösungen, ein Embedded Baukasten mit Enabling Software (to find vehicles – so zumindest das Grundprinzip), nicht unähnlich zum bekannten „ROS“ (Robot Operating System), das schon an Hochschulen unterrichtet wird und daher von hoher Bedeutung für die Automotive-Branche ist, vor allem im Bereich autonomen Fahrens. Gründer Jan Becker war es, der eben jenes ROS praktisch zur Serienreife erheben wollte, mit dem Gedanken, von der Expertise, dem Umsatz und der Verbreitung eines serienreifen Baukastens zu leben, statt diesen – wie bei ROS – ausschließlich von der Community weiterentwickeln zu lassen.

Die offensichtlichen Vorteile liegen auf der Hand – weshalb sie ja erst offensichtlich sind, versteht sich: Vor allem Hochschulabgänger haben den massiven Vorteil, ROS bereits zu kennen, wenn sie in der Automotive Branche Fuß fassen möchten, gegensätzlich beispielsweise zum ebenfalls elementar wichtigen AUTOSAR (Classic und Adaptive), das bedauerlicherweise nicht an Hochschulen gelehrt wird. In Zeiten des Fachkräftemangels ist der Vorteil unbestreitbar, wenn Unternehmen Studenten Tools bieten können, die bekannt sind und mit deren Nutzung sich entsprechend schnelle Fortschritte und Wertschöpfungen erzielen lassen.

Doch auch die Software selbst hat freilich ihre Reize. Wo AUTOSAR letztlich „lediglich“ eine Communication Middleware ist, bietet Apex.AI Slam-Algorithmen und Libraries, unterstützt Sensoren aus z.B. Radar- und Kamerabereich und ist eben ein echter Baukasten.

Wieso Apex.AI nicht (wirklich) das Thema dieses Artikels ist (aber ein bisschen dann doch…)

In der IT-Projektlandschaft hält man es gerne simpel. Nein, wirklich: Komplexe Datenströme werden in Data Pipelines gebündelt, klassifiziert, ausgewertet, am Ende steht ein Ergebnis. Prozesse werden zerlegt bis zum kleinstmöglichen Task, und dieser kann bearbeitet, optimiert und wiederholt werden – so geht Fortschritt. Daher machen wir es auch jetzt einfach: Apex.AI ist nicht wirklich das Thema dieses Beitrags. Damit das verständlich wird, behaupten wir zuvor nochmal das Gegenteil, ein in der Politik überaus beliebter (und erfolgreicher) Trick: Autonomem Fahren gehört die Zukunft – zumindest in Teilen – und Apex A.I. ist optimal geeignet für die Entwicklung von Assistenzsystemen und komplett autonomen Fahrfunktionen.

Demgegenüber steht allerdings eine branchenweite Dualität, ein Mindset, eine Haltung regelrecht, die nur allzu oft gebetsmühlenartig wiederholt, dass der Markt dominiert wird von den beiden großen Playern Apple und Google. Eine Zukunft, in der die beiden praktisch alleine bestimmen, was geht und was nicht geht, bis zur scheinbar unvermeidlichen Omnipräsenz (man denke nur an Azure vs. AWS im Cloudsektor). Aber ist dem wirklich so? Muss sich jedes kommende Betriebssystem im Fahrzeug zwischen dem Apfel und dem niedlichen Android Robot entscheiden? Oder können Player wie Apex A.I. den Markt verändern?

Wir glauben: Einfach ist gut, aber man sollte es auch nicht übertreiben. Sicher – nur zu behaupten, Apple und Google können eben Infotainment, und dann wird’s eng – das wäre ein bisschen einseitig. In den Bereichen Connectivity und besonders Usability sind beide Player State of the Art, und Android Automotive wird im Bereich der Entwicklung, insbesondere auch im Bereich Embedded, weiterhin eine Rolle spielen, wenn ehemalige Silicon Valley Akteure nach und nach in den lukrativen Automotive Markt einsteigen.

Betrachtet man den Markt aber ein wenig diversifizierter, stellt man fest, dass es hinter dem Tellerrand noch weitere Teller gibt, weitere Spielplätze, auf denen Apple und Google mitnichten die Platzhirsche sind. Ein Baukasten mit echtem Support, Sensorenanbindung, der Möglichkeit, diese zu fusionieren, Umgebungsmodelle einzupflegen, Fahrermodelle zu erstellen etc. bietet an, sich auf die Funktionalität der App zu konzentrieren, sich Gedanken zu machen, was wirklich in ein Fahrzeug gehört, um dieses zu verbessern und um Nutzern ein besseres, sichereres und angenehmeres Fahrerlebnis zu geben.

Das liest sich fast schon werblich, indes ist dieser Artikel mitnichten darauf ausgelegt, Apex.AI in den Vordergrund zu stellen. Hier wird kein neuer – Wortspielalarm – Spitzenpredator der Systementwicklung im automobilen Sektor geschaffen. Die Entstehung eines neuen Standards für Sensorenanbindung oder das Schaffen neuer Modelle im autonomen Fahren wäre aber denkbar.

With that out of the way, sagt der Anglizismus, zurück zum Einfachen: Aufzuzeigen, dass die marktbestimmende Dominanz von auf Google oder Apple basierenden Betriebssystemen in naher Zukunft eher oberflächlich ist und in Teilen auch ungenau, ist nicht von Apex.AI abhängig. Es gibt auch andere Themenfelder in Fahrzeugen – Beispiele wären hier die Cyber Security oder die Funktionale Sicherheit – mit anderen Lösungen, anderen Prozessen, und sicher (no pun intended) kein idealer Tummelplatz für Connectivity-Experten (auch wenn solche freilich idealerweise im Team sind).

Apex.AI und AUTOSAR – Zwei die sich (nicht) mögen

Apex.AI ist sicherlich zukunftsorientiert und daher interessant. Das hauseigene Apex.OS soll als Betriebssystem idealerweise AUTOSAR ersetzen, Schnittstellen nach unten hin vereinfachen, um Kooperationen über Fahrzeugherstellergrenzen hinweg und somit die Entwicklung einer ganzen Branche zu beschleunigen. Doch ganz so einfach wird es nicht: AUTOSAR bleibt vermutlich weiterhin die Domänen-Middleware für klassische Steuergeräte, die Funktionen wie Batteriemanagementsysteme und Fahrfunktionen (Lenkung, Fahrwerk, Antrieb etc.) regeln. Auch als Standard-Middleware für gehostete Apps, um beispielsweise Daten aus dem Fahrzeug zu übertragen, bleibt AUTOSAR langfristig denkbar, da es diese Spielfelder weiterhin geben wird und die thematische Trennung nicht so leicht überbrückbar ist.

Ein wichtiges und häufig genutztes serviceorientiertes Protokoll für verschiedene Fahrzeugfunktionen ist beispielsweise SOME/IP – was Apex.AI nicht bedienen kann. Die Pläne der Firma hinter CEO Jan Becker sind daher klar und gehen in Richtung Adaption von und mit AUTOSAR. Macht Sinn, denn nicht wenige OEMs haben ihre Infrastruktur auf SOME/IP ausgelegt. Statt dieses aktiv zu integrieren – wie beispielsweise DDS – kann Apex.AI also eine homogene Beziehung mit AUTOSAR eingehen. Ganz überflüssig wird also so schnell niemand – erst recht nicht, da viele der Hyperscaler sichtlich daran interessiert sind, in den oben genannten Feldern mitzumischen.

Unternehmen wie Cognizant Mobility fahren aus den vielen guten Gründen, die eine abwechslungsreiche OS Landscape bedingen und fördern, entsprechende Strategien, um sich für die Entwicklung via Apex.AI (bzw. eben Apex.OS) aufzustellen: Kunden helfen, die Laufzeitumgebung für ihre Applikationen zu schaffen, Middleware-Integration, wie es auch jetzt schon mit AUTOSAR praktiziert wird. Einen Standard etablieren, damit sich Kunden auf die App und deren Funktionen konzentrieren können (man denke nur an CARIAD): Sicherlich ein Zukunftsmodell jenseits der prognostizierten Dualität im OS-Markt. Unternehmen mit nachweisbarer Expertise in den Bereichen AUTOSAR, DevOps und Embedded werden hochaktiv darin sein, diese automobile Vielfalt im Connected Car von übermorgen zu fördern. Ein schönes Beispiel wären Anbieter, die die aktuelle Mangelware Chips verkaufen, aber niemanden dazu liefern können, der jegliche Middleware auf diese Chips integrieren kann. Wie auch, es gibt ja keine Dokumentation. An genau dieser Engstelle können Unternehmen wie Cognizant Mobility dabei helfen, die Treiber auf dem spezifischen Gerät einzubinden, was in einem weiten Netzwerk aus Herstellern, Lieferanten und OEMs einfacher wird (und in das, beiläufig erwähnt, auch kein einfacher Zugang besteht).

Nun also, sagen wir, Kameratreiber an die Library von Apex.AI anzubinden, die wiederum einen Videostream zur Hinderniserkennung aus dem Baukasten bieten kann – das wäre eine typische Servicelösung, die aus der Zulieferer- und Knowledge-Umgebung stammt.

Freilich – es wollen ja gar nicht immer alle mitspielen. Manche Anbieter versuchen, eigene Frameworks anzubieten und locken mit der auf den ersten Blick gutaussehenden One-Fits-All-Lösung, die nur allzu oft im Lock-In endet. Qualcomm könnte ein solcher Anbieter sein, oder auch Nvidia (auch wenn deren durchaus brauchbares Framework als gescheitert zu betrachten ist). Qualcomm und Apex.AI an einem Strang könnten allerdings ein hochproduktives Entwicklungsumfeld abgeben, das einen zweiten Blick wert ist. Vorteil von Apex bleibt indes, dass deren Lösung für alle Anbieter verfügbar ist, auch wenn es nicht mehr Open Source wie einst ROS ist, wohingegen die aktuellen Player auf diesem Gebiet eher Eigenlösungen verkaufen möchten. Nachvollziehbar, liegt auch in der Natur der Dinge – hemmt aber den Fortschritt und droht, langsame Komplett-Inhouse-Lösungen zu bevorzugen, verglichen beispielsweise mit dem Kauf aller Komponenten-Zulieferer für mehrere kommende Entwicklungsgenerationen und der damit verbundenen Übernahme der nötigen Komponenten in eine eigene, vertikale Development-Strategie, wie Tesla sie umsetzt. (Wir gucken dabei ganz bestimmt wieder nicht in Richtung CARIAD!)

Apex.AI im Automotive – Wo soll das nur enden? (Spoiler: Natürlich in der Cloud).

Gucken wir nochmal nach ganz, ganz weit vorne. Hinter dem Horizont, der sich auch in der sonst durchaus zögerlichen Automobilbranche kaum aufhaltbar öffnet, liegt eine Cloud-Native Software Architektur. Ein schöner Gedanke, wie Sommerstrahlen auf der abendlichen Veranda. Embedded System Development, nahtlos mit der Cloud verbunden, komplett freie Entscheidung für die Laufzeitumgebung, Software aus der Hardware in die Cloud für mehr Ressourcenfreiheit: Die komplette Applikationsumgebung inklusive Echtzeitanwendungen, vollständig in der Cloud gehostet – derzeit noch Vision, dank offener Player wie Apex.AI aber denkbar. Um sehr frei zu zitieren: Schöne neue Automobilwelt, die solche Frameworks trägt.

Gehen wir also weg von schnöder On-Premise, fort von Hardware, vergessen wir die dröge Steuergerätentwicklung. Kunden könnten direkt auf einem ARM-Server programmieren und entscheiden, ob die Applikation direkt in die Cloud kann oder noch Embedded wird. ARM würde diese in der Cloud geschriebenen Apps auch auf dem Embedded Gerät (beispielsweise dem Steuergerät) hosten – ein Schritt in Richtung No-Code bzw. Low-Code Entwicklung und Integration, aber, man ahnt es ob der beiläufig hingeworfenen Bemerkung wohl, das ist ein Thema für einen anderen Artikel.

Also bye bye Apple und Google? Na, nicht ganz. Beide Player sind stark im heimischen Stadion und machen eine gute Figur in der allgemeinen Connectivity und Usability. Und sie wären nicht die ersten Hyperscaler, die auch in Gebiete vordringen, die einstmals der klassischen Industrie vorbehalten waren. Alles erobern werden sie indes nicht, auch nicht in naher oder ferner Zukunft. Zu gute Lösungen sind präsent, werden auch jetzt parallel entwickelt und noch für die eine oder andere Überraschung bereit sein. Apex.AI ist sicherlich nur bedingt eine solche, basiert schließlich auf einem weithin bekannten und geläufigen Framework. Dennoch birgt deren Betriebssystem das Potenzial für ein branchenintern übergreifendes Zusammenarbeiten, für eine Beschleunigung der Entwicklung und, vielleicht am wichtigsten, einen hohen Grad an Zugänglichkeit, der es vor allem jungen Fachkräften erleichtert, aus der Vorlesung in produktive und innovative Gefilde vorzustoßen. Vielleicht kein finales „Ade“ zum Fachkräftemangel, aber ein hilfreicher Ansatz.

Was für ein schönes, interpretierbares Fazit.