Kubernetes für das Auto: So öffnen Sie den Entwicklerzugriff auf den Bordcomputer und machen ihn sicher

Dies ist eine zweiteilige Geschichte - über eine neue Runde der Automobilentwicklung. Diese „Serie“ ist der eigenen Entwicklung von EPAM gewidmet, der Aos Connected Vehicle Platform. Alex Agizim , CTO, Automotive & Embedded Systems, erklärt, wie es sich von einer herkömmlichen Cloud-Lösung unterscheidet und wie Softwareentwicklern der Zugriff auf das Auto ermöglicht wird. Hier können Sie sich mit dem ersten Teil vertraut machen .



Im ersten Teil habe ich darüber gesprochen, wie unsere XEN Hypervisor-Entwicklungen den Serviceteil von Automobilsoftware von sicherheitsrelevanter Software isolieren. Dies ist eines der Hindernisse für eine weit verbreitete Verwendung in der Branche. Zum ersten Mal wird ein Open-Source-Hypervisor zu einem vollwertigen Konkurrenten für geschlossene kommerzielle Lösungen.

Dies ist jedoch nur der erste Schritt. Um Automotive-Services auf ein neues Niveau zu heben, müssen Sie Service-Unternehmen und Entwickler, die weit davon entfernt sind, eingebettet und automobil zu sein, "hineinlassen". Dies erfordert die nächste Abstraktionsebene. Damit ein Entwickler, der moderne Frameworks in der Softwareentwicklung verwendet, seine Dienste für Autos entwerfen kann, ohne sie neu zu lernen.

Vielleicht möchten Sie nach dem Lesen sagen: „Warum solche Schwierigkeiten? Ich habe zum Beispiel ein Android-Tablet für ein Auto gekauft, die erforderlichen Dienste eingerichtet und bin sehr zufrieden. “ Dies ist ein klassischer Engineering-Ansatz, sehr unterstützend. Aber lasst uns weiter sehen. Die Automobilindustrie steckt aus Sicht der Software seit langem in klassischen Ansätzen. Ich werde Ihnen sagen, wie wir ihre Zukunft sehen und was wir dafür tun. Und am Ende gehen wir die Hauptschwierigkeiten durch.

Also.

Warum müssen Sie den Serviceentwickler in den Bordcomputer des Autos einlassen? Und was ist jetzt los?

Das Auto wird immer komplexer. Es ist für alle Gelegenheiten mit Sensoren vollgestopft, und Raumfahrzeuge werden die Leistung von Bordcomputern beneiden. Bei alledem bleibt die Leistungsfähigkeit des Autos sehr begrenzt. Die Softwareentwicklung schreitet voran, aber 90% vergehen.

Eine enge Analogie sind Smartphones. Bis 2007/09 war es ziemlich schwierig, eine Anwendung zu schreiben, die auf verschiedenen Mobiltelefonen ausgeführt werden konnte. Auf dem Markt kämpften viele Betriebssysteme und Frameworks: Lösungen von Symbian, Motorola, Ericsson usw. ... Die Anzahl der Personen mit Entwicklungsfähigkeiten war gering. Wenn ein Unternehmen wollte, dass eine große Anzahl von Personen seinen Dienst oder seine Anwendung nutzt, begann ein Problem mit der Unterstützung auf verschiedenen Betriebssystemen und Frameworks.

Genau das Gleiche passiert heute in der Automobilindustrie. Damit der Service von verschiedenen Automobilherstellern unterstützt wird, müssen Sie sich an viele Frameworks und Regeln anpassen. Für Mercedes separat, für Toyota separat usw.

Als iOS 2007 erschien, ein Jahr später - Android - gelang der Mobilfunkbranche sofort der Durchbruch. In AUTOMOBILE setzt sich der Konflikt zweier Hauptparadigmen fort.

