DE102022108288A1

DE102022108288A1 - Ota-master, aktualisierungssteuerungsverfahren und nicht-transitorisches speichermedium

Info

Publication number: DE102022108288A1
Application number: DE102022108288.1A
Authority: DE
Inventors: Shoichi NAGAMITSU
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2021-05-13
Filing date: 2022-04-06
Publication date: 2022-11-17
Also published as: US20220365766A1; CN115344279A; JP2022175460A

Abstract

Ein Over-the-Air (OTA)-Master, der eingerichtet ist, um eine oder mehrere Software(s) auf einer fahrzeuginternen Vorrichtung zu aktualisieren, weist einen oder mehrere Prozessoren (49) auf. Der OTA-Master ist eingerichtet, um eine Verbindung zu einem fahrzeuginternen Netzwerk, zu dem die fahrzeuginterne Vorrichtung gehört, herzustellen und über ein Netzwerk mit einem OTA-Center zu kommunizieren. Der eine oder die mehreren Prozessoren (49) sind eingerichtet, um aus Softwaregruppen, die jeweils aus einer Kombination der Software des fahrzeuginternen Geräts bestehen, Konfigurationsinformation(en) über die Softwaregruppe, in der eine Änderung in einer Konfiguration der Kombination der Software aufgetreten ist, zu erfassen. Der eine oder die mehreren Prozessoren (49) sind eingerichtet, um die erfasste(n) Konfigurationsinformation(en) an das OTA-Center zu senden.

Description

Hintergrund der Erfindung
Technisches Gebiet
Die vorliegende Offenbarung bezieht sich auf Over-the-Air (OTA)-Masters, Aktualisierungssteuerungsverfahren und nicht-transitorische Speichermedien zur Aktualisierung von Software auf einer fahrzeuginternen Vorrichtung.
Stand der Technik
Fahrzeuge sind mit einer Vielzahl von (elektronischen) Steuereinheiten („ECUs“) zur Durchführung von Steuerfunktionen ausgestattet. Jede (elektronische) Steuereinheit / ECU weist einen Prozessor und eine Speichereinheit auf. Die Steuerfunktionen jeder Steuereinheit werden durch den Prozessor, der in der Speichereinheit gespeicherte Software ausführt, implementiert. Die in jeder Steuereinheit gespeicherte Software kann aktualisiert werden. Insbesondere kann die Software in einer Wartungswerkstatt usw. durch Verwendung von externem Gerät, das über einen in dem Fahrzeug vorgesehenen Diagnosestecker angeschlossen ist, aktualisiert werden. Kommunikationsgerät, das in einem fahrzeuginternen Netzwerk und einem Kommunikationsnetzwerk wie dem Internet bereitgestellt ist, kann drahtlos verbunden werden, um die Software mit Software, die von einem in einem Aktualisierungs-Center bereitgestellten Verteilerserver über drahtlose Kommunikation heruntergeladen worden ist, zu aktualisieren (z. B. japanische Patentanmeldung JP 2020 - 004 245 A ). Dieser Aktualisierungsdienst über drahtlose Kommunikation wird als „OTA-Dienst“ bezeichnet.
Zusammenfassung der Erfindung
Bei dem Aktualisierungsverfahren in dem OTA-Dienst werden Daten über alle Steuereinheiten, die in einem vorbestimmten Fahrzeug installiert sind, von dem Fahrzeug an das Center gesendet, um die aktuelle Softwarekonfiguration des Fahrzeugs zu erfassen, bevor die Aktualisierung (bzw. das Update) für das Fahrzeug gestartet wird. Das Center entscheidet über die Erforderlichkeit der Aktualisierung, etc. basierend auf den Daten.
In den letzten Jahren jedoch ist die Zahl der in Fahrzeugen enthaltenen Steuereinheiten ständig angestiegen, zusammen mit der Zunahme der Zahl der Funktionen in den Fahrzeugen. Zum Beispiel kann die Anzahl der in den Fahrzeugen installierten Steuereinheiten so viel wie etwa 50 betragen. Daher steigt der Umfang der Datenkommunikation, wenn Daten über alle die Steuereinheiten jedes Mal an das Center gesendet werden. Außerdem ist die Belastung des Centers durch das Prüfverfahren nicht gering.
Die vorliegende Offenbarung stellt einen OTA-Master, ein Aktualisierungssteuerungsverfahren und ein nicht-transitorisches Speichermedium bereit, die in der Lage sind, Steuereinheit-Software zu aktualisieren, ohne Daten an alle in einem Fahrzeug installierten Steuereinheiten zu senden.
In einem ersten Aspekt einer Technik der vorliegenden Offenbarung weist ein Over-the-Air (OTA-Master), der eingerichtet ist, um eine oder mehrere Software(s) auf einer fahrzeuginternen Vorrichtung zu aktualisieren, eine Konfigurationsinformationserfassungseinheit und eine Übertragungseinheit auf. Der OTA-Master ist eingerichtet, um eine Verbindung zu einem fahrzeuginternen Netzwerk, das die fahrzeuginterne Vorrichtung aufweist, herzustellen und über ein Netzwerk mit einem OTA-Center zu kommunizieren. Die Konfigurationsinformationserfassungseinheit ist eingerichtet, um aus Softwaregruppen, die jeweils aus einer Kombination der Software der fahrzeuginternen Vorrichtung bestehen, Konfigurationsinformation(en) über eine Softwaregruppe, in der eine Änderung in einer Konfiguration der Kombination der Software aufgetreten ist, zu erfassen. Die Übertragungseinheit ist eingerichtet, um die erfasste(n) Konfigurationsinformation(en) an das OTA-Center senden.
In dem OTA-Master gemäß dem ersten Aspekt der Technik der vorliegenden Offenbarung kann die Konfigurationsinformationserfassungseinheit eingerichtet sein, um zu bestimmen, ob die Änderung in der Konfiguration der Kombination der Software vor und nach einem vorbestimmten Zeitpunkt aufgetreten ist. Die Konfigurationsinformationserfassungseinheit kann eingerichtet sein, um, wenn die Änderung aufgetreten ist, die Konfigurationsinformation(en) über die Softwaregruppe, in der die Änderung aufgetreten ist, zu erfassen.
Der OTA-Master gemäß dem ersten Aspekt der Technik der vorliegenden Offenbarung kann ferner eine Center-Befehl-Empfangseinheit aufweisen, wobei die Center-Befehl-Empfangseinheit eingerichtet ist, um von dem OTA-Center einen Center-Befehl, der einen Befehl, Konfigurationsinformation(en) über eine vorbestimmte Softwaregruppe zu senden, aufweist/enthält, zu empfangen. Die Konfigurationsinformationserfassungseinheit kann eingerichtet sein, um, wenn die Center-Befehl-Empfangseinheit den Center-Befehl empfangen hat, die Konfigurationsinformation(en) über die Softwaregruppe, in der die Änderung in der Konfiguration der Kombination der Software aufgetreten ist, zu erfassen.
In dem OTA-Master gemäß dem ersten Aspekt der Technik der vorliegenden Offenbarung kann der Center-Befehl einen Befehl, die Konfigurationsinformation(en) über die Softwaregruppe, in der die Änderung in der Konfiguration der Kombination der Software aufgetreten ist, zu senden, aufweisen/enthalten.
In einem zweiten Aspekt der Technik der vorliegenden Offenbarung wird ein Aktualisierungssteuerungsverfahren von einem Computer eines OTA-Masters, der eingerichtet ist, um mit einem OTA-Center über ein Netzwerk zu kommunizieren, durchgeführt. Der OTA-Master weist einen oder mehrere Prozessor(en) und einen Speicher auf. Das Aktualisierungssteuerungsverfahren umfasst: Erfassen von Konfigurationsinformation(en) über eine Softwaregruppe, in der eine Änderung in einer Konfiguration der Kombination der Software aufgetreten ist, aus Softwaregruppen, die jeweils aus einer Kombination von Software einer fahrzeuginternen Vorrichtung bestehen; und Senden der erfassten Konfigurationsinformation(en) an das OTA-Center.
In einem dritten Aspekt der Technik der vorliegenden Offenbarung speichert ein nicht-transitorisches Speichermedium Befehle, die von einem oder mehreren Computern eines OTA-Masters ausgeführt werden können und die den einen oder die mehreren Computer veranlassen, Funktionen auszuführen. Der OTA-Master weist einen oder mehrere Prozessor(en) und einen Speicher auf. Der OTA-Master ist eingerichtet, um mit einem OTA-Center über ein Netzwerk zu kommunizieren. Die Funktionen enthalten: Erfassen von Konfigurationsinformation(en) über eine Softwaregruppe, in der eine Änderung in einer Konfiguration der Kombination der Software aufgetreten ist, aus Softwaregruppen, die jeweils aus einer Kombination von Software einer fahrzeuginternen Vorrichtung bestehen; und Senden der erfassten Konfigurationsinformation(en) an das OTA-Center.
Gemäß dem OTA-Master, dem Aktualisierungssteuerungsverfahren und dem nicht-transitorischen Speichermedium der vorliegenden Offenbarung kann der Umfang der Datenkommunikation in dem Aktualisierungsverfahren reduziert werden, und kann die für einen Abschluss der Aktualisierung (bzw. des Updates) erforderliche Zeit verringert werden.
Figurenliste
Merkmale, Vorteile sowie technische und industrielle Bedeutung von beispielhaften Ausführungsformen der Erfindung werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen gleiche Zeichen gleiche Elemente bezeichnen und in denen:

1 ein Blockdiagramm, das eine Gesamtkonfiguration eines Systems gemäß einer Ausführungsform veranschaulicht, ist;
2 ein Blockdiagramm, das eine schematische Konfiguration eines Centers 1 veranschaulicht, ist;
3 ein Blockdiagramm, das eine schematische Konfiguration eines OTA-Masters 31 veranschaulicht, ist;
4 ein Funktionsblockdiagramm des Centers 1 ist;
5 ein Funktionsblockdiagramm des OTA-Masters 31 ist;
6 einen Speicherplan, der ein Beispiel für die in einer Speichereinheit 16 des Centers 1 gespeicherten Daten zeigt, veranschaulicht;
7 ein Beispiel für eine Datenkonfiguration einer Software-ID (SWID)-Datenbank 102 veranschaulicht;
8 ein Beispiel für eine Datenkonfiguration einer Fahrzeugdatenbank 103 veranschaulicht;
9 einen Speicherplan, der ein Beispiel für die in einer Speichereinheit 47 des OTA-Masters 31 gespeicherten Daten zeigt, veranschaulicht;
10 ein Beispiel für eine Datenkonfiguration von installierten Software-ID (SWID)-Definitionsdaten 152 veranschaulicht;
11 ein Beispiel für die Datenkonfiguration eines Prüf-Software-ID (SWID)-Hashwerts 153 veranschaulicht;
12 ein Flussdiagramm, das Details eines Verfahrens gemäß einer ersten Ausführungsform veranschaulicht, ist;
13 ein Flussdiagramm, das Details des Verfahrens gemäß der ersten Ausführungsform veranschaulicht, ist;
14 einen Speicherplan, der ein Beispiel für in der Speichereinheit 47 des OTA-Masters 31 gespeicherte Daten in einer zweiten Ausführungsform zeigt, veranschaulicht;
15 ein Flussdiagramm, das Details eines Verfahrens gemäß der zweiten Ausführungsform veranschaulicht, ist; und
16 ein Flussdiagramm, das Details eines Verfahrens gemäß einer dritten Ausführungsform veranschaulicht, ist.

