DE102023003362A1

DE102023003362A1 - Infotainment-Steuereinheit für ein Fahrzeug

Info

Publication number: DE102023003362A1
Application number: DE102023003362.6A
Authority: DE
Inventors: Mihai Marchidann
Original assignee: Mercedes Benz Group AG
Current assignee: Mercedes Benz Group AG
Priority date: 2023-08-12
Filing date: 2023-08-12
Publication date: 2023-10-05

Abstract

Die Erfindung betrifft eine portable Infotainment-Steuereinheit (100), die zur Verbindung mit mindestens einem Infotainment-System (200) und/oder einem Fahrzeugsteuergerät (400) eines Fahrzeugs über mindestens ein Fahrzeugnetzwerk (300, 301) und zur Ansteuerung mindestens einer Infotainment- und/oder Fahrzeugfunktion eingerichtet ist. Die Infotainment-Steuereinheit (100) umfasst mindestens ein Display (111, 121) und eine Verarbeitungseinheit mit einem Host-Betriebssystem, das mindestens einen Hypervisor (102) und eine erste, als minimale Zentralverarbeitungseinheit (MCPU) (103) ausgebildete Virtuelle Maschine (VM) sowie mindestens eine weitere, als Anwendungs-VM (104 bis 106) ausgebildete Virtuelle Maschine bereitstellt, welche von dem Hypervisor (102) überwacht und in voneinander isolierten Laufzeitumgebungen betrieben werden. Die MCPU (103) stellt unter einem sicheren Gast-Betriebssystem eine Adaptive Automotive Open System Architecture (AUTOSAR) Software-Umgebung bereit und umfasst einen Gateway Validator (112) und ist zur Ansteuerung eines sicheren Displays (111) sowie zur Datenübertragung mit mindestens einem Fahrzeugnetzwerk (300, 301) eingerichtet. Die mindestens eine Anwendungs-VM (104 bis 106) umfasst mindestens eine zur Ansteuerung eines generischen Displays (121) eingerichtete generische Schnittstellen-App (122), einen generischen App-Stack (123) und mindestens eine validierte App (124).

Description

Die Erfindung betrifft eine Infotainment-Steuereinheit gemäß dem Oberbegriff des Anspruchs 1.
Moderne Fahrzeuge weisen als Infotainment-Systeme bezeichnete Vorrichtungen auf, die einem Fahrzeuginsassen Komfort-, Sicherheits- und Unterhaltungsfunktionen bereitstellen, beispielsweise Radioprogramme, Multimedia-Inhalte, Funktionen zur Fahrzeugnavigation oder zur Verbindung mit externen Systemen. Typischerweise umfassen solche Infotainment-System mindestens ein Display sowie ein zentrales Infotainment-Steuergerät sowie eine als Head-Unit bezeichnete zentrale Bedieneinheit.
Zu den von Infotainment-Systemen bereitgestellten Funktionen können die Wiedergabe von Radioprogrammen oder Multimedia-Inhalten gehören, die insbesondere auch für Fahrzeuginsassen in einem hinteren Fahrzeugbereich über Displays und Steuergeräte angeboten werden, die in einem vorderen und/oder hinteren Fahrzeugsitz integriert sind.
Moderne Infotainment-Systeme weisen darüber hinaus die Möglichkeit auf, die Anzeige eines Smartphones zu spiegeln, das heißt: auf einem dem Infotainment-System zugeordneten Display darzustellen. Dies kann auch die Verwendung von Bedienelementen der Head-Unit zur Steuerung von Funktionen des Smartphones umfassen. Technologien zur Spiegelung von Smartphone-Anzeigen sind beispielsweise unter der Bezeichnung „MirrorLink“, „Apple CarPlay“ und „Android Auto“ bekannt und verfügbar.
Unter einem Steuergerät (auch als Electronic Control Unit, ECU bezeichnet) soll hier und im Folgenden ein eingebettetes System verstanden werden, welches derart eingerichtet und in die Elektronik eines Fahrzeugs derart integrierbar ist, dass ein elektrisches oder elektronisches System oder Teilsystem des Fahrzeugs mit dem Steuergerät gesteuert werden kann. Außer zur Ansteuerung von Funktionen eines Infotainment-Systems sind zahlreiche weitere Fahrzeugsteuergeräte bekannt, beispielsweise zur Steuerung von Funktionen des Antriebsstrangs, des Bremssystems oder der Lenkung und Fahrzeugstabilisierung.
Ein Steuergerät, das zur Verbindung mit einem Fahrzeug, insbesondere zur Verbindung mit einem Infotainment-System und/oder einem Fahrzeugsteuergerät über ein Fahrzeugnetzwerk eingerichtet ist und über das Fahrzeugfunktionen gesteuert werden können, das jedoch von diesem Fahrzeug trennbar und insbesondere mobil, vorzugsweise in der Art eines Smartphones oder Mobiltelefons tragbar ausgebildet ist, wird hier und im Folgenden als portable Infotainment-Steuereinheit bezeichnet.
Die Veröffentlichung US 2018/0307515 A1 beschreibt ein portables Rechengerät, auf dem mindestens eine Virtuelle Maschine (virtual machine, VM) bereitgestellt ist, welche zur Kommunikation mit und zur Steuerung von mindestens einem Gerät eingerichtet ist, das einem Nutzer des portablen Rechengeräts zugeordnet ist. Beispielsweise kann die VM zur Kommunikation mit einem Fahrzeug, einem Gebäude, einem Büro oder dem Körper des Nutzers eingerichtet sein. Durch die Bereitstellung von VMs, welche zur Steuerung spezifischer Systeme des Nutzers eingerichtet und vorgesehen sind, wird die Sicherheit solcher VMs verbessert, indem das Eindringen von Schadcode in diese VMs verhindert wird.
Der Erfindung liegt die Aufgabe zu Grunde, eine verbesserte Steuereinheit zur Ansteuerung mindestens einer Infotainment- und/oder Fahrzeugfunktion eines Fahrzeugs anzugeben.
Die Aufgabe wird erfindungsgemäß durch eine portable Steuereinheit mit den Merkmalen des Anspruchs 1 gelöst.
Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
Eine portable Infotainment-Steuereinheit ist zur Verbindung mit mindestens einem Infotainment-System und/oder einem Fahrzeugsteuergerät eines Fahrzeugs über mindestens ein Fahrzeugnetzwerk eingerichtet und für die Ansteuerung mindestens einer Infotainment- und/oder einer Fahrzeugfunktion eingerichtet.
Erfindungsgemäß umfasst die Infotainment-Steuereinheit mindestens ein Display und eine Verarbeitungseinheit, auf der ein Host-Betriebssystem installiert ist. Unter dem Host-Betriebssystem sind mindestens ein Hypervisor, eine erste sowie mindestens eine weitere Virtuelle Maschine (VM) bereitgestellt.
Als Hypervisor wird hier und im Folgenden eine Softwareschicht verstanden, welche von einer tatsächlich physikalisch vorhandenen Hardware und einem darauf installierten und laufenden Host-Betriebssystem abstrahiert wird und es ermöglicht, oberhalb dieser abstrahierenden Softwareschicht weitere, voneinander und gegenüber dem Host-Betriebssystem isolierte Gast-Betriebssystem zu installieren und zu betreiben. Für jedes dieser Gast-Betriebssysteme wird eine virtuelle Umgebung bereitgestellt, die eine Zentrale Verarbeitungseinheit (Central Processing Unit, CPU), Speicher sowie optional weitere Peripherie und weitere Hardwareressourcen bereitstellt. Der Hypervisor steuert die Aufteilung und Zuteilung der tatsächlich physikalisch vorhandenen Ressourcen zwischen dem Host-Betriebssystem und dem mindestens einen Gast-Betriebssystem.
Die erste Virtuelle Maschine ist als Minimale Zentralverarbeitungseinheit (minimal CPU, MCPU) ausgebildet. Die mindestens eine weitere Virtuelle Maschine ist als Anwendungs-VM ausgebildet.
Auf der MCPU ist ein besonders abgesichertes, den Anforderungen des Automotive Bereichs genügendes Gast-Betriebssystem installiert, unter dem eine Adaptive Automotive Open System Architecture (AUTOSAR) Software-Umgebung bereitgestellt ist. Die Adaptive AUTOSAR Software-Umgebung kann zur Unterstützung von Anwendungen für Steuergeräte entsprechend der Norm ISO 26262 „Road Vehicles - Functional Safety“ eingerichtet sein. Die MCPU kann zur Kommunikation mit einem Infotainment-System und/oder einem Fahrzeugsteuergerät über das mindestens eine Fahrzeugnetzwerk eingerichtet sein und darüber Signale und/oder Dienste austauschen, wobei dieses Fahrzeugnetzwerk nicht besonders abgesichert sein muss. Alternativ oder zusätzlich kann die MCPU in einer nachfolgend noch genauer beschriebenen Weise auch auf Signale und/oder Dienste einer Fahrzeug-Zentralverarbeitungseinheit (Vehicle Central Processing Unit, VCPU) zugreifen, welche mit einem besonders abgesicherten Fahrzeugnetzwerk mit einem Infotainment-System und/oder einem Fahrzeugsteuergerät verbunden ist und deren Signale und/oder Dienste mindestens teilweise verfügbar macht.
Ferner ist auf der MCPU ein Gateway Validator bereitgestellt, der zur Überwachung und Freigabe (beziehungsweise Sperrung) von Kommunikationsanfragen eingerichtet ist, die von außerhalb der MCPU an diese gerichtet sind.
Die MCPU ist ferner zur Ansteuerung eines sicheren Displays sowie zur Datenübertragung von beziehungsweise an mindestens ein Fahrzeugnetzwerk eingerichtet. Bevorzugt ist die MCPU zur Verbindung von Aktuatoren und/oder Sensoren mit einer oder mehreren Anzeigevorrichtungen eingerichtet, beispielsweise mit einem nachfolgend noch genauer erklärten generischen Display und/oder sicheren Display. Ferner ist die MCPU bevorzugt zur Datenweiterleitung an die mindestens eine Anwendungs-VM eingerichtet.
Die mindestens eine Anwendungs-VM umfasst mindestens eine generische Schnittstellen-App, einen generischen App-Stack und mindestens eine validierte App sowie mindestens ein generisches Display.
Als „generisch“ werden solche Hardware- und Softwarekomponenten bezeichnet, die nicht spezifisch für die Steuerung von Fahrzeugfunktionen vorgesehen und eingerichtet und/oder nicht gemäß den Vorgaben für den Automotive Bereich entwickelt worden sind.
Als „validiert“ werden solche Hardware- und Softwarekomponenten bezeichnet, für die, beispielsweise durch Review und/oder Testung, ein sicherer Betrieb in Verbindung mit der MCPU und der von der MCPU auf das Fahrzeug einwirkenden Steuerfunktionen nachgewiesen wurde.
Unter einer App soll hier und im Folgenden ein ausführbares Anwendungsprogramm verstanden werden. Eine generische Schnittstellen-App stellt Funktionen zur Kommunikation über Schnittstellen der jeweiligen Anwendungs-VM bereit, beispielsweise zur Kommunikation über einen Netzwerkadapter (Network Interface Card), zur Kommunikation mit einem Mobilfunknetz basierend auf einem der Anwendungs-VM zugeordneten Subscriber Identity Module (SIM) oder zur Kommunikation mit einer auf dem mindestens einen generischen Display dargestellten Bedienschnittstelle (User Interface, Ul).
Ein generischer App-Stack umfasst mindestens eine, typischerweise eine Mehrzahl von in Schichten aufeinander aufbauenden generischen Apps. Derartige App-Stacks werden beispielsweise von Betriebssystemen angeboten, die für mobile Endgeräte wie Smartphones oder Tablet Computer vorgesehen sind.
Der Gateway Validator ist zur sicheren Kommunikation der mindestens einen validierten App mit der Adaptiven AUTOSAR Umgebung eingerichtet, welche von der MCPU bereitgestellt wird. Beispielsweise kann der Gateway Validator für die Prüfung eingehender Kommunikations- und Dienstanfragen anhand eines kryptographischen Zertifikats eingerichtet sein und Anfragen von Apps abweisen, welche nicht (anhand eines derartigen Zertifikats) nachweisen können, dass sie für den Betrieb mit einem Fahrzeug validiert worden sind.
Da lediglich die MCPU sowie optional eine nachfolgend noch genauer erläuterte Fahrzeug-Zentralverarbeitungseinheit (Vehicle Central Processing Unit, VCPU), nicht jedoch die Anwendungs-VMs auf ein Fahrzeugnetzwerk zugreifen können, kann somit eine schädliche Beeinflussung von Funktionen des Fahrzeugs durch Schadcode und/oder Softwarekomponenten unzureichender Qualität ausgeschlossen werden.
Ein Vorteil der vorgeschlagenen Infotainment-Steuereinheit besteht ferner darin, dass in den isolierten Laufzeit- und Softwareumgebungen der Anwendungs-VMs Apps mit einem attraktiven Funktionsumfang, in modernem grafischem Design und mit kurzen Release-Zyklen angeboten werden können, wie sie der Nutzer aus dem Bereich mobiler Endgeräte (beispielsweise Smartphones oder Tablet Computer) kennt und erwartet.
Zugleich können, indem sicherheits- und zuverlässigkeitskritische Funktionen, welche in die Fahrzeugsteuerung eingreifen, innerhalb der MCPU gekapselt und insbesondere gegenüber einer Beeinflussung von Apps der mindestens einen Anwendungs-VM durch den Gateway Validator isoliert werden, die spezifischen Anforderungen des Automotive Bereichs an die Zuverlässigkeit und Sicherheit von Softwarekomponenten aufrechterhalten werden.
Somit entfällt der Bedarf, Entwicklern derartiger Apps Informationen über Entwurfsdetails eines Fahrzeugs für die Entwicklung oder Anpassung dieser Apps für ein Steuergerät offenzulegen. Indem fahrzeugspezifische Funktionen innerhalb der MCPU gekapselt und nur über eine durch den Gateway Validator kontrollierte Schnittstelle verfügbar gemacht werden, kann das geistige Eigentum eines Fahrzeugherstellers besser geschützt werden. Zudem können die Entwicklungszyklen von Apps, welche sicherheits- und zuverlässigkeitskritische, in die Steuerung des Fahrzeugs eingreifende Funktionen bereitstellen, besser von Entwicklungszyklen generischer Apps entkoppelt werden, die beispielsweise auf die Anwendung in Smartphones oder ähnlichen mobilen Endgeräte ohne spezifischen Bezug zur Steuerung eines Infotainment-Systems oder eines Fahrzeugsteuergeräts gerichtet sind.
Ausführungsbeispiele der Erfindung werden im Folgenden anhand von Zeichnungen näher erläutert.
Dabei zeigen:

1 schematisch eine vereinfachte Infotainment-Steuereinheit in einem Fahrzeugnetzwerk sowie
2 bis 4 schematisch eine Software- und Kommunikationsarchitektur für eine Infotainment-Steuereinheit in der Art eines OEM Phones.

Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugszeichen versehen.
1 zeigt schematisch eine vereinfachte portable Infotainment-Steuereinheit 100, die mit einem Infotainment-System 200 eines nicht näher dargestellten Fahrzeugs über ein Fahrzeugnetzwerk 300 sowie über ein besonders abgesichertes Fahrzeugnetzwerk (im Folgenden als sicheres Fahrzeugnetzwerk 301 bezeichnet) verbunden ist. Die Infotainment-Steuereinheit 100 ist in der Art eines Smartphones ausgebildet.
In der schematisch vereinfachten Darstellung nach 1 ist die Infotainment-Steuereinheit 100 über das Fahrzeugnetzwerk 300 und das sichere Fahrzeugnetzwerk 301 mit einer nicht näher dargestellten Topologie von Steuergeräten des Fahrzeugs verbunden. Eine solche Verbindung kann beispielsweise über eine OnBoard Diagnose II (OBD II) Standardverbindung hergestellt sein. Alternativ oder zusätzlich kann eine solche Verbindung auf der physikalischen Ebene (entsprechend den Schichten 1 und 2 des ISO/OSI Referenzmodells) über eine drahtgebundene Ethernet-Verbindung hergestellt sein.
Gegenüber aus dem Stand der Technik bekannten Verfahren zur Verbindung von Smartphones mit Fahrzeugsteuergeräten wie CarPlay oder Android Auto basierend auf BlueTooth und/oder Universal Serial Bus (USB) sind dadurch alternative Verbindungsmöglichkeiten bereitgestellt. Zudem ist gegenüber aus dem Stand der Technik bekannten Smartphones ein weiteres Display (das sichere Display 111 zusätzlich zu dem generischen Display 121) bereitgestellt. Ein Vorteil der erfindungsgemäßen Infotainment-Steuereinheit 100 besteht daher darin, dass die Nutzerinteraktion zur Ansteuerung von Fahrzeugfunktionen nicht auf fahrzeuggebundene Anzeigevorrichtungen beschränkt ist, wie bei Smartphones, die mit derartigen herkömmlichen Verfahren mit einem Fahrzeug verbunden werden.
Über das Fahrzeugnetzwerk 300 werden Protokollstandards und/oder Verbindungstechnologien zur Verbindung (Datenübertragung) zwischen Smartphones und einem Infotainment-System 200 eines Fahrzeugs bereitgestellt. Derartige Protokolle sind (lediglich beispielhaft und nicht abschließend aufgeführt) als MirrorLink, als CarPlay oder als Android Auto bekannt.
Mit derartigen Protokollen können Anwendungen (Apps) auf dem Smartphone über Bedienelemente (beispielsweise Knöpfe oder Schalter am Lenkrad oder von einem berührungsempfindlichen Display bereitgestellte Bedienelemente) des Fahrzeugs bedient werden. Durch die Verwendung solcher Protokolle und Technologien war es möglich, verglichen mit den Entwicklungszyklen für die Fahrzeugelektronik neuere und in kürzeren Abständen aktualisierbare Anwendungen auf einem Smartphone bereitzustellen.
Lediglich beispielhaft sind in 1 eine sichere App 110 sowie eine generische App 120 dargestellt, die auf der Infotainment-Steuereinheit 100 als Softwarekomponenten bereitgestellt sind und über ein jeweils zugeordnetes sicheres Display 111 beziehungsweise generisches Display 121 eine Nutzerschnittstelle bereitstellen. Die sichere App 110 kommuniziert über das sichere Fahrzeugnetzwerk 301 mit einer Steueranwendung 210 des Infotainment-Systems 200. Die generische App 120 kommuniziert über das Fahrzeugnetzwerk 300 mit einer generischen Anwendung 220 des Infotainment-Systems 200.
Mit den bereits erwähnten Protokollstandards und Verbindungstechnologien (beispielsweise MirrorLink, CarPlay, AndroidAuto) können Fahrzeuginsassen (Fahrer und/oder Beifahrer) ihre Smartphones mit einer als Head Unit bezeichneten Schnittstelle des Infotainment-Systems 200 verbinden. Es sind jedoch auch Anwendungen möglich, bei denen Smartphones von Fahrzeuginsassen mit anderen Schnittstellen und/oder Teilsystemen, beispielsweise Teilsystemen eines auf mehrere Komponenten verteilten Infotainment-Systems 200 verbunden werden können. Beispielsweise sind als Rear Seat Entertainment bezeichnete Teilsysteme von Infotainment-Systemen 200 bekannt, welche an die Rückenlehnen von Vordersitzen integrierte Displays umfassen und mit denen im hinteren Fahrzeugteil sitzende Fahrzeuginsassen ihre Smartphones verbinden können.
Eine Übersicht zur Architektur von Softwarekomponenten der als Android Auto bezeichneten Verbindungstechnologie ist beispielsweise unter https.7/www.androidautomotivebook.com/android-automotive-embedded-os-whitepaper/ veröffentlicht worden. Eine Übersicht zu Merkmalen der als Android Auto bezeichneten Verbindungstechnologie ist beispielsweise unter https://www.androidautomotivebook.com/android-automotive-embedded-os-whitepaper/ veröffentlicht worden. Vorteile einer als CarPlay bezeichneten Verbindungstechnologie sind beispielsweise unter https://www.patentlyapple.com/2022/09/apple-has-won-a-patent-for-their-next-qen-2023-carplav-interface-with-dashboard-clusters-for-vehicles-and-beyond.html veröffentlicht worden. Insbesondere ist es mit gewissen Verbindungstechnologien, beispielsweise mit CarPlay, möglich, außer den eigenen Anwendungen (Apps) auch in das Fahrzeug integrierte Funktionen zu steuern, welche von Fremdherstellern bereitgestellt wurden.
Für die Infotainment-Steuereinheit 100 wird eine Software-Architektur vorgeschlagen, die eine Klassische Automotive Open System Architecture (AUTOSAR) und eine Adaptive AUTOSAR Architektur umfasst.
Die Klassische AUTOSAR Architektur ist beispielsweise auf einem Microcontroller (MCU) implementiert und umfasst mindestens drei Softwareschichten: eine Anwendungsschicht, eine Laufzeitumgebung (runtime environment, RTE) sowie eine Basissoftware (BSW). Softwarekomponenten der Anwendungsschicht (auch als Anwendungen bezeichnet) greifen auf die BSW über die RTE zu.
Mit einer derartigen Klassischen AUTOSAR Architektur ist es möglich, Sensorwerte von Sensoren des Fahrzeugs auszulesen, Aktuatoren anzusteuern und eine Präsentationslogik sowie die Kommunikation von Signalen und Diensten, die von Sensoren und Aktuatoren angeboten werden, über das Fahrzeugnetzwerk 300 bereitzustellen. Eine derartige Architektur ist beispielsweise unter https://www.redeweb.com/en/articulos/como-enfrentar-los-desafios-de-la-arquitectura-e-e-de-future-zone-introduccion-de-una-Plataforma-de-solucion-de-virtualizacion-basada-enmcu/ beschrieben.
Eine Adaptive AUTOSAR Architektur, die auch als minimale Zentralverarbeitungseinheit (minimal Central Processing Unit, MCPU) ausgebildet sein kann, nutzt einen Hochleistungs-Rechenknoten innerhalb eines sicheren Betriebssystem-Hypervisors. Beispielhaft ist eine Adaptive AUTOSAR Architektur unter https://www.renesas.com/in/en/video/vector-r-car-solutions beschrieben.
Eine integrierte Architektur umfassend sowohl eine Klassische als auch eine Adaptive AUTOSAR Architektur, ist beispielsweise unter https://www.inchron.com/renesas/ beschrieben worden.
2 zeigt schematisch eine Software- und Kommunikationsarchitektur für eine mobile Infotainment-Steuereinheit 100, das in der Art eines Smartphones ausgestaltet ist und in dieser Ausführungsform im Folgenden auch als Original Equipment Manufacturer (OEM) Phone 100 bezeichnet wird. Alternativ zu einer Ausführung als Smartphone sind jedoch auch andere Ausführungsformen der Infotainment-Steuereinheit 100, beispielsweise als Tablet Computer, möglich.
Das OEM Phone 100 ist über das Fahrzeugnetzwerk 300 mit dem Infotainment-System 200 eines in 2 nicht näher dargestellten Fahrzeugs verbunden. Parallel zu der Verbindung über das Fahrzeugnetzwerk 300 ist das OEM Phone 100 über ein sicheres Fahrzeugnetzwerk 301 mit dem Infotainment-System 200 verbunden. Das Fahrzeugnetzwerk 300 und das sichere Fahrzeugnetzwerk 301 können über ein einziges, gemeinsames physikalisches Netzwerk bereitgestellt werden, beispielsweise über ein drahtloses Netzwerk, in dem das sichere Fahrzeugnetzwerk 301 beispielsweise als Virtual Private Network (VPN) in besonders zugriffsgeschützter Weise bereitgestellt wird. Beispielsweise kann ein als VPN ausgebildetes sicheres Fahrzeugnetzwerk 301, wie nachfolgend noch genauer erläutert wird, über ein kryptographisches Zertifikat abgesichert werden.
Darüber hinaus bietet eine Adaptive AUTOSAR Architektur neben kryptografisch sicheren Lösungen für die Kommunikation mit dem sicheren Fahrzeugnetzwerk 301 mehrere komplementäre sichere Technologien zur Sicherung der Kommunikationswege zwischen dem OEM Phone 100 und dem Infotainment-System 200 sowie für Kommunikationswege innerhalb des OEM Phone 100, beispielsweisegemäß SecOC (Specification of Secure Onboard Communication Protocol, https://www.autosar.org/fileadmin/standards/R20-11/FO/AUTOSAR_PRS_SecOcProtocol.pdf) und/oder als Adaptives AUTOSAR-Kryptographie-Management (gemäß https://www.autosar.org/fileadmin/standards/R22-11/AP/AUTOSAR SWS Cryptography.pdf).
In der vorliegend dargestellten Ausführungsform ist das OEM Phone 100 über das Fahrzeugnetzwerk 300 und das sichere Fahrzeugnetzwerk 301 außer mit dem Infotainment-System 200 mit einem weiteren Fahrzeugsteuergerät 400 verbunden.
Bei der Ausführungsform gemäß 2 sind ein Mikrocontroller (MCU) und eine darauf implementierte Klassische AUTOSAR Architektur als eine Zentralverarbeitungseinheit bereitgestellt, die als Fahrzeug-Zentralverarbeitungseinheit (Vehicle Central Processing Unit, VCPU) 101 bezeichnet wird.
Eine derartige VCPU 101 steuert Aktuatoren und/oder überwacht Sensoren des Fahrzeugs direkt, beispielsweise über ein als Controller Area Network (CAN) Bus und/oder als Ethernet sicheres Fahrzeugnetzwerk 301. Ferner kommuniziert die VCPU 101 mit der MCPU 103 und stellt der MCPU 103 Signale und/oder Dienste bereit, über die Funktionen des Infotainment-Systems 200 und/oder weiterer Fahrzeugsteuergeräte 400 verfügbar gemacht werden. Bevorzugt ist die VCPU 101 die einzige Komponente des Infotainment-Steuergeräts 100, die mit dem sicheren Fahrzeugnetzwerk 301 verbunden ist und kapselt somit den Zugriff auf zuverlässigkeits- und sicherheitskritische Funktionen des Fahrzeugs.
Optional kann die VCPU 101 zusätzlich zu der Verbindung mit dem sicheren Fahrzeugnetzwerk 301 auch über ein nicht besonders abgesichertes Fahrzeugnetzwerk 300 auf Signale und/oder Dienste von Steuergeräten des Fahrzeugs zugreifen, insbesondere auf solche, die nicht sicherheits- oder zuverlässigkeitskritisch sind.
Bevorzugt ist die VCPU 101 für Klassische AUTOSAR Anwendungen für Steuergeräte gemäß der Norm ISO 26262 („Road Vehicles - Functional Safety“) bis hin zu einem Automotive Safety Integrity Level (ASIL) D zugelassen und zertifiziert.
Ferner umfasst das OEM Phone 100 einen sicheren Hypervisor 102. Der Hypervisor 102 stellt Virtuellen Maschinen 103 bis 106 eine von dem nativen Betriebssystem des OEM Phones 100 entkoppelte Laufzeitumgebung bereit. Jede der Virtuellen Maschinen 103 bis 106 stellt ein unabhängiges Gast-Betriebssystem mit darauf zugreifenden Softwarekomponenten bereit.
Eine erste Virtuelle Maschine (virtual machine, VM) 103 stellt ein sicheres Gast-Betriebssystem mit einer Adaptiven AUTOSAR Umgebung bereit, die den Sicherheitsanforderungen im Automotive Bereich genügt. Bevorzugt ist die erste Virtuelle Maschine 103 als minimale CPU (MCPU) 103 ausgebildet. Als sicheres Gast-Betriebssystem kann beispielsweise QNX eingesetzt werden.
Ferner können unter diesem sicheren Gast-Betriebssystem sichere Apps 110 bereitgestellt werden, die Funktionen zur Diagnose, Wartung und Konfiguration des Fahrzeugs anbieten. Die sicheren Apps 110 stellen eine Nutzerschnittstelle auf einem sicheren Display 111 bereit.
Ferner stellt die MCPU 103 unter dem sicheren Gast-Betriebssystem einen Gateway Validator 112 bereit, über den in nachfolgend noch genauer erläuterter Weise Funktionen (Dienste) der sicheren Apps 110 für generische Apps 120 anderer virtueller Maschinen 104 bis 106 angeboten werden.
Durch das sichere Gast-Betriebssystem, das auch über den Gateway Validator 112 auf der Applikationsebene geschützt ist, stellt die MCPU 103 eine ausreichend geschützte Laufzeitumgebung dar, da eine Adaptive AUTOSAR Architektur Anwendungen für Steuergeräte nach ISO 26262 auf einer ASIL-Ebene unterstützt.
Gemäß der in 2 vorgeschlagenen Ausführungsform unterstützt die VCPU 101 Anwendungen für Steuergeräte nach ISO 26262 bis ASIL-D und stellt die einzige Komponente des OEM Phone 100 dar, die auf das sichere Fahrzeugnetzwerk 301 zugreifen kann.
Darüber hinaus ermöglicht der Hypervisor 102 die Ausführung einer zweiten bis vierten Virtuellen Maschine 104 bis 106, die jeweils einen Stack von generischen Apps 120 umfassen, der in der Art der typischen Laufzeitumgebung eines Smartphones ausgebildet ist. Diese Laufzeitumgebungen sind nicht in besonderer Weise für die Steuerung von Funktionen eines Fahrzeugs geschützt, können aber Gast-Betriebssysteme aufweisen, die für einen Einsatz im Automotive Bereich geeignet und zugelassen sind, beispielsweise das Betriebssystem QNX. Zur Unterscheidung von der MCPU 103 sollen die zweite bis vierte Virtuelle Maschine (VM) 104 bis 106 als Anwendungs-Virtuelle Maschine (Anwendungs-VM) 104 bis 106 bezeichnet werden. Es wird jedoch darauf hingewiesen, dass sich die Anwendungs-VM 104 bis 106 von der MCPU 103 lediglich durch das darauf laufende Gast-Betriebssystem und die darauf laufenden Apps 110, 120 unterscheiden und ansonsten in gleicher Weise von dem Hypervisor 102 verwaltet werden.
Typischerweise umfasst jede Anwendungs-VMs 104 bis 106 mindestens eine, üblicherweise mehrere generische Schnittstellen-Apps 122, mit denen ein Zugriff auf ein Subscriber Identity Module (SIM), auf einen Netzwerkadapter (Network Interface Card, NIC) und/oder auf eine Nutzerschnittstelle (User Interface, UI) angeboten und gesteuert wird.
Ferner umfasst jede dieser Anwendungs-VMs 104 bis 106 einen generischen App-Stack 123 von generischen Apps 120, die generische Funktionen eines Smartphones bereitstellen (beispielsweise Geoinformations-Apps, Telefonie- oder Messenger Apps oder Apps zur Verwaltung von Kontakten), die keinen direkten Bezug zu fahrzeugspezifischen Funktionen aufweisen.
Ferner umfasst jede dieser Anwendungs-VMs 104 bis 106 eine oder mehrere validierte Apps 124, mit denen sowohl fahrzeugspezifische als auch generische Funktionen ausgeführt oder ausgelöst werden können. Unter einer validierten App 124 soll dabei eine App verstanden werden, die für die Laufzeitumgebung der jeweiligen Virtuellen Maschine 104 bis 106 als kompatibel und sicher in Verbindung mit dem Betrieb des Fahrzeugs zugelassen wurde.
So kann beispielsweise die zweite Virtuelle Maschine 104 eine vom Hersteller des Fahrzeugs (OEM) bereitgestellte, proprietäre Laufzeitumgebung sein, die validierte Apps 124 umfasst, die ebenfalls vom Hersteller des Fahrzeugs entwickelt und bereitgestellt wurden. Die dritte Virtuelle Maschine 105 kann als Android Laufzeitumgebung bereitgestellt werden. Die vierte Virtuelle Maschine 106 kann als iOS Laufzeitumgebung bereitgestellt werden.
Generische Apps 120, generische Schnittstellen-Apps 122 und validierte Apps 124 können selbstverständlich auch vom Fahrzeughersteller selbst angeboten werden. Insbesondere kann auch ein kompletter generischer App-Stack 123 (eine Menge von untereinander kommunizierenden, einander aufrufenden Apps) vom Fahrzeughersteller selbst angeboten werden. Derartige Apps und App-Stacks werden als OEM Apps beziehungsweise OEM App-Stacks bezeichnet.
Bevorzugt sind generische und/oder sichere Apps 120, 110 als Software-Container ausgebildet, beispielsweise als Docker-Container. Verfahren zur Containerisierung von Softwarekomponenten, beispielsweise Apps, sind aus dem Stand der Technik bekannt.
Eine Anwendungs-VM 104 bis 106 kann zur Interaktion mit einem Nutzer auf ein zugeordnetes generisches Display 121 zugreifen, das exklusiv einer einzigen Virtuellen Maschine 104 oder einer Mehrzahl von Virtuellen Maschinen 105, 106 zugeordnet sein kann. Im vorliegend dargestellten Ausführungsbeispiel greift die zweite Virtuelle Maschine 104 exklusiv auf ein generisches Display 121 zu, das von dem OEM bereitgestellt wird. Die dritte und vierte Virtuelle Maschine 105, 106 greifen gemeinsam auf ein generisches Display 121 zu.
Die validierten Apps 124 greifen über den Gateway Validator 112 auf Funktionen der Fahrzeugsteuerung zu, welche innerhalb der ersten (besonders geschützten) Virtuellen Maschine 103 von einer oder mehreren sicheren Apps 110 bereitgestellt werden. Eine derartige Verbindung zum Gateway Validator 112 wird jedoch für die weiteren (nicht validierten) generischen Apps 120, vorliegend für die generischen Schnittstellen-Apps 122 und den generischen App-Stack 123 der jeweiligen Virtuellen Maschine 104 bis 106, nicht zugelassen.
Ein Zugriff auf den Gateway Validator 112 ist für diejenigen validierten Apps 124, die von dem Fahrzeughersteller (OEM) selbst bereitgestellt werden (vorliegend in der zweiten Virtuellen Maschine 104), über eine Kommunikationsverbindung 125 stets möglich.
Für solche validierten Apps 124, die nicht von dem Fahrzeughersteller (OEM) selbst, sondern von einem Fremdhersteller bereitgestellt werden, können optionale Kommunikationsverbindungen 126 zu dem Gateway Validator 112 ermöglicht oder versagt werden. Beispielsweise kann eine optionale Kommunikationsverbindung 126 nur dann ermöglicht werden, wenn eine solche validierte App 124 und/oder deren Fremdhersteller einer Prüfung unterzogen wurde, die beispielsweise mit einem kryptographischen Zertifikat nachgewiesen werden kann.
Diese Software- und Kommunikationsarchitektur ermöglicht die Verwendung von für Smartphones (oder ähnliche mobile Endgeräte) üblichen Laufzeitumgebungen und generischen Apps 120 in Verbindung mit Funktionen zur Steuerung eines Fahrzeugs. Indem jede dieser Laufzeitumgebungen in einer Virtuellen Maschine 103 bis 106 gekapselt und der Zugriff auf fahrzeugspezifische Funktionen ausschließlich über den Gateway Validator 112 und somit in besonders geschützter Weise erfolgt, wird verhindert, dass sich Fehler oder Schadcodes einer solchen Laufzeitumgebung oder einer darin gehosteten generischen App 120 auf die Steuerung des Fahrzeugs auswirken. Nachfolgend wird die Kommunikation zwischen den Komponenten dieser Softwarearchitektur an einem vereinfachten Anwendungsbeispiel erläutert. Dazu soll angenommen werden, dass ein Nutzer mittels des OEM Phones 100 eine Fahrertür öffnen möchte.
Hierzu wählt der Nutzer ein Bedienelement (beispielsweise ein Icon oder einen Button) einer Bedienschnittstelle (User Interface Ul) aus, welche von einer generischen Schnittstellen-App 122 von der zweiten Virtuellen Maschine 104 auf einem zugeordneten generischen Display 121 angeboten wird.
Die Schnittstellen-App 122 fordert darauf die Ausführung einer validierten App 124 derselben (zweiten) Virtuellen Maschine 104 an, welche mit dem ausgewählten Bedienelement (Icon oder Button) assoziiert ist und die für die Steuerung der Funktion „Fahrertür öffnen“ zuständig ist (im Folgenden als „Schließ-App“ bezeichnet).
Die generische App 120 des generischen App-Stacks 123 sendet eine Anforderung zum Öffnen der Fahrertür an die besonders geschützte erste Virtuelle Maschine 103, genauer: an eine darauf laufende sichere App 110. Dabei wird diese Anforderung vom Gateway Validator 112 der ersten Virtuellen Maschine 103 entgegengenommen, validiert und bei erfolgreicher Validierung an die für die Steuerung der Fahrertür zuständige sichere App 110 weitergeleitet.
Die zuständige sichere App 110 der ersten Virtuellen Maschine 103 leitet die Anforderung zum Öffnen der Fahrertür an die VCPU 101 weiter. Die Übertragung der Anforderung von dem der zweiten Virtuellen Maschine 104 zugeordneten generischen Display 121 bis zur VCPU 101 erfolgt unter Verwendung der dafür vorgesehenen Domänen, Netzwerkhardware, Softwareressourcen und Kommunikationsprotokolle.
Die VCPU 101 sendet über das Fahrzeugnetzwerk 300 und/oder über das sichere Fahrzeugnetzwerk 301 eine Nachricht, beispielsweise ein Controller Area Network (CAN)- oder ein Ethernet-Signal und/oder -Service, an einen Aktuator zu einer Betätigung derart, dass die Fahrertür entriegelt und/oder geöffnet wird. Mit dem Empfang dieser Nachricht entriegelt und/oder öffnet der Aktuator die Fahrertür. Diese Nachricht kann über das Infotainment-System 200 und/oder über ein anderes Fahrzeugsteuergerät 400 an den Aktuator übermittelt werden.
Das OEM Phone 100 überwacht nachfolgend den Zustand eines Sensors, der das Öffnen der Fahrertür erfasst, durch regelmäßige, bevorzugt periodische Abfragen, direkt.
Das Ergebnis der regelmäßigen Abfragen wird von der VCPU 101 an die für die Überwachung der Fahrertür zuständige sichere App 110 der MCPU 103 übertragen. Von dort wird der Zustand des Sensors zur Erfassung des Öffnens der Fahrertür an die Schließ-App 124 übermittelt und von dieser auf dem der zweiten Virtuellen Maschine 104 zugeordneten generischen Display 121 dargestellt. Diese Übermittlung erfolgt über den Gateway Validator 112.
Die Schließ-App 124 übermittelt den Zustand des Aktuators über die generische Schnittstellen-App 122, welche das generische Display 121 ansteuert. Beispielsweise kann auf dem generischen Display 121 eine symbolhafte Darstellung einer geschlossenen Fahrzeugtür durch eine symbolhafte Darstellung einer geöffneten Tür ausgetauscht werden.
Alternativ oder zusätzlich können die Schritte von der Überwachung des Zustands des Sensors der Fahrertür bis zur Anzeige dieses Zustands auch von dem Infotainment-System 200 ausgeführt werden.
Es ist auch möglich, dass die Anzeige dieses Zustands (Fahrertür geöffnet / geschlossen) parallel oder ersatzweise zu der Anzeige auf einem generischen Display 121 des OEM Phones 100 auf einem dem Infotainment-System 200 zugeordneten Display im Fahrzeuginnenraum erfolgt, welches in 2 nicht näher dargestellt ist.
Der vorstehend beschriebene Ablauf beim Öffnen einer Fahrertür mittels des OEM Phones 100 ist lediglich beispielhaft zu verstehen. Anstelle eines Aktuators zum Entriegeln der Fahrertür können andere Funktionen des Fahrzeugs über das OEM Phone 100 angesteuert werden.
Zur Absicherung der Kommunikation zwischen dem OEM Phone 100 und dem Infotainment-System 200 oder einem anderen Fahrzeugsteuergerät 400 können kryptographische Zertifikate eingesetzt werden, welche mit einem dem Fahrzeug zugeordneten privaten kryptographischen Schlüssel signiert sind. Dadurch wird verhindert, dass unberechtigte Endgeräte, beispielsweise ein fremdes Smartphone, über das Fahrzeugnetzwerk 300 Fahrzeugfunktionen ansteuern, beispielsweise eine Fahrertür öffnen.
Es ist möglich, auf einem einzigen OEM Phone 100 eine Mehrzahl derartiger Zertifikate abzulegen, welche je einem Fahrzeug zugeordnet sind, für das dem Nutzer / Besitzer des OEM Phones 100 Zugriff gestattet wird.
Die auf einem Hypervisor 102 basierende Softwarearchitektur gemäß 2 ermöglicht die flexible Nutzung eines OEM Phones 100 und die Integration der darauf installierten Apps 110, 120 unabhängig davon, ob der Hersteller des OEM Phones 100 identisch mit dem Hersteller des Fahrzeugs ist, dessen Infotainment-System 200 (und/oder Fahrzeugsteuergerät 400) angesteuert wird.
Indem die Kommunikation zwischen dem OEM Phone 100 und dem Fahrzeug über ein kryptographisches Zertifikat abgesichert wird, ermöglicht die vorgeschlagene Softwarearchitektur zudem eine Verwendung des OEM Phone 100 als digitalen Fahrzeugschlüssel, mit dem das Fahrzeug geöffnet / verriegelt oder gestartet werden kann. Darüber hinaus ist es auch möglich, weitere Fahrzeugfunktionen und/oder Funktionen des Infotainment-Systems 200 in sicherer, portabler und nutzerfreundlicher Weise anzusteuern.
Beispielsweise sind Ausführungsformen des oben beispielhaft beschriebenen Ablaufs der Kommunikation möglich, mit denen ein Fahrzeug über das OEM Phone 100 ferngesteuert wird, wenn und solange eine (beispielsweise mit einem kryptographischem Zertifikat) abgesicherte Verbindung über ein sicheres Fahrzeugnetzwerk 301 besteht. Auf diese Weise kann die Bewegung des Fahrzeugs von dem OEM Phone 100 aus geleitet und unter Verwendung von digitalen Karten und/oder spezieller Hardware unterstützt werden. So kann ein generisches Display 121 des OEM Phones 100 berührungsempfindlich und zur Auswertung von Mehr-Finger-Gesten ausgelegt sein, um die Bedienung von Fahrzeugfunktionen zu erleichtern.
Mit der vorgeschlagenen Softwarearchitektur ist es auch möglich, ein OEM Phone 100 mit einem weiteren Fahrzeugsteuergerät 400 zu verbinden, über welches beispielsweise in sicherer Weise ein Antriebsstrang, ein Bremssystem, eine Mehrzahl von Fahrinstrumenten (beispielsweise ein Tachometer, die Anzeige einer aktuellen Fahrstufe, ein Fahrtrichtungsanzeiger oder die Anzeige einer Transmission) angesteuert und/oder abgefragt werden.
In einer weiteren, in 3 schematisch dargestellten Ausführungsform umfasst die Software- und Kommunikationsarchitektur einen VCPU Hypervisor 107, der eine Mehrzahl von VCPUs 101 (das heißt: von Virtuellen Maschinen, in denen je ein Abbild einer VCPU 101 abläuft) umfasst. Durch die Ausgestaltung als Mehrzahl voneinander entkoppelter VCPUs 101, die von einem VCPU Hypervisor 107 überwacht und gesteuert werden, kann die Robustheit, Flexibilität und Skalierbarkeit der Softwarearchitektur verbessert werden.
In einer weiteren Ausführungsform können mehrere solcher von dem VCPU Hypervisor 107 gesteuerter VCPUs 101 über gemeinsame (das heißt: von mehreren VCPUs 101 geteilte) Schnittstellen mit einer Virtuellen Maschine 103 bis 106 des Hypervisors 107 kommunizieren.
Die Softwarearchitektur kann mehrere Netzwerk Switches umfassen.
Die Softwarearchitektur kann die Einrichtung, Integration und Konfiguration von einem oder mehreren Netzwerkadaptern (Network Interface Cards NIC) ermöglichen, der oder die mehrere Media Access Controller (MAC) Adressen aufweist / aufweisen. Beispielsweise kann ein solcher Netzwerkadapter für die interne Kommunikation zu einer oder mehreren MCPUs 103 vorgesehen und eingerichtet sein. Ferner kann ein solcher Netzwerkadapter für die Einrichtung eines Virtuellen Netzwerk Switches vorgesehen und eingerichtet sein, über den in abgeschlossenen Laufzeitumgebungen (Sandboxes) ablaufende Virtuelle Maschinen 103 bis 106 mit Fremdanwendungen außerhalb des OEM Phones 100 kommunizieren.
In einer weiteren Ausführungsform ermöglicht die vorgeschlagene Software- und Kommunikationsarchitektur den Entwurf und die Implementierung von Lösungen zur sicheren Verbindung von mehreren Fahrzeugen untereinander.
Hersteller von Fahrzeugen können ein Menge von Schnittstellen zur Kommunikation und/oder zur Bereitstellung von Funktionen definieren oder vorschlagen, welche die Entwicklung von Anwendungen und Apps ermöglichen, die im geschützten Bereich einer Virtuellen Maschine 103 bis 106 ablaufen und welche mit einem Infotainment-System 200 eines Fahrzeugs dieses Fahrzeugherstellers, aber auch mit einem anderen Fahrzeugsteuergerät 400 kommunizieren können. Dadurch wird Fremdherstellern ermöglicht, Anwendungen für ein Fahrzeug zu entwickeln, ohne dass der Fahrzeughersteller den Fremdherstellern schützenswerte Details über den Entwurf und die Architektur des Fahrzeugs offenlegen muss.
Mit der vorgeschlagenen Softwarearchitektur wird somit das Erfordernis beseitigt oder beschränkt, Technologien wie AndroidAuto oder CarPlay Zugriff auf Entwurfsdetails oder geistiges Eigentum der Technologie eines Infotainment-Systems 200 zu gestatten, indem der Entwurf des OEM Phone 100 (beziehungsweise einer anders ausgebildeten Infotainment-Steuereinheit 100) von dem Entwurf des Fahrzeugs und der Fahrzeugnetzwerke 300, 301 separiert wird.
Durch diese Trennung wird verhindert, dass Fremdhersteller, welche generische Apps 120 für mobile Endgeräte außerhalb eines Fahrzeugs entwickeln, dafür Zugriff auf die interne, proprietäre Software- und Kommunikationsarchitektur eines Fahrzeugs benötigen oder fordern können. Insbesondere wird verhindert, dass, nachdem derartige generische Apps 120 eine besonders hohe Kundenbindung entwickelt haben, gewisse Aspekte der internen Software- und Kommunikationsarchitektur den Anforderungen derartiger generischer Apps 120 unterworfen werden muss oder sogar in Kauf genommen werden muss, dass mit solchen generischen Apps 120 verbundenes, von Patenten oder ähnlichen Schutzrechten umfasstes geistiges Eigentum in die interne Software- und Kommunikationsarchitektur eines Fahrzeugs aufgenommen wird.
Die vorgeschlagene Software- und Kommunikationsarchitektur ermöglicht die sichere Verbindung von OEM Phones 100, welche von Fremdherstellern (das heißt, nicht vom Hersteller des Fahrzeugs selbst) angeboten und entwickelt werden können, zu dem Fahrzeugnetzwerk 300 und/oder dem sicheren Fahrzeugnetzwerk 301 eines Fahrzeugs ohne Verwendung von Verbindungstechnologien wie AndroidAudio oder CarPlay.
Dadurch wird es Fahrzeugherstellern ermöglicht, ihr geistiges Eigentum (intellectual property, IP) Portfolio gegenüber Herstellern von mobilen Endgeräten zu schützen, welche unter Ausnutzung ihrer starken Verbreitung und Nutzerbindung ihre Position gegenüber Fahrzeugherstellern verbessern möchten. Einem Fahrzeughersteller wird es durch diese Trennung ermöglicht, Verfahren und Vorrichtungen zur internen Steuerung von Fahrzeugfunktionen eigenständig zu entwickeln.
In einer Ausführungsform stellt ein von einem Fahrzeughersteller bereitgestellter generischer App-Stack 123 (auch als OEM-Stack 123 bezeichnet) eine Möglichkeit bereit, weitere generische Apps 120 von einem App Store des Fahrzeugherstellers zu beziehen. Dadurch wird verhindert, dass Hersteller von mobilen Endgeräten oder von Apps für mobile Endgeräte Nutzer und/oder Hersteller von Fahrzeugen in ihr eigenes Software-Ökosystem drängen. Ferner wird die Beteiligung von unabhängigen (Freelance-) Softwareentwicklern an der Entwicklung solcher generischer Apps 122 bis 124 ermöglicht.
Ferner kann der Fahrzeughersteller einen besonderen App Store zur Bereitstellung von Verwaltung von validierten Apps 124 betreiben, denen der Zugriff (über den Gateway Validator 112) auf sicherheitskritische Funktionen oder auf das sichere Fahrzeugnetzwerk 301 gestattet wird.
In einer Ausführungsform weist das OEM Phone 100 eine Netzwerkkarte (Network Interface Card, NIC) mit zwei oder mehr Netzwerkschnittstellen und mit zwei oder mehr Media Access Controller (MAC) Adressen auf. Dadurch wird die Bedienbarkeit verbessert und es werden Voraussetzungen für eine spätere Erweiterung um Anwendungen und Komponenten geschaffen, die solche Hardware erfordern.
Zur verbesserten Trennung der zweiten bis vierten Virtuellen Maschinen 104 bis 106, welche die generischen Apps 120 hosten, kann jede dieser zweiten bis vierten Virtuellen Maschine 104 bis 106 mit eigener Kommunikationsperipherie (SIM Karte, NIC, MAC Adresse) versehen werden.
Die vorgeschlagene Software- und Kommunikationsarchitektur kann auf einer speziellen Hardwarearchitektur umgesetzt sein, auf der ein sicheres Host-Betriebssystem und ein sicherer Hypervisor 102 implementiert sind. Der Hypervisor 102 ermöglicht die Verwendung einer Mehrzahl von virtualisierten Laufzeitumgebungen, welche als Gast-Betriebssystem entweder eine Kopie des sicheren Host-Betriebsystems bereitstellen (beispielsweise das Betriebssystem QNX für sichere Mobiltelefonanwendungen) oder jeweils unterschiedliche Betriebssystem bereitstellen, beispielsweise Mercedes Benz Operating System (MBOS), AndroidAuto, iOS oder andere. Der zugelassene Mix von derartigen verschiedenen Gast-Betriebssystemen kann abhängig von dem vom Kunden gewünschten Sicherheitsniveau gewählt werden.
Insbesondere die Verwendung von sicheren Gast-Betriebssystemen für die Virtuellen Maschinen 104 bis 106, welche die generischen Apps bereitstellen, ermöglichen eine sicherere, aber auch flexiblere Integration von Anwendungen von Fremdherstellern in das Infotainment-System 200, sowohl auf einem System- als auch auf einem Anwendungsniveau.
In einer Ausführungsform weist das OEM Phone 100 eine hybride Hardwarearchitektur auf, die eine VCPU 101 basierend auf einem Mikrocontroller mit hoher Rechenleistung und geringer Latenz umfasst und die überdies eine als MCPU ausgebildete erste Virtuelle Maschine 103 umfasst, welche mehr Ressourcen bereitstellt und die Ausführung von Hochleistungs-Rechenanwendungen ermöglicht.
Mit der vorgeschlagenen Software- und Kommunikationsarchitektur wird eine Verlagerung von Softwarekomponenten aus dem Automotive Bereich in den Bereich von Anwendungen für mobile Endgeräte erreicht und/oder eine umgekehrte Verlagerung von Softwarekomponenten aus dem Bereich mobiler Endgeräte in den Automotive Bereich unterbunden. Es ist dadurch möglich, OEM Phones 100 zu entwickeln, welche dieselbe Hardware verwenden wie Komponenten eines Infotainment-Systems 200 in einem Fahrzeug und die zudem den Vorteil aufweisen, dass Fahrzeuge und zugeordnete OEM Phones 100 einander bei der Kommunikation und/oder beim Teilen von Anwendungen oder Apps 110, 120 vertrauen können.
Durch die Verwendung einer solchen Software- und Kommunikationsarchitektur ist es möglich, Technologien aus dem Automotive Bereich in den Bereich von Anwendungen für mobile Endgeräte zu transferieren und die Sicherheit und die Portabilität von Software und Technologien aus dem Automotive Bereich zu verbessern. Beispielsweise kann ein OEM Phone 100 Software- und/oder Hardwarekomponenten verschiedener Fahrzeughersteller verwenden und integrieren. Beispielsweise kann ein Steuergerät eines ersten Fahrzeugherstellers als OEM Phone 100 ausgebildet und paketiert werden, welches dann sichere Apps 110, 120 verschiedener anderer Fahrzeughersteller bezieht und integriert und welches über Fahrzeugnetzwerke 300, 301 verschiedener Fahrzeughersteller mit einem Fahrzeug des ersten oder eines anderen Fahrzeugherstellers kommuniziert.
Derartige OEM Phones 100 können Anwendungsportale und/oder App Stores für die sichere und einfache Integration von Apps 110, 120 verwenden, welche den Anforderungen an Softwarekomponenten für den Automotive Bereich genügen.
In einer weiteren, in 4 schematisch dargestellten Ausführungsform kann die VCPU 101 entfallen, wenn die MCPU 103 ausschließlich über das (nicht besonders abgesicherte) Fahrzeugnetzwerk 300 mit dem Infotainment-System 200 und/oder mit weiteren Fahrzeugsteuergeräten 400 kommuniziert, mit anderen Worten: wenn die MCPU 103 nicht über ein sicheres Fahrzeugnetzwerk 301 mit dem Fahrzeug verbunden wird. In einer solchen Ausführungsform kann ein OEM Phone 100 lediglich nichtessenzielle und nicht sicherheitskritische Fahrzeugfunktionen des Infotainment-Systems 200 und/oder anderer Fahrzeugsteuergeräte 400 ansteuern.
Dadurch, dass ein derart ausgebildetes OEM Phone 100 nicht auf ein sicheres Fahrzeugnetzwerk 301, und somit auch nicht auf sicherheits- und zuverlässigkeitskritische Aktuatoren und Sensoren zugreifen kann, können gewisse Fahrzeugfunktionen darüber nicht ausgeführt werden, wie beispielsweise das Öffnen von Fahrzeugtüren, das Starten des Antriebsmotors oder die Fernbedienung von aktuatorgesteuerten anderen Fahrzeugfunktionen.
Um die Kommunikation über das sichere Fahrzeugnetzwerk 301 wie auch über das unsichere Fahrzeugnetzwerk 300 zu schützen, wird die Verschlüsselung der darauf übertragenen Nachrichten vorgeschlagen.
Softwarearchitekturen für OEM Phones 100, welche auf Klassischen AUTOSAR und/oder Adaptiven AUTOSAR Stacks von Softwarekomponenten basieren, ermöglichen Anwendungsentwicklern für mobile Endgeräte die Implementierung von sicheren Anwendungen für Fahrzeuge. Dadurch können Fahrzeughersteller einen Vorteil gegenüber den Herstellern von mobilen Endgeräten und deren Anwendungen erlangen, welche in die Schnittstelle zwischen einem Fahrzeughersteller und einem Nutzer eines Fahrzeugs drängen, indem sie die hohe Verbreitung von mobilen Endgeräten und die hohe Bindung von Kunden an solche mobile Endgeräte ausnutzen. Mit der vorgeschlagenen Softwarearchitektur werden demgegenüber Fahrzeughersteller in die Lage versetzt, in dem Markt für mobile Endgeräte und deren Anwendungen einzudringen und ihr eigenes Software-Ökosystem gegenüber solchen vorgenannten Angriffen zu schützen.
Derartige OEM Phones 100 können einem Software-Ökosystem für mobile Endgeräte Schnittstellen für Infotainment-Systeme 200, Fahrzeugsteuergeräte 400 und Fahrzeugnetzwerke 300, 301 in sicherer Weise bereitstellen und dem Eindringen von Technologien aus dem Bereich mobiler Endgeräte entgegenwirken, wie es beispielsweise mittels CarPlay in der Veröffentlichung https://www.patentlyapple.com/2022/09/apple-has-won-a-patent-for-their-next-aen-2023-carplay-interface-with-dashboard-clusters-for-vehicles-and-beyond.html vorgeschlagen wird.
Durch die Verwendung eines aus einem Fahrzeug bekannten Steuergeräts in einem OEM Phone 100, das eine SIM Karte aufweist, werden Möglichkeiten für Verbindungstechnologien zwischen mobilen Endgeräten und Fahrzeugen eröffnet, die bekannte, auf mobile Endgeräte zentrierte Technologien wie CarPlay oder AndroidAuto ersetzen können. Dadurch werden Fahrzeughersteller von der Zahlung von Nutzungsgebühren von bis zu 30 Prozent für die Integration populärer Anwendungen für mobile Endgeräte entlastet. Fahrzeughersteller können dadurch die Verbreitung von Technologien anderer Hersteller kontrollieren.
Ferner können Fahrzeughersteller derartige OEM Phones 100 als sichere Fernbedienungseinheiten zur Steuerung und zum Auslesen beliebiger Aktuatoren, Sensoren und anderer Steuereinheiten in einem Fahrzeug nutzen, welche einen höheren Grad an Zuverlässigkeit und Sicherheit aufweisen, beispielsweise auch für sprachgesteuerte Bedienungsverfahren.
Beispielsweise können derartige OEM Phones 100 zur Fernsteuerung eines Fahrzeugs in einer aus fiktionalen Filmen bekannten Weise genutzt werden. Insbesondere können für solche Fernsteuerungen ausgereifte Infotainment-Systeme 200, auch solche von zurückliegenden Entwicklungsgenerationen, verwendet werden.
Derartige OEM Phones 100 können standardisierte und/oder gebräuchliche Schnittstellen und Ports von Steuergeräten nutzen, zum Beispiel Ethernet Switches, Ethernet Switch Debug Ports, Universal Serial Bus (USP) Ports, Schnittstellen zur externen Stromversorgung, Debugschnittstellen für den Anschluss externer Debugging Hardware für die Übertragung von Softwareabbildern oder Schnittstellen für den Anschluss externe Displays oder anderer Anzeigevorrichtungen.
Durch den Einsatz der vorgeschlagenen Software- und Kommunikationsinfrastruktur erzielen Fahrzeughersteller unter anderem folgende Vorteile:

- eine ausgereifte, sichere Entwicklungsumgebung und Werkzeugkette für die Entwicklung von Anwendungen für den Automotive Bereich,
- die Möglichkeit, zurückliegende Generationen von Steuergeräten und/oder Anwendungen für Steuergeräte zu integrieren,
- die Möglichkeit, standardisierte Entwicklungsumgebungen für den Automotive Bereich wie AUTOSAR (Klassisch oder Adaptiv) als stabile und sichere Entwicklungsumgebungen für den Entwurf und die Entwicklung künftiger mobiler Endgeräte zu verwenden,
- standardisierte Entwicklungsumgebungen für den Automotive Bereich wie AUTOSAR (Klassisch oder Adaptiv) stellen bereits sichere Entwicklungs-und Test-Frameworks für die sichere Entwicklung derartiger OEM Phones 100 bereit und umfassen beispielsweise Werkzeuge wie CANoe des Softwareherstellers Vector sowie darauf basierende Frameworks, welche Testsuites für Sicherheitstest, Tests des Netzwerkmanagements oder der Diagnose bereitstellen,
- umfangreiche bestehende Entwürfe von Steuergeräten können in frühen Entwicklungsphasen für ein derartiges OEM Phone 100 vorteilhaft eingesetzt werden, während ein Fahrzeughersteller an der Vereinfachung des Hardwareentwurfs arbeitet,
- ausgehend von bestehenden Entwürfen von Steuergeräten Vereinfachungen vorzunehmen, insbesondere nicht verwendete Ressourcen und Funktionen zu entfernen, um den Größenanforderungen und den thermischen Anforderungen an ein mobiles Endgerät gerecht zu werden.

Ausgehend von einem aus dem Automotive Bereich bekannten Steuergerät und einem aus dem Bereich der Telekommunikation bekannten Smartphone wird ein OEM Phone 100 vorgeschlagen, bei dem eine als VCPU 101 und eine als MCPU 103 ausgebildete virtuelle (von einem Hypervisor 102 überwachte) Recheneinheit physisch auf einer gemeinsamen Leiterplatte angeordnet sind. Zusätzlich oder alternativ können nachfolgend beschriebene Maßnahmen vorgenommen werden, um die Anforderungen an die Hardware- und/oder Softwareressourcen für ein OEM Phone 100 zu reduzieren:

• Gegenüber einem aus dem Automotive Bereich bekannten Steuergerät werden diejenigen Schnittstellen für Signale und/oder Dienste aus der Systemkonfiguration entfernt, welche für die Verwendung als OEM Phone 100 nicht notwendig sind. Beispielsweise kann in einem als ECU Extract (arxml) Dateiformat eine entsprechend reduzierte Beschreibung der Systemkonfiguration erstellt werden.
• Falls auf einem bekannten Steuergerät verfügbare Ressourcen für eine Mehrzahl von Gast-Betriebssystemen in den Virtuellen Maschinen 103 bis 106 nicht ausreichen, kann die Anzahl der Kooperationspartner, mit denen ein Fahrzeughersteller einen Stack von Softwarekomponenten für diese Virtuellen Maschinen 103 bis 106 erstellt, entsprechend den verfügbaren Ressourcen beschränkt werden. Es ist möglich, dass ein Fahrzeughersteller mit nur einem Kooperationspartner an der Entwicklung von Softwarekomponenten für die Virtuellen Maschinen 103 bis 106 arbeitet.
• Die Ressourcenanforderungen der Softwareanwendungen, welche von einem bekannten Steuergerät auf ein OEM Phone 100 transferiert werden sollen, werden beschränkt und/oder reduziert.
• Die Anzahl von Kernen von Mikrocontrollern der VCPU 101 wird reduziert. Der Umfang des Cache-Speichers auf der VCPU 101 wird reduziert. Mindestens eine Taktfrequenz zum Betreiben der VCPU 101 wird reduziert.
• In analoger Weise werden die Anzahl von CPU-Kernen der MCPU 103, der Umfang des Cache-Speichers auf der MCPU 103 und mindestens eine Taktfrequenz zum Betreiben der MCPU 103 reduziert.
• Die Spezifikation des Netzwerkadapters (der Network Interface Card NIC) wird entspannt, beispielsweise hinsichtlich der Datenübertragungsrate reduziert.
• Der der VCPU 101 und/oder der der MCPU 103 zugeordnete Speicher für den wahlfreien Zugriff (Random Access Memory, RAM) wird reduziert.
• In analoger Weise werden weitere der VCPU 101 und/oder der MCPU 103 zugeordnete Speicher, beispielsweise Electrically Erasable Programmable Read Only Memory (EEPROM) oder andere, für eine persistente Datenspeicherung eingerichtete Speicher, im Umfang und/oder in der Spezifikation (beispielsweise hinsichtlich des Datendurchsatzes bei Lesen und/oder Schreiben) reduziert.
• Die mindestens eine Schnittstelle für den Anschluss eines externen Displays oder einer ähnlichen Anzeigevorrichtung wird/werden in ihrer Spezifikation entspannt, beispielsweise in ihrer Anzahl reduziert oder in ihrer Bildfrequenz verringert.
• Die elektrische Leistungsaufnahme der VCPU 101 und/oder der MCPU 103 und/oder weiterer Virtueller Maschinen 104 bis 106 oder Rechenknoten wird bevorzugt so weit reduziert, dass die anfallende thermische Leistung über eine passive Kühlung abgeführt werden kann. Wenn eine passive Kühlung nicht vollständig möglich ist, wird eine aktive Kühlung in dem erforderlichen (entsprechend der verbleibenden, passiv nicht abführbaren thermischen Leistung) ergänzt.
• Anforderungen an Hardware- und/oder Softwarekomponenten, beispielsweise an das Host-Betriebssystem und/oder das mindestens eine Gast-Betriebssystem und/oder den Hypervisor 102 werden so weit reduziert, dass der Formfaktor (die geometrischen Abmessungen) und die Erwärmung des OEM Phones 100 in einer einem üblichen Smartphone entsprechenden Weise ausgestaltet ist.

Zur weiteren Verringerung der technischen Anforderungen (beispielsweise auch zur Verringerung der Leistungsaufnahme, der Abwärme oder der geometrischen Größe) an ein OEM Phone 100 ist es möglich, das Host-Betriebssystem und/oder das mindestens eine Gast-Betriebssystem anzupassen. Beispielsweise können, wenn LINUX, bevorzugt Embedded-LINUX als Betriebssystem verwendet wird, nicht benötigte Softwarekomponenten entfernt werden. Beispielsweise kann ein als Yocto (www.yoctoproject.org) bekannter, für die Anpassung eines LINUX / Embedded LINUX Betriebssystems an variable Hardware-Konfigurationen verfügbarer Software-Stack reduziert oder vollständig entfernt werden. Dadurch kann eine sicherere und Ressourcen sparende Konfiguration eines Betriebssystems erreicht werden. Beispielsweise ist es möglich, ein Display mit einer besonders einfachen, minimalistischen und sicheren Benutzerschnittstelle zu betreiben.
Ferner kann die Verbindung zwischen dem OEM Phone 100 und dem Infotainment-System 200 und/oder einem Fahrzeugnetzwerk 300, 301 auf der physischen Ebene (Schichten 1 und 2 des ISO/OSI Referenzmodells) über kabelgebundenes Ethernet hergestellt sein. Dadurch können übertragene Daten gegen Mithören durch unberechtigte Dritte und gegen Manipulationen geschützt werden.
OBD II wird in Werkstätten eingesetzt, um Diagnosegeräte mit einem Fahrzeugnetzwerk 300, 301 des diagnostizierten Fahrzeugs zu verbinden und so ein derartiges Diagnosegerät (welches als Steuergerät betrachtet werden kann) nahtlos in die Topologie der Fahrzeugsteuergeräte 400 des Fahrzeugs zu integrieren. Aufbauend auf und in Erweiterung zu der OBD II-Erfahrung der nahtlosen Integration externer Steuergeräte (wie beispielsweise derartiger Diagnosegeräte) in die Steuergeräte-Topologie des Fahrzeugs wird eine ähnliche Art von Konnektivität geschaffen, die eine sichere Schnittstelle zu den Bedienelementen und den Funktionen des Fahrzeugs bereitstellt, um alle Aktuatoren, Sensoren und andere Fahrzeugsteuergeräte 400 in einem Fahrzeug zu steuern und/oder auszulesen, die ein höheres Maß an Zuverlässigkeit und Sicherheit aufweisen. Eine solche Konnektivität kann optional indirekt über ein dediziertes Fahrzeugnetzwerk, das zusätzlich zu den in 4 dargestellten Fahrzeugnetzwerken 300, 301 bereitgestellt wird, hergestellt werden.
Die Details der Hardware- und Softwarearchitektur und des Softwareentwurfs für ein Steuergerät können unterhalb einer standardisierten virtuellen Anwendungsschicht verborgen werden. Dadurch wird verhindert, dass schützenswerte Informationen über einen proprietären Entwurf eines Steuergeräts eines Fahrzeugherstellers preisgegeben werden müssen.
Bezugszeichenliste

100: Infotainment-Steuergerät, OEM Phone
101: Fahrzeug-Zentralverarbeitungseinheit, Vehicle Central Processing Unit VCPU
102: Hypervisor
103 bis 106: erste bis vierte Virtuelle Maschine (VM)
103: minimale Central Processing Unit (MCPU)
104 bis 106: Anwendungs-VM
107: VCPU Hypervisor
110: sichere App
111: sicheres Display
112: Gateway Validator
120: generische App
121: generisches Display
122: generische Schnittstellen-App
123: generischer App-Stack
124: validierte App, Schließ-App
125: Kommunikationsverbindung
126: optionale Kommunikationsverbindung
200: Infotainment-System
210: Steueranwendung
220: generische Anwendung
300: Fahrzeugnetzwerk
301: sicheres Fahrzeugnetzwerk
400: Fahrzeugsteuergerät

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2018/0307515 A1 [0007]

Claims

Portable Infotainment-Steuereinheit (100), die zur Verbindung mit mindestens einem Infotainment-System (200) und/oder einem Fahrzeugsteuergerät (400) eines Fahrzeugs über mindestens ein Fahrzeugnetzwerk (300, 301) und zur Ansteuerung mindestens einer Infotainment- und/oder Fahrzeugfunktion eingerichtet ist, dadurch gekennzeichnet, dass die Infotainment-Steuereinheit (100) mindestens ein Display (111, 121) und eine Verarbeitungseinheit mit einem Host-Betriebssystem umfasst, das mindestens einen Hypervisor (102) und eine erste, als minimale Zentralverarbeitungseinheit (minimal Central Processing Unit, MCPU) (103) ausgebildete Virtuelle Maschine (VM) sowie mindestens eine weitere, als Anwendungs-VM (104 bis 106) ausgebildete Virtuelle Maschine bereitstellt, welche von dem Hypervisor (102) überwacht und in voneinander isolierten Laufzeitumgebungen betrieben werden, wobei - die MCPU (103) unter einem sicheren Gast-Betriebssystem eine Adaptive Automotive Open System Architecture (AUTOSAR) Software-Umgebung bereitstellt und einen Gateway Validator (112) umfasst und zur Ansteuerung eines sicheren Displays (111) sowie zur Datenübertragung mit mindestens einem Fahrzeugnetzwerk (300, 301) eingerichtet ist, - die mindestens eine Anwendungs-VM (104 bis 106) mindestens eine zur Ansteuerung eines generischen Displays (121) eingerichtete generische Schnittstellen-App (122), einen generischen App-Stack (123) und mindestens eine validierte App (124) umfasst und wobei - der Gateway Validator (112) zur sicheren Kommunikation der mindestens einen validierten App (124) mit der Adaptiven AUTOSAR Umgebung eingerichtet ist.
Portable Infotainment-Steuereinheit (100) nach Anspruch 1, dadurch gekennzeichnet, dass unter dem Host-Betriebssystem in einer von den Virtuellen Maschinen (103 bis 106) und dem Hypervisor (102) isolierten Laufzeitumgebung eine Fahrzeug-Zentralverarbeitungseinheit (Vehicle Central Processing Unit, VCPU) (101) mit einer Klassischen AUTOSAR Software-Umgebung und mindestens einer sicheren App (110) bereitgestellt ist, wobei die VCPU (101) zur Datenübertragung mit der MCPU (103) und mit mindestens einem Fahrzeugnetzwerk (300, 301) eingerichtet ist.
Portable Infotainment-Steuereinheit (100) nach Anspruch 2, dadurch gekennzeichnet, dass eine Mehrzahl von VCPUs (101) und ein VCPU Hypervisor (107) zu deren Überwachung bereitgestellt sind.
Portable Infotainment- Steuereinheit (100) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Infotainment- Steuereinheit (100) mindestens ein zur Einbuchung in mindestens ein Mobilfunknetz eingerichtetes Subscriber Identity Module (SIM) und/oder mindestens einen zur Verbindung mit einem Datennetz eingerichteten Netzwerkadapter (Network Interface Card) umfasst.
Portable Infotainment- Steuereinheit (100) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens ein Fahrzeugnetzwerk (300, 301) als sicheres Fahrzeugnetzwerk (301) ausgebildet ist und die Infotainment- Steuereinheit (100) mindestens ein auf ein Fahrzeug bezogenes kryptographisches Zertifikat zur qualifizierten Datenübertragung auf dem sicheren Fahrzeugnetzwerk (301) umfasst.
Portable Infotainment- Steuereinheit (100) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eine sichere und/oder generische App (110, 120) als Software-Container bereitgestellt und von den übrigen Apps (110, 120) derselben VM (103 bis 106) isoliert ist.
Portable Infotainment- Steuereinheit (100) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eine generische Schnittstellen-App (122) für den Bezug und/oder die Aktualisierung von Softwarekomponenten über einen App Store eingerichtet ist.
Portable Infotainment- Steuereinheit (100) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Infotainment- Steuereinheit (100) zur Fernsteuerung der Bewegung des Fahrzeugs eingerichtet ist.
Portable Infotainment- Steuereinheit (100) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Infotainment- Steuereinheit (100) in der Art eines elektronischen Fahrzeugschlüssels für die Entriegelung und/oder Verriegelung mindestens einer Fahrzeugtür und/oder für das Starten/Stoppen eines Antriebsmotors des Fahrzeugs eingerichtet ist.
Portable Infotainment- Steuereinheit (100) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens ein generischer App-Stack (123) zur Ausführung generischer Smartphone-Funktionen eingerichtet ist.