Der erste ist traditionell. Ein Bordcomputer ist ein geschlossenes Gerät, auf das nur der Hersteller zugreifen kann . Entwickler von Drittanbietern haben hier keine Möglichkeit: Sicherheit zuallererst. Zuverlässig, aber nicht fehlerfrei. Einerseits schließt der Hersteller alles für sich. Es besteht keine Notwendigkeit, die Entwickler von Diensten von Drittanbietern zu beschuldigen. Auf der anderen Seite kann man nicht auf dem neuesten Stand des Fortschritts sein. Ein Autohersteller kann die Wunschliste des Kunden nicht vollständig abdecken. Der Entwicklungs- und Markteinführungszyklus ist zu lang, das Team ist, selbst wenn es sehr hochgespielt ist, immer noch begrenzt. Und das erwartete vernetzte selbstfahrende Auto fährt weiter weg. Wie die Integration in eine gemeinsame Wirtschaft.

Das andere Extrem ist, ein Auto als IoT-Gerät zu betrachten . Sammeln Sie einfach Daten von allen Automobilsensoren, packen Sie sie ein und senden Sie sie zur Verarbeitung an die Cloud. Bei Bedarf viele tausend Mal wiederholen. Hunderte von Cloud-Projekten, darunter Google, Microsoft und Amazon, versuchen, das Auto zu beobachten. Das ist aber ein bisschen falsch.

Auto ist kein Smart Home mit Glühbirnen, Thermostat und Fernseher. Es hat hunderte Male mehr Sensoren und eine eigene Rechenleistung. Und vor allem ist der Kanal zwischen Auto und Zentrum instabil. Selbst wenn es bedingt stabil ist, ist es unwahrscheinlich, dass es Hunderte von Megabyte Daten pro Sekunde ausführen möchte. Andernfalls gibt es keinen Weg in einen solchen Ansatz - die gesamte Geschäftslogik des Dienstes funktioniert in der Cloud.

Was haben wir uns dafür ausgedacht?

Wir haben eine andere Ideologie gewählt. Ein Auto ist nicht nur eine Informationsquelle von Sensoren. Dies ist ein vollwertiger Rechenknoten, auf dem der Dienst seine Geschäftslogik ausführen kann .

Dafür braucht das Auto ein Grundelement - die Connected Vehicle Platform. Sie können das Auto als Softwareplattform öffnen. Verwenden Sie andererseits die in Cloud-Diensten verwendeten Tools, um die Bereitstellung und Orchestrierung von Diensten zu erledigen, die auf dem Bordcomputer funktionieren sollen.

Wenn unsere Prognose wahr ist, werden wir ein Ökosystem haben, in dem der Programmierer auf die übliche Weise handeln und einen Teil der Geschäftslogik in einen Autocomputer einbetten kann. Auf die gleiche Weise wie heute bei Cloud-Diensten wird eine Taste gedrückt, CI / CD gestartet und alle erforderlichen Komponenten für alle erforderlichen Knoten bereitgestellt. In unserem Fall ist einer der Knoten für die Bereitstellung ein Auto. Und wir geben einen Rahmen, der dies tun kann. Deshalb nennen wir unsere Cloud-Plattform "Kubernetes für Autos".

Das Konzept unserer Vision gliedert sich in zwei Teile:

1. Sicherheitssoftware von Software für verbundene Dienste isolieren;
2. Bereitstellung des erforderlichen Abstraktionsniveaus für Unternehmen, die vernetzte Fahrzeugdienste entwickeln möchten oder bereits durchführen. Sie sollten sich nicht mit Embedded beschäftigen, sondern Dienste mit ihren üblichen Tools entwickeln und den Bordcomputer als Edge-Gerät verwenden.

Ein Bordautocomputer sollte ein Edge-Computer für zukünftige mobile Dienste werden. Wir ersparen Autoherstellern die selbständige Erfindung von Dienstleistungen und öffnen das Auto für Entwickler. Wie es einmal mit Smartphones passiert ist.

Welche Fälle kann es schließen?

Der Grundfall ist die mangelnde Konnektivität . In der klassischen Cloud-Version verliert der Dienst den Zugriff auf das Auto. In der Connected Vehicle Platform-Variante kann der Entwickler dies vorhersehen und die Logik im Auto vorab „flashen“. Und für den Cloud-Teil davon - puffern Sie zumindest die Daten.

Die Plattform wird auch dazu beitragen, das Flottenmanagement und das Flottenmanagement sowie die vorausschauende Wartung erheblich zu verbessern. Die Kommunikation mit der Cloud für diese Dienste wird, wenn nicht optional, viel weniger beliebt.

