DE102021129232A1

DE102021129232A1 - Center, managementverfahren und nicht-transitorisches speichermedium

Info

Publication number: DE102021129232A1
Application number: DE102021129232.8A
Authority: DE
Inventors: Yoshikazu Sakai
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2021-01-14
Filing date: 2021-11-10
Publication date: 2022-07-14
Also published as: US20220222055A1; JP2022109037A; US11847439B2; CN114764339A; US20240069903A1

Abstract

Center (1), das so konfiguriert ist, dass es mit einem OTA-Master (11) kommuniziert, der so konfiguriert ist, dass er eine Softwareaktualisierung einer Vielzahl von elektronischen Steuereinheiten (13a, 13b, 13c, 13d) steuert, die in einem Fahrzeug installiert sind, weist auf: eine Kommunikationseinheit (27), die so konfiguriert ist, dass sie vom OTA-Master (11) Identifikationsinformationen empfängt; eine Speichereinheit (26), die Korrektheit-Bestimmungsinformationen speichert, die bei einer Korrektheit-Bestimmung verwendet werden, um zu bestimmen, ob die Version der in jeder der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementierten Software eine Implementierungsmanagementversion ist; eine Bestimmungseinheit (28), die so konfiguriert ist, dass sie die Korrektheit-Bestimmung auf der Grundlage der Identifikationsinformation und der Korrektheit-Bestimmungsinformation durchführt; und eine Steuereinheit (29), die so konfiguriert ist, dass sie durch Kommunikation mit dem OTA-Master (11) eine Wiederherstellungssteuerung für zumindest eine der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) durchführt, für die bestimmt wurde, dass die Softwareversion nicht die Implementierungsmanagementversion ist.

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Offenbarung bezieht sich auf ein Center, ein Managementverfahren und ein nicht-transitorisches Speichermedium.
2. Beschreibung des Standes der Technik
Es gibt eine Vielzahl von elektronischen Steuereinheiten (ECUs), die in Fahrzeugen installiert sind, um den Betrieb des Fahrzeugs zu steuern. Eine ECU ist mit einem Prozessor, einer transitorischen Steuereinheit, wie z.B. einem Direktzugriffsspeicher (RAM), und einer nicht-flüchtigen Speichereinheit, wie z.B. einem Festwertspeicher (ROM), versehen, wobei der Prozessor eine Software ausführt, die in der nicht-flüchtigen Speichereinheit gespeichert ist, wodurch Steuerfunktionen der ECU realisiert werden. Die in jeder ECU gespeicherte Software ist überschreibbar und die Aktualisierung auf eine neuere Softwareversion ermöglicht es, die Funktionen der ECUs zu verbessern, neue Fahrzeugsteuerfunktionen hinzuzufügen, usw.
Die Over-the-Air (OTA)-Technologie ist als eine (Funk-)Technologie zur Aktualisierung der Software von ECUs bekannt. Bei OTA sind die Kommunikationsausrüstung im Fahrzeug, die mit einem Netzwerk im Fahrzeug (Fahrzeugnetzwerk) verbunden ist, und ein Kommunikationsnetzwerk, wie z.B. das Internet oder ähnliches, drahtlos verbunden, wird eine Software von einem OTA-Center (kann einfach als „Center“ (Zentrale) bezeichnet werden) über drahtlose Kommunikation heruntergeladen und wird die heruntergeladene Software installiert, wodurch ECU-Programme aktualisiert or hinzugefügt werden (siehe z.B. die JP 2004 - 326 689 A ).
Nach der Registrierung einer Aktion, die einem Ereignis für die Durchführung einer Softwareaktualisierung in einem Server entspricht, wird die Softwareaktualisierung durch OTA durchgeführt, ausgelöst durch das Fahrzeug, das eine Bestätigung anfordert, ob es Aktualisierungsdaten im OTA-Center gibt. Wenn es eine Aktion gibt, führt das Fahrzeug sequentiell / nacheinander das Herunterladen der Aktualisierungsdaten, die Installation der Aktualisierungsdaten und die Aktivierung der aktualisierten Softwareversion durch, wodurch die Software einer Ziel-ECU, die ein Aktualisierungs-Ziel-ECU ist, aktualisiert wird.
ZUSAMMENFASSUNG DER ERFINDUNG
Wenn eine ECU eines Fahrzeugs ausgetauscht wird (Teileaustausch), kann sich die Softwareversion, die in der ECU nach dem Austausch implementiert ist, von der Softwareversion unterscheiden, die in der ECU vor dem Austausch implementiert war. Bei Kombinationen von Softwareversionen mehrerer im Fahrzeug installierter ECUs gibt es Fälle, in denen Kombinationen existieren, bei denen die Möglichkeit besteht, dass das Fahrzeug nicht ordnungsgemäß funktioniert (nicht-konforme Versionskombinationen), und wenn eine ECU ausgetauscht / ersetzt wird und die Versionskombination nicht-konform ist, muss das Problem angegangen werden.
Die vorliegende Offenbarung stellt ein Center (Zentrale), ein Managementverfahren und ein nicht-transitorisches Speichermedium zur Verfügung, durch das die Versionen der in einer ECU implementierten Software vor und nach dem Austausch der ECU gleich / identisch zueinander gemacht werden können.
Ein Center gemäß einem ersten Aspekt der vorliegenden Offenbarung ist so konfiguriert, dass es über ein Netzwerk mit einem Over-the-Air (OTA)-Master kommuniziert, der so konfiguriert ist, dass er die Softwareaktualisierung einer Vielzahl von in einem Fahrzeug installierten elektronischen Steuereinheiten steuert. Das Center weist auf: eine Kommunikationseinheit, die so konfiguriert ist, dass sie von dem OTA-Master Identifikationsinformationen empfängt, die eine Version der in jeder der elektronischen Steuereinheiten implementierten Software angeben; eine Speichereinheit, die Korrektheit-Bestimmungsinformationen speichert, die bei einer Korrektheit-Bestimmung verwendet werden, um zu bestimmen, ob die Version der in jeder der elektronischen Steuereinheiten implementierten Software eine Implementierungsmanagementversion ist, die eine Version der zu implementierenden Software ist; eine Bestimmungseinheit, die so konfiguriert ist, dass sie die Korrektheit-Bestimmung auf der Grundlage der Identifikationsinformation und der Korrektheit-Bestimmungsinformation durchführt; und eine Steuereinheit, die so konfiguriert ist, dass sie durch Kommunikation mit dem OTA-Master eine Wiederherstellungssteuerung für zumindest eine der elektronischen Steuereinheiten durchführt, bezüglich derer die Bestimmungseinheit eine Bestimmung getroffen hat, dass die Softwareversion nicht die Implementierungsmanagementversion ist, wobei die Wiederherstellungssteuerung eine Steuerung für das Zurücksetzen der Softwareversion auf die Implementierungsmanagementversion ist.
Ein Managementverfahren gemäß einem zweiten Aspekt der vorliegenden Offenbarung wird von einem Computer ausgeführt, der einen Prozessor, einen Speicher und eine Kommunikationsvorrichtung aufweist, die so konfiguriert ist, dass sie über ein Netzwerk mit einem Over-the-Air (OTA)-Master kommuniziert, der so konfiguriert ist, dass er die Softwareaktualisierung einer Vielzahl von in einem Fahrzeug installierten elektronischen Steuereinheiten steuert. Das Managementverfahren weist die Schritte auf: Empfangen von Identifikationsinformationen, die eine Softwareversion angeben, die in jeder der elektronischen Steuereinheiten implementiert ist, von dem OTA-Master; Speichern von Korrektheit-Bestimmungsinformationen, die bei der Korrektheit-Bestimmung verwendet werden, um zu bestimmen, ob die Softwareversion, die in jeder der elektronischen Steuereinheiten implementiert ist, eine Implementierungsmanagementversion ist, die eine Version von zu implementierender Software ist; Durchführen der Korrektheit-Bestimmung basierend auf der Identifikationsinformation und der Korrektheit-Bestimmungsinformation; und Durchführen der Wiederherstellungssteuerung durch Kommunikation mit dem OTA-Master für zumindest eine der elektronischen Steuereinheiten, bezüglich derer bei der Korrektheit-Bestimmung bestimmt wurde, dass die Softwareversion nicht die Implementierungsmanagementversion ist, wobei die Wiederherstellungssteuerung die Steuerung für das Zurücksetzen der Softwareversion auf die Implementierungsmanagementversion ist.
Ein Steuerungsprogramm gemäß einem dritten Aspekt der vorliegenden Offenbarung speichert ein Steuerungsprogramm, das von einem Computer ausgeführt werden kann, der einen Prozessor, einen Speicher und eine Kommunikationsvorrichtung aufweist, die über ein Netzwerk mit einem Over-the-Air (OTA)-Master kommunizieren kann, der eine Softwareaktualisierung einer Vielzahl von in einem Fahrzeug installierten elektronischen Steuereinheiten steuert, und das den Computer veranlasst, Funktionen auszuführen, die Folgendes aufweisen: Empfangen von Identifikationsinformationen, die eine Softwareversion angeben, die in jeder der elektronischen Steuereinheiten implementiert ist, von dem OTA-Master; Speichern von Korrektheit-Bestimmungsinformationen, die bei der Korrektheit-Bestimmung verwendet werden, um zu bestimmen, ob die Softwareversion, die in jeder der elektronischen Steuereinheiten implementiert ist, eine Implementierungsmanagementversion ist, die eine Softwareversion ist, die implementiert werden soll; Durchführen der Korrektheit-Bestimmung basierend auf der Identifikationsinformation und der Korrektheit-Bestimmungsinformation; und Durchführen einer Wiederherstellungssteuerung durch Kommunikation mit dem OTA-Master für zumindest eine der elektronischen Steuereinheiten, bezüglich derer bei der Korrektheit-Bestimmung bestimmt wurde, dass die Softwareversion nicht die Implementierungsmanagementversion ist, wobei die Wiederherstellungssteuerung eine Steuerung für das Zurücksetzen der Softwareversion auf die Implementierungsmanagementversion ist.
Gemäß der vorliegenden Offenbarung können ein Center, ein Managementverfahren und ein nicht-transitorisches Speichermedium bereitgestellt werden, mit denen die Versionen der in einer ECU implementierten Software vor und nach dem Austausch der ECU gleich / identisch zueinander gemacht werden können.
Figurenliste
Merkmale, Vorteile und technische und industrielle Bedeutung von beispielhaften Ausführungsformen der Erfindung werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen gleiche Bezugszeichen gleiche Elemente bezeichnen, und wobei:

1 ein Blockdiagramm ist, das ein Beispiel für eine Gesamtkonfiguration eines Netzwerksystems gemäß einer ersten Ausführungsform darstellt;
2 ein Blockdiagramm ist, das ein Beispiel für eine schematische Konfiguration eines in 1 dargestellten OTA-Centers zeigt;
3 ein Blockdiagramm ist, das ein Beispiel für eine schematische Konfiguration eines in 1 dargestellten OTA-Masters zeigt;
4 ein Blockdiagramm ist, das Beispiele für schematische Konfigurationen der in 1 dargestellten ECUs zeigt;
5 ein funktionelles Blockdiagramm ist, das ein Beispiel für den in 1 dargestellten OTA-Center zeigt;
6 ein funktionelles Blockdiagramm ist, das ein Beispiel für den in 1 dargestellten OTA-Master zeigt;
7 ein Flussdiagramm ist, das ein Beispiel für einen Steuerprozess zeigt, der vom OTA-Master gemäß der ersten Ausführungsform ausgeführt wird;
8 ein Diagramm zur Beschreibung eines Beispiels von konformen Konfigurationsinformationen ist, die im Voraus in dem in 5 dargestellten OTA-Center abgespeichert wurden;
9 ein Diagramm zur Beschreibung eines Beispiels von Historieninformation ist, die in dem in 5 dargestellten OTA-Center gespeichert ist;
10 ein Diagramm zur Beschreibung eines Beispiels von Historieninformation ist, die in dem in 5 dargestellten OTA-Center gespeichert ist;
11 ein Flussdiagramm ist, das ein Beispiel des in 7 dargestellten Rollback-Prozesses zeigt; und
12 ein Flussdiagramm ist, das ein Beispiel für einen Steuerprozess zeigt, der von einem OTA-Master gemäß einer zweiten Ausführungsform ausgeführt wird.

DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Erste Ausführungsform
1 ist ein Blockdiagramm, das ein Beispiel für eine Gesamtkonfiguration eines Netzwerksystems gemäß einer ersten Ausführungsform darstellt. 2 ist ein Blockdiagramm, das ein Beispiel für eine schematische Konfiguration eines in 1 dargestellten OTA-Centers zeigt. 3 ist ein Blockdiagramm, das ein Beispiel für eine schematische Konfiguration eines in 1 dargestellten OTA-Masters zeigt. 4 ist ein Blockdiagramm, das Beispiele für schematische Konfigurationen der in 1 dargestellten ECUs veranschaulicht.
Das in 1 dargestellte Netzwerksystem ist ein System zur Aktualisierung der Software einer Vielzahl von ECUs 13a bis 13d, die in einem Fahrzeug installiert sind. Das Netzwerksystem ist mit einem OTA-Center (z.B. einem Server, wird vereinfacht als „Center“ bezeichnet) 1 und einem im Fahrzeug installierten Fahrzeugnetzwerk 2 versehen.
Das OTA-Center 1 ist in der Lage, mit einem im Fahrzeug installierten OTA-Master 11 drahtlos oder dergleichen über ein Kommunikationsnetzwerk 5, wie z.B. das Internet oder dergleichen, zu kommunizieren, und steuert die Aktualisierung der Software der im Fahrzeug installierten ECUs 13a bis 13d.
Wie in 2 dargestellt, ist das OTA-Center 1 mit einer zentralen Verarbeitungseinheit (CPU) 21, einem Arbeitsspeicher (RAM) 22, einer Steuervorrichtung 23 und einer Kommunikationsvorrichtung 24 versehen. Die Steuervorrichtung 23 ist mit einem lesbaren/schreibbaren Speichermedium, wie bspw. einer Festplatte, einem Solid-State-Laufwerk (SSD) oder ähnlichem, versehen und speichert Programme zur Ausführung einer Software-Aktualisierungssteuerung, bei einer Aktualisierungssteuerung verwendete Informationen und Aktualisierungsdaten für ECUs. Die CPU 21 führt aus der Steuervorrichtung 23 ausgelesene Programme unter Verwendung des RAMs 22 als einen Arbeitsbereich aus und führt damit einen Steuerprozess durch. Die Kommunikationsvorrichtung 24 führt die Kommunikation mit dem OTA-Master 11 über das Kommunikationsnetzwerk 5 durch.
Wie in 1 dargestellt, ist das Fahrzeugnetzwerk 2 mit dem OTA-Master 11, einem Kommunikationsmodul 12, den ECUs 13a bis 13d und einem Mensch-Maschine-Interface (HMI) 14 versehen, das beispielsweise eine Anzeigevorrichtung eines Kfz-Navigationssystems ist, die in der Lage ist, Eingabebetätigungen entgegenzunehmen. Der OTA-Master 11 ist über einen Bus 15a mit dem Kommunikationsmodul 12, über einen Bus 15b mit den ECUs 13a und 13b, über einen Bus 15c mit den ECUs 13c und 13d und über einen Bus 15d mit dem HMI 14 verbunden. Der OTA-Master 11 ist in der Lage, über das Kommunikationsmodul 12 drahtlos mit dem OTA-Center 1 zu kommunizieren. Der OTA-Master 11 steuert auf der Grundlage der vom OTA-Center 1 erhaltenen Aktualisierungsdaten die Softwareaktualisierung einer der ECUs 13a bis 13d, deren Software Ziel der Aktualisierung ist (kann als „Ziel-ECU“ bezeichnet werden). Das Kommunikationsmodul 12 ist eine Kommunikationsausrüstung, die das Fahrzeugnetzwerk 2 und das OTA-Center 1 verbindet. Die ECUs 13a bis 13d steuern die Betätigungen der Fahrzeugteile. Bei der Durchführung von Aktualisierungsvorgängen der Software der ECUs 13a bis 13d wird das HMI 14 für verschiedene Arten von Anzeigen verwendet, wie z. B. die Anzeige, dass Aktualisierungsdaten vorhanden sind, die Anzeige eines Zustimmungs-Anfrage-Bildschirms zur Aufforderung an einen Benutzer oder Administrator, einer Softwareaktualisierung zuzustimmen, die Anzeige der Ergebnisse der Aktualisierung, usw. Es ist zu beachten, dass, obwohl in 1 vier ECUs 13a bis 13d beispielhaft dargestellt sind, die Anzahl der ECUs nicht begrenzt ist.
Wie in 4 dargestellt, sind die ECUs 13 (13a bis 13d) jeweils mit einer CPU 41, einem RAM 42, einem nichtflüchtigen Speicher 43 und einer Kommunikationsvorrichtung 45 versehen. Die CPU 41 führt Software (Programme) aus, die aus dem nichtflüchtigen Speicher 43 (Datenspeicherbereich 44 (44a, 44b und 44c)) unter Verwendung des RAMs 42 als einen Arbeitsbereich ausgelesen werden, und kommuniziert außerdem mit anderen Vorrichtungen über einen Bus, sofern erforderlich, unter Verwendung der Kommunikationsvorrichtung 45, wodurch die Funktionen der ECU 13 realisiert werden.
Es gibt zwei Arten von ECUs 13, von denen die eine eine Einzelbank-Speicher-ECU (linkes Blockdiagramm in 4) ist, die einen Datenspeicherbereich (Bank) 44a zum Speichern von Software hat, und die andere eine Doppelbank-Speicher-ECU (rechtes Blockdiagramm in 4) ist, die zwei Datenspeicherbereiche (Bänke) 44b und 44c zum Speichern von Software hat. Es gibt Fälle, in denen der Datenspeicherbereich 44 der ECU 13 zusätzlich zur Software für die Realisierung von Funktionen der ECU Versionsinformationen und Parameterdaten, ein Boot-Programm für das Starten / das Hochfahren, Programme für die Softwareaktualisierung und so weiter speichert. In einer Einzelbank-Speicher-ECU wirkt sich das Installieren von Aktualisierungsdaten im Datenspeicherbereich 44a und das anschließende Aktivieren (Freigeben) der Aktualisierungsdaten auf die Software der ECU aus. Andererseits dient in einer Doppelbank-Speicher-ECU einer von zwei Datenspeicherbereichen (44b, 44c) als Speicherbereich, der das Ziel des Lesens ist (aktive Bank), und Software, die in dem Speicherbereich gespeichert ist, der das Ziel des Lesens ist, wird ausgeführt. Aktualisierte Daten können im Hintergrund in den anderen Speicherbereich geschrieben werden, der nicht das Ziel des Lesens (nicht-aktive Bank) ist, während Programme in dem Speicherbereich, der das Ziel des Lesens (aktive Bank) ist, ausgeführt werden. Beim Aktivieren des Software-Aktualisierungsprozesses wird der Speicherbereich, aus dem die CPU 41 die Programme ausliest, gewechselt, wodurch die Aktualisierungs-Softwareversion aktiviert (freigegeben) werden kann. In einer Einzelbank-Speicher-ECU und einer Doppelbank-Speicher-ECU kann ein Zustand, in dem die Aktivierung der Software abgeschlossen ist und die ECU bei dieser Software arbeiten kann, als ein Zustand bezeichnet werden, in dem diese Software in der ECU implementiert ist.
Man beachte, dass in der vorliegenden Offenbarung ECUs mit Doppelbank-Speicher-ECUs ECUs mit Speicher einer Konfiguration umfassen, die als „Einzelbank-Suspended-Memory“ bezeichnet wird, bei der eine Bank des Datenspeicherbereichs, den der nichtflüchtige Speicher hat, virtuell in zwei Bänke unterteilt ist, und während Programme einer Bank ausgeführt werden, Programme in die andere Bank geschrieben werden können, und auch ECUs, die zusätzlich zum nichtflüchtigen Speicher, der eine Bank im Datenspeicherbereich hat, einen erweiterten nichtflüchtigen Speicher haben, der eine Bank im Datenspeicherbereich hat, und diese zwei Bänke des nichtflüchtigen Speichers können als eine aktive Bank und eine nicht-aktive Bank verwendet werden.
Wie in 3 dargestellt, ist der OTA-Master 11 mit einem Mikrocomputer 35 versehen, der eine CPU 31, einen RAM 32, einen ROM 33 und eine Steuervorrichtung 34 sowie eine Kommunikationsvorrichtung 36 aufweist. Die CPU 31 führt aus dem ROM 33 ausgelesene Programme aus, wobei sie den RAM 32 als einen Arbeitsbereich nutzt und dadurch einen Steuerprozess durchführt. Die Kommunikationsvorrichtung 36 führt die Kommunikation mit dem Kommunikationsmodul 12, den ECUs 13a bis 13d und dem HMI 14 über die in 1 dargestellten Busse 15a bis 15d durch.
Der Software-Aktualisierungsprozess weist nun eine Phase des Herunterladens von Aktualisierungsdaten vom OTA-Center 1, eine Phase des Übertragens der heruntergeladenen Aktualisierungsdaten auf die Ziel-ECU, die Ziel der Aktualisierung ist, und eine Phase des Installierens der Aktualisierungsdaten im Speicherbereich der Ziel-ECUs und eine Phase des Aktivierens auf, in der die Aktualisierungsversion der auf der Ziel-ECU installierten Software aktiviert wird.
Das Herunterladen / Downloaden ist ein Prozess zum Empfangen von Aktualisierungsdaten, die vom OTA-Center 1 übertragen werden, um die Software der ECU zu aktualisieren, und zum Speichern der Aktualisierungsdaten in der Steuervorrichtung 34. Die Download-Phase hat neben dem Empfangen der Aktualisierungsdaten auch die Steuerung einer Reihe von Prozessen im Zusammenhang mit dem Download zum Inhalt, wie z.B. die Bestimmung, ob der Download ausgeführt werden kann, die Überprüfung der Aktualisierungsdaten, usw. Die Installation ist ein Prozess zum Schreiben eines Aktualisierungsversionsprogramms (Aktualisierungssoftware) in den nichtflüchtigen Speicher der Ziel-ECU, die Ziel der Aktualisierung ist, basierend auf den heruntergeladenen Aktualisierungsdaten. Die Installationsphase umfasst nicht nur die Ausführung der Installation, sondern umfasst auch die Steuerung einer Reihe von Prozessen im Zusammenhang mit der Installation, wie z.B. die Bestimmung, ob die Installation ausgeführt werden kann, die Übertragung der Aktualisierungsdaten, die Überprüfung des Aktualisierungsversionsprogramms, usw. Die Aktivierung ist ein Prozess zur Aktivierung (Freigabe) des installierten Aktualisierungsprogramms. Die Aktivierungsphase umfasst nicht nur die Ausführung der Aktivierung, sondern auch die Steuerung einer Reihe von Prozessen im Zusammenhang mit der Aktivierung, wie z. B. die Bestimmung, ob die Aktivierung ausgeführt werden kann, die Überprüfung der Ausführungsergebnisse, usw.
Die vom OTA-Center 1 an den OTA-Master 11 übertragenen Aktualisierungsdaten können eine Aktualisierungssoftware für ECUs, komprimierte Daten, in denen die Aktualisierungssoftware komprimiert wurde, und geteilte Daten, in denen die Aktualisierungssoftware oder komprimierte Daten geteilt wurden, enthalten. Außerdem können die Aktualisierungsdaten einen Identifikator (ID) zur Identifizierung der Ziel-ECU, die Ziel der Aktualisierung ist (ECU-ID), und einen Identifikator (ID) zur Identifizierung der Software vor der Aktualisierung (ECU-Software-ID) enthalten. Die Aktualisierungsdaten werden als ein Verteilungspaket heruntergeladen, und das Verteilungspaket enthält Aktualisierungsdaten von einer oder mehreren ECUs.
Wenn die Aktualisierungsdaten die Aktualisierungssoftware selbst aufweisen, überträgt der OTA-Master 11 die Aktualisierungsdaten (d.h. die Aktualisierungssoftware) in der Installationsphase auf die Ziel-ECU. Auch wenn die Aktualisierungsdaten komprimierte Daten, Differenzdaten oder geteilte Daten der Aktualisierungssoftware aufweisen, kann der OTA-Master 11 die Aktualisierungsdaten an die Ziel-ECU übertragen und die Ziel-ECU kann die Aktualisierungssoftware aus den Aktualisierungsdaten generieren, oder der OTA-Master 11 kann die Aktualisierungssoftware aus den Aktualisierungsdaten generieren und die Aktualisierungssoftware an das Ziel-ECU übertragen. Nun kann die Generierung der Aktualisierungssoftware durch Dekomprimierung von komprimierten Daten oder durch Zusammenstellen von Differenzdaten oder geteilten Daten erfolgen.
Die Installation der Aktualisierungssoftware kann in der Ziel-ECU auf Basis einer Installationsanforderung des OTA-Masters 11 erfolgen. Alternativ kann die Ziel-ECU, die die Aktualisierungsdaten erhalten hat, die Aktualisierungssoftware selbständig installieren, ohne eine ausdrückliche Anweisung vom OTA-Master 11 zu erhalten.
Die Aktivierung der Aktualisierungssoftware kann in der Ziel-ECU auf der Grundlage einer Aktivierungsanforderung vom OTA-Master 11 durchgeführt werden. Alternativ kann die Ziel-ECU, die die Aktualisierungsdaten erhalten hat, die Aktualisierungssoftware selbständig aktivieren, ohne eine explizite Anweisung vom OTA-Master 11 zu erhalten.
5 ist ein Beispiel für ein Funktionsblockdiagramm des in 1 dargestellten OTA-Centers 1. Wie in 5 dargestellt, ist das OTA-Center 1 mit einer Speichereinheit 26, einer Kommunikationseinheit 27, einer Bestimmungseinheit 28 und einer Steuereinheit 29 versehen. Die Kommunikationseinheit 27, die Bestimmungseinheit 28 und die Steuereinheit 29 werden von der in 2 dargestellten CPU 21 realisiert, die in der Steuervorrichtung 23 gespeicherten Programme unter Verwendung des RAM 22 ausführt. Die Speichereinheit 26 ist durch die in 2 dargestellte Steuervorrichtung 23 realisiert.
6 ist ein Beispiel für ein Funktionsblockdiagramm des in 1 dargestellten OTA-Masters 11. Wie in 6 dargestellt, ist der OTA-Master 11 mit einer Speichereinheit 37, einer Kommunikationseinheit 38 und einer Steuereinheit 39 versehen. Die Kommunikationseinheit 38 und die Steuereinheit 39 sind von der in 3 dargestellten CPU 31 realisiert, die die im ROM 33 gespeicherte Programme unter Verwendung des RAM 32 ausführt. Die Speichereinheit 37 ist durch die in 3 dargestellte Steuervorrichtung 34 realisiert.
7 ist ein Flussdiagramm, das ein Beispiel für den Steuerprozess zeigt, den das OTA-Center 1 gemäß der vorliegenden Ausführungsform durchführt. Der Steuerprozess gemäß der vorliegenden Ausführungsform wird im Folgenden unter Bezugnahme auf das in 7 dargestellte Flussdiagramm beschrieben.
Der in 7 dargestellte Prozess wird dadurch gestartet, dass die Kommunikationseinheit 27 von dem OTA-Master 11 übertragene Fahrzeugkonfigurationsinformationen empfängt.
Wenn nun vorbestimmte Bedingungen erfüllt sind (typischerweise die Erkennung des Einschaltens der Zündung des Fahrzeugs), erfasst der im Fahrzeug installierte OTA-Master 11 von jeder ECU aus allen ECUs des Fahrzeugs eine ECU-ID, die die Identifizierung des Typs der ECU ermöglicht, sowie eine ECU-Software-ID, die die Identifizierung des Typs und der Softwareversion (kann mit „SW“ abgekürzt werden) ermöglicht. Der OTA-Master 11 erzeugt dann Fahrzeugkonfigurationsinformationen, die die erfasste ECU-ID und ECU-Software-ID sowie eine Fahrzeugidentifikationsnummer (VIN) aufweisen, die die Identifizierung des Fahrzeugs ermöglicht, und überträgt die Fahrzeugkonfigurationsinformationen an den OTA-Center 1. Gemäß diesem Prozess werden beispielsweise jedes Mal, wenn die Zündung eingeschaltet wird, Fahrzeugkonfigurationsinformationen erzeugt und vom OTA-Master 11 an das OTA-Center 1 übertragen und dementsprechend kann das OTA-Center 1 die Hardwarekonfiguration und die Softwarekonfiguration der ECUs jedes Fahrzeugs nachvollziehen.
In Schritt S1 in 7 erfasst die Steuereinheit 29 die VIN und die ECU-Software-ID (Identifikationsinformation) aus den von der Kommunikationseinheit 27 empfangenen Fahrzeugkonfigurationsinformationen. Danach geht der Prozess zu Schritt S2 über.
In Schritt S2 bestimmt die Bestimmungseinheit 28, ob die Softwareversion in Bezug auf eine ECU, die in dem Fahrzeug installiert ist, das durch die in Schritt S1 erfasste Fahrgestellnummer angegeben ist, in unangemessener Weise geändert wurde. Dies wird im Folgenden detailliert beschrieben.
Die Speichereinheit 26 speichert Implementierungsmanagementversionsinformationen (Korrektheit-Bestimmungsinformationen), die die Softwareversionen angeben, die das OTA-Center 1 als in den ECUs der einzelnen Fahrzeuge implementiert steuert (im Folgenden als „Implementierungsmanagementversion“ bezeichnet). Mit anderen Worten ist die Implementierungsmanagementversionsinformation eine Information, die die Softwareversion angibt, die in der ECU implementiert sein sollte (Implementierungsmanagementversion). Die Implementierungsmanagementversionsinformation ist eine Information, die anzeigt, dass in einem Fahrzeug mit der VIN 1001 (ein Fahrzeug, in dem die ECU1 bis zur ECU4 installiert sind) zum Beispiel Software, die Software für ECU1 ist und die Version 2.2 hat, in ECU1 implementiert ist, Software, die Software für ECU2 ist und die Version 2. 4 hat, in der ECU2 implementiert ist, Software, die Software für die ECU3 ist und die Version 2.2 hat, in der ECU3 implementiert ist, und Software, die Software für die ECU4 ist und die Version 2.5 hat, in der ECU4 implementiert ist, was im Detail mit Bezug auf 9 beschrieben wird. Die Implementierungsmanagementversion- Informationen werden in geeigneter Weise aktualisiert. Wenn beispielsweise der OTA-Master 11 eine Aktualisierungssteuerung auf der Grundlage der von dem OTA-Center 1 übertragenen Aktualisierungsdaten der Software durchführt und die Software einer ECU aktualisiert (Versions-Aktualisierung) und der OTA-Master 11 eine Benachrichtigung über die abgeschlossene Aktualisierung an das OTA-Center 1 durchführt, wird die Implementierungsmanagementversionsinformation durch die Softwareversion nach der Aktualisierung aktualisiert.
In Schritt S2 vergleicht die Bestimmungseinheit 28 die Softwareversion, die durch die in Schritt S1 erfasste ECU-Software-ID (Identifikationsinformation) angegeben ist, mit der Implementierungsmanagementversion, die durch die in der Speichereinheit 26 gespeicherte Implementierungsmanagementversionsinformation angegeben ist, für jede der ECUs, die im Fahrzeug installiert sind, das die in Schritt S1 erfasste VIN angibt. Wenn die Softwareversion, die die ECU-Software-ID angibt, und die Implementierungsmanagementversion, die in den Implementierungsmanagementversions-Informationen angegeben ist, nicht übereinstimmen, stellt die Bestimmungseinheit 28 fest, dass die Softwareversion in unangemessener Weise geändert worden ist. Wenn nun eine in einem Fahrzeug installierte ECU ausgetauscht wird (Teileaustausch), stimmen die Softwareversion, die die ECU-Software-ID angibt, und die in den Implementierungsmanagementversions-Informationen angegebene Implementierungsmanagementversion, wie oben beschrieben, oft nicht mehr überein, und in einem solchen Fall stellt die Bestimmungseinheit 28 fest, dass die Softwareversion in unangemessener Weise geändert wurde. Daraufhin geht der Prozess zu Schritt S3 über.
In Schritt S3 fährt, wenn in Schritt S2 bestimmt wurde, dass die Softwareversion in unangemessener Weise geändert wurde (die Softwareversion wurde in unangemessener Weise geändert), die Steuereinheit 29 den Prozess mit Schritt S4 fort und beendet andernfalls den Prozess von 7.
In Schritt S4 bestimmt die Bestimmungseinheit 28 die Übereinstimmung zwischen den Softwareversionen für die ECUs, die in dem Fahrzeug installiert sind, das durch die in Schritt S1 erfasste Fahrgestellnummer angegeben ist (die Angemessenheit / Geeignetheit der Versionskombination). Dies wird im Folgenden detailliert beschrieben.
8 ist ein Diagramm zur Beschreibung von konformen Konfigurationsinformationen, die alle konformen (richtigen) Versionskombinationen von Software definieren, die in den im Fahrzeug installierten ECUs implementiert sind. Wie in 8 dargestellt, sind beispielsweise alle konformen (korrekten) Versionskombinationen von Software, die in der ECU1 bis zur ECU4 implementiert ist, in der konformen Konfigurationsinformation definiert, die sich auf das Fahrzeug mit der VIN 1001 (Fahrzeug, in dem die ECU1 bis zur ECU4 installiert sind) bezieht. Mit anderen Worten: Kombinationen von Softwareversionen, die nicht in der konformen Konfigurationsinformation enthalten sind, sind nicht-konforme Versionskombinationen und können als ungeeignete Versionskombinationen bezeichnet werden. Wenn die Versionskombination nicht-konform ist, besteht die Möglichkeit, dass die ECUs nicht ordnungsgemäß funktionieren, und es besteht die Möglichkeit, dass das Fahrzeug nicht ordnungsgemäß funktioniert.
In Schritt S4 bestimmt die Bestimmungseinheit 28 in Bezug auf die ECUs, die in dem Fahrzeug installiert sind, das durch die in Schritt S1 erfasste VIN angegeben ist, ob die Kombination von Softwareversionen, die durch die in Schritt S1 erfasste ECU-Software-ID angegeben ist, mit einer der Softwareversionskombinationen übereinstimmt, die in der in der Speichereinheit 26 im Voraus gespeicherten konformen / übereinstimmenden Konfigurationsinformation angegeben ist. Wenn bestimmt wird, dass eine der Kombinationen übereinstimmt / konform ist, stellt die Bestimmungseinheit 28 fest, dass die Softwareversionen übereinstimmen / konform sind, und wenn bestimmt wird, dass keine der Kombinationen übereinstimmt / konform ist, stellt sie fest, dass die Softwareversionen nicht übereinstimmen / konform sind (d. h., sie werden als nicht-konform bestimmt). Danach geht der Prozess zu Schritt S5 über.
In Schritt S5 schreibt die Steuereinheit 29 die Historie der Softwareversionen, die durch die in Schritt S1 erfassten ECU-Software-IDs angegeben sind, in die in der Speichereinheit 26 gespeicherte Softwareversions-Historieninformation (im Folgenden einfach als „Historieninformation“ bezeichnet). Dies wird nachfolgend im Detail beschrieben.
9 ist ein Diagramm zur Beschreibung der Softwareversion Historieninformation. Wie in 9 dargestellt, wird die Historie der Softwareversionen, die in der ECU1 bis zur ECU4 implementiert sind, in die Historieninformation geschrieben, die sich beispielsweise auf das Fahrzeug mit der VIN 1001 bezieht (das Fahrzeug, in dem die ECU1 bis zur ECU4 installiert sind).
In Schritt S5 schreibt die Steuereinheit 29 die Softwareversionen, die durch die in Schritt S1 erfassten ECU-Software-IDs angegeben sind (SW-Version 2.2 von ECU1, SW-Version 2.5 von ECU2, SW-Version 1.5 von ECU3 und SW-Version 2.5 von ECU4), beispielsweise als Historie Nr. 12 in die Historieninformation in 9.
Wenn in Schritt S4 bestimmt wird, dass es keine Übereinstimmung zwischen den Softwareversionen gibt, fügt die Steuereinheit 29 in Schritt S5 Informationen hinzu (z.B. Informationen durch eine Flag), die anzeigen, dass es keine Übereinstimmung in der Historie gibt, die durch die Historieninformation angezeigt wird (nicht-konform). In dem Beispiel in 9 existiert die Kombination von Softwareversionen in der Historie Nr. 12 nicht in der konformen Konfigurationsinformation in 8 und ist dementsprechend nicht-konform und daher wird eine Information, die die Nicht-Konformität anzeigt (ein Kreuz), zur Spalte „Konformitätsbestimmung“ für die Historie Nr. 12 hinzugefügt. Wenn die Steuereinheit 29 in Schritt S4 bestimmt, dass zwischen den Softwareversionen Konformität besteht, fügt sie in Schritt S5 Informationen hinzu, die anzeigen, dass in der durch die Historieninformation angegebenen Historie Konformität besteht. In dem Beispiel in 9 ist die Kombination von Softwareversionen in den Historien Nr. 1 bis 11 in der konformen Konfigurationsinformation in 8 vorhanden und dementsprechend konform und daher wird eine Information, die die Konformität anzeigt (ein Kreiszeichen), zu der Spalte „Konformitätsbestimmung“ für die Historien Nr. 1 bis 11 hinzugefügt.
10 zeigt einen Fall, in dem die Softwareversion von ECU3 in Historie Nr. 12 „2.3“ ist, im Vergleich mit der Historieninformation in 9. In dem Fall in 10 stimmt die Versionskombination der Software in der Historie Nr. 12 mit einer Versionskombination der Software überein, die durch Nr. 36 in der konformen Konfigurationsinformation in 8 angezeigt wird, und dementsprechend ist die Versionskombination konform. Daher wird die Information (eine Kreismarkierung), die eine konforme Versionskombination (eine korrekte Versionskombination) anzeigt, der Spalte „Konformitätsbestimmung“ für die Historie Nr. 12 im Beispiel in 10 hinzugefügt.
Man beachte, dass in der vorliegenden Ausführungsform die Steuereinheit 29 der Historieninformation Implementierungsmanagementversions-Informationen hinzufügt (aufweist), die die Softwareversion angeben, die als in den ECUs implementiert gesteuert wird (Implementierungsmanagementversion), und die Implementierungsmanagementversions-Informationen nach Bedarf aktualisiert. In den Beispielen in 9 und 10 wird die Versionskombination der Software der Historie Nr. 11 (Versionen der Software jeder ECU) um Informationen ergänzt, die Implementierungsmanagementversionen angeben (Kreismarkierung), wodurch die Informationen über die Implementierungsmanagementversion zu den Historieninformationen hinzugefügt werden. Gemäß dieser Anordnung wird die Implementierungsmanagementversionsinformation, die bei dem Prozess der SW-Version bei der Bestimmung der unangemessenen Änderung in Schritt S2 verwendet wird, in der Speichereinheit 26 gespeichert.
In Schritt S6 führt die Steuereinheit 29 den Prozess mit Schritt S7 fort, wenn in Schritt S4 bestimmt wird, dass keine Konformität zwischen den Softwareversionen besteht (d.h. nicht-konform ist), und beendet den Prozess von 7, wenn in Schritt S4 bestimmt wird, dass Konformität besteht. Es ist zu beachten, dass die Steuereinheit 29 bei der Bestimmung der Konformität in Schritt S4 und beim Beenden des Prozesses von 7 die Versionskombination der Software, für die eine Konformität bestimmt wurde, auf die Implementierungsmanagementversion einstellt und die Implementierungsmanagementversionsinformationen aktualisiert. In dem Beispiel in 10 wird die Information (Kreismarkierung), die der Versionskombination der Software für die Historie Nr. 11 hinzugefügt wurde und anzeigt, dass die Versionskombination eine Implementierungsmanagementversion ist, gelöscht, und diese Information (Kreismarkierung) wird in einen Zustand aktualisiert, in dem sie der Versionskombination der Software für die Historie Nr. 12 hinzugefügt wurde.
In Schritt S7 verwendet die Steuereinheit 29 die Historieninformation, um die aktuellste versionskonforme Konfiguration der Software zu identifizieren. In dem Beispiel in 9 identifiziert die Steuereinheit 29 die Versionskombination der Software der Historie Nr. 11 als die aktuellste versionskonforme Konfiguration der Software. Daraufhin geht der Prozess zu Schritt S8 über.
In Schritt S8 identifiziert die Steuereinheit 29 Software, die Ziel eines Rollback-Prozess (Wiederherstellungs-Prozess) ist, bei dem die Softwareversion zurückgesetzt wird, so dass die Versionskombination der in der ECU implementierten Software zu der aktuellsten versionskonformen Konfiguration der in Schritt S7 identifizierten Software zurückkehrt. Im Beispiel in 9 identifiziert die Steuereinheit 29 die Software der ECU 2 und der ECU 3 als Software, die Ziel der Ausführung des Rollback-Prozesses (Wiederherstellungs-Prozess) ist. Danach geht der Prozess zu Schritt S9 über.
In Schritt S9 führt die Steuereinheit 29 einen Rollback-Prozess durch, um die Version der in der ECU implementierten Software auf eine vorherige Version zurückzusetzen.
11 ist ein Flussdiagramm, das ein Beispiel für den Rollback-Prozess in Schritt S9 zeigt. In Schritt S11 in 11 entscheidet die Steuereinheit 29 über Daten zur Durchführung eines Versions-Rollbacks (Rollback-Daten) und eine Rollback-Anweisung für eine der in Schritt S8 identifizierten Software, die Ziel der Ausführung des Rollback-Prozesses sein soll, um zu der aktuellsten versionskonformen Konfiguration der in Schritt S7 identifizierten Software zurückzukehren. Danach geht der Prozess zu Schritt S12 über.
In Schritt S12 bestimmt die Steuereinheit 29, ob die Entscheidung von Schritt S11 für die gesamte Software getroffen wurde, die in Schritt S8 als Ziel des Rollbacks identifiziert wurde. Wenn die Bestimmung in Schritt S12 JA ist, geht der Prozess zu Schritt S13 über, und wenn diese Bestimmung NEIN ist, kehrt der Prozess zu Schritt S11 zurück. Dementsprechend wird ein Rollback (Wiederherstellung) aller Softwareversionen durchgeführt, die in Schritt S8 als Ziel eines Rollbacks identifiziert wurden.
In Schritt S13 überträgt die Steuereinheit 29 die Rollback-Daten und die in Schritt S11 beschlossene Rollback-Anweisung über die Kommunikationseinheit 27 an den OTA-Master 11. Danach endet der Rollback-Prozess von 11 und der Prozess von 7 endet ebenfalls.
Es ist zu beachten, dass der OTA-Master 11 nach Beendigung des Rollback-Prozesses von Schritt S9 in 7 und nach Abschluss des Rollbacks der Softwareversion, die Ziel des Rollbacks ist, eine Rollback-Abschlussmeldung an den OTA-Center 1 sendet. Nach Erhalt der Rollback-Abschlussmeldung schreibt das OTA-Center 1 (Steuereinheit 29) die aktuellste versionskonforme Konfiguration der in Schritt S7 identifizierten Software (d.h. die Versionskombination der Software nach dem Rollback) als neueste Historie in die Historieninformation. Zu diesem Zeitpunkt fügt das OTA-Center 1 (Steuereinheit 29) die Information, die angibt, dass Versionskonformität besteht, der neuesten geschriebenen Historie hinzu. Das OTA-Center 1 (Steuereinheit 29) aktualisiert auch die Implementierungsmanagementversionsinformationen, so dass die Versionskombination der Software, die durch die neueste geschriebene Historie angezeigt wird, die Implementierungsmanagementversion ist. In dem Beispiel in 9 werden Informationen, die den gleichen Inhalt wie die (Informationen) in Historie Nr. 11 haben, in die Historieninformation als neueste Historie Nr. 13 geschrieben und die Kreismarkierung in der Spalte „Implementierungsmanagementversion“ für Historie Nr. 11 wird gelöscht.
Zweite Ausführungsform
12 ist ein Flussdiagramm, das ein Beispiel des Steuerprozesses zeigt, den das OTA-Center 1 gemäß einer zweiten Ausführungsform ausführt. In dem Flussdiagramm in 12 wird der Prozess der Schritte S7 und S8 in dem Flussdiagramm in 7 gemäß der ersten Ausführungsform durch den Prozess von Schritt S71 ersetzt. In der zweiten Ausführungsform wird, wenn die Softwareversionen nicht-konform sind (bei JA in Schritt S6), ein Prozess durchgeführt, um zu der Implementierungsmanagementversion zurückzukehren, die die Implementierungsmanagementversions-Information anzeigt (die Softwareversionen, die das OTA-Center 1 als in den ECUs implementiert steuert), anstatt einen Prozess durchzuführen, um die aktuellste versionskonforme Konfiguration der Software zu identifizieren und zu dieser Versionskonfiguration zurückzukehren, wie in der ersten Ausführungsform. Im Folgenden werden hauptsächlich die Abschnitte beschrieben, die sich von dem Prozess der ersten Ausführungsform unterscheiden.
Wenn in Schritt S6 in 12 die Bestimmung JA getroffen wird, entscheidet die Steuereinheit 29 in Schritt S71, ein Rollback zu der Softwareversion vor der unangemessenen Änderung für die ECUs durchzuführen, die in dem Fahrzeug installiert sind, das durch die in Schritt S1 erfasste VIN angegeben ist. Insbesondere bezieht sich die Steuereinheit 29 auf die Implementierungsmanagementversion, die durch die in der Speichereinheit 26 gespeicherten Implementierungsmanagementversionsinformationen angegeben ist, und entscheidet, ein Rollback (Wiederherstellung) der Softwareversionen auf die Implementierungsmanagementversion in Bezug auf die ECUs durchzuführen, die in dem Fahrzeug installiert sind, das durch die in Schritt S1 erfasste VIN angegeben ist. Im Beispiel in 9 entscheidet die Steuereinheit 29, ein Rollback zu der Versionskombination der Software in der Historie Nr. 11 durchzuführen, die die Implementierungsmanagementversion ist. Danach geht der Prozess zu Schritt S9 über, die Versionen der Software, die Ziel des Rollbacks sind, werden zurückgesetzt (wiederhergestellt) und somit auf die Versionskombination der Software in der Historie Nr. 11, die die Implementierungsmanagementversion ist, zurückgesetzt.
Wie oben unter Bezugnahme auf 7, 12 und andere beschrieben, kann das OTA-Center 1 gemäß der ersten und der zweiten Ausführungsform, wenn die Softwareversionen der ECUs aufgrund des Austauschs von ECUs (Teileaustausch) in unangemessener Weise wechseln, die in unangemessener Weise gewechselte ECU-Software auf die Implementierungsmanagementversion zurücksetzen. Dementsprechend können die Softwareversionen vor und nach dem Austausch von ECUs (Teileaustausch) beibehalten werden und nach dem Austausch von ECUs auf geeignete Softwareversionen zurückgesetzt werden.
Wenn nun die ECUs nach dem Teileaustausch Doppelbank-Speicher-ECUs sind, wie mit Bezug auf das rechte Blockdiagramm in 4 beschrieben, ist die Art der Software (Softwareversion), die in dem Datenspeicherbereich (nicht-aktive Bank) gespeichert ist, die nicht das Ziel des Software-Lesens ist, unbekannt (alternativ gibt es Fälle, in denen keine Software in der nicht-aktiven Bank gespeichert ist). Dementsprechend muss die Wiederherstellung auf die Implementierungsmanagementversion unter der Kontrolle des OTA-Center 1 in der gleichen Weise, wie oben beschrieben, durchgeführt werden, selbst wenn die ECUs nach dem Teileaustausch Doppelbank-Speicher-ECUs sind.
Wie oben unter Bezugnahme auf 7, 12 und andere beschrieben, kann das OTA-Center 1 gemäß der ersten und der zweiten Ausführungsform ECU-Software-IDs vom OTA-Master 11 erfassen und Versions-Historieninformationen für die Software der ECUs erzeugen und steuern und die Softwareversionen von ECUs, die in unangemessener Weise gewechselt haben, unter Verwendung der Historieninformationen auf die Implementierungsmanagementversionen zurücksetzen (wiederherstellen). Dementsprechend können die Softwareversionen unter Verwendung der Historieninformation zurückgesetzt / wiederhergestellt werden, und dabei auf Softwareversionen in der Historie zurückgesetzt werden (grundsätzlich Softwareversionen, denen der Benutzer zugestimmt hat).
Wenn außerdem, wie oben unter Bezugnahme auf 7 und andere beschrieben ist, die Softwareversionen von ECUs unangemessen gewechselt werden, und wenn bestimmt wird, dass Versionen von Software, die in den im Fahrzeug installierten ECUs implementiert sind, nicht-konform sind (keine geeignete Kombination sind), kann das OTA-Center 1 gemäß der ersten Ausführungsform auf die aktuellste konforme Konfiguration von Softwareversionen unter Verwendung von Historieninformation zurücksetzen. Dies ist insofern ideal, als dass die konforme Konfiguration von Softwareversionen mit Sicherheit zurückgesetzt werden kann, und zwar auf die neueste konforme Konfiguration. Wenn andererseits die Softwareversionen von ECUs in unangemessener Weise gewechselt werden und wenn bestimmt wird, dass die Versionen der Software, die in den im Fahrzeug installierten ECUs implementiert sind, konform sind (eine geeignete Kombination sind), führt das OTA-Center 1 gemäß der ersten Ausführungsform keinen Prozess zur Wiederherstellung der Softwareversionen durch, da kein Problem aufgrund nicht-konformer Softwareversionen auftritt. Dadurch kann der Verarbeitungsaufwand reduziert werden. Auf diese Weise kann eine Steuerungskonfiguration vorgenommen werden, bei der selbst dann, wenn bestimmt wird, dass die in den ECUs implementierten Softwareversionen konform sind (eine geeignete Kombination darstellen), eine Wiederherstellung der aktuellsten konformen Konfiguration von Softwareversionen unter Verwendung von Historieninformationen durchgeführt wird. Gemäß dieser Steuerung kann die Wiederherstellung auf die Softwareversionen in der Historie (Softwareversionen, denen der Benutzer zugestimmt hat) erfolgen.
Wie oben unter Bezugnahme auf 12 beschrieben, kann das OTA-Center 1 gemäß der zweiten Ausführungsform die Softwareversionen der ECUs direkt auf die in den Implementierungsmanagementversionsinformationen angegebenen Implementierungsmanagementversionen zurücksetzen, wenn die Softwareversionen der ECUs unangemessen gewechselt werden. Auf diese Weise können die Softwareversionen mit einem übersichtlichen Prozess auf eine konforme Konfiguration zurückgesetzt werden.
Es ist zu beachten, dass in der oben beschriebenen zweiten Ausführungsform (siehe 12) eine Steuerkonfiguration erstellt werden kann, in der der Prozess zur Durchführung der konformen Bestimmung von Softwareversionen (Schritte S4 und S6) nicht ausgeführt wird. Das heißt, wenn eine unangemessene Änderung der Softwareversionen erkannt wird (siehe dicke Linien in 9 und 10), kann der Prozess durchgeführt werden, um die Softwareversionen auf die Implementierungsmanagementversionen zurückzusetzen, unabhängig davon, ob eine Konformität zwischen den Softwareversionen besteht. Nun haben die Implementierungsmanagementversionen in der Regel Konformität unter den Softwareversionen und dementsprechend kann die Verarbeitungslast durch einen solchen übersichtlichen Prozess reduziert werden.
Außerdem wurde oben in der ersten und der zweiten Ausführungsform ein Beispiel beschrieben, bei dem Implementierungsmanagementversions-Informationen, die die Implementierungssteuerungsversion angeben, ein Teil der Historieninformation sind (dieser hinzugefügt werden) und gespeichert werden (siehe 9 und 10). Die Implementierungsmanagementversions-Informationen können jedoch auch getrennt von den Historieninformationen gespeichert werden.
Auch können die Funktionen des OTA-Centers 1, die in den oben beschriebenen Ausführungsformen beispielhaft dargestellt sind, als ein Managementverfahren, das von einem Computer mit einem Prozessor (CPU), einem Speicher und einer Kommunikationsvorrichtung ausgeführt wird, oder als ein von dem Computer auszuführendes Steuerungsprogramm und als ein computerlesbares nichttransitorisches Speichermedium, das das Steuerungsprogramm speichert, realisiert werden. In gleicher Weise können die Funktionen des OTA-Masters 11, die in den oben beschriebenen Ausführungsformen beispielhaft dargestellt sind, als ein Managementverfahren, das von einem installierten Computer mit einem Prozessor (CPU), einem Speicher und einer Kommunikationsvorrichtung ausgeführt wird, oder als ein Steuerprogramm, das von dem installierten Computer auszuführen ist, und als ein computerlesbares, nichttransitorisches Speichermedium, das das Steuerprogramm speichert, realisiert werden.
Die Technologie gemäß der vorliegenden Offenbarung kann in einem Netzwerksystem verwendet werden, um Programme von elektronischen Steuereinheiten (ECUs) zu aktualisieren.
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 2004326689 A [0003]

