DE102015214389A1

DE102015214389A1 - Verfahren und Vorrichtung zum Aktualisieren einer auf einer physischen Maschine unter einem Hypervisor betriebenen virtuellen Maschine

Info

Publication number: DE102015214389A1
Application number: DE102015214389.9A
Authority: DE
Inventors: Gunnar Piel; Gary Morgan
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2015-07-29
Filing date: 2015-07-29
Publication date: 2017-02-02
Also published as: CN106484494A; CN106484494B; US20170031703A1

Abstract

Verfahren (10) zum Aktualisieren einer auf einer physischen Maschine (38) mit einem Direktzugriffsspeicher (12) und einem Festwertspeicher (14) unter einem Hypervisor (16) betriebenen virtuellen Maschine, gekennzeichnet durch folgende Merkmale: – der Hypervisor (16) betreibt die virtuelle Maschine unter einer individuellen Diagnoseadresse, wobei der Festwertspeicher (14) einen Maschinenkode (20) des Hypervisors (16) und der virtuellen Maschine speichert, – die virtuelle Maschine empfängt unter der Diagnoseadresse mittels einer Kommunikationsinfrastruktur (48) eine Aktualisierungsaufforderung (24) von einem externen Gerät (50) und teilt dem Hypervisor (16) die Aktualisierungsaufforderung (24) mit, – der Hypervisor (16) verlegt den Maschinenkode (20) von dem Festwertspeicher (14) in den Direktzugriffsspeicher (12), – der Hypervisor (16) startet (26) die virtuelle Maschine und führt (26) einen Bootmanager (28) der virtuellen Maschine aus, – der Bootmanager (28) empfängt unter der Diagnoseadresse der virtuellen Maschine einen aktuellen Maschinenkode (22) und tauscht den Maschinenkode (20) in dem Festwertspeicher (14) zumindest teilweise gegen den aktuellen Maschinenkode (22) aus und – der Bootmanager (28) startet die virtuelle Maschine neu (30).

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Aktualisieren einer auf einer physischen Maschine mit einem Direktzugriffsspeicher und einem Festwertspeicher unter einem Hypervisor betriebenen virtuellen Maschine. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
Stand der Technik
Bekannte Fahrzeugsteuergeräte verfügen in der Regel über Fähigkeiten zur On-Board-Diagnose. Typischerweise bezieht sich die gelieferte Diagnose dabei auf das Steuergerät selbst, seine Funktionalität und Softwareaktualisierung. Auf diese Fähigkeiten gattungsmäßiger Steuergeräte kann etwa mittels verschiedenster Fahrzeugkommunikationsnetzwerke wie CAN, Flexray oder Ethernet und jeweilige Diagnoseprotokolle wie OBD zugegriffen werden. Um eine Diagnosekommunikationsverbindung zwischen dem Steuergerät und einem externen Diagnosewerkzeug herzustellen, besitzt ein derartiges Steuergerät eine Diagnoseadresse. Bei einem einzigen Softwaresystem innerhalb des Steuergerätes sind die beschriebenen Fähigkeiten als Stand der Technik zu erachten.
In einem virtualisierten Steuergerät jedoch gibt es mehrere Softwaresysteme, sogenannte Gastsysteme, und die zusätzliche Softwarekomponente eines Hypervisors. Als Folge davon werden Diagnosefähigkeiten hinsichtlich Statusinformationen für jedes Gastsystem, die Hardware und den Hypervisor benötigt. Schließlich müssen die Gastsysteme und der Hypervisor aktualisiert werden.
DE 19921845 A1 beschreibt eine Diagnosetestvorrichtung für Kraftfahrzeuge, wobei im Kraftfahrzeug programmierbare Steuergeräte mit Eigendiagnosemittel vorgesehen sind, welche programmgesteuert die Motorsteuerung und andere Systeme des Kraftfahrzeugs steuern, überwachen, Fehlercodes generieren und diese abspeichern, und welche über einen Kraftfahrzeug-seitigen Diagnose-/Prüfstecker mit einem externen Diagnosetester verbindbar sind. Der externe Diagnosetester ist mit einer Programmerkennungs- und Programmladevorrichtung ausgestattet. Mittels der Programmerkennungsvorrichtung wird die im angeschlossenen Steuergerät enthaltene Programmversion abgefragt und erkannt. Dann, wenn das Kraftfahrzeug-seitig vorhandene und über den Diagnose-/Prüfstecker erkannte, im angeschlossenen Steuergerät des Kraftfahrzeugs vorhandene Programm nicht in der neuesten und aktuellsten Version abgespeichert ist, wird von der Programmladevorrichtung des Diagnosetesters die jeweils aktuellste Version in den Programmspeicher des entsprechenden Steuergerätes geladen.
Offenbarung der Erfindung
Die Erfindung stellt ein Verfahren zum Aktualisieren einer auf einer physischen Maschine mit einem Direktzugriffsspeicher und einem Festwertspeicher unter einem Hypervisor betriebenen virtuellen Maschine, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
Die vorgeschlagene Lösung fußt auf der Erkenntnis, dass ein virtualisiertes System mehr aktualisierbare Komponenten aufweist als ein einzelnes Softwaresystem. Hier sind es mehrere Gastsysteme und der Hypervisor selbst, welche voneinander unabhängiger Aktualisierungen bedürfen.
Ein Vorzug dieser Lösung liegt in der Beibehaltung bestehender, auf Diagnosekommunikation und -adresse sowie Bootmanager basierender Abläufe. So behält jedes Gastsystem seine eigene Diagnoseadresse und ist in der Lage, Diagnosekommunikation zu verarbeiten. Die Kommunikationsinfrastruktur lässt sich entweder zwischen mehreren Gastsystemen teilen oder ausschließlich einem Gastsystem vorbehalten.
Besonders vorteilhaft ist dabei die Fähigkeit bestimmter Ausführungsformen der Erfindung, eine im Betrieb befindliche Produktivumgebung zu aktualisieren. Dies bedeutet, dass Hypervisor und virtuelle Maschinen mitsamt der von ihnen ausgeführten Anwendungsprogramme normal weiterbetrieben werden können, während eine virtuelle Maschine oder der Hypervisor daselbst aktualisiert werden.
Der vorgestellte Ansatz trägt dabei dem Umstand Rechnung, dass die meisten Steuergeräte – zu denken ist in der Kraftfahrzeugtechnik etwa an Motor- und Karosseriesteuerung oder Fahrdynamikregelung – ihren Maschinenkode unmittelbar aus internem Flash-Speicher ausführen. Während der bei derartigen Geräten im Rahmen der Aktualisierung durchgeführten Flash-Neuprogrammierung wird durch die Anwendung des hier diskutierten Verfahrens ermöglicht, dass Applikationscode während der Neuprogrammierung ausgeführt werden kann. Dies erweist sich insofern als zweckdienlich, da eine gleichzeitige Kodeausführung bei einer konventionellen Herangehensweise kaum möglich ist.
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass das Gastsystem auf einer erhöhten Berechtigungsstufe betrieben wird und die Aktualisierungsaufforderung stellvertretend für den Hypervisor empfängt, welcher schließlich durch den Bootmanager oder einen durch diesen gestarteten Bootloader aktualisiert wird. Für Zwecke der Aktualisierung wird der Hypervisor somit gleichsam einem Gastsystem zugeordnet. Auf diese Weise kann er gemeinsam mit diesem bestimmten Gastsystem aktualisiert werden.
Gemäß einer Variante kann vorgesehen sein, dass das Gastsystem selbst ein mögliches Update feststellt und dieses auslöst. Eine entsprechende Ausführungsform erweist sich als weitgehend unabhängig von einem jedwedem Diagnosewerkzeug.
Kurze Beschreibung der Zeichnungen
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
1 das Datenflussdiagramm eines Verfahrens gemäß einer Ausführungsform.
2 schematisch das Blockdiagramm eines Steuergerätes gemäß einer zweiten Ausführungsform mitsamt möglicher Kommunikationspartner und Infrastruktur.
Ausführungsformen der Erfindung
1 fasst den grundsätzlichen Ablauf des vorgeschlagenen Verfahrens 10 zum Aktualisieren einer auf einer physischen Maschine 38 mit einem Direktzugriffsspeicher 12 und einem Festwertspeicher 14 unter einem Hypervisor 16 betriebenen virtuellen Maschine 18 in einem Datenflussdiagramm gemäß der Yourdon/DeMarco-Notation zusammen. Der Hypervisor 16 betreibt die virtuelle Maschine 18 unter einer individuellen Diagnoseadresse, wobei der Festwertspeicher 14 einen Maschinenkode 20 des Hypervisors 16 und der virtuellen Maschine 18 speichert. Die virtuelle Maschine 18 empfängt unter der Diagnoseadresse mittels einer Kommunikationsinfrastruktur 48 eine Aktualisierungsaufforderung 24 von einem externen Gerät 50 und teilt dem Hypervisor 16 die Aktualisierungsaufforderung 24 mit. Der Hypervisor 16 verlegt den Maschinenkode 20 von dem Festwertspeicher 14 in den Direktzugriffsspeicher 12, startet die virtuelle Maschine und führt einen Bootmanager 28 der virtuellen Maschine 18 aus (26). Der Bootmanager 28 empfängt unter der Diagnoseadresse der virtuellen Maschine 18 einen aktuellen Maschinenkode 22 und tauscht den Maschinenkode 20 in dem Festwertspeicher 14 zumindest teilweise gegen den aktuellen Maschinenkode 20 aus. Der Bootmanager 28 startet schließlich die virtuelle Maschine 18 neu (30).
2 illustriert ein detaillierteres Szenario im Rahmen der Aktualisierung eines Steuergerätes (electronic control unit, ECU), ohne dass dessen Gastsysteme außer Betrieb genommen werden.
Während ein herkömmliches Steuergerät 52 auf seiner Hardwareplattform 42 lediglich eine Software 44 mit einer einzigen Diagnoseadresse A ausführt, betreibt im Falle des virtualisierten Steuergerätes 40 ein Hypervisor 16 (virtual machine monitor, VMM) auf einer gemeinsamen physischen Maschine 38 eine erste virtuelle Maschine 18 unter der Diagnoseadresse B und eine zweite virtuelle Maschine 32 unter der Diagnoseadresse C. Sowohl die erste virtuelle Maschine 18 als auch die zweite virtuelle Maschine 32 sind somit in der Lage, Diagnosekommunikation zu betreiben. Die Diagnoseadresse B oder die Diagnoseadresse C verkörpert sowohl die unter ihr betriebene virtuelle Maschine 18, 32 als auch den Hypervisor 16 selbst.
Von einem externen Gerät 50, beispielsweise einem Diagnosetester, geht eine diagnostische Aktualisierungsaufforderung 24 unter der Diagnoseadresse B ein. Die betreffende erste virtuelle Maschine 18 teilt dies dem Hypervisor 16 mit.
Die adressierte erste virtuelle Maschine 18 fordert beim Hypervisor 16 Übertragung und Ausführung des Maschinenkodes 20 von Hypervisor 16 und erster virtueller Maschine 18 aus dem Direktzugriffsspeicher 12 (random-access memory, RAM) an. Wenn die Konfiguration des Hypervisors 16 dies erlaubt, überträgt der Hypervisor 16 einschlägigen Maschinenkode 20 in den Direktzugriffsspeicher 12 und führt 26 die Ausführung von dort aus fort. Die erste virtuelle Maschine 18 und zweite virtuelle Maschine 32 können dabei im Regelfall nur innerhalb der Bereichsgrenzen 36 ihrer zugewiesenen Ressourcen wie Speicherplatz, Geräte und Anzahl von Prozessorkernen aktualisiert werden.
Wenn Bereichsgrenzen 36 angepasst werden sollen, ist daher zunächst der Hypervisor 16 zu aktualisieren.
Die erste virtuelle Maschine 18 startet nun neu und führt einen Bootmanager 28 (bootstrap loader, bootloader) aus dem Direktzugriffsspeicher 12 aus. Der Bootmanager 28 ist unter der Diagnoseadresse B der ersten virtuellen Maschine 18 erreichbar.
Der Bootmanager 28 empfängt sodann weitere Anweisungen und aktuellen Maschinenkode 22, um die Aktualisierung im Wege einer Diagnosekommunikation an die Diagnoseadresse B der betreffenden ersten virtuellen Maschine 18 durchzuführen. Abhängig von der Aktualisierungsaufforderung 24 aktualisiert der Bootmanager 28 wahlweise die erste virtuelle Maschine 18 oder den Hypervisor 16.
Der Bootmanager 28 startet schließlich die erste virtuelle Maschine 18 neu (26). Die gewöhnliche Bootsequenz setzt sich nun fort und startet die erste virtuelle Maschine 18 neu (30). Falls der Hypervisor 16 aktualisiert wurde, fordert die erste virtuelle Maschine 18 einen vollständigen Systemneustart beim Hypervisor 16 an. In jedem Fall wird neue Funktionalität erst nach entweder dem Neustart des Hypervisors 16 oder des Systems aktiv.
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