Ein völlig verständliches Beispiel ist die Arbeit der Taxidienste. Jetzt sind sie auf Smartphones implementiert, funktionieren hervorragend mit Karten und Zahlungen, können aber den Zustand des Autos nicht berücksichtigen. Wenn Sie zum Beispiel zu spät zum Flughafen kommen, kommt Uber an - und plötzlich stellt sich heraus, dass der Fahrer nur für einen Teil des Weges genug Benzin hat. Der Fahrer konnte dies nicht im Voraus verstehen. Wenn der Uber-Dienst jedoch im Bordcomputer bereitgestellt wurde, konnte ich dem Backend in der Phase der Bestellung mitteilen, dass dieses bestimmte Auto nicht geeignet ist. Und die Servicequalität wäre höher.

Für die zukünftige gemeinsame Wirtschaft benötigen Sie eine Reihe von Diensten im Auto, die vollständig ohne Benutzeroberfläche auskommen. Zum Beispiel ein Service, der den technischen Zustand des Autos überwacht (das Beispiel mit Uber und Benzin ist auch hier geeignet). Oder ein Dienst, der überwacht, wie eine Person fährt, und diese Daten an Versicherungs- oder Vermietungsunternehmen weitergibt.

Gleichzeitig müssen Versicherungs- oder Vermietungsunternehmen verhindern, dass Passagier und Fahrer sie entfernen oder trennen. Heute werden sie durch Dienste verdreht, die nur mit Hilfe zusätzlicher Telekommunikationseinheiten funktionieren. Und dies ist der Kauf, die Installation, die Integration und das Schreiben des Dienstes selbst. Es kostet viel Zeit und Geld.

Daher betrachten wir das vernetzte Fahrzeug immer in zwei Aspekten. Eine Seite stellt nur eine Verbindung zu Internetdiensten her. Das zweite ist Auto als Teil einer geteilten Wirtschaft. Dazu müssen alle Grundelemente in der Phase der Produktion in das Auto integriert werden. Deshalb sprechen wir entweder mit Autoherstellern oder mit Autocomputerherstellern.

Eines der Probleme der Branche besteht darin, dass es nicht möglich ist, Benutzerfälle zu erstellen, da der Plattformansatz nicht ausreicht. Bei Mobiltelefonen war es genauso. Sie können beispielsweise sagen, dass 2.800 Unternehmen Lösungen für das Flottenmanagement entwickeln. Aber sie sind alle sehr monolithisch. Wenn Sie etwas ändern müssen, müssen Sie die Bord- und Telekommunikationscomputer ändern. Schließlich möchte ich etwas tun, was dieses Gerät nicht kann.

Wie kann ein Business-Service sicher von der Cloud zum Auto heruntergefahren werden? Was kann dies verhindern und wie lösen wir es?

1. Behälter

Da wir aus den Ideen von Kubernetes stammen, besteht seine Hauptkompetenz darin, Container bereitzustellen. Aber mit einem Autocomputer ist es schwierig.

Erstens, selbst wenn wir in Python ein paar Codezeilen schreiben, die "Hallo Welt" drucken, kann die Größe des Containers 50 MB erreichen. Das Gießen durch einen Mobilfunkkanal kann funktionieren oder nicht. Sogar das mystische 5G hat die gleichen Probleme wie jede andere Verbindung: Abdeckung, Bandbreite, Stabilität. Sie müssen also die Chancen erhöhen.

Zweitens ist der Autocomputer sehr leistungsfähig, aber immer noch viel eingeschränkter als jeder kleinste Server in der Cloud. Viele andere Programme laufen darauf. Sie können nicht einfach 200 MB RAM "essen".

Daher haben wir zunächst unseren Containertyp im Rahmen des OCI-Standards beschrieben. Das Problem mit der Größe wird wie folgt gelöst: Alle grundlegenden Dinge, die ein Entwickler zum Betreiben eines Dienstes benötigt, müssen nicht aus der Cloud übertragen werden. Sie sind bereits auf dem Autocomputer vorinstalliert. Sie müssen nur den Code selbst mitbringen, der im schlimmsten Fall Hunderte von Kilobyte benötigt.