Claims

Center (1), das so konfiguriert ist, dass es über ein Netzwerk (5) mit einem Over-the-Air (OTA)-Master (11) kommuniziert, der so konfiguriert ist, dass er eine Softwareaktualisierung einer Vielzahl von elektronischen Steuereinheiten (13a, 13b, 13c, 13d), die in einem Fahrzeug installiert sind, steuert, wobei das Center (1) aufweist: eine Kommunikationseinheit (27), die so konfiguriert ist, dass sie von dem OTA-Master (11) Identifikationsinformationen empfängt, die eine Version der in jeder der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementierten Software angeben; eine Speichereinheit (26), die Korrektheit-Bestimmungsinformationen speichert, die bei einer Korrektheit-Bestimmung verwendet werden, um zu bestimmen, ob die Softwareversion, die in jeder der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementiert ist, eine Implementierungsmanagementversion ist, die eine Version einer zu implementierenden Software ist; eine Bestimmungseinheit (28), die so konfiguriert ist, dass sie die Korrektheit-Bestimmung basierend auf den Identifikationsinformationen und den Korrektheit-Bestimmungsinformationen durchführt; und eine Steuereinheit (29), die so konfiguriert ist, dass sie durch Kommunikation mit dem OTA-Master (11) eine Wiederherstellungssteuerung für zumindest eine der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) durchführt, bezüglich derer die Bestimmungseinheit (28) eine Bestimmung getroffen hat, dass die Softwareversion nicht die Implementierungsmanagementversion ist, wobei die Wiederherstellungssteuerung eine Steuerung zum Zurücksetzen der Softwareversion auf die Implementierungsmanagementversion ist.
Center (1) nach Anspruch 1, wobei die Steuereinheit (29) so konfiguriert ist, dass sie basierend auf den Identifikationsinformationen Historieninformationen erzeugt, die die Historie der implementierten Softwareversionen für die elektronischen Steuereinheiten (13a, 13b, 13c, 13d) angeben; die Historieninformationen in der Speichereinheit (26) gespeichert werden; die Bestimmungseinheit (28) so konfiguriert ist, dass sie die Korrektheit-Bestimmung unter Verwendung der Historieninformationen als Korrektheit-Bestimmungsinformationen durchführt; und die Steuereinheit (29) so konfiguriert ist, dass sie die Wiederherstellungssteuerung unter Verwendung der Historieninformationen für die zumindest eine der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) durchführt, bezüglich derer die Bestimmungseinheit (28) die Bestimmung getroffen hat, dass die Softwareversion nicht die Implementierungsmanagementversion ist.
Center (1) nach Anspruch 2, wobei die Speichereinheit (26) konforme Konfigurationsinformationen speichert, die eine geeignete Kombination von Versionen der in den elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementierten Software definieren; die Bestimmungseinheit (28) konfiguriert ist, die konformen Konfigurationsinformationen und die Historieninformationen zu verwenden, um zu bestimmen, ob eine neueste Kombination von Softwareversionen, die durch die Historieninformationen angezeigt werden, geeignet ist; und die Steuereinheit (29) konfiguriert ist, wenn die Bestimmungseinheit (28) bestimmt, dass die neueste Kombination nicht geeignet ist, die Wiederherstellungssteuerung für die zumindest eine der elektronischen Steuereinheiten (13a, 13b, 13c, 13d), bezüglich der die Bestimmungseinheit (28) die Bestimmung getroffen hat, dass die Softwareversion nicht die Implementierungsmanagementversion ist, durchzuführen, und wenn die Bestimmungseinheit (28) bestimmt, dass die neueste Kombination geeignet ist, die Wiederherstellungssteuerung für die zumindest eine der elektronischen Steuereinheiten (13a, 13b, 13c, 13d), bezüglich derer die Bestimmungseinheit (28) die Bestimmung getroffen hat, dass die Softwareversion nicht die Implementierungsmanagementversion ist, nicht durchzuführen.
Center (1) nach Anspruch 3, wobei, wenn die Bestimmungseinheit (28) bestimmt, dass die neueste Kombination nicht geeignet ist, die Steuereinheit (29) konfiguriert ist, eine aktuellste geeignete Kombination von Softwareversionen aus der durch die Historieninformationen angegebenen Historie zu identifizieren, und die Wiederherstellungssteuerung durchzuführen, indem sie eine Steuerung durchführt, um eine Kombination der Softwareversionen der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) auf eine aktuellste geeignete Kombination zurückzusetzen.
Center (1) nach Anspruch 1, wobei die Korrektheit-Bestimmungsinformationen Informationen sind, die die Implementierungsmanagementversion angeben; und die Steuereinheit (29) konfiguriert ist, unter Verwendung der Korrektheit-Bestimmungsinformationen die Wiederherstellungssteuerung für die zumindest eine der elektronischen Steuereinheiten (13a, 13b, 13c, 13d), für die die Bestimmungseinheit (28) die Bestimmung getroffen hat, dass die Softwareversion nicht die Implementierungsmanagementversion ist, durchzuführen.
Center (1) nach einem der Ansprüche 1 bis 5, wobei die Identifikationsinformationen eine Identifikationsinformation aufweist, die eine Softwareversion angibt, die in zumindest einer der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementiert ist, die aufgrund eines Teileaustauschs im Fahrzeug installiert ist.
Managementverfahren, das von einem Computer ausgeführt wird, der einen Prozessor, einen Speicher und eine Kommunikationsvorrichtung aufweist, die so konfiguriert ist, dass sie über ein Netzwerk (5) mit einem Over-the-Air (OTA)-Master (11) kommuniziert, der so konfiguriert ist, dass er die Softwareaktualisierung einer Vielzahl von in einem Fahrzeug installierten elektronischen Steuereinheiten (13a, 13b, 13c, 13d) steuert, wobei das Managementverfahren folgende Schritte aufweist: Empfangen von Identifikationsinformationen, die eine Version der in jeder der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementierten Software angeben, von dem OTA-Master (11); Speichern von Korrektheit-Bestimmungsinformationen, die bei einer Korrektheit-Bestimmung verwendet werden, um zu bestimmen, ob die Softwareversion, die in jeder der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementiert ist, eine Implementierungsmanagementversion ist, die eine Version der zu implementierenden Software ist; Durchführen der Korrektheit-Bestimmung basierend auf den Identifikationsinformationen und den Korrektheit-Bestimmungsinformationen; und Durchführen einer Wiederherstellungssteuerung durch Kommunikation mit dem OTA-Master (11) für zumindest eine der elektronischen Steuereinheiten (13a, 13b, 13c, 13d), bezüglich derer bei der Korrektheit-Bestimmung bestimmt wurde, dass die Softwareversion nicht die Implementierungsmanagementversion ist, wobei die Wiederherstellungssteuerung eine Steuerung zum Zurücksetzen der Softwareversion auf die Implementierungsmanagementversion ist.
Nicht-transitorisches Speichermedium, das ein Steuerungsprogramm speichert, das von einem Computer ausgeführt werden kann, der einen Prozessor, einen Speicher und eine Kommunikationsvorrichtung aufweist, die über ein Netzwerk (5) mit einem Over-the-Air (OTA)-Master (11) kommunizieren kann, der die Softwareaktualisierung einer Vielzahl von in einem Fahrzeug installierten elektronischen Steuereinheiten (13a, 13b, 13c, 13d) steuert, und das den Computer veranlasst, Funktionen auszuführen, die Folgendes umfassen: Empfangen von Identifikationsinformationen von dem OTA-Master (11), die eine Version der in jeder der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementierten Software angeben; Speichern von Korrektheit-Bestimmungsinformationen, die bei einer Korrektheit-Bestimmung verwendet werden, um zu bestimmen, ob die Softwareversion, die in jeder der elektronischen Steuereinheiten (13a, 13b, 13c, 13d) implementiert ist, eine Implementierungsmanagementversion ist, die eine Version der zu implementierenden Software ist; Durchführen der Korrektheit-Bestimmung basierend auf den Identifikationsinformationen und den Korrektheit-Bestimmungsinformationen; und Durchführen einer Wiederherstellungssteuerung durch Kommunikation mit dem OTA-Master (11) für zumindest eine der elektronischen Steuereinheiten (13a, 13b, 13c, 13d), bezüglich derer bei der Korrektheit-Bestimmung bestimmt wurde, dass die Softwareversion nicht die Implementierungsmanagementversion ist, wobei die Wiederherstellungssteuerung die Steuerung zum Zurücksetzen der Softwareversion auf die Implementierungsmanagementversion ist.