DE102015214382A1

DE102015214382A1 - Verfahren und Vorrichtung zum Aktualisieren eines Steuergerätes mit einem Bootmanager, einem Hypervisor und mindestens einem unter dem Hypervisor betriebenen Gastsystem

Info

Publication number: DE102015214382A1
Application number: DE102015214382.1A
Authority: DE
Inventors: Gunnar Piel; Ingo Ehlert
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

Abstract

Verfahren (10) zum Aktualisieren eines Steuergerätes mit einem Bootmanager (14), einem Hypervisor und mindestens einem unter dem Hypervisor betriebenen Gastsystem, gekennzeichnet durch folgende Merkmale: – der Hypervisor betreibt (26) das Gastsystem unter einer individuellen Diagnoseadresse, – das Gastsystem empfängt (28) unter der Diagnoseadresse mittels einer Kommunikationsinfrastruktur eine Aktualisierungsaufforderung (32), – das Gastsystem leitet einen Neustart des Steuergerätes ein, – nach dem Neustart wird der Bootmanager (14) ausgeführt, – der Bootmanager (14) aktualisiert (36) auf die Aktualisierungsaufforderung (34) wahlweise das Gastsystem oder den Hypervisor und – der Bootmanager (14) leitet einen Neustart ein.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Aktualisieren eines Steuergerätes mit einem Bootmanager, einem Hypervisor und mindestens einem unter dem Hypervisor betriebenen Gastsystem. 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.
WO 2005004160 A2 betrifft ein Verfahren zur Durchführung eines Software-Updates eines Steuergerätes durch eine Flash-Programmierung eines mehrere Segmente aufweisende Flash-Speichers des Steuergerätes über eine serielle Schnittstelle, wobei an die Flash-Programmierung zu stellende Anforderung festgelegt, ein Ablauf der Flash-Programmierung durch ein Zustände und Übergänge der Software definierenden Zustandsautomaten spezifiziert und Verfügbarkeits-, Sicherheits- und Zuverlässigkeitsanforderungen eines jeden Zustands und eines jeden Übergangs des Zustandsautomaten überprüft werden.
Offenbarung der Erfindung
Die Erfindung stellt ein Verfahren zum Aktualisieren eines Steuergerätes mit einem Bootmanager, einem Hypervisor und mindestens einem unter dem Hypervisor betriebenen Gastsystem, 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.
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 während des Ausführens des Bootmanagers das Steuergerät dem Bootmanager untersteht und der Hypervisor inaktiv ist. Der Bootmanager wird somit in die Lage versetzt, Aktualisierungen sämtlicher Gastsysteme sowie des Hypervisors zu verarbeiten. Soll ein Update durchgeführt werden, kann der Bootmanager hierzu beispielsweise einen Bootloader starten. Falls kein Update angefordert wurde, wird er den Hypervisor und der dann die Gäste starten.
Gemäß einem weiteren Aspekt 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 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.
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 Blockdiagramm eines Steuergerätes gemäß einer Ausführungsform der Erfindung sowie exemplarischer Kommunikationspartner dieses Steuergeräts.
2 ein Aktivitätsdiagramm des Steuergeräts.
Ausführungsformen der Erfindung
1 illustriert ein beispielhaftes Szenario 42 im Rahmen der Aktualisierung eines Steuergerätes (electronic control unit, ECU) 12 gemäß einer Ausführungsform. Während ein herkömmliches Steuergerät 44 auf seiner Hardwareplattform 46 lediglich eine Software 48 mit einer einzigen Diagnoseadresse 50 ausführt, betreibt im Falle des virtualisierten Steuergerätes 12 ein Hypervisor (virtual machine monitor, VMM) 16 auf einer gemeinsamen Hardware 52 ein erstes Gastsystem 18 unter einer ersten Diagnoseadresse 22 und ein zweites Gastsystem 20 unter einer zweiten Diagnoseadresse 24. Sowohl das erste Gastsystem 18 als auch das zweite Gastsystem 20 ist somit in der Lage, Diagnosekommunikation zu betreiben. Die erste Diagnoseadresse 22 oder die zweite Diagnoseadresse 24 verkörpert sowohl das unter ihr betriebene Gastsystem 18, 20 als auch den Hypervisor 16. Dieses Gastsystem 18, 20 wird auf einer erhöhten Berechtigungsstufe betrieben.
2 veranschaulicht anhand einer an Version 1 der vereinheitlichten Modellierungssprache (unified modeling language, UML) angelehnten Darstellung die Aktivität des Steuergerätes 12 im Rahmen der Durchführung eines Verfahrens 14 gemäß einer Ausführungsform. Den Ausgangspunkt der erörterten Aktivität bildet die Aktualisierungsaufforderung 32 durch ein externes Gerät wie einen Diagnosetester 54.
Das mit der Aktualisierungsaufforderung 32 adressierte Gastsystem 18, 20 schaltet nun das Steuergerät 12 aus (56), als seien ein Sicherheitsproblem entdeckt (58) oder beide Gastsysteme 18, 20 heruntergefahren (60) worden.
Nach dem Einschalten 62 des Steuergerätes 12 wird zunächst dessen Bootmanager 14 ausgeführt. In der entsprechenden Betriebsart ist der Hypervisor 16 inaktiv, und dem Bootmanager 14 untersteht im Wesentlichen das gesamte Steuergerät 12. Der Bootmanager 14 ist somit im vorliegenden Falle einer anhängigen (64) Aktualisierungsaufforderung 32 in der Lage, in dieser steuergerätübergreifenden Bootmanager-Betriebsart 66 unter der Diagnoseadresse 22, 24 jedes der beiden Gastsysteme 18, 20 zu kommunizieren.
Der Bootmanager empfängt sodann weitere Anweisungen und Kode, um die Aktualisierung 36 im Wege einer Diagnosekommunikation an die Diagnoseadresse 22, 24 des betreffenden Gastsystems 18, 20 durchzuführen. Abhängig von der Aktualisierungsaufforderung 34 betrifft die Aktualisierung 36 dabei wahlweise die – den Bootmanager 14, den Hypervisor 16 und das diesem zugeordnete Gastsystem 18, 20 umfassende – Master-Partition oder die – lediglich den Bootmanager 14 und das nicht dem Hypervisor 16 zugeordnete Gastsystem 18, 20 umfassende – Slave-Partition.
Sobald die Aktualisierung abgeschlossen (68) ist, prüft der Bootmanager 14 die Programmabhängigkeiten 70, speichert das Ergebnis 72 und schaltet das Steuergerät 12 aus (56). Nach dem anschließenden Neustart des Steuergerätes 12 setzt sich die gewöhnliche Bootsequenz fort.
Im Falle inkompatibler oder beschädigter Softwarekomponenten 40 von Hypervisor 16, Gastsystemen 18, 20 oder Bootmanager 14 wird letzterer unmittelbar nach dem Neustart ausgeführt. Das Verfahren 10 wird nun ansonsten unverändert mit dem Empfang der Aktualisierungsaufforderung 34 fortgesetzt. Sind hingegen alle Softwarekomponenten kompatibel und betriebsbereit (74), erfolgt eine Vorinitialisierung 76 des Hypervisors 16. Ist die Initialisierung erledigt (78), schließen sich anfängliche Sicherheitsprüfungen (38) an. Falls eine Prüfung scheitert (80), schaltet der Bootmanager 14 das Steuergerät 12 wieder aus (56).
Sobald sämtliche Prüfungen erfolgreich (82) durchlaufen sind, geht das Steuergerät 12 mit dem Initialisieren 84 des Hypervisors 16 in den Normalbetrieb über.
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