Das Problem mit den Ressourcen des Bordcomputers wird durch deren Beschreibung in unserer Containerspezifikation gelöst. Aufgrund dessen können Sie sehr einfach die Kontingente bestimmen, die der Autocomputer überwachen wird. Und der installierte Service kann sie niemals überschreiten.

2. Sicherheit

Kubernetes wurde ursprünglich für die Bereitstellung und Orchestrierung von Diensten in der Cloud entwickelt. Das heißt, in einer kontrollierten, unterstützten und vor falschen Händen geschützten Umgebung. Aber wir haben ein Auto und die Angreifer haben eine unbegrenzte Fantasie. Sie können den Bordcomputer herausziehen, ihn mit einem Gerät knacken und in den Kanal zwischen Auto und Cloud gelangen. Sicherheit ist daher unsere ständige Aufgabe mit höchster Priorität.

Wir haben ein fortschrittliches Modell gemäß den Empfehlungen der US National Security Agency implementiert. Darin heißt es: Beim Entwerfen Ihres Sicherheitssystems müssen Sie zunächst die Anzahl der potenziellen Angriffsstellen minimieren und die Sicherheit als Schichtkuchen erstellen. Auf irgendeiner Ebene gehackt? Es ist notwendig, dies zu bemerken und alle Anstrengungen zu unternehmen, um nicht zum nächsten zu gehen.

In unserem Modell sieht der „Kuchen“ folgendermaßen aus:

1. Wir verwenden Container als eine Art Isolator auf der Ebene des Linux-Betriebssystems. Es ist sehr schwierig, aus dem Behälter auszubrechen;
2. Aus dem Container ausbrechen? Die Connected Vehiclle Platform wird jedoch in einer separaten virtuellen Maschine ausgeführt - für die wir XEN benötigen. Diese virtuelle Maschine ist von allen Peripheriegeräten isoliert. Die Kommunikation mit Peripheriegeräten kann nur über einige APIs erfolgen, die vom Autohersteller bereitgestellt werden.
3. Container und virtuelle Maschine kaputt gemacht? Wir haben noch eine Barriere - die Selbstbeobachtung der virtuellen Maschine: die Analyse von Mustern, mit denen die virtuelle Maschine arbeitet. Beispielsweise versucht eine virtuelle Maschine plötzlich aggressiv, auf eine Art Speicher zuzugreifen, den sie normalerweise nicht berührt. Sie können antworten: Schalten Sie diese virtuelle Maschine aus, kehren Sie zur stabilen Version zurück usw.

3. Skalieren

Ist die Aktualisierungszeit auf den Smartphones der Benutzer für das bedingte Mobile Banking von entscheidender Bedeutung? Nicht besonders. Wenn nur nichts auf dem Weg kaputt wäre. Für Cloud-Dienste spielt das Thema Skalierung keine große Rolle.

Nicht mit einem Auto. Angenommen, Sie haben ein Auto gemietet und möchten Ihren Service nutzen, der Ihnen eine gute Versicherungspolice bietet, weil Sie gut fahren. Dafür ist es jedoch erforderlich, dass im Auto ein Dienst installiert ist, der Ihre Daten an die Versicherungsgesellschaft weitergibt.

Sie stiegen ins Auto, steckten den Schlüssel in das Schloss, drehten sich um und nach 3 Sekunden sind Sie bereit zu gehen. Es ist logisch, dass das Auto in diesen 3 Sekunden alle für die Fahrt erforderlichen Leistungen akzeptiert. Aber wenn es nicht eine solche Maschine gibt, sondern 10.000? Ein System, das Dienste für ein Auto bereitstellt, sollte dies schnell tun können. Die Installationszeit sollte unabhängig von der Anzahl der zu installierenden Fahrzeuge konstant sein.

Wir haben dieses Problem mit Hilfe des Add-Ons gelöst, das wir über RabbitMQ entwickelt haben. Es erleichtert das Skalieren und Verkleinern von Systemen, je nachdem, wie viele Knoten Sie verwenden müssen.

4. Kommunikationskanäle

Bei der Bereitstellung von der Cloud zum Auto muss der Kommunikationskanal verschlüsselt werden. Wir verwenden gegenseitiges TLS zur Authentifizierung. Es funktioniert in zwei Richtungen: Das Auto meldet sich bei der Cloud an und die Cloud meldet sich beim Auto an. All dies basiert auf Zertifikaten. Wenn die Zertifikate nicht passen oder jemand versucht, sie zu ersetzen, erfolgt keine Autorisierung und es wird kein Zugriff auf den Bordcomputer gewährt.

