DE112022003289T5

DE112022003289T5 - Bordeigenes kommunikationssystem, zentrale vorrichtung, fahrzeugseitiges system und verfahren zur verifizierung von aktualisierungsdaten einer bordeigenen kommunikation

Info

Publication number: DE112022003289T5
Application number: DE112022003289.8T
Authority: DE
Inventors: Koto TOMATSU; Hideo Yoshimi; Masaaki Abe
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2021-06-29
Filing date: 2022-05-31
Publication date: 2024-04-18
Also published as: US20240111519A1; WO2023276532A1; CN117561500A; JP2023005717A

Abstract

In dem bordeigenen Kommunikationssystem 1 gemäß einer Ausführungsform der vorliegenden Offenbarung überträgt ein OTA-Zentrum 2 beim Übertragen von Aktualisierungsdaten durch Streaming an einen fahrzeugseitigen OTA-Master 21 auch einen für die Aktualisierungsdaten berechneten Hash-Wert an den OTA-Master 21. Der OTA-Master 21 überträgt, nachdem er die Aktualisierungsdaten empfangen hat, diese an ein Ziel-ECU 22. Das Ziel-ECU 22 überträgt, nachdem es einen Hash-Wert für die Aktualisierungsdaten berechnet hat, den Hash-Wert an den OTA-Master 21 und der OTA-Master 21 vergleicht den von dem OTA-Zentrum 2 übertragenen Hash-Wert und den von dem Ziel-ECU 22 übertragenen Hash-Wert, um die Integrität der Aktualisierungsdaten zu verifizieren.

Description

Querverweis auf verwandte Anmeldungen
Die vorliegende Anmeldung beansprucht die Priorität der am 29. Juni 2021 eingereichten japanischen Patentanmeldung Nr. 2021-107834 . Die gesamte Offenbarung der obigen Anmeldung wird hiermit durch Bezugnahme aufgenommen.
Technisches Gebiet
Die vorliegende Offenbarung betrifft ein bordeigenes Kommunikationssystem, das eine zentrale Vorrichtung zum Streamen eines Verteilungspakets, das Aktualisierungsdaten enthält, die in eine in einem Fahrzeug installierte elektronische Steuerungseinheit geschrieben werden sollen, und eine Master-Vorrichtung zum Empfangen des Verteilungspakets und Übertragen der Aktualisierungsdaten an die elektronische Steuerungseinheit enthält; wobei die zentrale Vorrichtung und ein fahrzeugseitiges System für das System verwendet werden; und ein Verfahren zur Verifizierung von Aktualisierungsdaten einer bordeigenen Kommunikation.
Stand der Technik
In den letzten Jahren gab es eine Zunahme in dem Umfang von Anwendungsprogrammen zur Fahrzeugsteuerung und -diagnose, die in elektronischen Steuerungseinheiten (ECUs) für Fahrzeuge installiert sind, zusammen mit diversifizierten Fahrzeugsteuerungen, wie Fahrunterstützungsfunktionen und automatischen Fahrfunktionen. Es gab ebenfalls eine Zunahme in den Möglichkeiten eines Umprogrammierens zum Umschreiben bzw. Überschreiben von ECU-Anwendungsprogrammen aufgrund von Versionsaktualisierungen, wie Funktionsverbesserungen. Zum Beispiel fördert die Entwicklung von Kommunikationsnetzwerken ebenfalls Connected-Car-Technologien bzw. Technologien zur Fahrzeugvernetzung bzw. -kopplung. Unter diesen Umständen offenbart zum Beispiel die Patentliteratur 1 die Technologie, bei der ein Server Datenpakete, einschließlich ECU-Aktualisierungsprogramme, an fahrzeuginterne Vorrichtungen basierend auf OTA (Over The Air) liefert und das Fahrzeug die Aktualisierungsprogramme umschreibt bzw. überschreibt.
Das Aktualisierungsprogramm wird gemäß einer Speicherweise und einer Streamingweise umgeschrieben. Die Speicherweise lädt alle Aktualisierungsprogramme von der zentralen Vorrichtung in den Fahrzeugspeicher herunter und führt dann Aktualisierungen durch. Die Streamingweise führt Aktualisierungen durch, während Aktualisierungsprogramme von der zentralen Vorrichtung in das Fahrzeug heruntergeladen werden. Das Fahrzeug enthält einen OTA-Master, der zum Beispiel eine Einheit hat, die generell als DCM (Data Communication Module) oder CGW (Central Gate Way) bezeichnet wird. Der OTA-Master empfängt ein Verteilungspaket, das ein Aktualisierungsprogramm enthält, von der zentralen Vorrichtung und überträgt und schreibt das Aktualisierungsprogramm an bzw. in ein Ziel-ECU, um aktualisiert zu werden.
Die Speicherweise fügt eine digitale Signatur an das Verteilungspaket an. Der OTA-Master verwendet die digitale Signatur, um die Integrität des Verteilungspakets zu verifizieren, und schreibt dann das Aktualisierungsprogramm in das Ziel-ECU.
Literatur aus dem Stand der Technik
Patentliteratur
Patentliteratur 1: JP 2020-27624 A
Zusammenfassung der Erfindung
Jedoch schreibt die Streamingweise das empfangene Aktualisierungsprogramm direkt in das Ziel-ECU, während der OTA-Master die Integrität nicht prüft, im Gegensatz zu dem Vorstehenden. Ungültige Daten können direkt in das Ziel-ECU geschrieben werden, wenn die Daten des in dem Verteilungspaket enthaltenen Programms während eines Datenübertragungspfads von der zentralen Vorrichtung zu dem Ziel-ECU ersetzt werden.
Die vorliegende Offenbarung ist unter Berücksichtigung des Vorstehenden gemacht worden. Es ist daher eine Aufgabe der Offenbarung, ein bordeigenes Kommunikationssystem, eine zentrale Vorrichtung, ein fahrzeugseitiges System und ein Verfahren zur Verifizierung von Aktualisierungsdaten einer bordeigenen Kommunikation bereitzustellen, die in der Lage sind, die Integrität von Aktualisierungsdaten zu verifizieren, die von der zentralen Vorrichtung gestreamt werden.
Bordeigenes Kommunikationssystem nach Anspruch 1, wobei eine zentrale Vorrichtung ebenfalls einen Hash-Wert, der für Aktualisierungsdaten berechnet wird, überträgt, wenn die Aktualisierungsdaten als ein Verteilungspaket in einer Streamingweise an eine Master-Vorrichtung auf einer Fahrzeugseite übertragen werden. Die Master-Vorrichtung überträgt die Aktualisierungsdaten an eine elektronische Steuerungseinheit, wenn sie das Verteilungspaket empfängt. Die elektronische Steuerungseinheit berechnet einen Hash-Wert für die Aktualisierungsdaten und überträgt den Hash-Wert an die Master-Vorrichtung. Die Master-Vorrichtung vergleicht den von der zentralen Vorrichtung übertragenen Hash-Wert mit dem von der elektronischen Steuerungseinheit übertragenen Hash-Wert, um die Integrität der Aktualisierungsdaten zu verifizieren.
Gemäß dieser Konfiguration führt die Master-Vorrichtung eine Verifizierung unter Verwendung von Hash-Werten durch, selbst wenn die Aktualisierungsdaten, die in dem Verteilungspaket enthalten sind, das von der zentralen Vorrichtung an das Fahrzeug gestreamt wird, beispielsweise gefälscht bzw. verfälscht und in unvollständige Daten geändert sein können. Es ist möglich, zu verhindern, dass unvollständige Aktualisierungsdaten auf der elektronischen Steuerungseinheit installiert werden. Es ist möglich, die Sicherheit von Kommunikationssystemen zu verbessern.
Bordeigenes Kommunikationssystem nach Anspruch 2, wobei die zentrale Vorrichtung eine Mehrzahl von Hash-Werten, die für jede Aktualisierungsdaten berechnet werden, an die Master-Vorrichtung überträgt, wenn eine Mehrzahl von Aktualisierungsdaten jeweils in eine Mehrzahl von elektronischen Steuerungseinheiten geschrieben wird. Die Master-Vorrichtung überträgt die Mehrzahl von Aktualisierungsdaten jeweils an die elektronischen Steuerungseinheiten. Jede der elektronischen Steuerungseinheiten berechnet einen Hash-Wert für die Aktualisierungsdaten und überträgt den Hash-Wert an die Master-Vorrichtung. Die Master-Vorrichtung vergleicht jeden der von den elektronischen Steuerungseinheiten übertragenen Hash-Werte mit dem entsprechenden von der zentralen Vorrichtung übertragenen Hash-Wert. Daher ist es ähnlich wie in einem Fall, in dem eine Mehrzahl von Aktualisierungsdaten jeweils an eine Mehrzahl von elektronischen Steuerungseinheiten übertragen wird, möglich, zu verhindern, dass unvollständige Aktualisierungsdaten in jeder elektronischen Steuerungseinheit installiert werden.
Bordeigenes Kommunikationssystem nach Anspruch 7, wobei die zentrale Vorrichtung, wie in Anspruch 1, ebenfalls einen Hash-Wert, der für die Aktualisierungsdaten berechnet wird, überträgt, wenn ein Verteilungspaket in einer Streamingweise an eine Master-Vorrichtung übertragen wird. Die Master-Vorrichtung berechnet einen Hash-Wert für jede vorbestimmte Datengröße für die Aktualisierungsdaten, um einen Hash-Wert für die gesamten Aktualisierungsdaten zu erhalten, und vergleicht den Hash-Wert mit dem von der zentralen Vorrichtung übertragenen Hash-Wert, um die Integrität der Aktualisierungsdaten zu verifizieren.
Die Master-Vorrichtung berechnet, anstelle der elektronischen Steuerungseinheit nach Anspruch 1, einen Hash-Wert für die Aktualisierungsdaten und verifiziert die Integrität. Derselbe Effekt wie in Anspruch 1 kann durch Vervollständigen des Verifizierungsprozesses in der Master-Vorrichtung erlangt werden.
Kurzbeschreibung der Figuren
Die obigen und anderen Aufgaben, Merkmale und Vorteile der vorliegenden Offenbarung werden aus der folgenden ausführlichen Beschreibung unter Bezugnahme auf die beigefügten Zeichnungen noch deutlicher. In den Zeichnungen:

ist 1 ein Funktionsblockschaltbild, das die Konfiguration des bordeigenen Kommunikationssystems gemäß einer ersten Ausführungsform schematisch zeigt;
ist 2 ein Diagramm, das ein Beispiel für Neuprogrammierungsrichtlinien-Metadaten bzw. Umprogrammierrichtlinien-Metadaten veranschaulicht;
ist 3 ein Diagramm, das ein Beispiel für Download-Metadaten veranschaulicht;
ist 4 ein Diagramm, das einen Modus veranschaulicht, in dem ein Verteilungspaket von einem OTA-Zentrum an ein fahrzeuginternes System gestreamt wird;
ist 5 ein Flussdiagramm, das einen Paketerzeugungsprozess veranschaulicht, der an dem OTA-Zentrum durchgeführt wird;
ist 6 ein Flussdiagramm, das einen Signaturerzeugungsprozess an dem OTA-Zentrum veranschaulicht;
ist 7 ein Flussdiagramm, das einen Signaturübertragungsprozess an dem OTA-Zentrum veranschaulicht;
ist 8 ein Flussdiagramm, das einen Paket- und Signaturempfangsprozess veranschaulicht, der von einem OTA-Master durchgeführt wird;
ist 9 ein Flussdiagramm, das einen Prozess an einem Ziel-ECU veranschaulicht;
ist 10 ein Diagramm, das mit 4 vergleichbar ist, wenn ein einzelnes Ziel-ECU verwendet wird;
ist 11 ein Diagramm, das einen Modus eines Übertragens eines Verteilungspakets durch die Verwendung einer Hash-Kette gemäß einer zweiten Ausführungsform veranschaulicht;
ist 12 ein Flussdiagramm, das den Signaturerzeugungsprozess veranschaulicht, der von dem OTA-Zentrum durchgeführt wird;
ist 13 ein Flussdiagramm, das einen Prozess an dem OTA-Master veranschaulicht;
ist 14 ein Diagramm, das einen Modus veranschaulicht, in dem der OTA-Master einen Hash-Wert während der Übertragung eines Verteilungspakets gemäß einer dritten Ausführungsform berechnet;
ist 15 ein Flussdiagramm, das einen Prozess an dem OTA-Master veranschaulicht;
ist 16 ein Flussdiagramm, das einen Prozess an dem Ziel-ECU veranschaulicht;
ist 17 ein Diagramm, das einen Modus eines Übertragens eines Verteilungspakets basierend auf einer Mischung aus einer Streamingweise und einer Speicherweise gemäß einer vierten Ausführungsform veranschaulicht;
ist 18 ein Flussdiagramm, das einen Prozess an dem OTA-Master veranschaulicht;
ist 19 ein Diagramm, das einen Modus eines Übertragens eines Verteilungspakets über ein Smartphone gemäß einer fünften Ausführungsform veranschaulicht.
ist 20 ein Flussdiagramm, das einen Prozess an dem OTA-Zentrum veranschaulicht;
ist 21 ein Flussdiagramm, das einen Prozess an dem Smartphone veranschaulicht;
ist 22 ein Flussdiagramm, das einen Prozess an dem OTA-Master veranschaulicht.