Detaillierte Beschreibung der Ausführungsformen
Eine Ausführungsform einer Technik der vorliegenden Offenbarung wird unter Bezugnahme auf die Zeichnungen im Einzelnen beschrieben.
Bei der Durchführung eines Aktualisierungsverfahrens einer Aktualisierung von Software einer fahrzeuginternen (elektronischen) Steuereinheit/ECU (im Folgenden als „Steuereinheit/ECU-Software“ bezeichnet) in einem Over-the-Air (OTA)-Dienst werden Daten über alle in einem Fahrzeug installierten Steuereinheit-Software-Teile (bzw. - Stücke) an ein OTA-Center (im Folgenden einfach als „Center“ bezeichnet) gesendet. Insbesondere werden Seriennummern von allen der Steuereinheit-Software-Teile (jedes Software-Teil identifizierende Nummern) und ein Hashwert basierend auf den Versionen der Software-Teile (im Folgenden als „Gesamthashwert“ bezeichnet) erzeugt und an das Center gesendet. In der vorliegenden Ausführungsform wird/werden hingegen Konfigurationsinformation(en) über einen Teil (bzw. Part) von Steuereinheit-Software-Teilen anstatt über alle die Steuereinheit-Software-Teile, insbesondere ein Hashwert des Teils der Steuereinheit-Software-Teile, erzeugt und an das Center gesendet. Die Erforderlichkeit eines Aktualisierungsverfahrens für ein vorbestimmtes Steuereinheit-Software-Teil wird basierend auf diesem Hashwert bestimmt. Das Aktualisierungsverfahren wird durchgeführt, wenn das Aktualisierungsverfahren als erforderlich bestimmt wird. In der vorliegenden Ausführungsform kann die für den Abschluss des Aktualisierungsverfahrens erforderliche Zeit bei gleichzeitiger Verringerung des Kommunikationsaufwands im Vergleich zur Verwendung des Gesamthashwerts reduziert werden. Insbesondere wird der Hashwert eines Teils (bzw. Parts) der Steuereinheit-Software-Teile (bzw. -Stücke) erzeugt und unter Verwendung einer „Software-Identifikation (ID)“ gesendet, und wird die Erforderlichkeit des Aktualisierungsverfahrens bestimmt.
Die Software-ID (im Folgenden SWID genannt) wird beschrieben. Die SWID zeigt eine Gruppe von Steuereinheit-Software-Teilen an, die durch eine vorbestimmte Funktion, die durch eine Kombination von Funktionen einer Vielzahl von Steuereinheiten/ECUs implementiert ist/wird, gruppiert ist. Mit anderen Worten, die SWID zeigt die Softwarekonfiguration zur Implementierung einer bestimmten Funktion an. Zum Beispiel wird hier angenommen, dass es eine Funktion namens „Autonomes-Fahren-Funktion“ vorliegt. Es wird auch angenommen, dass die „Autonomes-Fahren-Funktion“ durch die folgenden miteinander kooperierenden drei Steuereinheit-Software-Teile implementiert wird: (diejenige) Steuereinheit-Software, die ein Lenkrad steuert (im Folgenden als „Lenkrad-Steuereinheit“ bezeichnet), (diejenige) Steuereinheit-Software, die ein(en) Beschleuniger/Gaspedal steuert (im Folgenden als „Beschleuniger-Steuereinheit“ bezeichnet), und (diejenige) Steuereinheit-Software, die eine Bremse steuert (im Folgenden als „Brems-Steuereinheit“ bezeichnet). In diesem Fall ist, als Beispiel für die SWID, die „Autonomes-Fahren-Funktion Version 1.0“ oder die „Autonomes-Fahren-Funktion Version 2.0“ definiert. Die SWID definiert eine Kombination von Steuereinheit-Software-Teilen unter Berücksichtigung der Versionen der Steuereinheit-Software-Teile. Im obigen Beispiel gibt „Autonomes-Fahren-Funktion Version 1.0“ eine Kombination aus „Lenkrad-Steuereinheit Version 1.0“, „Beschleuniger-Steuereinheit Version 1.0“ und „Brems-Steuereinheit Version 1.0“ an. Außerdem gibt „Autonomes-Fahren-Funktion Version 2.0“ eine Kombination aus „Lenkrad-Steuereinheit Version 2.0“, „Beschleuniger-Steuereinheit Version 2.0“ und „Brems-Steuereinheit Version 2.0“ an.
Bei der vorliegenden Ausführungsform ist/wird ein Hashwert für jede SWID erzeugt. Zum Beispiel ist/wird ein Hashwert basierend auf den Seriennummern und Versionsnummern der Steuereinheit-Software-Teile (im Folgenden als konstituierende Steuereinheiten bezeichnet) erzeugt, definiert als „Autonomes-Fahren-Funktion Version 1.0“. Man kann sagen, dass der Hashwert sogenannte Konfigurationsinformation, die die Softwarekonfiguration der Steuereinheit-Software-Teile der SWID angibt, ist. Der Hashwert wird von dem OTA-Master an das Center gesendet. Das Center vergleicht einen der „Autonomes-Fahren-Funktion Version 1.0“ zugehörigen Hashwert, der in dem Center selbst gespeichert ist oder der selbst berechnet werden kann, mit dem von dem OTA-Master gesendeten Hashwert. Die Erforderlichkeit des Aktualisierungsverfahrens für eine/jegliche konstituierende Steuereinheit der SWID wird basierend auf dem Vergleichsergebnis bestimmt. Insbesondere wird, wenn die Hashwerte übereinstimmen, bestimmt, dass eine Aktualisierung nicht erforderlich ist, und wird, wenn die Hashwerte nicht übereinstimmen, bestimmt, dass eine Aktualisierung erforderlich ist.
Erste Ausführungsform
Nachfolgend wird ein Anwendungsbeispiel für ein solches Verfahren unter Verwendung der oben beschriebenen SWID beschrieben. Der folgende Fall wird in einer ersten Ausführungsform betrachtet. In der ersten Ausführungsform wird angenommen, dass die Kombination der Versionen der Steuereinheit-Software-Teile, die als eine bestimmte SWID definiert sind, und die tatsächliche Kombination der Versionen der Steuereinheit-Software-Teile aufgrund des Austauschs einer vorbestimmten Steuereinheit nicht übereinstimmen. Insbesondere wird angenommen, dass sich bei einem Fahrzeug, das mit der „Autonomes-Fahren-Funktion Version 2.0“ ausgestattet ist, die Version der Steuereinheit für den Beschleuniger (bzw. das Gaspedal) infolge des Austauschs einer Steuereinheit zur Steuerung eines Beschleunigers von „Version 2.0“ auf „Version 1.0“ geändert hat. In diesem Fall sollten in Bezug auf die Kombination der Versionen der als „Autonomes-Fahren-Funktion Version 2.0“ definierten Steuereinheit-Software-Teile die Versionen der Beschleuniger-Steuereinheit, der Lenkrad-Steuereinheit und der Brems-Steuereinheit alle „Version 2.0“ sein. Jedoch unterscheidet sich die tatsächliche Kombination der Versionen der Beschleuniger-Steuereinheit, der Lenkrad-Steuereinheit und der Brems-Steuereinheit von dieser Kombination aufgrund des Austauschs der Steuereinheit (im Folgenden wird dieser Zustand mitunter als „Nichtübereinstimmungszustand“ bezeichnet). Es wird als unerwünscht angesehen, das Fahrzeug in einem solchen Zustand zu betreiben. Daher ist es erforderlich, die Beschleuniger-Steuereinheit von „Version 1.0“ auf „Version 2.0“ zu aktualisieren.
In der ersten Ausführungsform wird die SWID, deren Konfiguration sich geändert hat, erkannt, wenn ein solcher Nichtübereinstimmungszustand (bzw. Nichtübereinstimmungszustand) auftritt. Ein Hashwert für die SWID, deren Konfiguration sich geändert hat, (im Folgenden als „SWID-Hashwert“ bezeichnet) wird erzeugt. Im obigen Beispiel hat sich die Beschleuniger-Steuereinheit, die eine konstituierende Steuereinheit der „Autonomes-Fahren-Funktion Version 2.0“ ist, geändert. Demgemäß wird ein SWID-Hashwert basierend auf den Versionen der „Lenkrad-Steuereinheit“, der „Beschleuniger-Steuereinheit“ und der „Brems-Steuereinheit“ zu dem Zeitpunkt einer Änderung der Beschleuniger-Steuereinheit erzeugt. Das heißt, ein SWID-Hashwert wird basierend auf „Lenkrad-Steuereinheit Version 2.0“, „Beschleuniger-Steuereinheit Version 1.0“ (die Version hat sich aufgrund des Austauschs geändert) und „Brems-Steuereinheit Version 2.0“ erzeugt. Der SWID-Hashwert wird an das Center gesendet und das Center bestimmt die Erforderlichkeit einer Aktualisierung (bzw. eines Updates). Ein Verfahren der Durchführung eines Aktualisierungsverfahrens für die Beschleuniger-Steuereinheit wird durchgeführt, wenn eine Aktualisierung erforderlich ist. Nachfolgend wird die erste Ausführungsform näher beschrieben.
Gesamtkonfiguration des Systems der ersten Ausführungsform
1 ist ein Blockdiagramm, das eine Gesamtkonfiguration eines Aktualisierungssteuerungssystems gemäß der ersten Ausführungsform zeigt. Das Aktualisierungssteuerungssystem weist ein Center 1 und ein Fahrzeug 3 auf.
Das Center 1 ist ein Server, der eine Aktualisierung von Software auf einer fahrzeuginternen Vorrichtung in dem Fahrzeug 3 managt (genauer gesagt ist das Center 1 ein Centersystem mit einem solchen Server, wird jedoch der Einfachheit halber als Server beschrieben). Das Center 1 kann mit dem Fahrzeug 3 kommunizieren (OTA-Master 31).
Das Fahrzeug 3 ist mit einem fahrzeuginternen Netzwerksystem (nicht dargestellt) ausgestattet. Das fahrzeuginterne Netzwerksystem kann mit dem Center 1 kommunizieren. Das fahrzeuginterne Netzwerksystem weist zumindest den OTA-Master (Software-Aktualisierungsvorrichtung) 31, ein Kommunikationsmodul 32 und eine Vielzahl von (elektronischen) Steuereinheiten (ECUs) 33a bis 33d auf.
Der OTA-Master 31 ist mit dem Kommunikationsmodul 32 und den Steuereinheiten 33a bis 33d über einen Bus 35 verbunden. Der OTA-Master 31 kann mit dem Center 1 über das Kommunikationsmodul 32 drahtlos kommunizieren. Der OTA-Master 31 steuert ein Software-Aktualisierungsverfahren für jede Steuereinheit 33a bis 33d, während er vorbestimmte Daten an das Center 1 sendet und von ihm empfängt. Das heißt, der OTA-Master 31 hat eine Software-Aktualisierungsfunktion. Das Kommunikationsmodul 32 ist eine Kommunikationsvorrichtung, die an ein vorbestimmtes Netzwerk (Telefonnetzwerk, Internetnetzwerk, etc.) angeschlossen ist. Eine der Steuereinheiten 33a bis 33d kann als der OTA-Master 31 fungieren.
Die Steuereinheiten 33a bis 33d steuern den Betrieb verschiedener Teile des Fahrzeugs 3. Es versteht sich, dass die Anzahl der Steuereinheiten 33a bis 33d in 1 nur beispielhaft ist.
Konfiguration von Center 1
2 ist ein Blockdiagramm, das eine schematische Konfiguration des Centers 1 zeigt. Wie in 2 dargestellt, weist das Center 1 einen Prozessor 11, einen Direktzugriffsspeicher (RAM) 12, eine Speichervorrichtung 13 und eine Kommunikationsvorrichtung 14 auf. Die Speichervorrichtung 13 hat ein lesbares und beschreibbares Speichermedium, wie z. B. ein Festplattenlaufwerk (HDD) oder ein Solid State Drive (SSD). Die Speichervorrichtung 13 speichert verschiedene Arten von Programmen und Daten, die für Verfahren gemäß der vorliegenden Ausführungsform erforderlich sind. Der Prozessor 11 führt ein vorbestimmtes Steuerverfahren aus, indem er aus der Speichervorrichtung 13 gelesene Programme durch Verwendung des RAM 12 als Arbeitsbereich ausführt. Die Kommunikationsvorrichtung 14 kommuniziert mit dem Fahrzeug 3 über das Netzwerk.
Konfiguration des OTA-Masters 31
3 ist ein Blockdiagramm, das eine schematische Konfiguration des OTA-Masters 31 zeigt. Wie in 3 dargestellt, weist der OTA-Master 31 einen Mikrocomputer 45 und eine Kommunikationsvorrichtung 46 auf. Der Mikrocomputer 45 weist einen Prozessor 41, einen Arbeitsspeicher 42, einen Festwertspeicher (ROM) 43 und eine Speichervorrichtung 44 auf. In dem OTA-Master 31 führt der Prozessor 41 des Mikrocomputers 45 ein vorbestimmtes Steuerverfahren durch, indem er aus dem ROM 43 gelesene Programme durch Verwendung des RAM 42 als Arbeitsbereich ausführt. Die Kommunikationsvorrichtung 46 kommuniziert mit dem Kommunikationsmodul 32 und den Steuereinheiten 33a bis 33d über den in 1 dargestellten Bus 35.
Funktionsblockdiagramm des Centers 1
4 ist ein Funktionsblockdiagramm des Centers 1. Das Center 1 weist eine Speichereinheit 16, eine Kommunikationseinheit 17 und eine Steuereinheit 18 auf. Die Kommunikationseinheit 17 und die Steuereinheit 18 werden von dem in 2 dargestellten Prozessor 11, der in der Speichervorrichtung 13 gespeicherte Programme durch Verwendung des RAM 12 ausführt, implementiert. Die Speichereinheit 16 wird durch die in 2 gezeigte Speichervorrichtung 13 implementiert.
Die Speichereinheit 16 speichert Programme und Daten, die in den Verfahren gemäß der vorliegenden Ausführungsform zu verwenden sind.
Die Steuereinheit 18 sendet und empfängt unter Verwendung der Kommunikationseinheit 17 vorbestimmte Daten an den bzw. von dem OTA-Master 31 und führt ein Software-Aktualisierungsverfahren durch.
Funktionsblockdiagramm des OTA-Masters 31
5 ist ein Funktionsblockdiagramm des in 3 dargestellten OTA-Masters 31.
Der OTA-Master 31 weist eine Speichereinheit 47, eine Kommunikationseinheit 48 und eine Steuereinheit 49 auf. Die Speichereinheit 47 ist durch die in 3 gezeigte Speichervorrichtung 44 implementiert. Die Kommunikationseinheit 48 und die Steuereinheit 49 sind durch den in 3 dargestellten Prozessor 41, der in dem ROM 43 gespeicherte Programme durch Verwendung des RAM 42 ausführt, implementiert.
Die Speichereinheit 47 speichert verschiedene Arten von Programmen und Daten zur Ausführung des Software-Aktualisierungsverfahrens.
Die Steuereinheit 49 kommuniziert mit dem Center 1 über die Kommunikationseinheit 48 und führt verschiedene Steuerungen bezüglich des Software-Aktualisierungsverfahrens durch. Insbesondere führt die Steuereinheit 49 ein Verfahren einer Erkennung eines Auftretens einer Änderung in der Softwarekonfiguration, wie oben dargestellt, ein Verfahren einer Erzeugung eines SWID-Hashwertes, wenn die Änderung aufgetreten ist, und ein Senden des SWID-Hashwertes an das Center und ein Verfahren der Aktualisierung der vorbestimmten Steuereinheit-Software, soweit erforderlich, durch. Die Kommunikationseinheit 48 ist ein Beispiel einer „Übertragungseinheit“.
Nachfolgend werden die Verfahren gemäß der ersten Ausführungsform im Detail beschrieben.
Daten zur Verwendung in dem Center 1
Zunächst werden die in den Verfahren des Centers 1 zu verwendenden Daten beschrieben. 6 zeigt einen Speicherplan, der ein Beispiel für die in der Speichereinheit 16 des Centers 1 gespeicherten Daten darstellt. Ein Aktualisierungssteuerungsprogramm 101, eine Software-ID (SWID)-Datenbank 102 und eine Fahrzeugdatenbank 103 sind in der Speichereinheit 16 gespeichert. Obwohl in der Abbildung nicht gezeigt, können auch verschiedene Arten von Programmen und Daten zur Implementierung des OTA-Dienstes in der Speichereinheit 16 gespeichert werden.
Das Aktualisierungssteuerungsprogramm 101 ist ein Programm zur Steuerung des Software-Aktualisierungsverfahrens gemäß der vorliegenden Ausführungsform.
Die SWID-Datenbank 102 ist eine Datenbank, die die SWID definiert. In der SWID-Datenbank 102 sind alle SWIDs definiert, die in dem Fahrzeug installiert werden können. 7 zeigt ein Beispiel für die Datenkonfiguration der SWID-Datenbank 102. Die SWID-Datenbank 102 ist eine Datenbank, die zumindest die folgenden Elemente aufweist: SWID 111 und Konfigurationsinformation(en) 112. Das Element der SWID 111 sind Daten (bzw. ist ein Datenwert), die die SWID identifizieren, wie z. B. die oben beschriebene „Autonomes-Fahren-Funktion Version 1.0“. Das Element der Konfigurationsinformation(en) 112 sind Daten über die konstituierenden Steuereinheiten, die die SWID bilden (die der SWID zugehörige Funktion). Insbesondere ist/sind die Konfigurationsinformation(en) 112 ein tabellarischer Datensatz, der die folgenden Elemente aufweist: konstituierende Steuereinheit 113 und Ver(sions)-Information(en) 114. Das Element der konstituierenden Steuereinheit 113 sind Daten, die die Steuereinheit-Software-Teile identifizieren, die die SWID konstitutieren/bilden. Das Element der Version-Information(en) 114 sind Daten, die die Version jedes Steuereinheit-Software-Teils angeben. Im Beispiel von 7 definiert die SWID 111, dass die „Autonomes-Fahren-Funktion Version 1.0“ aus einer Kombination von „Beschleuniger-Steuereinheit Version 1.0“, „Brems-Steuereinheit Version 1.0“ und „Lenkrad-Steuereinheit Version 1.0“ konstituiert ist.
Unter Bezugnahme zurück auf 6 ist die Fahrzeugdatenbank 103 eine Datenbank, in der Information(en) über Fahrzeuge, für die der OTA-Dienst bereitgestellt werden soll, registriert ist/sind. 8 zeigt ein Beispiel für die Datenkonfiguration der Fahrzeugdatenbank 103. Das Element der Fahrzeugdatenbank 103 ist eine Datenbank, die zumindest die folgenden Elemente aufweist: Fahrzeugidentifikationsnummer („VIN“) 121 und vorherige Speicherinformation(en) 122. Die VIN 121 ist eine Nummer, die das Fahrzeug eindeutig identifiziert. Die vorherige Speicherinformation 122 ist Information über die SWID nach Abschluss des aktuellsten Aktualisierungsverfahrens für das in der VIN 121 angegebene Fahrzeug. Insbesondere sind die vorherigen Speicherinformationen 122 Daten ein tabellarischer Datensatz, der die folgenden Elemente aufweist: SWID 123 und vorheriger Hashwert 124. Die SWID 123 ist ein Datenwert, der die in dem Fahrzeug installierte SWID angibt (die der in dem Fahrzeug installierten SWID zugehörige Funktion). Daher kann der Inhalt je nach Fahrzeug variieren. Der vorherige Hashwert 124 ist ein der SWID zugehöriger SWID-Hashwert. In der vorliegenden Ausführungsform ist dieser Wert derselbe Wert wie der Hashwert, der basierend auf der/den Information(en) in der SWID-Datenbank 102 berechnet wird, doch wird der Hashwert selbst gespeichert, um die mit der Berechnung verbundene Arbeit zu sparen.
Daten zur Verwendung in dem OTA-Master 31
Als Nächstes werden die in dem OTA-Master 31 zu verwendenden Daten beschrieben. 9 veranschaulicht einen Speicherplan, der ein Beispiel für die in der Speichereinheit 47 des OTA-Masters 31 gespeicherten Daten zeigt. Zumindest ein Aktualisierungssteuerungsprogramm 151, installierte SWID-Definitionsdaten 152 und ein Prüf-Software-ID (SWID)- Hashwert 153 sind in der Speichereinheit 47 des OTA-Masters 31 gespeichert. Obwohl in der Abbildung nicht dargestellt, können auch verschiedene Arten von Programmen und Daten zur Implementierung des OTA-Dienstes in der Speichereinheit 47 gespeichert werden.
Das Aktualisierungssteuerungsprogramm 151 ist ein Programm für den OTA-Master 31, um die Verfahren gemäß der vorliegenden Ausführungsform durchzuführen.
Die installierten SWID-Definitionsdaten 152 sind Daten über die in dem Fahrzeug installierte SWID (die der in dem Fahrzeug installierten SWID zugehörige Funktion). 10 zeigt ein Beispiel für die Datenkonfiguration der installierten SWID-Definitionsdaten 152. Die installierten SWID-Definitionsdaten 152 sind eine Datenbank, die zumindest die folgenden Elemente aufweist: SWID 161 und Konfigurationsinformation(en) 162. Da die grundlegende Datenkonfiguration der installierten SWID-Definitionsdaten 152 derjenigen der SWID-Datenbank 102 ähnelt, wird auf deren detaillierte Beschreibung verzichtet; jedoch zeigen die installierten SWID-Definitionsdaten 152 nur Daten, die sich auf die derzeit in dem Fahrzeug installierte SWID beziehen, wie sie aus den in der SWID-Datenbank 102 enthaltenen Daten extrahiert worden ist. Der Inhalt der installierten SWID-Definitionsdaten 152 kann aktualisiert werden, wenn das Aktualisierungsverfahren durchgeführt wird. Wenn z. B. „Autonomes-Fahren-Funktion Version 1.0“ auf „Autonomes-Fahren-Funktion Version 2.0“ als ein Ergebnis des Aktualisierungsverfahrens durch den OTA-Dienst aktualisiert ist/wird, ist/wird auch der Inhalt der installierten SWID-Definitionsdaten 152 gemäß dieser Aktualisierung aktualisiert.
Unter Bezugnahme zurück auf 9 ist der Prüf-SWID-Hashwert 153 ein Datenwert, der verwendet wird, um festzustellen, ob in der Softwarekonfiguration des Fahrzeugs eine andere Änderung als eine Änderung aufgrund des Aktualisierungsverfahrens bezüglich des OTA-Dienstes stattgefunden hat. In der vorliegenden Ausführungsform wird angenommen, dass eine Steuereinheit in einer Wartungswerkstatt physisch ausgetauscht wird. Daher wird davon ausgegangen, dass der Prüf-SWID-Hashwert 153 beispielsweise von einem Wartungsarbeiter, der vor dem Austausch eine vorbestimmte Operation durchführt, erzeugt wird. Insbesondere wird der SWID-Hashwert für jede SWID (die in dem Fahrzeug installiert ist) zu diesem Zeitpunkt basierend auf der vorbestimmten Operation berechnet. Es wird angenommen, dass der Prüf-SWID-Hashwert 153 durch Speichern der berechneten SWID-Hashwerte in der Speichereinheit 47 erzeugt wird. 11 zeigt ein Beispiel für die Datenkonfiguration des Prüf-SWID-Hashwerts 153. Der Prüf-SWID-Hashwert 153 ist ein tabellarischer Datensatz, der die folgenden Elemente aufweist: SWID 171 und Prüf-Hashwert 172. Das Element der SWID 171 ist ein Datenwert (bzw. sind Daten), der die in dem Fahrzeug installierte SWID angibt. Das Element des Prüf-Hashwerts 172 ist ein Datenwert, der die SWID-Hashwerte vor Austauscharbeiten speichert.
Verfahrensablauf in der ersten Ausführungsform
Im Folgenden wird der Verfahrensablauf der ersten Ausführungsform beschrieben. 12 und 13 sind Flussdiagramme, die die Details des Aktualisierungssteuerungsverfahrens gemäß der ersten Ausführungsform veranschaulichen. In den 12 und 13 ist ein Verfahren dargestellt, das von dem OTA-Master 31 durchgeführt wird, auf der linken Seite der Abbildung und ist ein Verfahren, das von dem Center 1 durchgeführt wird, auf der rechten Seite der Abbildung dargestellt. In der vorliegenden Ausführungsform wird davon ausgegangen, dass das Verfahren auf der Seite des OTA-Masters 31 gestartet wird, wenn die Zündung des Fahrzeugs eingeschaltet wird. In der folgenden Beschreibung wird davon ausgegangen, dass der Prüf-SWID-Hashwert 153 bereits von einem Wartungsarbeiter wie oben beschrieben erzeugt worden ist.
Zunächst, in Schritt S1, bestimmt die Steuereinheit 49 des OTA-Masters 31, ob eine Änderung in der Softwarekonfiguration der in dem Fahrzeug installierten Steuereinheit-Software stattgefunden hat. Das heißt, die Steuereinheit 49 des OTA-Masters 31 bestimmt, ob eine SWID, die sich in dem Nichtübereinstimmungszustand befindet (bzw. ist), vorliegt. Obwohl diese Bestimmung mit einem beliebigen Verfahren durchgeführt werden kann, wird in der vorliegenden Ausführungsform ein Verfahren, bei dem die SWID-Hashwerte vor und nach dem Steuereinheitsaustausch verglichen werden, dargestellt. Insbesondere werden vor solchem Steuereinheitsaustausch die SWID-Hashwerte für alle in dem Fahrzeug installierten SWIDs basierend auf der Operation des Wartungsarbeiters gespeichert. Die Steuereinheit 49 prüft dann für jede SWID, ob der SWID-Hashwert nach dem Austausch mit dem gespeicherten SWID-Hashwert übereinstimmt. Die Steuereinheit 49 bestimmt somit, ob eine Änderung in der Softwarekonfiguration stattgefunden hat. Das heißt, die Steuereinheit 49 berechnet den SWID-Hashwert jeder SWID und vergleicht den berechneten SWID-Hashwert jeder SWID mit dem Inhalt des Prüf-SWID-Hashwerts 153. Wenn eine Nichtübereinstimmung zwischen den SWID-Hashwerten (irgend)einer SWID vorliegt, bestimmt die Steuereinheit 49, dass eine Änderung in der Softwarekonfiguration dieser SWID stattgefunden hat. Wenn keine Nichtübereinstimmung zwischen den SWID-Hashwerten vorliegt, bestimmt die Steuereinheit 49, dass keine Änderung in der Softwarekonfiguration stattgefunden hat. Die Steuereinheit 49 ist ein Beispiel einer „Konfigurationsinformationserfassungseinheit“.
Was Schritt S1 betrifft, so werden in der ersten Ausführungsform die SWID-Hashwerte aller in dem Fahrzeug installierten SWIDs gespeichert, und überprüft die Steuereinheit 49 alle die SWIDs, um eine SWID zu erkennen, deren Konfiguration sich geändert hat. In einer anderen Ausführungsform kann der Schritt S1 wie folgt durchgeführt werden. Es wird beispielsweise davon ausgegangen, dass die auszutauschende Steuereinheit im Voraus in einer Wartungswerkstatt bestimmt werden kann. Daher können vor Beginn der Austauscharbeiten nur die Daten, die die SWID angeben, deren konstituierende Steuereinheit die zu ersetzende Steuereinheit ist, und der SWID-Hashwert dieser SWID als Prüf-SWID-Hashwert 153 gespeichert werden. In Schritt S1 kann (vorzugsweise) die Steuereinheit 49 das obige Vergleichsverfahren nur für die SWID der zu ersetzenden Steuereinheitr durchführen. Dadurch kann die Verarbeitung beschleunigt werden.
Wenn die Steuereinheit 49 in Schritt S1 bestimmt, dass keine Änderung in der Softwarekonfiguration stattgefunden hat (NEIN in Schritt S1), wird das Aktualisierungssteuerungsverfahren auf der Fahrzeugseite (OTA-Master-Seite) beendet. Bestimmt hingegen die Steuereinheit 49 in Schritt S1, dass eine Änderung in der Softwarekonfiguration stattgefunden hat (JA in Schritt S1), fährt die Routine mit Schritt S2 fort. In Schritt S2 berechnet die Steuereinheit 49 den SWID-Hashwert der SWID, deren Softwarekonfiguration sich geändert hat. Die Steuereinheit 49 erzeugt dann eine „Aktualisierungsanfrage“ und sendet sie an das Center 1. Die „Aktualisierungsanfrage“ ist ein Datenwert (bzw. sind Daten) zur Abfrage, ob eine Aktualisierung vorliegt. Zu diesem Zeitpunkt nimmt die Steuereinheit 49 die das Fahrzeugs angebende VIN, die SWID, deren Softwarekonfiguration sich geändert hat, und den berechneten SWID-Hashwert in die „Aktualisierungsanfrage“ auf und sendet die „Aktualisierungsanfrage“ an das Center 1.
Als Nächstes, in Schritt S3, bestimmt die Steuereinheit 18 des Centers 1, ob die „Aktualisierungsanfrage“ mit dem SWID-Hashwert von einem vorbestimmten Fahrzeug gesendet worden ist. Wenn die „Aktualisierungsanfrage“ nicht von einem vorbestimmten Fahrzeug gesendet worden ist (NEIN in Schritt S3), wiederholt die Steuereinheit 18 den Schritt S3 (d. h. wartet auf eine „Aktualisierungsanfrage“). Wenn die „Aktualisierungsanfrage“ von dem vorbestimmten Fahrzeug gesendet worden ist (JA in Schritt S3), fährt die Routine mit Schritt S4 fort. In Schritt S4 empfängt die Steuereinheit 18 die „Aktualisierungsanfrage“ und führt ein Prüfverfahren basierend auf dem in der „Aktualisierungsanfrage“ enthaltenen SWID-Hashwert durch. Insbesondere bezieht sich die Steuereinheit 18 auf die Fahrzeugdatenbank 103 und identifiziert das Fahrzeug (OTA-Master 31), das die „Aktualisierungsanfrage“ gesendet hat. Die Steuereinheit 18 erfasst auch den vorherigen Hashwert 124, der der in der „Aktualisierungsanfrage“ enthaltenen SWID entspricht, aus der Fahrzeugdatenbank 103. Das Steuereinheit 18 bestimmt dann, ob der vorherige Hashwert 124 mit dem in der Aktualisierungsanfrage enthaltenen SWID-Hashwert übereinstimmt. Wenn die Steuereinheit 18 bestimmt, dass die Hashwerte übereinstimmen (JA in Schritt S4), sendet die Steuereinheit 18 in Schritt S5 eine Keine-Aktualisierung-erforderlich-Benachrichtigung (bzw. eine Meldung, dass keine Aktualisierung erforderlich) an den OTA-Master 31. Die Keine-Aktualisierung-erforderlich-Benachrichtigung ist eine Benachrichtigung, die anzeigt, dass das Aktualisierungsverfahren nicht erforderlich ist. Die Routine kehrt dann zu Schritt S3 zurück (die Steuereinheit 18 wartet auf eine „Aktualisierungsanfrage“).
Wenn andererseits die Steuereinheit 18 bestimmt, dass die Hashwerte nicht übereinstimmen (NEIN in Schritt S4), fährt die Routine mit Schritt S6 fort. In Schritt S6 sendet die Steuereinheit 18 an den OTA-Master 31 eine Anfrage, Detailinformation(en) über diese SWID zu senden. Die Detailinformation(en) bezieht/beziehen sich auf Information(en), die die spezifischen Softwareversionen der konstituierenden Steuereinheiten der SWID (anstatt den SWID-Hashwert) angibt/angeben. Nach dem Senden der Anfrage wartet die Steuereinheit 18 auf eine Antwort von dem OTA-Master 31.
Als Nächstes, in Schritt S7, bestimmt die Steuereinheit 49 des OTA-Masters 31, ob eine Anfrage, Detailinformation(en) zu senden, vorliegt. Insbesondere bestimmt die Steuereinheit 49, ob eine Keine-Aktualisierung-erforderlich-Benachrichtigung an den OTA-Master 31 gesendet worden ist oder ob eine Anfrage, Detailinformation(en) zu senden, an den OTA-Master 31 gesendet worden ist. Wenn eine Keine-Aktualisierung-erforderlich-Benachrichtigung an den OTA-Master 31 gesendet worden ist (NEIN in Schritt S7), geht die Steuereinheit 49 davon aus, dass keine Detailinformation angefordert worden ist, und beendet das Aktualisierungssteuerungsverfahren auf der Fahrzeugseite. Wenn andererseits eine Anfrage, Detailinformation(en) zu senden, an den OTA-Master 31 gesendet worden ist (JA in Schritt S7), fährt die Routine mit Schritt S8 fort. In Schritt S8 erzeugt die Steuereinheit 49 Detailinformation(en) und sendet sie an das Center 1. Insbesondere erfasst die Steuereinheit 49 Information(en) über die Softwareversionen der konstituierenden Steuereinheiten der in der Anfrage spezifizierten SWID. Die Steuereinheit 49 erzeugt dann Detailinformation(en) einschließlich der Information(en) über die Softwareversionen und sendet die Detailinformation(en) an das Center 1. Danach wartet die Steuereinheit 49 auf eine Benachrichtigung oder eine Anweisung von dem Center 1.
Anschließend, in Schritt S9, empfängt die Steuereinheit 18 des Centers 1 die von der Steuereinheit 49 gesendete(n) Detailinformation(en). In Schritt S10 identifiziert die Steuereinheit 18 dann die Steuereinheit-Software, deren Version nicht übereinstimmt/übereinstimmt, basierend auf der/den Detailinformation(en). Insbesondere vergleicht die Steuereinheit 18 die in der/den Detailinformation(en) gezeigte Version jeder konstituierenden Steuereinheit mit der/den in der SWID-Datenbank 102 definierten Version-Information(en) 114, um die konstituierende Steuereinheit zu identifizieren, deren Version nicht übereinstimmt. Nachfolgend wird diese konstituierende Steuereinheit, deren Version nicht übereinstimmt, als „Nichtübereinstimmungs-Steuereinheit“ bezeichnet.
Danach, in Schritt S11 von 13, bestimmt die Steuereinheit 18, ob es erforderlich ist, den Nichtübereinstimmungszustand zu beseitigen, indem sie das Aktualisierungsverfahren für die Nichtübereinstimmungs-Steuereinheit durchführt. Diese Bestimmung erfolgt unter Berücksichtigung der Tatsache, dass der Nichtübereinstimmungszustand prinzipiell beseitigt werden sollte, aber je nach Softwareversion es Fälle geben kann, in denen es kein funktionales Problem geben wird, selbst wenn der Nichtübereinstimmungszustand bestehen bleibt. Wenn beispielsweise die Version de Beschleuniger-Steuereinheit von 2.0 auf 2.1 aktualisiert wird, kann es sich bei der mit der Aktualisierung verbundenen Änderung um eine Änderung handeln, die die Implementierung der Autonomes-Fahren-Funktion nicht beeinträchtigt. In diesem Fall kann die Steuereinheit 18 bestimmen, dass eine Aktualisierung nicht erforderlich ist, selbst wenn die Version der Beschleuniger-Steuereinheit nicht mit dem Inhalt der in der SWID-Datenbank 102 definierten Version-Information 114 übereinstimmt. Auf diese Weise lässt sich ein Aktualisierungsverfahren, das nicht unbedingt durchgeführt werden muss, vermeiden und kann der Kommunikationsaufwand reduziert werden. Information(en) über eine solche Version, die auch in dem Nichtübereinstimmungszustand zulässig ist, ist/sind in den Abbildungen nicht dargestellt. Die Daten, die die Information(en) über eine solche Version, die auch in dem Nichtübereinstimmungszustand zulässig ist, angeben, können in der Speichereinheit 16 des Centers 1 gespeichert werden. In diesem Fall kann die Steuereinheit 18 basierend auf dieser/diesen Information(en) die Erforderlichkeit des Aktualisierungsverfahrens bestimmen.
Wenn die Steuereinheit 18 in Schritt S11 bestimmt, dass es nicht erforderlich ist, den Nichtübereinstimmungszustand zu beseitigen (NEIN in Schritt S11), fährt die Routine mit Schritt S12 fort. In Schritt S12 sendet die Steuereinheit 18 eine „Keine-Aktualisierung-erforderlich-Benachrichtigung“ an den OTA-Master 31. Die Routine kehrt dann zu Schritt S3 zurück.
Wenn andererseits die Steuereinheit 18 in Schritt S11 bestimmt, dass es erforderlich ist, den Nichtübereinstimmungszustand zu beseitigen (JA in Schritt S11), wird das Aktualisierungsverfahren durchgeführt. Insbesondere sendet zunächst die Steuereinheit 18 in Schritt S13 einen Aktualisierungsstartbefehl an den OTA-Master 31. Die Steuereinheit 49 des OTA-Masters 31 bestimmt dann in Schritt S14, ob ein Aktualisierungsstartbefehl empfangen worden ist. Wenn die Steuereinheit 49 in Schritt S14 bestimmt, dass eine Keine-Aktualisierung-erforderlich-Benachrichtigung (anstatt ein Aktualisierungsstartbefehl) empfangen worden ist (NEIN in Schritt S14), beendet die Steuereinheit 49 das Aktualisierungssteuerungsverfahren auf der Seite des OTA-Masters 31. Andererseits, wenn die Steuereinheit 49 in Schritt S14 bestimmt, dass ein Aktualisierungsstartbefehl empfangen worden ist (JA in Schritt S14), arbeiten die Steuereinheit 18 des Centers 1 und die Steuereinheit 49 des OTA-Masters 31 in geeigneter Weise zusammen, um das Aktualisierungsverfahren für die Nichtübereinstimmungs-Steuereinheit in Schritten S15 und S16 durchzuführen. Insbesondere sendet die Steuereinheit 18 des Centers 1 Aktualisierungsdaten an den OTA-Master 31. Die Steuereinheit 49 des OTA-Masters 31 führt ein Verfahren zur Aktualisierung der Software auf der Nichtübereinstimmungs-Steuereinheit basierend auf den Aktualisierungsdaten durch.
In Schritt S17 bestimmt die Steuereinheit 49 dann, ob das Aktualisierungsverfahren abgeschlossen ist. Wenn das Aktualisierungsverfahren noch nicht abgeschlossen ist (NEIN in Schritt S17), kehrt die Routine zu Schritt S15 zurück, und setzt die Steuereinheit 49 das Aktualisierungsverfahren fort. Wenn das Aktualisierungsverfahren abgeschlossen ist (JA in Schritt S17), sendet die Steuereinheit 49 eine Aktualisierungsabschluss-Benachrichtigung (bzw. Benachrichtigung über den Abschluss der Aktualisierung) an das Center 1. In Schritt S18 erzeugt die Steuereinheit 49 außerdem einen aktualisierten SWID-Hashwert. Die Steuereinheit 49 sendet den erzeugten SWID-Hashwert an das Center 1.
Die Steuereinheit 18 des Centers 1 bestimmt in Schritt S19, ob die Steuereinheit 18 eine Aktualisierungsabschluss-Benachrichtigung von dem OTA-Master 31 erhalten hat. Wenn die Steuereinheit 18 keine Aktualisierungsabschluss-Benachrichtigung erhalten hat, kehrt die Routine zu Schritt S16 zurück, und setzt die Steuereinheit 18 das Aktualisierungsverfahren fort. Wenn die Steuereinheit 18 eine Aktualisierungsabschluss-Benachrichtigung erhält, geht die Routine zu Schritt S20 über. In Schritt S20 empfängt die Steuereinheit 18 den von dem OTA-Master 31 gesendeten aktualisierten SWID-Hashwert und zeichnet ihn als den vorherigen Hashwert 124 in der Fahrzeugdatenbank 103 auf. Die Routine kehrt dann zu Schritt S3 zurück; und die Steuereinheit 18 wiederholt das Verfahren.
In Schritt S21 aktualisiert die Steuereinheit 49 des OTA-Masters 31 dann den Inhalt des Prüf-SWID-Hashwerts 153 mit dem Inhalt des aktualisierten SWID-Hashwerts. Demgemäß bestimmt die Steuereinheit 49 das nächste Mal, dass die Steuereinheit 49 den Schritt S1 durchführt, dass keine Änderung in der Softwarekonfiguration stattgefunden hat. Dies bedeutet, dass der Nichtübereinstimmungszustand in der Softwarekonfiguration beseitigt worden ist. Das Aktualisierungssteuerungsverfahren gemäß der ersten Ausführungsform endet auf diese Weise.
Wie oben beschrieben, wird/werden in der ersten Ausführungsform, wenn eine Änderung in der Softwarekonfiguration einer Steuereinheit aufgrund eines Austauschs der Steuereinheit auftritt, nur die Information(en) über die Steuereinheit der SWID, in der die Änderung aufgetreten ist, an das Center 1 gesendet und wird das Aktualisierungsverfahren durchgeführt. Demgemäß kann der Kommunikationsaufwand im Vergleich zur Verwendung des Gesamthashwertes reduziert werden und kann die für den Abschluss des Aktualisierungsverfahrens erforderliche Zeit verringert werden.
Zweite Ausführungsform
Als Nächstes wird eine zweite Ausführungsform eines solchen Verfahrens, das eine SWID wie oben beschrieben verwendet, beschrieben. Der folgende Fall wird in der zweiten Ausführungsform betrachtet. In der zweiten Ausführungsform wird davon ausgegangen, dass eine Notfallaktualisierung für eine vorbestimmte Steuereinheit durchzuführen ist. In dem OTA-Dienst stellt der OTA-Master 31 in der Regel periodisch, z. B. alle zwei Wochen, eine Anfrage an das Center 1, ob eine Aktualisierung vorliegt. Wenn das Center 1 als Antwort auf die Anfrage, ob eine Aktualisierung vorliegt, bestimmt, dass eine Aktualisierung vorliegt, wird das Aktualisierungsverfahren durchgeführt. Es kann jedoch Fälle geben, in denen eine Notfallaktualisierung (bzw. ein Notfall-Update) vorliegt. In solchen Fällen wird die folgende Verarbeitung als die zweite Ausführungsform durchgeführt. Zunächst sendet das Center 1 einen Befehl (im Folgenden als der „Center-Befehl“ bezeichnet), um den OTA-Master 31 zu veranlassen, eine „Aktualisierungsanfrage“ an das Center 1 über einen anderen Weg als das für den OTA-Dienst verwendete Netzwerk (Internet-Netzwerk), wie z. B. Kurznachrichtendienst (SMS) oder Fahrzeug-an-Umwelt-Kommunikation (V2X) eines Trägernetzwerks, zu stellen. In der vorliegenden Ausführungsform wird davon ausgegangen, dass das Center 1 den Center-Befehl über eine SMS sendet. Der Center-Befehl enthält Information(en), die die SWID, deren konstituierende Steuereinheit die einer Notfallaktualisierung zu unterziehende Steuereinheit ist, angibt/angeben. Auf der Fahrzeugseite (Seite des OTA-Masters 31) sendet die Steuereinheit 49, wenn sie den Center-Befehl empfängt, den SWID-Hashwert der durch den Center-Befehl angegebenen SWID bei dem nächsten Einschalten der Zündung an das Center 1. Die Steuereinheit 18 des Centers 1 bestimmt die Erforderlichkeit des Aktualisierungsverfahrens für das Fahrzeug, basierend auf dem empfangenen SWID-Hashwert. Wenn erforderlich, wird das Verfahren für die Notfallaktualisierung durchgeführt. Die Steuereinheit 49 ist ein Beispiel einer „Center-Befehl-Empfangseinheit“.
Nachfolgend wird die zweite Ausführungsform im Detail beschrieben. Da die Hardwarekonfiguration (Center 1 und OTA-Master 31) in der zweiten Ausführungsform im Wesentlichen derjenigen in der ersten Ausführungsform ähnelt, wird auf deren detaillierte Beschreibung verzichtet. In der zweiten Ausführungsform fungiert das Kommunikationsmodul 32 des Fahrzeugs 3 auch als Center-Befehl-Empfangseinheit zum Empfang des Center-Befehls.
Die Daten, die in der zweiten Ausführungsform verwendet werden, sind im Wesentlichen ähnlich wie die der ersten Ausführungsform. Jedoch unterscheidet sich ein Teil (bzw. ein Part) der Daten, die in der Speichereinheit 47 des OTA-Masters 31 gespeichert sind, zwischen der ersten und zweiten Ausführungsform. 14 veranschaulicht einen Speicherplan, der ein Beispiel für die in der Speichereinheit 47 des OTA-Masters 31 in der zweiten Ausführungsform gespeicherten Daten darstellt. Zumindest ein Aktualisierungssteuerungsprogramm 151, installierte SWID-Definitionsdaten 152 und Center-Befehlsdaten 181 sind in der Speichereinheit 47 des OTA-Masters 31 gespeichert. Da das Aktualisierungssteuerungsprogramm 151 und die installierten SWID-Definitionsdaten 152 denen der ersten Ausführungsform ähneln, wird deren Beschreibung weggelassen.
Die Center-Befehlsdaten 181 speichern den von dem Kommunikationsmodul 32 empfangenen Center-Befehl. In der vorliegenden Ausführungsform wird bei dem Einschalten der Zündung bestimmt, ob der Center-Befehl vorliegt. Wenn der Center-Befehl vorliegt, wird die Verarbeitung basierend auf dem Inhalt der Center-Befehlsdaten 181 durchgeführt. In der vorliegenden Ausführungsform wird davon ausgegangen, dass der Center-Befehl einen Befehl, eine solche Notfallaktualisierung wie oben beschrieben durchzuführen, insbesondere eine Anweisung, die die der Notfallaktualisierung zu unterziehende SWID an das Center 1 zu senden, definiert.
Als Nächstes wird der Verfahrensablauf der zweiten Ausführungsform beschrieben. 15 ist ein Flussdiagramm, das die Details des Aktualisierungssteuerungsverfahrens gemäß der zweiten Ausführungsform veranschaulicht. In 15 ist ein Verfahren, das von dem OTA-Master 31 durchgeführt wird, auf der linken Seite der Abbildung dargestellt und ist ein Verfahren, das von dem Center 1 durchgeführt wird, auf der rechten Seite der Abbildung dargestellt. In der vorliegenden Ausführungsform wird davon ausgegangen, dass das Verfahren auf der Seite des OTA-Masters 31 gestartet wird, wenn die Zündung des Fahrzeugs eingeschaltet wird. Es wird auch angenommen, dass der Center-Befehl bereits von dem Center 1 über die SMS gesendet worden ist und in den Center-Befehlsdaten 181 gespeichert ist.
Zunächst bestimmt die Steuereinheit 49 des OTA-Masters 31 in Schritt S31, ob ein Center-Befehl empfangen worden ist. Insbesondere bezieht sich die Steuereinheit 49 auf die Center-Befehlsdaten 181. Wenn der Center-Befehl in den Center-Befehlsdaten 181 gespeichert ist, bestimmt die Steuereinheit 49, dass ein Center-Befehl empfangen worden ist. Wenn der Center-Befehl nicht in den Center-Befehlsdaten 181 gespeichert ist, bestimmt die Steuereinheit 49, dass kein Center-Befehl empfangen worden ist. Wenn die Steuereinheit 49 bestimmt, dass kein Center-Befehl empfangen worden ist (NEIN in Schritt S31), beendet die Steuereinheit 49 das Aktualisierungssteuerungsverfahren gemäß der zweiten Ausführungsform. Wenn andererseits die Steuereinheit 49 bestimmt, dass ein Center-Befehl empfangen worden ist (JA in Schritt S31), fährt die Routine mit Schritt S32 fort. In Schritt S32 berechnet die Steuereinheit 49 den SWID-Hashwert der durch den Center-Befehl angegebenen SWID. Die Steuereinheit 49 erzeugt dann eine „Aktualisierungsanfrage“, die Information(en) über die SWID und den SWID-Hashwert aufweist, und sendet die „Aktualisierungsanfrage“ an das Center 1.
Danach bestimmt die Steuereinheit 18 des Centers 1 in Schritt S33, ob eine auf dem Center-Befehl basierende „Aktualisierungsanfrage“ von einem vorbestimmten Fahrzeug empfangen worden ist. Beispielsweise werden Daten, die anzeigen, dass diese Aktualisierungsanfrage eine auf dem Center-Befehl basierende „Aktualisierungsanfrage“ ist, in den Kopf der „Aktualisierungsanfrage“ aufgenommen, und kann die Steuereinheit 18 basierend auf diesen Daten bestimmen, ob die Aktualisierungsanfrage die auf dem Center-Befehl basierende „Aktualisierungsanfrage“ ist. Wenn die Steuereinheit 18 bestimmt, dass keine auf dem Center-Befehl basierende „Aktualisierungsanfrage“ empfangen worden ist (NEIN in Schritt S33), wird Schritt S33 wiederholt. Das heißt, die Steuereinheit 18 wartet weiterhin auf die auf dem Center-Befehl basierende „Aktualisierungsanfrage“.
Wenn andererseits die Steuereinheit 18 bestimmt, dass eine auf dem Center-Befehl basierende „Aktualisierungsanfrage“ empfangen worden ist (JA in Schritt S33), fährt die Routine mit Schritt S34 fort. In Schritt S34 bestimmt die Steuereinheit 18, ob das Aktualisierungsverfahren erforderlich ist, basierend auf dem in der empfangenen „Aktualisierungsanfrage“ enthaltenen SWID-Hashwert. Insbesondere bestimmt die Steuereinheit 18, ob der in der „Aktualisierungsanfrage“ enthaltene SWID-Hashwert mit dem SWID-Hashwert der dieses Mal der Notfallaktualisierung zu unterziehenden SWID übereinstimmt. Wenn diese SWID-Hashwerte übereinstimmen, bestimmt die Steuereinheit 18, dass die Aktualisierung nicht erforderlich ist. Wenn diese SWID-Hashwerte nicht übereinstimmen, bestimmt die Steuereinheit 18, dass die Aktualisierung erforderlich ist. Beispielsweise ist eine solche Notfallaktualisierung nicht erforderlich, wenn ein dieser Notfallaktualisierung ähnliches Aktualisierungsverfahren bereits in einer Wartungswerkstatt durchgeführt worden ist, bevor der Center-Befehl für die Notfallaktualisierung empfangen worden ist.
Wenn die Steuereinheit 18 in Schritt S34 bestimmt, dass die Aktualisierung nicht erforderlich ist (NEIN in Schritt S34), sendet die Steuereinheit 18 in Schritt S35 eine Keine-Aktualisierung-erforderlich-Benachrichtigung an den OTA-Master 31. Wenn andererseits die Steuereinheit 18 in Schritt S34 bestimmt, dass die Aktualisierung erforderlich ist (JA in Schritt S34), sendet die Steuereinheit 18 in Schritt S36 einen Aktualisierungsstartbefehl an den OTA-Master 31. Danach bestimmt die Steuereinheit 49 des OTA-Masters 31 in Schritt S37, ob ein Aktualisierungsstartbefehl empfangen worden ist. Wenn die Steuereinheit 49 in Schritt S37 bestimmt, dass eine Keine-Aktualisierung-erforderlich-Benachrichtigung (anstatt ein Aktualisierungsstartbefehl) empfangen worden ist (NEIN in Schritt S37), beendet die Steuereinheit 49 das Aktualisierungssteuerungsverfahren. Wenn andererseits die Steuereinheit 49 in Schritt S37 bestimmt, dass ein Aktualisierungsstartbefehl empfangen worden ist (JA in Schritt S37), arbeiten die Steuereinheit 18 des Centers 1 und die Steuereinheit 49 des OTA-Masters 31 in geeigneter Weise zusammen, um das Aktualisierungsverfahren in Schritten S38 und S39 durchzuführen. Insbesondere sendet die Steuereinheit 49 solche Detailinformation(en) wie in der ersten Ausführungsform beschrieben an das Center 1. Die Steuereinheit 18 des Centers 1 identifiziert die zu aktualisierende Steuereinheit-Software und sendet Aktualisierungsdaten an den OTA-Master 31. Die Steuereinheit 49 des OTA-Masters 31 führt dann, basierend auf den Aktualisierungsdaten, ein Verfahren zur Aktualisierung der der Notfallaktualisierung zu unterziehenden Steuereinheit-Software durch.
In Schritt S40 bestimmt die Steuereinheit 49 dann, ob das Aktualisierungsverfahren abgeschlossen ist. Wenn das Aktualisierungsverfahren noch nicht abgeschlossen ist (NEIN in Schritt S40), kehrt die Routine zu Schritt S38 zurück, und setzt die Steuereinheit 49 das Aktualisierungsverfahren fort. Wenn das Aktualisierungsverfahren abgeschlossen ist (JA in Schritt S40), sendet die Steuereinheit 49 eine Aktualisierungsabschluss-Benachrichtigung (bzw. Benachrichtigung über den Abschluss der Aktualisierung an das Center 1.
Die Steuereinheit 18 des Centers 1 bestimmt in Schritt S41, ob die Steuereinheit 18 eine Aktualisierungsabschluss-Benachrichtigung erhalten hat. Wenn die Steuereinheit 18 keine Aktualisierungsabschluss-Benachrichtigung erhalten hat (NEIN in Schritt S41), kehrt die Routine zu Schritt S39 zurück, und setzt die Steuereinheit 18 das Aktualisierungsverfahren fort. Wenn die Steuereinheit 18 eine Aktualisierungsabschluss-Benachrichtigung erhalten hat (JA in Schritt S41), kehrt die Routine zu Schritt S33 zurück und wiederholt die Steuereinheit 18 das Verfahren.
Danach, in Schritt S42, löscht die Steuereinheit 49 des OTA-Masters 31 die Center-Befehlsdaten 181. Infolgedessen bestimmt die Steuereinheit 49 in Schritt S31, dass kein Center-Befehl empfangen worden ist, es sei denn, ein neuer Center-Befehl wird empfangen.
Das Aktualisierungssteuerungsverfahren gemäß der zweiten Ausführungsform endet auf diese Weise.
Wie oben beschrieben, kann in der zweiten Ausführungsform, wenn eine Notfallaktualisierung vorliegt, die zu aktualisierende Steuereinheit im Voraus bestimmt werden. Daher enthält der Center-Befehl eine Anweisung, nur die SWID der zu aktualisierenden Steuereinheit zu senden. Demgemäß kann die Erforderlichkeit der Aktualisierung für jede mit der zu aktualisierenden Steuereinheit verbundene SWID bestimmt werden, ohne dass eine Verarbeitung für alle Steuereinheiten durchgeführt wird. Die Verarbeitung bezüglich der Notfallaktualisierung kann somit schneller abgeschlossen werden.
Dritte Ausführungsform
Als Nächstes wird eine dritte Ausführungsform beschrieben. Die dritte Ausführungsform veranschaulicht das kombinierte Verfahren der ersten Ausführungsform und der zweiten Ausführungsform. Insbesondere, wenn eine Änderung in der Softwarekonfiguration bei dem Empfang des Center-Befehls aufgetreten ist, sendet die Steuereinheit 49 auch den SWID-Hashwert der SWID, die der Änderung der Softwarekonfiguration entspricht. Dann ist/wird der Nichtübereinstimmungszustand beseitigt, bevor die Ausführung des Verfahrens gemäß dem Center-Befehl gestartet ist/wird. Mit anderen Worten, die Steuereinheit 49 sendet, als Antwort auf den Center-Befehl, die SWID, deren Softwarekonfiguration sich geändert hat, an das Center 1 und beseitigt, falls erforderlich, den Nichtübereinstimmungszustand.
16 ist ein Flussdiagramm, das den Verfahrensablauf gemäß der dritten Ausführungsform veranschaulicht. 16 zeigt nur das Verfahren, das von dem OTA-Master 31 durchgeführt wird. In 16 bestimmt die Steuereinheit 49 zunächst in Schritt S51, ob ein Center-Befehl empfangen worden ist. Dieser Schritt ist ähnlich wie Schritt S31. Wenn die Steuereinheit 49 in Schritt S51 bestimmt, dass ein Center-Befehl empfangen worden ist (JA in Schritt S51), fährt die Routine mit Schritt S52 fort. Die Steuereinheit 49 bestimmt dann in Schritt S52, ob eine Änderung in der Softwarekonfiguration der in dem Fahrzeug installierten Steuereinheit-Software stattgefunden hat. Dieser Schritt ist ähnlich wie der in 12 gezeigte Schritt S1. Wenn die Steuereinheit 49 in Schritt S52 bestimmt, dass keine Änderung in der Softwarekonfiguration aufgetreten ist (NEIN in Schritt S52), fährt die Routine mit Schritt S55 fort, der später beschrieben wird.
Wenn andererseits die Steuereinheit 49 in Schritt S52 bestimmt, dass eine Änderung in der Softwarekonfiguration stattgefunden hat (JA in Schritt S52), fährt die Routine mit Schritt S53 fort. In Schritt S53 bestimmt die Steuereinheit 49, ob die SWID, deren Softwarekonfiguration sich geändert hat (die Steuereinheit-Software, die der SWID entspricht, deren Softwarekonfiguration sich geändert hat), in der wie durch den Center-Befehl angegeben zu aktualisierenden SWID enthalten ist. Wenn die Steuereinheit 49 in Schritt S53 bestimmt, dass die SWID, deren Softwarekonfiguration sich geändert hat, in der wie durch den Center-Befehl angegeben zu aktualisierenden SWID enthalten ist, führt die Steuereinheit 49 ein Aktualisierungsverfahren basierend auf dem Center-Befehl durch. Wenn andererseits die Steuereinheit 49 in Schritt S53 bestimmt, dass die SWID, deren Softwarekonfiguration sich geändert hat, nicht in der wie durch den Center-Befehl angegeben zu aktualisierenden SWID enthalten ist, führt die Steuereinheit 49 eine separate Steuerung aus, um ein Verfahren zur Beseitigung des Nichtübereinstimmungszustands durchzuführen. Insbesondere, wenn die SWID, deren Softwarekonfiguration sich geändert hat, nicht in der wie durch den Center-Befehl angegeben zu aktualisierenden SWID enthalten ist (NEIN in Schritt S53), fährt die Routine mit Schritt S54 fort. In Schritt S54 führt die Steuereinheit 49 das Verfahren der Beseitigung des Nichtübereinstimmungszustands durch. Das heißt, die Steuereinheit 49 beseitigt den Nichtübereinstimmungszustand, indem sie ein solches Verfahren wie in der ersten Ausführungsform beschrieben durchführt. Die Routine fährt dann mit Schritt S55 fort.
Wenn andererseits die Steuereinheit 49 in Schritt S53 bestimmt, dass die SWID, deren Softwarekonfiguration sich geändert hat, in der wie durch den Center-Befehl angegeben zu aktualisierenden SWID enthalten ist (JA in Schritt S53), fährt die Routine mit Schritt S55 fort. In Schritt S55 führt die Steuereinheit 49 das Aktualisierungsverfahren basierend auf dem Center-Befehl durch. Das heißt, die Steuereinheit 49 führt ein solches Verfahren wie oben in der zweiten Ausführungsform beschrieben durch, um die wie durch den Center-Befehl angegeben zu aktualisierende Steuereinheit-Software zu aktualisieren. Die Steuereinheit 49 beendet dann das Aktualisierungssteuerungsverfahren gemäß der dritten Ausführungsform.
Wenn andererseits die Steuereinheit 49 in Schritt S51 bestimmt, dass kein Center-Befehl empfangen worden ist (NEIN in Schritt S51), fährt die Routine mit Schritt S56 fort. Die Steuereinheit 49 bestimmt dann in Schritt S56, ob eine Änderung in der Softwarekonfiguration der in dem Fahrzeug installierten Steuereinheit-Software stattgefunden hat. Dieser Schritt ist ähnlich wie Schritt S31. Wenn die Steuereinheit 49 in Schritt S56 bestimmt, dass eine Änderung in der Softwarekonfiguration aufgetreten ist (JA in Schritt S56), führt die Steuereinheit 49 das Verfahren der Beseitigung des Nichtübereinstimmungszustands in Schritt S57 durch. Das heißt, wie in Schritt S54, beseitigt die Steuereinheit 49 den Nichtübereinstimmungszustand, indem sie ein solches Verfahren durchführt, wie in der ersten Ausführungsform beschrieben.
Wenn die Steuereinheit 49 hingegen in Schritt S56 bestimmt, dass keine Änderung in der Softwarekonfiguration stattgefunden hat (NEIN in Schritt S56), beendet die Steuereinheit 49 das Aktualisierungssteuerungsverfahren gemäß der dritten Ausführungsform.
Wie oben beschrieben, werden in der dritten Ausführungsform, wenn eine Änderung in der Softwarekonfiguration bei dem Empfang des Center-Befehls aufgetreten ist, Informationen über die SWID, in der die Änderung aufgetreten ist, an das Center 1 gesendet. Daher kann das Verfahren der Beseitigung des Nichtübereinstimmungszustands auch durchgeführt werden, wenn das auf dem Center-Befehl basierende Verfahren durchgeführt wird. Auf diese Weise wird es möglich zu vermeiden, dass die Verfahren getrennt durchgeführt werden. Außerdem kann der Nichtübereinstimmungszustand schnell beseitigt werden.
Abwandlungen
Ein Beispiel, bei dem in dem Falle einer Notfallaktualisierung ein Center-Befehl über die SMS usw. gesendet wird, ist in der zweiten Ausführungsform dargestellt. Die vorliegende Offenbarung ist jedoch nicht darauf beschränkt, und es kann auch ein anderer Center-Befehl als ein Center-Befehl, um eine Notfallaktualisierung zu adressieren, gesendet werden. Beispielsweise kann in einer anderen Ausführungsform ein Center-Befehl mit/einschließlich der Anweisung, nur die Information(en) über die SWID, deren Softwarekonfiguration sich geändert hat, an das Center 1 zu senden, gesendet werden. In diesem Fall kann die Steuereinheit 49 des OTA-Masters 31 den SWID-Hashwert der SWID, deren Softwarekonfiguration sich geändert hat, berechnen und den berechneten SWID-Hashwert senden, gemäß der Anweisung des Center-Befehls an das Center 1. Das heißt, der Center-Befehl kann gesendet werden, um ein solches Verfahren der Beseitigung des Nichtübereinstimmungszustands, wie in der ersten Ausführungsform dargestellt, zu starten.
Was den Center-Befehl betrifft, so kann ein solcher Center-Befehl, nur die Information(en) über die SWID, deren Softwarekonfiguration sich geändert hat, an das Center 1 zu senden, wie oben beschrieben, auch in dem folgenden Fall gesendet werden. Zum Beispiel wird hier angenommen, dass eine Änderung in der Softwarekonfiguration einer vorbestimmten SWID aufgrund des Austauschs einer Steuereinheit in dem Fahrzeug aufgetreten ist, und der OTA-Master 31 aus irgendeinem Grund von dieser Änderung nichts weiß, aber das Center 1 von dieser Änderung weiß. Beispielsweise kann das Center 1 von einer solchen Änderung wissen, wenn Informationen über den Inhalt des Steuereinheitsaustauschs von einer Wartungswerkstatt an das Center 1 nach Abschluss des Steuereinheitsaustauschs gesendet werden. In einem solchen Fall kann das Center 1 die SWID, in der die Änderung für das Fahrzeug, für das der Steuereinheitsaustausch durchgeführt worden ist, aufgetreten ist (oder aufgetreten sein könnte), identifizieren. Daher kann, um ein solches Verfahren wie in der ersten Ausführungsform veranschaulicht in diesem Fall durchzuführen, ein Center-Befehl mit/einschließlich einer Anweisung, Information(en) über die der ausgetauschten Steuereinheit zugehörige SWID an das Center 1 zu senden, an den OTA-Master 31 gesendet werden.
In der ersten Ausführungsform wird, wenn eine Änderung der Softwarekonfiguration auftritt, der dieser Änderung zugehörige SWID-Hashwert an das Center 1 gesendet. In der zweiten und dritten Ausführungsform wird ein vorbestimmter SWID-Hashwert an das Center 1 als Antwort auf den Center-Befehl gesendet. In einer anderen Ausführungsform kann das folgende Verfahren durchgeführt werden, um einen solchen SWID-Hashwert zu senden. Das heißt, der SWID-Hashwert kann an das Center 1 bei Empfang einer Anfrage für ein normales Aktualisierungsverfahren in dem OTA-Dienst gesendet werden. In dem Aktualisierungsverfahren in dem OTA-Dienst stellt der OTA-Master 31 in der Regel periodisch, z. B. alle zwei Wochen, eine Anfrage an das Center 1, ob eine Aktualisierung vorliegt. Im Zuge dieser Anfrage wird der Gesamthashwert gesendet. Wenn es bestimmt wird, dass die Gesamthashwerte nicht übereinstimmen, werden die Versionsinformationen aller Steuereinheit-Software-Teile angefordert. Anstelle eines solchen Gesamthashwertes können auch die SWID-Hashwerte der in einem vorbestimmten Fahrzeug installierten SWIDs an das Center 1 gesendet werden. Das Center 1 kann ein Prüfverfahren für jede SWID durchführen und die Detailinformation(en) nur für die SWID, die aktualisiert werden muss, anfordern. Auch in diesem Fall kann die Zeit, die für den Abschluss des Aktualisierungsverfahrens benötigt wird, reduziert werden.
Obwohl Ausführungsformen der Technik der vorliegenden Offenbarung oben beschrieben sind, kann die vorliegende Offenbarung nicht nur als ein OTA-Master aufgefasst werden, sondern auch als ein Aktualisierungssteuerungsverfahren, das von einem Computer eines OTA-Masters durchgeführt wird, wobei der Computer zumindest einen Prozessor und einen Speicher aufweist und eingerichtet ist, um mit einem OTA-Center über ein Netzwerk zu kommunizieren; ein Steuerungsprogramm des Aktualisierungssteuerungsverfahrens; ein computerlesbares nicht-transitorisches Speichermedium, das das Steuerungsprogramm speichert, etc. Der OTA-Master kann einen oder mehrere Prozessoren enthalten.
Die Technik der vorliegenden Offenbarung kann für einen OTA-Master verwendet werden, der eine Software-Aktualisierungsfunktion steuert.
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

JP 2020004245 A [0002]

Claims

Over-the-Air (OTA)-Master, der eingerichtet ist, um eine oder mehrere Software(s) auf einer fahrzeuginternen Vorrichtung zu aktualisieren, wobei der OTA-Master eingerichtet ist, um eine Verbindung zu einem fahrzeuginternen Netzwerk mit der fahrzeuginternen Vorrichtung herzustellen und mit einem OTA-Center über ein Netzwerk zu kommunizieren, wobei der OTA-Master hat: eine Konfigurationsinformationserfassungseinheit (49), die eingerichtet ist, um aus Softwaregruppen, die jeweils aus einer Kombination der Software der fahrzeuginternen Vorrichtung bestehen, Konfigurationsinformationen über eine Softwaregruppe, in der eine Änderung in einer Konfiguration der Kombination der Software aufgetreten ist, zu erfassen; und eine Übertragungseinheit (48), die eingerichtet ist, um die erfassten Konfigurationsinformationen an das OTA-Center zu senden.
OTA-Master nach Anspruch 1, wobei die Konfigurationsinformationserfassungseinheit (49) eingerichtet ist, um: zu bestimmen, ob die Änderung in der Konfiguration der Kombination der Software vor und nach einem vorbestimmten Zeitpunkt aufgetreten ist; und, wenn die Änderung aufgetreten ist, die Konfigurationsinformationen über die Softwaregruppe, in der die Änderung aufgetreten ist, zu erfassen.
OTA-Master nach Anspruch 1 ferner mit: einer Center-Befehl-Empfangseinheit, welche eingerichtet ist, von dem OTA-Center einen Center-Befehl, der einen Befehl, Konfigurationsinformationen über eine vorbestimmte Softwaregruppe zu senden, aufweist, zu empfangen, wobei die Konfigurationsinformationserfassungseinheit (49) eingerichtet ist, um, wenn die Center-Befehl-Empfangseinheit (49) den Center-Befehl empfangen hat, die Konfigurationsinformationen über die Softwaregruppe, in der die Änderung in der Konfiguration der Kombination der Software aufgetreten ist, zu erfassen.
OTA-Master nach Anspruch 3, wobei der Center-Befehl einen Befehl, die Konfigurationsinformationen über die Softwaregruppe, in der die Änderung in der Konfiguration der Kombination der Software aufgetreten ist, zu senden, aufweist.
Aktualisierungssteuerungsverfahren, das von einem Computer eines OTA-Masters, der eingerichtet ist, um mit einem OTA-Center über ein Netzwerk zu kommunizieren, durchgeführt wird, wobei der OTA-Master einen oder mehrere Prozessoren (49) und einen Speicher aufweist, wobei das Aktualisierungssteuerungsverfahren umfasst: Erfassen von Konfigurationsinformationen über eine Softwaregruppe, in der eine Änderung in einer Konfiguration der Kombination der Software aufgetreten ist, aus Softwaregruppen, die jeweils aus einer Kombination von Software einer fahrzeuginternen Vorrichtung bestehen; und Senden der erfassten Konfigurationsinformationen an das OTA-Center.
Nicht-transitorisches Speichermedium, das Befehle, die von einem oder mehreren Computern eines OTA-Masters ausgeführt werden können und die den einen oder die mehreren Computer veranlassen, Funktionen auszuführen, speichert, wobei der OTA-Master einen oder mehrere Prozessoren (49) und einen Speicher aufweist und der OTA-Master eingerichtet ist, um mit einem OTA-Center über ein Netzwerk zu kommunizieren, wobei die Funktionen umfassen: Erfassen von Konfigurationsinformationen über eine Softwaregruppe, in der eine Änderung in einer Konfiguration der Kombination der Software aufgetreten ist, aus Softwaregruppen, die jeweils aus einer Kombination von Software einer fahrzeuginternen Vorrichtung bestehen; und Senden der erfassten Konfigurationsinformationen an das OTA-Center.