Darüber hinaus wird jeder Kanal, über den Container von der Cloud zum Auto transportiert werden, mit einem eigenen Schlüsselsatz verschlüsselt. Angenommen, jemand hat einen Schlüssel und ein Zertifikat gestohlen und konnte auf den Containerübertragungskanal zugreifen. Aber er kann nur zum Kanal dieses bestimmten Autos gelangen. Worum geht es bei der Anzeige? Sie können die Zertifikate erneuern, die neue gegenseitige TLS-Verschlüsselung wird daran arbeiten - und alle Cracking-Bemühungen sind gescheitert. Dies erspart uns das Problem von IoT-Netzwerken, wenn ein gehacktes Zertifikat alle Geräte gefährden kann.

5. Mandantenfähigkeit

Stellen Sie sich ein normales Smart-Home-IoT-Netzwerk vor. Es hat Hersteller von Geräten und Netzbetreibern. Abhängigkeiten zwischen Geräten und Bedienern sind in der Regel statisch. Der Lebenszyklus ist auch ziemlich stabil: Wenn Sie anfangen, eine intelligente Glühbirne gegen eine andere auszutauschen, wird es nicht bald sein und Sie werden es selten tun.

Im Falle des Autos und der geteilten Wirtschaft sind diese Abhängigkeiten sehr dynamisch. Es gibt einen Autohersteller . Es gibt einen Käufer / Eigentümer - sagen wir, dies ist eine Carsharing-Firma. Es gibt einen Dienstleister. Und es gibt einen Endbenutzer .

Besitzer, Betreiber und Benutzer können jederzeit wechseln. Am Montagmorgen gehört das Auto einer bestimmten Bank, der Betreiber ist Firma A. Nach dem Mittagessen wird es bereits von Firma B betrieben. Benutzer verschiedener Betreiber können auch unterschiedlich sein. Gleichzeitig müssen die ihnen gehörenden Dienste für verschiedene Autos nach ihnen migrieren.

Dies wird hier als Multitenancy bezeichnet und wird vom Design in unserem Service Deployment Management System unterstützt. Die Rollen des Dienstanbieters und des Dienstanbieters wurden bereits definiert, es ist keine zusätzliche Logik erforderlich. Sie können einem Auto verschiedene Dienste zuweisen. Angenommen, ein Auto wird an einen anderen Eigentümer übergeben. Die Dienste des vorherigen werden automatisch entfernt und die Dienste des neuen werden automatisch bereitgestellt. Heutige IoT-Netzwerke und dieselben Kubernetes sind nicht geeignet - sie sind einfach nicht auf einen solchen Fall gestoßen.

6. Überwachung des Betriebs von Diensten

Für die Kommunikation mit dem Fahrzeugdienst gibt es eine standardisierte API namens VIS - Vehicle Information Services. Es ist von W3C standardisiert. Diese API in unserem Konzept wird vom Automobilhersteller implementiert und gesteuert. Der Service für vernetzte Fahrzeuge ist unter voller Kontrolle.

Verschiedene Hersteller beginnen, diese API zu unterstützen. Und dem Entwickler ist es egal, für welchen Hersteller er den Service anbietet.

Natürlich kann jeder Autohersteller einige Ausnahmen machen. Wie Smartphones: Das Galaxy S9 und das Galaxy S10 haben dieselbe grundlegende API, aber jedes hat Dinge, die für ein bestimmtes Modell fair sind. In einem Auto können grundlegende Informationen auch unabhängig von ihrem Typ erhalten werden. Und für bestimmte Dinge ihre eigenen Nuancen. Dies ermöglicht es den Herstellern, einige einzigartige, herausragende Dinge mit Mehrwert zu entwickeln.

Auf welchen Komponenten der Plattform ist geschrieben? Und worauf wird es möglich sein, Dienstleistungen für Autos zu schreiben?

Die Plattform selbst ist in Python geschrieben. Die Verwaltung des Bereitstellungssystems auf oberster Ebene ist in Python geschrieben. Der gesamte eingebettete Teil ist in C geschrieben.

