DE112020005928T5 - Masteragent und verteilte Agentenarchitektur für Fahrzeuge - Google Patents

Masteragent und verteilte Agentenarchitektur für Fahrzeuge Download PDF

Info

Publication number
DE112020005928T5
DE112020005928T5 DE112020005928.6T DE112020005928T DE112020005928T5 DE 112020005928 T5 DE112020005928 T5 DE 112020005928T5 DE 112020005928 T DE112020005928 T DE 112020005928T DE 112020005928 T5 DE112020005928 T5 DE 112020005928T5
Authority
DE
Germany
Prior art keywords
update
software
update agent
electronic device
agent
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112020005928.6T
Other languages
English (en)
Inventor
Shrikant Acharya
John Crosbie
Pawel Veselov
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Excelfore Corp
Original Assignee
Excelfore Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Excelfore Corp filed Critical Excelfore Corp
Publication of DE112020005928T5 publication Critical patent/DE112020005928T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

Ein System und Verfahren für einen eSync-Update-Agenten wird bereitgestellt. Der Update-Agent kann mit einem eSync-Client kommunizieren, der Software-Updates von einem externen Server empfängt und die Software-Updates an den Update-Agenten überträgt. Der Update-Agent kann seinerseits seine Programmierung nutzen, um einen oder mehrere Aspekte des Software-Updates zu bestimmen, z. B. wann oder ob das Software-Update auf dem zugehörigen elektronischen Gerät durchgeführt werden soll und ob das Update als Reaktion auf einen Fehler bei der Durchführung des Software-Updates auf dem zugehörigen elektronischen Gerät rückgängig gemacht werden soll. Der Update-Agent kann auch mit der Datenerfassung von seinem zugehörigen elektronischen Gerät oder mit der Gerätesteuerung beauftragt sein. Die verschiedenen Funktionen, einschließlich der Software-Update, der Datenerfassung und der Gerätesteuerung, können programmierbar und aktivierbar sein, so dass die vom Update-Agenten ausgeführten Funktionen auf die Anforderungen des Lebenszyklus des zugehörigen elektronischen Geräts zugeschnitten werden können.

