Dies ist eine zweiteilige Geschichte - über eine neue Runde der Automobilentwicklung. Im ersten
spricht Alex Agizim, CTO Automotive & Embedded Systems bei EPAM , über Virtualisierung in einem
Autocomputer . Und auch, wie und warum der Open-Source-XEN-Hypervisor zu einem vollständigen Konkurrenten kommerzieller Lösungen für die Automobilindustrie werden kann.
Ich muss Sie sofort warnen - ich werde keine Code- und technischen Details in den Leser werfen. Hier werden wir über globale Dinge sprechen, von denen wir glauben, dass sie die Automobilindustrie in den nächsten 2 bis 4 Jahren verändern werden. Genau wie vor 12 Jahren haben sich Mobiltelefone mit dem Aufkommen von Android und Apple iOS für immer verändert.
Bei EPAM Automotive konzentrieren wir uns auf zwei große Blöcke: Virtualisierung und eine Cloud-Plattform für die Bereitstellung von Diensten direkt im Auto. Diese Geschichte handelt von der ersten.
Zwei Ansätze
Wenn Sie dem Thema Automobil folgen, haben Sie wahrscheinlich bemerkt, wie aktiv Google das Thema Infotainment mit seinem Android Auto OS entwickelt. Seit Ende letzten Jahres hat das Unternehmen mehrere strategische Partnerschaften mit Autoherstellern geschlossen, um Android Auto OS in das Auto zu integrieren.
Aber die Hersteller haben immer noch Bedenken. Der Hauptgrund ist die Sicherheit. In modernen und zukünftigen Autos werden das Infotainment-Cluster und das Instrumental-Cluster, die „wichtige“ Geräte und Indikatoren enthalten, eins und verwenden dieselben Ressourcen. Physische Pfeile und Indikatoren machten gemalten Platz. Der Fahrer sollte jedoch die tatsächlichen Geschwindigkeitswerte, den Kraftstoffstand, den Zustand des Bremssystems und den Motor sehen, egal was passiert. Es ist nicht akzeptabel, wenn irgendwo auf dem Weg die Bildschirme plötzlich einfrieren und einen Neustart erfordern. Und aus der Erfahrung von Android-Smartphones wissen wir, dass dies durchaus möglich ist.
Autohersteller lösen dieses Problem direkt: Sie setzen
zwei oder mehr Computer ein. Der erste befasst sich beispielsweise mit dem Rendern und Verwalten des gesamten Dashboards. Im zweiten Schritt wird Android Auto OS ausgeführt und zeigt Navigation, Musik, Anwendungen usw. an.
Diese Option hat mehrere Nachteile. Erstens sind mehrere Computer immer noch teurer als einer. Zweitens ist die Implementierung kompliziert: Sie müssen den Informationsaustausch zwischen dem Android-Teil und dem Installationscluster, die Konsistenz und viele andere Aspekte sicherstellen.
Eine weitere Option ist die
Verwendung der Virtualisierung mithilfe eines Hypervisors gemäß dem Beispiel der Cloud. Die Leistung und Leistungsfähigkeit moderner Mikroprozessoren in Automobilcomputern ist völlig ausreichend. Es sind mindestens zwei Bildschirme an den Computer angeschlossen. Eine für Android ist Infotainment. Die andere ist für die Wartung des Dashboards vorgesehen. Zwei Betriebssysteme werden in isolierten virtuellen Maschinen ausgeführt. Selbst wenn Android "müde" wird und abstürzt, wird nur die virtuelle Maschine neu gestartet, auf der es ausgeführt wird.
Mit einer solchen Konsolidierung können wir an einem Computer arbeiten und die Integration erheblich vereinfachen. Aber hier gibt es Nuancen.
Auto-Hypervisor
Im Rechenzentrum befasst sich der Hypervisor nur mit dem Aufteilen von Prozessor, Speicher und Speicher zwischen verschiedenen virtuellen Maschinen. Er sorgt auch dafür, dass die „virtuellen Mädchen“ nicht in den Raum des anderen klettern. Darüber hinaus verfügen alle über dieselben Dienste, die sie von der Serverplattform erhalten.
Im Automobilcomputer gibt es neben CPU, RAM und Speicher verschiedene Coprozessoren für bestimmte Aufgaben. Zum Beispiel dieselbe GPU, die Android und das Dashboard benötigen. Dies bedeutet, dass die Aufgabe des Hypervisors darin besteht, beiden Betriebssystemen die Möglichkeit zu geben, Coprozessoren zu verwenden. Stellen Sie außerdem sicher, dass Android den Coprozessor nicht mit einem unzulässigen Befehls- oder Softwarefehler verbindet.
Dies ist eine funktionale Sicherheitsanforderung - das Instrumental Cluster sollte ohne Rücksicht auf Android-Tänze funktionieren. Daher muss der Hypervisor ausreichend fortgeschritten sein und über spezielle Mechanismen verfügen, durch die eine vollständige Isolierung sichergestellt wird.
Die Hardware-Isolation wird bereits von modernen Prozessoren bereitgestellt. Wir kümmern uns um den Software-Teil. Wir modifizieren nämlich den
Open-Source-XEN-Hypervisor so, dass er im Auto unter Berücksichtigung aller Nuancen der Umgebung funktioniert. Darin haben wir die folgenden Blöcke bereitgestellt.
1. Vollständige Isolierung von virtuellen Maschinen, auf denen Infotainment und Dashboard ausgeführt werden
Erstens verfügt der Computer über viele Peripheriegeräte, Tasten, ein Touchscreen-Netzwerk usw. Die Virtualisierung von Peripheriegeräten wird bereits von einer Reihe von Treibern unterstützt.
Zweitens virtualisieren wir GPUs und Coprozessoren. Wenn eine der virtuellen Maschinen etwas mit einem der Coprozessoren im System tut, hat dies keine Auswirkungen auf den Betrieb der anderen virtuellen Maschine.
Drittens wird die TEE Support-Virtualisierung implementiert - eine vertrauenswürdige Ausführungsumgebung. Dies ist eine spezielle, hardwaregeschützte Zone im Prozessor, in der verschiedene Sicherheitsverfahren ausgeführt werden. Da es jedoch mehr als ein Betriebssystem gibt, werden auch die Anforderungen von diesen an TEE aufgeteilt.
Unten sehen Sie den Status der Komponenten und ob es interessant ist, den Code zu sehen
2. Ernährung und Leistung
Jedes Betriebssystem verwaltet Strom und Leistung und kann den Computer entsprechend den aktuellen Aufgaben und Belastungen in den Energiesparmodus versetzen. Android Car möchte möglicherweise auch das Gleiche tun: Wenn keine aktuellen Aufgaben vorhanden sind, wird der Prozessor in den Energiesparmodus versetzt. Das Betriebssystem, das sich mit Geräten befasst, sollte jedoch weiterhin funktionieren. Wir lösen diesen Konflikt mit einer speziellen Erweiterung des Hypervisors. Es überwacht den Status des gesamten Systems und verwaltet Leistung und Leistung.
Der nächste Moment ist Echtzeit. Das System sollte mit einem garantierten Zeitplan arbeiten. Wir tun dies auch als Teil des XEN-Echtzeitplaners.
3. Funktionssicherheit
Zuletzt aber der erste wichtige Block für die zukünftige Autoindustrie. Autohersteller erkennen heute, dass ein Virtualisierungsansatz ihnen helfen wird, wirklich wesentlich flexiblere und leistungsfähigere digitale Cockpit-Service-Systeme zu schaffen. Dies erfordert einen Hypervisor in Automobilqualität.
Es gibt 3-4 kommerzielle Hypervisor-Lösungen für die Automobilindustrie auf dem Markt. Alle kommerziellen Produkte haben jedoch Nachteile:
- hohe Lizenzkosten;
- Mangel an der Fähigkeit, alles in der Software einfach nach Ihren Bedürfnissen zu ändern
- der Hersteller bricht hierfür den Scheck und die Fristen;
- Anbietersperre.
All diese Probleme werden durch den Open Source-Hypervisor beseitigt. Anfänglich kostenlos. Es besteht Zugriff auf die Quelle, Sie können Änderungen vornehmen. Dazu können Sie Ihr Team organisieren oder Servicefirmen kontaktieren. Es gibt völlige Freiheit, denn wenn Sie den Lieferanten wechseln, bleibt der Quellcode beim Hersteller.
Was bleibt zu entscheiden
Die vorletzte Barriere bleibt auf dem Weg zu Open Source. Ein offener Auto-Hypervisor muss der funktionalen Sicherheit entsprechen. Bis vor kurzem glaubten alle, dass dies unmöglich ist. Jetzt gibt es Schichten.
Vor kurzem haben wir aktiv mit der Open Source-Community von XEN Hypervisor zusammengearbeitet. Die Herausforderung besteht darin, den Entwicklungsprozess so anzupassen, dass XEN für die Sicherheit zertifiziert werden kann.
Ende März fand in Cambridge ein Gipfel statt, auf dem sich alle Interessierten versammelten. Erstens alle Hauptunternehmen, die XEN entwickeln: Citrix, ARM, Xilinx, Renesas, EPAM. Zweitens Unternehmen, die sich mit der Zertifizierung befassen. Drittens Unternehmen, die Tools für die automatische Systemanalyse und Identifizierung von Problembereichen bereitstellen.
Als Ergebnis des Gipfels haben wir einen Plan entwickelt, nach dem es absolut möglich ist, die Funktionssicherheit eines Open-Source-Hypervisors zu gewährleisten. Bis Ende dieses Jahres planen wir, eine Reihe spezifischer Artefakte zu beschaffen, damit XEN bei der Integration in Fahrzeugcomputer für die Sicherheit zertifiziert werden kann.
XEN wird zu einem vollwertigen Konkurrenten für kommerzielle Lösungen in der Automobilindustrie und nimmt ihr letztes Argument über das Fehlen einer Sicherheitszertifizierung weg.
Vom letzten - Mitte Juli vergangener
Xen Developer Summit . Funktionssicherheit war eines der Hauptthemen. Wir haben den
Ansatz zur funktionalen Sicherheitslösung vorgestellt (per PDF-Link).
Warum Xen
Wahrscheinlich ist diese Frage von Anfang an von einigen gestellt worden.
Das XEN-Projekt besteht seit 2003 und ist im Vergleich zu anderen Open Source-Lösungen in Rechenzentren sehr weit verbreitet. Er ist schon ziemlich reif geworden. Seit 2012 unterstützt XEN die ARM-Architektur nativ. Und die Prozessoren dieser speziellen Architektur werden hauptsächlich in der Automobilindustrie eingesetzt.
Darüber hinaus haben wir viel Arbeit geleistet, verschiedene Lösungen analysiert und sehr gute Leistungsindikatoren erzielt. Wenn beispielsweise die Leistung eines Betriebssystems, das auf einem Prozessor ohne Virtualisierung ausgeführt wird, gleich X ist, beträgt sie auf einer virtuellen Maschine 0,96 bis 0,97 x. Bei kommerziellen Hypervisoren kann ein Leistungsabfall 30% erreichen. Der Unterschied ist eine Größenordnung überzeugend.
Daher scheint uns XEN eine geeignete Grundlösung zu sein. Daher treibt EPAM dieses Projekt voran. Es gibt bereits mehrere europäische Autohersteller, die die XEN-basierte Lösung für zukünftige Autos mit digitalem Cockpit, Android im Inneren und anderen oben erwähnten Dingen evaluieren.
Parallel zu dieser großartigen Geschichte entwickeln wir unsere eigene vernetzte Fahrzeugplattform Aos. Die Hauptidee ist, dass wir einerseits den Entwicklern vernetzter Dienste die Möglichkeit geben, sie direkt auf einem Autocomputer bereitzustellen, und andererseits sie von kritischen Funktionen isolieren, um die Sicherheit zu gewährleisten. Ich werde im nächsten Teil darüber sprechen.