Als erstes haben wir Python unterstützt und JavaScript hinzugefügt. Auf Wunsch mehrerer Automobilhersteller wurde .NET hinzugefügt. Es ist die Rede von Java.

Im Allgemeinen ist dies ein taktisches Problem. Es gibt keine JavaScript-Programmierer - es gibt Programmierer. Ich denke, dass mit der Entwicklung der Automobilindustrie Programmierer auftauchen werden, die an speziell vernetzten Fahrzeugdiensten beteiligt sind. Eine Glühbirne „Was tun, wenn keine Verbindung besteht?“ Blinkt immer im Kopf Egal was wir in der Luft haben - 5G oder 10G. Die drahtlose Verbindung funktioniert nicht 100% der Zeit.

Wie reagieren Autohersteller auf die Plattform?

Jeder Autobauer hat heute eine interne Abteilung, die vernetzte Dienste entwickelt. Diese Leute können schnell arbeiten. Sie werden jedoch durch ihre eigenen Abteilungen für interne Hardware und Software behindert.

Wir konzentrieren uns darauf. Wir bringen ein Tool mit, mit dessen Hilfe die eigenen Entwicklungsabteilungen schneller und flexibler arbeiten können. Und die Jungs von embedded, die jetzt 2 Jahre lang eine Codezeile ändern, können dies einmal mit der Plattform tun - dann können sie vom System unabhängig von ihnen sein.

Im Allgemeinen schauen sich die Hersteller Aos genau genug an. Aber mit Interesse - weil es ihnen neue Möglichkeiten eröffnet. Sie können beispielsweise ein Geschäftsmodell wie Amazon, Google, Microsoft erstellen: Weisen Sie eine Servicegebühr für die Verwendung des Bordcomputers, der API usw. zu. Ich denke auch, dass sie eines Tages zu einem Marktplatzmodell kommen werden. Das heißt, Entwickler von Software und verbundenen Diensten zahlen eine Provision für den Benutzer, der ihren Dienst installiert.

In der Mobilfunkbranche geschah dies schnell. Aber wir verstehen: Die Leute wechseln nicht jedes Jahr das Auto. Der Entwicklungszyklus für Automobilsoftware dauert 4-6 Jahre. Daher wird das, worüber wir heute mit Autoherstellern sprechen, kaum vor 2022 in Form von Piloten erscheinen.

Versuchen wir, Tesla zu kopieren oder mit ihm zu konkurrieren?

Nein und sogar umgekehrt. Im Gegensatz zu anderen kann Tesla jede Software, die auf einem beliebigen Computer im Auto ausgeführt wird, auf dem Luftweg aktualisieren. So können sie ständig neue Funktionen einführen. Ihr Computer ist jedoch keine Plattform für die Entwicklung von Carsharing-Diensten. Sie können nicht 10 Autos kaufen, 2 Programmierer einstellen und einen coolen Carsharing-Service schreiben. Daher ist Tesla auch einer unserer potenziellen Kunden. Und von den fortgeschrittensten.

Mit unserer Plattform müssen weder Tesla noch andere Hersteller Zeit damit verbringen, ein Fahrrad zu erfinden. Schließlich entwickelt noch niemand in Cloud-Anwendungen seine Kubernetes. Unsere Vision ist, dass dies mit der Connected Vehicle Platform geschehen sollte.

Wenn wir über Wettbewerb im Allgemeinen sprechen, haben wir bisher keinen einzigen Konkurrenten gesehen, der zumindest über das gesprochen hat, worüber wir sprechen. Wie sich herausstellte, ist die Automobilindustrie immer noch sehr geschlossen. Und viele Dinge auf der Plattform - die gleiche Unterstützung für FOTA und SOTA - tun wir nicht nur, weil sie jetzt benötigt werden, sondern vorzeitig.

Ich denke jedoch nicht, dass es in Zukunft eine Plattform für alle Autos geben wird.Höchstwahrscheinlich wird es 2-3 große geben. Einerseits werden sie die Automobilhersteller vereinen. Zum anderen werden sie es wieder ermöglichen, moderne Programmier-Frameworks zu verwenden. Und wir werden völlig neue Fälle sehen, die wir uns jetzt nicht vorstellen können.