Description

  • VERWEIS AUF VERWANDTE ANMELDUNG
  • Diese Anmeldung beansprucht den Zeitrang der am 2. Dezember 2019 eingereichten vorläufigen US-Anmeldung Nr. 62/942,739 , die in ihrer Gesamtheit durch Bezugnahme hierin aufgenommen wird.
  • HINTERGRUND
  • Heutige Fahrzeuge enthalten Elektronik, um das Fahrzeug zu steuern und zu bedienen. Die Elektronik kann in verschiedenen Formen vorliegen, z.B. in Form von Mikroprozessoren, Mikrocontrollern oder dergleichen. In der Elektronik wird Software ausgeführt, um die gewünschten Funktionen bereitzustellen (z.B. um den Betrieb des Fahrzeugs zu bedienen und zu steuern). Für die im Fahrzeug installierte Software können Software-Updates durchgeführt werden. Diese Software-Updates können in regelmäßigen Abständen im Fahrzeug (z.B. in der Elektronik) zu verschiedenen Zwecken installiert werden, z.B. um Softwarefehler zu korrigieren oder zu beheben, die Software upzudaten, um Hackerangriffe zu verhindern, oder ähnliches.
  • Figurenliste
    • 1 zeigt ein Blockdiagramm, das ein Beispiel für eSync-Agenten im Fahrzeug darstellt.
    • 2A zeigt Steuergeräte (ECU, Abkürzung für electronic control unit) auf getrennten Bussen (z.B. getrennte CAN-Busse).
    • 2B zeigt Steuergeräte an einem einzelnen Bus (z.B. einem einzelnen CAN-Bus) mit mehreren Update-Agenten, die in einen einzelnen Master-Agenten (z.B. einen einzelnen Gateway-Master-CAN-Agenten) integriert sind.
    • 2C zeigt Steuergeräte an einem einzigen Bus (z.B. einem einzigen CAN-Bus), die einen einzigen Update-Agenten verwenden, der in einen einzigen Master-Agenten (z.B. einen einzigen Gateway-Master-CAN-Agenten) integriert ist.
    • 3 zeigt ein Blockdiagramm, in dem das Konzept des Master-Agenten auf Diagnostics over IP (DoIP) Update-Agenten im eSync-System angewendet werden kann (z.B. logische Verknüpfung).
    • 4 zeigt ein Blockdiagramm eines einzelnen Master-Update-Agenten in Multi-Core-ECUs mit VMs, wobei die gestrichelten Linien physische Partitionen darstellen.
    • 5 zeigt ein Blockdiagramm eines einzelnen Agenten in Multi-Core-ECUs unter Verwendung einer einzelnen VM mit mehreren portionierten Prozessen.
    • 6 zeigt ein Blockdiagramm verteilter Agenten in Multi-Core-ECUs mit mehreren VMs und Kernels, wobei gestrichelte Linien Partitionen anzeigen.
    • 7 ist ein Beispiel für ein Flussdiagramm zur Durchführung eines Software-Updates.
    • 8 zeigt ein Blockdiagramm eines eSync-Clients, der einen Download-Manager enthält, der so konfiguriert ist, dass er mit einem fahrzeugexternen Server kommuniziert, um das Software-Update herunterzuladen.
    • 9 zeigt ein Blockdiagramm einer beispielhaften Computerarchitektur.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Elektronische Geräte können in einer Vielzahl von Bereichen vorhanden sein, wie z.B. in Fahrzeugen, Gebäuden, Passagierschiffen, Zügen, automatisierten Nahverkehrssystemen oder jeder anderen Art von großen Systemen mit Komponenten. Ein Beispiel: Software kann in einem oder mehreren elektronischen Geräten in einem Fahrzeug vorhanden sein. Ein weiteres Beispiel ist die Software in einer Vielzahl von elektronischen Geräten in einem Gebäude oder einer anderen Art von Wohnung oder Wohnhaus. Insbesondere Gebäude können eine umfassende Überwachung erfordern, wobei die hier beschriebene Elektronik verschiedene Vorgänge in den Gebäuden, einschließlich ihres Energieverbrauchs, der Evakuierung im Notfall usw., steuert. Das Gebäude kann mehrere Zonen (z.B. mehrere Stockwerke) haben, wobei jeder Zone ein oder mehrere elektronische Geräte zugewiesen oder zugeordnet sind. In dem Beispiel eines Gebäudes mit mehreren Stockwerken kann ein Gebäude mit 30 Stockwerken ein elektronisches Gerät (oder eine Reihe elektronischer Geräte) haben, das jedem Stockwerk zugeordnet ist, um die Kommunikation, die Heizung/Klimaanlage, den Brandschutz und ähnliches zu steuern. Ein weiteres Beispiel sind elektronische Geräte, die in Passagierschiffen, Zügen oder automatisierten Nahverkehrssystemen eingesetzt werden. In dem Maße, in dem sich die hierin enthaltenen Angaben auf ein Fahrzeug beziehen, können sie auch auf jede andere elektronische Umgebung angewendet werden. Ferner kann in einer oder einigen Ausführungsformen ein Gerät in einer eSync-Plattform als ein System definiert werden, auf dem ein einziger eSync-Client läuft (z.B. kann in einer oder einigen Ausführungsformen ein Fahrzeug einen eSync-Client haben, auf den weiter unten eingegangen wird, so dass das Fahrzeug als Gerät bezeichnet werden kann; alternativ kann ein Fahrzeug mehr als einen eSync-Client haben, wie in US-Patent Nr. 10,834,206 dargestellt, das hierin vollumfänglich durch Bezugnahme eingebunden wird).
  • Die elektronischen Geräte in einer Umgebung wie z.B. einem Fahrzeug können einem Software-Update oder mehreren Software-Updates unterzogen werden. Zu diesem Zweck kann in einer oder einigen Ausführungsformen ein Update-Agent (hier auch als Agent, eSync-Agent, Agent-Gerät oder eSync-Agent-Gerät bezeichnet) so gestaltet sein, dass er mit einem elektronischen Gerät im Fahrzeug verbunden ist. Es sind verschiedene Zuordnungen des Update-Agenten denkbar. So kann der Update-Agent beispielsweise in das elektronische Gerät im Fahrzeug (oder in einer anderen Umgebung) integriert werden und sich darin befinden. Ein weiteres Beispiel ist, dass der Update-Agent in einem Knoten untergebracht sein kann, der von dem dem elektronischen Gerät zugewiesenen Knoten getrennt ist (z.B. kann der Update-Agent, wie weiter unten erörtert, bei elektronischen Geräten wie Steuergeräten mit begrenzter Verarbeitungs- und/oder Speicherkapazität zur Durchführung der Entschlüsselung in einem Knoten untergebracht sein, der dem dem elektronischen Gerät zugewiesenen Knoten oder Endpunkt am nächsten liegt). So kann die Platzierung des Update-Agenten in der elektronischen Architektur des Fahrzeugs flexibel sein (z.B. kann der Update-Agent ein Modul an der logischsten Stelle zur Steuerung des zugehörigen elektronischen Geräts sein). Darüber hinaus kann der Update-Agent je nach Anzahl der elektronischen Geräte im Fahrzeug skaliert werden. Beispielsweise kann einem Fahrzeug ein einziger eSync-Client oder mehrere eSync-Clients zugewiesen werden (z.B. ein erster eSync-Client für den wesentlichen Bereich und ein zweiter eSync-Client für den nicht wesentlichen Bereich). Die Anzahl der dem jeweiligen eSync-Client zugewiesenen Update-Agenten kann wiederum von der Anzahl der elektronischen Endpunkte innerhalb der Domäne des jeweiligen eSync-Clients abhängig sein.
  • Es werden verschiedene elektronische Geräte in Betracht gezogen, einschließlich eines, einer Kombination oder aller dieser Geräte: Steuergeräte; Sensoren; Hochleistungscomputer (HPC, engl. high perfomance computer); virtuelle Maschinen (oder andere Virtualisierungen); usw. In der Praxis kann einem, einigen oder allen elektronischen Geräten, die Software-Updates erhalten sollen, ein Update-Agent zugewiesen werden. Der eSync-Client kann mit einem Server (z.B. einem Software-Update-Server) außerhalb des Fahrzeugs kommunizieren, um die Software-Updates herunterzuladen oder zu beziehen. Im Gegenzug kann der eSync-Client die Software-Updates an die Update-Agenten übertragen oder kommunizieren, damit die Update-Agenten die eigentlichen Software-Updates der elektronischen Geräte durchführen (z.B. enthalten die Update-Agenten die Intelligenz, um zu bestimmen, ob und/oder wann die Software-Updates auf den elektronischen Geräten durchgeführt werden sollen, was ein Beispiel für Software-Update-Bedingungsangaben sein kann). Diese Aufteilung der Zuständigkeiten zwischen dem eSync-Client und den Update-Agenten ermöglicht mehr Intelligenz am Rande (z.B. sind die Update-Agenten intelligenter und ermöglichen eine dezentralere Intelligenz im elektronischen Ökosystem des Fahrzeugs). Wie weiter unten erörtert, kann der eSync-Client mit der Kommunikation mit dem externen Server beauftragt werden, um bestimmte Funktionen auszuführen, wie z.B. eine, eine beliebige Kombination oder alle der folgenden: Empfangen von Software-Update-Downloads vom externen Server und Weiterleiten der Software-Updates an die zuständigen Update-Agenten; Melden der Ergebnisse des Erfolgs/Misserfolgs der von den Update-Agenten empfangenen Software-Updates an den externen Server; Empfangen von Programmierbefehlen vom externen Server, wie z.B. einer Programmierangabe, um die Update-Agenten so zu programmieren, dass sie die Durchführung mindestens eines Software-Updates aktivieren (z.B. eine oder mehrere Software-Updates-Bedingungsangaben), Datenerfassung (z.B. eine oder mehrere Datenerfassungs-Bedingungsangaben) oder Gerätesteuerung (z.B. ein oder mehrere Steuerparameter) zu aktivieren und die Programmierbefehle an die zuständigen Update-Agenten weiterzuleiten; usw. Der Update-Agent kann damit beauftragt werden, mit dem eSync-Agenten auf der einen Seite und mit den zugehörigen elektronischen Geräten auf der anderen Seite zu kommunizieren, um eine, eine Kombination oder alle Software-Updates, Datenerfassungen oder Gerätesteuerungen durchzuführen. Auf diese Weise kann der Update-Agent eine standardisierte Schnittstelle für Updates bereitstellen. Wie weiter unten näher erläutert, kann sich die Verantwortung des Agenten auch auf das Sammeln von Systeminformationen (Datenerfassung) erstrecken (z.B. eine, eine beliebige Kombination oder alle der folgenden Informationen innerhalb des Fahrzeugs: Ladezustand; Geschwindigkeit des Fahrzeugs; Zustand der Zündung ein oder aus; und Übermittlung eines solchen Status an das eSync-System, wobei ein Beispiel für ein eSync-System im US-Patent Nr. 10.834.206 offenbart wird, das hierin vollumfänglich durch Bezugnahme eingebunden wird).
  • So kann der Update-Agent in einer oder einigen Ausführungsformen Intelligenz zur Ausführung einer oder mehrerer Funktionen enthalten, die programmierbar sein können (z.B. programmierbar in Bezug auf die Aktivierung zur Ausführung der einen oder mehreren Funktionen (z.B. ob die eine oder mehreren Funktionen ausgeführt werden sollen) und/oder programmierbar in Bezug auf die Kriterien zur Ausführung der einen oder mehreren Funktionen (z.B. wie die eine oder mehreren Funktionen ausgeführt werden sollen). Als nur ein Beispiel kann der Update-Agent eine, eine beliebige Kombination oder alle der folgenden Funktionen ausführen: (1) Durchführen von Software-Updates; (2) Sammeln von Daten (z.B. Kommunizieren mit dem zugehörigen elektronischen Gerät, um Daten von Sensoren zu erhalten, die sich in dem elektronischen Gerät befinden oder mit diesem verbunden sind; intelligentes Sammeln von Daten, um zu bestimmen, ob Daten gesammelt werden sollen und/oder um zu bestimmen, ob die gesammelten Daten zurück an den eSync-Client übertragen werden sollen (der Update-Agent kann z.B. die Ähnlichkeit und/oder Unähnlichkeit der gesammelten Daten mit zuvor übertragenen Daten analysieren, um zu bestimmen, ob die Daten zurück an den eSync-Client übertragen werden sollen; in einer Ausführungsform führt die Feststellung der Ähnlichkeit der gesammelten Daten mit zuvor übertragenen Daten durch den Update-Agenten zu einer Entscheidung, die gesammelten Daten nicht an den eSync-Client zu übertragen und/oder die gesammelten Daten zu verwerfen, oder zu beiden; alternativ dazu führt das Reagieren auf den Update-Agenten, der die Unähnlichkeit der gesammelten Daten mit zuvor übertragenen Daten feststellt, zu der Entscheidung, die gesammelten Daten an den eSync-Client zu übertragen); oder (3) die Steuerung des Endpunktgeräts (z.B. programmatische Regeln, die ein Beispiel für Steuerparameter sein können und vom eSync-Client von einem externen Server heruntergeladen und zur Speicherung an den Update-Agenten weitergeleitet werden können, können zur Steuerung des mit dem Update-Agenten verbundenen elektronischen Geräts verwendet werden; auf diese Weise kann der Update-Agent dem mit dem Update-Agenten verbundenen elektronischen Gerät Befehle erteilen). Da der Update-Agent über die Intelligenz zur Ausführung der verschiedenen Funktionen verfügt, muss er sich nicht auf den externen Server oder den eSync-Client verlassen, um die verschiedenen Funktionen auszuführen, wenn die Kommunikation vorübergehend unterbrochen ist.
  • Darüber hinaus können in einer oder einigen Ausführungsformen die vom Update-Agenten ausgeführten Funktionen programmierbar aktiviert werden. Insbesondere kann der eSync-Client mit dem externen Server kommunizieren, um die Programmierangabe zu erhalten, die angibt, ob ein entsprechender Update-Agent aktiviert werden soll, um eine, einige oder alle der hier beschriebenen Funktionen auszuführen (z.B. eine, eine Kombination oder alle Funktionen des Software-Updatings, Datenerfassung oder Gerätesteuerung). Auf diese Weise kann die Aktivierung von Funktionen im Update-Agenten sequentiell erfolgen, wie z.B. die Aktivierung der Ausführung von mindestens zwei oder mehr Funktionen des Software-Updatings, der Datenerfassung oder der Gerätesteuerung oder wie die Aktivierung der Ausführung der Funktionen jedes der Software-Updatings, der Datenerfassung oder der Gerätesteuerung. Diese programmierbare Aktivierung kann somit auf verschiedene Weise für Flexibilität sorgen, unter anderem in Abhängigkeit von den Bedürfnissen des Endpunkts (z.B. muss das mit dem Update-Agenten verbundene elektronische Gerät eine Funktion möglicherweise nicht sofort nach der Herstellung ausführen, sondern kann die Funktion, z.B. eine Sicherheitsfunktion, nach einem bestimmten Zeitraum ausführen müssen, z.B. in Abhängigkeit von künftigen Vorschriften oder dergleichen) und/oder in Abhängigkeit von den Wünschen des externen Servers (z.B. kann der externe Server einen Datenerfassungsdienst bereitstellen, der als Dienst bereitgestellt werden kann), wodurch ein besseres Lebenszyklusmanagement der elektronischen Endpunktgeräte ermöglicht wird.
  • Auf diese Weise können die beschriebenen Funktionen bei der Herstellung des Fahrzeugs deaktiviert (oder nur eingeschränkt aktiviert) und später aktiviert werden (z.B. von der Ausführung keiner Funktionen zur Ausführung einiger Funktionen; von der Ausführung einer Funktion zur Ausführung von mehr als einer Funktion; von der Ausführung einiger Funktionen zur Ausführung aller möglichen Funktionen). Insbesondere im Hinblick auf ein Steuergerät ist die Flexibilität gegeben, die gegenwärtig für das Steuergerät benötigte Funktionalität einzubauen und danach die Funktionalität über die Update-Agenten upzudaten, wenn sich die Anforderungen des Steuergeräts ändern.
  • Darüber hinaus liefern die Update-Agenten eine Manifestation der Intelligenz am Endpunkt. Beispielsweise können die Update-Agenten in Bezug auf Software-Updates die Information enthalten, ob und/oder wann die Software-Updates durchgeführt werden sollen und/oder ob und/oder wann Software-Rollbacks durchgeführt werden sollen. Insbesondere kann der eSync-Client die Software-Updates an die Update-Agenten übermitteln. Die Update-Agenten wiederum können mit einer Programmierung, die bei der Herstellung in den Update-Agenten enthalten sein kann oder später vom eSync-Client übertragen wird, bestimmen, ob das Update durchgeführt werden soll (z.B. die Bedingungen, die der jeweilige Update-Agent für die Durchführung der Software-Update zulässt, und/oder die Bedingungen, die die Durchführung der Software-Update nicht zulassen oder verzögern, was Beispiele für die Angabe der Software-Update-Zustände sind). So kann der Update-Agent selbst dann, wenn er ein Software-Update vom eSync-Client empfängt und damit dem jeweiligen Update-Agenten anzeigt, dass das Software-Update für ein sofortiges Update der Software in dem mit dem Update-Agenten verbundenen elektronischen Gerät bestimmt ist, beschließen, das Software-Update zu verzögern (oder optional zu verwerfen). Der Update-Agent kann bei seiner Entscheidung, ob das Update durchgeführt werden soll, ein oder mehrere Kriterien berücksichtigen, einschließlich eines oder beider der folgenden: ein oder mehrere Aspekte des Fahrzeugs (z.B. mindestens ein Aspekt des aktuellen Betriebs des Fahrzeugs, wie z.B. die aktuelle Geschwindigkeit); oder ein oder mehrere Aspekte der Software in dem elektronischen Gerät, das dem Update-Agenten zugeordnet ist (z.B. ein Zeitstempel bezüglich des letzten Zeitpunkts, zu dem die Software upgedated wurde, und/oder ein Zeitstempel, der mit der ursprünglichen Programmierung des elektronischen Geräts bei der Herstellung verbunden ist). Beispielsweise kann der Update-Agent auf der Grundlage des aktuellen Betriebs des Fahrzeugs bestimmen, ob die Software-Update durchgeführt werden soll (z.B. ob das Fahrzeug mit mehr als 50 mph oder einer anderen vorgegebenen Geschwindigkeit fährt, die nicht Null ist; wenn der Update-Agent feststellt, dass das Fahrzeug mit mehr als 50 mph fährt, kann der Update-Agent bestimmen, die Durchführung der Software-Update zu verzögern; wenn der Update-Agent feststellt, dass das Fahrzeug mit weniger als 50 mph fährt, kann der Update-Agent bestimmen, die Software-Update durchzuführen). Auf diese Weise kann das Software-Update auf Daten zugreifen, die mit dem aktuellen Betrieb des Fahrzeugs in Verbindung stehen (z.B. auf Daten, die in dem mit dem Update-Agenten verbundenen Steuergerät vorhanden oder verfügbar sind, oder auf Daten, die der Update-Agent von einem Steuergerät anfordern kann, das nicht mit dem Update-Agenten verbunden ist), um seine Bestimmung durchzuführen. Als weiteres Beispiel kann der Update-Agent auf der Grundlage mindestens eines Aspekts der Software, die Gegenstand dem Update ist, bestimmen, ob die Software-Update durchgeführt werden soll (z.B. ob die Software innerhalb eines vorbestimmten Zeitraums geupdated, hergestellt oder installiert wurde; wenn dies der Fall ist, kann der Update-Agent bestimmen, die Durchführung des Software-Updates zu verzögern oder das Software-Update zu verwerfen). Auf diese Weise kann der Software-Agent bei der Entscheidung, ob und/oder wann das Software-Update durchgeführt werden soll, Richtlinien berücksichtigen (z.B. die Zustimmung des Benutzers und/oder die Neuplanung durch den Benutzer).
  • Alternativ oder zusätzlich kann der Update-Agent, z.B. ein unten beschriebener Master-Update-Agent, bestimmen, ob und/oder wie ein Software-Rollback durchgeführt werden soll. Beispielsweise können im Update-Agenten ein oder mehrere Rollback-Indikatoren gespeichert sein, wie etwa ein oder mehrere Kriterien, um zu bestimmen, ob ein Software-Rollback durchgeführt werden soll, wenn der Update-Agent einen Fehler bei der Software-Update feststellt (wie etwa einen Fehler bei dem Update der Software des Geräts, das dem Update-Agenten zugeordnet ist, und/oder einen Fehler bei dem Update der Software des Geräts, das nicht dem Update-Agenten zugeordnet ist). Wie bereits erwähnt, können die ein oder mehreren Rollback-Indikatoren bei der Herstellung im Update-Agenten gespeichert und/oder dynamisch upgedated werden, z.B. als Programmierindikator. Der Update-Agent kann auf der Grundlage der einen oder mehreren Rollback-Indikatoren bestimmen, ob ein Rollback der Software durchgeführt werden soll (in seinem zugehörigen elektronischen Gerät und/oder im Falle eines Master-Update-Agenten durch Senden eines Befehls an einen oder mehrere Follower-Update-Agenten, um die Software in den zugehörigen elektronischen Geräten des einen oder der mehreren Follower-Update-Agenten zurückzusetzen), und als Reaktion auf die Bestimmung das Rollback der Software durchführen. Die Entscheidung über das Rollback kann von einer Rollback-Richtlinie abhängen. Im Zusammenhang mit einem Master-Update-Agenten ist der Prozessor beispielsweise so konfiguriert, dass er als Reaktion darauf, dass die Vorrichtung des Master-Update-Agenten feststellt, dass ein Fehler in der Software-Update vorliegt, die einem oder beiden elektronischen Geräten, die dem Master-Update-Agenten zugeordnet sind, oder dem einen oder den mehreren elektronischen Geräten, die dem einen oder den mehreren Follower-Update-Agenten zugeordnet sind, zugeordnet ist, auf der Grundlage einer im Master-Update-Agenten residenten Richtlinie bestimmt, ob das eine oder die mehreren Geräte des Follower-Update-Agenten angewiesen werden sollen, die Software zurückzusetzen (z. B, der Master-Update-Agent alle ein oder mehrere Follower-Update-Agenten anweist, die Software zurückzusetzen, um ein synchronisiertes Rollback der Software durchzuführen; der Master-Update-Agent nur die ein oder mehreren Follower-Update-Agenten anweist, die Software zurückzusetzen, um ein synchronisiertes Rollback der Software durchzuführen, wenn ihr zugehöriges elektronisches Gerät einen Fehler erlitten hat; der Master-Update-Agent kann einen Typ oder eine Klasse von elektronischem Gerät (wie z.B. wesentlich versus nicht wesentlich, unten besprochen) bestimmen, das von dem Fehler in dem Software-Update betroffen ist, und basierend auf dem bestimmten Typ oder der Klasse von elektronischem Gerät, das von dem Fehler in dem Software-Update betroffen ist, eine oder mehrere der Follower-Update-Agent-Vorrichtungen anzuweisen, die Software zurückzusetzen (wie im Falle eines wesentlichen elektronischen Geräts, das die Software-Update nicht durchführt, alle wesentlichen und nicht wesentlichen Geräte, die vom Master-Update-Agenten kontrolliert werden, zurückzusetzen, oder im Falle eines nicht wesentlichen elektronischen Geräts, das die Software-Update nicht durchführt, nur die nicht wesentlichen Geräte, die vom Master-Update-Agenten kontrolliert werden, zurückzusetzen). Auf diese Weise können die Rollback-Entscheidungen an die Update-Agenten weitergeleitet werden und in diesen verbleiben (z.B. näher am oder am Endpunkt) und nicht im eSync-Client oder im Backend-Server.
  • Wie bereits erwähnt, kann ein Master-Update-Agent einen oder mehrere Follower-Update-Agenten steuern (die ihrerseits ihre zugehörigen elektronischen Geräte steuern). In einer oder einigen Ausführungsformen kann der Master-Update-Agent mit einem elektronischen Gerät verbunden sein und somit sein zugehöriges elektronisches Gerät direkt steuern, zusätzlich zur indirekten Steuerung der zugehörigen elektronischen Geräte der ein oder mehreren Follower-Update-Agenten. Darüber hinaus können Entscheidungen, wie z.B. Software-Update-Entscheidungen, Rollback-Entscheidungen, Datensammlungsentscheidungen oder Gerätesteuerungsentscheidungen, im Master-Update-Agenten durchgeführt werden (und der Master-Update-Agent kann wiederum dem einen oder den mehreren Follower-Update-Agenten befehlen, diese Entscheidungen umzusetzen), oder sie können im Update-Agenten durchgeführt werden (und der Update-Agent setzt die Entscheidungen wiederum nur in seinem zugehörigen elektronischen Gerät um und nicht in einem nicht zugehörigen elektronischen Gerät). Sind beispielsweise mehrere elektronische Endgeräte über ein einziges Gateway verbunden, das über einen einzigen Anschluss zur Verwaltung mehrerer elektronischer Endgeräte verfügt, kann ein einziger Master-Update-Agent letztlich jedes der elektronischen Endgeräte über den einzigen Anschluss steuern.
  • Darüber hinaus kann in einer oder einigen Ausführungsformen eine 1:1-Architektur einen Update-Agenten einem elektronischen Endpunktgerät in einer 1:1-Weise zuweisen. Alternativ kann eine 1:M-Architektur einen Update-Agenten einer Vielzahl von elektronischen Endpunktgeräten in einer 1:M-Weise zuweisen.
  • So können sich mehrere Agenten und/oder verschiedene Arten von Agenten im Fahrzeug befinden. In einer oder einigen Ausführungsformen kann ein Master-Agent einen oder mehrere Follower-Agenten in einem Cluster halten, um Updates an Controller Area Network (CAN)-basierten Steuergeräten vorzunehmen, die beispielsweise an einem einzigen Bus oder mehreren CAN-Bussen hängen, wie weiter unten erläutert. In diesem Zusammenhang können ein, zwei, drei oder mehr Follower-Agenten im Fahrzeug von einem Master-Agenten gesteuert werden.
  • Agenten (z.B. Master- und/oder Follower-Agenten und austauschbar als eSync-Agenten oder eSync-Agent-Geräte bezeichnet) können eine oder mehrere Funktionen ausführen. So können Agenten beispielsweise Richtlinien auflösen (z.B. Benutzer-Opt-in oder Benutzer-Umplanung und/oder spezifische gerätebezogene Richtlinien für das Steuergerät). Ein Beispiel: Das Gerät (z.B. das Steuergerät oder ein anderes elektronisches Gerät im Fahrzeug) wurde upgedated (z.B. beim Mechaniker) und hat eine Zeitspanne, in der das Gerät nicht upgedated werden sollte, was die Geräte in Verbindung mit Systemagenten umsetzen können. Insbesondere kann auf dem Gerät (z.B. über einen Tag o.ä.) eine Angabe über das Update-Protokoll gespeichert sein (z.B. ob ein Software-Update überhaupt durchgeführt werden darf; ob ein Software-Update erst nach einer bestimmten Zeit (z.B. erst nach einem bestimmten Datum) durchgeführt werden darf; ob ein Software-Update nur unter bestimmten Umständen (z.B. nur, wenn sich das Fahrzeug in einem bestimmten Zustand befindet, nur, wenn sich das Gerät in einem bestimmten Zustand (z.B. Leerlauf) befindet usw.) durchgeführt werden darf. Der Agent kann auf das Gerät zugreifen, um die gerätespezifischen Richtlinien zu erhalten. Als Reaktion auf den Empfang der gerätespezifischen Richtlinien von dem spezifischen Gerät, das einem möglichen Update unterliegt, kann der Agent entscheiden, ob das Update durchgeführt werden soll. Wenn der Agent beispielsweise auf die gerätespezifischen Richtlinien von einem bestimmten Gerät zugreift und die gerätespezifischen Richtlinien angeben, dass das Update erst nach einem zukünftigen Datum (z.B. zwei Monate ab dem aktuellen Datum) durchgeführt werden soll, kann der Agent entscheiden, das Update nicht durchzuführen. Außerdem kann der Agent das zukünftige Datum in seinem Speicher vermerken, um das Update zu dem zukünftigen Datum durchzuführen. Alternativ oder zusätzlich können die Agenten Diagnoseinformationen sammeln. In diesem Zusammenhang kann der Agent eine, eine Kombination oder alle der hier beschriebenen Funktionen ausführen.
  • Updates können in einer eSync-Plattform beispielsweise im Zusammenhang mit einem, einer beliebigen Kombination oder allen folgenden Elementen durchgeführt werden: eSync-Agenten, einem eSync-Bus, eSync-Client(s), einer eSync-Cloud, eSync-Elementen, eSync-Monitoren, eSync-Servern oder eSync-Bäumen. Wie weiter unten erläutert, kann ein eSync-Agent Steuergeräte mithilfe eingehender/heruntergeladener Software updaten. eSync-Agenten in der eSync-Plattform können eine Zwei-Wege-Informationsübertragung unterstützen und können Updates durchführen und/oder Daten für Diagnosen sammeln.
  • Der eSync-Bus kann sich an ein Kommunikationsprotokoll zwischen den eSync-Elementen halten, das vom Message Broker im eSync-Client entschieden werden kann. Der im US-Patent Nr. 10,834,206 beschriebene Nachrichten-Broker (auch als Broker oder Broker-Gerät bezeichnet) kann ein Teil des eSync-Clients sein, der eine integrierte Einheit zur sicheren Weiterleitung von Nachrichten zwischen eSync-Elementen darstellt. Es kann sich um ein busorientiertes System handeln, das sowohl Multicast- und Broadcast-Nachrichten als auch einfache Punkt-zu-Punkt-Nachrichten unterstützt.
  • Der eSync-Client kann einige oder alle Softwarefunktionen umfassen, die typischerweise einmalig im Fahrzeug implementiert werden, um den eSync-over-the-Air (OTA)-Fluss im Fahrzeug zu steuern. Der eSync-Client kann eine, eine Kombination oder alle der folgenden Funktionen umfassen: den Orchestrator (z.B. einen der folgenden Dienste: Download Manager, Authenticator, Controller), den Message Server, den HMI-Dienst, den Policy Service, den Status Service oder den Health Monitor Service. Der eSync-Client kann Updates empfangen, das Update überprüfen und dann die Updates an den richtigen eSync-Agenten innerhalb des Fahrzeugs, mit dem er kommuniziert, übertragen.
  • Die eSync-Cloud kann den eSync-Server hosten und in einer beliebigen Cloud wie Amazon Web Services (AWS), Azure oder der privaten Cloud eines OEM angesiedelt sein. eSync-Elemente können aus einem eSync-Client und seinen Unterkomponenten bestehen, wobei einzelne oder mehrere kombinierte eSync-Agenten als eSync-Elemente bezeichnet werden können. Der eSync-Monitor kann ein Teil des eSync-Clients sein und eine, eine beliebige Kombination oder alle der folgenden Aufgaben übernehmen: Überwachung, Wiederherstellung oder Neustart von Unterkomponenten des eSync-Clients (z.B. HMI Service, Policy Service, Orchestrator) und eSync Agents. Der eSync Server kann zur Speicherung von Updates, zur Durchführung von Kampagnen, zur Angabe des Fahrzeugstatus und/oder zur Kommunikation mit Geräten im Feld und zur Berichterstattung an den Benutzer verwendet werden. Ein eSync-Baum kann die Registrierung der Konfiguration des eSync-Clients, Agentenzertifikate und einen dauerhaften Speicher umfassen.
  • 1 zeigt ein Blockdiagramm 100, das ein Beispiel für eSync-Agenten im Fahrzeug darstellt (wie in den eSync Alliance Specifications v1.0 definiert). Beispiele für eSync-Agenten sind im US-Patent Nr. 10,834,206 offenbart, das hierin vollumfänglich durch Bezugnahme eingebunden wird. 1 zeigt insbesondere drei Steuergeräte mit unterschiedlicher Funktionalität, die eine standardisierte Schnittstelle zum eSync-Client darstellen. Eine geringere oder größere Anzahl von Steuergeräten ist denkbar. Die systemeigene Schnittstelle kann unter der standardisierten (z.B. abstrahierten) Schnittstelle verborgen sein, die jedes Gerät dem eSync-Client beim Einschalten präsentiert. Die dargestellte Funktionalität umfasst eine oder beide der folgenden Funktionen: (1) Updates (z.B. in Form eines Update-Controllers) und (2) Datenerfassung.
  • So können sich Steuergeräte in verschiedenen Netzwerksegmenten oder Bussen innerhalb desselben Fahrzeugs befinden. So kann beispielsweise eine beliebige Kombination aus Telematikeinheit, Antriebsstrang, Infotainment, Fahrerassistenzsystemen (ADAS) und Fahrwerk eine Vielzahl von Steuergeräten beherbergen, die mit verschiedenen Netzwerkbussen (z.B. einem oder beiden CAN- und LIN-Bussen) verbunden sind. Der OEM kann ein Software-Repository unterhalten, das Software-Updates enthält, die sowohl vom OEM als auch von Zulieferern stammen. Ein OEM kann Software-Updates an alle in Frage kommenden Fahrzeuge verteilen, oder ein Fahrzeug kann die neuesten bekannten Software-Updates beziehen. Einige Gateway-ECUs oder Telematik- und Infotainment-ECUs haben eine drahtlose Verbindung zum Internet. Updates können über diese sichere drahtlose Verbindung oder über physische Verteilungskanäle wie Händler, vom Kunden eingesteckte USB-Sticks oder OBDII-Anschlüsse, die normalerweise für die Diagnose reserviert sind, an die Fahrzeuge verteilt werden.
  • In diesem Zusammenhang kann das Update von Steuergeräten und elektronischen Systemen in einem Fahrzeug, das von mehreren Lieferanten und Anbietern hergestellt wurde, eine mühsame Aufgabe sein und Tage dauern, um die gesamte elektronische Hardware in einem bestimmten Fahrzeug mit neuerer Software upzudaten. Möglicherweise muss das Fahrzeug für ein Software-Update auch zum Service-Center gefahren werden. Dies kostet die OEMs und Händler mehrere Tausend Dollar und ist für die Fahrzeugbesitzer sehr ärgerlich. In einer oder einigen Ausführungsformen kann die eSync-Plattform eine OTA-Lösung ermöglichen, die dem „Server-Client-Agent“-Modell folgt, wobei sich mehrere „Agenten“ auf verschiedenen Systemen im Fahrzeug befinden können, um die vom Client empfangenen und vom Server gesendeten Updates durchzuführen, wie weiter unten erläutert.
  • Im Fahrzeug können verschiedene Geräte vorhanden sein, einschließlich eines, einer Kombination oder aller Steuergeräte 130, Hochleistungscomputer (HPCs) 140 oder Sensoren 150. Jedes Gerät, unabhängig davon, ob es sich um ein Steuergerät 130/HPC 140/Sensor 150 handelt, hat die Möglichkeit, entweder nur Agenten zu haben, die Updates für das Steuergerät bereitstellen, oder Agenten, die sowohl Updates für das Steuergerät als auch Funktionen zur Datenerfassung von diesem bereitstellen. Darüber hinaus kann jede Erörterung im vorliegenden Zusammenhang, die sich auf ein Steuergerät bezieht, auch auf jede andere Art von elektronischem Gerät im Fahrzeug angewendet werden, wie z.B. HPCs oder Sensoren.
  • Der Entwickler hat somit die Flexibilität, die vom Steuergerät benötigte Funktionalität zu integrieren, und diese Agenten können bei Bedarf upgedated werden, um zusätzliche Informationen hinzuzufügen, die vom Steuergerät benötigt werden könnten. In der Praxis können die Agenten, sobald sie mit allen Funktionen in das Gerät geschrieben wurden, Over-the-Air (OTA) bereit sein, während sie entworfen werden.
  • Wenn ein Agent mit vollem Funktionsumfang bei der ersten Einführung nicht erwünscht oder in Betracht gezogen wird, können die Agenten von einem externen Server, z.B. einem eSync-Server, mit einer neuen Software- oder Konfigurationsversion upgedated werden.
  • Der eSync-Agent kann speziell auf die Eigenschaften des spezifischen Steuergeräts zugeschnitten sein, dem er zugewiesen ist, und kann eine, einige oder alle der folgenden Funktionen bereitstellen, die auf das spezifische Steuergerät zugeschnitten sind: Authentifizierung, Aufzählung und andere Eigenschaften, um sich gegenüber dem eSync OTA-Client zu identifizieren. Wieder Bezug nehmend auf 1, kann der eSync-Client 102 mit einem oder mehreren eSync-Agenten 104, 106, 108 kommunizieren, z.B. über Ethernet, CAN-Bus, Flexray, USB oder Ähnliches. Ferner sind die eSync-Agenten 104, 106, 108 mit verschiedenen Funktionen dargestellt, wie z.B. Message-Broker-Schnittstellenmodul 110, Verschlüsselungs-/Entschlüsselungsmodul 112, Delta-Rekonstruktionsmodul 114, Richtlinienmodul 116, Update-Steuerungsmodul 118, Signaturvalidierungsmodul 122, Statusüberwachungsmodul 124, Rollback-Managementmodul 126, Datensammelmodul 128 und Geräteprogrammierschnittstellenmodul 120. Der Begriff Modul kann Software, Hardware oder eine Kombination aus Software und Hardware umfassen. Außerdem dient die in 1 gezeigte Unterteilung der Module lediglich der Veranschaulichung. Es sind auch andere Unterteilungen denkbar. Außerdem können verschiedene Funktionalitäten kombiniert werden.
  • Das Message-Broker-Schnittstellenmodul 110 ist so konfiguriert, dass es mit einem Message-Broker kommunizieren kann. Ein Beispiel hierfür ist im US-Patent Nr. 10,834,206 offenbart, das hierin vollumfänglich durch Bezugnahme eingebunden wird. Wie oben beschrieben, kann der Message Broker in einer oder einigen Ausführungsformen in einem eSync-Client, wie dem eSync-Client 102, untergebracht sein. In diesem Zusammenhang kann ein eSync-Client über den Message Broker mit einem oder mehreren eSync-Agenten, wie den eSync-Agenten 104, 106, 108, kommunizieren.
  • Mit dem Verschlüsselungs-/Entschlüsselungsmodul 112 können die Funktionen der Verschlüsselung und/oder Entschlüsselung vom eSync-Agenten 104, 106, 108 ausgeführt werden. In einer oder einigen Ausführungsformen kann aufgrund des Ende-zu-Ende-Sicherheitskonzepts in der eSync-Architektur die Nutzlast, die bis zum Endpunktgerät ankommt, gesichert und bis zu dem Punkt verschlüsselt werden, an dem das Flashing Tool auftritt. Abhängig von den Fähigkeiten des Steuergeräts kann ein eSync-Agent eine eingehende Nutzlast entschlüsseln. Typischerweise handelt es sich bei Steuergeräten um Geräte mit niedrigem Stromverbrauch und geringem Speicherplatz; daher kann die Entschlüsselung als optional betrachtet werden, kann aber je nach Implementierungsoptionen wichtig werden. Darüber hinaus können eSync-Agenten Daten sammeln und sie über einen eSync-Client an den eSync-Server senden. In solchen Fällen können die Daten vor der Übertragung vom eSync-Agent-System verschlüsselt werden. In diesem Zusammenhang kann der eSync-Agent ein Verschlüsselungsverfahren unterstützen.
  • So kann der eSync Agent eine verschlüsselte Nutzlast entschlüsseln und/oder die Nutzlast rekonstruieren, um das Steuergerät mit einem neuen Image zu flashen. Alternativ oder zusätzlich kann der eSync Agent alle von der ECU-Hardware gesammelten Daten verschlüsseln, bevor er sie an den eSync Client sendet. In der Regel kann der eSync Agent nicht auf dem Steuergerät, sondern außerhalb des Steuergeräts auf einem Gateway oder einer TBox (z.B. einem Gerät in der Nähe des Steuergeräts) laufen. In solchen Fällen kann der eSync-Agent, der sich an einem Ort außerhalb des Steuergeräts befindet, die Nutzdaten entschlüsseln und die entschlüsselten Nutzdaten übertragen. Der eSync-Agent kann auch eine Verschlüsselung der von dem/den Steuergerät(en) gesammelten Daten vornehmen, bevor er sie an den eSync-Client zur Weiterleitung an den eSync-Server sendet.
  • Mit dem Delta-Rekonstruktionsmodul 114 können die Funktionen des Delta-Updates, wie sie im US-Patent Nr. 10,834,207 offenbart sind, das hierin vollumfänglich durch Bezugnahme eingebunden wird, vom eSync Agent 104, 106, 108 ausgeführt werden.
  • Das Policy-Modul 116 kann Informationen enthalten, die den Zustand oder die Bedingungen definieren, unter denen das Steuergerät mit einem Update geflasht werden kann. Der eSync-Agent 104, 106, 108 kann das Policy-Modul 116 verwenden, um sicherzustellen, dass das Steuergerät für ein Update geeignet ist, und das Steuergerät entsprechend mit neuer Software flashen. In einer oder einigen Ausführungsformen können die Richtlinien von Steuergerät zu Steuergerät und von Hersteller zu Hersteller variieren. Als nur ein Beispiel kann die Richtlinie die Bedingungen angeben, unter denen das Update durchgeführt werden soll und/oder die Bedingungen, unter denen das Update nicht durchgeführt werden soll (z.B. sollte das Update nicht durchgeführt werden, wenn die Temperatur der Steuergeräteplatine > 100 Grad Celsius ist; das Update sollte nicht durchgeführt werden, wenn das mit dem eSync Agent verbundene Gerät bei der Herstellung upgedated wurde und einen Zeitraum hat, in dem es nicht upgedated werden sollte). In diesem Zusammenhang können die eSync-Agenten Richtlinien für das Update der Software festlegen (z.B. Benutzer-Opt-in oder Benutzer-Neuplanung und sogar spezifische gerätebezogene Richtlinien für das Steuergerät, z.B. dass das Gerät bei der Herstellung geupdated wurde und einen Zeitraum hat, in dem es nicht upgedated werden sollte).
  • Das Update-Controller-Modul 118 kann so konfiguriert werden, dass es die verifizierten oder rekonstruierten Updates an die Geräteprogrammierschnittstelle weiterleitet, um den endgültigen Steuergerätespeicher zu flashen.
  • Das Signaturvalidierungsmodul 122 kann so konfiguriert werden, dass es eine elektronische Signatur verifiziert und/oder validiert und damit sicherstellt, dass die eingehende entschlüsselte Nutzlast oder deltarekonstruierte Nutzlast die korrekte Signatur enthält, bevor sie an das Geräteprogrammierschnittstellenmodul 120 gesendet wird.
  • Das Statusüberwachungsmodul 124 kann so konfiguriert werden, dass es den Status des Geräts kennt, so dass er an den eSync Client und den eSync Server gemeldet werden kann. Verschiedene Aspekte des Status sind denkbar, einschließlich einer, einer Kombination oder aller der folgenden: Implementierung bestimmter Funktionsaufrufe über die Programmierschnittstelle des Geräts, um den Status des Flash-Fortschritts oder der Leistung zu kennen (z.B. laufend, abgeschlossen und/oder fehlgeschlagen); Lesen der Versionsnummer und Weitergabe der Informationen an den eSync-Client für andere Dienste (z.B. Anzeige auf der HMI); oder Einbindung von Speicherintegritätsprüfungen, um den Zustand des Speichers, des verfügbaren Speichers, des unter Quarantäne gestellten Speichers auf dem Steuergerät
  • Wie bereits erwähnt, kann ein Software-Update aus einer Vielzahl von Gründen fehlschlagen. Daher ist es wichtig, ein Steuergerät in dem besten oder letzten bekannten guten Zustand zu belassen, wenn ein bestimmtes Update fehlschlägt. Das Rollback-Management-Modul 126 ist so konfiguriert, dass es die erforderlichen Prüfungen und Funktionen bereitstellt, um ein Rollback der vorherigen Arbeitsversion auf ein Steuergerät zu erreichen. Dies kann mit einer sorgfältigen Bewertung durchgeführt werden; andernfalls könnte eine böswillige Entität diese Rollback-Operation initiieren und die Gesamtfunktion des Steuergeräts beeinträchtigen.
  • Als solches kann das Rollback-Management-Modul 126 eine, eine beliebige Kombination oder alle der folgenden Funktionen ausführen: Zurücksetzen der Software auf eine frühere Version in Abhängigkeit von den Update-Bedingungen der Kampagne; Verwalten des Rollbacks von fehlgeschlagenen oder fehlerhaften Updates, die in Steuergeräte geflasht wurden; Bereitstellen der erforderlichen Funktionen und Schnittstellen, um zu prüfen, ob ein Rollback zulässig ist und wenn ja, auf welche Version zurückgesetzt werden sollte; oder Versuchen, das Rollback eine vorgegebene Anzahl von Malen durchzuführen (z. B. wenn ein Update nicht geflasht werden kann, kann der eSync-Agent ein Kampagnen-Flag prüfen (falls vorhanden), das die Fähigkeit bietet, die Software nach einer vorgegebenen Anzahl von Wiederholungen auf einen früheren Zustand zurückzusetzen).
  • In einer oder einigen Ausführungsformen kann die Versions-Rollback-Funktion von eSync Agent gesteuert werden. Insbesondere kann in einer oder einigen Ausführungsformen nur für die erste Version einer Komponente ein Rollback-Wert in der manifest.xml definiert sein, der auf die EOL-Version (Werksversion) verweist. Ansonsten darf keine der zukünftigen Versionen einer Komponente das Rollback-Feld in ihrer manifest.xml haben. Wenn ein Update einer Komponente fehlschlägt, wird erwartet, dass der eSync-Agent das Rollback mit einer lokalen Kopie der „letzten bekannten“ Version durchführt (z.B. eine Softwareversion, die die Komponente wieder in den erfolgreichen Zustand versetzt. Da diese Rollback-Version möglicherweise nicht aus dem Manifest stammt, kann der eSync-Client diese Information vom Update-Agenten erhalten und an den Server zurückmelden.
  • Wenn der eSync-Client zum ersten Mal mit den Update-Agenten kommuniziert (z.B. über die Querypackage-Nachricht), kann er von allen Update-Agenten die installierten Versionen und alle verfügbaren Versionsangaben abfragen. Die Update-Agenten können als Antwort die Informationen über die installierte und die verfügbare Version senden. Die von den Update-Agenten ausgetauschten Informationen können eine, eine beliebige Kombination oder alle der folgenden Angaben enthalten:
    • Name: Gleich wie in der Abfrage.
    • Typ: Gleich wie in der Abfrage.
    • Replyid: Gleiche wie in der Abfrage.
    • Version: Installierte Version. Wenn keine Version installiert ist, sollte der Wert JSON null sein.
    • Deltacap: Verfügbare Deltafähigkeit, die vom Server zur Erzeugung eines Deltabinärs verwendet wird.
    • Versionsliste: Liste aller zu diesem Zeitpunkt verfügbaren Versionen des Pakets und deren Informationen wie.
    • Version: <binary file location>, <SHA256 value>, <downloaded: true/false>
  • Das Flag „downloaded“ gibt an, ob die Kopie der versionierten Binärdatei lokal für die Delta-Rekonstruktion und das Rollback verfügbar ist. Das Flag downloaded=true bedeutet, dass die Version lokal verfügbar ist und für die Delta-Rekonstruktion und das Rollback verwendet werden kann. Wenn eine Version als verfügbar aufgeführt ist (z.B. downloaded = true), aber nicht den SHA256-Wert in der Liste hat, wird diese Version nicht für die Delta-Rekonstruktion berücksichtigt.
  • Dadurch kann der eSync-Client die Informationen über die verfügbaren Versionen erhalten. Außerdem kann das Update-Agent-Modul die „Rollback-Reihenfolge“ für jede der verfügbaren Versionen angeben, wobei Null die höchste Priorität ist. In einer oder einigen Ausführungsformen können keine zwei Versionen die gleiche Priorität haben. Wenn die Installation der Zielversion fehlschlägt, kann der eSync-Agent außerdem seinen lokalen Speicher auf die Verfügbarkeit der letzten bekannten funktionierenden Version überprüfen. Die Information über die letzte bekannte funktionierende Version kann vom eSync-Client in der Nachricht „readyupdate“ (unter der Eigenschaft „rollbackversions“) bereitgestellt werden.
  • Wenn der Update-Agent die Version findet, versucht er, diese Version zu installieren. Bei Erfolg wird der Status in einer „Update-Status“-Meldung mit Informationen über die Zielversion und die Rollback-Version an eSync Client aktualisiert.
  • Wenn das Update-Agent-Modul die installierte Binärversion nicht lokal findet, kann es außerdem den Status „INSTALL_FAILED“ senden. In einer oder einigen Ausführungsformen kann der eSync-Client die Binärdatei der Rollback-Version niemals herunterladen. Wenn die „letzte bekannte Arbeitsversion“ lokal nicht verfügbar ist, darf das Update-Agent-Modul (das Teil des Update-Controller-Moduls 118 sein kann) sie nicht als verfügbar melden. Stattdessen sollte das Abfrage-Paket das Flag downloaded = false haben.
  • Wenn das Update-Agent-Modul die Version findet, aber nicht installieren kann, kann das Update-Agent-Modul versuchen, weitere Versionen zu installieren, falls diese verfügbar sind. Die Informationen über die anderen Versionen können vom eSync-Client auf der Grundlage der Antwort des Update-Agenten auf die Paketanfrage bereitgestellt werden. Im Erfolgsfall kann das Update-Agent-Modul den eSync-Client mit dem Status aktualisieren.
  • Gelingt es dem Update-Agent-Modul schließlich nicht, alle verfügbaren Versionen zu installieren, kann es den Status „INSTALL_FAILED“ senden und das Flag „terminal-failure“= true setzen, um dem eSync-Client mitzuteilen, dass er nicht mehr versuchen soll, die Zielversion zu installieren.
  • In einer oder einigen Ausführungsformen kann der eSync-Client, wenn das Update-Agent-Modul die Installation der Version als erfolgreich meldet, eine Nachricht „confirm-update“ senden, in der das Update-Agent-Modul aufgefordert wird, die installierte Version als „letzte bekannte Arbeitsversion“ zu speichern. Als Reaktion auf den Erhalt dieser Nachricht kann das Update-Agent-Modul die installierte Version speichern und das Versionsverzeichnis aktualisieren (falls die installierte Version nicht direkt vom Gerät gelesen wird).
  • Wenn der eSync-Client ein nichtpersistentes Atomic-Paket als fehlgeschlagen meldet, kann das Update-Agent-Modul angewiesen werden, zu seiner vorherigen Version zurückzukehren (selbst wenn die Zielversion erfolgreich war). Das Update-Agent-Modul kann auf die vorherige Version zurücksetzen und den Status an den eSync-Client aktualisieren. Wenn der eSync-Client die Nachricht „confirm-update“ sendet, kann das Update-Agent-Modul die installierte Version in seinem lokalen Speicher als „letzte bekannte Arbeitsversion“ speichern.
  • Beim Ausfall eines nichtpersistenten Atomic-Pakets und anschließendem Rollback kann eine Komponente des Pakets, für die keine Rollback-Version aufgeführt ist, im aktuellen Zustand verbleiben (z.B. installiert oder fehlgeschlagen). Wenn bei einem nichtpersistenten Atomic-Paket und anschließendem Rollback eine andere Komponente ausfällt (Rollback), kann diese Komponente INSTALL_FAILED melden. Daraufhin darf der eSync-Client die Komponenten (im Paket) nicht mehr zum Rollback auffordern. In einem solchen Szenario kann die SOTA-Benutzeroberfläche einen Erfolg für die erfolgreich installierten Komponenten und einen Misserfolg für die fehlgeschlagenen Komponenten anzeigen.
  • So kann der Update-Agent (z.B. der Master-Update-Agent) auf eine Update-Richtlinie (z.B. im Richtlinienmodul 116) zugreifen, um zu bestimmen, ob/welche Software in den elektronischen Geräten, die mit dem/den Update-Agenten verbunden sind, zurückgesetzt werden soll (z.B. ob die Software der elektronischen Geräte, die mit dem MasterUpdate-Agenten und/oder den zugehörigen Follower-Update-Agenten verbunden sind, die vom Master-Update-Agenten überwacht werden, zurückgesetzt werden soll). Beispielsweise kann die Update-Richtlinie angeben, dass ein Fehler in einem oder einigen dem Update-Prozesse in den elektronischen Geräten zu einem globalen Rollback für alle elektronischen Geräte führt (z.B. führt ein einziger Fehler dazu, dass alle elektronischen Geräte zu ihren vorherigen Versionen zurückkehren und die Rückkehr an den Cloud-Server melden). Als weiteres Beispiel kann die Update-Richtlinie angeben, dass ein Fehler in einem oder einigen dem Update-Prozesse nur in den ausgefallenen Geräten zu einem Rollback führt (z.B. wenn die Update-Richtlinie angibt, dass ein Rollback nur in ausgefallenen oder abhängigen elektronischen Geräten stattfindet, dann wird das Rollback nur auf den elektronischen Geräten durchgeführt, die als ausgefallen markiert wurden). Wenn beispielsweise ein Fehler bei dem Update der Software für ein wesentliches Steuergerät auftritt (z.B. kann ein „wesentliches“ Steuergerät so definiert sein, dass es eine bestimmte Funktion, wie z.B. eine Sicherheitsfunktion, für das Fahrzeug ausführt), aber kein Fehler bei dem Update der Software für ein nicht wesentliches Steuergerät (z.B. kann ein „nicht wesentliches“ Steuergerät so definiert sein, dass es eine bestimmte Funktion, wie z.B. eine Sicherheitsfunktion, für das Fahrzeug nicht ausführt), kann der Master-Update-Agent den Rollback aller Steuergeräte unter seiner endgültigen Kontrolle veranlassen (z.B. in dem Fall, dass der Master-Update-Agent mit dem wesentlichen Steuergerät verbunden ist und die Update-Agenten mit nicht wesentlichen Steuergeräten verbunden sind, führt der Master-Update-Agent das Rollback der Software für das wesentliche Steuergerät durch und weist die nachfolgenden Update-Agenten an, das Rollback der Software für die nicht wesentlichen Steuergeräte durchzuführen). Im umgekehrten Fall, wenn ein Fehler bei dem Update der Software für ein nicht wesentliches Steuergerät auftritt, aber kein Fehler bei dem Update der Software für das wesentliche Steuergerät, kann der Master-Update-Agent einige oder alle Update-Agenten, die mit den nicht wesentlichen Steuergeräten verbunden sind, anweisen, das Rollback durchzuführen (z.B., in einer oder einigen Ausführungsformen kann der Master-Update-Agent das Rollback der Software für alle nicht wesentlichen Steuergeräte anweisen, nachdem ein Fehler bei der Software-Update für eines oder mehrere der nicht wesentlichen Steuergeräte festgestellt wurde; alternativ kann der Master-Update-Agent das Rollback der Software nur für die nicht wesentlichen Steuergeräte anweisen, bei denen ein Fehler bei der Software-Update aufgetreten ist). Auf diese Weise kann der Master-Update-Agent auf der Grundlage der im Master-Update-Agenten residenten oder ihm zugeordneten Richtlinie bestimmen, ob das Rollback durchgeführt werden soll. In einem bestimmten Fall kann die Richtlinie angeben, dass ein Fehler bei der Software-Update in einem elektronischen Gerät unter der endgültigen Kontrolle des Master-Update-Agenten den Master-Update-Agenten anweist, die Software für alle elektronischen Geräte unter der endgültigen Kontrolle des Master-Update-Agenten zurückzusetzen. In einem anderen speziellen Fall kann die Richtlinie angeben, dass ein Fehler bei der Software-Update in einem elektronischen Gerät unter der letztendlichen Kontrolle des Master-Update-Agenten den Master-Update-Agenten anweist, (1) eine Klasse oder einen Typ zu bestimmen, die bzw. der in der Software enthalten ist: (1) eine Klasse oder einen Typ von elektronischem Gerät zu bestimmen, bei der bzw. dem der Fehler auftrat (z.B. ein nicht wesentliches Steuergerät oder ein wesentliches Steuergerät); und (2) als Reaktion auf die Bestimmung der Klasse oder des Typs des elektronischen Geräts, bei der bzw. dem der Fehler auftrat, zu bestimmen, welche Geräte zurückgesetzt werden sollen (z.B. als Reaktion auf die Feststellung, dass der Fehler in einem wesentlichen Steuergerät auftrat, alle elektronischen Geräte unter der endgültigen Kontrolle des Master-Update-Agenten zurücksetzen; als Reaktion auf die Feststellung, dass der Fehler in einem nicht wesentlichen Steuergerät auftrat, einige oder alle nicht wesentlichen Steuergeräte unter der endgültigen Kontrolle des Master-Update-Agenten zurücksetzen). Auf diese Weise kann der Master-Update-Agent über die Intelligenz verfügen, die Software-Update und/oder das Rollback ohne Abhängigkeit vom eSync-Client durchzuführen.
  • Wie bereits erwähnt, gibt es eine Vielzahl von Gründen für ein Scheitern der Software-Update, darunter: Übertragungsfehler, Update-Fehler, Fehler während des Update-Prozesses oder funktionale Nichtleistung nach dem Update. Während ein Übertragungsfehler die Wiederaufnahme der Verbindung zur Cloud erforderlich machen kann, können andere Fehler in Abhängigkeit von bestimmten Aspekten, z.B. dem mit einem Steuergeräteausfall verbundenen Risiko, durch einen lokalen Cache im Fahrzeug verwaltet werden. Als ein Beispiel kann die folgende Rollback-Strategie verfolgt werden: für Steuergeräte mit hohem Risiko werden 2 oder 3 lokale Versionen dieser Steuergeräte-Firmware empfohlen; für Steuergeräte mit geringem Risiko wird 1 lokale Version empfohlen; und für Steuergeräte ohne Risiko wird keine lokale Version benötigt (z.B. kann in diesem Fall jedoch das vorherige Rollback-Update aus der Cloud bezogen werden. Diese Strategie kann den Bedarf an lokalem Cache-Flash-Speicher eliminieren).
  • Abhängig von der Anzahl der Steuergeräte und der damit verbundenen Anzahl der erforderlichen Sicherungen muss der zusätzliche Flash-Speicherbedarf im Fahrzeug (falls vorhanden) berechnet und zugewiesen werden. Um eine feste Basislinie (Version 1.0) zu ermöglichen, werden alle Deltas von dieser Basislinie aus für das Rollback berechnet.
  • Wenn das Steuergerät ein solches Rollback unterstützt, kann es möglich sein, eine neue und eine alte Steuergeräte-Firmware innerhalb des Steuergeräts zu speichern und einfach auf die alte Firmware zurückzugreifen, wenn die neue Firmware nicht den Spezifikationen entspricht. Jedes dieser Steuergeräte kann den doppelten Speicherbedarf haben. Diese Methode ist die schnellste Methode der Rollback-Wiederherstellung.
  • Wenn die Fahrzeugarchitektur ein fahrzeuginternes Rollback unterstützt, kann es möglich sein, dass ein Speicher außerhalb des Steuergeräts vorhanden ist. Dieser Speicher kann groß genug sein, um eine Kopie der letzten Arbeitsversion aller ECU-Updates sowie einen zusätzlichen Puffer zu speichern. In der Regel wird empfohlen, dass der Puffer 25-100 % der Gesamtmenge aller Updates umfasst.
  • Was den Versicherungskernel betrifft, so ist der Versicherungskernel eine proprietäre ausfallsichere Strategie, bei der nur ein begrenzter Speicher auf dem System verfügbar ist. Diese Methode kann jedoch hardwarespezifisch sein und den Zugriff auf den Bootloader jedes Steuergeräts erfordern, weshalb sie kundenspezifisch entwickelt werden kann.
  • Im Hinblick auf ein Händler-Service-Szenario ist es zwar unwahrscheinlich, aber möglich, dass das Steuergerät während eines Updates „gebrannt“ wird und keine der oben beschriebenen Rollback-Strategien in der Lage ist, es wiederherzustellen. In diesem Fall muss der Fahrzeughalter informiert und das Fahrzeug zur nächsten Werkstatt gebracht werden, um ein manuelles Steuergeräte-Update durchzuführen.
  • Im Hinblick auf das Datenerfassungsmodul 128 können die Diagnoseinformationen einen oder beide Typen umfassen: (1) OTA-bezogen; oder (2) fahrzeugbezogen. Die OTA-Diagnose kann Daten über Erfolg oder Misserfolg, die für das Update des Steuergeräts benötigte Zeit und die Anzahl der Wiederholungsversuche enthalten. Die Fahrzeugdiagnose kann Informationen über den Zustand des Steuergeräts, Sensordaten und Diagnosefehlercodes enthalten. In regelmäßigen Abständen kann es wünschenswert sein, den Status und den Zustand des Steuergeräts zu erfahren, Diagnoseinformationen zu erhalten und diese über den eSync-Client mit dem eSync-Server zu teilen. Das Data Gathering-Modul 128 in eSync kann diese Funktionen und Schnittstellen bereitstellen, um Daten aus dem Steuergerät zu extrahieren und an den eSync-Server zu übertragen.
  • Das Modul 120 der Geräteprogrammierschnittstelle kann so konfiguriert sein, dass es eine Vielzahl von Funktionen für den eSync-Agenten übernimmt. Die Geräteprogrammierschnittstelle kann eine, eine Kombination oder alle der folgenden Funktionen ausführen: Zugriff auf die Flash-Tools, wenn die Tools separat sind; Flashen der Binärdatei; oder Zugriff auf die vom Hersteller bereitgestellten Flash-Tools.
  • Insbesondere kann das Geräteprogrammierschnittstellenmodul 120 so konfiguriert sein, dass es die Steuergeräte programmiert (z.B. über eine CAN-Bus-Schnittstelle oder eine serielle Schnittstelle oder eine USB-Schnittstelle oder eine andere spezifische oder generische Schnittstelle) und kann von Steuergerät zu Steuergerät variieren. Alternativ oder zusätzlich kann das Modul 120 der Geräteprogrammierschnittstelle sicherstellen, dass das geflashte Image durch vom Steuergerätehersteller definierte Mechanismen korrekt ist und kann von Steuergerät zu Steuergerät variieren. Schließlich kann der eSync Agent das Device Programming Interface Modul 120 verwenden, um die Updates in den Programmspeicher des Steuergeräts zu programmieren. Selbst wenn die Hersteller der Endgeräte (z.B. Steuergerät 130, HPC 140 oder Sensor 150) nicht alle proprietären Aspekte der Endgeräte offenlegen, ermöglicht die standardisierte Schicht über das Device Programming Interface-Modul 120 eine standardisierte Software-Update, Datenerfassung und/oder Gerätesteuerung.
  • Die eSync-Spezifikation 1.0 kann auch einen Mechanismus vorsehen, mit dem der Agent außerhalb des Steuergeräts bei dem nächstgelegenen Domain Controller mit ausreichenden Ressourcen untergebracht werden kann, falls das Steuergerät nicht über genügend Ressourcen zur Unterbringung eines Agenten verfügt. Insbesondere kann ein Steuergerät, das nicht über ausreichende Verarbeitungs- und/oder Speicherkapazitäten verfügt, nicht in der Lage sein, die Funktionen eines Agenten auszuführen. In diesem Fall kann der Agent im nächstgelegenen Domain Controller untergebracht werden, der über die Ressourcen zur Verwaltung des Steuergeräts verfügt. Beispiele für solche Steuergeräte, die nicht über ausreichende Ressourcen verfügen, sind ältere Geräte, die traditionell ihre eigenen Updates nicht verwalten. Bestimmte CAN-Geräte können jedoch mit einem UDS-Server (Universal Diagnostic Services) ausgestattet sein, um Updates zu ermöglichen. Darüber hinaus kann sich der Agent im Domain Controller befinden und auch auf LIN-Geräte (Local Interconnected Network) angewendet werden. Somit können die Architektur und insbesondere die Agenten (und die Funktionalität der Agenten) auf verschiedene Anwendungen angewendet werden, einschließlich der Anpassung an ältere Steuergeräte.
  • Insbesondere gibt es Fälle, in denen die Steuergeräte weniger leistungsfähig sind, wenig Speicherplatz zur Verfügung haben und einige der Eigenschaften von eSync Agent (wie z.B. Delta-Rekonstruktion und/oder Ver-/Entschlüsselung) auf dem Steuergerät nicht ausgeführt werden können. In solchen Fällen kann der eSync Client modifiziert werden, um den Einschränkungen eines solchen Steuergeräts gerecht zu werden und das Steuergerät über einen anderen Mechanismus upzudaten. Solche Steuergeräte können ein klassisches AUTOSAR-konformes Steuergerät sein, mit Software-Komponente, RTE und Basis-Software, die auf einer bestimmten Hardware laufen.
  • In einer solchen Situation kann der eSync-Client eines, eine beliebige Kombination oder alle der folgenden Verfahren durchführen: Kommunikation mit dem eSync-Server, um festzustellen, ob neue Updates für das Steuergerät verfügbar sind; Kommunikation mit einem Agenten (als Spezialagent bezeichnet), der die eSync-Bus-Nachrichten in CAN-Bus-Nachrichten übersetzt; Empfang der CAN-Nachricht und Fortfahren mit dem Schreiben in den Flash-Speicher auf der Grundlage des Flash-Konstrukts oder Designs. Darüber hinaus kann die Softwarekomponente RTE und Basissoftware verwenden, um auf das Flash zuzugreifen, und zwar für eine, eine beliebige Kombination oder alle der folgenden Funktionen: Lesen/Schreiben des Flash, SHA-Verifizierung oder Zurücksetzen des Bootloaders.
  • Der Special Agent kann eine, eine beliebige Kombination oder alle der folgenden Funktionen ausführen: Übersetzen von eSync-Nachrichten (z.B. Query Version, Download Ready, Update Ready) in CAN-Nachrichten als Befehle; Teilnahme an der eSync-Bus-Nachricht, um die entsprechenden Agent-Nachrichten zu abonnieren (z.B. können einige der Nachrichten erforderlich sein, um die Anfrage in das CAN-Nachrichtenformat umzuwandeln und an das Steuergerät zu senden); Speichern der Arbeitskopie der Nutzdaten im Sicherungsordner (z.B. kann diese Kopie als Referenzkopie für den Server zur Erstellung eines Delta-Pakets verwendet werden); Übertragen der Nutzdaten an das Steuergerät diese Kopie kann als Referenzkopie für den Server zur Erstellung eines Deltapakets verwendet werden); Rekonstruktion der nächsten Version aus dem erhaltenen Deltapaket zur Verwendung im Falle eines fehlgeschlagenen Upgrades des Steuergeräts; Übertragung der Nutzdaten in den Flash des Steuergeräts und Anweisung zur Rekonstruktion der neuen Anwendung in der Backup-Flash-Partition; Anweisung an das Steuergerät, umzuschalten (z.B. kann dies dem Bootloader im Steuergerät erlauben, die Umschaltung vorzunehmen und in die neue Version der Anwendung zu booten); die Version abfragen, um zu bestätigen, dass das neue Update geflasht ist und funktioniert, und den Server informieren, dass das Update abgeschlossen ist; wenn der spezielle Agent einen Fehler feststellt, dann die vollständige neue Version von BA auf das Steuergerät übertragen; oder die Nachrichten an den eSync-Agent senden, der als Softwarekomponente läuft.
  • Die Softwarekomponente kann eine, eine beliebige Kombination oder alle der folgenden Funktionen ausführen: Authentifizierung des Servers und Aufbau einer sicheren Verbindung; Herunterladen und Verifizieren der Pakete; Entschlüsseln des Pakets; Berechnen des Hashwerts und Verifizieren; Schreiben in den Flash-Speicher; oder Verwendung einer API, um einen Wechsel zum Bootloader einzuleiten, um den Update-Vorgang abzuschließen (z.B. wird erwartet, dass der Bootloader das Ergebnis des im nächsten Zyklus durchgeführten Updates zurückgibt).
  • Das Flash-Konstrukt kann auf eine der folgenden Weisen ausgeführt werden: (i) A/B zwei gleichwertige Partitionen; oder (ii) A, B eine Backup- und eine aktive Partition. Außerdem kann die Softwarekomponente den Bootloader über die Verfügbarkeit des neuen Updates in den Flash-Konstrukten informieren, z.B. „neue Version in B, B nach A kopieren und von A aus ausführen“.
  • Im Hinblick auf das A/B-Flash-Update-Schema kann die eSync-Softwarekomponente eine AUTOSAR-Anwendung umfassen, die eine Schnittstelle mit dem Steuergerät-BsW für eine, eine beliebige Kombination oder alle der folgenden Funktionen bilden kann: Nutzdatenübertragung, Abfrage der Version, Delta-Rekonstruktion oder Update. Ferner kann die eSync-Softwarekomponente aufgerufen werden, wenn das Deltapaket geliefert wird, wobei das Deltamodul das empfangene Deltapaket validiert und die Rekonstruktion der neuen Version auf der Grundlage des aktuellen Referenzbildes im aktiven Speicher beginnt. Nach der Rekonstruktion kann die SHA erneut berechnet werden, und bei Erfolg kann der Bootloader aufgerufen werden, um die Version von der aktuellen Aktivität auf die neue Version umzuschalten. Das Delta-Rekonstruktionsmodul in der Softwarekomponente kann Zugriff auf den Flash-Speicher benötigen, um das Referenzbild zu lesen und das neue rekonstruierte Bild in die Sicherungspartition zu schreiben. Außerdem kann der Paketvalidator Zugriff auf den Flash-Speicher benötigen, um das neu rekonstruierte Abbild zu lesen.
  • In Bezug auf den Bootloader kann der Bootloader ein Flag im nichtflüchtigen Speicher überprüfen. Findet der Bootloader eine neue Version der Software, kann er auf die neue Version umschalten und das Flag löschen, so dass die neue Version anschließend hochgefahren wird.
  • Im Hinblick auf das Update-Schema „Erase and Write“ (Löschen und Schreiben) enthält die App möglicherweise nicht viel anderen Code als den, das Steuergerät in den erweiterten Diagnosemodus zu versetzen. Im Hinblick auf den eSync-Delta-Rekonstruktor im Bootloader kann BA im Bootloader-Modus das Delta-Paket streamen und die Rekonstruktion kann beim Empfang der Daten erfolgen. Wenn die Validierung fehlschlägt, kann das komplette Paket von BA an das Steuergerät gestreamt werden, während es sich noch im Bootloader-Modus befindet.
  • Im Hinblick auf den Bootloader kann der Bootloader den Delta-Rekonstruktor nutzen, um die neue Version zu erstellen, während das Delta einströmt. Dadurch kann das Steuergerät mit dem Delta-Paket anstelle des vollständigen Pakets upgedated werden. Wenn die Delta-Rekonstruktion erfolgreich ist und die Validierung erfolgreich ist, kann ein Wechsel zur neuen Version durchgeführt werden. Schlägt die Delta-Rekonstruktion fehl, kann die BA das Paket-Streaming nach Deaktivierung des Deltas neu starten. Wenn jedoch das Update nach dem erneuten Versuch fehlschlägt, kann die BA eine frühere Kopie erneut flashen, um das Rollback durchzuführen und so das Steuergerät wiederzubeleben.
  • Bei seriellen Bussen, wie z.B. CAN/LIN, können viele Steuergeräte am selben Bus hängen und einzeln angesprochen werden. In einer solchen Architektur müssen jedoch Updates für jedes Steuergerät seriell durchgeführt werden, da sich alle Geräte auf demselben seriellen Bus befinden. Da es sich bei den meisten CAN/LIN-Steuergeräten um Legacy-Geräte handelt, die keine eigenen Update-Agenten haben, befinden sich in einer Ausführungsform die Update-Agenten in den nächstgelegenen Domain Controllern.
  • Technisch gesehen kann zwar jedes adressierbare Gerät einen eigenen Agenten im Domänencontroller haben, aber aus Gründen der Bequemlichkeit und der Verwaltung können alle separaten Agenten zu einem einzigen Master-Agenten zusammengefasst werden (z.B. in einer Gruppe). Im Folgenden wird das Konzept des Master-Agenten erläutert.
  • Es werden verschiedene Implementierungen der Agentenarchitektur in Erwägung gezogen. In einer Implementierung können ein oder mehrere Master-Agenten in verschiedenen Abschnitten der Architektur platziert werden, um eine oder mehrere Gruppen von elektronischen Geräten (wobei die Gruppen aus einem einzigen elektronischen Gerät oder mehreren elektronischen Geräten bestehen können) in der Fahrzeugarchitektur upzudaten. In einer anderen Implementierung können Mikroagenten verwendet werden, die innerhalb der Architektur verteilt und positioniert werden, um in die elektronische(n) Vorrichtung(en), die einem Software-Update unterzogen werden, integriert oder mit ihnen verbunden zu werden. In einer weiteren Implementierung kann eine Kombination aus Master-Agent(en) und Mikro-Agent(en) verwendet werden.
  • 2A ist ein Blockdiagramm 200 von Steuergeräten (z.B. ECU1 220, ECU2 222, ECU3 224) auf separaten Bussen (z.B. separate CAN-Busse einschließlich CAN1, CAN 2 und CAN 3). Insbesondere ermöglicht die in BILD 2A dargestellte Architektur die Verwaltung älterer CAN-Geräte mit UDS (Unified Diagnostic Services). 2A veranschaulicht insbesondere die Verwendung eines Clusters in einem Gateway, das drei Agenten umfasst (oder aus ihnen besteht), z.B. Update Agent (A1) 212, Update Agent (A2) 214 und Update Agent (A3) 216. In einem solchen Fall können die drei Agenten mit dem Update von jeweils drei separaten Steuergeräten beauftragt werden, wobei jeder Agent einem Steuergerät auf demselben oder verschiedenen CAN-Bussen zugewiesen ist. Beispielsweise ist Update Agent (A1) 212 mit dem Update der Software für Steuergerät 1 220, Update Agent (A2) 214 mit dem Update der Software für Steuergerät 2 222 und Update Agent (A3) 216 mit dem Update der Software für Steuergerät 3 224 beauftragt. 2A zeigt einen CAN-Bus mit drei repräsentativen Steuergeräten, die jeweils in unterschiedlichen Hardware-Konfigurationen und mit unterschiedlichen Agenten-Setups angeschlossen sind. Jeder CAN-Bus kann mit dem Domain Controller verbunden sein, der den Master-Agenten beherbergt (z.B. Gateway Master CAN Agent 210). Die Adressen können als hierarchische Adressen für das jeweilige Gerät und den/die zugehörigen Agenten aufgelöst werden. Als ein Beispiel kann die Adresse für ECU1 220 als /A1/CAN1/ECU1 aufgelöst werden.
  • Während des Einschaltvorgangs kann der Master-Agent validierte Adressen aller von ihm verwalteten Steuergeräte an den eSync Message Broker übermitteln. Zur Veranschaulichung sind in den drei repräsentative Konfigurationen dargestellt. Außerdem wird in jeder der gezeigt, wie die Adressen aufgelöst werden (z.B. die hierarchischen Adressen für jedes Steuergerät). Darüber hinaus veranschaulichen die , dass ein oder mehrere Update-Agenten einem jeweiligen elektronischen Gerät (z.B. einem jeweiligen Steuergerät) innerhalb des Fahrzeugs zugewiesen werden können. Beispielsweise können die Update-Agenten in einem Verhältnis von eins zu eins zugewiesen werden, wobei ein Update-Agent einem Steuergerät zugewiesen wird. Dies kann verwendet werden, wenn die Steuergeräte auf verschiedenen CAN-Bussen sitzen (z.B. wie in 2A gezeigt) oder wenn die Steuergeräte auf demselben CAN-Bus sitzen (z.B. wie im Blockdiagramm 230 in 2B gezeigt). Als weiteres Beispiel können Update-Agenten in einem Verhältnis von eins zu vielen zugewiesen werden, wobei ein Update-Agent einer Vielzahl von Steuergeräten zugewiesen wird (z.B. mindestens 2 Steuergeräte, mindestens 3 Steuergeräte, usw.). Dies kann verwendet werden, wenn die Steuergeräte auf verschiedenen CAN-Bussen sitzen (z.B. wie in 2A gezeigt) oder wenn die Steuergeräte auf demselben CAN-Bus sitzen (z.B. wie im Blockdiagramm 250 in 2C gezeigt). Wie in 2C dargestellt, enthält der Gateway Master CAN Agent 260 einen einzelnen Update Agenten (A1) 212.
  • Wie oben beschrieben, kann ein Master-Agent-Konzept auf die Steuerung älterer Geräte auf einem CAN-Bus angewendet werden. Alternativ oder zusätzlich kann der Master-Agent auf neuere Software-Organisation(en) innerhalb von Steuergeräten angewandt werden, einschließlich eines oder beider der folgenden Themen: (1) Verwaltung mehrerer virtueller Maschinen in Multi-Core-Steuergeräten; und (2) Verwaltung portionierter Prozesse innerhalb einer virtuellen Maschine. Darüber hinaus können CAN-Master-Agenten von einem fahrzeugexternen Gerät aus upgedated werden, z.B. von einem eSync-Server, der sich im Internet befindet.
  • So kann die Aufteilung der Architektur in verschiedene Agenten von einem oder mehreren Faktoren abhängen, einschließlich einem oder beiden von: der Architektur des Systems (z.B. dem einen oder mehreren CAN-Bussen); oder den Typen von Steuergeräten (ein erster Typ von Steuergeräten, der konfiguriert ist, einen ersten Funktionstyp, wie z.B. Bremsen, auszuführen, kann mit einem ersten Update-Agenten verbunden sein; ein zweiter Typ von Steuergeräten, der konfiguriert ist, einen zweiten Funktionstyp, wie z.B. Infotainment, auszuführen, kann mit einem zweiten Update-Agenten verbunden sein; usw.). Zum Beispiel kann ein bestimmter Agent einer Gruppe von Steuergeräten zugeordnet werden, die ein gemeinsames Software-Update haben. Alternativ oder zusätzlich können Agenten in Abhängigkeit von der Architektur zugewiesen werden. Zum Beispiel kann ein erster CAN-Bus einen ersten Satz von Steuergeräten enthalten, die einem ersten gemeinsamen Software-Update unterliegen (mit einem ersten Update-Agenten, der dem ersten Satz von Steuergeräten zugeordnet ist, um das erste gemeinsame Software-Update auf dem ersten CAN-Bus durchzuführen) und einen zweiten Satz von Steuergeräten, die einem zweiten gemeinsamen Software-Update unterliegen (mit einem zweiten Update-Agenten, der dem zweiten Satz von Steuergeräten zugeordnet ist, um das zweite gemeinsame Software-Update auf dem ersten CAN-Bus durchzuführen), und ein zweiter CAN-Bus kann einen dritten Satz von Steuergeräten, die dem ersten gemeinsamen Software-Update unterliegen (mit einem dritten Update-Agenten, der dem dritten Satz von Steuergeräten zugewiesen ist, um das erste gemeinsame Software-Update auf dem zweiten CAN-Bus durchzuführen) und einen vierten Satz von Steuergeräten, die dem zweiten gemeinsamen Software-Update unterliegen (mit einem vierten Update-Agenten, der dem vierten Satz von Steuergeräten zugewiesen ist, um das zweite gemeinsame Software-Update auf dem zweiten CAN-Bus durchzuführen), umfassen. Auf diese Weise kann die Agentenarchitektur flexibel auf verschiedene Architekturen und verschiedene Arten von Steuergeräten zugeschnitten werden.
  • 3 zeigt ein Blockdiagramm 300, in dem das Konzept des Master-Agenten auf Diagnostics over IP (DoIP) Update-Agenten im eSync-System (z.B. logische Assoziation) angewendet werden kann. Insbesondere wenn die Updates des Steuergeräts, wie ECU1 220, ECU2 222 und/oder ECU3 224, unter Verwendung von DolP (z.B. unter Verwendung von Ethernet-Konnektivität und mit einem DoIP-Server) durchgeführt werden sollen, kann ein DolP-Client 330 in den eSync-Update-Agenten (z.B. Master-Agent 320) integriert werden, wie in 3 dargestellt.
  • Das Diagramm in 3 zeigt logisch zusammengehörige Blöcke, die sich nicht unbedingt im selben SW-Block befinden müssen (z.B. kann sich der Agent in einem Gateway und der DolP-Server 340 in einem (über Ethernet verbundenen) Domänencontroller wie dem Domänencontroller 310 befinden). In einer anderen Konfiguration können sowohl die Agenten (z.B. der Master-Agent 320) als auch der DolP-Server 340 in demselben elektronischen Gerät (z.B. in einem Domain-Controller) untergebracht sein. Der Domain Controller kann dann die ECUs auf dem CAN updaten. Darüber hinaus können Agenten für ein Gerät in jedem referenzierbaren angeschlossenen Knoten im System untergebracht sein.
  • In einem anderen Fall, wenn die Updates in einer ODX-Datei verfügbar sind, kann der Agent (wie der in 3 dargestellte Master-Agent 320) die ODX-Datei analysieren, um relevante Details in Bezug auf das Update zu extrahieren (z.B. ein, eine Kombination oder alle von: ROM-Code; Adressstandort; oder Sicherheitsdetails). Der Agent kann dann die extrahierten relevanten Details über den DolP-Client 330 an den DolP-Server 340 übermitteln. Im Gegenzug kann der DolP-Client 330 die Steuergeräte upzudaten (wie ECU1 220, ECU2 222 und ECU3 224 in 3). Die drei repräsentativen Konfigurationen für die CAN-Updates, die in 2A-C dargestellt sind, können auch dazu dienen, zu veranschaulichen, wie der DolP-Server 340 die Steuergeräte updaten kann.
  • Wie bereits erwähnt, kann die Architektur des Master-Agenten auf mehrere virtuelle Maschinen oder separate Kernel-Konfigurationen in einem Steuergerät erweitert werden. Insbesondere haben Steuergeräte in den letzten zehn Jahren an Rechenleistung (z.B. mit Multicores), Speicher und I/O-Ressourcen zugelegt. In dieser Hinsicht steuern die Steuergeräte heute komplexe Funktionen in Fahrzeugen, wie z.B. die Infotainment-Einheit, ADAS, Adaptive AUTomotive Open System Architecture (AUTOSAR), usw. Diese Steuergeräte können durch ein oder mehrere Betriebssysteme, wie z.B. Linux/QNX/Integrity, verwaltet werden, die als virtuelle Maschinen in ihrem eigenen Speicherbereich montiert sind. Illustrative Beispiele für VMs in einem Multi-Core-Steuergerät in zwei verschiedenen Konfigurationen sind in den 4 und 5 dargestellt.
  • Jede VM oder ein separater Kernel kann als ein mit dem Netz verbundener Endpunkt betrachtet werden. In bestimmten Fällen für den Anwendungsfall des Updates kann ein netzverbundener Endpunkt sogar ein Verweis auf einen Dateiordner oder eine Partition oder ein Datenträger oder eine einzelne Datei sein. Die Adressen für jeden Endpunkt können wie folgt aufgelöst werden:
  • Ein getrennter Kernel kann über eine Netzadresse oder eine Verbindung entdeckt werden. In der Praxis können sich die Kernel den vereinheitlichten physischen Speicherraum teilen. Insbesondere können bei einer Implementierung die separierten Echtzeitbetriebssystem-Kernel 450 auf der Hardware 460 ausgeführt werden, z.B. auf einem Multi-Core-System auf einem Chip (SOC, system on chip), wobei die verschiedenen Betriebssysteme auf verschiedenen Kernen laufen. Ein Separationskernel ist eine Art von Sicherheitskernel, der zur Simulation einer verteilten Umgebung verwendet wird. Die Aufgabe des Separationskernels besteht darin, eine Umgebung zu schaffen, die von der eines physisch verteilten Systems nicht zu unterscheiden ist (z.B. erscheint es so, als ob jedes System eine separate, isolierte Maschine ist und Informationen nur über bekannte externe Kommunikationsleitungen von einer Maschine zur anderen fließen können). So kann es in einer Implementierung für den Trennungs-Kernel keine anderen als die ausdrücklich vorgesehenen Kanäle für den Informationsfluss zwischen den Regimen geben.
  • 4 zeigt eine Konfiguration 400 eines einzelnen Master-Update-Agenten in Multi-Core-ECUs unter Verwendung virtueller Maschinen, wobei die gestrichelten Linien 470, 472 physische Partitionen darstellen. Wie dargestellt, umfasst die Telematik-Steuereinheit (TCU) 430 den eSync Master Agent (A) 434 und den eSync Client 432. Darüber hinaus können in der in FIG. 400 dargestellten Konfiguration 4 dargestellten Konfiguration 400 verschiedene Adressen verwendet werden, um über einen Hypervisor 440 mit den verschiedenen Kernels zu kommunizieren, z.B. /A/TCU (für die Kommunikation mit TCU 430), /A/Android (für die Kommunikation mit der virtuellen Android-Maschine 420), /A (Meter Linux) (für die Kommunikation mit der virtuellen Maschine (VM) 418), /A/AdaptiveAutosar (für die Kommunikation mit Adaptive AUTOSAR 416), /A/ADAS (für die Kommunikation mit ADAS RT Software 414), /A/AUTOSAR (für die Kommunikation mit klassischem AUTOSAR, das in einer oder mehreren Instanziierungen 410, 412 manifestiert sein kann).
  • Insbesondere kann der Hypervisor 440, der auch als Virtual Machine Monitor, VMM oder Virtualisierer bezeichnet werden kann, aus Computersoftware, Firmware und/oder Hardware bestehen, die virtuelle Maschinen erstellt und betreibt. Ein elektronisches Gerät, auf dem ein Hypervisor eine oder mehrere virtuelle Maschinen ausführt, kann eine Host-Maschine sein, und jede virtuelle Maschine kann eine Gast-Maschine sein. Hypervisor 440 kann den Gastbetriebssystemen eine virtuelle Betriebsplattform zur Verfügung stellen und die Ausführung der Gastbetriebssysteme verwalten. Mehrere Instanzen einer Vielzahl von Betriebssystemen können sich die virtualisierten Hardwareressourcen teilen.
  • In einer oder einigen Ausführungsformen können Updates von partitionierten Prozessen innerhalb einer virtuellen Maschine (VM) oder einer anderen ähnlichen Instanz durchgeführt werden. Insbesondere kann eine einzelne VM 530 einen oder mehrere unterteilte unabhängige Prozesse 510 umfassen, die ihren eigenen Speicherplatz für Programm und Daten und auch eine begrenzte CPU-Nutzung erhalten haben. Dies kann insbesondere für ADAS-Plattformen in Fahrzeugen relevant sein, die mehrere unabhängige und isolierte Funktionsblöcke in einer einzigen VM umfassen können. Jeder Block für sich kann bei jeder Änderung oder jedem Update der Software zusammen mit anderen Komponenten gründlich getestet und verifiziert werden, um zu bestätigen, dass das Update den behördlichen Vorschriften entspricht. Diese Tests/Verifizierungen verursachen einen hohen Kosten-, Zeit- und Ressourcenaufwand für alle Beteiligten und sogar Programmverzögerungen für die OEMs. Alternativ können auch Container-basierte Auslieferungen in eine oder mehrere VMs oder Multi-Core-Maschinen verwendet werden.
  • Zu den Prozessen 510 können beispielsweise A1 520, A2 522, A3 524, A4 526 gehören und Teil des ADAS-Systems sein, das vor seinem Einsatz einer umfassenden Qualifizierung unterzogen werden kann. Der Agent kann einen, eine Kombination oder alle Prozesse A1-A4 520, 522, 524, 526 updaten.
  • In einer oder einigen Ausführungsformen können verteilte Agenten verwendet werden. Insbesondere wenn ein Konzept mit verteilten Agenten verwendet wird (z.B. keine einzelnen Agenten, sondern mehrere Agenten), kann dieselbe Konfiguration 500 von 5 Agenten wie in 6 dargestellt aufweisen. Insbesondere zeigt 6 eine Konfiguration 600 mit verteilten Agenten (eSync-Agent A, eSync-Agent A1, eSync-Agent A2, eSync-Agent A3, eSync-Agent A4, eSync-Agent A5) unter Verwendung mehrerer virtueller Maschinen (VMs) und Kernel, wobei gestrichelte Linien 640, 642 Partitionen anzeigen. Wie in der Konfiguration 600 in 6 dargestellt, sieht der eSync-Client 532 in der TCU 630 die folgenden aufgelösten Agentenadressen: /A (TCU), /A1 (Android), /A2 (Meter Linux), /A3 (Classic Autosar), /A4 (Adaptive Autosar) und /A5 (RT ADAS).
  • In einer Implementierung kann ein eSync-Busprotokoll einen Broker verwenden, der als Vermittler zwischen elektronischen Geräten in der Umgebung fungieren kann, z.B. um Nachrichten zwischen den ersten und zweiten elektronischen Geräten im Fahrzeug weiterzuleiten (z.B. zwischen einem eSync-Client und einem Agenten, z.B. einem Master-Agenten). Dies ist im Blockdiagramm 800 in dargestellt. 8 umfasst den eSync-Client, der einen Download-Manager, der so konfiguriert ist, dass er mit einem Server außerhalb des Fahrzeugs kommuniziert, um das Software-Update herunterzuladen (z.B. ein Delta-Update, wie in der US-Patentanmeldungsveröffentlichung Nr. 2019-0265965 A1 (Anwaltsnummer 014442-18017B-US) offenbart, das hierin vollumfänglich durch Bezugnahme eingebunden wird), und einen Controller umfasst, der so konfiguriert ist, dass er mit dem Download-Manager und dem Nachrichtenbroker (auch als Broker bezeichnet) kommuniziert. Der Broker kann ein eigenständiges Gerät sein oder ein Gerät, das in ein anderes Gerät eingebaut ist. In diesem Zusammenhang kann der Broker in jeder dieser Konfigurationen austauschbar verwendet werden. Die Maklervorrichtung, wie sie in der US-Patentanmeldung Nr. 2019-0268420 A1 (Aktenzeichen 014442-18019A-US) offenbart ist, die hierin vollständig enthalten ist, kann so konfiguriert sein, dass sie als Vermittler zwischen dem eSync-Client und dem Agenten (wie dem Master-Agenten, wie in 9 dargestellt) fungiert.
  • In einer Implementierung kann der Broker so konfiguriert sein, dass er eines, eine beliebige Kombination oder alle der folgenden Elemente ermitteln kann: Adressen der verschiedenen Geräte (z.B. Steuergeräte); Fähigkeiten der verschiedenen Geräte (z.B. ob ein bestimmtes Steuergerät über ausreichend Speicher und/oder Verarbeitungsleistung verfügt, um die Erstellung des Image des Software-Updates durchzuführen); oder die Architektur im Fahrzeug (z.B. die verschiedenen CAN-Busse und die mit den verschiedenen CAN-Bussen verbundenen Steuergeräte). Der Broker kann die Software-Updates auch vom eSync-Client erhalten. So kann in einer Implementierung der Broker mit dem Agenten, z.B. dem Master-Agenten, kommunizieren, um eine, eine Kombination oder alle der folgenden Informationen zu übermitteln: Adressen der elektronischen Geräte, Fähigkeiten des elektronischen Geräts, Architektur im Fahrzeug oder das Software-Update (z.B. das Delta-Update, das zur Erstellung des Software-Updates verwendet werden kann). Der Agent, z.B. der Master-Agent, kann seinerseits so konfiguriert sein, dass er das Software-Update wie hier beschrieben überträgt. Beispielsweise kann der Makler alle Adressen, die Fähigkeiten, die Architektur und das Software-Update (unerstellt) an den Master-Agenten senden. Alternativ kann der Broker die Adressen, die Architektur und das (noch nicht erstellte) Software-Update an den Master-Agenten senden, wobei der Master-Agent (unter Verwendung der vom Broker gesendeten Adressen) mit den elektronischen Geräten kommuniziert, um die Fähigkeiten der elektronischen Geräte abzufragen, um zu bestimmen, ob der Agent die Erstellung des Software-Updates durchführt oder ob die elektronischen Geräte die Erstellung durchführen.
  • Ein beispielhaftes Flussdiagramm 700 für die Durchführung des Software-Updates ist in 7 dargestellt. Nach dem Start bei 702 empfängt der Agent die Nutzdaten (zur Durchführung des Software-Updates, z.B. das Delta) bei 704 und kann Metadaten der Nutzdaten bei 706 empfangen. Der Agent, z.B. der Master-Agent, kann die Metadaten und die Nutzdaten untersuchen, um einen oder mehrere Aspekte des Software-Updates zu bestimmen, z.B. einen, eine Kombination oder alle der folgenden Aspekte: wie viele Updates es gibt, die upzudatenden Gerätetypen oder den Zeitpunkt des Updates.
  • Bei 708 kann der Agent feststellen, ob die Adresse, die das Update gesendet hat, verifiziert und authentifiziert ist. Wie bereits erwähnt, kann der eSync-Client mit einem externen Server kommunizieren, um das Software-Update (z.B. das Delta) zu erhalten. Der externe Server, der das Software-Update übermittelt hat, kann von einem oder mehreren Geräten, wie dem eSync-Client und/oder dem Agenten, überprüft werden. Beispielsweise kann der externe Server sowohl vom eSync-Client als auch vom Agenten überprüft werden, um zusätzliche Sicherheit und Verifizierung zu gewährleisten. Falls die Adresse des externen Servers nicht verifiziert wird („Nein“ bei 708), wird bei 710 festgestellt, dass die Adresse nicht mit einer Liste von Adressen zugelassener Absender übereinstimmt, wobei die Liste für den Agenten zugänglich oder intern ist. Ferner kann der Bearbeiter bei 712 eine Fehlermeldung an den Makler oder den eSync-Client oder an beide senden und bei 714 mit dem Beenden fortfahren.
  • Wenn die Adresse verifiziert und authentifiziert ist, kann bei 716 die Liste der gültigen Adressen als übereinstimmend angezeigt werden. Ferner wird bei 718 festgestellt, ob Geräte an mehreren CAN-Bussen angeschlossen sind. Wie bereits erwähnt, kann ein Agent, z.B. ein Master-CAN-Agent, die Architektur des Systems bestimmen, wie in den dargestellt. Insbesondere kann der Agent über die Architektur der verschiedenen Busse (z.B. die Struktur des CAN-Busses/der CAN-Busse) informiert sein und die Adressen auflösen, um mit den verschiedenen elektronischen Geräten (z.B. den verschiedenen ECUs) zu kommunizieren.
  • Als Reaktion auf die Feststellung, dass keine Geräte an mehreren CAN-Bussen vorhanden sind (d. h. dass die Steuergeräte seriell an einen einzigen CAN-Bus angeschlossen sind), kann der Agent bei 720 die Nutzdaten für das Update der Steuergeräte in serieller Weise organisieren. Als ein Beispiel kann der Agent das Software-Update an ein erstes Steuergerät der Steuergeräte senden (erstellt in dem Fall, in dem das Steuergerät nicht in der Lage ist, das Update zu erstellen; oder nicht erstellt in dem Fall, in dem das Steuergerät in der Lage ist, das Update zu erstellen), und auf eine Empfangsbestätigung warten. Als Reaktion auf die Bestätigung kann der Agent das Software-Update an ein zweites Steuergerät der Steuergeräte senden und dies so lange wiederholen, bis alle Steuergeräte das Software-Update erhalten haben. Bei 722 können die Steuergeräte das Update speichern (z.B. durch Flashen des Updates). Alternativ kann, wenn Geräte an verschiedenen CAN-Bussen angeschlossen sind, bei 724 eine Liste der Geräte erstellt werden, die an den verschiedenen CAN-Bussen angeschlossen sind, und bei 726 wird ein paralleler Upload des Software-Updates eingeleitet.
  • In einer Implementierung kann ein erster Satz von Steuergeräten seriell auf einem ersten CAN-Bus und ein zweiter Satz von Steuergeräten seriell auf einem zweiten CAN-Bus konfiguriert sein. In einem solchen Fall kann ein paralleles Update unter Verwendung eines ersten Update-Agenten durchgeführt werden, der die Verteilung des Software-Updates an die erste Gruppe von Steuergeräten auf dem ersten CAN-Bus steuert (z.B. die Planung der seriellen Verteilung, wie oben bei 720 beschrieben), und eines zweiten Update-Agenten, der die Verteilung des Software-Updates an die zweite Gruppe von Steuergeräten auf dem zweiten CAN-Bus steuert (wiederum die Planung der seriellen Verteilung, wie oben bei 720 beschrieben). In einer anderen Implementierung kann der erste Satz von Steuergeräten seriell auf dem ersten CAN-Bus konfiguriert sein und ein zweites Steuergerät (oder der zweite Satz von Steuergeräten) kann parallel auf dem zweiten CAN-Bus konfiguriert sein. In einem solchen Fall kann ein paralleles Update unter Verwendung des ersten Update-Agenten durchgeführt werden, der die Verteilung des Software-Updates an die erste Gruppe von Steuergeräten auf dem ersten CAN-Bus steuern kann (z.B. die Planung der seriellen Verteilung, wie oben unter 720 beschrieben), und des zweiten Update-Agenten, der die Verteilung des Software-Updates parallel an die zweite Gruppe von Steuergeräten auf dem zweiten CAN-Bus steuern kann. Somit kann eine parallele Verteilung sowohl auf den verschiedenen CAN-Bussen als auch innerhalb eines jeweiligen CAN-Busses erfolgen.
  • Obwohl in 7 nicht dargestellt, kann der Agent, wie z.B. der Master-Agent, bestimmen, wie das Software-Update durchgeführt werden soll (z.B. ob das erstellte Software-Update an die Steuergeräte übertragen werden soll oder ob das nicht erstellte Software-Update an die Steuergeräte übertragen werden soll, damit die Steuergeräte selbst das Erstellen des Software-Updates durchführen können). Insbesondere kann der Agent über die Intelligenz verfügen, um zu bestimmen, wie das Update durchgeführt werden soll, und die Adresse der Steuergeräte enthalten (die vom Nachrichtenbroker (siehe oben) erhalten werden kann), wobei der Nachrichtenbroker alle elektronischen Geräte in der Fahrzeugarchitektur, einschließlich der Steuergeräte im Fahrzeug und/oder des Layouts (z.B. an welchen CAN-Bus das spezifische Steuergerät angeschlossen ist) und die Adressen der verschiedenen Geräte im System ermittelt. Außerdem kann der Agent die Fähigkeit des jeweiligen Geräts (z.B. des jeweiligen Steuergeräts) zur Durchführung des Updates in Erfahrung bringen.
  • Ein Beispiel ist, dass das jeweilige Gerät in der Lage sein kann, das Image des Software-Updates zu erstellen. In einem besonderen Beispiel kann ein bestimmtes Steuergerät über mehrere Bänke (Bank A und Bank B) verfügen, wobei die mehreren Bänke das bestimmte Steuergerät in die Lage versetzen, eine der Bänke zu verwenden, um das Image des Software-Updates zu erstellen. In einem solchen Fall kann der Agent das Software-Update (unkompiliert und in verschlüsselter Form) übermitteln, damit das spezifische Steuergerät das Image des Software-Updates zur Installation durch das spezifische Steuergerät erstellen kann. In diesem speziellen Beispiel kann der Agent somit Software-Updates an die verschiedenen Steuergeräte senden, die das Erstellen durchführen können, ohne dass der Bus für die Übertragung des erstellten Images gehalten werden muss. Ein weiteres Beispiel ist, dass das betreffende Gerät möglicherweise nicht über die Kapazität (z.B. unzureichender Speicher und/oder Verarbeitungskapazität) verfügt, um das Image des Software-Updates zu erstellen. In einem solchen Fall kann der Agent, anstatt dass das Steuergerät das Image erstellt, das Image erstellen (z.B. das aktuelle Software-Image vom Steuergerät abrufen und die Differenz hinzufügen, um das erstellte Image für das Software-Update zu generieren) und dann das erstellte Image des Software-Updates an das Steuergerät zur Installation durch das Steuergerät übertragen (z.B. das erstellte Image einzeln an die verschiedenen Steuergeräte senden, die nicht in der Lage sind, das Erstellen durchzuführen). Unabhängig davon, ob der/die Agent(en) die Software-Updates seriell und/oder parallel überträgt/übertragen, kann/können der/die Agent(en) die Form des Software-Updates (z.B. erstellt oder nicht erstellt) an die verschiedenen Steuergeräte bestimmen. Auf diese Weise kann die Hierarchie der Steuergeräte organisiert werden.
  • Bei 728 kann der Agent den Status des Updates erhalten, z.B. ob das Steuergerät meldet, dass das Update erfolgreich durchgeführt wurde oder nicht. Bei 730 stellt der Agent fest, ob ein Fehler bei das Software-Update vorliegt. Wenn dies der Fall ist, wird bei 734 ein Rollback in Abhängigkeit von der Richtlinie durchgeführt. Die Richtlinie kann vom Agenten auf eine von mehreren Arten festgelegt werden. Zum einen kann die Richtlinie in den empfangenen Metadaten enthalten sein (z.B. bei 706). Alternativ kann der Agent den Broker oder den eSync-Client nach der Richtlinie befragen. In einer Implementierung kann die Richtlinie angeben, dass nur das Steuergerät, bei dem das Software-Update fehlgeschlagen ist, auf die vorherige Software-Version zurückgesetzt wird. In diesem Fall kann der Agent das Software-Update nur für die Steuergeräte initiieren, die einen Fehler gemeldet haben. In einer anderen Implementierung kann die Richtlinie angeben, dass sowohl Steuergeräte, die einen Fehler gemeldet haben, als auch Steuergeräte, die ein erfolgreiches Update gemeldet haben, zurückgesetzt werden. In einem Beispiel sollen alle Steuergeräte, die ein gemeinsames Attribut mit dem Steuergerät haben, das den Fehler gemeldet hat (z.B. Steuergeräte am selben CAN-Bus; Steuergeräte desselben Typs), zurückgesetzt werden. In einem solchen Fall kann der Agent das Software-Update nur für die Steuergeräte initiieren, die das gemeinsame Attribut mit dem Steuergerät, das den Fehler gemeldet hat, aufweisen.
  • Wenn kein Fehler gemeldet wird, werden die Steuergeräte bei 732 geflasht, bei 736 meldet der Agent den Status (z.B. meldet der Agent dem Broker oder dem eSync-Client, ob das Software-Update fehlgeschlagen oder erfolgreich war) und endet bei 738.
  • Zurück zu 8: Der eSync-Client, einschließlich der Download-Funktionalität und der Verarbeitungsfunktionalität, kann zusätzliche Funktionen enthalten. Ferner zeigen die gestrichelten Linien in 8, dass der Master-Agent direkt mit den Steuergeräten über UDS (statt über den DoIP-Master) kommunizieren kann. Insbesondere kann es bestimmte Fälle geben, in denen ein Master-Agent in seiner Rolle als Diagnostiker direkt mit den Steuergeräten kommunizieren kann. In einem solchen Fall kann der Master-Agent direkt (Master-Agent an Steuergeräte) oder indirekt (über den DoIP-Master) kommunizieren. Der OEM kann vorgeben, ob der Master-Agent direkt oder indirekt kommuniziert. Somit kann die Architektur in einer Implementierung dem Master-Agenten flexibel erlauben, mit den Steuergeräten entweder direkt oder indirekt (über den DoIP-Master) zu kommunizieren. Des Weiteren kann die logische Darstellung, wie in 8 dargestellt, dazu führen, dass die Steuergeräte physisch auf verschiedenen CAN-Bussen und/oder auf demselben CAN-Bus sitzen. Wie bereits erwähnt, können Steuergeräte, die auf verschiedenen CAN-Bussen sitzen, parallel upgedated werden. Darüber hinaus kann die Transportsicherheit zwischen dem eSync-Client und den Steuergeräten auf der Grundlage von OEM-Vorgaben angepasst werden. Insbesondere kann der OEM die Art der Verschlüsselung (falls vorhanden) beim Transport des Software-Updates vom eSync-Client über den Message Broker zum Master-Agent (möglicherweise über den DoIP-Master) und schließlich zu den Steuergeräten vorgeben. In einem Beispiel kann der OEM das Software-Update bereits verschlüsselt haben. In diesem Fall ist eine separate Verschlüsselung nicht erforderlich. In einem anderen Beispiel kann es sein, dass der OEM das Software-Update nicht verschlüsselt hat. In diesem Fall kann der OEM vorschreiben, dass die Ver-/Entschlüsselung durch den eSync-Client, den Message Broker, den Master-Agent oder den DolP-Master erfolgt. Insbesondere kann der OEM verschiedene Arten von Sicherheit vorschreiben, z.B. auf der Datenverbindungsebene und/oder auf der Transportsicherheitsebene
  • 9 zeigt ein allgemeines Computersystem 900, das so programmiert werden kann, dass es ein spezifisches Computersystem 900 ist, das einen beliebigen Server, ein elektronisches Gerät oder eine elektronische Komponente darstellen kann, die hierin offenbart werden, wie z.B. einen beliebigen Server, einen beliebigen Fahrzeug-Client, ein beliebiges Steuergerät, ein beliebiges Gateway, eine beliebige Haupteinheit oder ähnliches. Das Computersystem 900 kann eine geordnete Auflistung eines Satzes von Anweisungen 902 enthalten, die ausgeführt werden können, um das Computersystem 900 zu veranlassen, eine oder mehrere der hier offengelegten Methoden oder computerbasierten Funktionen auszuführen. Das Computersystem 900 kann als eigenständiges Gerät arbeiten oder z.B. über das Netzwerk 945 mit anderen Computersystemen oder Peripheriegeräten verbunden werden.
  • In einem vernetzten Einsatz kann das Computersystem 900 in der Funktion eines Servers oder als Client-Benutzer-Computer in einer Server-Client-Benutzer-Netzwerkumgebung oder als Peer-Computersystem in einer Peer-to-Peer- (oder verteilten) Netzwerkumgebung arbeiten. Das Computersystem 900 kann auch als verschiedene Geräte implementiert oder in diese eingebaut werden, wie z.B. ein Personal Computer oder ein mobiles Computergerät, das in der Lage ist, eine Reihe von Anweisungen 902 auszuführen, die die von diesem Gerät auszuführenden Aktionen spezifizieren, einschließlich, aber nicht beschränkt auf den Zugriff auf das Internet oder das Web über eine beliebige Form von Browser. Darüber hinaus kann jedes der beschriebenen Systeme eine beliebige Sammlung von Teilsystemen umfassen, die einzeln oder gemeinsam einen Satz oder mehrere Sätze von Anweisungen ausführen, um eine oder mehrere Computerfunktionen auszuführen.
  • Das Computersystem 900 kann einen Speicher 904 an einem Bus 920 zur Informationsübertragung enthalten. In dem Speicher 904 kann ein Code gespeichert werden, der das Computersystem veranlasst, eine der hier beschriebenen Handlungen oder Operationen durchzuführen. Der Speicher 904 kann ein Direktzugriffsspeicher, ein Festwertspeicher, ein programmierbarer Speicher, ein Festplattenlaufwerk oder eine andere Art von flüchtigem oder nichtflüchtigem Speicher oder Speichergerät sein.
  • Das Computersystem 900 kann einen Prozessor 908 enthalten, wie z.B. eine Zentraleinheit (CPU) und/oder eine Grafikverarbeitungseinheit (GPU). Der Prozessor 908 kann einen oder mehrere allgemeine Prozessoren, digitale Signalprozessoren, anwendungsspezifische integrierte Schaltkreise, feldprogrammierbare Gate-Arrays, digitale Schaltkreise, optische Schaltkreise, analoge Schaltkreise, Kombinationen davon oder andere jetzt bekannte oder später entwickelte Geräte zur Analyse und Verarbeitung von Daten umfassen. Der Prozessor 908 kann den Befehlssatz 902 oder ein anderes Softwareprogramm implementieren, z.B. einen manuell programmierten oder computergenerierten Code zur Implementierung logischer Funktionen. Die beschriebene logische Funktion oder ein beliebiges Systemelement kann unter anderem eine analoge Datenquelle wie ein analoges elektrisches, Audio- oder Videosignal oder eine Kombination davon in eine digitale Datenquelle für audiovisuelle Zwecke oder andere digitale Verarbeitungszwecke, z.B. zur Kompatibilität für die Computerverarbeitung, verarbeiten und umwandeln.
  • Das Computersystem 900 kann auch eine Platten- oder optische Laufwerkeinheit 915 enthalten. Die Plattenlaufwerkeinheit 915 kann ein computerlesbares Medium 940 enthalten, in das ein oder mehrere Sätze von Anweisungen 902, z.B. Software, eingebettet sein können. Ferner können die Anweisungen 902 einen oder mehrere der hier beschriebenen Vorgänge durchführen. Die Anweisungen 902 können sich während der Ausführung durch das Computersystem 900 vollständig oder zumindest teilweise in dem Speicher 904 oder in dem Prozessor 908 befinden. Dementsprechend können verschiedene Datenbanken, wie z.B. Software-Repository-Revisionen, in dem Speicher 904 oder der Platteneinheit 915 gespeichert werden.
  • Der Speicher 904 und der Prozessor 908 können auch computerlesbare Medien enthalten, wie oben beschrieben. Ein „computerlesbares Medium“, „computerlesbares Speichermedium“, „maschinenlesbares Medium“, „Signalübertragungsmedium“ oder „signaltragendes Medium“ kann jede Vorrichtung umfassen, die Software zur Verwendung durch oder in Verbindung mit einem anweisungsausführbaren System, Gerät oder einer Vorrichtung besitzt, speichert, kommuniziert, überträgt oder transportiert. Bei dem maschinenlesbaren Medium kann es sich wahlweise, aber nicht ausschließlich, um ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, -gerät, -vorrichtung oder -übertragungsmedium handeln.
  • Darüber hinaus kann das Computersystem 900 ein Eingabegerät 925, z.B. eine Tastatur oder eine Maus, enthalten, mit dem ein Benutzer mit einer der Komponenten des Systems 900 interagieren kann. Es kann ferner eine Anzeige 970 enthalten, wie z.B. eine Flüssigkristallanzeige (LCD), eine Kathodenstrahlröhre (CRT) oder eine andere Anzeige, die für die Übermittlung von Informationen geeignet ist. Das Display 970 kann als Schnittstelle für den Benutzer dienen, um die Funktionsweise des Prozessors 908 zu sehen, oder speziell als Schnittstelle zur Software, die im Speicher 904 oder in der Antriebseinheit 915 gespeichert ist.
  • Das Computersystem 900 kann eine Kommunikationsschnittstelle 936 enthalten, die die Kommunikation über das Kommunikationsnetzwerk 945 ermöglicht. Das Netzwerk 945 kann drahtgebundene Netzwerke, drahtlose Netzwerke oder Kombinationen davon umfassen. Das Netzwerk der Kommunikationsschnittstelle 936 kann die Kommunikation über eine beliebige Anzahl von Kommunikationsstandards ermöglichen, wie 802.11, 802.17, 802.20, WiMax, 802.15.4, Mobilfunkstandards oder andere Kommunikationsstandards, wie oben beschrieben. Die Tatsache, dass eine dieser Normen aufgeführt ist, bedeutet nicht, dass eine dieser Normen bevorzugt wird, da eine beliebige Anzahl dieser Normen niemals in ein kommerzielles Produkt übernommen werden kann.
  • Blockdiagramme zu verschiedenen Aspekten des Systems, einschließlich der hierin dargestellten, einschließlich der 1-6, können unter Verwendung der in 9 offenbarten Computerfunktionalität implementiert werden. Ferner können die hier erörterten Flussdiagramme, wie z.B. 7-8, computerlesbare Anweisungen verwenden, die von einem oder mehreren Prozessoren ausgeführt werden, um die beschriebene Funktionalität zu implementieren.
  • Die vorliegende Offenbarung sieht ein computerlesbares Medium vor, das Anweisungen enthält oder Anweisungen als Reaktion auf ein verbreitetes Signal empfängt und ausführt, so dass ein an ein Netzwerk angeschlossenes Gerät Sprache, Video, Audio, Bilder oder andere Daten über das Netzwerk übertragen kann. Außerdem können die Befehle über eine Kommunikationsschnittstelle über das Netz übertragen oder empfangen werden. Die Kommunikationsschnittstelle kann ein Teil des Prozessors sein oder eine separate Komponente darstellen. Die Kommunikationsschnittstelle kann in Software erstellt werden oder eine physische Verbindung in Hardware sein. Die Kommunikationsschnittstelle kann so konfiguriert sein, dass sie mit einem Netzwerk, externen Medien, dem Display oder anderen Komponenten im System oder Kombinationen davon verbunden werden kann. Die Verbindung mit dem Netzwerk kann eine physische Verbindung sein, wie z.B. eine kabelgebundene Ethernet-Verbindung, oder sie kann drahtlos hergestellt werden, wie unten beschrieben. Im Falle eines Dienstanbieterservers kann der Dienstanbieterserver mit den Benutzern über die Kommunikationsschnittstelle kommunizieren.
  • Das computerlesbare Medium kann ein einzelnes Medium sein, oder das computerlesbare Medium kann ein einzelnes Medium oder mehrere Medien sein, wie z.B. eine zentrale oder verteilte Datenbank oder zugehörige Caches und Server, die einen oder mehrere Sätze von Anweisungen speichern. Der Begriff „computerlesbares Medium“ kann auch jedes Medium umfassen, das in der Lage ist, einen Satz von Anweisungen zur Ausführung durch einen Prozessor zu speichern, zu kodieren oder zu tragen, oder das ein Computersystem veranlassen kann, eine oder mehrere der hierin offenbarten Methoden oder Operationen durchzuführen.
  • Das computerlesbare Medium kann einen Festkörperspeicher wie eine Speicherkarte oder ein anderes Gehäuse umfassen, das einen oder mehrere nichtflüchtige Festwertspeicher enthält. Das computerlesbare Medium kann auch ein Direktzugriffsspeicher oder ein anderer flüchtiger, wiederbeschreibbarer Speicher sein. Darüber hinaus kann das computerlesbare Medium ein magneto-optisches oder optisches Medium sein, wie z.B. eine Diskette oder ein Band oder eine andere Speichervorrichtung, um Trägerwellensignale zu erfassen, wie z.B. ein Signal, das über ein Übertragungsmedium übermittelt wird. Ein digitaler Dateianhang zu einer E-Mail oder einem anderen in sich geschlossenen Informationsarchiv oder einer Reihe von Archiven kann als Verteilungsmedium betrachtet werden, das ein greifbares Speichermedium sein kann. Das computerlesbare Medium ist vorzugsweise ein materielles Speichermedium. Dementsprechend kann davon ausgegangen werden, dass die Offenbarung ein oder mehrere computerlesbare Medien oder ein Verteilungsmedium und andere Äquivalente und Nachfolgemedien umfasst, in denen Daten oder Anweisungen gespeichert werden können.
  • Alternativ oder zusätzlich können spezielle Hardware-Implementierungen, wie anwendungsspezifische integrierte Schaltungen, programmierbare Logik-Arrays und andere Hardware-Geräte, konstruiert werden, um eine oder mehrere der hier beschriebenen Methoden zu implementieren. Zu den Anwendungen, die die Geräte und Systeme der verschiedenen Ausführungsformen umfassen können, gehören im Großen und Ganzen eine Vielzahl von elektronischen und Computersystemen. Eine oder mehrere der hier beschriebenen Ausführungsformen können Funktionen unter Verwendung von zwei oder mehreren spezifischen, miteinander verbundenen Hardwaremodulen oder -vorrichtungen mit zugehörigen Steuer- und Datensignalen implementieren, die zwischen und durch die Module oder als Teile einer anwendungsspezifischen integrierten Schaltung kommuniziert werden können. Dementsprechend kann das vorliegende System Software-, Firmware- und Hardware-Implementierungen umfassen.
  • Die hier beschriebenen Methoden können durch Softwareprogramme implementiert werden, die von einem Computersystem ausgeführt werden können. Darüber hinaus können Implementierungen verteilte Verarbeitung, komponenten-/objektverteilte Verarbeitung und parallele Verarbeitung umfassen. Alternativ oder zusätzlich kann eine virtuelle Computersystemverarbeitung aufgebaut werden, um eine oder mehrere der hier beschriebenen Methoden oder Funktionen zu implementieren.
  • Obwohl Komponenten und Funktionen beschrieben sind, die in bestimmten Ausführungsformen unter Bezugnahme auf bestimmte Standards und Protokolle implementiert werden können, sind die Komponenten und Funktionen nicht auf solche Standards und Protokolle beschränkt. So stellen beispielsweise die Standards für die Übertragung über das Internet und andere paketvermittelte Netze (z.B. TCP/IP, UDP/IP, HTML und HTTP) Beispiele für den Stand der Technik dar. Solche Standards werden in regelmäßigen Abständen durch schnellere oder effizientere Äquivalente ersetzt, die im Wesentlichen die gleichen Funktionen haben. Dementsprechend werden Ersatzstandards und -protokolle, die dieselben oder ähnliche Funktionen wie die hier offengelegten haben, als Äquivalente betrachtet.
  • Die hier beschriebenen Abbildungen sollen ein allgemeines Verständnis für die Struktur verschiedener Ausführungsformen vermitteln. Die Abbildungen sollen nicht als vollständige Beschreibung aller Elemente und Merkmale von Geräten, Prozessoren und Systemen dienen, die die hier beschriebenen Strukturen oder Verfahren verwenden. Viele andere Ausführungsformen sind für den Fachmann nach Durchsicht der Offenbarung offensichtlich. Andere Ausführungsformen können verwendet und von der Offenbarung abgeleitet werden, so dass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne den Umfang der Offenbarung zu verlassen. Darüber hinaus sind die Abbildungen lediglich repräsentativ und können nicht maßstabsgetreu gezeichnet werden. Bestimmte Proportionen innerhalb der Abbildungen können übertrieben sein, während andere Proportionen minimiert sein können. Dementsprechend sind die Offenbarung und die Abbildungen eher als illustrativ denn als einschränkend zu betrachten.
  • Darüber hinaus können in der vorstehenden detaillierten Beschreibung verschiedene Merkmale zusammengefasst oder in einer einzigen Ausführungsform beschrieben werden, um die Offenlegung zu vereinfachen. Diese Offenbarung ist nicht so zu verstehen, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern, als in den einzelnen Ansprüchen ausdrücklich aufgeführt sind. Wie aus den folgenden Ansprüchen hervorgeht, kann der Erfindungsgegenstand vielmehr auf weniger als alle Merkmale einer der offenbarten Ausführungsformen gerichtet sein. Daher werden die folgenden Ansprüche in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch für sich allein steht und einen gesondert beanspruchten Gegenstand definiert. In dieser Hinsicht ist der oben offengelegte Gegenstand als illustrativ und nicht einschränkend zu betrachten, und die beigefügten Ansprüche sollen alle derartigen Modifikationen, Verbesserungen und anderen Ausführungsformen abdecken, die in den wahren Geist und Umfang der Beschreibung fallen. Soweit gesetzlich zulässig, ist der Umfang durch die weitestmögliche Auslegung der folgenden Ansprüche und ihrer Äquivalente zu bestimmen und wird durch die vorstehende detaillierte Beschreibung nicht eingeschränkt oder begrenzt.
  • Die folgenden beispielhaften Ausführungsformen der Erfindung werden ebenfalls offenbart:
    • Ausführungsform 1. Eine Update-Agentenvorrichtung, die dazu eingerichtet ist, mit mindestens einen zugehörigen elektronischen Gerät in einem Fahrzeug zu kommunizieren, wobei die Update-Agentenvorrichtung umfasst:
      • mindestens einen Speicher, der dazu eingerichtet ist, eine oder beide von einer oder mehreren Software-Update-Bedingungsangaben oder einer oder mehreren Rollback-Angaben zu speichern; und
      • mindestens einen Prozessor, der dazu eingerichtet ist:
        • mit einem im Fahrzeug befindlichen Client-Gerät zu kommunizieren, um ein Software-Update zu empfangen, wobei das Client-Gerät dazu eingerichtet ist, mit einem externen Server zu kommunizieren, damit das Client-Gerät das Software-Update erhält; und
          • (i) auf der Grundlage der einen oder mehreren Software-Update-Bedingungsangaben zu bestimmen, ob das Software-Update durchgeführt werden soll; und in Abhängigkeit von Entscheidung, das Software-Update durchzuführen, das Software-Update des mindestens einen zugehörigen elektronischen Geräts durchzuführen;
          oder
          • (ii) in Abhängigkeit von der Entscheidung, dass ein Fehler bei der Durchführung eines Software-Updates eines anderen elektronischen Geräts im Fahrzeug vorliegt:
            • auf der Grundlage der einen oder mehreren Rollback-Angaben zu entscheiden, ob ein Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchgeführt werden soll; und
            • in Abhängigkeit von der Entscheidung, das Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchzuführen, das Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchzuführen.
    • Ausführungsform 2. Die Update-Agentenvorrichtung nach Ausführungsform 1: wobei die Update-Agentenvorrichtung in dem mindestens einen zugehörigen elektronischen Gerät installiert ist.
    • Ausführungsform 3. Die Update-Agentenvorrichtung nach Ausführungsform 1, wobei die Update-Agentenvorrichtung außerhalb des mindestens einen zugehörigen elektronischen Geräts angeordnet ist.
    • Ausführungsform 4. Die Update-Agentenvorrichtung nach Ausführungsformen 1-3, wobei die Durchführung des Software-Updates eine Entschlüsselung umfasst;
      • wobei das mindestens eine zugehörige elektronische Gerät die Entschlüsselung nicht durchführt; und
      • wobei die Update-Agentenvorrichtung dazu eingerichtet ist, die Entschlüsselung durchzuführen, um ein unverschlüsseltes Software-Update zu erzeugen und das unverschlüsselte Software-Update an das mindestens eine zugehörige elektronische Gerät zur Installation des unverschlüsselten Software-Updates in dem mindestens einen zugehörigen elektronischen Gerät zu übertragen.
    • Ausführungsform 5. Die Update-Agentenvorrichtung nach Ausführungsformen 1-4, wobei die Update-Agentenvorrichtung nur mit einem einzigen elektronischen Gerät verbunden ist;
      • wobei ein Empfang des Software-Updates dem Update-Agenten anzeigt, dass das Software-Update zum sofortigen Updaten der Software in dem einzigen elektronischen Gerät dient;
      • wobei die eine oder die mehreren Software-Update-Bedingungsangaben mindestens einen Aspekt des aktuellen Betriebs des Fahrzeugs umfassen;
      • wobei der Prozessor ferner dazu eingerichtet ist, den mindestens einen Aspekt des aktuellen Betriebs des Fahrzeugs zu bestimmen; und
      • wobei der Prozessor dazu eingerichtet ist, auf der Grundlage des mindestens einen Aspekts des aktuellen Betriebs des Fahrzeugs zu bestimmen, ob er die Durchführung des Software-Updates für das einzige elektronische Gerät verzögert.
    • Ausführungsform 6. Die Update-Agentenvorrichtung nach Ausführungsformen 1-5, wobei der mindestens eine Aspekt des laufenden Betriebs eine laufende Geschwindigkeit des Fahrzeugs umfasst; und
      • wobei der Prozessor als Reaktion auf die Feststellung, dass die aktuelle Geschwindigkeit des Fahrzeugs kleiner als eine von Null verschiedene vorbestimmte Geschwindigkeit ist, dazu eingerichtet ist, mit der Durchführung des Software-Updates zu beginnen.
    • Ausführungsform 7. Die Update-Agentenvorrichtung nach Ausführungsformen 1-6, wobei die Update-Agentenvorrichtung nur mit einem einzigen elektronischen Gerät verbunden ist;
      • wobei dein Empfang des Software-Updates dem Update-Agenten anzeigt, dass das Software-Update zum sofortigen Updaten der Software in dem einzigen elektronischen Gerät dient;
      • wobei die eine oder die mehreren Software-Update-Bedingungsangaben mindestens einen Aspekt der mit dem einzigen Gerät verbundenen Software umfassen;
      • wobei der Prozessor ferner dazu eingerichtet ist, den mindestens einen Aspekt der Software zu bestimmen, der mit dem einzelnen elektronischen Gerät verbunden ist; und
      • wobei der Prozessor dazu eingerichtet ist, auf der Grundlage des mindestens einen Aspekts der Software, die mit dem einzelnen elektronischen Gerät verbunden ist, zu bestimmen, ob die Durchführung des Software-Updates für das einzige elektronische Gerät verzögert werden soll.
    • Ausführungsform 8. Die Update-Agentenvorrichtung nach Ausführungsformen 1-7, wobei der mindestens eine Aspekt der Software, die mit der einzigen elektronischen Vorrichtung verbunden ist, eine Zeitspanne umfasst, seit der die Software, die mit der einzigen elektronischen Vorrichtung verbunden ist, zuletzt upgedated wurde; und
      • wobei als Reaktion auf die Feststellung, dass die Zeitspanne seit dem letzten Update der mit der einzigen elektronischen Vorrichtung verbundenen Software kürzer als eine vorbestimmte Zeitspanne ist, der Prozessor dazu eingerichtet ist, die Durchführung des Software-Updates für die einzige elektronische Vorrichtung zu verzögern.
    • Ausführungsform 9. Die Update-Agentenvorrichtung nach Ausführungsformen 1-8, wobei ein Empfang des Software-Updates der Update-Agentenvorrichtung anzeigt, dass das Software-Update zum sofortigen Updaten der Software in dem mindestens einen zugehörigen elektronischen Gerät dient; und wobei der Prozessor dazu eingerichtet ist:
      • (i) auf der Grundlage der einen oder mehreren Software-Update-Bedingungsangaben zu bestimmen, ob das Software-Update durchgeführt werden soll; und als Reaktion auf die Entscheidung, das Software-Update durchzuführen, das Software-Update des mindestens einen zugehörigen elektronischen Geräts durchzuführen; und
      • (ii) als Reaktion auf die Feststellung eines Fehlers bei der Durchführung eines Software-Updates eines anderen elektronischen Geräts im Fahrzeug:
        • auf der Grundlage der einen oder mehreren Rollback-Angaben zu bestimmen, ob ein Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchgeführt werden soll; und
        • als Reaktion auf die Entscheidung, das Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchzuführen, das Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchzuführen.
    • Ausführungsform 10. Die Update-Agentenvorrichtung nach Ausführungsformen 1-9, wobei die Update-Agentenvorrichtung eine Master-Update-Agentenvorrichtung umfasst, die dazu eingerichtet ist, das Rollback einer oder mehrerer Follower-Update-Agentenvorrichtungen zu steuern; und
      • wobei als Reaktion auf die Entscheidung des Master-Update-Agentenvorrichtung, dass es den Fehler in dem Software-Update im Zusammenhang mit der einen oder beiden der elektronischen Vorrichtung gibt, die dem Master-Update-Agentenvorrichtung zugeordnet ist, oder der einen oder mehreren elektronischen Vorrichtungen, die der einen oder mehreren Follower-Update-Agent-Vorrichtungen zugeordnet sind, der Prozessor auf der Grundlage einer in der Master-Update-Agentenvorrichtung residenten Richtlinie dazu eingerichtet ist zu bestimmen, ob die eine oder mehreren Follower-Update-Agent-Vorrichtungen angewiesen werden sollen, die Software zurückzusetzen.
    • Ausführungsform 11. Die Update-Agentenvorrichtung nach Ausführungsformen 1-10, wobei als Reaktion auf die Entscheidung der Master-Update-Agentenvorrichtung, dass es den Fehler in dem Software-Update im Zusammenhang mit der einen oder beiden der elektronischen Vorrichtung gibt, die dem Master-Update-Agent-Vorrichtung zugeordnet ist, oder der einen oder mehreren elektronischen Vorrichtungen, die der einen oder mehreren Follower-Update-Agent-Vorrichtungen zugeordnet sind, der Prozessor dazu eingerichtet ist, alle der einen oder mehreren Follower-Update-Agentenvorrichtungen anzuweisen, die Software zurückzusetzen, um ein synchronisiertes Rollback der Software durchzuführen.
    • Ausführungsform 12. Die Update-Agentenvorrichtung nach Ausführungsformen 1-10, wobei als Reaktion auf die Entscheidung der Master-Update-Agentenvorrichtung, dass es den Fehler in dem Software-Update im Zusammenhang mit der einen oder beiden der elektronischen Vorrichtung, die dem Master-Update-Agent-Vorrichtung zugeordnet ist, oder der einen oder mehreren elektronischen Vorrichtungen, die der einen oder mehreren Follower-Update-Agent-Vorrichtungen zugeordnet sind, der Prozessor dazu eingerichtet ist, nur die eine oder die mehreren Follower-Update-Agentenvorrichtungen anzuweisen, die Software zurückzusetzen, wenn ihre zugeordnete elektronische Vorrichtung einen Fehler erlitten hat.
    • Ausführungsform 13. Die Update-Agent-Vorrichtung nach Ausführungsformen 1-12, wobei als Reaktion auf die Entscheidung der Master-Update-Agentenvorrichtung, dass es den Fehler in dem Software-Update im Zusammenhang mit der einen oder beiden der elektronischen Vorrichtung, die dem Master-Update-Agent-Vorrichtung zugeordnet ist, oder der einen oder mehreren elektronischen Vorrichtungen, die der einen oder mehreren Follower-Update-Agent-Vorrichtungen zugeordnet sind, der Prozessor dazu eingerichtet ist:
      • den Typ oder die Klasse des elektronischen Geräts zu bestimmen, das von dem Fehler in der Software-Update betroffen ist, und
      • auf der Grundlage des Typs oder der Klasse des elektronischen Geräts, das von dem Fehler in der Software-Update betroffen ist, ein oder mehrere der nachfolgenden Update-Agentengeräte anweisen, die Software zurückzusetzen.
    • Ausführungsform 14. Die Update-Agent-Vorrichtung nach Ausführungsformen 1-13, wobei der Prozessor ferner dazu eingerichtet ist:
      • eine Datenerfassung auf dem mindestens einen zugehörigen elektronischen Gerät durchzuführen; und
      • Daten, die bei der Datenerfassung mit dem mindestens einen zugehörigen elektronischen Gerät gesammelt wurden, an die Client-Vorrichtung zu übertragen.
    • Ausführungsform 15. Die Update-Agent-Vorrichtung nach Ausführungsformen 1-14, wobei der Prozessor ferner dazu eingerichtet ist, die gesammelten Daten zu analysieren, um zu bestimmen, ob die gesammelten Daten an die Client-Vorrichtung übertragen werden sollen.
    • Ausführungsform 16. Die Update-Agentenvorrichtung nach Ausführungsformen 1-15, wobei der Prozessor dazu eingerichtet ist, die gesammelten Daten zu analysieren, indem er die Ähnlichkeit oder Unähnlichkeit mit Daten bestimmt, die die Update-Agentenvorrichtung zuvor an die Client-Vorrichtung übertragen hat;
      • wobei als Reaktion auf die Entscheidung der Ähnlichkeit der Daten, die die Update-Agentenvorrichtung zuvor an die Client-Vorrichtung übertragen hat, der Prozessor dazu eingerichtet ist, die gesammelten Daten nicht an die Client-Vorrichtung zu übertragen; und
      • wobei der Prozessor als Reaktion auf die Entscheidung der Unähnlichkeit der Daten, die die Update-Agentenvorrichtung zuvor an die Client-Vorrichtung übertragen hat, dazu eingerichtet ist, die gesammelten Daten an die Client-Vorrichtung zu übertragen.
    • Ausführungsform 17. Die Update-Agentenvorrichtung nach Ausführungsformen 1-16, wobei als Reaktion auf die Entscheidung der Ähnlichkeit der Daten, die die Update-Agentenvorrichtung zuvor an die Client-Vorrichtung übertragen hat, der Prozessor dazu eingerichtet ist, sowohl die gesammelten Daten nicht an die Client-Vorrichtung zu übertragen als auch die gesammelten Daten zu verwerfen.
    • Ausführungsform 18. Die Update-Agentenvorrichtung nach Ausführungsformen 1-17, wobei der Prozessor ferner dazu eingerichtet ist:
      • den Betrieb mindestens eines Aspekts des mindestens einen zugehörigen elektronischen Geräts zu steuern.
    • Ausführungsform 19. Die Update-Agentenvorrichtung nach Ausführungsformen 1-18, wobei der Prozessor ferner dazu eingerichtet ist, den mindestens einen Aspekt der mindestens einen zugehörigen elektronischen Vorrichtung zu analysieren, um zu bestimmen, ob der mindestens eine Aspekt der mindestens einen zugehörigen elektronischen Vorrichtung gesteuert werden soll.
    • Ausführungsform 20. Die Update-Agentenvorrichtung nach Ausführungsformen 1-19, wobei der Prozessor dazu eingerichtet ist, auf der Grundlage der in der Update-Agentenvorrichtung residenten Richtlinie tu bestimmen, ob der mindestens eine Aspekt der mindestens einen zugehörigen elektronischen Vorrichtung gesteuert werden soll.
    • Ausführungsform 21. Die Update-Agentenvorrichtung nach Ausführungsformen 1-20, wobei der Prozessor ferner dazu eingerichtet ist:
      • von der Client-Vorrichtung eine Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie die Durchführung von mindestens einer der Funktionen Software-Update, Datenerfassung oder Gerätesteuerung aktiviert;
      • als Reaktion auf den Empfang der Programmierangabe die Update-Agentenvorrichtung für das Software-Update und/oder die Datenerfassung und/oder die Gerätesteuerung zu programmieren;
      • mit der im Fahrzeug befindlichen Client-Vorrichtung zu kommunizieren, um mindestens eines der folgenden Verfahren durchzuführen: (i) Empfangen des Software-Updates für das mindestens eine zugehörige elektronische Gerät; (ii) Übertragen von Daten, die bei der Datenerfassung mit dem mindestens einen zugehörigen elektronischen Gerät gesammelt wurden, an die Client-Vorrichtung; oder (iii) Empfangen eines oder mehrerer Steuerparameter, damit die Update-Agentenvorrichtung das mindestens eine zugehörige elektronische Gerät steuern kann;
      • als Reaktion auf die Programmierung des Software-Updates und als Reaktion auf den Empfang des Software-Updates von der Client-Vorrichtung:
        • auf der Grundlage einer oder mehrerer Software-Update-Bedingungsangaben zu bestimmen, ob das Software-Update durchgeführt werden soll; und
        • als Reaktion auf die Entscheidung, das Software-Update durchzuführen, das Software-Update des mindestens einen zugehörigen elektronischen Geräts durchzuführen;
      • auf die Programmierung für die Datenerfassung zu reagieren:
        • auf der Grundlage einer oder mehrerer Angaben über den Zustand der Datenerfassung zu bestimmen, ob die Datenerfassung durchgeführt werden soll;
        • als Reaktion auf die Entscheidung, die Datenerfassung durchzuführen, die Datenerfassung durchzuführen, um Daten von dem mindestens einen zugehörigen elektronischen Gerät zu erhalten; und
        • die Daten aus der Datenerfassung an die Client-Vorrichtung zu übertragen;
      • in Abhängigkeit von der Programmierung des Steuergeräts:
        • auf der Grundlage einer oder mehrerer Steuerangaben zu bestimmen, ob die Gerätesteuerung durchgeführt werden soll; und
        • als Reaktion auf die Entscheidung, die Gerätesteuerung durchzuführen, die Gerätesteuerung durchzuführen, um das mindestens eine zugehörige elektronische Gerät zu steuern.
    • Ausführungsform 22. Die Update-Agentenvorrichtung nach Ausführungsformen 1-21, wobei die Update-Agentenvorrichtung dazu eingerichtet ist, sequentiell aktiviert zu werden, um Funktionen aus mindestens zwei oder mehr der Software-Updates, der Datenerfassung oder der Gerätesteuerung auszuführen.
    • Ausführungsform 23. Die Update-Agentenvorrichtung nach Ausführungsformen 1-22, wobei die Update-Agentenvorrichtung dazu eingerichtet ist, die Funktionen des Software-Update, der Datenerfassung oder der Gerätesteuerung nacheinander zu aktivieren.
    • Ausführungsform 24. Die Update-Agentenvorrichtung nach Ausführungsformen 1-23, wobei der Prozessor dazu eingerichtet ist, die Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie das Software-Update und die Datenerfassung oder/oder die Gerätesteuerung durchführt.
    • Ausführungsform 25. Die Update-Agentenvorrichtung nach Ausführungsformen 1-24, wobei der Prozessor dazu eingerichtet ist, die Programmierangaben zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie sowohl das Software-Update als auch die Datenerfassung und die Gerätesteuerung durchführt.
    • Ausführungsform 26. Eine Update-Agentenvorrichtung, die dazu eingerichtet ist, mit mindestens einem zugehörigen elektronischen Gerät und einer Client-Vorrichtung in einem Fahrzeug zu kommunizieren, wobei die Update-Agentenvorrichtung umfasst:
      • mindestens einen Speicher, der dazu eingerichtet ist, eine oder beide von einer oder mehreren Software-Update-Bedingungsangaben oder einer oder mehreren Rollback-Angaben zu speichern; und
      • mindestens einen Prozessor, der dazu eingerichtet ist:
        • von der Client-Vorrichtung eine Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie mindestens eine der Funktionen Software-Update, Datenerfassung oder Gerätesteuerung ausführt;
        • als Reaktion auf den Empfang der Programmierangabe die Update-Agentenvorrichtung für das Software-Update und/oder die Datenerfassung und/oder die Gerätesteuerung zu programmieren;
        • mit einer im Fahrzeug befindlichen Client-Vorrichtung zu kommunizieren, um mindestens eines der folgenden Schritte durchzuführen: (i) Empfangen eines Software-Updates für das mindestens eine zugehörige elektronische Gerät, wobei die Client-Vorrichtung so konfiguriert ist, dass sie mit einem externen Server kommuniziert, damit die Client-Vorrichtung das Software-Update für das Updaten der Software erhält; (ii) Übertragen von Daten, die bei der Datenerfassung mit dem mindestens einen zugehörigen elektronischen Gerät gesammelt wurden, an die Client-Vorrichtung; oder (iii) Empfangen eines oder mehrerer Steuerparameter, damit die Update-Agentenvorrichtung das mindestens eine zugehörige elektronische Gerät steuert;
      • als Reaktion auf die Programmierung des Software-Update und als Reaktion auf den Empfang des Software-Update von der Client-Vorrichtung:
        • auf der Grundlage einer oder mehrerer Software-Update-Bedingungsangaben zu bestimmen, ob das Software-Update durchgeführt werden soll; und
        • als Reaktion auf die Entscheidung, das Software-Update durchzuführen, das Software-Update des mindestens einen zugehörigen elektronischen Geräts durchzuführen;
      • auf die Programmierung für die Datenerfassung zu reagieren:
        • auf der Grundlage einer oder mehrerer Angaben über den Zustand der Datenerfassung zu bestimmen, ob die Datenerfassung durchgeführt werden soll;
        • als Reaktion auf die Entscheidung, die Datenerfassung durchzuführen, die Datenerfassung durchzuführen, um Daten von dem mindestens einen zugehörigen elektronischen Gerät zu erhalten; und
        • die Daten aus der Datenerfassung an das Client-Gerät zu übertragen;
      • in Abhängigkeit von der Programmierung des Steuergeräts:
        • auf der Grundlage einer oder mehrerer Steuerangaben zu bestimmen, ob die Gerätesteuerung durchgeführt werden soll; und
        • als Reaktion auf die Entscheidung, die Gerätesteuerung durchzuführen, die Gerätesteuerung durchzuführen, um das mindestens eine zugehörige elektronische Gerät zu steuern.
    • Ausführungsform 27. Die Update-Agentenvorrichtung nach Ausführungsform 26, wobei die von der Client-Vorrichtung empfangene Programmierangabe wiederum von einem Server außerhalb des Fahrzeugs empfangen wird; und
      • wobei die Update-Agentenvorrichtung dazu eingerichtet ist, nacheinander mindestens zwei oder mehr Funktionen Software-Update, Datenerfassung oder Gerätesteuerung zu aktivieren.
    • Ausführungsform 28. Die Update-Agentenvorrichtung nach Ausführungsformen 26-27, wobei die Update-Agentenvorrichtung dazu eingerichtet ist, die Funktionen Software-Update, Datenerfassung oder Gerätesteuerung nacheinander zu aktivieren.
    • Ausführungsform 29. Die Update-Agentenvorrichtung nach Ausführungsformen 26-28, wobei der Prozessor dazu eingerichtet ist, die Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie das Software-Update und die Datenerfassungen und/oder die Gerätesteuerung durchführt.
    • Ausführungsform 30. Die Update-Agentenvorrichtung nach Ausführungsformen 26-29, wobei der Prozessor dazu eingerichtet ist, die Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie sowohl das Software-Update als auch die Datenerfassung und die Gerätesteuerung durchführt.
    • Ausführungsform 31: Ein Verfahren zur Durchführung der in Ausführungsformen 1-25 genannten Schritte.
    • Ausführungsform 32: Ein Verfahren zur Durchführung der in Ausführungsformen 26-30 genannten Schritte.
  • 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
    • US 62/942739 [0001]
    • US 10834206 [0003, 0005, 0016, 0019, 0026]
    • US 10834207 [0029]
    • US 20190268420 A1 [0085]

Claims (30)

  1. Eine Update-Agentenvorrichtung, die dazu eingerichtet ist, mit mindestens einen zugehörigen elektronischen Gerät in einem Fahrzeug zu kommunizieren, wobei die Update-Agentenvorrichtung umfasst: mindestens einen Speicher, der dazu eingerichtet ist, eine oder beide von einer oder mehreren Software-Update-Bedingungsangaben oder einer oder mehreren Rollback-Angaben zu speichern; und mindestens einen Prozessor, der dazu eingerichtet ist: mit einem im Fahrzeug befindlichen Client-Gerät zu kommunizieren, um ein Software-Update zu empfangen, wobei das Client-Gerät dazu eingerichtet ist, mit einem externen Server zu kommunizieren, damit das Client-Gerät das Software-Update erhält; und (iii) auf der Grundlage der einen oder mehreren Software-Update-Bedingungsangaben zu bestimmen, ob das Software-Update durchgeführt werden soll; und in Abhängigkeit von Entscheidung, das Software-Update durchzuführen, das Software-Update des mindestens einen zugehörigen elektronischen Geräts durchzuführen; oder (iv) in Abhängigkeit von der Entscheidung, dass ein Fehler bei der Durchführung eines Software-Updates eines anderen elektronischen Geräts im Fahrzeug vorliegt: auf der Grundlage der einen oder mehreren Rollback-Angaben zu entscheiden, ob ein Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchgeführt werden soll; und in Abhängigkeit von der Entscheidung, das Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchzuführen, das Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchzuführen.
  2. Die Update-Agentenvorrichtung nach Anspruch 1, wobei die Update-Agentenvorrichtung in dem mindestens einen zugehörigen elektronischen Gerät installiert ist.
  3. Die Update-Agentenvorrichtung nach Anspruch 1, wobei die Update-Agentenvorrichtung außerhalb des mindestens einen zugehörigen elektronischen Geräts angeordnet ist.
  4. Die Update-Agentenvorrichtung nach Anspruch 3, wobei die Durchführung des Software-Updates eine Entschlüsselung umfasst; wobei das mindestens eine zugehörige elektronische Gerät die Entschlüsselung nicht durchführt; und wobei die Update-Agentenvorrichtung dazu eingerichtet ist, die Entschlüsselung durchzuführen, um ein unverschlüsseltes Software-Update zu erzeugen und das unverschlüsselte Software-Update an das mindestens eine zugehörige elektronische Gerät zur Installation des unverschlüsselten Software-Updates in dem mindestens einen zugehörigen elektronischen Gerät zu übertragen.
  5. Die Update-Agentenvorrichtung nach Anspruch 1, wobei die Update-Agentenvorrichtung nur mit einem einzigen elektronischen Gerät verbunden ist; wobei ein Empfang des Software-Updates dem Update-Agenten anzeigt, dass das Software-Update zum sofortigen Updaten der Software in dem einzigen elektronischen Gerät dient; wobei die eine oder die mehreren Software-Update-Bedingungsangaben mindestens einen Aspekt des aktuellen Betriebs des Fahrzeugs umfassen; wobei der Prozessor ferner dazu eingerichtet ist, den mindestens einen Aspekt des aktuellen Betriebs des Fahrzeugs zu bestimmen; und wobei der Prozessor dazu eingerichtet ist, auf der Grundlage des mindestens einen Aspekts des aktuellen Betriebs des Fahrzeugs zu bestimmen, ob er die Durchführung des Software-Updates für das einzige elektronische Gerät verzögert.
  6. Die Update-Agentenvorrichtung nach Anspruch 5, wobei der mindestens eine Aspekt des laufenden Betriebs eine laufende Geschwindigkeit des Fahrzeugs umfasst; und wobei der Prozessor als Reaktion auf die Feststellung, dass die aktuelle Geschwindigkeit des Fahrzeugs kleiner als eine von Null verschiedene vorbestimmte Geschwindigkeit ist, dazu eingerichtet ist, mit der Durchführung des Software-Updates zu beginnen.
  7. Die Update-Agentenvorrichtung nach Anspruch 1, wobei die Update-Agentenvorrichtung nur mit einem einzigen elektronischen Gerät verbunden ist; wobei dein Empfang des Software-Updates dem Update-Agenten anzeigt, dass das Software-Update zum sofortigen Updaten der Software in dem einzigen elektronischen Gerät dient; wobei die eine oder die mehreren Software-Update-Bedingungsangaben mindestens einen Aspekt der mit dem einzigen Gerät verbundenen Software umfassen; wobei der Prozessor ferner dazu eingerichtet ist, den mindestens einen Aspekt der Software zu bestimmen, der mit dem einzelnen elektronischen Gerät verbunden ist; und wobei der Prozessor dazu eingerichtet ist, auf der Grundlage des mindestens einen Aspekts der Software, die mit dem einzelnen elektronischen Gerät verbunden ist, zu bestimmen, ob die Durchführung des Software-Updates für das einzige elektronische Gerät verzögert werden soll.
  8. Die Update-Agentenvorrichtung nach Anspruch 7, wobei der mindestens eine Aspekt der Software, die mit der einzigen elektronischen Vorrichtung verbunden ist, eine Zeitspanne umfasst, seit der die Software, die mit der einzigen elektronischen Vorrichtung verbunden ist, zuletzt upgedated wurde; und wobei als Reaktion auf die Feststellung, dass die Zeitspanne seit dem letzten Update der mit der einzigen elektronischen Vorrichtung verbundenen Software kürzer als eine vorbestimmte Zeitspanne ist, der Prozessor dazu eingerichtet ist, die Durchführung des Software-Updates für die einzige elektronische Vorrichtung zu verzögern.
  9. Die Update-Agentenvorrichtung nach Anspruch 1, wobei ein Empfang des Software-Updates der Update-Agentenvorrichtung anzeigt, dass das Software-Update zum sofortigen Updaten der Software in dem mindestens einen zugehörigen elektronischen Gerät dient; und wobei der Prozessor dazu eingerichtet ist: (iii) auf der Grundlage der einen oder mehreren Software-Update-Bedingungsangaben zu bestimmen, ob das Software-Update durchgeführt werden soll; und als Reaktion auf die Entscheidung, das Software-Update durchzuführen, das Software-Update des mindestens einen zugehörigen elektronischen Geräts durchzuführen; und (iv) als Reaktion auf die Feststellung eines Fehlers bei der Durchführung eines Software-Updates eines anderen elektronischen Geräts im Fahrzeug: auf der Grundlage der einen oder mehreren Rollback-Angaben zu bestimmen, ob ein Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchgeführt werden soll; und als Reaktion auf die Entscheidung, das Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchzuführen, das Rollback der Software in dem mindestens einen zugehörigen elektronischen Gerät durchzuführen.
  10. Die Update-Agentenvorrichtung nach Anspruch 9, wobei die Update-Agentenvorrichtung eine Master-Update-Agentenvorrichtung umfasst, die dazu eingerichtet ist, das Rollback einer oder mehrerer Follower-Update-Agentenvorrichtungen zu steuern; und wobei als Reaktion auf die Entscheidung des Master-Update-Agentenvorrichtung, dass es den Fehler in dem Software-Update im Zusammenhang mit der einen oder beiden der elektronischen Vorrichtung gibt, die dem Master-Update-Agentenvorrichtung zugeordnet ist, oder der einen oder mehreren elektronischen Vorrichtungen, die der einen oder mehreren Follower-Update-Agent-Vorrichtungen zugeordnet sind, der Prozessor auf der Grundlage einer in der Master-Update-Agentenvorrichtung residenten Richtlinie dazu eingerichtet ist zu bestimmen, ob die eine oder mehreren Follower-Update-Agent-Vorrichtungen angewiesen werden sollen, die Software zurückzusetzen.
  11. Die Update-Agentenvorrichtung nach Anspruch 10, wobei als Reaktion auf die Entscheidung der Master-Update-Agentenvorrichtung, dass es den Fehler in dem Software-Update im Zusammenhang mit der einen oder beiden der elektronischen Vorrichtung gibt, die dem Master-Update-Agent-Vorrichtung zugeordnet ist, oder der einen oder mehreren elektronischen Vorrichtungen, die der einen oder mehreren Follower-Update-Agent-Vorrichtungen zugeordnet sind, der Prozessor dazu eingerichtet ist, alle der einen oder mehreren Follower-Update-Agentenvorrichtungen anzuweisen, die Software zurückzusetzen, um ein synchronisiertes Rollback der Software durchzuführen.
  12. Die Update-Agentenvorrichtung nach Anspruch 10, wobei als Reaktion auf die Entscheidung der Master-Update-Agentenvorrichtung, dass es den Fehler in dem Software-Update im Zusammenhang mit der einen oder beiden der elektronischen Vorrichtung, die dem Master-Update-Agent-Vorrichtung zugeordnet ist, oder der einen oder mehreren elektronischen Vorrichtungen, die der einen oder mehreren Follower-Update-Agent-Vorrichtungen zugeordnet sind, der Prozessor dazu eingerichtet ist, nur die eine oder die mehreren Follower-Update-Agentenvorrichtungen anzuweisen, die Software zurückzusetzen, wenn ihre zugeordnete elektronische Vorrichtung einen Fehler erlitten hat.
  13. Die Update-Agent-Vorrichtung nach Anspruch 10, wobei als Reaktion auf die Entscheidung der Master-Update-Agentenvorrichtung, dass es den Fehler in dem Software-Update im Zusammenhang mit der einen oder beiden der elektronischen Vorrichtung, die dem Master-Update-Agent-Vorrichtung zugeordnet ist, oder der einen oder mehreren elektronischen Vorrichtungen, die der einen oder mehreren Follower-Update-Agent-Vorrichtungen zugeordnet sind, der Prozessor dazu eingerichtet ist: den Typ oder die Klasse des elektronischen Geräts zu bestimmen, das von dem Fehler in der Software-Update betroffen ist, und auf der Grundlage des Typs oder der Klasse des elektronischen Geräts, das von dem Fehler in der Software-Update betroffen ist, ein oder mehrere der nachfolgenden Update-Agentengeräte anweisen, die Software zurückzusetzen.
  14. Die Update-Agent-Vorrichtung nach Anspruch 10, wobei der Prozessor ferner dazu eingerichtet ist: eine Datenerfassung auf dem mindestens einen zugehörigen elektronischen Gerät durchzuführen; und Daten, die bei der Datenerfassung mit dem mindestens einen zugehörigen elektronischen Gerät gesammelt wurden, an die Client-Vorrichtung zu übertragen.
  15. Die Update-Agent-Vorrichtung nach Anspruch 14, wobei der Prozessor ferner dazu eingerichtet ist, die gesammelten Daten zu analysieren, um zu bestimmen, ob die gesammelten Daten an die Client-Vorrichtung übertragen werden sollen.
  16. Die Update-Agentenvorrichtung nach Anspruch 15, wobei der Prozessor dazu eingerichtet ist, die gesammelten Daten zu analysieren, indem er die Ähnlichkeit oder Unähnlichkeit mit Daten bestimmt, die die Update-Agentenvorrichtung zuvor an die Client-Vorrichtung übertragen hat; wobei als Reaktion auf die Entscheidung der Ähnlichkeit der Daten, die die Update-Agentenvorrichtung zuvor an die Client-Vorrichtung übertragen hat, der Prozessor dazu eingerichtet ist, die gesammelten Daten nicht an die Client-Vorrichtung zu übertragen; und wobei der Prozessor als Reaktion auf die Entscheidung der Unähnlichkeit der Daten, die die Update-Agentenvorrichtung zuvor an die Client-Vorrichtung übertragen hat, dazu eingerichtet ist, die gesammelten Daten an die Client-Vorrichtung zu übertragen.
  17. Die Update-Agentenvorrichtung nach Anspruch 16, wobei als Reaktion auf die Entscheidung der Ähnlichkeit der Daten, die die Update-Agentenvorrichtung zuvor an die Client-Vorrichtung übertragen hat, der Prozessor dazu eingerichtet ist, sowohl die gesammelten Daten nicht an die Client-Vorrichtung zu übertragen als auch die gesammelten Daten zu verwerfen.
  18. Die Update-Agentenvorrichtung nach Anspruch 14, wobei der Prozessor ferner dazu eingerichtet ist: den Betrieb mindestens eines Aspekts des mindestens einen zugehörigen elektronischen Geräts zu steuern.
  19. Die Update-Agentenvorrichtung nach Anspruch 18, wobei der Prozessor ferner dazu eingerichtet ist, den mindestens einen Aspekt der mindestens einen zugehörigen elektronischen Vorrichtung zu analysieren, um zu bestimmen, ob der mindestens eine Aspekt der mindestens einen zugehörigen elektronischen Vorrichtung gesteuert werden soll.
  20. Die Update-Agentenvorrichtung nach Anspruch 19, wobei der Prozessor dazu eingerichtet ist, auf der Grundlage der in der Update-Agentenvorrichtung residenten Richtlinie tu bestimmen, ob der mindestens eine Aspekt der mindestens einen zugehörigen elektronischen Vorrichtung gesteuert werden soll.
  21. Die Update-Agentenvorrichtung nach Anspruch 18, wobei der Prozessor ferner dazu eingerichtet ist: von der Client-Vorrichtung eine Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie die Durchführung von mindestens einer der Funktionen Software-Update, Datenerfassung oder Gerätesteuerung aktiviert; als Reaktion auf den Empfang der Programmierangabe die Update-Agentenvorrichtung für das Software-Update und/oder die Datenerfassung und/oder die Gerätesteuerung zu programmieren; mit der im Fahrzeug befindlichen Client-Vorrichtung zu kommunizieren, um mindestens eines der folgenden Verfahren durchzuführen: (i) Empfangen des Software-Updates für das mindestens eine zugehörige elektronische Gerät; (ii) Übertragen von Daten, die bei der Datenerfassung mit dem mindestens einen zugehörigen elektronischen Gerät gesammelt wurden, an die Client-Vorrichtung; oder (iii) Empfangen eines oder mehrerer Steuerparameter, damit die Update-Agentenvorrichtung das mindestens eine zugehörige elektronische Gerät steuern kann; als Reaktion auf die Programmierung des Software-Updates und als Reaktion auf den Empfang des Software-Updates von der Client-Vorrichtung: auf der Grundlage einer oder mehrerer Software-Update-Bedingungsangaben zu bestimmen, ob das Software-Update durchgeführt werden soll; und als Reaktion auf die Entscheidung, das Software-Update durchzuführen, das Software-Update des mindestens einen zugehörigen elektronischen Geräts durchzuführen; auf die Programmierung für die Datenerfassung zu reagieren: auf der Grundlage einer oder mehrerer Angaben über den Zustand der Datenerfassung zu bestimmen, ob die Datenerfassung durchgeführt werden soll; als Reaktion auf die Entscheidung, die Datenerfassung durchzuführen, die Datenerfassung durchzuführen, um Daten von dem mindestens einen zugehörigen elektronischen Gerät zu erhalten; und die Daten aus der Datenerfassung an die Client-Vorrichtung zu übertragen; in Abhängigkeit von der Programmierung des Steuergeräts: auf der Grundlage einer oder mehrerer Steuerangaben zu bestimmen, ob die Gerätesteuerung durchgeführt werden soll; und als Reaktion auf die Entscheidung, die Gerätesteuerung durchzuführen, die Gerätesteuerung durchzuführen, um das mindestens eine zugehörige elektronische Gerät zu steuern.
  22. Die Update-Agentenvorrichtung nach Anspruch 21, wobei die Update-Agentenvorrichtung dazu eingerichtet ist, sequentiell aktiviert zu werden, um Funktionen aus mindestens zwei oder mehr der Software-Updates, der Datenerfassung oder der Gerätesteuerung auszuführen.
  23. Die Update-Agentenvorrichtung nach Anspruch 22, wobei die Update-Agentenvorrichtung dazu eingerichtet ist, die Funktionen des Software-Update, der Datenerfassung oder der Gerätesteuerung nacheinander zu aktivieren.
  24. Die Update-Agentenvorrichtung nach Anspruch 22, wobei der Prozessor dazu eingerichtet ist, die Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie das Software-Update und die Datenerfassung oder/oder die Gerätesteuerung durchführt.
  25. Die Update-Agentenvorrichtung nach Anspruch 22, wobei der Prozessor dazu eingerichtet ist, die Programmierangaben zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie sowohl das Software-Update als auch die Datenerfassung und die Gerätesteuerung durchführt.
  26. Eine Update-Agentenvorrichtung, die dazu eingerichtet ist, mit mindestens einem zugehörigen elektronischen Gerät und einer Client-Vorrichtung in einem Fahrzeug zu kommunizieren, wobei die Update-Agentenvorrichtung umfasst: mindestens einen Speicher, der dazu eingerichtet ist, eine oder beide von einer oder mehreren Software-Update-Bedingungsangaben oder einer oder mehreren Rollback-Angaben zu speichern; und mindestens einen Prozessor, der dazu eingerichtet ist: von der Client-Vorrichtung eine Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie mindestens eine der Funktionen Software-Update, Datenerfassung oder Gerätesteuerung ausführt; als Reaktion auf den Empfang der Programmierangabe die Update-Agentenvorrichtung für das Software-Update und/oder die Datenerfassung und/oder die Gerätesteuerung zu programmieren; mit einer im Fahrzeug befindlichen Client-Vorrichtung zu kommunizieren, um mindestens eines der folgenden Schritte durchzuführen: (i) Empfangen eines Software-Updates für das mindestens eine zugehörige elektronische Gerät, wobei die Client-Vorrichtung so konfiguriert ist, dass sie mit einem externen Server kommuniziert, damit die Client-Vorrichtung das Software-Update für das Updaten der Software erhält; (ii) Übertragen von Daten, die bei der Datenerfassung mit dem mindestens einen zugehörigen elektronischen Gerät gesammelt wurden, an die Client-Vorrichtung; oder (iii) Empfangen eines oder mehrerer Steuerparameter, damit die Update-Agentenvorrichtung das mindestens eine zugehörige elektronische Gerät steuert; als Reaktion auf die Programmierung des Software-Update und als Reaktion auf den Empfang des Software-Update von der Client-Vorrichtung: auf der Grundlage einer oder mehrerer Software-Update-Bedingungsangaben zu bestimmen, ob das Software-Update durchgeführt werden soll; und als Reaktion auf die Entscheidung, das Software-Update durchzuführen, das Software-Update des mindestens einen zugehörigen elektronischen Geräts durchzuführen; auf die Programmierung für die Datenerfassung zu reagieren: auf der Grundlage einer oder mehrerer Angaben über den Zustand der Datenerfassung zu bestimmen, ob die Datenerfassung durchgeführt werden soll; als Reaktion auf die Entscheidung, die Datenerfassung durchzuführen, die Datenerfassung durchzuführen, um Daten von dem mindestens einen zugehörigen elektronischen Gerät zu erhalten; und die Daten aus der Datenerfassung an das Client-Gerät zu übertragen; in Abhängigkeit von der Programmierung des Steuergeräts: auf der Grundlage einer oder mehrerer Steuerangaben zu bestimmen, ob die Gerätesteuerung durchgeführt werden soll; und als Reaktion auf die Entscheidung, die Gerätesteuerung durchzuführen, die Gerätesteuerung durchzuführen, um das mindestens eine zugehörige elektronische Gerät zu steuern.
  27. Die Update-Agentenvorrichtung nach Anspruch 26, wobei die von der Client-Vorrichtung empfangene Programmierangabe wiederum von einem Server außerhalb des Fahrzeugs empfangen wird; und wobei die Update-Agentenvorrichtung dazu eingerichtet ist, nacheinander mindestens zwei oder mehr Funktionen Software-Update, Datenerfassung oder Gerätesteuerung zu aktivieren.
  28. Die Update-Agentenvorrichtung nach Anspruch 27, wobei die Update-Agentenvorrichtung dazu eingerichtet ist, die Funktionen Software-Update, Datenerfassung oder Gerätesteuerung nacheinander zu aktivieren.
  29. Die Update-Agentenvorrichtung nach Anspruch 27, wobei der Prozessor dazu eingerichtet ist, die Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie das Software-Update und die Datenerfassungen und/oder die Gerätesteuerung durchführt.
  30. Die Update-Agentenvorrichtung nach Anspruch 27, wobei der Prozessor dazu eingerichtet ist, die Programmierangabe zu empfangen, um die Update-Agentenvorrichtung so zu programmieren, dass sie sowohl das Software-Update als auch die Datenerfassung und die Gerätesteuerung durchführt.
DE112020005928.6T 2019-12-02 2020-12-02 Masteragent und verteilte Agentenarchitektur für Fahrzeuge Pending DE112020005928T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962942739P 2019-12-02 2019-12-02
US62/942,739 2019-12-02
PCT/US2020/062813 WO2021113305A1 (en) 2019-12-02 2020-12-02 Master agent and distributed agent architecture for vehicles

Publications (1)

Publication Number Publication Date
DE112020005928T5 true DE112020005928T5 (de) 2022-11-17

Family

ID=76222464

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020005928.6T Pending DE112020005928T5 (de) 2019-12-02 2020-12-02 Masteragent und verteilte Agentenarchitektur für Fahrzeuge

Country Status (3)

Country Link
US (1) US11914987B2 (de)
DE (1) DE112020005928T5 (de)
WO (1) WO2021113305A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102023100200A1 (de) 2023-01-05 2024-07-11 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Installieren eines Datenpakets auf einer elektronischen Recheneinrichtung für ein Kraftfahrzeug, Computerprogrammprodukt, computerlesbares Speichermedium sowie elektronische Recheneinrichtung

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7415726B2 (ja) * 2020-03-26 2024-01-17 株式会社オートネットワーク技術研究所 車載情報処理装置、情報処理方法及びサーバプログラム
JP7284143B2 (ja) * 2020-12-25 2023-05-30 本田技研工業株式会社 制御システム、移動体、制御方法及びプログラム
US11853100B2 (en) * 2021-04-12 2023-12-26 EMC IP Holding Company LLC Automated delivery of cloud native application updates using one or more user-connection gateways
US11593211B2 (en) * 2021-04-16 2023-02-28 Dell Products L.P. Applying a failure management policy during updating of components at an information handling system
FR3136289A1 (fr) * 2022-06-02 2023-12-08 Psa Automobiles Sa Procédé et dispositif de contrôle de calculateurs d’un véhicule
EP4332755A1 (de) * 2022-08-29 2024-03-06 Continental Automotive Technologies GmbH Systeme und verfahren zur massenanwendung von diensten von einem einzelnen zugangspunkt aus
EP4354300A1 (de) * 2022-10-13 2024-04-17 Vitesco Technologies GmbH Elektronische dienststeuereinheit und verfahren zur fehlerbehebung in einem heterogenen echtzeitsystem
CN116456301A (zh) * 2023-03-30 2023-07-18 成都赛力斯科技有限公司 一种程序刷写方法、装置、设备及存储介质
CN116701335B (zh) * 2023-05-17 2024-06-18 中国第一汽车股份有限公司 一种车载座舱域控制器跨系统日志数据处理方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190268420A1 (en) 2018-02-27 2019-08-29 Excelfore Corporation Broker-based bus protocol and multi-client architecture

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050132351A1 (en) * 2003-12-12 2005-06-16 Randall Roderick K. Updating electronic device software employing rollback
BRPI0701225A2 (pt) * 2007-03-27 2008-11-11 Vector Tecnologia E Sistemas Eletronicos Ltda sistema de gerenciamento de frotas com rfid e coletor de dados utilizado no mesmo
TWI462017B (zh) * 2012-02-24 2014-11-21 Wistron Corp 伺服器部署系統及資料更新的方法
US9715378B2 (en) * 2013-12-18 2017-07-25 International Business Machines Corporation Automated software update scheduling
KR102605987B1 (ko) 2017-01-05 2023-11-23 가드녹스 사이버 테크놀로지스 엘티디. 서비스 지향 아키텍처에 기초하는 집중식 서비스 ecu를구현하도록 구성된 관련 디바이스들을 갖는 특별히 프로그래밍된 컴퓨팅 시스템들 및 그 사용 방법들
US20190050294A1 (en) * 2017-12-29 2019-02-14 Intel Corporation Context aware software update framework for autonomous vehicles
JP7010087B2 (ja) 2018-03-16 2022-01-26 トヨタ自動車株式会社 プログラム更新管理装置、プログラム更新管理方法、およびプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190268420A1 (en) 2018-02-27 2019-08-29 Excelfore Corporation Broker-based bus protocol and multi-client architecture
US10834206B2 (en) 2018-02-27 2020-11-10 Excelfore Corporation Broker-based bus protocol and multi-client architecture
US10834207B2 (en) 2018-02-27 2020-11-10 Excelfore Corporation System and method for updating software in an electronic device

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102023100200A1 (de) 2023-01-05 2024-07-11 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Installieren eines Datenpakets auf einer elektronischen Recheneinrichtung für ein Kraftfahrzeug, Computerprogrammprodukt, computerlesbares Speichermedium sowie elektronische Recheneinrichtung

Also Published As

Publication number Publication date
US20230025735A1 (en) 2023-01-26
WO2021113305A1 (en) 2021-06-10
US11914987B2 (en) 2024-02-27

Similar Documents

Publication Publication Date Title
DE112020005928T5 (de) Masteragent und verteilte Agentenarchitektur für Fahrzeuge
US11704111B2 (en) Using data deltas in controllers and managing interdependencies between software versions in controllers using tool chain
US10599420B2 (en) Updating a controller unit in a vehicle
DE102015206764A1 (de) System und Verfahren zum Verwalten von Softwareaktualisierungen an einem Fahrzeugrechensystem
JP2017059211A (ja) ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
DE112017006980T5 (de) Steuereinrichtung, Programmaktualisierungsverfahren und Computerprogramm
DE102018100015A1 (de) Wechselverifizierung vor abschaltung
DE102013108020A1 (de) Authentifizierungsschema zum Aktivieren eines Spezial-Privileg-Modus in einem gesicherten elektronischen Steuergerät
DE112012003795T5 (de) Fahrzeugnetwerksystem und Fahrzeug-Informationsverarbeitungsverfahren
JP2022093680A (ja) ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
DE102017100380A1 (de) Diagnostiktest-durchführungssteuersystem und verfahren
DE102020208245A1 (de) Datenspeicherungsvorrichtung und Datenspeicherungsprogramm
DE112018004090T5 (de) Steuervorrichtung, Steuerverfahren und Computerprogramm
EP3405923B1 (de) Aktualisierung einer steuergeräteeinheit in einem fahrzeug
DE102021130897A1 (de) Elektronische steuerungseinheit, softwareaktualisierungsverfahren, softwareaktualisierungsprogramm und elektronisches steuerungssystem
DE102022122064A1 (de) System und verfahren für verbesserte ecu-ausfallerkennung in fahrzeugflotte
DE102017220472A1 (de) Verfahren und Vorrichtung zum datenorientierten Informationsaustausch mit einem Fahrzeugnetzwerk
DE102022122159A1 (de) Verbessertes gezieltes komponententesten
DE102022120276A1 (de) Austausch von flüchtigen schlüsseln zwischen fahrzeugsoftwareknoten
DE102022122188A1 (de) System und verfahren zum ermöglichen persistenter fahrzeugsoftwareschnittstellen
DE102022122162A1 (de) Eingebettete systemzeiterfassung bei automobilen
DE102019217047A1 (de) Verfahren und Vorrichtung zum Verwalten von Zugriffen mehrerer Softwarekomponenten auf Softwareschnittstellen
DE102022113922A1 (de) Ota-master, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
DE102022110251A1 (de) Ota-master, center, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
DE102022106659A1 (de) Ota-master, aktualisierungssteuerungsverfahren und nicht-transitorisches speichermedium