DE 19921845 A1 [0004]

Claims

Verfahren (10) zum Aktualisieren einer auf einer physischen Maschine (38) mit einem Direktzugriffsspeicher (12) und einem Festwertspeicher (14) unter einem Hypervisor (16) betriebenen virtuellen Maschine (18), gekennzeichnet durch folgende Merkmale: – der Hypervisor (16) betreibt die virtuelle Maschine (18) unter einer individuellen Diagnoseadresse, wobei der Festwertspeicher (14) einen Maschinenkode (20) des Hypervisors (16) und der virtuellen Maschine (18) speichert, – die virtuelle Maschine (18) empfängt unter der Diagnoseadresse mittels einer Kommunikationsinfrastruktur (48) eine Aktualisierungsaufforderung (24) von einem externen Gerät (50) und teilt dem Hypervisor (16) die Aktualisierungsaufforderung (24) mit, – der Hypervisor (16) verlegt den Maschinenkode (20) von dem Festwertspeicher (14) in den Direktzugriffsspeicher (12), – der Hypervisor (16) startet die virtuelle Maschine (18) und führt einen Bootmanager (28) der virtuellen Maschine (18) aus (26), – der Bootmanager (28) empfängt unter der Diagnoseadresse der virtuellen Maschine (18) einen aktuellen Maschinenkode (22) und tauscht den Maschinenkode (20) in dem Festwertspeicher (14) zumindest teilweise gegen den aktuellen Maschinenkode (22) aus und – der Bootmanager (28) startet die virtuelle Maschine neu (30).
Verfahren (10) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: – die virtuelle Maschine (18) empfängt die Aktualisierungsaufforderung (24) stellvertretend für den Hypervisor (16), – die virtuelle Maschine (18) wird auf einer erhöhten Berechtigungsstufe betrieben und – der Maschinenkode (20) wird solchermaßen ausgetauscht, dass wahlweise die virtuelle Maschine (18) oder der Hypervisor (16) aktualisiert wird.
Verfahren (10) nach Anspruch 2, gekennzeichnet durch folgende Merkmale: – vor dem Aktualisieren empfängt der Bootmanager (28) unter der Diagnoseadresse der virtuellen Maschine (18) mittels der Kommunikationsinfrastruktur (48) weitere Anweisungen und – abhängig von den weiteren Anweisungen wird der Maschinenkode (20) solchermaßen ausgetauscht, dass entweder die virtuelle Maschine (18), der Hypervisor (16) oder die virtuelle Maschine und der Hypervisor (16) aktualisiert werden.
Verfahren (10) nach Anspruch 3, dadurch gekennzeichnet, dass zunächst der Hypervisor (16) und anschließend die virtuelle Maschine (18) solchermaßen aktualisiert werden, dass durch den Hypervisor (16) überwachte Bereichsgrenzen (36) der virtuellen Maschine (18) verlegt werden.
Verfahren (10) nach Anspruch 4, dadurch gekennzeichnet, dass die Bereichsgrenzen (36) mindestens eines der folgenden Betriebsmittel der physischen Maschine (38) eingrenzen: – den Direktzugriffsspeicher (12), – Peripheriegeräte oder – Prozessorkerne.
Verfahren (10) nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass der Bootmanager (28) vor dem Neustarten der virtuellen Maschine (18) den Hypervisor (16) neu startet (26), falls der Hypervisor (16) aktualisiert worden ist.
Verfahren (10) nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der Festwertspeicher (14) ein elektrisch löschbarer programmierbarer Festwertspeicher (14), insbesondere ein Flash-Speicher ist.
Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.
Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 8 gespeichert ist.
Vorrichtung (40), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.