WO 2005004160 A2 [0004]

Claims

Verfahren (10) zum Aktualisieren eines Steuergerätes (12) mit einem Bootmanager (14), einem Hypervisor (16) und mindestens einem unter dem Hypervisor (16) betriebenen Gastsystem (18, 20), gekennzeichnet durch folgende Merkmale: – der Hypervisor (16) betreibt (26) das Gastsystem (18, 20) unter einer individuellen Diagnoseadresse (22, 24), – das Gastsystem (18, 20) empfängt (28) unter der Diagnoseadresse (22, 24) mittels einer Kommunikationsinfrastruktur (30) eine Aktualisierungsaufforderung (32), – das Gastsystem (18, 20) leitet einen Neustart des Steuergerätes (12) ein, – nach dem Neustart wird der Bootmanager (14) ausgeführt, – der Bootmanager (14) aktualisiert (36) auf die Aktualisierungsaufforderung (34) wahlweise das Gastsystem (18, 20) oder den Hypervisor (16) und – der Bootmanager (14) leitet einen Neustart ein.
Verfahren nach Anspruch 1, gekennzeichnet durch folgende Merkmale: – das Gastsystem (18, 20) empfängt die Aktualisierungsaufforderung (34) stellvertretend für den Hypervisor (16), – das Gastsystem (18, 20) wird auf einer erhöhten Berechtigungsstufe betrieben (26) und – der Hypervisor (16) wird aktualisiert.
Verfahren nach Anspruch 1 oder 2, gekennzeichnet durch weitere Sicherheitsmaßnahmen (38) während des Neustarts.
Verfahren nach einem der Ansprüche 1 bis 3, gekennzeichnet durch folgende Merkmale: – während des Ausführens des Bootmanagers (14) untersteht das Steuergerät (12) dem Bootmanager (14) und – während des Ausführens des Bootmanagers (14) ist der Hypervisor (16) inaktiv.
Verfahren nach Anspruch 4, gekennzeichnet durch folgende Merkmale: – vor dem Aktualisieren (36) empfängt der Bootmanager (14) unter der Diagnoseadresse (22, 24) einer Masterpartition des Gesamtsystems (18, 20) mittels der Kommunikationsinfrastruktur (30) weitere Anweisungen und – abhängig von den weiteren Anweisungen wird entweder das Gastsystem (18, 20) oder der Hypervisor (16) aktualisiert (36).
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass der Bootmanager (14) vor dem Aktualisieren (36) unter der Diagnoseadresse (22, 24) einer Masterpartition des Gesamtsystems (18, 20) mittels der Kommunikationsinfrastruktur (30) ferner einen Kode empfängt.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Aktualisierungsaufforderung (34) ferner empfangen wird, falls ein Kompatibilitätsproblem (40) zwischen dem Gastsystem (18, 20) und dem Hypervisor (16) besteht.
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 (12), die eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 7 auszuführen.