Beschreibung der Ausführungsbeispiele
Erste Ausführungsform
Wie in 1 dargestellt, enthält ein bordeigenes Kommunikationssystem 1 gemäß der vorliegenden Ausführungsform ein OTA-Zentrum 2, das mit einer zentralen Vorrichtung vergleichbar ist, und ein fahrzeugseitiges System 3. Das OTA-Zentrum 2 enthält einen PKG-Erzeugungsserver 4, einen Verteilungsserver 5 und einen DB-Abschnitt 100. Der DB-Abschnitt 100 enthält eine Softwarepaket-DB 101, eine Digitalsignatur-DB 102, eine Konfigurationsinformations-DB 103, eine Fahrzeuginformations-DB 104, eine ECU-Neuprogrammierungsdaten-DB bzw. ECU-Umprogrammierdaten-DB 105 und eine ECU-Metadaten-DB 106. Nachfolgend kann „Datenbank“ als DB bezeichnet werden und kann „Paket“ als PKG bezeichnet werden.
Der PKG-Erzeugungsserver 4 enthält einen Softwarepaket-Erzeugungsabschnitt 9, einen Hashwert-Sammlungsabschnitt 10, einen Hashwert-Berechnungsabschnitt 11 und einen Digitalsignatur-Erzeugungsabschnitt 12. Der Softwarepaket-Erzeugungsabschnitt 9 ist ein Funktionsabschnitt, der ein Softwarepaket erzeugt, das an ein Fahrzeug verteilt werden soll, das mit einem Ziel-ECU ausgestattet ist, dessen Daten aktualisiert werden sollen. Die Details sind zum Beispiel in 15, 16 und 19 der JP 2020-27624 A offenbart. Nachfolgend wird die JP 2020-27624 A als „Referenzpatentveröffentlichung“ bezeichnet. Das Softwarepaket enthält zum Beispiel Aktualisierungsdaten oder Überschreibungs- bzw. Umschreibungs-Spezifikationsdaten für Programme. Die Softwarepaket-DB 101 speichert ein Softwarepaket, das Hashwerte enthält.
Der Hashwert-Sammlungsabschnitt 10 ist ein Funktionsabschnitt, der Aktualisierungsdaten sammelt, die verwendet werden, um einen Hashwert aus dem Softwarepaket zu berechnen. Der Hashwert-Berechnungsabschnitt 11 ist ein Funktionsabschnitt, der eine Hashfunktion auf die gesammelten Daten anwendet, um einen Hashwert zu berechnen. Der Digitalsignatur-Erzeugungsabschnitt 12 ist ein Funktionsabschnitt, der eine erzeugte digitale Signatur zu Hashwert-Verknüpfungsinformationen hinzufügt, die den berechneten Hashwert einer Ziel-ID, nämlich der ID eines entsprechenden Ziel-ECU, zuordnen. Die digitale Signatur wird in der Digitalsignatur-DB 102 gespeichert.
Der Verteilungsserver 5 enthält einen Verteilungsverwaltungsabschnitt 13, einen Fahrzeuginformations-Verwaltungsabschnitt 14, einen Softwareverwaltungsabschnitt 15, einen Kampagnenverwaltungsabschnitt 16, einen Konfigurationsinformations-Verwaltungsabschnitt 17 und einen Individualfahrzeugzustands-Verwaltungsabschnitt 18. Der Verteilungsverwaltungsabschnitt 13 ist ein Funktionsabschnitt, der die Verteilung von Softwarepaketen und Kampagneninformationen an jedes Fahrzeug verwaltet. Der Fahrzeuginformations-Verwaltungsabschnitt 14 registriert und verwaltet individuelle Fahrzeuginformationen, die von individuellen Fahrzeugen hochgeladen werden, in der Individualfahrzeuginformations-DB 104. Ein OEM (Original Equipment Manufacturer) registriert zum Beispiel ein Aktualisierungsprogramm für das Ziel-ECU in dem Softwareverwaltungsabschnitt 15. Zum Beispiel registriert der OEM die Kampagneninformationen in dem Kampagnenverwaltungsabschnitt 16. Die Kampagneninformationen sind in erster Linie auf Programmaktualisierungen bezogen, die in dem fahrzeugseitigen System 3 angezeigt werden.
Der Konfigurationsinformations-Verwaltungsabschnitt 17 verwaltet Konfigurationsinformationen für jeden Fahrzeugtyp, der in der Konfigurationsinformations-DB 103 registriert ist. Die Konfigurationsinformationen sind Identifikationsinformationen, die die Hardware und die Software des in dem Fahrzeug installierten ECU betreffen. Die Konfigurationsinformationen enthalten ebenfalls Identifikationsinformationen über eine Systemkonfiguration, die aus mehreren ECUs gebildet ist, und Identifikationsinformationen über eine Fahrzeugkonfiguration, die aus mehreren Systemen gebildet ist. Der Individualfahrzeugzustands-Verwaltungsabschnitt 18 verwaltet Informationen, wie Programmaktualisierungszustände und Versionen des Ziel-ECU in jedem Fahrzeug. Der PKG-Erzeugungsserver 4 und der Verteilungsserver 5 sind Funktionen, die durch die Computerhardware und -software implementiert sind.
Die Konfigurationsinformations-DB 103, die Individualfahrzeuginformations-DB 104, die ECU-Neuprogrammierungsdaten-DB 105 und die ECU-Metadaten-DB 106 des DB-Abschnitts 100 entsprechen „der Konfigurationsinformations-DB 208, der Individualfahrzeuginformations-DB 213, der ECU-Neuprogrammierungsdaten-DB 204 und der ECU-Metadaten-DB 205“ in der Referenzpatentveröffentlichung.
Das fahrzeugseitige System 3 enthält einen OTA-Master 21, der mit einer Master-Vorrichtung vergleichbar ist, und Aktualisierungs-Ziel-ECUs 22 (1), 22 (2), 22 (3) und so weiter, nämlich elektronische Steuerungseinheiten, deren Programme aktualisiert werden sollen. Nachfolgend wird das Aktualisierungs-Ziel-ECU 22 als Ziel-ECU 22 bezeichnet.
Der OTA-Master 21 ist ein Funktionsabschnitt als eine Kombination aus dem DCM 12 und dem CGW 13, die in 1 der Referenzpatentveröffentlichung dargestellt sind. Der OTA-Master 21 enthält einen Download-Verarbeitungsabschnitt 23, einen Entpacken-Verarbeitungsabschnitt 24, einen Hashwert-Berechnungsabschnitt 25 und einen Hashwert-Vergleichsabschnitt 26. Der Download-Verarbeitungsabschnitt 23 führt eine drahtlose Kommunikation mit dem OTA-Zentrum 2 durch und lädt Verteilungspaketdaten und digitale Signaturdaten herunter. Der Entpacken-Verarbeitungsabschnitt 24 führt einen Entpackprozess durch, der das heruntergeladene Verteilungspaket in jeden Datenabschnitt trennt, der für entsprechende Prozesse verwendet wird. Der Hashwert-Berechnungsabschnitt 25 berechnet einen Hashwert für den Datenwert, der für den Hashwert berechnet werden soll. Dieser Funktionsabschnitt wird in der zweiten Ausführungsform verwendet. Wie später beschrieben, vergleicht der Hashwert-Vergleichsabschnitt 26 den Hashwert, der auf der Seite des Ziel-ECU 22 berechnet wird, mit dem Hashwert, der in dem heruntergeladenen Verteilungspaket enthalten ist.
Das Ziel-ECU 22 enthält einen Mikrocomputer 27, einen Speicher 28 und einen Hashwert-Berechnungsabschnitt 29. Der Speicher 28 ist beispielsweise als Flash-Speicher verfügbar. Die Aktualisierungsdaten, die durch den OTA-Master 21 heruntergeladen werden, werden in den Speicher 28 übertragen und dort installiert. Der Hashwert-Berechnungsabschnitt 29 berechnet einen Hashwert für die Aktualisierungsdaten, die von dem OTA-Master 21 übertragen werden.
«Neuprogrammierungsrichtlinien-Metadaten bzw. Umprogrammierrichtlinien-Metadaten»
Die in 2 veranschaulichten Neuprogrammierungsrichtlinien-Metadaten bzw. Umprogrammierrichtlinien-Metadatenwerden werden vor dem Datendownload von dem OTA-Zentrum 2 an den OTA-Master 21 übertragen.
<Neuprogrammierungsrichtlinien-Metadatenversion bzw. Umprogrammierrichtlinien-Metadatenversion>
Die Neuprogrammierungsrichtlinien-Metadatenversion stellt die Version der Neuprogrammierungsrichtlinien-Metadaten bereit. Zum Beispiel werden die Versionsinformationen, wie „1.0.0“ oder „2.0.0“ gespeichert.
<Verteilungsschicht>
Die Verteilungsschicht speichert Informationen über das Protokoll, das zur Kommunikation mit dem OTA-Zentrum 2 verwendet wird, wie Uptane (eingetragene Marke) oder OMA-DM (Open Mobile Alliance-Device Management), „zellular“, das den OTA-Master 21 als ein Kommunikationsverfahren kennzeichnet, und andere Informationen, wie ein Smartphone oder USB-Speicher, die später beschrieben werden.
<Masterschicht>
Die Masterschicht speichert Informationen über den OTA-Master 21, dessen Plattform (PF) zum Beispiel AP, CP, AGL (Automotive Grade Linux) oder Android (eingetragene Marke) ist. Die Spezifikationen gemäß der General Incorporated Association JASPAR spezifizieren die Datenanforderungen, die auf die klassische Plattform (CP) anwendbar sind, die auf dem statischen OS gemäß dem Standardisierungsgremium AUTOSAR läuft, hinsichtlich der Paketstruktur, um Aktualisierungsprogramme zu verteilen, die für die ECU-Plattformen geeignet sind. AUTOSAR spezifiziert die Datenanforderungen, die auf einen neuen Typ einer adaptiven Plattform (AP) anwendbar sind, die auf einem dynamischen OS läuft. AGL repräsentiert ein bordeigenes Linux (eingetragene Marke). Android repräsentiert Android Automotive OS.
Darüber hinaus speichert die Masterschicht Informationen über die Steuerungsweise, wie beispielsweise „Parameter“ zur Verarbeitung gemäß Parametern, die gemäß einem spezifischen Format festgelegt sind, oder „Skript“ zur Verarbeitung basierend auf einem freieren Beschreibungsformat ohne die Verwendung eines spezifischen Formats.
<Zielschicht>
Diese Informationen entsprechen dem Ziel-ECU 22. Die PF, die Übertragungsweise und die Steuerungsweise entsprechen den oben beschriebenen. Die Ziel-ID repräsentiert eine ID, die dem Ziel-ECU 22 entspricht, und wird als eine Option gespeichert.
<< Download-Metadaten >>
Die in 3 veranschaulichten Download-Metadaten werden im Anschluss an die Neuprogrammierungsrichtlinien-Metadaten von dem OTA-Zentrum 2 an den OTA-Master 21 übertragen.
<Verteilungsschicht>
Wenn das Kommunikationsprotokoll zum Beispiel Uptane ist, stellt die Verteilungsschicht Informationen zum Erlangen von Uptane-Metadaten bereit und speichert diese zum Beispiel die entsprechende URI, den Datennamen, die Datengröße, den Hashwert, die Ziel-ID und die Übertragungsweise.
<Masterschicht>
Die Masterschicht stellt Informationen zum Erlangen von zum Beispiel einem Fahrzeug-PKG bereit und speichert dieselben Elemente bzw. Punkte wie die Verteilungsschicht. Es können mehrere Masterschichten verfügbar sein.
<Zielschicht>
Die Masterschicht stellt Informationen zum Erlangen von zum Beispiel einem Software-PKG bereit und speichert dieselben Elemente bzw. Punkte wie die Verteilungsschicht. Es können ebenfalls mehrere Masterschichten verfügbar sein. Fahrzeug-PKG und Software-PKG sind zum Beispiel auf den Seiten 50, 52 und 53 der „Specification of Update Configuration Management AUTOSAR AP R20-11, Dokument-ID Nr. 706“ beschrieben. Es wird auf die zugehörige Beschreibung in dem Dokument verwiesen.
Die nachstehende Beschreibung erläutert die Unterschiede zwischen AP und CP. AP und CP repräsentieren Softwareplattformen. Die Softwareplattform wird auch als Softwarearchitektur bezeichnet. CP steht für AUTOSAR Classic Platform. AP steht für AUTOSAR Adaptive Platform. ECUs, die basierend auf den CP-Spezifikationen arbeiten, können als CP-ECUs oder CP's-ECUs bezeichnet werden. ECUs, die basierend auf den AP-Spezifikationen arbeiten, können als AP-ECUs oder AP's-ECUs bezeichnet werden.
AP und CP unterscheiden sich in Betriebssystemen (OSs) oder verwendeten Entwicklungssprachen. CP-ECU und AP-ECU unterscheiden sich in den Strukturen von empfangbaren Paketen. Der Unterschied in den Paketstrukturen stammt in erster Linie aus dem Unterschied in den ECU-Verarbeitungsleistungen bzw. -leistungsfähigkeiten. Generell kennzeichnet eine CP-ECU eine niedrige Verarbeitungsleistung bzw. - leistungsfähigkeit. Die in dem Paket enthaltenen Spezifikationsdaten werden auch binär geschrieben. Die Paketdatenstruktur ist leicht zu interpretieren und zu verarbeiten, selbst auf ECUs mit niedriger Verarbeitungsleistung bzw. -leistungsfähigkeit.
Im Gegensatz dazu kennzeichnen AP-ECUs eine hohe Verarbeitungsleistung bzw. -leistungsfähigkeit, was es ermöglicht, eine Parserfunktion zu installieren, die strukturelle Zeichendaten, die in einigen Sprachen geschrieben sind, analysiert und die Daten in eine programmfreundliche Datenstruktur umwandelt. Die Datenstruktur kann ein objektorientiertes Datenformat, wie beispielsweise JSON (JavaScript Object Notation), anstelle von einfachen binären Daten verwenden. Die Paketdatenstruktur ist flexibel.
Die nachstehende Beschreibung erläutert die Vorgänge bzw. Funktionsweisen der vorliegenden Ausführungsform. 4 veranschaulicht konzeptionell die Vorgänge bzw. Funktionsweisen der vorliegenden Ausführungsform. Man nehme an, Aktualisierungsdaten A bis C entsprechen Ziel-ECUs 22 (1) bis 22 (3). Dann ermöglicht der Verteilungsserver 5 des OTA-Zentrums 2 dem Hashwert-Berechnungsabschnitt 11, Hashwerte a bis c für Aktualisierungsdaten A bis C durch Anwenden einer Hashfunktion, wie beispielsweise SHA (Secure Hush Algorithm)-2 (S0 in 5), zu berechnen. Ein Hashwert d wird in ähnlicher Weise auch für Download-Metadaten D berechnet. Die Flussdiagramme in 4 bis 9 veranschaulichen lediglich Prozesse, die Hashwerte a bis c betreffen.
Der Hashwert-Sammlungsabschnitt 10 sammelt Hashwerte a bis c (S1 in 6), um Hashwert-Verknüpfungsinformationen zu erzeugen, die diese Hashwerte a bis c mit der Ziel-ID verbinden (S2). Der Digitalsignatur-Erzeugungsabschnitt 12 erzeugt eine digitale Signatur und liefert diese an die Hashwert-Verknüpfungsinformationen (S3) zur Verschlüsselung durch die Verwendung eines privaten Schlüssels. Die digitale Signatur wird an die Digitalsignatur-DB 102 übertragen und in dieser gespeichert (S4, S5). Der OTA-Master 21 kann danach anfordern, die Hashwert-Verknüpfungsinformationen zu übertragen (S6: Ja in 7). Dann überträgt der Verteilungsserver 5 nacheinander die Hashwert-Verknüpfungsinformationen und das Verteilungspaket an den OTA-Master 21 (S7, S7a).
Die nachstehende Beschreibung erläutert Prozesse an dem fahrzeugseitigen System 3. Wie in 8 veranschaulicht, empfängt der Download-Verarbeitungsabschnitt 23 des OTA-Masters 21 das gestreamte Verteilungspaket von dem Verteilungsserver 5 und überträgt dieser Aktualisierungsdaten A bis C an die Ziel-ECUs 22 (1) bis 22 (3) (S11). Dann empfängt der Download-Verarbeitungsabschnitt 23 die digitale Signatur (S12). Das Kommunikationsprotokoll verwendet in diesem Fall eine Verschlüsselung, wie beispielsweise Uptane oder SSL (Secure Sockets Layer).
Wie in 9 veranschaulicht, lädt das Ziel-ECU 22 die von dem OTA-Master 21 empfangenen Aktualisierungsdaten herunter (S21) und wendet die Hashfunktion auf die Aktualisierungsdaten an, um den Hashwert zu berechnen (S22). Der berechnete Hashwert wird an den OTA-Master 21 übertragen (S23).
Der OTA-Master 21 verifiziert die empfangene digitale Signatur durch Verwendung eines öffentlichen Schlüssels zur Entschlüsselung und erlangt die Hashwert-Verknüpfungsinformationen (S13). Die Ziel-ECUs 22 (1) bis 22 (3) werden aufgefordert, Hashwerte zu übertragen (S14). Dieser Prozess ist jedoch unnötig, wenn das Ziel-ECU 22 spezifiziert ist, um im Schritt S23 Hashwerte automatisch an den OTA-Master 21 zu übertragen.
Die Hashwerte a' bis c' können von allen Ziel-ECUs 22 empfangen werden (S15; Ja). Dann vergleicht der Hashwert-Vergleichsabschnitt 26 die Hashwerte a bis c, die aus den Hashwert-Verknüpfungsinformationen erlangt werden, mit den Hashwerten a' bis c', die von dem Ziel-ECU 22 erlangt werden (S16). Wenn alle Hashwerte miteinander übereinstimmen (S17; Ja), wird eine Installationsanweisung an die Ziel-ECUs 22 (1) bis 22 (3) ausgegeben (S18). Wenn ein Unterschied gefunden wird (S17; Nein), wird eine Rollback-Anweisung an das andere bzw. unterschiedliche Ziel-ECU 22 ausgegeben (S19). Dieser Prozess ist optional.
Die Installation kann von dem OTA-Master 21 angefordert werden (S24; Ja). Dann installiert das Ziel-ECU 22 die heruntergeladenen Aktualisierungsdaten (S25). Es kann keine Installation angefordert werden (S24; Nein) und ein Abbruch kann von dem OTA-Master 21 angefordert werden (S26; Ja). Dann endet der Prozess.
Der oben beschriebene Prozess gilt für die mehreren Ziel-ECUs 22. 10 veranschaulicht einen Prozess, der auf das einzelne Ziel-ECU 22 angewendet wird. Der Prozess ist im Wesentlichen gleich dem in 4 veranschaulichten, mit der Ausnahme, dass die Metadaten E dem Hash-Wert e entsprechen.
In dem bordeigenen Kommunikationssystem 1 gemäß der vorliegenden Ausführungsform überträgt das OTA-Zentrum 2 das Verteilungspaket in einer Streamingweise an den OTA-Master 21 an dem Fahrzeug und überträgt diese ebenfalls den Hash-Wert, der basierend auf den Aktualisierungsdaten berechnet wird, an den OTA-Master 21. Der OTA-Master 21 empfängt das Verteilungspaket und überträgt dann die Aktualisierungsdaten an das Ziel-ECU 22. Das Ziel-ECU 22 berechnet einen Hash-Wert basierend auf den Aktualisierungsdaten und überträgt dann den Hash-Wert an den OTA-Master 21. Der OTA-Master 21 verifiziert die Integrität der Aktualisierungsdaten durch Vergleichen des von dem OTA-Zentrum 2 übertragenen Hash-Werts mit dem von dem Ziel-ECU 22 übertragenen Hash-Wert.
Gemäß dieser Konfiguration führt der OTA-Master 21 eine Verifizierung unter Verwendung von Hash-Werten durch, selbst wenn die Aktualisierungsdaten, die in dem Verteilungspaket enthalten sind, das von dem OTA-Zentrum 2 an das fahrzeugseitige System 3 gestreamt wird, zum Beispiel gefälscht bzw. verfälscht und in unvollständige Daten geändert sein können. Es ist möglich, zu verhindern, dass unvollständige Aktualisierungsdaten auf dem Ziel-ECU 22 installiert werden. Es ist möglich, die Sicherheit des Kommunikationssystems 1 zu verbessern.
Aktualisierungsdaten A bis C können jeweils in die mehreren Ziel-ECUs 22 (1) bis 22 (3) geschrieben werden. In diesem Fall überträgt das OTA-Zentrum 2 auch die Hash-Werte a bis c, die für Aktualisierungsdaten A bis C berechnet werden, an den OTA-Master 21. Der OTA-Master 21 überträgt Aktualisierungsdaten A bis C jeweilig an die Ziel-ECUs 22 (1) bis 22 (3). Die Ziel-ECUs 22 (1) bis 22 (3) berechnen Hash-Werte a' bis c' für Aktualisierungsdaten A bis C und übertragen die Hash-Werte a' bis c' an den OTA-Master 21. Der OTA-Master 21 vergleicht die Hash-Werte a' bis c' mit den Hash-Werten a bis c. Es ist ebenfalls möglich, zu verhindern, dass unvollständige Aktualisierungsdaten installiert werden, wenn Aktualisierungsdaten A bis C an die mehreren Ziel-ECUs 22 (1) bis 22 (3) übertragen werden.
Zweite Ausführungsform
Die einander entsprechenden Teile in der zweiten und der ersten Ausführungsform sind mit denselben Bezugszeichen bezeichnet und eine ausführliche Beschreibung wird der Einfachheit halber weggelassen. Das Folgende beschreibt Unterschiede zu der ersten Ausführungsform. Gemäß der zweiten Ausführungsform, wie in 11 veranschaulicht, wendet der PKG-Erzeugungsserver 4 die Hashfunktion auf Hashwerte a bis c, die entsprechend den Aktualisierungsdaten A bis C erlangt werden, und einen Hashwert d, der entsprechend den Metadaten erlangt wird, an. Der erlangte Hashwert f wird als eine „Hash-Kette“ bezeichnet (S8 in 12). Die Hash-Kette f entspricht einem Hashwert höherer Ordnung. Eine digitale Signatur wird der Hash-Kette f gegeben (S9) und dann folgen die Schritte S4 und S5.
Der OTA-Master 21 empfängt das Verteilungspaket von dem Verteilungsserver 5 des OTA-Zentrums 2 (S31 in 13) und überträgt dann die Aktualisierungsdaten A bis C an die Ziel-ECUs 22 (1) bis 22 (3) (S32). Der Prozess, der von dem Ziel-ECU 22 durchgeführt wird, ist ähnlich dem in 9 veranschaulichten.
Der Download-Verarbeitungsabschnitt 23 empfängt die der Hash-Kette f gegebene digitale Signatur (S33) und verifiziert die empfangene digitale Signatur (S34). Eine erfolgreiche Verifizierung stellt die Hash-Kette f bereit.
Der OTA-Master 21 empfängt die von den Ziel-ECUs 22 (1) bis 22 (3) berechneten Hashwerte a' bis c' (S35). Der Hashwert-Berechnungsabschnitt 11 berechnet die Hash-Kette f' für die empfangenen Hashwerte a' bis c' (und d') (S36).
Der Hashwert-Vergleichsabschnitt 26 vergleicht die von dem OTA-Zentrum 2 erlangte Hash-Kette f mit der von dem Hashwert-Berechnungsabschnitt 11 berechneten Hash-Kette f' (S37). Wenn beide übereinstimmen (S38; Ja), wird eine Installationsanweisung an die Ziel-ECUs 22 (1) bis 22 (3) ausgegeben (S18). Wenn ein Unterschied gefunden wird (S38; Nein), endet der Prozess oder wird eine Rollback-Anweisung an das Ziel-ECU 22 ausgegeben (S40).
Gemäß der zweiten Ausführungsform wie oben überträgt das OTA-Zentrum 2 auch die Hash-Kette f, nämlich einen Hashwert, der im Hinblick auf mehrere Hashwerte a bis c berechnet wird, an den OTA-Master 21. Der OTA-Master 21 berechnet die Hash-Kette f' im Hinblick auf die von den ECU 22 (1) bis 22 (3) empfangenen Hashwerte a' bis c' und vergleicht dann die Hash-Kette f' mit der Hash-Kette f. Die Verifizierung kann unvollständige Daten, falls vorhanden, in den Hashwerten a bis c detektieren, wodurch es möglich wird, die Sicherheit des Kommunikationssystems weiter zu verbessern.
Dritte Ausführungsform
Gemäß der dritten Ausführungsform, wie in 14 veranschaulicht, berechnet der OTA-Master 21 sequentiell Hash-Werte für Aktualisierungsdaten, während er die Verteilungspakete von dem OTA-Zentrum 2 im Streamingmodus empfängt. Die oben beschriebene SHA-2 wird als Hashfunktion verwendet. Die nachstehende Beschreibung erläutert Beispiele, die die SHA-2-Funktion verwenden. Der Prozess an dem OTA-Zentrum 2 ist ähnlich wie der in 5 veranschaulichte. Der OTA-Master 21 identifiziert die Größe der zu empfangenden Daten basierend auf den von dem OTA-Zentrum 2 empfangenen Download-Metadaten (S41 in 15). Dann berechnet der OTA-Master 21, wie oft die Datengröße mit 512 Bit multipliziert wird (S42), und empfängt dieser dann das Verteilungspaket in einer Streamingweise von dem OTA-Zentrum 2 (S43).
Der OTA-Master 21 teilt die empfangenen Daten in Einheiten von 512 Bit auf (S44). Man nehme an, die empfangenen Daten werden zum Beispiel in N Nachrichten aufgeteilt. Der Hashwert-Berechnungsabschnitt 25 wendet die SHA-2-Funktion auf die Nachrichten an (S45) und hält das Ausgabeergebnis als einen initialen Pufferwert für die nächste SHA-2-Funktion (S46). Zum Beispiel wird SHA-256 auf 512-Bit-Daten angewendet, um einen Hashwert zu erzeugen, dessen Hashlänge 256 Bit beträgt. Der Prozess in den Schritten S45 und S46 wird wiederholt, bis die SHA-2-Funktion auf (N-1) Nachrichten angewendet wird (S47; NEIN).
Wenn die N-te Nachricht erreicht wird (S47; JA), bestimmt der Prozess, ob die Datengröße ein ganzzahliges Vielfaches von 512 Bit ist (S48). Wenn die Datengröße nicht das ganzzahlige Vielfache ist (Nein), erzeugt der Prozess das ganzzahlige Vielfache durch Auffüllen und wendet dann die SHA-2-Funktion an. Das Ausgabeergebnis wird als ein Hashwert verwendet (S49). Der OTA-Master 21 verifiziert die von dem Verteilungsserver 5 empfangene digitale Signatur und erlangt den Hashwert (S50). In Schritt S48 kann die Nachrichtendatengröße ein ganzzahliges Vielfaches von 512 Bit sein (Ja). In diesem Fall wird der endgültige Hashwert erlangt. Dann geht die Steuerung zu Schritt S50 über.
Der Hashwert-Vergleichsabschnitt 26 vergleicht den in Schritt S50 erlangten Hashwert mit dem vom Hashwert-Berechnungsabschnitt 25 berechneten Hashwert (S51). Wenn beide übereinstimmen (S52; Ja), wird eine Installationsanweisung an das Ziel-ECU 22 ausgegeben (S53). Wenn ein Unterschied gefunden wird (S52; Nein), endet der Prozess oder wird eine Rollback-Anweisung an das Ziel-ECU 22 ausgegeben (S54).
Der in 15 veranschaulichte Prozess entspricht einem Ziel-ECU 22 und wird wiederholt für mehrere Ziel-ECUs 22 durchgeführt. Der in 16 veranschaulichte Prozess für das Ziel-ECU 22 führt nur die Schritte S21, S24 und S25 in 9 durch und endet, wenn im Schritt S24 „Nein“ bestimmt wird.
Gemäß der dritten Ausführungsform wie oben berechnet der OTA-Master 21 einen Hashwert für jede Aktualisierungsdaten basierend auf einer vorbestimmten Datengröße und erlangt dadurch einen Hashwert für die gesamten Aktualisierungsdaten. Der OTA-Master 21 vergleicht den Hashwert mit dem von dem OTA-Zentrum 2 übertragenen Hashwert, um die Integrität der Aktualisierungsdaten zu verifizieren. Die oben beschriebene Konfiguration kann die Integritätsverifizierung als einen Prozess innerhalb des OTA-Masters 21 durchführen.
Vierte Ausführungsform
Wie in 17 veranschaulicht, stellt die vierte Ausführungsform den Prozess als eine Mischung aus der Streamingweise und der Speicherweise bereit. Der Prozess an dem OTA-Zentrum 2 ist der ersten Ausführungsform ähnlich. Wie in 18 veranschaulicht, empfängt der OTA-Master 21 das Paket A vom Speichertyp basierend auf der Speicherweise und das Paket B basierend auf der Streamingweise von dem Verteilungsserver 5 (S61). Das Paket A entspricht dem Zip-Format und enthält Validierungsdaten über das Paket A. Der OTA-Master 21 verifiziert dann das Paket A unter Verwendung der Verifizierungsdaten und überträgt Aktualisierungsdaten K und L, die in dem Paket B enthalten sind, an die Ziel-ECUs 22 (4) und 22 (5) (S62). Dann beginnt das Herunterladen der Pakete A und B.
Das Paket A kann identifiziert werden (S63; Ja) und die Verifizierung kann normal enden (S70; Ja). Dann werden Aktualisierungsdaten G bis I, die in dem Paket A enthalten sind, in die Ziel-ECUs 22 (1) bis 22 (3) geschrieben (S71). Das Installieren von Paket A beginnt. Wenn die Verifizierung nicht normal endet (S70; Nein), endet der Prozess von dem Paket A. Eine Rollback-Anweisung wird an das Ziel-ECU 22 ausgegeben, das mit dem Installieren des Pakets B begonnen hat (S72).
Wenn das Paket B identifiziert wird (S63; Nein), empfängt der OTA-Master 21 die von den Ziel-ECUs 22 (4) und 22 (5) berechneten Hashwerte k' und I' für die Aktualisierungsdaten K und L (S64). Der Prozess durch das Ziel-ECU 22 ist ähnlich dem in 9 veranschaulichten. Die Verifizierung wird durchgeführt, wenn die digitale Signatur von dem Verteilungsserver 5 empfangen wird (S65).
Der Prozess vergleicht die entschlüsselten Hashwerte k und I mit den Hashwerten k' und I' (S66). Wenn beide übereinstimmen (S67; Ja), wird eine Installationsanweisung an die Ziel-ECUs 22 (4) und 22 (5) ausgegeben (S68). Das Installieren von Paket B beginnt. Wenn sich beide voneinander unterscheiden (S67; Nein), endet der Prozess für das Paket B. Eine Rollback-Anweisung wird an das Ziel-ECU 22 ausgegeben, das mit dem Installieren des Pakets A begonnen hat (S69).
Die nachstehende Beschreibung erläutert einen weiteren Modus von 18. Die oben beschriebene Ausführungsform bestimmt in S63, ob das Paket das Paket A ist. Stattdessen kann der OTA-Master 21 den Typ des Pakets bestimmen und einen Prozess gemäß dem Ergebnis durchführen. Bei Empfang der Pakete A und B bestimmt der OTA-Master 21 den Pakettyp. Wenn es basierend auf der Speicherweise bestimmt wird, dass das Paket dem Paket A entspricht, geht der OTA-Master 21 zu S70 über und führt den Prozess von S70 bis S72 durch. Wenn es basierend auf der Streamingweise bestimmt wird, dass das Paket dem Paket B entspricht, geht der OTA-Master 21 zu S64 über und führt den Prozess von S64 bis S69 durch. Der OTA-Master 21 wiederholt die Bestimmung des Pakettyps so oft wie die Anzahl der empfangenen Pakete.
Gemäß der vierten Ausführungsform wie oben überträgt das OTA-Zentrum 2 Aktualisierungsdaten, die in einige der mehreren Ziel-ECUs 22 geschrieben werden sollen, gemäß der Speicherweise, während die Aktualisierungsdaten und der für die Daten berechnete Hash-Wert an den OTA-Master 21 übertragen werden. Der OTA-Master 21 berechnet einen Hash-Wert für die Aktualisierungsdaten und vergleicht ihn mit dem entsprechenden von dem OTA-Zentrum 2 übertragenen Hash-Wert, um die Integrität der Aktualisierungsdaten zu verifizieren. Wenn die Integrität verifiziert ist, werden die Aktualisierungsdaten an die Ziel-ECUs 22 (1) bis 22 (3) übertragen, die der Speicherweise entsprechen. Die Sicherheit kann verbessert werden, selbst wenn einige Ziel-ECUs 22 der Speicherweise entsprechen.
Fünfte Ausführungsform
Wie in 19 veranschaulicht, veranschaulicht die fünfte Ausführungsform einen Fall, in dem ein Verteilungspaket einmal von dem OTA-Zentrum 2 auf ein Smartphone 31 heruntergeladen und dann von dem Smartphone 31 an den OTA-Master 21 übertragen wird. Das „Smartphone“ kann als ein „Smartphone“ bezeichnet werden und ein Fahrzeugnavigationssystem kann als ein „Navi“ bezeichnet werden. Wie in 20 veranschaulicht, führt das OTA-Zentrum 2 die Schritte S1 bis S4 durch und bestimmt dann, ob das Smartphone 31 als Paketlieferziel ausgewählt ist (S73). Wie nachstehend erläutert, kommuniziert der Benutzer mit dem OTA-Zentrum 2 unter Verwendung eines Fahrzeugnavigationssystems (nicht gezeigt) oder des Smartphones 31. Wenn das Smartphone 31 ausgewählt ist (Ja), wird das Paket an das Smartphone 31 verteilt (S74). Wenn das Smartphone 31 nicht ausgewählt ist (Nein), wird das Paket wie vorstehend an den OTA-Master 21 verteilt (S7).
Wie in 21 veranschaulicht, empfängt der Benutzer, der das Smartphone 31 trägt, eine Push-Benachrichtigung von dem OTA-Zentrum 2 (S81) unter der Bedingung, dass das Smartphone 31 und eine Vorrichtung an dem Fahrzeug basierend auf einer drahtlosen Kommunikation gekoppelt sind. Das Smartphone 31 verwendend, wählt der Benutzer aus, wohin das Verteilungspaket herunterzuladen ist (S82). Das Auswahlergebnis wird dem Verteilungsserver 5 des OTA-Zentrums 2 mitgeteilt (S83).
Wenn der Benutzer das Smartphone 31 auswählt (S84; Ja), wird das Paket auf einen spezifizierten Pfad auf dem Smartphone 31 heruntergeladen (DL) (S85). Das Smartphone 31 teilt dem Verteilungsserver 5 die Vervollständigung des Paketdownloads mit (S86) und überträgt dann das Paket an den OTA-Master 21 (S87).
Wie in 22 veranschaulicht, überträgt der OTA-Master 21 Fahrzeugkonfigurationsinformationen an das OTA-Zentrum 2 (S91), um das OTA-Zentrum 2 mit den Fahrzeugkonfigurationsinformationen zu synchronisieren. Wenn der Benutzer eine Anweisung, die auf dem Fahrzeugnavigationssystem angezeigt wird (S92; Ja), durchführt, verifiziert der OTA-Master 21 die von dem OTA-Zentrum 2 empfangene digitale Signatur und erlangt dieser die Hashwert-Verknüpfungsinformationen (S93).
Das Fahrzeugnavigationssystem oder das Smartphone 31 kann dem OTA-Zentrum 2 mitteilen, dass das Smartphone 31 als das Verteilungspaket-Übertragungsziel ausgewählt ist (S94; Ja). Dann lädt der OTA-Master 21 das Verteilungspaket von dem Smartphone 31 gemäß dem von dem OTA-Zentrum 2 mitgeteilten Verzeichnis herunter (S95). Wenn das Smartphone 31 nicht als das Übertragungsziel ausgewählt ist (S94; Nein), lädt der OTA-Master 21 das Verteilungspaket von dem OTA-Zentrum 2 herunter (S96). Der Prozess führt danach die Schritte S12 bis S19 gemäß der ersten Ausführungsform durch.
Gemäß der fünften Ausführungsform wie oben kann der OTA-Master 21 die Verteilungspakete selektiv von dem Smartphone 31 herunterladen, nachdem die Verteilungspakete von dem OTA-Zentrum 2 auf das Smartphone 31 heruntergeladen sind. Verteilungspakete können flexibler erlangt werden.
Andere Ausführungsformen
Die Inhalte der Neuprogrammierungsrichtlinien-Metadaten bzw. Umprogrammierrichtlinien-Metadaten und der Download-Metadaten können nach Bedarf gemäß individuellen Gestaltungen modifiziert werden.
Die Hashfunktion ist nicht auf SHA-2 beschränkt.
Die vorliegende Offenbarung ist in Übereinstimmung mit den Ausführungsformen beschrieben worden, jedoch ist die vorliegende Offenbarung nicht auf diese Ausführungsformen oder Strukturen beschränkt. Die vorliegende Offenbarung enthält ebenfalls verschiedene Modifikationen und Modifikationen innerhalb eines äquivalenten Bereichs. Zusätzlich sind verschiedene Kombinationen und Modi und andere Kombinationen und Modi, die durch Hinzufügen von einzig einem Element oder mehr oder weniger Elementen zu den Kombinationen und Modi erhalten werden, ebenfalls in den Kategorien und dem technischen Geltungsbereich der vorliegenden Offenbarung enthalten.
Mittel und/oder Funktionen, die durch jede Vorrichtung oder dergleichen bereitgestellt werden, können durch Software, die in einer substantiellen bzw. materiellen Speichervorrichtung aufgezeichnet ist, und einen Computer, der die Software ausführen kann, einzig Software, einzig Hardware oder eine Kombination aus diesen bereitgestellt werden. Wenn beispielsweise die Steuerungsvorrichtung durch eine elektronische Schaltung bereitgestellt wird, das heißt, Hardware, kann die Steuerungsvorrichtung durch eine digitale Schaltung oder eine analoge Schaltung bereitgestellt werden, die eine große Anzahl von Logikschaltungen enthält.
Die Steuerungseinheit und das Verfahren, die in der vorliegenden Offenbarung beschrieben sind, können durch einen dedizierten Computer implementiert werden, der mit einem Speicher und einem Prozessor, der programmiert ist, um eine oder mehrere bestimmte Funktionen auszuführen, die in Computerprogrammen des Speichers verkörpert sind, konfiguriert ist. Alternativ können die Steuerungseinheit und das Verfahren, die in der vorliegenden Offenbarung beschrieben sind, durch einen dedizierten Computer implementiert werden, der durch Bilden eines Prozessors mit einer oder mehreren dedizierten Hardware-Logikschaltungen bereitgestellt wird. Alternativ können die Steuerungseinheit und das Verfahren, die in der vorliegenden Offenbarung beschrieben sind, durch einen oder mehrere dedizierte Computer implementiert werden, die eine Kombination aus einem Prozessor und einem Speicher, der programmiert ist, um eine oder mehrere Funktionen auszuführen, und einem Prozessor, der eine oder mehrere Hardware-Logikschaltungen enthält, enthalten. Ferner kann das Computerprogramm in einem computerlesbaren, nichtflüchtigen, greifbaren Aufzeichnungsmedium als eine Anweisung, die durch einen Computer ausgeführt wird, gespeichert sein.
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 2021107834 [0001]
JP 202027624 A [0006, 0016]

Claims

Bordeigenes Kommunikationssystem, aufweisend: eine zentrale Vorrichtung (2), die konfiguriert ist, um Aktualisierungsdaten als ein Verteilungspaket auf einer Streamingweise an eine in einem Fahrzeug installierte elektronische Steuerungseinheit (22) zu übertragen; eine Master-Vorrichtung (21), die in dem Fahrzeug installiert ist und konfiguriert ist, um das Verteilungspaket zu empfangen und die Aktualisierungsdaten an die elektronische Steuerungseinheit zu übertragen; und die elektronische Steuerungseinheit, die konfiguriert ist, um die von der Master-Vorrichtung übertragenen Aktualisierungsdaten in eine Speichereinheit zu schreiben, wobei die zentrale Vorrichtung ebenfalls einen für die Aktualisierungsdaten berechneten Hash-Wert an die Master-Vorrichtung überträgt, die elektronische Steuerungseinheit einen Hash-Wert für die Aktualisierungsdaten berechnet und den Hash-Wert an die Master-Vorrichtung überträgt, und die Master-Vorrichtung den von der zentralen Vorrichtung übertragenen Hash-Wert mit dem von der elektronischen Steuerungseinheit übertragenen Hash-Wert vergleicht, um die Integrität der Aktualisierungsdaten zu verifizieren.
Bordeigenes Kommunikationssystem nach Anspruch 1, wobei die zentrale Vorrichtung eine Mehrzahl von Hash-Werten, die für jede Aktualisierungsdaten berechnet werden, an die Master-Vorrichtung überträgt, wenn eine Mehrzahl von Aktualisierungsdaten jeweils in eine Mehrzahl von elektronischen Steuerungseinheiten geschrieben wird, die Master-Vorrichtung jede der Aktualisierungsdaten an jede der elektronischen Steuerungseinheiten überträgt, jede der elektronischen Steuerungseinheiten einen Hash-Wert für die Aktualisierungsdaten berechnet und den Hash-Wert an die Master-Vorrichtung überträgt, und die Master-Vorrichtung jeden der von den elektronischen Steuerungseinheiten übertragenen Hash-Werte mit dem entsprechenden von der zentralen Vorrichtung übertragenen Hash-Wert vergleicht.
Bordeigenes Kommunikationssystem nach Anspruch 2, wobei ein für die Mehrzahl von Hash-Werten berechneter Hash-Wert als ein Hashwert höherer Ordnung definiert ist, die zentrale Vorrichtung ebenfalls den Hashwert höherer Ordnung an die Master-Vorrichtung überträgt, und die Master-Vorrichtung einen Hashwert höherer Ordnung für die von den elektronischen Steuerungseinheiten empfangenen Hash-Werte berechnet und den berechneten Hashwert höherer Ordnung mit dem von der zentralen Vorrichtung übertragenen Hashwert höherer Ordnung vergleicht.
Bordeigenes Kommunikationssystem nach Anspruch 2 oder 3, wobei wenn Aktualisierungsdaten in einer Speicherweise an einen Teil der Mehrzahl von elektronischen Steuerungseinheiten übertragen werden, die zentrale Vorrichtung die Aktualisierungsdaten und den für die Aktualisierungsdaten berechneten Hash-Wert an die Master-Vorrichtung überträgt, die Master-Vorrichtung einen Hash-Wert für die Aktualisierungsdaten berechnet und den berechneten Hash-Wert mit dem entsprechenden Hash-Wert, der von der zentralen Vorrichtung übertragenen wird, vergleicht, um die Integrität der Aktualisierungsdaten zu verifizieren, und wenn die Integrität der Aktualisierungsdaten verifiziert ist, die Master-Vorrichtung die Aktualisierungsdaten an eine elektronische Steuerungseinheit, die die Speicherweise unterstützt, überträgt.
Bordeigenes Kommunikationssystem nach einem der Ansprüche 1 bis 4, wobei die zentrale Vorrichtung den Hash-Wert zum Herunterladen von Metadaten, die mindestens eine Adresse eines Datenerlangungsziels, einen Datennamen, eine Datengröße, eine ID einer elektronischen Steuerungseinheit, an die die Aktualisierungsdaten verteilt werden, und Informationen einer Datenübertragungsart enthalten, hinzufügt und an die Master-Vorrichtung überträgt.
Bordeigenes Kommunikationssystem nach einem der Ansprüche 1 bis 5, ferner aufweisend: ein tragbares Informationsterminal, das in der Lage ist, die Aktualisierungsdaten von der zentralen Vorrichtung zu empfangen, wobei die Master-Vorrichtung in der Lage ist, die Aktualisierungsdaten über das tragbare Informationsterminal zu empfangen.
Bordeigenes Kommunikationssystem, aufweisend: eine zentrale Vorrichtung, die konfiguriert ist, um Aktualisierungsdaten als ein Verteilungspaket auf einer Streamingweise an eine in einem Fahrzeug installierte elektronische Steuerungseinheit zu übertragen; eine Master-Vorrichtung, die konfiguriert ist, um das Verteilungspaket zu empfangen und die Aktualisierungsdaten an die elektronische Steuerungseinheit zu übertragen; und die elektronische Steuerungseinheit, die konfiguriert ist, um die von der Master-Vorrichtung übertragenen Aktualisierungsdaten in eine Speichereinheit zu schreiben, wobei die zentrale Vorrichtung ebenfalls einen für die Aktualisierungsdaten berechneten Hash-Wert an die Master-Vorrichtung überträgt, und die Master-Vorrichtung einen Hash-Wert für jede vorbestimmte Datengröße für die Aktualisierungsdaten berechnet, um einen Hash-Wert für die gesamten Aktualisierungsdaten zu erhalten, und den Hash-Wert mit dem von der zentralen Vorrichtung übertragenen Hash-Wert vergleicht, um die Integrität der Aktualisierungsdaten zu verifizieren.
Zentrale Vorrichtung, die Aktualisierungsdaten auf einer Streamingweise sowie einen für die Aktualisierungsdaten berechneten Hash-Wert an eine in einem Fahrzeug installierte elektronische Steuerungseinheit überträgt.
Zentrale Vorrichtung nach Anspruch 8, wobei wenn die Aktualisierungsdaten an jede von einer Mehrzahl von elektronischen Steuerungseinheiten übertragen werden, die zentrale Vorrichtung ebenfalls eine Mehrzahl von Hash-Werten, die für jede Aktualisierungsdaten berechnet werden, überträgt.
Zentrale Vorrichtung nach Anspruch 9, wobei der für die Mehrzahl von Hash-Werten berechnete Hashwert als ein Hashwert höherer Ordnung definiert ist, und der Hashwert höherer Ordnung ebenfalls übertragen wird.
Zentrale Vorrichtung nach Anspruch 9 oder 10, wobei wenn die Aktualisierungsdaten in einer Speicherweise für einen Teil von der Mehrzahl von elektronischen Steuerungseinheiten übertragen werden, die zentrale Vorrichtung die Aktualisierungsdaten und den für die Aktualisierungsdaten berechneten Hashwert überträgt.
Zentrale Vorrichtung nach einem der Ansprüche 8 bis 11, wobei die zentrale Vorrichtung den Hash-Wert zu mindestens einer Adresse eines Datenerlangungsziels, einem Datennamen, einer Datengröße, einer ID einer elektronischen Steuerungseinheit, an die die Aktualisierungsdaten verteilt werden, und Informationen einer Datenübertragungsart hinzufügt und diese überträgt.
Fahrzeugseitiges System, aufweisend: eine Master-Vorrichtung, die in einem Fahrzeug installiert ist und konfiguriert ist, um ein Verteilungspaket zu empfangen, das Aktualisierungsdaten enthält und von einer zentralen Vorrichtung auf einer Streamingweise übertragen wird; und eine elektronische Steuerungseinheit, die in dem Fahrzeug installiert ist und konfiguriert ist, um die von der Master-Vorrichtung übertragenen Aktualisierungsdaten in einen Speicherabschnitt zu schreiben, wobei die Master-Vorrichtung einen für die Aktualisierungsdaten berechneten und von der zentralen Vorrichtung übertragenen Hash-Wert empfängt, die elektronische Steuerungseinheit einen Hash-Wert für die Aktualisierungsdaten berechnet und den Hash-Wert an die Master-Vorrichtung überträgt, und die Master-Vorrichtung den von der zentralen Vorrichtung übertragenen Hash-Wert mit dem von der elektronischen Steuerungseinheit übertragenen Hash-Wert vergleicht, um die Integrität der Aktualisierungsdaten zu verifizieren.
Fahrzeugseitiges System nach Anspruch 13, wobei wenn die zentrale Vorrichtung eine Mehrzahl von Aktualisierungsdaten an eine Mehrzahl von elektronischen Steuerungseinheiten überträgt, die Master-Vorrichtung ebenfalls eine Mehrzahl von Hash-Werten, die für jede der Aktualisierungsdaten berechnet und übertragen werden, empfängt und jede Aktualisierungsdaten an jede elektronische Steuerungseinheit überträgt, jede der elektronischen Steuerungseinheiten einen Hash-Wert für die Aktualisierungsdaten berechnet und den Hash-Wert an die Master-Vorrichtung überträgt, und die Master-Vorrichtung die von der Mehrzahl von elektronischen Steuerungseinheiten übertragenen Hash-Werte mit den entsprechenden von der zentralen Vorrichtung übertragenen Hash-Werten vergleicht.
Fahrzeugseitiges System nach Anspruch 14, wobei die Master-Vorrichtung ebenfalls einen Hash-Wert, der von der zentralen Vorrichtung für die Hash-Werte berechnet und übertragen wird, als einen Hashwert höherer Ordnung empfängt, und wenn die Master-Vorrichtung einen Hashwert höherer Ordnung für die Mehrzahl von Hashwerten, die von der Mehrzahl von elektronischen Steuerungseinheiten empfangen werden, berechnet, die Master-Vorrichtung den berechneten Hashwert höherer Ordnung mit dem von der zentralen Vorrichtung übertragenen Hashwert höherer Ordnung vergleicht.
Fahrzeugseitiges System nach Anspruch 14 oder 15, wobei wenn die zentrale Vorrichtung ein Verteilungspaket, das die Aktualisierungsdaten für einen Teil von der Mehrzahl von elektronischen Steuerungseinheiten enthält, in einer Speicherweise überträgt, die Master-Vorrichtung die Aktualisierungsdaten und einen für die Aktualisierungsdaten berechneten Hash-Wert empfängt, die Master-Vorrichtung einen Hash-Wert für die Aktualisierungsdaten berechnet und den berechneten Hash-Wert mit dem entsprechenden Hash-Wert, der von der zentralen Vorrichtung übertragen wird, vergleicht, um die Integrität der Aktualisierungsdaten zu verifizieren, und wenn die Integrität der Aktualisierungsdaten verifiziert ist, die Master-Vorrichtung die Aktualisierungsdaten an eine elektronische Steuerungseinheit, die die Speicherweise unterstützt, überträgt.
Fahrzeugseitiges System nach einem der Ansprüche 13 bis 16, ferner aufweisend: ein tragbares Informationsterminal, das in der Lage ist, das Verteilungspaket von der zentralen Vorrichtung zu empfangen, wobei die Master-Vorrichtung in der Lage ist, das Verteilungspaket von der zentralen Vorrichtung über das tragbare Informationsterminal zu empfangen.
Fahrzeugseitiges System, aufweisend: eine Master-Vorrichtung, die in einem Fahrzeug installiert ist und konfiguriert ist, um Aktualisierungsdaten, die auf einer Streamingweise von einer zentralen Vorrichtung übertragen werden, als ein Verteilungspaket zu empfangen; und eine elektronische Steuerungseinheit, die in dem Fahrzeug installiert ist und konfiguriert ist, um die von der Master-Vorrichtung übertragenen Aktualisierungsdaten in einen Speicherabschnitt zu schreiben, wobei die zentrale Vorrichtung einen für die Aktualisierungsdaten berechneten Hash-Wert an die Master-Vorrichtung überträgt, und die Master-Vorrichtung einen für die Aktualisierungsdaten von der zentralen Vorrichtung berechneten Hash-Wert empfängt, einen Hash-Wert für jede vorbestimmte Datengröße für die Aktualisierungsdaten berechnet, um einen Hash-Wert für die gesamten Aktualisierungsdaten zu erhalten, und den Hash-Wert mit dem von der zentralen Vorrichtung übertragenen Hash-Wert vergleicht, um die Integrität der Aktualisierungsdaten zu verifizieren.
Verfahren zur Verifizierung von Aktualisierungsdaten einer bordeigenen Kommunikation, aufweisend: wenn eine zentrale Vorrichtung Aktualisierungsdaten auf einer Streamingweise an eine in einem Fahrzeug installierte elektronische Steuerungseinheit überträgt, Übertragen eines Verteilungspakets an die elektronische Steuerungseinheit, wenn eine in dem Fahrzeug installierte Master-Vorrichtung die Aktualisierungsdaten als das Verteilungspaket empfängt; Übertragen, durch die zentrale Vorrichtung, eines für die Aktualisierungsdaten berechneten Hash-Werts an die Master-Vorrichtung, Übertragen, durch die elektronische Steuerungseinheit, eines für die Aktualisierungsdaten berechneten Hash-Werts an die Master-Vorrichtung, und Verifizieren, durch die Master-Vorrichtung, der Integrität der Aktualisierungsdaten durch Vergleichen des von der zentralen Vorrichtung übertragenen Hash-Werts mit dem von der elektronischen Steuerungseinheit übertragenen Hash-Wert.
Verfahren zur Verifizierung von Aktualisierungsdaten einer bordeigenen Kommunikation, aufweisend, wenn eine zentrale Vorrichtung Aktualisierungsdaten auf einer Streamingweise an eine in einem Fahrzeug installierte elektronische Steuerungseinheit überträgt, Übertragen eines Verteilungspakets an die elektronische Steuerungseinheit, wenn eine in dem Fahrzeug installierte Master-Vorrichtung die Aktualisierungsdaten als das Verteilungspaket empfängt, Übertragen, durch die zentrale Vorrichtung, eines für die Aktualisierungsdaten berechneten Hash-Werts an die Master-Vorrichtung, Empfangen, durch die Master-Vorrichtung, eines von der zentralen Vorrichtung berechneten Hash-Werts für die Aktualisierungsdaten, Erhalten, durch die Master-Vorrichtung, eines Hash-Werts für die gesamten Aktualisierungsdaten durch Berechnen eines Hash-Werts für jede vorbestimmte Datengröße für die Aktualisierungsdaten, und Verifizieren, durch die Master-Vorrichtung, der Integrität der Aktualisierungsdaten durch Vergleichen des Hash-Werts mit dem von der zentralen Vorrichtung übertragenen Hash-Wert.