DE102022122167A1 - Verfahren zur ecu-echtzeit-absturzmeldung und wiederherstellung - Google Patents

Verfahren zur ecu-echtzeit-absturzmeldung und wiederherstellung Download PDF

Info

Publication number
DE102022122167A1
DE102022122167A1 DE102022122167.9A DE102022122167A DE102022122167A1 DE 102022122167 A1 DE102022122167 A1 DE 102022122167A1 DE 102022122167 A DE102022122167 A DE 102022122167A DE 102022122167 A1 DE102022122167 A1 DE 102022122167A1
Authority
DE
Germany
Prior art keywords
vehicle
information
volatile memory
data
server
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
DE102022122167.9A
Other languages
English (en)
Inventor
Richard Edward SLINDEE
Shayan Mukhtar
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.)
Rivian IP Holdings LLC
Original Assignee
Rivian IP Holdings LLC
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 Rivian IP Holdings LLC filed Critical Rivian IP Holdings LLC
Publication of DE102022122167A1 publication Critical patent/DE102022122167A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0816—Indicating performance data, e.g. occurrence of a malfunction
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die vorliegende Offenbarung betrifft Systeme und Verfahren, die auf das Verbessern der Funktionen eines Fahrzeugs gerichtet sind. Es werden Systeme und Verfahren bereitgestellt, die ein benutzerdefiniertes Werkzeug bereitstellen, das einen Satz von Softwareagenten automatisch generiert, die zulassen, dass ein System die Verarbeitung, Übertragung und das Empfangen von Nachrichten trennt, um eine bessere Synchronisation zu erreichen. Die Offenbarung hierin stellt auch ein vereinfachtes Verfahren der Bereitstellung von Schlüsseln bereit, indem ein Client als Server bezeichnet wird und jedem zweiten Client ein symmetrischer Schlüssel zugewiesen wird, der dauerhaft zwischen diesem Client und dem Server bereitgestellt wird. Ferner sind Systeme und Verfahren bereitgestellt, die Fehler in einem Fahrzeug vorhersagen. Es werden auch Systeme und Verfahren bereitgestellt, die Daten im Falle eines Systemabsturzes sichern. Es werden auch Systeme und Verfahren bereitgestellt, bei denen ein Betriebssystem eines Fahrzeugs das Vorhandensein eines neuen Peripheriegeräts erkennt und die zugehörige Schnittstellendatei für dieses neue Peripheriegerät zieht. Ferner wird hierin eine Datensynchronisationslösung bereitgestellt, die optimierte Synchronisationsebenen bereitstellt.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNG
  • Diese Offenbarung beansprucht den Vorteil der vorläufigen US-Anmeldung Nr. 63/240.190 , eingereicht am 2. September 2021, die durch Bezugnahme in ihrer Gesamtheit hierin eingeschlossen ist.
  • KURZDARSTELLUNG
  • Die vorliegende Offenbarung betrifft Systeme und Verfahren, die auf das Verbessern der Funktionen eines Fahrzeugs gerichtet sind.
  • Ein typisches Fahrzeug schließt Systeme ein, die Funktionen ausführen, die Synchronisation erfordern. Bei vielen dieser Systeme nehmen einige Aufgaben Priorität ein und können anderen zuvorkommen, wobei sie eine erste Aufgabe zugunsten einer anderen zurückstellen. Einige typische Fahrzeugsysteme führen auch eine End-to-End-Überprüfung und das Entpacken von Daten aus. Bei diesen Aufgaben müssen Signaldaten und End-to-End-Ergebnisdaten synchronisiert werden, um sicherzustellen, dass das End-to-End-Ergebnis den korrekten Daten entspricht. Wenn jedoch eine zweite Aufgabe einer End-to-End-Überprüfung zuvorkommt, entsprechen die Daten nicht einwandfrei. Die Diskrepanz bei Daten kann zu einem Problem führen, dessen Behebung zusätzliche Zyklen erfordern kann, oder das sogar zu einem Systemabsturz führen kann. Folglich ist ein System erforderlich, um Synchronisation zwischen Aufgaben sicherzustellen. Gemäß der vorliegenden Offenbarung werden Systeme und Verfahren bereitgestellt, die ein benutzerdefiniertes Werkzeug bereitstellen, das einen Satz von Softwareagenten automatisch generiert, die zulassen, dass ein System die Verarbeitung, Übertragung und das Empfangen von Nachrichten trennt, um eine bessere Synchronisation zu erreichen. In einigen Ausführungsformen wird ein vorausgewähltes textbasiertes Deskriptordateiformat (z. B. speziell formatierte DBC-Dateien) dazu verwendet, das Netzwerk des Fahrzeugs durch mehrere Dateifragmente pro Bus zu beschreiben. Das Deskriptordateiformat kann einen bestimmten Stil von Kommentaren oder verkürzten Abschnitten erfordern, die die benötigten Informationen bereitstellen, aber nicht ausgeführt werden würden. In einer anderen Implementierung kann ein Deskriptordateiformat erfordern, dass Daten in einer bestimmten Reihenfolge und mit bestimmten Markierungen (z. B. mit vordefinierten Variablennamen) bereitgestellt werden. In einigen Ausführungsformen kennt die Software zur automatischen Codegenerierung das Dateiformat und kann Signale hinzufügen, die ohne Problem oder zusätzliche Verarbeitung kompiliert werden können.
  • Einige Ausführungsformen schließen ein Verfahren ein, das Zugreifen auf eine Datei umfasst, die Informationen zum Decodieren von Busdaten umfasst, Generieren, basierend auf der Datei, einer Vielzahl von Softwareagenten, wobei die Softwareagenten, wenn sie ausgeführt werden, dazu konfiguriert sind, eine Rohnachricht über den Bus zu empfangen, wobei die Rohnachricht einen Signalwert generieren, Generieren eines Sicherheitsschutzwerts für die Rohnachricht und als Reaktion auf eine Anforderung nach dem Signalwert von einer Instanz einer Anwendung, die basierend auf Anweisungen an einem geschützten Speicherort ausgeführt wird, Bereitstellen eines synchronen Zugriffs auf den Signalwert und den Sicherheitsschutzwert. In einigen Ausführungsformen umfasst das Generieren der Vielzahl von Softwareagenten einen ersten Satz von Anweisungen zum Ausführen aus einer ersten nicht sicheren Speicherpartition, wobei der erste Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, eine Rohnachricht von dem Bus zu empfangen, Generieren eines zweiten Satzes von Anweisungen zur Ausführung aus einer geschützten Speicherpartition, wobei der zweite Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, die Rohnachricht zu entpacken, um den Signalwert zu generieren, Durchführen einer Verifizierung, um den Sicherheitsschutzwert für die Rohnachricht zu generieren, Speichern des Signalwerts und des Sicherheitsschutzwerts zu speichern und synchrones Übertragen des Signalwerts und des Sicherheitsschutzwerts auf die Instanz einer Anwendung, einen dritten Satz von Anweisungen zur Ausführung aus einer zweiten nicht sicheren Speicherpartition, wobei der dritte Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, die Rohnachricht zu entpacken, um einen Signalwert zu generieren, den Signalwert auf die Instanz einer Anwendung zu übertragen. In einigen Ausführungsformen ist der Bus ein Controller Area Network-Bus (CAN-Bus). In einigen Ausführungsformen ist die Datei eine Datenbankdatei (DBC-Datei), die Anweisungen zum Decodieren von CAN-Busdaten von mindestens einem Sensor umfasst. In einigen Ausführungsformen ist die erste nicht sichere Speicherpartition eine Qualitätsmanagementpartition (QM-Partition). In einigen Ausführungsformen ist die geschützte Speicherpartition eine Automotive Safety Integrity Level-Partition (ASIL-Partition). In einigen Ausführungsformen umfasst das Generieren des Sicherheitsschutzwerts das Generieren eines End-to-End-Status (E2E-Status).
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit darauf codierten Anweisungen ein, die, wenn sie durch eine Steuerschaltlogik ausgeführt werden, die Steuerschaltlogik veranlassen, auf eine Datei zuzugreifen, die Informationen zum Decodieren von Busdaten umfasst, basierend auf der Datei eine Vielzahl von Softwareagenten zu generieren, wobei die Softwareagenten, wenn sie ausgeführt werden, dazu konfiguriert sind, eine Rohnachricht über den Bus zu empfangen, die Rohnachricht zu entpacken, um einen Signalwert zu generieren, einen Sicherheitsschutzwert für die Rohnachricht zu generieren, und als Reaktion auf eine Anforderung nach dem Signalwert von einer Instanz einer Anwendung, die basierend auf Anweisungen an einem geschützten Speicherort ausgeführt wird, einen synchronen Zugriff auf den Signalwert und den Sicherheitsschutzwert bereitzustellen. In einigen Ausführungsformen bewirkt die Steuerschaltlogik das Generieren der Vielzahl von Softwareagenten durch Generieren eines ersten Satzes von Anweisungen zum Ausführen aus einer ersten nicht sicheren Speicherpartition, wobei der erste Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, eine Rohnachricht von dem Bus zu empfangen, Generieren eines zweiten Satzes von Anweisungen zur Ausführung aus einer geschützten Speicherpartition, wobei der zweite Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, die Rohnachricht zu entpacken, um den Signalwert zu generieren, Durchführen einer Verifizierung, um den Sicherheitsschutzwert für die Rohnachricht zu generieren, Speichern des Signalwerts und des Sicherheitsschutzwerts und synchrones Übertragen des Signalwerts und des Sicherheitsschutzwerts auf die Instanz einer Anwendung, Generieren eines dritten Satzes von Anweisungen zur Ausführung aus einer zweiten nicht sicheren Speicherpartition, wobei der dritte Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, die Rohnachricht zu entpacken, um einen Signalwert zu generieren, den Signalwert auf die Instanz einer Anwendung zu übertragen. In einigen Ausführungsformen ist der Bus ein Controller Area Network-Bus (CAN-Bus). In einigen Ausführungsformen ist die Datei eine Datenbankdatei (DBC-Datei), die Anweisungen zum Decodieren von CAN-Busdaten von mindestens einem Sensor umfasst. In einigen Ausführungsformen ist die erste nicht sichere Speicherpartition eine Qualitätsmanagementpartition (QM-Partition). In einigen Ausführungsformen ist die geschützte Speicherpartition eine Automotive Safety Integrity Level-Partition (ASIL-Partition). In einigen Ausführungsformen umfasst das Generieren des Sicherheitsschutzwerts das Generieren eines End-to-End-Status (E2E-Status).
  • Einige Ausführungsformen schließen ein Fahrzeugsystem ein, umfassend einen Sensor, der mit mindestens einem Bus verbunden ist, und eine Steuerschaltlogik, die dazu konfiguriert ist, auf eine Datei zuzugreifen, die Informationen zum Decodieren von Busdaten umfasst, die vom Sensor über den Bus erhalten wurden, und Generieren, basierend auf der Datei, einer Vielzahl von Softwareagenten, wobei die Softwareagenten, wenn sie ausgeführt werden, dazu konfiguriert sind, eine Rohnachricht über den Bus zu empfangen, die Rohnachricht zu entpacken, um einen Signalwert generieren, Generieren eines Sicherheitsschutzwerts für die Rohnachricht und als Reaktion auf eine Anforderung nach dem Signalwert von einer Instanz einer Anwendung, die basierend auf Anweisungen an einem geschützten Speicherort ausgeführt wird, Bereitstellen eines synchrones Zugriffs auf den Signalwert und den Sicherheitsschutzwert. In einigen Ausführungsformen ist die Steuerschaltlogik dazu konfiguriert, die Vielzahl von Softwareagenten durch
  • Generieren eines ersten Satzes von Anweisungen zum Ausführen aus einer ersten nicht sicheren Speicherpartition zu generieren, wobei der erste Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, eine Rohnachricht von dem Bus zu empfangen, einen zweiten Satz von Anweisungen zur Ausführung aus einer geschützten Speicherpartition zu generieren, wobei der zweite Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, die Rohnachricht zu entpacken, um den Signalwert zu generieren, eine Verifizierung durchzuführen, um den Sicherheitsschutzwert für die Rohnachricht zu generieren, den Signalwert und den Sicherheitsschutzwert zu speichern und synchron den Signalwert und den Sicherheitsschutzwert auf die Instanz einer Anwendung zu übertragen, einen dritten Satz von Anweisungen zur Ausführung aus einer zweiten nicht sicheren Speicherpartition zu generieren, wobei der dritte Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, die Rohnachricht zu entpacken, um einen Signalwert zu generieren, den Signalwert auf die Instanz einer Anwendung zu übertragen. In einigen Ausführungsformen ist der Bus ein Controller Area Network-Bus (CAN-Bus). In einigen Ausführungsformen ist die Datei eine Datenbankdatei (DBC-Datei), die Anweisungen zum Decodieren von CAN-Busdaten von mindestens einem Sensor umfasst. In einigen Ausführungsformen ist die erste nicht sichere Speicherpartition eine Qualitätsmanagementpartition (QM-Partition). In einigen Ausführungsformen ist die geschützte Speicherpartition eine Automotive Safety Integrity Level-Partition (ASIL-Partition).
  • Typische Fahrzeugsysteme schließen Hardware- oder Softwaremodule ein, die möglicherweise (einen) kryptografische(n) Schlüssel (z. B. einen flüchtigen Schlüssel) austauschen müssen, um zwischen ihnen gesendete Nachrichten zu verschlüsseln. Vorhandene Systeme sind aufwändig, da sie viele Schlüssel und Zertifikate für jedes Modul erfordern, um einen privaten oder öffentlichen Schlüssel für jede sichere Transaktion aufzuweisen. Es wird ein verbessertes, vereinfachtes Verfahren zur Schlüsselbereitstellung benötigt. Die Offenbarung stellt hierin ein solches Verfahren bereit, indem ein Client als Server bezeichnet wird und jedem zweiten Client ein symmetrischer Schlüssel zugewiesen wird, der dauerhaft zwischen diesem Client und dem Server bereitgestellt wird. Dieser symmetrische Schlüssel minimiert die Notwendigkeit eines dauerhaften Schlüssels und kann zur Nutzung von flüchtigen Schlüsseln verwendet werden. Während eines Austauschs kann ein Client in einigen Ausführungsformen die Kommunikation mit einem zweiten Client initiieren. In einigen Ausführungsformen kann der zweite Client dann von dem Server einen flüchtigen Schlüssel anfordern, der für diese Transaktion erstellt wurde. Der Server kann auch verifizieren, dass der erste Client tatsächlich eine Kommunikation angefordert hat. Der Server kann auf den Client 2 mit dem flüchtigen Schlüssel reagieren. In einigen Ausführungsformen sind die Clients 1 und 2 nun im Besitz eines gemeinsamen Schlüssels und können sicher kommunizieren. Dieses Verfahren reduziert die Anzahl der erforderlichen Schlüssel und vereinfacht die sichere Kommunikation.
  • Einige Ausführungsformen schließen ein Verfahren zum Herstellen sicherer Kommunikationen zwischen einem ersten Knoten und einem zweiten Knoten innerhalb eines Fahrzeugs ein, wobei das Verfahren die folgenden Schritte umfasst Empfangen, von dem ersten Knoten des Fahrzeugs, einer ersten Nachricht, die Informationen umfasst, die den zweiten Knoten des Fahrzeugs identifizieren, als Reaktion auf das Empfangen der ersten Nachricht, Generieren, unter Verwendung der Verarbeitungsschaltlogik des Fahrzeugs, eines Verschlüsselungsschlüssels, Kommunizieren, an den ersten Knoten des Fahrzeugs, von Informationen, die den Verschlüsselungsschlüssel identifizieren, Empfangen, von dem zweiten Knoten des Fahrzeugs, einer zweiten Nachricht, die Informationen umfasst, die den ersten Knoten des Fahrzeugs identifizieren, Bestimmen, unter Verwendung der Verarbeitungsschaltlogik, dass die zweite Nachricht gültig ist, basierend auf der ersten Nachricht, und Kommunizieren, an den zweiten Knoten des Fahrzeugs, Informationen, die den Verschlüsselungsschlüssel identifizieren. In einigen Ausführungsformen umfasst die erste Nachricht ferner eine Zufallszahl, die durch den ersten Knoten des Fahrzeugs generiert wird. Einige Ausführungsformen schließen das Kommunizieren eines Hash der Zufallszahl an den ersten Knoten des Fahrzeugs ein. In einigen Ausführungsformen umfasst die zweite Nachricht ferner eine Zufallszahl, die durch den zweiten Knoten generiert wird. Einige Ausführungsformen schließen das Kommunizieren eines Hash der Zufallszahl an den ersten Knoten des Fahrzeugs ein. In einigen Ausführungsformen befinden sich der erste Knoten des Fahrzeugs und der zweite Knoten des Fahrzeugs auf einem gemeinsam genutzten Bus im Fahrzeug. In einigen Ausführungsformen erfolgen das Kommunizieren mit dem ersten Knoten des Fahrzeugs und das Kommunizieren mit dem zweiten Knoten des Fahrzeugs über den gemeinsam genutzten Bus.
  • Einige Ausführungsformen schließen ein System zum Herstellen sicherer Kommunikationen zwischen einem ersten Knoten und einem zweiten Knoten innerhalb eines Fahrzeugs ein, wobei das System eine erste Nachricht von dem ersten Knoten des Fahrzeugs umfasst, die Informationen umfasst, die den zweiten Knoten des Fahrzeugs identifizieren, eine zweite Nachricht von dem zweiten Knoten des Fahrzeugs, die Informationen umfasst, die den ersten Knoten des Fahrzeugs identifizieren, wobei basierend auf der ersten Nachricht bestimmt wird, dass die zweite Nachricht gültig ist, und einen Verschlüsselungsschlüssel, wobei der Verschlüsselungsschlüssel gegenüber dem ersten Knoten und dem zweiten Knoten identifiziert wird. In einigen Ausführungsformen umfasst die erste Nachricht ferner eine Zufallszahl, die durch den ersten Knoten des Fahrzeugs generiert wird. Einige Ausführungsformen schließen einen Hash der Zufallszahl ein, wobei der Hash an den ersten Knoten des Fahrzeugs kommuniziert wird. In einigen Ausführungsformen umfasst die zweite Nachricht ferner eine Zufallszahl, die durch den zweiten Knoten generiert wird. Einige Ausführungsformen schließen einen Hash der Zufallszahl ein, wobei der Hash an den ersten Knoten des Fahrzeugs kommuniziert wird. In einigen Ausführungsformen befinden sich der erste Knoten des Fahrzeugs und der zweite Knoten des Fahrzeugs auf einem gemeinsam genutzten Bus im Fahrzeug. In einigen Ausführungsformen wird der Verschlüsselungsschlüssel durch Kommunikation über den gemeinsam genutzten Bus gegenüber dem ersten Knoten und dem zweiten Knoten identifiziert.
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit darauf codierten nicht-transitorischen computerlesbaren Anweisungen ein, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, von dem ersten Knoten des Fahrzeugs eine erste Nachricht zu empfangen, die Informationen umfasst, die den zweiten Knoten des Fahrzeugs identifizieren, als Reaktion auf das Empfangen der ersten Nachricht, Generieren, unter Verwendung der Verarbeitungsschaltlogik des Fahrzeugs, eines Verschlüsselungsschlüssels, Kommunizieren, an den ersten Knoten des Fahrzeugs, von Informationen, die den Verschlüsselungsschlüssel identifizieren, Empfangen, von dem zweiten Knoten des Fahrzeugs, einer zweiten Nachricht, die Informationen umfasst, die den ersten Knoten des Fahrzeugs identifizieren;
  • Bestimmen, unter Verwendung der Verarbeitungsschaltlogik, dass die zweite Nachricht gültig ist, basierend auf der ersten Nachricht, und Kommunizieren an den zweiten Knoten des Fahrzeugs, von Informationen, die den Verschlüsselungsschlüssel identifizieren. In einigen Ausführungsformen umfasst die erste Nachricht ferner eine Zufallszahl, die durch den ersten Knoten des Fahrzeugs generiert wird. Einige Ausführungsformen schließen das Kommunizieren eines Hash der Zufallszahl an den ersten Knoten des Fahrzeugs ein. In einigen Ausführungsformen umfasst die zweite Nachricht ferner eine Zufallszahl, die durch den zweiten Knoten generiert wird. In einigen Ausführungsformen befinden sich der erste Knoten des Fahrzeugs und der zweite Knoten des Fahrzeugs auf einem gemeinsam genutzten Bus im Fahrzeug. In einigen Ausführungsformen erfolgt das Kommunizieren an den ersten Knoten des Fahrzeugs und das Kommunizieren an den zweiten Knoten des Fahrzeugs über den gemeinsam genutzten Bus.
  • Im Verlauf der Lebensdauer des Fahrzeugs kommt es zu Fehlfunktionen. Funktionsstörungen in einem Fahrzeug können nicht nur Unannehmlichkeiten verursachen, wie z. B. Auswirkungen auf die Leistung des Fahrzeugs, sie können auch gefährlich sein, da sie die Sicherheit des Fahrzeugs beeinträchtigen können. Sie können ferner zu anderen Störungen mit zusätzlichen Problemen führen. Bei diesen Komplikationen ist es vorteilhaft, Fehlfunktionen möglichst schnell zu erkennen, sodass sie vor dem Entstehen gefährlicher oder teurer Komplikationen angegangen werden können. Insbesondere wird ein System benötigt, das Fehler vorhersagt, bevor sie auftreten. Gemäß der vorliegenden Offenbarung werden Systeme und Verfahren bereitgestellt, die Fehler in einem Fahrzeug vorhersagen. In einigen Ausführungsformen schließt das System eine Flotte von Fahrzeugen ein, die alle mit einem Server verbunden sind. Der Server kann Daten von mehreren Fahrzeugen in der Flotte bezüglich der Metriken und Zustände des Fahrzeugs empfangen. Der Server kann ferner die empfangenen Metriken analysieren und bestimmen, wie oft ein bestimmtes Problem auftritt. Der Server kann diese Informationen speichern und weiterhin Fahrzeuge überwachen. Ein weiteres Fahrzeug kann Metriken melden, die ähnlich einem bestimmten Problem sind oder für die eine Korrelation dazu gezeigt wurde, und der Server kann eine frühzeitige Ausfallerkennung für dieses Fahrzeug bereitstellen. In einigen Ausführungsformen kann der Server eine frühzeitige Warnung an das Fahrzeug übertragen, dringend Reparaturen oder andere Maßnahmen auszuführen. Auf diese Weise bietet die Offenbarung ein Mittel zum Vorhersagen einer Fehlfunktion und Abmildern der von dieser ggf. verursachten Schäden.
  • Einige Ausführungsformen schließen ein Verfahren zum Vorhersagen eines Fehlerereignisses in einem Fahrzeug ein, wobei das Verfahren umfasst: Überwachung, Verwendung einer Verarbeitungsschaltlogik, einer Vielzahl von Betriebsparametern eines Fahrzeugs und eines geografischen Orts des Fahrzeugs, der unter Verwendung der Verarbeitungsschaltlogik bestimmt, dass Werte der Betriebsparameter und des geografischen Orts wahrscheinlich mit einem Fehlerereignis korrelieren, basierend auf einem Modell, das unter Verwendung jeweiliger Werte der Betriebsparameter für einen Satz von Fahrzeugen und jeweiligen geografischen Orten des Satzes von Fahrzeugen trainiert wird, an denen entsprechende Fehlerereignisse auftreten, und Bewirken, unter Verwendung der Verarbeitungsschaltlogik, einer Aktion, die als Reaktion auf das Bestimmen durchgeführt wird. Einige Ausführungsformen schließen auch das Übertragen der Betriebsparameter und des geografischen Orts des Fahrzeugs auf einen entfernten Server ein, wobei das Bestimmen, dass die Werte der Betriebsparameter und des geografischen Orts wahrscheinlich mit dem Fehlerereignis korrelieren, das Empfangen von Informationen, die die Korrelation angeben, von dem entfernten Server umfasst. In einigen Ausführungsformen befindet sich das Modell auf dem entfernten Server. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, dass eine Benachrichtigung bereitgestellt wird, die das Fehlerereignis angibt. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, eine Änderung mindestens eines der Vielzahl von Betriebsparametern, um zu vermeiden, dass das Fehlerereignis auftritt. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, das Bewirken, dass die Aktion an einem entfernten Server durchgeführt wird, wobei die Aktion innerhalb des Fahrzeugs durchgeführt wird. In einigen Ausführungsformen wird das Modell wiederholt basierend auf neuen Daten aktualisiert, die von dem Satz von Fahrzeugen bereitgestellt werden.
  • Einige Ausführungsformen schließen ein System zum Vorhersagen eines Fehlerereignisses in einem Fahrzeug ein, wobei das System umfasst: eine Vielzahl von Betriebsparametern eines Fahrzeugs, einen geografischen Ort des Fahrzeugs, Werte der Betriebsparameter und des geografischen Orts, die wahrscheinlich mit einem Fehlerereignis korrelieren, basierend auf einem Modell, das unter Verwendung jeweiliger Werte der Betriebsparameter für einen Satz von Fahrzeugen trainiert wird, und jeweiliger geografischer Orte des Satzes von Fahrzeugen, an denen entsprechende Fehlerereignisse auftreten, wobei bestimmt wird, dass Werte der Betriebsparameter und des geografischen Orts wahrscheinlich mit einem Fehler korrelieren, basierend auf dem Modell und einer Aktion, die als Reaktion auf das Bestimmen durchgeführt wird. Einige Ausführungsformen schließen das Bereitstellen von Informationen ein, die die Korrelation der Betriebsparameter und des geografischen Orts des Fahrzeugs mit dem Fehlerereignis angeben. In einigen Ausführungsformen befindet sich das Modell auf dem entfernten Server. Einige Ausführungsformen schließen eine Benachrichtigung ein, die das Fehlerereignis angibt. In einigen Ausführungsformen umfasst die Aktion eine Änderung mindestens eines von der Vielzahl von Betriebsparametern, um zu vermeiden, dass das Fehlerereignis auftritt. In einigen Ausführungsformen wird die Aktion durch einen entfernten Server durchgeführt und wobei die Aktion innerhalb des Fahrzeugs durchgeführt wird. In einigen Ausführungsformen wird das Modell wiederholt basierend auf neuen Daten aktualisiert, die von dem Satz von Fahrzeugen bereitgestellt werden.
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit nicht-transitorischen darauf codierten computerlesbaren Anweisungen ein, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, unter Verwendung der Verarbeitungsschaltlogik eine Vielzahl von Betriebsparametern eines Fahrzeugs und einen geografischen Ort des Fahrzeugs zu überwachen, unter Verwendung der Verarbeitungsschaltlogik zu bestimmen, dass Werte der Betriebsparameter und des geografischen Orts wahrscheinlich mit einem Fehlerereignis korrelieren, basierend auf einem Modell, das unter Verwendung jeweiliger Werte der Betriebsparameter für einen Satz von Fahrzeugen und jeweilige geografische Orte des Satzes von Fahrzeugen, an denen entsprechende Fehlerereignisse auftreten, trainiert werden, und unter Verwendung der Verarbeitungsschaltlogik eine Aktion bewirken, die als Reaktion auf das Bestimmen durchzuführen ist. Einige Ausführungsformen schließen das Übertragen der Betriebsparameter und des geografischen Orts des Fahrzeugs an einen entfernten Server ein, wobei das Bestimmen, dass die Werte der Betriebsparameter und der geografischen Position wahrscheinlich mit dem Fehlerereignis korrelieren, das Empfangen von Informationen, die die Korrelation angeben, von dem entfernten Server umfasst. In einigen Ausführungsformen befindet sich das Modell auf dem entfernten Server. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, dass eine Benachrichtigung bereitgestellt wird, die das Fehlerereignis angibt. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, das Bewirken einer Änderung mindestens eines der Vielzahl von Betriebsparametern, um zu vermeiden, dass das Fehlerereignis auftritt. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, das Bewirken, dass die Aktion an einem entfernten Server durchgeführt wird, wobei die Aktion innerhalb des Fahrzeugs durchgeführt wird. In einigen Ausführungsformen wird das Modell wiederholt basierend auf neuen Daten aktualisiert, die von dem Satz von Fahrzeugen bereitgestellt werden.
  • Systemabstürze sind ein häufiges Problem bei Fahrzeugsystemen. Systeme können unter Umständen zum Beispiel nicht mehr reagieren. In diesen Situationen besteht die Gefahr, dass das System Daten verliert, da einige Informationen unwiederbringlich verloren oder nicht wiederherstellbar sein können. Datenverlust kann verhindern, dass Funktionen ordnungsgemäß arbeiten oder Informationen korrekt aufzeichnen, was beides zu verschiedenen Problemen führen kann. Daher wird ein System zum Sichern von Daten benötigt. Gemäß der vorliegenden Offenbarung werden Systeme und Verfahren bereitgestellt, die Daten im Falle eines Systemabsturzes sichern. In einigen Ausführungsformen schließt das System einen Standby-Speicher ein. In einigen Ausführungsformen kann das System einen oder mehrere Schnappschüsse von Systeminformationen aufnehmen und in dem Standby-Speicher speichern. In einigen Ausführungsformen wird der Speicher zwischen Systemstarts nicht gelöscht. Auf diese Weise stellt das offenbarte System ein Mittel zum Sichern von Daten im Falle eines Absturzes bereit.
  • Einige Ausführungsformen schließen ein Verfahren zum Speichern von Informationen über ein Fahrzeug ein, wobei das Verfahren umfasst: Erkennen, durch die Verarbeitungsschaltlogik, eines Fehlerereignisses und als Reaktion auf das Erkennen, Generieren, durch die Verarbeitungsschaltlogik, der Informationen über das Fahrzeug zu einer Zeit des Fehlerereignisses, Generieren, durch die Verarbeitungsschaltlogik, von Integritätsdaten basierend auf den Informationen, Bewirken, dass durch die Verarbeitungsschaltlogik die Informationen über das Fahrzeug und die Integritätsdaten in einem Abschnitt des flüchtigen Speichers gespeichert werden, wobei der Abschnitt des flüchtigen Speichers dazu konfiguriert ist, gespeicherte Daten während eines Neustarts eines Betriebssystems des Fahrzeugs zu erhalten, Bewirken, unter Verwendung der Verarbeitungsschaltlogik, dass das Betriebssystem des Fahrzeugs neu gestartet wird, nach dem Neustart, Validieren, unter Verwendung der Verarbeitungsschaltlogik, der in dem flüchtigen Speicher gespeicherten Informationen basierend auf den Integritätsdaten, und als Reaktion auf das Validieren, Bewirken, dass die Informationen über das Fahrzeug im nichtflüchtigen Speicher gespeichert werden. In einigen Ausführungsformen umfassen die Integritätsdaten eine zyklische Redundanzprüfung (Cyclic Redundancy Check, CRC). In einigen Ausführungsformen umfasst der flüchtige Speicher einen Direktzugriffsspeicher (Random Access Memory, RAM). In einigen Ausführungsformen ist der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers, der für die Informationen und die Integritätsdaten reserviert ist. In einigen Ausführungsformen umfasst das Erkennen des Fehlerereignisses das Erkennen eines Systemabsturzes. In einigen Ausführungsformen umfassen die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug. In einigen Ausführungsformen wird das Generieren der Informationen, Generieren der Integritätsdaten und Bewirken, dass die Informationen und die Integritätsdaten gespeichert werden, durch einen Notfall-Stapel durchgeführt, der dazu programmiert ist, im Falle des Fehlerereignisses ausgeführt zu werden. Einige Ausführungsformen schließen ein System zum Speichern von Informationen über ein Fahrzeug ein, wobei das System umfasst: ein Betriebssystem eines Fahrzeugs, ein Fehlerereignis, Informationen über das Fahrzeug zu einer Zeit des Fehlerereignisses, Integritätsdaten, die basierend auf den Informationen über das Fahrzeug zu einer Zeit des Fehlerereignisses generiert werden, einen Abschnitt des flüchtigen Speichers, der dazu konfiguriert ist, gespeicherte Daten während eines Neustarts des Betriebssystems des Fahrzeugs zu erhalten, wobei die Informationen über das Fahrzeug und die Integritätsdaten in dem Abschnitt des flüchtigen Speichers als Reaktion auf das Fehlerereignis gespeichert werden,
    nichtflüchtigen Speicher, wobei als Reaktion darauf, dass das Betriebssystem des Fahrzeugs neu gestartet wird, die Informationen über das Fahrzeug basierend auf den Integritätsdaten validiert werden, und wobei als Reaktion auf die Validierung die Informationen über das Fahrzeug in dem nichtflüchtigen Speicher gespeichert werden. In einigen Ausführungsformen umfassen die Integritätsdaten eine zyklische Redundanzprüfung (Cyclic Redundancy Check, CRC). In einigen Ausführungsformen umfasst der flüchtige Speicher einen Direktzugriffsspeicher (Random Access Memory, RAM). In einigen Ausführungsformen ist der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers, der für die Informationen und die Integritätsdaten reserviert ist. In einigen Ausführungsformen umfasst das Erkennen des Fehlerereignisses das Erkennen eines Systemabsturzes. In einigen Ausführungsformen umfassen die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug. Einige Ausführungsformen schließen einen Notfall-Stapel ein, der dazu programmiert ist, die Informationen zu generieren, die Integritätsdaten zu generieren und die Informationen und die Integritätsdaten im Falle des Fehlerereignisses zu speichern.
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit nicht-transitorischen darauf codierten computerlesbaren Anweisungen ein, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, durch eine Verarbeitungsschaltlogik ein Fehlerereignis zu erkennen, und als Reaktion auf das Erkennen durch die Verarbeitungsschaltlogik die Informationen über das Fahrzeug zu einer Zeit des Fehlerereignisses zu generieren, durch die Verarbeitungsschaltlogik Integritätsdaten basierend auf den Informationen zu generieren, durch die Verarbeitungsschaltlogik das Speichern der Informationen über das Fahrzeug und die Integritätsdaten in einem Abschnitt des flüchtigen Speichers zu bewirken, wobei der Abschnitt des flüchtigen Speichers dazu konfiguriert ist, gespeicherte Daten während eines Neustarts eines Betriebssystems des Fahrzeugs zu erhalten, unter Verwendung der Verarbeitungsschaltlogik den Neustart des Betriebssystems des Fahrzeugs zu bewirken, nach dem Neustart unter Verwendung der Verarbeitungsschaltlogik die im flüchtigen Speicher gespeicherten Informationen basierend auf den Integritätsdaten zu validieren und als Reaktion auf das Validieren zu bewirken, dass die Informationen über das Fahrzeug im nichtflüchtigen Speicher gespeichert werden. In einigen Ausführungsformen umfassen die Integritätsdaten eine zyklische Redundanzprüfung (Cyclic Redundancy Check, CRC). In einigen Ausführungsformen umfasst der flüchtige Speicher einen Direktzugriffsspeicher (Random Access Memory, RAM). In einigen Ausführungsformen ist der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers, der für die Informationen und die Integritätsdaten reserviert ist. In einigen Ausführungsformen umfasst das Erkennen des Fehlerereignisses das Erkennen eines Systemabsturzes. In einigen Ausführungsformen umfassen die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug.
  • Ein typisches Fahrzeug schließt Peripherieteile, wie einen Pumpenausfall, ein. Peripherieteile sind in vielen Modellen von vielen Herstellern erhältlich. Oft sind Schnittstellendateien zum Handhaben einer spezifischen Datei von einem bestimmten Peripheriegerät fest zugeordnet. Wenn sich die Peripheriehardware ändert, können die vorhandenen Schnittstellendateien nicht mit dem neuen Peripheriegerät kommunizieren und es ist eine völlig neue Schnittstellenhardware erforderlich. Dies ist aufwändig und kann Verzögerungen im System hervorrufen. Viele Peripheriegeräte nutzen jedoch unabhängig von der Hardware gemeinsame Komponenten. Daher ist es vorteilhaft, ein System bereitzustellen, das unabhängig von der Peripheriehardware konsistent ist. Insbesondere wird ein System benötigt, das denselben Anwendungscode innerhalb unterschiedlicher Hardware verwendet. Gemäß der vorliegenden Offenbarung wird ein System bereitgestellt, bei dem ein Betriebssystem eines Fahrzeugs das Vorhandensein eines neuen Peripheriegeräts erkennt und die zugehörige Schnittstellendatei für dieses neue Peripheriegerät zieht. In einigen Ausführungsformen stellt das System eine Abstraktionsschicht zwischen der Peripheriedatei und den Anwendungen bereit, die Peripheriedaten empfangen. In einigen Ausführungsformen kann jede Software, die sich auf das Peripheriegerät bezieht, in der Lage sein, sich direkt oder indirekt auf die Abstraktionsschicht zu stützen, die Daten von einem beliebigen Peripheriegerät mit einer gemeinsamen Funktion übersetzen kann. Dementsprechend kann das Peripheriegerät nun geändert werden, ohne dass vorhandene Software ausgetauscht werden muss.
  • Einige Ausführungsformen schließen ein Verfahren zum Aktualisieren eines Fahrzeugs ein, wenn eine neue Hardwarekomponente installiert wird, wobei das Verfahren umfasst: Erkennen, unter Verwendung der Verarbeitungsschaltlogik in dem Fahrzeug, der neuen Hardwarekomponente, Identifizieren, unter Verwendung der Verarbeitungsschaltlogik, einer Zuordnung zwischen den von der neuen Hardwarekomponente generierten Daten-Konfigurationsdaten und mindestens einer Softwarekomponente des Fahrzeugs, und Generieren, unter Verwendung der Verarbeitungsschaltlogik, einer aktualisierten Schnittstelle zum Interpretieren der Daten von der Hardwarekomponente, wobei die aktualisierte Schnittstelle die von der Hardwarekomponente bereitgestellten Daten in abstrahierte Informationen umwandelt, und wobei die aktualisierte Schnittstelle die abstrahierten Informationen der mindestens einen Softwarekomponente des Fahrzeugs bereitstellt. In einigen Ausführungsformen umfassen die von der neuen Hardwarekomponente generierten Daten eine Datenbankdatei (DBC-Datei). Einige Ausführungsformen schließen das Speichern der aktualisierten Schnittstelle in einer Bibliothek von Schnittstellen ein, wobei das Generieren der aktualisierten Schnittstelle das Zugreifen auf die aktualisierte Schnittstelle aus der Bibliothek umfasst. In einigen Ausführungsformen wird die aktualisierte Schnittstelle basierend auf einer Identifikation der neuen Hardwarekomponente aus der Bibliothek ausgewählt. Einige Ausführungsformen schließen das Verarbeiten der abstrahierten Informationen ungeachtet der von der neuen Hardwarekomponente generierten Daten durch die mindestens eine Softwarekomponente des Fahrzeugs ein. In einigen Ausführungsformen wird die aktualisierte Schnittstelle zur bidirektionalen Kommunikation zwischen der mindestens einen Softwarekomponente und der neuen Hardwarekomponente verwendet. In einigen Ausführungsformen umfasst das Generieren der aktualisierten Schnittstelle das Modifizieren einer vorhandenen Schnittstelle.
  • Einige Ausführungsformen schließen ein System zum Aktualisieren eines Fahrzeugs ein, wenn eine neue Hardwarekomponente installiert wird, wobei das System umfasst: die neue Hardwarekomponente, eine Zuordnung zwischen Daten, die von der neuen Hardwarekomponente generiert werden, und mindestens eine Softwarekomponente des Fahrzeugs und eine Schnittstelle, die dazu konfiguriert ist, die Daten von der Hardwarekomponente in abstrahierte Informationen umzuwandeln, wobei die Schnittstelle die abstrahierten Informationen der mindestens einen Softwarekomponente des Fahrzeugs bereitstellt. In einigen Ausführungsformen umfassen die von der neuen Hardwarekomponente generierten Daten eine Datenbankdatei (DBC-Datei). Einige Ausführungsformen schließen eine Schnittstellenbibliothek ein, in der die aktualisierte Schnittstelle gespeichert ist. Einige Ausführungsformen schließen eine Identifikation der neuen Hardwarekomponente ein, wobei die aktualisierte Schnittstelle basierend auf der Identifikation der neuen Hardwarekomponente aus der Bibliothek ausgewählt wird. In einigen Ausführungsformen werden die abstrahierten Informationen ungeachtet der von der neuen Hardwarekomponente generierten Daten von der mindestens einen Softwarekomponente des Fahrzeugs verarbeitet. In einigen Ausführungsformen wird die aktualisierte Schnittstelle zur bidirektionalen Kommunikation zwischen der mindestens einen Softwarekomponente und der neuen Hardwarekomponente verwendet. In einigen Ausführungsformen ist die aktualisierte Schnittstelle eine Modifizierung einer vorhandenen Schnittstelle.
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit nicht-transitorischen darauf codierten computerlesbaren Anweisungen ein, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, unter Verwendung der Verarbeitungsschaltlogik in dem Fahrzeug die neue Hardwarekomponente zu erkennen, unter Verwendung der Verarbeitungsschaltlogik eine Zuordnung zwischen Daten zu identifizieren, die von der neuen Hardwarekomponente und mindestens einer Softwarekomponente des Fahrzeugs generiert werden, und unter Verwendung der Verarbeitungsschaltlogik eine aktualisierte Schnittstelle zum Interpretieren der Daten von der Hardwarekomponente zu generieren, wobei die aktualisierte Schnittstelle die von der Hardwarekomponente bereitgestellten Daten in abstrahierte Informationen umwandelt, und wobei die aktualisierte Schnittstelle die abstrahierten Informationen der mindestens einen Softwarekomponente des Fahrzeugs bereitstellt. In einigen Ausführungsformen umfassen die von der neuen Hardwarekomponente generierten Daten eine Datenbankdatei (DBC-Datei). Einige Ausführungsformen schließen das Bewirken ein, dass der Prozessor die aktualisierte Schnittstelle in einer Schnittstellenbibliothek speichert, wobei das Generieren der aktualisierten Schnittstelle das Zugreifen auf die aktualisierte Schnittstelle aus der Bibliothek umfasst. In einigen Ausführungsformen wird die aktualisierte Schnittstelle basierend auf einer Identifikation der neuen Hardwarekomponente aus der Bibliothek ausgewählt. Einige Ausführungsformen schließen das Bewirken ein, dass der Prozessor durch die mindestens eine Softwarekomponente des Fahrzeugs die abstrahierten Informationen ungeachtet der von der neuen Hardwarekomponente generierten Daten verarbeitet. In einigen Ausführungsformen wird die aktualisierte Schnittstelle zur bidirektionalen Kommunikation zwischen der mindestens einen Softwarekomponente und der neuen Hardwarekomponente verwendet.
  • Eine Schlüsselkomponente von Fahrzeugmanagementsystemen schließt regelmäßige Datenübertragungen ein. Zeitweise müssen mehrere Knoten auf demselben Bus in der Lage sein, Daten zu übertragen. Ferner ist es für die Fahrzeugfunktion wichtig, dass einige dieser Übertragungen synchronisiert sind. Während einige Knoten mit grundlegender oder lockerer Synchronisation funktionieren können, erfordern andere eine sehr präzise Synchronisation. Die präzise Synchronisation beruht jedoch auf vielen Nachrichten zwischen dem Client und dem Server und das präzise Synchronisieren jedes Knotens kann das System überlasten, den Bus sättigen und die Leistung verschlechtern. Es ist eine Hybridlösung, die sowohl lockere als auch enge Synchronisation handhaben kann, erforderlich. Wie in der vorliegenden Offenbarung beschrieben, wird hierin eine Hybridlösung bereitgestellt, die den Vorteil bietet, eine enge Synchronisation bei Bedarf bereitzustellen, und eine lockere Synchronisation dann, wenn keine enge Synchronisation erforderlich ist. Wie offenbart, kann der Server des Systems seine interne Zeit kontinuierlich durchlaufen. Ein Empfangsknoten kann dann die Zeit, zu der er von dem Server eine Nachricht empfangen hat, mit der internen Zeit des Servers vergleichen und die Differenz berechnen. Der Knoten kann dann seine interne Zeit anpassen, sodass sie mit der des Servers übereinstimmt, um eine lockere Synchronisation zu erreichen. Für eine enge Synchronisation kann ein Knoten eine präzise Synchronisation anfordern und kann seinen eigenen Zeitstempel in der Anforderung einschließen. Der Server kann mit der Zeit antworten, zu der die Anforderung empfangen wurde, was eine Verzögerung zwischen dem Server und dem Client und der Zeit seiner Antwort widerspiegelt. Der Knoten kann die Verzögerung zwischen dem Serverempfang und der Serverübertragung und die Verzögerung zwischen der Knotenübertragung und dem Knotenempfang berechnen und diese Werte voneinander subtrahieren. Der Knoten kann auch den Zeitversatz berechnen, indem er einen Durchschnitt der Zeitdifferenz zwischen der Knotenuhr und der Serveruhr erstellt. Die Versatzwerte können von dem Knoten dazu verwendet werden, seine lokale Uhr zu modifizieren, um sie eng mit der Server-Uhr abzustimmen (z. B. durch Hinzufügen der Umlaufverzögerung und des Zeitversatzes zu seiner internen Uhr).
  • Zusätzlich kann in einigen Implementierungen ein Knoten eine Historie von berechneten Zeitversätzen und Umlaufverzögerungen speichern. Wenn die Historie ein stabiles Muster angibt, kann der Knoten die Frequenz reduzieren, bei der er eine enge Synchronisation anfordert oder das Senden einer Anforderung nach enger Synchronisation stoppt und sich auf historische Werte stützt, anstatt die Synchronisation durchzuführen. Vorteilhafterweise können zwei Knoten, wenn sie miteinander synchronisiert sind, eine enge Serversynchronisation unter Verwendung derselben Nachricht vom Server durchführen, da ihre Übertragungswerte gleich sein werden.
  • Einige Ausführungsformen schließen ein System zur engen Synchronisation zwischen einem ersten Client, einem zweiten Client und einem Zeitserver ein, die jeweils einer jeweiligen lokalen Uhr zugeordnet sind, wobei das System umfasst: den mit einem Bus verbundenen Zeitserver, den mit dem Bus verbundenen ersten Client, den mit dem Bus verbundenen zweiten Client, wobei der erste Client dazu konfiguriert ist, eine enge Synchronisation mit dem Zeitserver durch Übertragen einer Synchronisationsnachricht über den Bus anzufordern, wobei der Zeitserver dazu konfiguriert ist, eine periodische Synchronisationsnachricht zu generieren, die über den Bus kommuniziert wird, der Zeitserver-Client dazu konfiguriert ist, die periodische Synchronisationsnachricht basierend auf der engen Synchronisationsanforderung von dem ersten Client durch Anpassen der nächsten periodischen Synchronisationsnachricht anzupassen, sodass sie einschließt: (a) eine erste Zeit, die angibt, wann der erste Client die Synchronisationsnachricht übertragen hat, (b) eine zweite Zeit, die angibt, wann der Server die enge Synchronisationsanforderung empfangen hat, und (c) eine dritte Zeit, die angibt, wann die periodische Synchronisationsnachricht durch den Zeitserver gesendet wurde, wobei der erste Client dazu konfiguriert ist, eine enge Synchronisation basierend auf der angepassten periodischen Synchronisationsnachricht durchzuführen, und der zweite Client dazu konfiguriert ist, eine lockere Synchronisation basierend auf der angepassten periodischen Synchronisationsnachricht durchzuführen. In einigen Ausführungsformen ist der erste Client ferner dazu konfiguriert, die enge Synchronisation basierend auf dem Inhalt der angepassten periodischen Synchronisationsnachricht und auf einer Zeit des Empfangs der angepassten periodischen Synchronisationsnachricht durchzuführen. In einigen Ausführungsformen umfasst die Synchronisationsnachricht Daten, die die erste Zeit angeben. Einige Ausführungsformen schließen Speicher zum Speichern von Informationen über Verzögerungen zwischen dem Zeitserver und dem ersten Client ein. Einige Ausführungsformen schließen Schaltlogik ein, die ein Muster basierend auf den Verzögerungen bestimmt und bewirkt, dass die Synchronisation zwischen dem ersten Client und dem Zeitserver basierend auf dem Muster erfolgt.
  • Einige Ausführungsformen schließen ein Verfahren zur engen Synchronisation zwischen einem ersten Client, einem zweiten Client und einem Zeitserver ein, die jeweils mit einer jeweiligen lokalen Uhr verbunden sind und jeweils mit einem Bus verbunden sind, wobei das Verfahren umfasst: Generieren einer periodischen über den Bus kommunizierten Synchronisationsnachricht durch den Zeitserver, Empfangen, am Zeitserver über den Bus, einer Synchronisationsnachricht, die eine Anforderung nach einer engen Synchronisation von dem ersten Client umfasst, als Reaktion auf das Empfangen der Synchronisationsnachricht, Anpassen der periodischen Synchronisationsnachricht durch den Zeitserver basierend auf der engen Synchronisationsanforderung durch Anpassen der nächsten periodischen Synchronisationsanforderung, um einzuschließen: (a) eine erste Zeit, die angibt, wann der erste Client die Synchronisationsnachricht übertragen hat, (b) eine zweite Zeit, die angibt, wann der Server die enge Synchronisationsanforderung empfangen hat, und (c) eine dritte Zeit, die angibt, wann die periodische Synchronisationsnachricht durch den Zeitserver gesendet wurde, Durchführen einer engen Synchronisation durch den ersten Client basierend auf der angepassten periodischen Synchronisationsnachricht, und Durchführen einer lockeren Synchronisation durch den zweiten Client basierend auf der angepassten periodischen Synchronisationsnachricht. Einige Ausführungsformen schließen das Durchführen der engen Synchronisation basierend auf dem Inhalt der angepassten periodischen Synchronisationsnachricht und auf einer Zeit des Empfangs der angepassten periodischen Synchronisationsnachricht ein. In einigen Ausführungsformen befinden sich der erste Client, der zweite Client und der Zeitserver auf einem Fahrzeug. In einigen Ausführungsformen umfasst die Synchronisationsnachricht Daten, die die erste Zeit angeben. Einige Ausführungsformen schließen das Speichern von Informationen über Verzögerungen zwischen dem Zeitserver und dem ersten Client in einem Speicher ein.
  • Einige Ausführungsformen schließen das Bestimmen eines Musters durch eine Verarbeitungsschaltlogik basierend auf den Verzögerungen ein und bewirken, dass die Synchronisation zwischen dem ersten Client und dem Zeitserver basierend auf dem Muster erfolgt.
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit nicht-transitorischen darauf codierten computerlesbaren Anweisungen ein, die, wenn sie durch den Prozessor ausgeführt werden, den Prozessor veranlassen, durch den Zeitserver eine periodische Synchronisationsnachricht zu generieren, die über den Bus kommuniziert wird, eine Synchronisationsnachricht über den Bus am Zeitserver zu empfangen, die eine Anforderung nach einer engen Synchronisation von dem ersten Client umfasst, als Reaktion auf das Empfangen der Synchronisationsnachricht, die periodische Synchronisationsnachricht basierend auf der engen Synchronisationsanforderung durch Anpassen der nächsten periodischen Synchronisationsnachricht durch den Zeitserver anzupassen, um einzuschließen: (a) eine erste Zeit, die angibt, wann der erste Client die Synchronisationsnachricht übertragen hat, (b) eine zweite Zeit, die angibt, wann der Server die enge Synchronisationsanforderung empfangen hat, und (c) eine dritte Zeit, die angibt, wann die periodische Synchronisationsnachricht durch den Zeitserver gesendet wurde, Durchführen einer engen Synchronisation durch den ersten Client basierend auf der angepassten periodischen Synchronisationsnachricht, und Durchführen einer lockeren Synchronisation durch den zweiten Client basierend auf der angepassten periodischen Synchronisationsnachricht. Einige Ausführungsformen schließen das Bewirken ein, dass der Prozessor die enge Synchronisation basierend auf dem Inhalt der angepassten periodischen Synchronisationsnachricht und auf einer Zeit des Empfangs der angepassten periodischen Synchronisationsnachricht durchführt. In einigen Ausführungsformen befinden sich der erste Client, der zweite Client und der Zeitserver auf einem Fahrzeug. In einigen Ausführungsformen umfasst die Synchronisationsnachricht Daten, die die erste Zeit angeben. Einige Ausführungsformen schließen das Bewirken ein, dass der Prozessor Informationen über Verzögerungen zwischen dem Zeitserver und dem ersten Client in einem Speicher speichert. Einige Ausführungsformen schließen ferner das Bewirken ein, dass der Prozessor ein Muster basierend auf den Verzögerungen bestimmt und bewirkt, dass die Synchronisation zwischen dem ersten Client und dem Zeitserver basierend auf dem Muster eintritt.
  • Der Komponententest ist integraler Bestandteil eines beliebigen Softwaresystems, einschließlich dieser Betriebsfahrzeugkomponenten. In einem typischen Fahrzeugsystem kann eine Softwarefunktion einen Eingang verwenden, den sie von einer zweiten Funktion empfangen hat. Um Ergebnisse sicherzustellen, ist es vorteilhaft, die erste Funktion mit jedem möglichen Eingang von der zweiten unter Verwendung einer Pseudo-Version der zweiten Funktion zu testen, die diese Werte bereitstellt. Viele Funktionen werden jedoch in einer Programmiersprache geschrieben, in der das Bereitstellen von Pseudo-Versionen einer Funktion eine separate Funktion erfordert. Eine separate Funktion erfordert dann mühsamen Austausch im Testaufbau. Es wird eine Lösung benötigt, bei der eine Pseudo-Funktion in die Hauptfunktion integriert wird, bei Funktionen, die in Sprachen geschrieben werden, in denen eine Pseudo-Funktion getrennt ist. Gemäß der hierin vorliegenden Offenbarung wird eine Lösung bereitgestellt, die alle Funktionen separat in den Assembler-Code kompiliert, der zu einem Super-Bild zusammengesetzt wird. Während des Zusammensetzens werden Anpassungen an jedem Teilbild vorgenommen, um der Tatsache Rechnung zu tragen, dass sie sich nun in einem anderen Adressbereich befinden. Zu kompilierende Bilder werden in ein Mega-Bilderstellungsprogramm (Mega-Image Creation Program, MICP) eingespeist. Das MICP lokalisiert für jedes Bild die Position dieses Bildes im Speicher, sodass es nicht mit Speicheranforderungen anderer Bilder kollidiert. Dann passt das MICP für jedes Bild die Maschinenanweisungen an, um den neuen endgültigen Adressort widerzuspiegeln. Als Nächstes wird als Teil der endgültigen Mega-Bilderstellung eine Tabelle von Eintrittspunkten in jedes Teilbild innerhalb des Mega-Bildes erstellt, das die Kombination aus allen Teilbildern sowie dem Komponententestgerüst ist. Eine einzige Datei kann dann auf ein Laufwerk geflasht werden, das sowohl für Tests als auch für die Produktion verwendet werden kann. Auf diese Weise werden Pseudo-Funktionen unabhängig von der verwendeten Programmiersprache in einer Funktion für Tests bereitgestellt.
  • Einige Ausführungsformen können ein Verfahren zum Überladen einer Funktion einschließen, wobei das Verfahren das Kompilieren eines ersten Bildes einer ersten Version der Funktion, das Kompilieren eines zweiten Bildes einer zweiten Version der Funktion und das Generieren eines zusammengesetzten Super-Bildes durch Platzieren von Code, der die erste Version der Funktion definiert, und Code, der die zweite Version der Funktion definiert, in eine Speicherpartition umfasst, wobei der Code, der die zweite Version der Funktion definiert, dazu angepasst ist, nicht mit dem Code der ersten Version der Funktion zu kollidieren, und Generieren einer Tabelle, die verwendet wird, um selektiv entweder die erste Version der Funktion oder die zweite Version der Funktion aufzurufen. In einigen Ausführungsformen werden die erste Version der Funktion und die zweite Version der Funktion in Code geschrieben, der das Überladen von Funktionen nicht zulässt. In einigen Ausführungsformen werden die erste Version der Funktion und die zweite Version der Funktion in C-Code geschrieben. In einigen Ausführungsformen befindet sich die Speicherpartition innerhalb eines Fahrzeugs. In einigen Ausführungsformen definiert die Tabelle eine jeweilige Speicheradresse für jede der ersten Version der Funktion und der zweiten Version der Funktion. In einigen Ausführungsformen umfasst das erste Bild der ersten Version der Funktion einen ersten Assembler-Code und das zweite Bild der zweiten Version der Funktion umfasst einen zweiten Assembler-Codierer. Einige Ausführungsformen umfassen ferner das Aufrufen jeder Version der Funktion in dem zusammengesetzten Super-Bild basierend auf der Tabelle.
  • Einige Ausführungsformen schließen ein System zum Überladen einer Funktion ein, wobei das System umfassteine Speicherpartition, die Code umfasst, der eine erste Version der Funktion definiert, und Code, der eine zweite Version der Funktion definiert, wobei der Code, der die zweite Version der Funktion definiert, so angepasst ist, dass er nicht mit dem Code der ersten Version der Funktion kollidiert, eine Tabelle, die dazu konfiguriert ist, selektiv entweder die erste Version der Funktion oder die zweite Version der Funktion aufzurufen, und ein zusammengesetztes Super-Bild, das aus der Tabelle und der Speicherpartition generiert wird. In einigen Ausführungsformen werden die erste Version der Funktion und die zweite Version der Funktion in Code geschrieben, der das Überladen von Funktionen nicht zulässt. In einigen Ausführungsformen werden die erste Version der Funktion und die zweite Version der Funktion in C-Code geschrieben. In einigen Ausführungsformen befindet sich die Speicherpartition innerhalb eines Fahrzeugs. In einigen Ausführungsformen definiert die Tabelle eine jeweilige Speicheradresse für jede der ersten Version der Funktion und der zweiten Version der Funktion. In einigen Ausführungsformen umfasst das erste Bild der ersten Version der Funktion einen ersten Assembler-Code und das zweite Bild der zweiten Version der Funktion umfasst einen zweiten Assembler-Codierer. In einigen Ausführungsformen wird jede Version der Funktion in dem zusammengesetzten Super-Bild basierend auf der Tabelle aufgerufen.
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit nicht-transitorischen darauf codierten computerlesbaren Anweisungen ein, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen zum Kompilieren eines ersten Bildes einer ersten Version der Funktion, die ein zweites Bild einer zweiten Version der Funktion kompiliert, und zum Generieren eines zusammengesetzten Super-Bildes durch Platzieren von Code, der die erste Version der Funktion definiert, und Code, der die zweite Version der Funktion definiert, in eine Speicherpartition, wobei der Code, der die zweite Version der Funktion definiert, dazu angepasst ist, nicht mit dem Code der ersten Version der Funktion zu kollidieren, und zum Generieren einer Tabelle, die verwendet wird, um selektiv entweder die erste Version der Funktion oder die zweite Version der Funktion aufzurufen. In einigen Ausführungsformen werden die erste Version der Funktion und die zweite Version der Funktion in Code geschrieben, der das Überladen von Funktionen nicht zulässt. In einigen Ausführungsformen werden die erste Version der Funktion und die zweite Version der Funktion in C-Code geschrieben. In einigen Ausführungsformen ist die Speicherpartition innerhalb eines Fahrzeugs angeordnet. In einigen Ausführungsformen definiert die Tabelle eine jeweilige Speicheradresse für jede der ersten Version der Funktion und der zweiten Version der Funktion. In einigen Ausführungsformen umfasst das erste Bild der ersten Version der Funktion einen ersten Assembler-Code und das zweite Bild der zweiten Version der Funktion umfasst einen zweiten Assembler-Codierer. Einige Ausführungsformen umfassen ferner, zu bewirken, dass der Prozessor jede Version der Funktion in dem zusammengesetzten Super-Bild basierend auf der Tabelle aufruft.
  • Figurenliste
  • Die vorstehenden und andere Aufgaben und Vorteile der vorliegenden Offenbarung werden unter Berücksichtigung der folgenden detaillierten Beschreibung in Verbindung mit den beigefügten Zeichnungen deutlich, in denen sich gleiche Bezugszeichen durchgehend auf gleiche Teile beziehen und in denen:
    • 1 ein Blockdiagramm von Komponenten eines Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 2 ein Blockdiagramm für ein Syste zum Betreiben eines Fahrzeugs (z. B. von 1) gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 3 eine beispielhafte Architektur des Fahrzeugs von 1 gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 4a ein beispielhaftes Auftreten einer Präemption zeigt, die ein Synchronisationsproblem gemäß einigen Ausführungsformen der vorliegenden Offenbarung verursacht,
    • 4b ein beispielhaftes Datenflussdiagramm von generierten Softwareagenten gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 5 beispielhafte Softwareagenten zeigt, die von dem Build-System der Code-Autogenerierungssoftware gemäß einigen Ausführungsformen der vorliegenden Offenbarung erstellt werden,
    • 6 eine alternative Version von beispielhaften Softwareagenten zeigt, die von dem Build-System der Code-Autogenerierungssoftware gemäß einigen Ausführungsformen der vorliegenden Offenbarung generiert werden,
    • 7 Details einer beispielhaften Implementierung der Signalempfangsprüfung zeigt, die in
    • 5 gemäß einigen Ausführungsformen der vorliegenden Offenbarung beschrieben ist,
    • 8 Details einer beispielhaften Implementierung des in 5 beschriebenen Übertragungsprozesses gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 8a ein Flussdiagramm von veranschaulichenden Schritten für ein Verfahren zum Synchronisieren von Daten gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 9 ein beispielhaftes Schlüsselaustauschszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 10 ein verbessertes Schlüsselbereitstellungsprotokoll basierend auf symmetrischen Schlüsseln gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 11 eine Zustandsmaschine für einen Knoten in einem Verschlüsselungsalgorithmus gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 12 eine Zustandsmaschine für einen Schlüsselserver in einem
    • Verschlüsselungsalgorithmus gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 12a ein Flussdiagramm veranschaulichender Schritte für ein Verfahren zum Herstellen sicherer Kommunikationen zwischen einem ersten Knoten und einem zweiten Knoten innerhalb eines Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 13 ein beispielhaftes System zum Verbessern der Ausfallerkennung in Schaltlogiken oder Komponenten eines Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 13a ein Flussdiagramm von veranschaulichenden Schritten für ein Verfahren zum Vorhersagen eines Fehlerereignisses in einem Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 14 ein beispielhaftes System zum Ermöglichen der Absturzwiederherstellung gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 14a ein Flussdiagramm veranschaulichender Schritte für ein Verfahren zum Speichern von Informationen über ein Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 15 ein beispielhaftes System zum Management von Versionen von Datenbankdateien für eine Mikrosteuerung zeigt, wie eine Mikrosteuerung von Fahrzeugen, die in einer der 1-3 gemäß einigen Ausführungsformen der vorliegenden Offenbarung dargestellt sind,
    • 15a ein Flussdiagramm von veranschaulichenden Schritten für ein Verfahren zum Aktualisieren eines Fahrzeugs zeigt, wenn eine neue Hardwarekomponente installiert wird, gemäß einigen Ausführungsformen der vorliegenden Offenbarung,
    • 16 ein beispielhaftes System zum Management der Zeitsynchronisation verschiedener Module zeigt, die über einen einzigen Bus verbunden sind, gemäß einigen Ausführungsformen der vorliegenden Offenbarung,
    • 17 eine Interaktion zwischen einem Knoten, der eine enge Synchronisation benötigt, und dem Server gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 18 eine beispielhafte Interaktion zeigt, die eine Umlaufverzögerung gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 18a ein Flussdiagramm veranschaulichender Schritte für ein Verfahren zur engen Synchronisation zwischen einem ersten Client, einem zweiten Client und einem Zeitserver gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 19 beispielhaften Code für eine Zweite Einheit zeigt, die dazu verwendet wird, eine Erste Einheit zu testen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung,
    • 20 beispielhaften Code für eine Erste Einheit zeigt, die dazu verwendet wird, getestet zu werden, gemäß einigen Ausführungsformen der vorliegenden Offenbarung,
    • 21 ein beispielhaftes Ergebnis der Erstellung eines Super-Bildes des Codes von 19 und 20 gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt,
    • 21a ein Flussdiagramm von veranschaulichenden Schritten für ein Verfahren zum Überladen einer Funktion gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Fahrzeugübersicht
  • Gemäß der vorliegenden Offenbarung werden Systeme und Verfahren bereitgestellt, die den Betrieb eines Fahrzeugs (oder mehrerer Fahrzeuge) durch verschiedene Verbesserungen der Konfiguration von Hardware und/oder Software des Fahrzeugs, mehrerer Fahrzeuge und/oder eines oder mehrerer Server verbessern, die dazu konfiguriert sind, mit einem Fahrzeug oder Fahrzeugen zu kommunizieren.
  • 1 zeigt ein Blockdiagramm von Komponenten eines Fahrzeugs 100 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. In einigen Ausführungsformen kann das Fahrzeug 100 eine Vielfalt von geeigneten Systemen umfassen, die zum Steuern und Betreiben eines Fahrzeugs verwendet werden. Zum Beispiel kann das Fahrzeug 100 (einen) Motor oder Motorsysteme, Batteriesysteme, Systeme für autonomes Fahren, ein oder mehrere Lenksysteme, Pumpenbremssystem, Belüftungssystem und andere geeignete Systeme oder eine beliebige Kombination davon einschließen. In einigen Ausführungsformen kann das Fahrzeug eine oder mehrere elektronische Steuereinheiten (ECUs) oder Schaltlogiken (z. B. Mikrosteuerungen) zum Steuern einiger oder aller der vorstehend genannten Systeme umfassen. In einigen Ausführungsformen kann das Fahrzeug interne Verbindungen oder Vernetzungskomponenten einschließen, die zum Verknüpfen der Systeme des Fahrzeugs erforderlich sind.
  • In einigen Ausführungsformen kann das Fahrzeug einen Prozessor 105 oder Prozessoren (z. B. einen Zentralprozessor und/oder -prozessoren, die ihren Subsystemen fest zugeordnet sind) einschließen. Ein Prozessor kann eine Hardware-CPU zum Ausführen von Befehlen, die im Speicher 103 oder in Softwaremodulen 112, 113 gespeichert sind, oder eine Kombination davon umfassen. In einigen Ausführungsformen kann das Fahrzeug 100 eine oder mehrere Einheiten von transitorischem Speicher und/oder eine oder mehrere Einheiten von nicht-transitorischem Speicher einschließen. In einigen Ausführungsformen kann der Speicher 103 ein Teil der Schaltlogiken des Fahrzeugs sein. In einigen Ausführungsformen kann der Speicher 103 Hardwareelemente zum nicht-transitorischen Speichern von Befehlen oder Anweisungen einschließen, die, wenn sie durch den Prozessor 105 ausgeführt werden, den Prozessor 105 veranlassen, das Fahrzeug 100 gemäß den vorstehend und nachstehend beschriebenen Ausführungsformen zu betreiben.
  • In einigen Ausführungsformen kann ein Prozessor 105 kommunikativ mit Sensoren 106, 107, einer Vernetzungskomponente und Benutzerschnittstellenkomponente oder -komponenten verbunden sein. Die Sensoren 106, 107 können Videosensoren, Audiosensoren, Gassensoren, Drucksensoren, GPS-Sensoren, Funkantennen, Videokameras, Mikrofone, Drucksensoren, Gewichtssensoren, Gassensoren, für Fahrzeugfunktionen spezifische Sensoren, andere Sensoren oder eine beliebige Kombination davon einschließen.
  • In einigen Ausführungsformen kann der Prozessor 105 Daten von den Sensoren 106, 107 dazu verwenden, das Fahrzeug 100 zu betreiben und/oder andere Funktionen durchzuführen. In einigen Ausführungsformen kann der Prozessor 105 einen Benutzereingang über eine Benutzerschnittstelle 102 empfangen. In einigen Ausführungsformen kann die Benutzerschnittstelle 102 einen Bildschirm einschließen. In einigen Ausführungsformen kann der Prozessor 105 mit einer Benutzervorrichtung und anderen Datenquellen über ein Netzwerk kommunizieren, auf das über eine Vernetzungskomponente 104 zugegriffen werden kann.
  • In einigen Ausführungsformen kann das Fahrzeug 100 eine Vielzahl von Softwaremodulen (z. B. Softwaremodule 1-N) 112, 113 einschließen. In einigen Ausführungsformen kann jedes der Softwaremodule 1-N 112, 113 durch den Prozessor 105 gesteuert werden. In einigen Ausführungsformen kann das Fahrzeug 100 eine Vielzahl von Hardwaremodulen (z. B. Hardwaremodule 1-N) 114, 115 einschließen. In einigen Ausführungsformen kann jedes der Hardwaremodule 1-N 114, 115 durch den Prozessor 105 gesteuert oder durch ihren eigenen Prozessor betrieben werden. In einigen Ausführungsformen kann das Fahrzeug 100 Schaltlogiken und Software einschließen, die spezifisch für Funktionen von Vorgängen des Fahrzeugs 100 sind. Zum Beispiel kann das Fahrzeug 100 eines oder mehrere von elektrischen Steuermodulen (Electric Control Module, ECM) oder elektrischen Steuereinheiten (Electric Control Units, ECU) 111 zum Steuern eines oder mehrerer Motoren des Fahrzeugs 100 einschließen. Jedes ECM 111 kann Zugriff auf verschiedene Sensoren haben, z. B. MAP: Saugrohr-Absolutdruck (Manifold Absolute Pressure), IAT: Ansauglufttemperatur (Intake Air Temperature), MAF: Luftmasse (Mass Air Flow), CKP: Kurbelwellenposition (Crank Shaft Position), CMP: Nockenwellenposition Cam Shaft Position), ECT: Motorkühlmitteltemperatur (Engine Coolant Temperature), 02: Sauerstoffsensor (Oxygen Sensor), TP: Drosselposition (Throttle Position), VSS: Fahrzeuggeschwindigkeitssensor (Vehicle Speed Sensor), Klopfsensor (Knock Sensor), APP: Fahrpedalposition (Acceleration Pedal Position), Kühlmittelsensor, beliebige andere geeignete oder beliebige Kombinationen davon. Das Fahrzeug 100 kann ein Getriebesteuermodul (Transmission Control Module, TCM) 108 für Getriebe oder Kraftübertragungen des Fahrzeugs, Fahrzeugdynamikmodul (Vehicle Dynamics Module, VDM) 109 und zentrales Gateway-Modul (Central Gateway Modul, CGM) 110 einschließen. Das Fahrzeug kann auch beliebige andere geeignete Hardware- oder Softwaresysteme einschließen.
  • Übersicht über Vernetzung
  • 2 zeigt ein Blockdiagramm eines Systems zum Betreiben eines Fahrzeugs (z. B. von 1) gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System kann mehrere Fahrzeuge einschließen, einschließlich Fahrzeug 210 (z. B. das Fahrzeug von 1) und andere Fahrzeuge 220 und 230, und Server 250.
  • In einigen Ausführungsformen kann das System das Netzwerk 240 einschließen, das die Fahrzeuge 210, 220, 230 und den Server 250 kommunikativ miteinander verbindet. In einigen Ausführungsformen kann das Netzwerk 240 das Internet, Intranet, Bluetooth-Netzwerk, LAN, WAN, ein Wi-Fi-Netzwerk, ein beliebiges anderes leitungsgebundenes oder drahtloses Netzwerk oder eine beliebige Kombination davon sein.
  • In einigen Ausführungsformen kann jedes Fahrzeug 210-230 eine Verarbeitungsschaltlogik zum Ausführen von Funktionalitäten der Fahrzeuge umfassen, wie in verschiedenen Ausführungsformen dieser Offenbarung beschrieben. In einigen Ausführungsformen kann jedes der Fahrzeuge 210-230 einen transitorischen und nicht-transitorischen Speicher zum Speichern von Daten und Anweisungen, die für den Betrieb des Fahrzeugs erforderlich sind, umfassen. In einigen Ausführungsformen kann jedes der Fahrzeuge 210-230 eine Kommunikationsschaltlogik zum Kommunizieren mit dem Server 250 über das Netzwerk 240 umfassen. In einigen Ausführungsformen kann die Verarbeitungsschaltlogik jedes der Fahrzeuge 210-230 in der Lage sein, Daten von Sensoren oder Hardware- oder Softwaremodulen (z. B. wie in 1 gezeigt) zu sammeln. Die Fahrzeuge 210-230 können Verbraucherfahrzeuge sein oder in einigen Ausführungsformen eine Flotte von Nutzfahrzeugen darstellen.
  • In einigen Ausführungsformen kann der Server 250 einen einzigen Server umfassen. In einigen Ausführungsformen kann der Server 250 eine Vielzahl von Servern umfassen, die in einer oder mehreren Einrichtungen verteilt sind. In einigen Ausführungsformen kann der Server 250 Informationen von den Fahrzeugen 210-230 (z. B. Informationen, die von Sensoren der Fahrzeuge 210-230 generiert werden) über das Netzwerk 240 sammeln. In einigen Ausführungsformen kann der Server 250 Informationen an Fahrzeuge 210-230 über das Netzwerk 240 gemäß den vorstehend und nachstehend beschriebenen Ausführungsformen senden.
  • Übersicht über die Kernarchitektur
  • 3 zeigt eine beispielhafte Architektur des Fahrzeugs von 1 (z. B. eines der Prozessorkerne des Fahrzeugs, zum Beispiel eines Kerns des ECM). Zum Beispiel kann die in 3 gezeigte Architektur unter Verwendung der in 1 gezeigten Prozessoren und des dort gezeigten Speichers implementiert werden. Obwohl die Implementierung eines einzigen Kerns gezeigt ist, kann das Fahrzeug eine beliebige Anzahl von Kernen einschließen, die durch Busse oder Vernetzungselemente verbunden sind.
  • In einigen Ausführungsformen kann die Architektur unter Verwendung einer Mikrosteuerung 301 implementiert werden. Die Mikrosteuerung 301 kann Zugriff auf ein Hardware-Abstraktionsmodul 307, einen Betriebssystem-Kernel 302 (mit Intercore-Mischfunktionalitäten) und Selbsttestbibliotheken 303 aufweisen. Weitere Sicherheits- und Schutzmodule können End-2-End-Schutzmodule (E2E-Schutzmodule) 304, Überwachungsmodule 305 und das Redundanzmodul 306 einschließen. Einige oder alle Module können gemeinsame Speicher nutzen. Der Kern kann auch einen Abschnitt ausführen, der zum Durchführen von Intervallaufgaben fest zugeordnet ist.
  • In einigen Ausführungsformen schließt die Architektur eine Steuerungs-Abstraktionsschicht 308 ein, die auf das Controller Area Network (CAN) 309, die serielle Peripheriegeräteschnittstelle (Serial Peripheral Interface, SPI) 310, die inter-integrierte Schaltung (Inter-Integrated Circuit, 12C) 311, einen universellen asynchronen Empfänger/Sender (Universal Asynchronous Receiver-Transmitter, UART) 312, ein lokales Zusammenschaltungsnetz (Local Interconnect Network, LIN) 313 und Digital Inout/Output-Busse (DIO-Busse) 314 Zugriff hat. Die Mikrosteuerung 301 kann auch Chipsatztreiber 315, einen Bootloader 316, Controller Area Network First-in-First-Out-Warteschlangen (FIFO-Warteschlangen) 317 und eine Ethernet-Komponente 318 einschließen. Es kann auch ein weiteres Vernetzungsmodul eingeschlossen sein (z.B. einschließlich eines Gateways 319 für FreeRTOS-Kommunikationen 320, Uniform Data System-Kommunikationen (UDS-Kommunikationen) 321, Universal Measurement and Calibration Protocol-Kommunikationen (XCP-Kommunikationen) 322, Diagnostics Over Internet Protocol-Kommunikationen (DoIp-Kommunikationen) 323, ISO-Transportschicht-Kommunikationen (ISOTP-Kommunikationen) 324, VX1000-Kommunikationen 325 und dergleichen). Die Mikrosteuerung 301 kann auch ECU Peripherietreiber 326, ein Hardware-Abstraktionsmodul 307 und einen Diagnosereignis-Manager 327 einschließen. Der Kernel 302 kann dann verwendet werden, um einen im Speicher gespeicherten Anwendungscode auszuführen. In einigen Ausführungsformen kann die Architektur eines Kerns jedes andere geeignete Hardware- oder Softwaremodul einschließen.
  • Der Kern ermöglicht dem Fahrzeug den Zugriff auf verschiedene Funktionen und Fähigkeiten, einschließlich Kommunikation, Synchronisation und Datenerfassung. Zum Beispiel kann das Fahrzeug Informationen, wie Diagnose- oder Fehlercodes, zwischen externen Testausrüstungen und Automobilsteuereinheiten (ECU) (unter Verwendung des ECU-Peripherietreibers 326) über DoIP 323 kommunizieren. Dies ermöglicht es einem Fahrzeugsystem beispielsweise, Diagnoseinformationen zu verfolgen und zu analysieren, um die Ausfallerkennung zu verbessern. Der Kern kann auch Dateien von externen Systemen wie Cloud-Server über den Controller Area Network-Bus (CAN-Bus) oder das Unified Diagnostic Services-Protokoll (UDS-Protokoll) empfangen und an diese senden. Diese Dateien können beispielsweise von Peripherievorrichtungen (z. B. Signalen von einem Pumpenbremsmodul, von einem Motormodul wie ECM oder einem anderen Kern oder Peripheriegerät oder Sensor eines Fahrzeugs) oder an andere Module, deren eigenen Anwendungen oder anderen Kernen stammen. Diese Kommunikation ermöglicht Funktionen, die Daten von verschiedenen Teilen eines Fahrzeugs (d. h. Bremsen, die mit einer Anzeigeeinheit kommunizieren, oder Speichern eines Daten-Schnappschusses nach einem ECU-Ausfall) oder von verschiedenen Systemen (d. h. Berichtsdaten an einen externen Server) einschließen.
  • In einigen Ausführungsformen kann ein System (z. B. ein Kern, wie in 3 gezeigt) eines Fahrzeugs (z. B. wie in 1 dargestellt) in der Lage sein, Nachrichten und Signale von externen Modulen (z. B. von Sensoren, anderen Modulen des Fahrzeugs wie TCM oder VDM) zu empfangen. Die DBC-Dateien können verwendet werden, um zu definieren, wie Module miteinander kommunizieren (z. B. ein Pumpenbremsmodul, ein Motormodul wie ECM oder ein anderer Kern, ein anderes Peripheriegerät oder ein anderer Sensor eines Fahrzeugs). Es kann auch erforderlich sein, dass das System (z. B. Kern 300, wie in 3 gezeigt) eines Fahrzeugs Daten (z. B. Daten an andere Module, an seine eigenen Anwendungen oder an andere Kerne anderer Systeme) überträgt.
  • In einem Ansatz schließt das System individuell programmierte Schnittstellen zum Empfangen und Interpretieren von Daten und/oder Anwendungen zum Übertragen der Daten ein. In einigen Ausführungsformen kann das System in Echtzeit-Betriebssystemen (RTOS) ausgeführt werden. Bei RTOSs haben Aufgaben Prioritäten und dürfen sich gegenseitig zuvorkommen. Aufgrund der Präemption kann eine Aufgabe ihre Ausführung zurückstellen, wenn eine andere Aufgabe mit höherer Priorität ausgeführt wird. Die Präemption kann zu einem Ausfall der Datenkohärenz führen.
  • 4A zeigt ein beispielhaftes Auftreten einer Präemption, die ein Synchronisationsproblem verursacht. Zum Beispiel können sowohl Task0_5ms als auch Task0_100ms bei t=0ms auf einem System (z. B. einem Kern) geplant werden. Da Task0_5ms eine höhere Priorität hat, kann sie zuerst ausgeführt werden, und beginnt somit mit der Ausführung zur Zeit t = 0ms. Wenn Task0_5ms (z. B. bei t = 2ms) endet, wird Task0_100ms Ausführungszeit auf dem Kern (z. B. bei t = 2ms) eingeräumt, aber Task0_100ms verfügt möglicherweise nicht über genug Zeit, bis ein zweiter Anruf für Task0_5ms erneut ausgeführt werden muss (bei t = 5ms). Das Betriebssystem des Systems wird Task0_100ms zugunsten der höherrangigen Aufgabe Task0_5ms „vorwegnehmen“ und die zweite Instanz der Aufgabe Task0_5ms bis zum Abschluss (z. B. bis t = 7ms) ausführen, bevor es umschaltet, um die Aufgabe Task0_100ms (z. B. t = 7ms) zu beenden. Diese Präemption kann problematischerweise nicht gewährleisten, dass die Kommunikation zwischen Task0_5ms und Task0_100ms synchronisiert wird.
  • Zum Beispiel kann Task0_5ms für das End-2-End-(E2E) Prüfen und Entpacken von Signaldaten (z. B. Daten, die über einen CAN-Bus empfangen werden) verantwortlich sein. In diesem Beispiel muss Task0_100ms möglicherweise empfangen: (a) Signaldaten und (b) das E2E-Ergebnis der Überprüfung für dieses Signal (das durch die Task0_5ms bereitgestellt würde). Zum Beispiel kann Task0_100ms eine Funktion aufrufen, um die Signaldaten während des 2ms-5ms-Teils ihrer Ausführung zu erhalten, und dann eine andere Funktion anzurufen, um den E2E-Status während des 7ms-8ms Teils ihrer Ausführung zu erhalten. Da jedoch eine zweite Instanz von Task0_5ms zwischen dem Zeitraum 5ms-7ms ausgeführt wurde, entspricht der von Task0_100ms in dem Zeitraum 7ms-8ms empfangene E2E-Status nicht den Signaldaten, die von Task0_100ms in dem Zeitraum 2ms-5ms empfangen wurden. Dieses Problem verschärft sich, wenn Task0_100ms auf einem anderen Kern als Task0_5ms ausgeführt wurde. Die Diskrepanz bei den Daten kann zu Desynchronisation und anderen Programmierungsproblemen bei der Ausführung von Task0_100ms führen, was zusätzliche Zyklen erfordern kann, um Abhilfe zu schaffen, oder sogar zu einem Systemabsturz führen kann.
  • Frühere Lösungen dieses Problems würden die E2E-Berechnungen in derselben Partition ausführen, von der aus der Anwendungscode, der die Daten erfordert, ausgeführt wird. Dies stellt die Synchronisation der E2E und der Nachrichtendaten mit dem Code bereit, da alle Informationen in demselben Kontext verlaufen, diese Lösungen jedoch Nachteile aufweisen. Zum einen müssen Nachrichtendaten zwischen dem Kontext des Kommunikationsstapels und dem vorstehend genannten Kontext synchronisiert werden. Dies würde in der Regel dadurch gehandhabt werden, dass das Betriebssystem oder eine Warteschlange einbezogen wird, die weniger portabel und ressourcenintensiv ist. Wenn weiterhin in anderen Partitionen Code ausgeführt wird, sind redundante Berechnungen erforderlich. Diese Lösungen erfordern auch, dass der Code im Gleichschritt mit eingehenden Daten abläuft.
  • Dementsprechend wird eine Lösung bereitgestellt, um eine Synchronisation zwischen Aufgaben sicherzustellen, zum Beispiel wird ein Verfahren bereitgestellt, um sicherzustellen, dass E2E-Daten mit Signalverarbeitungs- und -sendedaten synchronisiert werden. Insbesondere wird ein benutzerdefiniertes Werkzeug (z. B. ein Satz von Programmierskripten) bereitgestellt, das einen Satz von Softwareagenten (z. B. in der Programmiersprache C) automatisch generiert, die es zulassen, dass ein System (z. B. einschließlich eines oder mehrerer Kerne) Verarbeitung, Übertragung und Empfang von Nachrichten trennt, um eine bessere Synchronisation zu erreichen. Insbesondere können E2E-Berechnungen für einen Empfang eines Signals innerhalb einer einzigen Aufgabe stattfinden, während die Software-Architektur eines Kerns und der Anwendung (die das Signal und den E2E-Status empfangen oder senden würden) die erforderlichen Aktionen durchführen, um sicherzustellen, dass Informationen bei Bedarf mit Synchronizität empfangen werden. Dies ermöglicht das Speichern von CPU-Zyklen auf einem Kern (z. B. Kern 300, der in 3 gezeigt ist.)
  • 4B zeigt ein beispielhaftes Datenflussdiagramm der generierten Softwareagenten. In einigen Ausführungsformen gibt es Tausende von Signalen, die jede Anwendung in einem Fahrzeug (z. B. wie in 1-3 gezeigt) empfangen und senden muss. Darüber hinaus gibt es Nachrichten, die durch zahlreiche Netzwerke zu verschiedenen Endpunkten in einem System des Fahrzeugs geleitet werden müssen. Einige Nachrichten müssen validiert werden (z. B. unter Verwendung eines E2E-Status). Von Menschen generierter Code für die Handhabung des Empfangs von Nachrichten und für die E2E-Validierung ist fehleranfällig und kann Fehler in das System einführen. Dementsprechend generiert das System hier Code automatisch basierend auf DBC-Daten, wobei der resultierende Code es kundenspezifischen Softwareagenten ermöglicht, eine Signal- und E2E-Statussynchronisation bereitzustellen. Zum Beispiel kann Code für die folgenden Aufgaben automatisch generiert werden: Gatewaying von Nachrichten zwischen Netzwerken, Entpacken/Packen von Signalen zwischen Rohbytes und Konstruktionswerten, Handhabung des End-to-End-Schutzes für Nachrichten-/Signalintegrität, Handhabung von Nachrichtenplanung, Variantenmanagement von Kommunikationsnetzen, Einstellen von kommunikationsbezogenen Diagnosefehlercodes (DTCs, Diagnostic Rausch Codes), Aktivieren/Deaktivieren der Kommunikation durch Netzwerk/Nachricht und beliebige andere geeignete kommunikationsbezogene Aufgaben.
  • In einigen Implementierungen wird ein vorausgewähltes textbasiertes Deskriptordateiformat (z. B. speziell formatierte DBC-Dateien oder andere serialisierte Formate) dazu verwendet, das Netzwerk des Fahrzeugs durch mehrere Dateifragmente pro Bus zu beschreiben. Beispielsweise kann das Deskriptordateiformat einen bestimmten Stil von Kommentaren oder verkürzten Abschnitten erfordern, die die benötigten Informationen bereitstellen, aber nicht ausgeführt werden würden. In einer anderen Implementierung kann ein Deskriptordateiformat erfordern, dass Daten in einer bestimmten Reihenfolge und mit bestimmten Markierungen (z. B. mit vordefinierten Variablennamen) bereitgestellt werden. DBC-Dateien oder ein anderes geeignetes vorausgewähltes Deskriptor-Datenformat können von der Code-Autogenerierungssoftware unter Verwendung von Details des Deskriptor-Datenformats verwendet werden. Die Code-Autogenerierungssoftware kann Segmente oder Fragmente dieser Deskriptordateien verwenden, um den Quellcode zu generieren. Auf diese Weise kann ein Signal oder eine Nachricht mit der Sicherheit übertragen werden, dass der Code kompiliert wird und dass die Kerne und Anwendungen in der Lage sind, auf diese Nachricht bzw. den Signalwert des Signals über eine spezifizierte Anwendungs-Programmierungsschnittstelle (Application Programming Interface, API) zuzugreifen, ohne dass weitere Arbeit oder Integration erforderlich ist. Die Code-Autogenerierungssoftware kann auch das Variantenmanagement handhaben (z. B. wie später in Verbindung mit 15 beschrieben). In einigen Ausführungsformen kann die Code-Autogenerierungssoftware einen Rahmen zum Bereitstellen von automatisierter Nachrichtenredundanz einschließen (z. B. durch Umschalten einer Quelle der Nachricht in einer ad hoc-Weise, wenn mehrere Nachrichtenquellen zum Auswählen vorhanden sind). In einigen Ausführungsformen kann die Code-Autogenerierungssoftware ein Schema für ein neues Datenformat zum Ersetzen von DBC-Dateien einschließen.
  • Die Ausgabe der Code-Autogenerierungssoftware kann ein Satz von Programmierdateien sein, die auf einer oberen Schicht des Anwendungsstapels eines Kerns (z. B. eines Kerns der ECU) und/oder mit einer Anwendung ausgeführt werden sollen. Die generierten Programmierdateien, die eine oder mehrere Programmiersprachen (z. B. C, C++, Javascript usw.) umfassen, können für Verarbeitungsdaten verantwortlich sein (z. B. durch Generieren von Dateien, die tatsächliche Nutzwerte einschließen), zum Durchführen einer E2E-Verifizierung für die Signaldaten und zum Senden der Signaldaten an andere Kerne oder Anwendungen. E2E-Prüfmodule können dazu konfiguriert sein, eine einzige Nachricht angesichts eines durchlaufenden Zustands früherer Nachrichten zu validieren. E2E-Bibliotheken können mittels der Spezifikation Automotive Open System-Architektur (AUTOSAR-Architektur) geschrieben werden. Eine E2E-Überprüfung kann einen der Werte „Fehler“, „OK“, „wiederholt“, „keine neuen Daten“ oder „falsche Sequenz“ bereitstellen, die zum Validieren der Signalnachricht benötigt werden.
  • In einigen Beispielen kann das Build-System der Code-Autogenerierungssoftware Source DBC-Dateien (z. B. in Fragmentform einschließlich gemeinsamer Teile und Varianten) empfangen. Das Build-System kann dann einen Netzwerk-Framer-Aggregator verwenden, um eine Variantenbehandlung durchzuführen und eine DBC-Deserialisierung durchzuführen. Das Build-System kann ein vordefiniertes Netzwerkobjekt (das z. B. das Netzwerk durch mehrere Austauschfragmente pro Bus beschreibt) und zum Generieren von Laufzeitumgebungsobjekten (z. B. Softwareagenten, die nachstehend ausführlicher in 5-8 beschrieben sind) bereitgestellte Vorlagen verwenden. Das Build-System kann auch aggregierte DBC-Dateien erstellen.
  • Die resultierenden Softwareagenten können Speicherschutz und sichere Ausführungsumgebung bereitstellen. Zum Beispiel müssen alle von einer Peripherievorrichtung empfangenen Daten in einer sicheren Umgebung ausgeführt werden. Zusätzlich muss der Speicherschutz aktiv sein, um den Speicher zu schützen, der für die Ausführung von Schlüsselaufgaben benötigt wird (z. B. darf jeder nicht qualifizierte Prozess nicht auf geschützte Speicher zugreifen können). Zu diesem Zweck kann der Speicher (z. B. wie in 1 gezeigt) in mehrere Abschnitte unterteilt werden (z. B. wie durch die Norm ISO 26262 definiert): QM-Speicherabschnitt, der eine nicht geschützte nicht qualifizierte Speicherebene sein kann und verschiedene Ebenen von ASIL-Abschnitten (z. B. ASIL A-D), in denen jede ASIL-Speicherebene stärker geschützt ist. Die Code-Autogenerierungssoftware generiert Code, der in 5-8 weiter erläutert wird.
  • 5 zeigt beispielhafte Softwareagenten, die von dem Build-System der Code-Autogenerierungssoftware erstellt werden, die, wenn sie zusammen ausgeführt werden, automatisch E2E-Schutzbehandlung für ein empfangenes Signal bereitstellen.
  • Insbesondere werden Aufgaben im oberen Rechteck durch Kern 1 (z. B. auf der oberen Schicht des Anwendungsstapels von Kern 1) ausgeführt. Während Aufgaben auf der niedrigeren Ebene durch eine Anwendungsaufgabe auf höherer Ebene ausgeführt werden, die auf dem Signal beruht. Wie vorstehend in 4A erläutert, muss die Anwendungsaufgabe mit der E2E-Schutzaufgabe synchronisiert werden (um zu vermeiden, dass die Anwendung den E2E-Status empfängt, was einer falschen Nachricht entspricht). Zu diesem Zweck wird, wenn eine Nachricht empfangen wird (z. B. von Kern 0), die Nachricht von der E2E-Aufgabe 502 auf Kern 1 gelesen (z. B. unter Verwendung von E2E-Bibliotheken 503). Die E2E-Aufgabe 502 auf Kern 1 schreibt dann sowohl das Signal als auch den E2E-Status des Signals in einer Form, die von der Anwendung verwendet werden kann. Der E2E-Status kann dann von Software gelesen werden, die die Ebene ASIL B 504 oder ASIL D 505 des Speicherschutzes verwendet, während auf das Signal selbst von Software zugegriffen werden kann, die die Schutzebene ASIL B 504, ASIL D 505 oder QM 506 verwendet. Vorteilhafterweise erfolgt die gesamte kernübergreifende Kommunikation für jede E2E-Nachricht (z. B. als E2E-Überprüfung) an Kern 1, was Unterstützung für eine höhere Speicherschutzebene (z. B. bei der Ebene ASIL D) zulässt. Da die E2E-Berechnung vollständig innerhalb einer Aufgabe erfolgt, führt die Anwendung auch erforderliche Aktionen durch, um sicherzustellen, dass die empfangenen Informationen bei Bedarf synchronisiert werden.
  • 6 zeigt eine weitere Version beispielhafter Softwareagenten, die durch das Build-System der Code-Autogenerierungssoftware erstellt werden, die, wenn sie zusammen ausgeführt werden, automatisch E2E-Schutzbehandlung für ein empfangenes Signal bereitstellen. Im Gegensatz zur Implementierung von 5 werden die E2E-Überprüfungen von der Anwendung gehandhabt. Zum Beispiel kann die E2E-Berechnung im gleichen Kontext wie der Code, der die Berechnung verbraucht, durchgeführt werden, erfordert aber, dass die Aufgabe mit der gleichen Rate wie die Nachricht läuft.
  • Insbesondere werden Aufgaben 601 in der oberen Ebene 607 durch Kern 1 (z. B. auf der oberen Schicht des Anwendungsstapels von Kern 1) ausgeführt. Während Aufgaben auf der niedrigeren Ebene 608 durch eine Anwendung auf höherer Ebene ausgeführt werden, die auf dem Signal beruht. Hierzu wird, wenn eine Nachricht empfangen wird (z. B. von Kern 0), die Nachricht durch Kern 1 gelesen, der eine Nachricht zur Verwendung durch die Anwendung schreibt. In dieser Implementierung kann die Software, die die Ebene oder Schutz ASIL B 602, ASIL D 603 oder QM 604 nutzt, durchweg auf die Nachricht zugreifen. Dann kann Software, die ASIL B 602 nutzt, und Software, die ASIL D 603 nutzt, sowohl auf E2E-Bibliotheken 605 zugreifen als auch die E2E-Nachricht generieren (z. B. als E2E-Überprüfung). In solchen Ausführungsformen können die Anwendungen die E2E-Überprüfung während jedes Nachrichtenzyklus durchführen.
  • 7 zeigt Details einer beispielhaften Implementierung der in 5 beschriebenen Signalempfangsprüfung. Gepunktete Felder geben den Code an, der vom Build-System der Code-Autogenerierungssoftware erstellt wurde. Wie gezeigt, können sich die verschiedenen Codeagenten in den Partitionen ASIL B 701, ASIL D 702 und QM 703 befinden und können zusammen ausgeführt werden, um eine Synchronisation zwischen der Anwendungsaufgabe und der Kommunikationsaufgabe zu gewährleisten (was den in 4A beschriebenen Aufgaben entsprechen kann). In diesem Fall empfängt Code in der QM-Partition, die die Kommunikationsaufgabe ausführt, über den FIFO 704-Puffer eine Nachricht und schreibt das Signal oder die Nachricht in einem Format, auf das durch Code in den Partitionen ASIL B 701, ASIL D 702 und QM 703 zugegriffen werden kann. Der Code in der Partition ASIL B 701 kann die Nachrichten- und Schreibsignaldaten und den E2E-Zustand entpacken. Auf diese beiden Werte kann dann durch eine Anwendung synchronisiert zugegriffen werden. Der Code in der Partition ASIL D 702 kann in ähnlicher Weise die Nachrichten- und Schreibsignaldaten und den E2E-Zustand entpacken. Auf diese beiden Werte kann dann durch eine Anwendung synchronisiert zugegriffen werden. Darüber hinaus kann Code in ASIL D 702 Sicherheitsaufgaben durchführen. Der Code in der Partition QM 703 kann der Anwendung nur Signaldaten und nicht E2E-Daten zur Verfügung stellen.
  • 8 zeigt Details einer beispielhaften Implementierung des in 5 beschriebenen Übertragungsverfahrens. Gepunktete Felder geben den Code an, der vom Build-System der Code-Autogenerierungssoftware erstellt wurde. Wie gezeigt, können sich die verschiedenen Codeagenten in den Partitionen ASIL B 801, ASIL D 802 und QM 803 befinden und können zusammen ausgeführt werden, um eine Synchronisation zwischen der Anwendungsaufgabe und der Kommunikationsaufgabe zu gewährleisten (was den in 4A beschriebenen Aufgaben entsprechen kann). In diesem Fall empfängt Code in der Partition QM 803, die die Kommunikationsaufgabe ausführt, eine Nachricht an den FIFO-Puffer 804 basierend auf Signalen, die von Code in den Partitionen ASIL B 801, ASIL D 802 und QM 803 bereitgestellt werden. Der Code in der Partition ASIL B 801 kann die Nachricht durch Kombinieren von Signaldaten und den E2E-Zustand verpacken. Der Code in der Partition ASIL B 801 kann die Nachricht auch durch Kombinieren von Signaldaten und den E2E-Zustand verpacken. Darüber hinaus kann Code in ASIL D 802 Sicherheitsaufgaben durchführen. Der Code in der QM-Partition kann der Kommunikationsaufgabe nur Signaldaten (und nicht den E2E-Status) zur Verfügung stellen.
  • Einige Ausführungsformen schließen ein Verfahren wie in 8a ein, das das Zugreifen auf eine Datei umfasst, die Informationen zum Decodieren von Busdaten in Schritt 810 umfasst, Generieren, basierend auf der Datei, einer Vielzahl von Softwareagenten, wobei die Softwareagenten, wenn sie ausgeführt werden, dazu konfiguriert sind, eine Rohnachricht über den Bus zu empfangen, wobei die Rohnachricht einen Signalwert generieren soll, in Schritt 820 einen Sicherheitsschutzwert für die Rohnachricht generieren soll, und wenn in Schritt 830 eine Anforderung nach dem Signalwert von einer Instanz einer Anwendung, die basierend auf Anweisungen an einem geschützten Speicherort ausgeführt wird, empfangen wird, dann in Schritt 840 Bereitstellen eines synchronen Zugriffs auf den Signalwert und den Sicherheitsschutzwert. Wenn in Schritt 830 keine Anforderung empfangen wird, fährt das Verfahren mit Schritt 850 fort und es findet keine Aktion statt. In einigen Ausführungsformen umfasst das Generieren der Vielzahl von Softwareagenten einen ersten Satz von Anweisungen zum Ausführen aus einer ersten nicht sicheren Speicherpartition, wobei der erste Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, eine Rohnachricht von dem Bus zu empfangen, Generieren eines zweiten Satzes von Anweisungen zur Ausführung aus einer geschützten Speicherpartition, wobei der zweite Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, die Rohnachricht zu entpacken, um den Signalwert zu generieren, Durchführen einer Verifizierung, um den Sicherheitsschutzwert für die Rohnachricht zu generieren, Speichern des Signalwerts und des Sicherheitsschutzwerts zu speichern und synchrones Übertragen des Signalwerts und des Sicherheitsschutzwerts auf die Instanz einer Anwendung, einen dritten Satz von Anweisungen zur Ausführung aus einer zweiten nicht sicheren Speicherpartition, wobei der dritte Satz von Anweisungen, wenn er ausgeführt wird, dazu konfiguriert ist, die Rohnachricht zu entpacken, um einen Signalwert zu generieren, den Signalwert auf die Instanz einer Anwendung zu übertragen. In einigen Ausführungsformen ist der Bus ein Controller Area Network-Bus (CAN-Bus). In einigen Ausführungsformen ist die erste nicht sichere Speicherpartition eine Qualitätsmanagement-Partition (QM-Partition). In einigen Ausführungsformen ist die geschützte Speicherpartition eine Automotive Safety Integrity Level-Partition (ASIL-Partition). In einigen Ausführungsformen umfasst das Generieren des Sicherheitsschutzwerts das Generieren eines End-to-End-Status (E2E-Status).
  • In einigen Ausführungsformen müssen verschiedene Hardware- oder Softwaremodule möglicherweise (einen) kryptografische(n) Schlüssel (z. B. einen flüchtigen Schlüssel) austauschen, um zwischen ihnen gesendete Nachrichten zu verschlüsseln. Zum Beispiel kann es erforderlich sein, dass TCM, VDM und CGM eines Fahrzeugs (wiez. B. in 1-3 gezeigt) einen sicheren Kommunikationskanal zwischen jedem Paar von Modulen herstellen. Die gleichen Techniken können jedoch zwischen beliebigen Software- oder Hardwaremodulen verwendet werden, die Schlüssel austauschen müssen.
  • In einem Ansatz kann jedes Modul oder jeder Knoten ein eigenes Paar aus privatem Schlüssel/öffentlichen Schlüssel für eine sichere Kombination aufweisen. Dies kann jedoch sehr aufwändig sein, insbesondere wenn Zertifikate benötigt werden, um Schlüsselquellen zu verifizieren. Um diesen Mangel zu beheben, werden beispielhafte Verfahren für einen verbesserten Schlüsselbereitstellungsvorgang bereitgestellt.
  • 9 zeigt ein beispielhaftes Schlüsselaustauschszenario nach dem Stand der Technik. In diesem Beispiel erstellen 4 Knoten paarweise symmetrische Kommunikationsschlüssel (z. B. DEC-Schlüssel, obwohl jeder andere geeignete Schlüssel verwendet werden kann). Wie erwähnt, erfordert die paarweise Schlüsselgenerierung typischerweise 6-maligen Schlüsselaustausch, was aufwändig ist. Bei 20 Knoten würden zum Beispiel 190 Schlüsselpaare benötigt. Um die Probleme dieser früheren Ansätze zu beheben, wird ein Schema bereitgestellt, um flüchtige symmetrische Schlüssel zwischen Knoten zu generieren, basierend auf der Nutzung eines vorab freigegebenen Schlüssels zwischen einem Knoten und einem Server. Die Techniken werden für zwei beliebige Knoten und einen Server beschrieben. In einigen Beispielen kann das CGM als Server fungieren und TCM, VDM können Knoten sein. Es können jedoch jeder andere geeignete Server und beliebige andere geeignete Knoten verwendet werden. In einigen Ausführungsformen kann der Prozess für andere Knoten wiederholt werden, die den bereitgestellten Schlüssel gemeinsam nutzen müssen.
  • 10 stellt ein verbessertes Schlüsselbereitstellungsprotokoll basierend auf symmetrischen Schlüsseln dar, das zur Bereitstellung neuer symmetrischer Schlüssel zur Laufzeit (oder jeder anderen Zeit) zwischen mehreren Knoten verwendet werden kann. Die Lösung lässt eine sichere Bereitstellung neuer symmetrischer Schlüssel unter Verwendung nur von früheren symmetrischen Schlüsseln zu. Die Technik ist sicher gegen Abhör- und Mensch-in-der-Mitte-Angriffe. Zur Umsetzung der Lösung kann ein Knoten im Netzwerk als SchlüsselServer und der Rest als Schlüssel-Clients bezeichnet werden. Als ersten Schritt weist jeder Client einen symmetrischen Schlüssel auf, der dauerhaft zwischen ihm und dem Server bereitgestellt wird. Dadurch wird der Bedarf an permanenten Schlüsseln minimiert. Beispielsweise werden bei 20 Knoten nur 20 Schlüssel anstelle von 190 Schlüsselpaaren benötigt. Die vorab freigegebenen Schlüssel lassen die Kommunikation eines Knotens mit dem Serverknoten zu und können auch genutzt werden, um flüchtige Schlüssel zur Nutzung für die Verschlüsselung von Kommunikationen zwischen Knoten zu erstellen.
  • Wie in 10 gezeigt, möchte der Client 1 einen sicheren Kanal mit dem Client 2 erstellen, indem er einen flüchtigen symmetrischen Schlüssel gemeinsam nutzt. Der Client 1 fordert einen symmetrischen Schlüssel vom Schlüsselserver 1001 (z. B. einen neu erstellten flüchtigen Schlüssel) an. In einigen Ausführungsformen schließt die Anforderung die Adresse des Zielknotens für die Kanalerstellung (z. B. IP-Adresse vom Client 2) und eine Zufallszahl (z. B. 16-Bit-Zahl) ein, die vom Client 1 generiert wird. Die Zufallszahl kann als Sicherheitsfrage für den Server verwendet werden. Zum Beispiel kann erwartet werden, dass der Server eine Antwort basierend auf dieser Zahl neu überträgt, wenn er mit dem Schlüssel antwortet, um den Client 1 zu helfen, den Server durch Untersuchen der empfangenen Sicherheitsantwort zu überprüfen. Diese Nachricht kann ohne Verschlüsselung gesendet werden, oder sie kann unter Verwendung eines vorab freigegebenen Schlüssels für den Client 1/den Server verschlüsselt werden. Bevor ein bestimmter vorgegebener Zeitraum abgelaufen ist, kann der Server dem Client 1 mit einer Nachricht antworten, die den neu bereitgestellten Schlüssel und eine Antwort auf die Sicherheitsfrage 1002 einschließt. Der neu bereitgestellte Schlüssel kann unter Verwendung einer beliebigen geeigneten Schlüsselerstellungstechnik erstellt werden (z. B. wie in der in Norm IEEE 1363-2000 definiert). Die Antwort auf die Sicherheitsfrage kann ein Hash (z. B. Cipher-based Message Authentication Code Hash) der vom Client 1 gesendeten Zufallszahl sein. Die Nachricht kann auch aufgefüllt werden, um die Größe des Verschlüsselungsblocks einzuhalten. Die gesamte Nachricht kann unter Verwendung eines für das Paar Client 1/Server (z. B. unter Verwendung von Chiffrierung) vorab freigegebenen Schlüssels verschlüsselt werden. In einigen Ausführungsformen kann die vom Client 1 generierte Zufallszahl als Initialisierungsvektor für den Verschlüsselungsalgorithmus verwendet werden.
  • Der Client 1 kann dann den Hash überprüfen, bevor er fortfährt. Nach der Hash-Überprüfung kann der Client 1 eine Nachricht an den Client 2 senden, um den Client 2 zu benachrichtigen, dass der Client 1 die sichere Kommunikation mit dem Client 2 1003 initiieren möchte. Dies kann eine unverschlüsselte (z. B. User Datagram Protocol-Nachricht (UDP-Nachricht)) sein. Die Nachrichten können den Client 2 informieren (z. B. über ein Bitfeld), ob der Kanal Verschlüsselung, Authentifizierung oder beides erfordert. Der Client 2 erfährt jetzt, dass der Server bereits einen flüchtigen Schlüssel für diese Transaktion generiert hat. Der Client 2 kann jetzt eine Nachricht an den Server senden, um eine Kopie des neu bereitgestellten flüchtigen Schlüssels für sich anzufordern 1004.
  • Der Client 2 kann jetzt eine Anforderung nach dem flüchtigen Schlüssel an den Server senden 1004. Die Anforderung kann die Adresse des gewünschten Knotens (z. B. IP-Adresse vom Client 1) und eine vom Client 2 generierte Zufallszahl (z. B. eine 16-Bit-Zahl) einschließen. Diese Nachricht kann ohne Verschlüsselung gesendet werden, oder sie kann unter Verwendung eines vorab freigegebenen Schlüssels für den Client 2/den Server verschlüsselt werden.
  • Der Server kann verifizieren, dass der Client 1 tatsächlich einen Kanal mit dem Client 2 angefordert hat, bevor er auf den Client 2 reagiert. Die Antwortnachricht an den Client 2 1005 kann einschließen: (a) eine Antwort auf die Zufallszahl-Sicherheitsfrage (z. B. einen Hash der vom Client 2 generierten Zufallszahl) und (b) denselben Schlüssel, der auf Anforderung des Clients 1 hin bereitgestellt wurde. Die Nachricht kann auch aufgefüllt werden, um die Größe des Verschlüsselungsblocks einzuhalten. Die gesamte Nachricht kann unter Verwendung eines Schlüssels verschlüsselt werden, der für das Paar Client 2/Server vorab freigegeben wurde (z. B. unter Verwendung von Chiffirerung). In einigen Ausführungsformen kann die vom Client 2 generierte Zufallszahl als Initialisierungsvektor für den Verschlüsselungsalgorithmus verwendet werden.
  • Der Client 2 kann den Antwort-Hash überprüfen, bevor er fortfährt 1006. Danach, da der Client 1 und der Client 2 im Besitz desselben Schlüssels sind, können sie diesen Schlüssel für eine sichere Kommunikation nutzen (z. B. zum Signieren oder Verschlüsseln von Nachrichten unter einander). In einigen Ausführungsformen kann die Kommunikation über normale UDP- oder Transmission Control Protocol-Nachrichten (TCP-Nachrichten) oder andere geeignete Nachrichten durchgeführt werden.
  • 11 zeigt eine Zustandsmaschine 1100 für einen Knoten in diesem Algorithmus. Zum Beispiel kann der Knoten aus dem „Ruhezustand“ 1101 eine Schlüsselanforderung 1102 (z. B. an das TCM) senden und abwarten, um den Versuch eine vorgegebene Anzahl von Malen zu wiederholen. Wenn im Initiatormodus eine Schlüsselantwort 1103 empfangen wird (und wenn die Authentifizierung nicht fehlschlägt), kann der Knoten die Gegenstelle nach einer sicheren Verbindung 1104 abfragen. Wenn die Antwort der Gegenstelle empfangen wird, kehrt der Zustand in den „Ruhezustand“ 1101 zurück und die Kommunikation mit der Gegenstelle kann beginnen. Im Empfangsmodus antwortet der Knoten zurück an die Gegenstelle, um anzuzeigen, dass dieselbe Kombination 1105 zulässig ist.
  • 12 zeigt eine Zustandsmaschine für einen Schlüsselserver in diesem Algorithmus. Aus dem „Ruhezustand“ 1201 kann der Server eine Initiierungsanforderung 1202 empfangen. Als Reaktion darauf sendet der Server eine Antwort 1203 oder führt einen Timeout 1204 durch und kehrt in den „Ruhezustand“ 1201 zurück.
  • Einige Ausführungsformen schließen ein Verfahren zum Herstellen sicherer Kommunikationen zwischen einem ersten Knoten und einem zweiten Knoten innerhalb eines Fahrzeugs wie in 12a ein, wobei das Verfahren die folgenden Schritte umfasst Empfangen, von dem ersten Knoten des Fahrzeugs, einer ersten Nachricht, die Informationen umfasst, die den zweiten Knoten des Fahrzeugs 1210 identifizieren, als Reaktion auf das Empfangen der ersten Nachricht, Generieren, unter Verwendung der Verarbeitungsschaltlogik des Fahrzeugs, eines Verschlüsselungsschlüssels 1220, Kommunizieren, an den ersten Knoten des Fahrzeugs, von Informationen, die den Verschlüsselungsschlüssel 1230 identifizieren, Empfangen, von dem zweiten Knoten des Fahrzeugs 1240, einer zweiten Nachricht, die Informationen umfasst, die den ersten Knoten des Fahrzeugs identifizieren, Bestimmen, unter Verwendung der Verarbeitungsschaltlogik, dass die zweite Nachricht gültig ist, basierend auf der ersten Nachricht 1250, und Kommunizieren, an den zweiten Knoten des Fahrzeugs, von Informationen, die den Verschlüsselungsschlüssel 1260 identifizieren. In einigen Ausführungsformen umfasst die erste Nachricht ferner eine Zufallszahl, die durch den ersten Knoten des Fahrzeugs generiert wird. Einige Ausführungsformen schließen das Kommunizieren eines Hash der Zufallszahl an den ersten Knoten des Fahrzeugs ein. In einigen Ausführungsformen umfasst die zweite Nachricht ferner eine Zufallszahl, die durch den zweiten Knoten generiert wird. Einige Ausführungsformen schließen das Kommunizieren eines Hash der Zufallszahl an den ersten Knoten des Fahrzeugs ein. In einigen Ausführungsformen befinden sich der erste Knoten des Fahrzeugs und der zweite Knoten des Fahrzeugs auf einem gemeinsam genutzten Bus im Fahrzeug. In einigen Ausführungsformen erfolgen das Kommunizieren mit dem ersten Knoten des Fahrzeugs und das Kommunizieren mit dem zweiten Knoten des Fahrzeugs über den gemeinsam genutzten Bus.
  • 13 stellt ein beispielhaftes System zum Verbessern der Ausfallerkennung in Schaltlogiken oder Komponenten eines Fahrzeugs (z. B. eines in 1 dargestellten Fahrzeugs) dar. Zum Beispiel kann die Ausfallerkennung durch einen Server 1300 (z. B. wie in 2 dargestellt) durchgeführt werden. In einigen Ausführungsformen kann der Server Zugriff auf Metriken von mehreren Fahrzeugen 1301, 1302, 1303, 1304 innerhalb einer kommerziellen Flottenumgebung haben, oder die Fahrzeuge 1301, 1302, 1303, 1304 können einen Satz von Verbraucherfahrzeugen in Kommunikation mit einem Server darstellen, der einem Hersteller der Fahrzeuge zugeordnet ist. Zum Beispiel kann der Server in konstanter oder periodischer Kommunikation mit jedem Fahrzeug in der Flotte unter Verwendung von Vernetzungsschaltlogiken des Servers und der Flotte (z. B. über das Mobilfunknetz oder eine andere geeignete Art eines Netzwerks) stehen. Der Server kann Daten 1305 von allen Schaltlogiken der Fahrzeuge in der Flotte sammeln. In einem Beispiel kann der Server ECU-Metrikdaten für alle Fahrzeuge in der Flotte sammeln.
  • Nachdem der Server ECU-Metriken aus einem Satz von Fahrzeugen sammelt, kann der Server die Metrikdaten in seiner Datenbank speichern. Der Server kann die Metriken im Vergleich zu Schwellenwerten analysieren und bestimmen, wie oft ein bestimmtes Problem (z. B. ein Fehler) innerhalb der gesamten Flotte auftritt und wie dieser Fehler mit den Metriken korreliert. Durch die Verfolgung dieser Informationen kann der Server in der Lage sein, eine frühzeitige Ausfallerkennung in einem Fahrzeug bereitzustellen. In einigen Ausführungsformen kann der Server eine frühzeitige Warnung 1306 an das Fahrzeug übertragen, die eine Fehler angibt und auf Reparatur oder eine andere geeignete Aktion drängt.
  • Zum Beispiel kann der Server Sensordaten für jede ECU jedes Fahrzeugs sammeln, um Motorlast, Batteriezustand oder -Ladung, Kühlmitteltemperatur, Motortemperatur, Motordrehzahl, Luftströmung, beliebige andere geeignete Metriken oder eine beliebige Kombination davon aufzuzeichnen. Weitere komplexe ECU-Metriken können aktuelle und durchschnittliche Prozessorlast, eventuelle Prozessorfehler, Nutzung von RAM und nichtflüchtigem Speicher (durchschnittlich und aktuell), ECU-Kerntemperatur (aktuell und durchschnittlich), Netzwerklast (durchschnittlich und aktuell), Einschaltzeithistorie, eine beliebige andere geeignete Prozessormetrik oder eine beliebige Kombination davon einschließen. Der Server kann auch Zustandsinformationen für jedes Element des Motors sammeln, z. B. können Alter und Leistung für jeden Teil des Motors gesammelt werden. Der Server kann auch Softwareabsturz- oder Störungsberichte von jedem Fahrzeug in der Fahrzeugflotte empfangen. Der Server kann das Auftreten der Abstürze mit dem Zustand und der Historie von Metriken der Fahrzeuge zur Zeit des Absturzes oder vor dem Absturz korrelieren. Die Korrelation kann stärker werden, wenn mehr Absturz- oder Störungsberichte von anderen Fahrzeugen empfangen werden. Zum Beispiel kann das Alter oder die schlechte Leistung eines bestimmten Motorteils mit einer bevorstehenden Funktionsstörung korreliert werden. In einigen Ausführungsformen kann ein Fahrzeug Informationen an den Server melden, um sowohl für die Entdeckung von Korrelationen analysiert zu werden als auch Fehlerwarnungen von Korrelationen als solchen zu empfangen. Das heißt, ein Fahrzeug kann sowohl zu dem Wissen des Systems beitragen, als auch von dem System selbst zu profitieren. Wenn sich der Server der Korrelation sicher ist (z. B. dass die Korrelation einen bestimmten Schwellenwert überschreitet), kann der Server Warnungen über bevorstehende Fehler an ein Fahrzeug übertragen, das ein Teil in einem Zustand aufweist, der mit dem Fehler korreliert. In einigen Ausführungsformen können Warnungen basierend auf der Korrelation einer beliebigen Metrik oder einer Kombination von Metriken mit einem bestimmten Fehler gesendet werden. Die Warnungen können eine Benachrichtigung darüber einschließen, welcher Teil des Fahrzeugs gewartet oder ausgetauscht werden muss. Der Server kann in ähnlicher Weise Daten für jedes andere Modul des Fahrzeugs sammeln und generieren.
  • In einigen Ausführungsformen kann der Server ein Maschinenlernmodell verwenden (z. B. ein neuronales Netz), um Fehler vorherzusagen. In solchen Ausführungsformen trainiert der Server das Maschinenlernmodell mit Metrikzuständen, die dafür bekannt sind, einen Fehler zu verursachen. Nach dem Trainieren kann das Maschinenlernmodell als Eingang aktuelle Metriken eines Fahrzeugs akzeptieren (z. B. ECU-Metriken) und ausgeben, ob ein bevorstehender Fehler wahrscheinlich ist oder nicht. Wenn der Fehler wahrscheinlich ist, kann der Server eine entsprechende Benachrichtigung an das Fahrzeug senden. In einigen Ausführungsformen wird das Modell wiederholt aktualisiert, wenn der Server neue Daten sammelt. In einigen Ausführungsformen befindet sich das Modell auf dem entfernten Server.
  • In einigen Ausführungsformen kann die Benachrichtigung an das Fahrzeug den erwarteten Fehler angeben. In einigen Ausführungsformen kann die Benachrichtigung einen Bereich angeben, in dem wahrscheinlich der erwartete Fehler auftritt. Dieser Bereich kann in Meilen, Stunden oder einer anderen relevanten Einheit vorliegen. Zum Beispiel kann der Server das Fahrzeug warnen, dass es wahrscheinlich, basierend auf einem erkannten Zustand einer Batterie oder eines Motorteils, in 20 Meilen überhitzt sein wird. In einem anderen Beispiel kann der Server das Fahrzeug warnen, dass ein Scheinwerfer wahrscheinlich, basierend auf einem identifizierten Zustand einer Lampe oder einer anderen dem Fahrzeug zugeordneten Schaltlogik in 12 Stunden ausfällt. In einigen Ausführungsformen kann die Benachrichtigung die Korrelation beschreiben. Beispielsweise kann sie feststellen, dass das Fahrzeug 65.000 Meilen gefahren ist, was darauf hinweist, dass es wahrscheinlich ist, dass der Motor gewartet werden muss.
  • In einigen Ausführungsformen kann die Benachrichtigung eine prozentuale Wahrscheinlichkeit einschließen, dass ein Fehler auftritt. Zum Beispiel kann der Server warnen, dass eine Wahrscheinlichkeit von 40 % besteht, dass die Batterie des Fahrzeugs ausfällt. In einigen Ausführungsformen kann die Benachrichtigung Angaben des Schweregrads wie Farbänderungen oder Animation auf einer Fahrzeuganzeige einschließen, die für den Fahrer sichtbar ist, oder die Angaben können an ein mobiles Gerät (z. B. das Mobiltelefon mit einer mobilen Anwendung, die dem darauf installierten Server zugeordnet ist) gesandt werden, das dem Benutzer zugeordnet ist. Beispielsweise kann ein dringendes Risiko in Rot und blinkend erscheinen, während ein geringeres Risiko in Gelb erscheinen kann. Der Schweregrad kann zum Beispiel basierend auf der Wahrscheinlichkeit und potenziellen Gefahr oder Unannehmlichkeit bewertet werden. In einigen Ausführungsformen kann der Server eine Änderung eines Betriebsparameters eines Fahrzeugs veranlassen, um den Fehler zu vermeiden oder abzumildern. Eine solche Änderung kann an dem Fahrzeug drahtlos durch einen entfernten Server unter Verwendung einer Software oder eines anderen Update durchgeführt werden.
  • In einigen Ausführungsformen kann der Server Daten von anderen Quellen als den Fahrzeugen empfangen. Zum Beispiel kann der Server unter anderem mit Systemen kommunizieren, die Daten über Wetter, Verkehrsmuster, den geografischen Ort des Fahrzeugs, Höhe über dem Meeresspiegel, Route und das Fahrerprofil bereitstellen. Der Server kann dann diese zusätzlichen Daten in die Analyse der Korrelation eines Fehlers integrieren. Zum Beispiel kann der Server feststellen, dass ein gewisser Fehler, wie die Batterieleistung, eine Korrelation mit Außentemperatur zeigt. Der Server kann dann nach Empfang von Wettervorhersagen für die bevorstehenden Stunden ein Fahrzeug warnen, dass wahrscheinlich ein Fehler auftritt. Zum Beispiel kann der Server in dem Fall, dass die Batterieleistung mit der Temperatur korreliert, lernen, dass die Temperatur wahrscheinlich unter einen Schwellenwert fällt, an dem die Temperatur die Batterieleistung beeinträchtigt. Der Server kann dann das Fahrzeug vor der bevorstehenden Änderung oder einer bevorstehenden potenziellen Leistungsbeeinträchtigung warnen. Alternativ kann der Server beispielsweise feststellen, dass eine andere Funktionsstörung bei häufigem Anhalten gewöhnlich auftritt und kann Informationen über bevorstehenden Verkehr empfangen. Der Server kann lernen, dass vorausfahrender Verkehr wahrscheinlich zu häufigem Anhalten führt. In diesem Fall kann der Server das Fahrzeug auf ähnliche Weise warnen, dass wahrscheinlich ein Ausfall auftritt. In einem anderen Beispiel kann der Server feststellen, dass Fahrzeuge an einem bestimmten geografischen Ort eine höhere Korrelation zu einem spezifischen Fehler aufweisen, und nur Fahrzeuge an diesem Ort vor dem spezifischen Fehler warnen. In einigen Ausführungsformen kann der Server eine Aktion vorschlagen. Zum Beispiel kann der Server in dem Szenario, in dem Verkehrsmuster das Ausfallrisiko erhöhen können, mit dem System kommunizieren, dass eine alternative Route empfohlen wird.
  • Einige Ausführungsformen schließen ein Verfahren zum Vorhersagen eines Fehlerereignisses in einem Fahrzeug wie in 13a ein, wobei das Verfahren das Überwachen, unter Verwendung einer Verarbeitungsschaltlogik, einer Vielzahl von Betriebsparametern eines Fahrzeugs und eines geografischen Orts des Fahrzeugs in Schritt 1310 umfasst. Nach dem Bestimmen, unter Verwendung der Verarbeitungsschaltlogik, dass Werte der Betriebsparameter und der geografischen Ort wahrscheinlich mit einem Fehlerereignis in Schritt 1320 korrelieren, wobei die Korrelation auf einem Modell basiert, das unter Verwendung jeweiliger Werte der Betriebsparameter für einen Satz von Fahrzeugen und jeweiligen geografischen Orten des Satzes von Fahrzeugen trainiert wird, die entsprechende Fehlerereignisse erfahren, Bewirken, dass unter Verwendung der Verarbeitungsschaltlogik als Reaktion auf das Bestimmen in Schritt 1330 eine Aktion durchgeführt wird. Wenn keine Korrelation erkannt wird, fährt das Verfahren fort mit Schritt 1340 und es findet keine Aktion statt. Einige Ausführungsformen schließen auch das Übertragen der Betriebsparameter und des geografischen Orts des Fahrzeugs auf einen entfernten Server ein, wobei das Bestimmen, dass die Werte der Betriebsparameter und des geografischen Orts wahrscheinlich mit dem Fehlerereignis korrelieren, das Empfangen von Informationen, die die Korrelation angeben, von dem entfernten Server umfasst. In einigen Ausführungsformen befindet sich das Modell auf dem entfernten Server. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, dass eine Benachrichtigung bereitgestellt wird, die das Fehlerereignis angibt. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, eine Änderung mindestens eines der Vielzahl von Betriebsparametern, um zu vermeiden, dass das Fehlerereignis auftritt. In einigen Ausführungsformen umfasst das Bewirken, dass die Aktion durchgeführt wird, das Bewirken, dass die Aktion an einem entfernten Server durchgeführt wird, wobei die Aktion innerhalb des Fahrzeugs durchgeführt wird. In einigen Ausführungsformen wird das Modell wiederholt basierend auf neuen Daten aktualisiert, die von dem Satz von Fahrzeugen bereitgestellt werden.
  • 14 stellt ein beispielhaftes System zum Ermöglichen der Wiederherstellung nach einem Absturz (z. B. eines Absturzes der ECU) durch ein System eines Fahrzeugs (z. B. wie in 1 gezeigt) dar. Zum Beispiel können die Systeme eine Situation handhaben, wenn eine ECU blockiert und nicht reagiert; infolgedessen kann das System verhindern, dass Daten verloren gehen, nachdem die nicht wiederherstellbare Trap oder ein anderes Modul einen ganzen Kern zurücksetzt (z. B. wie in 3 gezeigt). In diesen Situationen vermeidet das System einen harten Leistungszyklus, erleidet aber einen „sanften“ oder „warmen“ Absturz. Infolgedessen können flüchtige Speicherinhalte erhalten bleiben.
  • Wie in 14 gezeigt, kann das beispielhafte System des Fahrzeugs einen Kern mit einem Prozessor 1401, einem regulären Direktzugriffsspeicher (RAM) 1402 (in 14 als „Hauptspeicher“ bezeichnet) und einem fest zugeordneten Standby-RAM-Speicher 1403 (in 14 als „Standby-Speicher“ bezeichnet) einschließen. In einigen Ausführungsformen kann der Standby-RAM-Speicher ein Teil des regulären RAM-Speichers sein. In einigen Ausführungsformen kann der Standby-RAM-Speicher eine fest zugeordnete Schaltlogik sein. Das Betriebssystem (OS) des Fahrzeugs kann Anweisungen einschließen, die für einen Ausfall auf niedriger Ebene (z. B. einen ECU-Ausfall auf niedriger Ebene), einen fehlerhaften Code oder einen Speicherschutzfehler oder ein Watchdog-Trigger-Ereignis fest zugeordnet sind. Der Prozessor kann einen Schnappschuss von Systeminformationen aufnehmen und im Standby-RAM-Speicher speichern. Zu diesem Zweck kann das System einen Abschnitt des RAM in einer Linker-Struktur reservieren, die nicht zwischen den Neustarts gelöscht wird.
  • In einigen Ausführungsformen kann der Prozessor die Daten schützen, indem nach dem Absturz Cyclic Redundancy Check-Codes (CRC-Codes) 1404 für Blöcke des Schnappschusses berechnet werden, der nach dem Aufprall aufgenommen und in dem Standby-RAM 1403 gespeichert wurde. Auf diese Weise kann nach einem Neustart eine CRC-Überprüfung 1404 durchgeführt werden, um zu überprüfen, ob die Daten gültig sind. Die Daten können dann über den Controller Area Network-Bus (CAN-Bus) oder das Unified Diagnostic Services-Protokoll (UDS-Protokoll) gemeldet werden. Das System kann auch ein „frisches“ Flag im Standby-Speicher setzen, um das Vorhandensein neuer Daten anzugeben. Die Absturzdaten im Standby-RAM können später in einen nichtflüchtigen Speicher und/oder auf ein externes System (z. B. einen anderen Kern oder eine Mikrosteuerung) kopiert werden.
  • In einigen Ausführungsformen kann der nichtflüchtige Speicher (Non-Volatile Memory, NVM) verwendet werden, um einen Schnappschuss zu speichern. Auf diese Weise wird der Puffer mit Absturzinformationen nicht bei einem nachfolgenden Neustart gelöscht, sondern in den nichtflüchtigen Speicher kopiert. Zum Beispiel kann der Kern einen Notfallstapel zum Durchführen zusätzlicher Funktionen in einem blockierten Zustand einschließen. Während eines Absturzes kann das System einen Zeiger auf den Notfallstapel setzen und neue Funktionen aufrufen, um einen Schnappschuss aufzunehmen. In einigen Ausführungsformen kann ein Stapelüberlauf im Watchdog-Modul zu einem nicht maskierbaren Interrupt-Handler umgeleitet werden.
  • In einigen Ausführungsformen kann der Schnappschuss eine Stapel-Trace einschließen. Zum Beispiel kann ein System beispielsweise auf eine vorab zugewiesene Liste von Ganzzahlen ohne Vorzeichen mit einer Tiefe von 20 zugreifen, wobei jede eine Adresse für eine Rücksprunganweisung speichert. In einigen Ausführungsformen kann der Schnappschuss einen Software-GitHash einschließen. In einigen Ausführungsformen kann der Schnappschuss eine Trap-Kennung einschließen. In einigen Ausführungsformen kann der Schnappschuss einen Watchdog-Status einschließen. In einigen Ausführungsformen kann der Schnappschuss einen Freilaufsystem-Zeitgeberwert einschließen. In einigen Ausführungsformen kann der Schnappschuss beliebige Daten von Interesse (Stapelzeiger, Statusregister, Zeitstempel usw.) einschließen.
  • In einigen Ausführungsformen kann der Absturzdaten-Schnappschuss durch den Heartbeat Frame auf den CAN-Bus ausgegeben werden, wenn der Bootloader startet. Der Bootloader kann dann normal arbeiten. In einigen Ausführungsformen kann der Daten-Dump durch einen an den Bus (z. B. an den CAN-Bus) angeschlossenen Datenlogger aufgezeichnet werden.
  • In einigen Ausführungsformen kann der Schnappschuss eine gepackte Binärdatei sein, die über einen Dienst wie Unified Diagnostical Services-Protokoll (UDS-Protokoll) unter Verwendung eines UDS-Clients erhalten werden kann. Die Binärdatei kann eine Header-Datei mit definierten Funktionen einschließen. Ein Python-Werkzeug kann dann verwendet werden, um die Daten in ein menschen- oder systemlesbares Format zu entpacken. In einigen Ausführungsformen kann das System Schnappschüsse während des normalen Betriebs (z. B. periodisch oder basierend auf einer System- oder Benutzeranforderung) aufnehmen, um hinzugefügte Verwaltungswerkzeuge bereitzustellen. In einigen Ausführungsformen können die Schnappschuss-Daten von einer gesamten Flotte gesammelt und dazu verwendet werden, einen Ausfall in anderen Fahrzeugen vorherzusagen, wie z. B. in 13 beschrieben.
  • Einige Ausführungsformen schließen ein Verfahren zum Speichern von Informationen über ein Fahrzeug ein, wie in 14A, wobei das Verfahren umfasst: Erkennen eines Fehlerereignisses 1410 durch die Verarbeitungsschaltlogik und als Reaktion auf das Erkennen, Generieren, durch die Verarbeitungsschaltlogik, der Informationen über das Fahrzeug zu einer Zeit des Fehlerereignisses 1420, Generieren, durch die Verarbeitungsschaltlogik, von Integritätsdaten basierend auf den Informationen 1430, Bewirken, dass durch die Verarbeitungsschaltlogik die Informationen über das Fahrzeug und die Integritätsdaten in einem Abschnitt des flüchtigen Speichers gespeichert werden, wobei der Abschnitt des flüchtigen Speichers dazu konfiguriert ist, gespeicherte Daten während eines Neustarts eines Betriebssystems des Fahrzeugs 1440 zu erhalten, Bewirken, unter Verwendung der Verarbeitungsschaltlogik, dass das Betriebssystem des Fahrzeugs neu gestartet 1450 wird, nach dem Neustart, Validieren, unter Verwendung der Verarbeitungsschaltlogik, der in dem flüchtigen Speicher gespeicherten Informationen basierend auf den Integritätsdaten 1460, und als Reaktion auf das Validieren, Bewirken, dass die Informationen über das Fahrzeug im nichtflüchtigen Speicher 1480 gespeichert werden. In einigen Ausführungsformen umfassen die Integritätsdaten eine zyklische Redundanzprüfung (Cyclic Redundancy Check, CRC). In einigen Ausführungsformen umfasst der flüchtige Speicher einen Direktzugriffsspeicher (Random Access Memory, RAM). In einigen Ausführungsformen ist der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers, der für die Informationen und die Integritätsdaten reserviert ist. In einigen Ausführungsformen umfasst das Erkennen des Fehlerereignisses das Erkennen eines Systemabsturzes. In einigen Ausführungsformen umfassen die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug. In einigen Ausführungsformen wird das Generieren der Informationen, Generieren der Integritätsdaten und Bewirken, dass die Informationen und die Integritätsdaten gespeichert werden, durch einen Notfall-Stapel durchgeführt, der dazu programmiert ist, im Falle des Fehlerereignisses ausgeführt zu werden.
  • Einige Ausführungsformen schließen ein System zum Speichern von Informationen über ein Fahrzeug ein, wobei das System umfasst: ein Betriebssystem eines Fahrzeugs, ein Fehlerereignis, Informationen über das Fahrzeug zu einer Zeit des Fehlerereignisses, Integritätsdaten, die basierend auf den Informationen über das Fahrzeug zu einer Zeit des Fehlerereignisses generiert werden, einen Abschnitt des flüchtigen Speichers, der dazu konfiguriert ist, gespeicherte Daten während eines Neustarts des Betriebssystems des Fahrzeugs zu erhalten, wobei die Informationen über das Fahrzeug und die Integritätsdaten in dem Abschnitt des flüchtigen Speichers als Reaktion auf das Fehlerereignis gespeichert werden, nichtflüchtigen Speicher, wobei als Reaktion darauf, dass das Betriebssystem des Fahrzeugs neu gestartet wird, die Informationen über das Fahrzeug basierend auf den Integritätsdaten validiert werden, und wobei als Reaktion auf die Validierung die Informationen über das Fahrzeug in dem nichtflüchtigen Speicher gespeichert werden. In einigen Ausführungsformen umfassen die Integritätsdaten eine zyklische Redundanzprüfung (Cyclic Redundancy Check, CRC). In einigen Ausführungsformen umfasst der flüchtige Speicher einen Direktzugriffsspeicher (Random Access Memory, RAM). In einigen Ausführungsformen ist der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers, der für die Informationen und die Integritätsdaten reserviert ist. In einigen Ausführungsformen umfasst das Erkennen des Fehlerereignisses das Erkennen eines Systemabsturzes. In einigen Ausführungsformen umfassen die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug. Einige Ausführungsformen schließen einen Notfall-Stapel ein, der dazu programmiert ist, die Informationen zu generieren, die Integritätsdaten zu generieren und die Informationen und die Integritätsdaten im Falle des Fehlerereignisses zu speichern.
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit nicht-transitorischen darauf codierten computerlesbaren Anweisungen ein, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, durch eine Verarbeitungsschaltlogik ein Fehlerereignis zu erkennen, und als Reaktion auf das Erkennen durch die Verarbeitungsschaltlogik die Informationen über das Fahrzeug zu einer Zeit des Fehlerereignisses zu generieren, durch die Verarbeitungsschaltlogik Integritätsdaten basierend auf den Informationen zu generieren, durch die Verarbeitungsschaltlogik das Speichern der Informationen über das Fahrzeug und die Integritätsdaten in einem Abschnitt des flüchtigen Speichers zu bewirken, wobei der Abschnitt des flüchtigen Speichers dazu konfiguriert ist, gespeicherte Daten während eines Neustarts eines Betriebssystems des Fahrzeugs zu erhalten, unter Verwendung der Verarbeitungsschaltlogik den Neustart des Betriebssystems des Fahrzeugs zu bewirken, nach dem Neustart unter Verwendung der Verarbeitungsschaltlogik die im flüchtigen Speicher gespeicherten Informationen basierend auf den Integritätsdaten zu validieren und als Reaktion auf das Validieren zu bewirken, dass die Informationen über das Fahrzeug im nichtflüchtigen Speicher gespeichert werden. In einigen Ausführungsformen umfassen die Integritätsdaten eine zyklische Redundanzprüfung (Cyclic Redundancy Check, CRC). In einigen Ausführungsformen umfasst der flüchtige Speicher einen Direktzugriffsspeicher (Random Access Memory, RAM). In einigen Ausführungsformen ist der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers, der für die Informationen und die Integritätsdaten reserviert ist. In einigen Ausführungsformen umfasst das Erkennen des Fehlerereignisses das Erkennen eines Systemabsturzes. In einigen Ausführungsformen umfassen die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug.
  • 15 stellt ein beispielhaftes System zur Verwaltung von Versionen von Datenbankdateien (DBC-Dateien) für eine Mikrosteuerung (z. B. eine Mikrosteuerung von Fahrzeugen, die in einer der 1-3 dargestellt sind) dar. DBC-Dateien können Definitionsdateien sein, die den SAE J1939-Standards entsprechen. DBC-Dateien können auch in speziellen formatierten Definitionsdateien vorliegen, wie in Bezug auf 4-8 beschrieben. Die DBC-Dateien können verwendet werden, um Daten über den Controller Area Network-Bus (CAN-Bus) von Peripheriegeräten (z. B. von einem Pumpenbremsmodul, Motormodul wie ECM oder einem anderen Peripheriegerät oder Sensor eines Fahrzeugs) bereitzustellen. DBC-Dateien werden im Allgemeinen in einer Form vorliegen, die interpretiert werden muss. Zum Beispiel können Daten von DBC in dem in Tabelle 1 gezeigten Format erscheinen: Tabelle 1
    0 18FE6900 X 8 9C 27 DC 29 FF FF F3 23 49,745760 R
  • Diese Daten können decodiert werden, um Werte für bestimmte definierte Parameter zu empfangen. Zum Beispiel kann die von einem Pumpenbremssystem empfangene DBC-Datei den Betätigungswinkelwert definieren. In einem anderen Beispiel kann die von einem Motorsystem empfangene DBC-Datei Werte definieren, die Ladelufttemperatur, Motordrehzahl usw. einschließen. Die Umwandlung von binären DBC-Daten in Nutzwerte kann durch eine Schnittstellendatei durchgeführt werden, die Daten über den CAN oder Ethernet-Bus akzeptiert.
  • In einem Ansatz ist eine einzige Schnittstellendatei dafür fest zugeordnet, eine bestimmte DBC-Datei von einem bestimmten Peripheriegerät (z. B. vom Pumpenbremsmodul) zu verarbeiten. Wenn jedoch die Pumpenbremshardware mit einer anderen Pumpenbremse physisch modifiziert werden sollte, würde dies den vollständigen Austausch der Schnittstellendatei erfordern, um die neue Version eines Peripheriegeräts zu handhaben. Bei diesem Ansatz entfällt die Nutzung von Gemeinsamkeiten zwischen DBC-Dateien für verschiedene Versionen eines Peripheriegeräts und somit die Verwendung gemeinsamer Teile einer Schnittstellendatei, die noch verwendet werden könnte, wobei stattdessen eine völlig neue Schnittstellendatei erforderlich wäre, was zu aufwändigen Verzögerungen beim Erfassen und Installieren neuer Schnittstellendateien führen kann. Darüber hinaus kann eine Änderung der Schnittstellendatei auch Änderungen im gesamten System erfordern, die sich auf Daten vom DBC-Dateiinterpreter stützen. Somit kann eine Änderung bei einem einzigen Peripheriegerät Änderungen in der gesamten Architektur eines Fahrzeugs (oder eines anderen Systems) erfordern.
  • Um die Probleme der vorstehend beschriebenen Ansätze zu überwinden, wird eine Implementierung der Fahrzeugarchitektur bereitgestellt, die den Anwendungscode über das gesamte System hinweg beibehält, während sie unterschiedliche Schnittstellen in Abhängigkeit vom Fahrzeugtyp, der Architektur des Fahrzeugs oder basierend auf dem Austausch eines bestimmten Peripheriegeräts bereitstellt. Zum Beispiel können für verschiedene Versionen eines Fahrzeugs unterschiedliche Schnittstellen erforderlich sein. In einem anderen Beispiel kann ein Austausch eines Peripheriegeräts eine neue Version der DBC-Interpreterschnittstelle erforderlich machen. In einem Beispiel kann ein Fahrzeug z. B. eine neue Pumpenbremshardware empfangen, die eine neue Schnittstellendatei erfordert.
  • In einigen Ausführungsformen kann das Betriebssystem eines Fahrzeugs das Vorhandensein eines neuen Peripheriegeräts (z. B. einer neuen Pumpenbremse) durch Erkennen eines Build-Konfigurationsereignisses erkennen. Dann kann das Betriebssystem eine neue Schnittstellendatei ziehen, um sie in die Hardware des Fahrzeugs zu flashen. Zum Beispiel kann das Betriebssystem eine Zuordnung zwischen Quelldateien und einer Fahrzeugsoftwarekomponente identifizieren (z. B. eine Zuordnung zwischen Daten von einer neuen Pumpenbremse und Anwendungen, die den Pumpenbremseingang handhaben, und/oder jede Anwendung, die Daten von der Pumpenbremse verwendet). Das Betriebssystem kann dann die zugehörigen Quelldateien in einem Stammverzeichnis kombinieren und mindestens eine Schnittstellenabstraktionsschicht für die Fahrzeugsoftwarekomponente generieren (z. B. die ECU, die Pumpenbremsdaten benötigen kann) basierend auf den kombinierten Quelldateien.
  • Zum Beispiel kann das Pumpenbremsmodul eine DBC-Datei bereitstellen, die einen Betätigungswinkel für das Bremspedal bereitstellt. Da jedoch unterschiedliche Bremsen unterschiedliche „Geber“-Werte aufweisen, kann dieselbe Winkeländerung des Bremsbetätigungswerts durch andere Teile des Fahrzeugs (z. B. ECU oder TCM) völlig unterschiedlich gehandhabt werden. Um das Problem zu lösen, kann das System eine Abstraktionsschicht 1506 zwischen der DBC-Interpretation durch eine zugehörige Schnittstelle und Anwendungen bereitstellen, die für andere Module im System ausgeführt werden. Beispielsweise kann die Abstraktionsschicht anstelle eines Rohwinkelwerts einen Wert der „beabsichtigten Geschwindigkeitsänderung“ in das System bereitstellen. Zum Beispiel gibt bei einem Typ von Pumpenbremse eine Änderung in 5 Grad eine gewünschte Abnahme von 5 MPH an, und bei einem anderen Typ von Pumpenbremse gab eine Änderung von 5 Grad eine gewünschte Abnahme von 7 MPH an. Wenn die gesamte auf Bremsaktionen bezogene Software so programmiert ist, dass sie sich auf die gewünschte Drehzahländerungsmetrik stützt, kann eine Abstraktionsschicht bereitgestellt werden, die DBC-Daten von der Pumpenbremse in eine gewünschte Drehzahländerungsmetrik umwandelt, bevor diese Daten anderen Anwendungen bereitgestellt werden. Auf diese Weise kann eine Schnittstellenversion für die Pumpenbremse ohne weitere Änderungen am übrigen System leicht geändert werden. Ähnliche Abstraktionen können für (einen) beliebige(n) andere(n) Wert(e) verwendet werden, der/die von den DBC-Dateien bereitgestellt wird/werden. Die abstrahierten Informationen können daher ohne Berücksichtigung der von der neuen Hardwarekomponente generierten Daten verarbeitet werden.
  • Die Aktualisierung der Schnittstellenversion kann durch ein in 15 dargestellten System durchgeführt werden. Zum Beispiel kann das Fahrzeug einen Unified Diagnostic Services-Server (UDS-Server) 1501 einschließen, der es externen Vorrichtungen ermöglicht, UDS-Vorgänge durchzuführen (z. B. Bereitstellen von Laufzeitsteuerung, Abrufen der Laufzeitsteuerung und Löschen der Laufzeitsteuerung). Diese Vorgänge können CRC-geschützt sein. Der UDS-Server ermöglicht es, einen Computer 1502, bekannt als UDS Client, (z. B. Computer oder ein fest zugeordnetes Testwerkzeug) mit dem Fahrzeug (z. B. über eine UDS-Schnittstelle) zu verbinden. Der UDS-Client 1502 kann (z. B. über ein externes Netzwerk wie das Internet) mit codierter Laufzeitkonfigurationsdatei für das Fahrzeug bereitgestellt werden. Die codierte Laufzeitkonfigurationsdatei 1503 kann an den UDS-Server 1501 gesendet werden, der sie dann in die Variantenbibliothek 1504 im Speicher des Fahrzeugs schreiben kann. Das Fahrzeug kann einen nichtflüchtigen Speicher und optional eine oder mehrere zusätzliche Bibliotheken, wie zum Beispiel die Leistungsverlustresilienzanwendung, verwenden, um die Laufzeitkonfigurationsdatei 1503 zu decodieren. Infolgedessen kann eine zusätzliche decodierte Laufzeitkonfiguration 1505 zu dem Variantenbibliothekspeicher hinzugefügt werden. Die Anwendung (z. B. ECM-Anwendungen) kann dann während der Laufzeit die benötigte Konfiguration aus der Bibliothek anfordern. Optional kann es eine Abstraktionsschicht geben, die der Anwendung zur Verfügung steht, die anstelle von Rohwerten aus DBC-Dateien auf abstrahierte Daten zugreifen kann.
  • In einigen Ausführungsformen kann anstelle diskreter Versionen die Variantenbibliothek stattdessen definieren, was in verschiedenen Versionen der Laufzeitanweisungen unterschiedlich ist. Zum Beispiel können bestimmte Teile des Codes in dem Code verschleiert werden, um verschiedene Versionen zu erhalten. In einigen Implementierungen kann das Build-System auf Fahrzeuggenerierungsinformationen zugreifen und diese Informationen zum Identifizieren von Hardware-Unterschieden verwenden. Zum Beispiel kann auf eine andere Schnittstellen-ID für eine Batterie oder HLK zugegriffen werden. Stattdessen kann das System bei Verwendung einer Konfiguration, die für ein bestimmtes Fahrzeugmodell spezifisch ist, identifizieren, welche Teile des Fahrzeugs unterschiedlich sind. Wenn beispielsweise zwei Fahrzeuge ein unterschiedliches HLK-System aufweisen, kann das Softwaremodul zum Steuern des HLK in der Konfiguration umgeschaltet werden, ohne den Rest der Konfiguration zu beeinflussen (dies kann durch die Verwendung von Abstraktion ermöglicht werden). Eine neue Lokale Interconnect Network-Tabelle (LIN-Tabelle) kann verwendet werden, um diese Funktionalität zu erreichen. In einer anderen Ausführungsform kann die Zeitplan-Tabelle verwendet werden, um die Umschaltung zur Laufzeit vorzunehmen. Zum Beispiel kann dieselbe Binärdatei in alle Fahrzeuge geladen werden, und das System kann den korrekten Code im laufenden Betrieb auswählen und den für andere Konfigurationen relevanten Code ignorieren.
  • In einigen Ausführungsformen können Build-Zeitkonfigurationsoptionen durch Laufzeitkonfigurationsoptionen ersetzt werden. Beispielsweise kann auf diese Weise nur eine einzige Binärdatei für alle Fahrzeugvarianten verwendet werden. Alle anderen Konfigurationsoptionen können durch diese Variantenbibliothek eingestellt werden. Die benutzerkonfigurierbaren oder auswählbaren Variantenoptionen eines Fahrzeugs können auch unter Verwendung der Variantenbibliothek gespeichert werden. Als weiteres Beispiel kann eine auswählbare Variante durch die Radgröße am Fahrzeug definiert werden. Da die Radgröße Einfluss auf die Fahrzeugdynamik hat, hat die Radgröße eine vordefinierte Auswirkung auf die Fahrzeugdynamikmodul-Software, wobei die gesamte Software betroffen sein kann. Die Radgröße kann in Software abstrahiert und allen Modulen bereitgestellt werden, die sich auf die Radgröße stützen, um ihre Funktionen auszuführen.
  • In einigen Ausführungsformen können ähnliche Techniken für die Handhabung von CAN-Schnittstellen verwendet werden. Zum Beispiel kann eine Konfigurationsdatei eine Software- oder Hardware-Differenz bezeichnen. In Abhängigkeit von einem Stringwert, der die Unterschiede benennt, kann das Build-System korrekte DBC-Dateien aus den Verzeichnissen im Speicher auswählen.
  • In einigen Ausführungsformen können Laufzeitsoftwarevarianten in jedem Modul (z. B. in einer ECU) zur Laufzeit basierend auf der Konfigurationseinstellung im Fahrzeug gehandhabt werden. Wenn die Konfiguration in einem Fahrzeug geändert wird, arbeitet die Modulsoftware basierend auf der neuen Konfiguration anders, obwohl die Software auf dem Modul gleich bleibt. Laufzeitsoftwarevarianten können im ECU-Quellcode unter Verwendung von „if/then“- oder „switch“-Statements (z. B. in der Programmiersprache C) verfolgt werden. Durch das Software-Build-System können Build-Zeitsoftwarevarianten unter Verwendung von Kompilierzeit-Flags generiert werden. Für das gleiche Modul können mehrere Binärdateien verwendet werden, um unterschiedliche Fahrzeugkonfigurationen zu unterstützen. Um den Softwarebetrieb auf einem Fahrzeug zu ändern, kann das Modul (z. B. die ECU) mit unterschiedlicher Software geflasht werden, nachdem die Konfiguration im Fahrzeug geändert wird. Build-Zeitvarianten können durch die Variantenkonfigurationskarte verfolgt und gesteuert werden. Die Variantenkonfigurationskarte kann im Speicher des Fahrzeugs (z. B. in einem Software GitHub-Repository) als Teil der Build-Skripte gespeichert werden. Während eines Software-Builds werden die generierten Binärdateien entsprechend ihrer Varianten innerhalb des Fahrzeugsoftwarepakets strukturiert, die dann hochgeladen und in der Variantenbibliothek gespeichert werden.
  • In einigen Ausführungsformen können die Fahrzeuggenerierungs-IDs als eine Revision einer bestimmten Plattform definiert sein. Um die Varianten zu handhaben, können mehrere DBC-Dateien basierend auf den in der Build-Konfiguration des Projekts definierten IDs kombiniert werden. DBC-Dateien können durch die Plattform zerlegt und dann zu einer DBC-Datei pro Bus kombiniert und vor der Build-Zeit basierend auf in der Build-Konfiguration definierten Feldern im Speicher platziert werden. Das Betriebssystem kann die Schnittstellenabstraktionsdateien basierend auf Schnittstellenvarianten generieren. Auf diese Weise kann ein Ordner von gemeinsamen Schnittstellen und fahrzeugmodellspezifischen Gemeinsamkeiten generiert werden, die dazu definiert sind, DBC-Dateien aus mehreren Peripheriegeräten zu handhaben. Zum Beispiel können ein Ordner für gemeinsame DBC-Schnittstellen sowie Variantenordner für Schnittstellen für Modelle vorhanden sein, die unterschiedliche Hardwareversionen verwenden. Da die Gemeinsamkeiten zwischen Plattformen abnehmen, kann die Ordnerstruktur sich schließlich in ein Format verändern, das den gemeinsamen Ordner nicht mehr verwendet.
  • Einige Ausführungsformen schließen ein Verfahren zum Aktualisieren eines Fahrzeugs ein, wenn eine neue Hardwarekomponente installiert wird, wie in 15a, wobei das Verfahren umfasst: Erkennen, unter Verwendung der Verarbeitungsschaltlogik in dem Fahrzeug, der neuen Hardwarekomponente in Schritt 1510, Identifizieren, unter Verwendung der Verarbeitungsschaltlogik, einer Zuordnung zwischen den von der neuen Hardwarekomponente generierten Daten-Konfigurationsdaten und mindestens einer Softwarekomponente des Fahrzeugs 1520, Bestimmen, ob eine aktualisierte Schnittstelle in Schritt 1530 benötigt wird, und wenn ja, in Schritt 1540, Generieren, unter Verwendung der Verarbeitungsschaltlogik, einer aktualisierten Schnittstelle zum Interpretieren der Daten von der Hardwarekomponente, wobei die aktualisierte Schnittstelle die von der Hardwarekomponente bereitgestellten Daten in abstrahierte Informationen umwandelt, und wobei die aktualisierte Schnittstelle die abstrahierten Informationen der mindestens einen Softwarekomponente des Fahrzeugs bereitstellt. Wenn in Schritt 1520 keine aktualisierte Schnittstelle benötigt wird, dann bewegt sich das Verfahren zu Schritt 1540 und es findet keine Aktion statt. In einigen Ausführungsformen umfassen die von der neuen Hardwarekomponente generierten Daten eine Datenbankdatei (DBC-Datei). Einige Ausführungsformen schließen das Speichern der aktualisierten Schnittstelle in einer Bibliothek von Schnittstellen ein, wobei das Generieren der aktualisierten Schnittstelle das Zugreifen auf die aktualisierte Schnittstelle aus der Bibliothek umfasst. In einigen Ausführungsformen wird die aktualisierte Schnittstelle basierend auf einer Identifikation der neuen Hardwarekomponente aus der Bibliothek ausgewählt. Einige Ausführungsformen schließen das Verarbeiten der abstrahierten Informationen ungeachtet der von der neuen Hardwarekomponente generierten Daten durch die mindestens eine Softwarekomponente des Fahrzeugs ein. In einigen Ausführungsformen wird die aktualisierte Schnittstelle zur bidirektionalen Kommunikation zwischen der mindestens einen Softwarekomponente und der neuen Hardwarekomponente verwendet. In einigen Ausführungsformen umfasst das Generieren der aktualisierten Schnittstelle das Modifizieren einer vorhandenen Schnittstelle.
  • Einige Ausführungsformen schließen ein System zum Aktualisieren eines Fahrzeugs ein, wenn eine neue Hardwarekomponente installiert wird, wobei das System umfasst: die neue Hardwarekomponente, eine Zuordnung zwischen Daten, die von der neuen Hardwarekomponente generiert werden, und mindestens eine Softwarekomponente des Fahrzeugs und eine Schnittstelle, die dazu konfiguriert ist, die Daten von der Hardwarekomponente in abstrahierte Informationen umzuwandeln, wobei die Schnittstelle die abstrahierten Informationen der mindestens einen Softwarekomponente des Fahrzeugs bereitstellt. In einigen Ausführungsformen umfassen die von der neuen Hardwarekomponente generierten Daten eine Datenbankdatei (DBC-Datei). Einige Ausführungsformen schließen eine Schnittstellenbibliothek ein, in der die aktualisierte Schnittstelle gespeichert ist. Einige Ausführungsformen schließen eine Identifikation der neuen Hardwarekomponente ein, wobei die aktualisierte Schnittstelle basierend auf der Identifikation der neuen Hardwarekomponente aus der Bibliothek ausgewählt wird. In einigen Ausführungsformen werden die abstrahierten Informationen ungeachtet der von der neuen Hardwarekomponente generierten Daten von der mindestens einen Softwarekomponente des Fahrzeugs verarbeitet. In einigen Ausführungsformen wird die aktualisierte Schnittstelle zur bidirektionalen Kommunikation zwischen der mindestens einen Softwarekomponente und der neuen Hardwarekomponente verwendet. In einigen Ausführungsformen ist die aktualisierte Schnittstelle eine Modifizierung einer vorhandenen Schnittstelle.
  • Einige Ausführungsformen schließen ein nicht-transitorisches computerlesbares Medium mit nicht-transitorischen darauf codierten computerlesbaren Anweisungen ein, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, unter Verwendung der Verarbeitungsschaltlogik in dem Fahrzeug die neue Hardwarekomponente zu erkennen, unter Verwendung der Verarbeitungsschaltlogik eine Zuordnung zwischen Daten zu identifizieren, die von der neuen Hardwarekomponente und mindestens einer Softwarekomponente des Fahrzeugs generiert werden, und unter Verwendung der Verarbeitungsschaltlogik eine aktualisierte Schnittstelle zum Interpretieren der Daten von der Hardwarekomponente zu generieren, wobei die aktualisierte Schnittstelle die von der Hardwarekomponente bereitgestellten Daten in abstrahierte Informationen umwandelt, und wobei die aktualisierte Schnittstelle die abstrahierten Informationen der mindestens einen Softwarekomponente des Fahrzeugs bereitstellt. In einigen Ausführungsformen umfassen die von der neuen Hardwarekomponente generierten Daten eine Datenbankdatei (DBC-Datei). Einige Ausführungsformen schließen das Bewirken ein, dass der Prozessor die aktualisierte Schnittstelle in einer Schnittstellenbibliothek speichert, wobei das Generieren der aktualisierten Schnittstelle das Zugreifen auf die aktualisierte Schnittstelle aus der Bibliothek umfasst. In einigen Ausführungsformen wird die aktualisierte Schnittstelle basierend auf einer Identifikation der neuen Hardwarekomponente aus der Bibliothek ausgewählt. Einige Ausführungsformen schließen das Bewirken ein, dass der Prozessor durch die mindestens eine Softwarekomponente des Fahrzeugs die abstrahierten Informationen ungeachtet der von der neuen Hardwarekomponente generierten Daten verarbeitet. In einigen Ausführungsformen wird die aktualisierte Schnittstelle zur bidirektionalen Kommunikation zwischen der mindestens einen Softwarekomponente und der neuen Hardwarekomponente verwendet.
  • 16 zeigt ein beispielhaftes System zum Managen der Zeitsynchronisation verschiedener Module (z. B. Hardware und/oder Software), die über einen einzigen Bus (z. B. einen CAN-Bus) verbunden sind. Insbesondere können die Techniken auf jede Art eines Many-Master-Bus-basierten Protokolls angewendet werden (z. B. wenn am Bus viele Busmasterknoten vorhanden sind). Solche Busse können verwendet werden, wenn mehrere Knoten auf dem Bus eine Fähigkeit aufweisen müssen, die Übertragung von Daten einzuleiten. Zum Beispiel kann ein Many-Master-Bus verwendet werden, um Daten zwischen Peripheriegeräten und Speicher ohne die Nutzung der CPU zu übertragen.
  • In einem beispielhaften Fahrzeug (z. B. wie in 1-3 dargestellt) können mehrere Knoten (z. B. ECUs) mit einem Bus 1600 (z. B. einem CAN-Bus oder einem anderen Many-Master-Bus) verbunden sein, wie in 16 gezeigt. Jeder Kreis in 16 kann einen Knoten 1601, 1602 und so weiter darstellen. Oft müssen einzelne Knoten (z. B. ECUs) ein Zeitintervall kennen, das über den Bus hinweg konsistent ist. In einem Ansatz kann ein einziger Knoten (z. B. zufallsbasiert) zum „Zeitserver“ ernannt werden. Dieser Zeitserverknoten kann dann seine interne Uhr auf dem Bus ausstrahlen. Alle anderen Knoten würden dann diese ausgestrahlte Nachricht empfangen und ihre internen Uhren synchronisieren.
  • Diese vorherige Lösung berücksichtigt jedoch nicht die Zeitverzögerung zwischen dem Punkt, an dem die Zeit an einer Busnachricht durch den Zeitserver eingestellt wird, und der Zeit, zu der sie schließlich von einem Empfangsknoten empfangen und verarbeitet wird. Die Verzögerung kann durch mehrere variable Verzögerungsquellen verursacht werden. Die Verzögerungsquellen können die Zeit einschließen, die für die Zeitsynchronisations-Ausstrahlung benötigt wird, um den Softwarestapel des Servers zu durchlaufen, bevor er über einen Hardware-Bus übertragen werden kann. Die Verzögerungsquellen können die Zeit einschließen, während der die Nachricht auf der Leitung des Busses wandert (der in Busmanagersystemen, die Arbitrierungsprotokolle verwenden, nicht deterministisch sein kann). Die Verzögerungsquellen können die Zeit einschließen, die benötigt wird, um die empfangene Nachricht durch den Softwarestapel des Client zu verarbeiten, bevor der Client auf den Zeitwert zugreifen kann. Aus diesen Gründen wird, wenn der Client seine interne Uhr auf die gerade in der Busnachricht empfangene Zeit aktualisiert, diese auf eine Zeit in der Vergangenheit synchronisiert. Bei diesem Ansatz wird die interne Uhr eines Clients der Zeit des Zeitserverknotens nacheilen. Einige Knoten sind möglicherweise für eine solche relativ kleine Zeitdifferenz (z. B. Knoten 1602 und 1603) unempfindlich, jedoch können andere Knoten präzise und enge Zeitsynchronisation (z. B. ein Knoten 1604) mit den Serverknoten (1601) benötigen.
  • Ein weiterer Ansatz zur Zeitsynchronisation wird durch einfaches Netzwerk-Zeitprotokoll (Simple Network Time Protocol, SNTP-Protokoll), RFC 1769, https://datatracker.ietf.org/doc/html/rfcl769 beschrieben, das hierin in seiner Gesamtheit aufgenommen ist. In einem solchen Ansatz sendet ein Client seine lokale Zeit in einer Synchronisationsnachricht an den Zeitserver. Der Server antwortet mit einer Synchronisationsnachricht, die sowohl die lokale Zeit des Clients als auch die lokale Zeit des Servers einschließt. Der Client kann dann die Verzögerung (z. B. durch Subtrahieren von Zeitstempeln) zwischen dem Client und dem Server berechnen und seine Uhr um den Verzögerungswert anpassen und dadurch eine engere Synchronisation erreichen. Der Nachteil dieses Ansatzes besteht darin, dass es eine Punkt-zu-Punkt-Kommunikation zwischen jedem Knoten und dem Zeitserver erfordert. Große Mengen solcher Nachrichten können den Bus sättigen und die Busleistung verschlechtern. Darüber hinaus benötigen einige Knoten möglicherweise keine enge Synchronisation, wobei sie in diesem Fall den Bus noch mit völlig unnötigen Synchronisationsnachrichten fluten.
  • 17 und 18 zeigen eine Hybridlösung zur Knotensynchronisation, mit der sowohl lockere als auch enge Synchronisation erreicht werden kann, je nachdem was von mehreren Knoten mit unterschiedlichen Anforderungen auf demselben Bus benötigt wird. Dieses Verfahren bietet dem Knoten die Fähigkeit, seine Zeitsynchronisationsebene auszuwählen. Durch das passive Abhören der Zeitaktualisierungen kann er eine unterdurchschnittliche Synchronisationsebene aufrecht erhalten. Durch aktives Anfordern von Zeitaktualisierungen kann er eine hohe Synchronisationsebene aufrecht erhalten, ohne die anderen Knoten im Netzwerk zu beeinflussen. Wie in 17 gezeigt, kann der Serverknoten kontinuierlich (z. B. periodisch oder in anderen spezifischen Intervallen) eine Nachricht übertragen (z. B. durch Ausstrahlen auf einen Bus), die die interne Zeit des Servers einschließt. Zum Beispiel kann die Nachricht ein „Übertragungsfeld“ einschließen, das einen Zeitwert der internen Uhr des Servers einschließt, wenn die Nachricht erstellt wird. Zum Beispiel kann der Übertragungszeitstempel einen Wert von „47,5 ms“ aufweisen.
  • Die Nachricht kann eine Serverstapelverzögerung, eine Leitungsverzögerung und eine Client-Stapelverzögerung erfahren, bevor sie durch einen Zeit-Clientknoten verarbeitet werden, der die Nachricht modifizieren kann, indem ein Zielzeitstempel zur Zeit des Empfangs der Nachricht hinzugefügt wird. Beispielsweise kann der Zielzeitstempel einen Wert von „60 ms“ aufweisen Der Knoten kann dann die Differenz zwischen dem Übertragungs- und Zielzeitstempel berechnen, um seine Uhr anzupassen. Zum Beispiel kann der Knoten seinen Uhr auf „47,5 ms“ anpassen, um eine lockere Synchronisation zu erreichen. Der Client-Knoten kann diese Synchronisation durchführen, wann immer dies geeignet ist (z. B. jedes Mal, wenn die Synchronisationsnachricht vom Server empfangen wird oder nur unter Verwendung von einigen der ausgestrahlten Nachrichten).
  • 17 zeigt eine Interaktion zwischen einem Knoten, der eine enge Synchronisation benötigt, und demselben Server. In diesem Fall kann der Server auch kontinuierlich (z. B. periodisch oder in anderen spezifischen Intervallen) eine Nachricht übertragen (z. B. durch Ausstrahlen auf einen Bus), die die interne Zeit des Servers einschließt. Der Server kann jedoch Synchronisationsanforderungen berücksichtigen, die von Knoten über einen Bus gesendet werden.
  • In 17 kann beispielsweise ein Knoten, der eine enge Synchronisation benötigt, eine Synch-Anforderung übertragen, die einen Zeitstempel 1701 zur Zeit des Übertragens unter Verwendung der internen Uhr des Knotens einschließt. Zum Beispiel kann das Übertragungsfeld einen Wert von „56,5“ einschließen (der die lokale Zeit des Knotens ist). Der Knoten kann eine lokale Kopie des Übertragungsfelds zur Verifizierung speichern.
  • Wenn der Zeitserver eine solche Anforderung empfängt, kann er seine nächste periodisch gesendete Zeitaktualisierungsnachricht modifizieren. In einigen Ausführungsformen kann der Server mehrere enge Synch-Anforderungen vor der nächsten Aktualisierungsnachricht empfangen. In diesem Fall kann der Server unter Umständen nur eine dieser Anforderungen verarbeiten (z. B. die erste oder eine zufällig ausgewählte). Insbesondere kann der Server die nächste Synch-Aktualisierungsnachricht erstellen, indem er den Übertragungswert der empfangenen Nachrichten in ein Feld „Ursprung“ platziert. Beispielsweise kann das Feld „Ursprung“ einen Wert von „56,5“ einschließen Der Server kann auch unter Verwendung der Uhr des Servers einen Zeitstempel 1702 einschließen, der angibt, wann die von dem Knoten gesendete Nachricht durch den Server empfangen wurde. Zum Beispiel kann die „Empfangs“-Datei den Wert „60“ aufweisen. Der Server sendet dann die Aktualisierungsnachricht (z. B. in der ursprünglich geplanten Zeit oder sofort), wobei die Aktualisierungsnachricht die Zeit des Übertragens basierend auf der Uhr des Servers einschließt. Zum Beispiel kann der Übertragungswert auf „60,5“ gesetzt werden.
  • Wenn der Client die Synch-Nachricht empfängt, kann er ihn modifizieren, indem er basierend auf seiner eigenen Uhr einen Zeitstempel in das Zielfeld hinzufügt. Wenn der Client die Synch-Nachricht vom Server empfängt, der einen „Ursprungs“-Wert von nicht Null aufweist, kann der Client das „Ursprungs“-Feld mit der anfänglichen „Übertragungszeit“ der durch den Knoten gesendeten (und im Speicher des Knotens gespeicherten) Nachricht vergleichen. Wenn die Felder nicht übereinstimmen, kann der Knoten weiterhin die von dem Server empfangene Nachricht für eine lockere Synchronisation verwenden (wie z. B. in Bezug auf 16 beschrieben). Wenn die Felder übereinstimmen, kann der Client eine enge Synchronisation durchführen.
  • Insbesondere kann die enge Synchronisation durchgeführt werden, indem eine Umlaufverzögerung 1801 berechnet wird, wobei z. B. die Umlaufverzögerung = („Ziel“-Wert 1802 - „Ursprungs“-Wert 1803) - („Empfangs“-Wert 1804 - „Übertragungs“-Wert 1805), wie in 18 gezeigt, durchgeführt werden kann. Das heißt, der Client-Knoten kann die Verzögerung zwischen dem Serverempfang und der Serverübertragung, die Verzögerung zwischen der Knotenübertragung und dem Knotenempfang berechnen und diese Werte subtrahieren. Der Knoten kann auch den Zeitversatz 1806 durch Mittelwertbildung berechnen: (a) eine Zeitdifferenz zwischen dem „Ursprungs“-Wert 1803 (Knoten-Uhr) und der Empfangszeit 1804 (Serveruhr) und (b) eine Zeitdifferenz zwischen dem „Übergangswert“ 1805 (Serveruhr) und „Ziel“ 1802 (Knoten-Uhr). Die Umlaufverzögerung und die Versatzwerte können von dem Knoten dazu verwendet werden, seine lokale Uhr zu modifizieren, um sie eng mit der Server-Uhr abzustimmen (z. B. durch Hinzufügen der Umlaufverzögerung und des Zeitversatzes zu seiner internen Uhr). Vorteilhafterweise können zwei Knoten, wenn sie miteinander synchronisiert sind, eine enge Serversynchronisation unter Verwendung derselben Nachricht vom Server durchführen (da ihre Übertragungswerte gleich sein werden).
  • Zusätzlich kann in einigen Implementierungen ein Knoten eine Historie von berechneten Zeitversätzen und Umlaufverzögerungen speichern. Wenn die Historie ein stabiles Muster angibt, kann der Knoten die Frequenz reduzieren, bei der er eine enge Synchronisation anfordert oder das Senden einer Anforderung nach enger Synchronisation stoppt und sich auf historische Werte stützt, anstatt die Synchronisation durchzuführen. Dies kann ferner eine Überlastung auf einem Bus (z. B. auf dem CAN-Bus) reduzieren.
  • Einige Ausführungsformen, wie sie in 18A zu sehen sind, schließen ein Verfahren zur engen Synchronisation zwischen einem ersten Client, einem zweiten Client und einem Zeitserver ein, die jeweils mit einer jeweiligen lokalen Uhr verbunden sind und jeweils mit einem Bus verbunden sind, wobei das Verfahren die folgenden Schritte umfasst: Generieren einer periodischen über den Bus 1810 kommunizierten Synchronisationsnachricht durch den Zeitserver, Empfangen, am Zeitserver über den Bus, einer Synchronisationsnachricht, die eine Anforderung nach einer engen Synchronisation von dem ersten Client 1820 umfasst, als Reaktion auf das Empfangen der Synchronisationsnachricht, Anpassen der periodischen Synchronisationsnachricht durch den Zeitserver basierend auf der engen Synchronisationsanforderung durch Anpassen der nächsten periodischen Synchronisationsanforderung, um einzuschließen: (a) eine erste Zeit, die angibt, wann der erste Client die Synchronisationsnachricht übertragen hat, (b) eine zweite Zeit, die angibt, wann der Server die enge Synchronisationsanforderung empfangen hat, und (c) eine dritte Zeit, die angibt, wann die periodische Synchronisationsnachricht durch den Zeitserver 1830 gesendet wurde, Durchführen, durch den ersten Client, von enger Synchronisation basierend auf der angepassten periodischen Synchronisationsnachricht 1840 und Durchführen, durch den zweiten Client, einer lockeren Synchronisation basierend auf der angepassten periodischen Synchronisationsnachricht 1850.
  • 19-21 stellen ein Beispiel zum Zusammensetzen von Assembler-Code für Testvorrichtungen (z. B. integrierte Schaltlogiken) dar. Insbesondere werden Systeme und Verfahren bereitgestellt, um kompilierten maschinenlesbaren Code (z. B. Assembler-Code) zum Testen mehrerer Versionen von Funktionen zu erstellen, die aus einer Sprache kompiliert sind, die keine Überladungsvorgänge von Funktionen zulässt (z. B. der Sprache C). Die Vorrichtung kann jede Schaltlogik eines Fahrzeugs sein, wie in 1-3 gezeigt. In einigen Ausführungsformen kann die Vorrichtung jede geeignete elektronische Vorrichtung sein.
  • Der Komponententest ist integraler Bestandteil der sicheren Softwareentwicklung. Zum Beispiel empfiehlt die Norm ISO26262 dringend, dass sicherheitskritische Software Komponententests auf der Zielvorrichtung oder -schaltlogik aufweist, für die der Code ausgeführt werden soll. Zu diesem Zweck wird die Software während der Tests der zu erstellenden Vorrichtung bereitgestellt und/oder auf die vorhandene Hardware geladen. Diese Tests gewährleisten, dass evtl. compiler- oder hardwarespezifische Merkmale im Vorrichtungstest ordnungsgemäß berücksichtigt werden.
  • In einigen Implementierungen kann eine Schaltlogik, die getestet werden soll (z. B. eine eingebettete Schaltlogik des Fahrzeugs), die gesamte Anwendung als einen einzigen kompilierten Binärcode in der Assembler-Sprache empfangen und installieren. Zum Beispiel können alle Anwendungen, Treiber und notwendige Bibliotheken in einem einzigen Bild innerhalb eines einzigen Speicherplatzes der Schaltlogik kompiliert werden. Eine solche Anforderung macht es jedoch schwierig, ein erschöpfendes Testen aller Eingänge für bestimmte Funktionen durchzuführen.
  • In einem Beispiel kann eine erste Funktion auf einer ersten Vorrichtung einen Ausgang einer zweiten Funktion erfordern, der durch eine zweite Vorrichtung erzeugt wird. In diesem Fall wäre es für erschöpfende Tests des Betriebs der ersten Funktion auf der ersten Vorrichtung vorteilhaft, jeden möglichen Ausgang zu testen, der von der zweiten Funktion bereitgestellt werden kann, die von einer zweiten Vorrichtung erzeugt wird. Um dies zu erreichen, kann die zweite Vorrichtung mit Code geflasht werden, bei dem die zweite Funktion durch eine Fake- (auch bekannt als verkürzte oder Pseudo-) Funktion ersetzt wird, die einfach einen vom Programmierer eingestellten Wert bereitstellte oder alle möglichen Ausgänge durchläuft, anstatt eine echte Funktionalität zu bieten. Zum Beispiel kann ein TCM eine Funktion aufweisen, die einen Drehzahlwert (Revolutions per Minute-Wert, RPM-Wert) von einem ECM erfordert. In diesem Fall kann es beim Testen der TCM-Software von Vorteil sein, eine RPM-Bereitstellungsfunktion auf dem ECM zu simulieren, die jeden möglichen Drehzahlwert durchläuft. Dies bedeutet jedoch, dass das ECM, das zum Testen des TCM verwendet wurde, schließlich mit Bildern zum Testen anderer Funktionen oder einem realen Bild, das eine reale Funktion einschließt, die einen realen Drehzahlwert zurückgibt, erneut geflasht werden muss. Ein solcher Prozess zum Erstellen und erneuten Flashen mehrerer Binärbilder kann aufwändig sein und kann zu Fehlern führen, wenn ein falsches Bild verwendet wird.
  • In einem Ansatz kann eine Funktionsüberladung verwendet werden. In diesem Fall können mehrere Versionen einer Funktion existieren, und das System kann differenzieren, welche Funktion aufgerufen wird (z. B. basierend auf Eingängen des Funktionsaufrufs). Jedoch akzeptieren mehrere eingebettete Systeme den aus solchen Sprachen kompilierten Code nicht und können Code von Sprachen annehmen, die Überladung nicht unterstützen (z. B. C Programmiersprache).
  • Wenn derartige Sprachen verwendet werden, kann für ein gegebenes Bild nur eine Kopie einer Funktion vorhanden sein. Dies bedeutet, dass, wenn eine Funktion für eine Fake-Testfunktion zum Testen einer anderen Funktion verkürzt werden muss, die verkürzte Funktion die einzige Kopie im gesamten Bild ist. Wenn beispielsweise die nächste zu prüfende Einheit die verkürzte Funktion war, kann sie nicht in demselben Bild zusammen mit der vorherigen existieren. In der Praxis bedeutet dies, dass mehrere Bilder für die verschiedenen zu prüfenden Einheiten zusammengestellt werden müssen.
  • Der Prozess zum Flashen dieser mehreren Bilder auf die Zielhardware und das Sammeln der Ergebnisse ist aufwändig.
  • Um dieses Problem zu überwinden, wird ein Verfahren bereitgestellt, das alle benötigten Bilder (einschließlich der realen Bilder und aller Bilder mit verkürzten Funktionen) separat im Assembler-Code kompiliert. Dann wird der Assembler-Code zu einem einzigen Super-Bild zusammengesetzt. Während des Zusammensetzens werden Anpassungen an jedem Teilbild vorgenommen, um der Tatsache Rechnung zu tragen, dass sie sich nun in einem anderen Adressbereich befinden. Dadurch kann eine einzige Datei geflasht werden, die für alle Tests und in der Produktion verwendet werden kann.
  • Diese Lösung erfordert keine Technologie zusätzlich zur Sprache ohne Funktionsüberladung (z. B. Programmiersprache C) und erlegt der Zielhardware keine Einschränkungen auf. Zum Beispiel erfordert die Lösung nicht die Verwendung einer Speichermanagementeinheit, eines neuen Betriebssystems oder einer anderen Programmiersprache. Die Lösung ist weithin auf alle Arten geeigneter Hardware anwendbar und kann die Effizienz von gezielten Komponententests erheblich erhöhen. Darüber hinaus fördert die Lösung die Isolierung zwischen Komponententests, die ein zentraler Faktor von ordnungsgemäßen Komponententests ist, und war dazu mittels der Sprachen ohne Funktionsüberlastung schwierig zu erreichen.
  • Die Verfahren zum Erstellen der Super-Bilder basierend auf den kompilierten Bildern können unter Verwendung der folgenden Schritte durchgeführt werden. Jeder Komponententestcode, der die Verwendung von verkürzten Funktionen erfordert, wird als einziges Bild kompiliert. Dann werden so viele verschiedene Bilder kompiliert, wie für die endgültige Testsuite erforderlich ist. Alle kompilierten Bilder werden in ein Mega-Bilderstellungsprogramm (Mega-Image Creation Program, MICP) eingespeist. MICP lokalisiert für jedes Bild die Position dieses Bildes im Speicher, sodass es nicht mit Speicheranforderungen anderer Bilder kollidiert. Dann passt das MICP für jedes Bild die Maschinenanweisungen an, um den neuen endgültigen Adressort widerzuspiegeln. Als Nächstes wird als Teil der endgültigen Mega-Bilderstellung eine Tabelle von Eintrittspunkten in jedes Teilbild innerhalb des Mega-Bildes erstellt, das die Kombination aus allen Teilbildern sowie dem Komponententestgerüst ist.
  • Als Nächstes wird das Mega-Bild auf die Zielhardware geflasht. An dieser Stelle kann der Hardwaretest zum Sammeln von Testdaten durchgeführt werden. Die Fähigkeit zur schnellen Durchführung von gezielten Komponententests senkt deren Eintrittsbarriere und erleichtert somit das Erhalten der ISO26262 ASIL-Zertifizierung und ermöglicht eine schnellere Produktion von Software mit ASIL-Zertifizierung.
  • 19 zeigt beispielhaften Code für eine zweite Einheit, die zum Testen einer Ersten Einheit verwendet wird. Der Code für die zweite Einheit kann Code für eine Funktion „Funktion 2“ einschließen, die eine reale Funktion ist, die variable Ausgänge erzeugen kann. 20 zeigt beispielhaften Code für eine verwendete erste Einheit, die getestet wird. Wie zu sehen ist, schließt eine zu testende Funktionseinheit 32_t_to_test_one einen Funktionsaufruf an die Funktion 2 in Zeile 111 des Codes ein. Wie vorstehend erwähnt, kann es vorteilhaft sein, die reale Funktion „Funktion 2“ mit einer verkürzten oder Fake-Funktion zu ersetzen, die vom Programmierer eingestellte Werte zurückgibt (z. B. um alle möglichen Ausgänge zu durchlaufen).
  • 21 zeigt ein beispielhaftes von dem MICP erzeugtes Ergebnis, das ein Bild für den Code von 19 und ein Bild für den Code von 20 innerhalb eines einzigen Mega-Bildes 2101 zusammensetzt. Insbesondere schließt das Mega-Bild 2101 eine Sprungtabelle ein, die es der Funktion „Funktion 1“ (an der Linie 105) in dem Teilbild eins 2102 ermöglicht, die reale Funktion „Funktion 2“ in Zeile 246 zusätzlich zum Aufruf der Fake-Funktion an der Linie 193 anzurufen. Die Liniennummern für die Funktion „Funktion 2“ können vom MICP geändert worden sein, um Speicherkonflikte zu vermeiden. Ein Fachmann wird bemerken, dass, obwohl 19-21 einen Code in der Sprache C zeigen, jede andere Programmiersprache verwendet worden sein kann (z. B. Assembler-Sprache, die spezifisch für Hardware ist, die getestet wird).
  • Das hierin beschriebene System und Verfahren beschränkt sich nicht auf die Verwendung von Tests. Das System kann immer dann verwendet werden, wenn eine Funktionsüberladung vorteilhaft ist, einschließlich aus Gründen der Lesbarkeit oder um Speicherplatz zu sparen, unter anderen Anwendungen.
  • Einige Ausführungsformen können ein Verfahren zum Überladen einer Funktion einschließen, wie in 21a gezeigt, wobei das Verfahren das Kompilieren eines ersten Bildes einer ersten Version der Funktion 2110, das Kompilieren eines zweiten Bildes einer zweiten Version der Funktion 2120 und das Generieren eines zusammengesetzten Super-Bildes durch Platzieren von Code, der die erste Version der Funktion definiert, und Code, der die zweite Version der Funktion definiert, in eine Speicherpartition umfasst, wobei der Code, der die zweite Version der Funktion definiert, dazu angepasst ist, nicht mit dem Code der ersten Version der Funktion zu kollidieren, und das Generieren einer Tabelle, die verwendet wird, um selektiv entweder die erste Version der Funktion oder die zweite Version der Funktion 2130 aufzurufen. In einigen Ausführungsformen werden die erste Version der Funktion und die zweite Version der Funktion in Code geschrieben, der das Überladen von Funktionen nicht zulässt. In einigen Ausführungsformen werden die erste Version der Funktion und die zweite Version der Funktion in C-Code geschrieben. In einigen Ausführungsformen befindet sich die Speicherpartition innerhalb eines Fahrzeugs. In einigen Ausführungsformen definiert die Tabelle eine jeweilige Speicheradresse für jede der ersten Version der Funktion und der zweiten Version der Funktion. In einigen Ausführungsformen umfasst das erste Bild der ersten Version der Funktion einen ersten Assembler-Code und das zweite Bild der zweiten Version der Funktion umfasst einen zweiten Assembler-Codierer. Einige Ausführungsformen umfassen ferner das Aufrufen jeder Version der Funktion in dem zusammengesetzten Super-Bild basierend auf der Tabelle.
  • Das Vorstehende dient lediglich der Veranschaulichung der Prinzipien dieser Offenbarung, und verschiedene Modifikationen können vom Fachmann vorgenommen werden, ohne vom Schutzumfang dieser Offenbarung abzuweichen. Die vorstehend beschriebenen Ausführungsformen werden zu Veranschaulichungszwecken und nicht einschränkend dargestellt. Die vorliegende Offenbarung kann auch viele andere Formen annehmen als die hierin ausdrücklich beschriebenen. Dementsprechend wird betont, dass diese Offenbarung nicht auf die explizit offenbarten Verfahren, Systeme und Vorrichtungen beschränkt ist, sondern Variationen und Modifikationen davon einschließen soll, die innerhalb des Geistes der folgenden Abschnitte liegen.
  • 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 63240190 [0001]

Claims (20)

  1. Verfahren zum Speichern von Informationen über ein Fahrzeug, wobei das Verfahren umfasst: Erkennen eines Fehlerereignisses durch Verarbeitungsschaltlogik und, als Reaktion auf das Erkennen: Generieren, durch die Verarbeitungsschaltlogik, der Informationen über das Fahrzeug zu einem Zeitpunkt des Fehlerereignisses, Generieren, durch die Verarbeitungsschaltlogik, von Integritätsdaten basierend auf den Informationen, Bewirken, dass durch die Verarbeitungsschaltlogik die Informationen über das Fahrzeug und die Integritätsdaten in einem Abschnitt des flüchtigen Speichers gespeichert werden, wobei der Abschnitt des flüchtigen Speichers dazu konfiguriert ist, gespeicherte Daten während eines Neustarts eines Betriebssystems des Fahrzeugs zu halten, Bewirken, unter Verwendung der Verarbeitungsschaltlogik, dass das Betriebssystem des Fahrzeugs neu gestartet wird, nach dem Neustart, Validieren, unter Verwendung der Verarbeitungsschaltlogik, der im flüchtigen Speicher gespeicherten Informationen basierend auf den Integritätsdaten und, als Reaktion auf das Validieren, Bewirken, dass die Informationen über das Fahrzeug im nichtflüchtigen Speicher gespeichert werden.
  2. Verfahren nach Anspruch 1, wobei die Integritätsdaten eine zyklische Redundanzprüfung (CRC) umfassen.
  3. Verfahren nach Anspruch 1, wobei der flüchtige Speicher einen Direktzugriffsspeicher (RAM) umfasst.
  4. Verfahren nach Anspruch 1, wobei der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers ist, der für die Informationen und die Integritätsdaten reserviert ist.
  5. Verfahren nach Anspruch 1, wobei das Erkennen des Fehlerereignisses das Erkennen eines Systemabsturzes umfasst.
  6. In einigen Ausführungsformen umfassen die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug.
  7. Verfahren nach Anspruch 1, wobei das Generieren der Informationen, Generieren der Integritätsdaten und Bewirken, dass die Informationen und die Integritätsdaten gespeichert werden, durch einen Notfall-Stapel durchgeführt wird, der dazu programmiert ist, im Falle des Fehlerereignisses ausgeführt zu werden.
  8. System zum Speichern von Informationen über ein Fahrzeug, wobei das System umfasst: flüchtigen Speicher, nichtflüchtigen Speicher, Verarbeitungsschaltlogik, die mit dem flüchtigen Speicher und dem nichtflüchtigen Speicher gekoppelt und konfiguriert ist zum: Erkennen eines Fehlerereignisses und als Reaktion auf das Erkennen: Generieren der Informationen über das Fahrzeug zu einem Zeitpunkt des Fehlerereignisses, Generieren von Integritätsdaten basierend auf den Informationen, Bewirken, dass die Informationen über das Fahrzeug und die Integritätsdaten in einem Abschnitt des flüchtigen Speichers gespeichert werden, wobei der Abschnitt des flüchtigen Speichers dazu konfiguriert ist, gespeicherte Daten während eines Neustarts eines Betriebssystems des Fahrzeugs zu halten, und Bewirken, dass das Betriebssystem des Fahrzeugs neu gestartet wird, nach dem Neustart, Validieren der im flüchtigen Speicher gespeicherten Informationen basierend auf den Integritätsdaten und, als Reaktion auf das Validieren, Bewirken, dass die Informationen über das Fahrzeug in dem nichtflüchtigen Speicher gespeichert werden.
  9. System nach Anspruch 8, wobei die Integritätsdaten eine zyklische Redundanzprüfung (CRC) umfassen.
  10. System nach Anspruch 8, wobei der flüchtige Speicher einen Direktzugriffsspeicher (RAM) umfasst.
  11. System nach Anspruch 8, wobei der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers ist, der für die Informationen und die Integritätsdaten reserviert ist.
  12. System nach Anspruch 8, wobei das Erkennen des Fehlerereignisses das Erkennen eines Systemabsturzes umfasst.
  13. System nach Anspruch 8, wobei die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug umfassen.
  14. System nach Anspruch 8, wobei das Generieren der Informationen, das Generieren der Integritätsdaten und das Bewirken, dass die Informationen und die Integritätsdaten gespeichert werden, durch einen Notfall-Stapel durchgeführt werden, der dazu programmiert ist, im Falle des Fehlerereignisses ausgeführt zu werden.
  15. Nicht-transitorisches computerlesbares Medium mit nichtflüchtigen computerlesbaren darauf codierten Anweisungen, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen zum: Erkennen eines Fehlerereignisses durch Verarbeitungsschaltlogik und, als Reaktion auf das Erkennen: Generieren der Informationen über das Fahrzeug durch die Verarbeitungsschaltlogik zu einem Zeitpunkt des Fehlerereignisses, Generieren, durch die Verarbeitungsschaltlogik, von Integritätsdaten basierend auf den Informationen, Bewirken, dass durch die Verarbeitungsschaltlogik die Informationen über das Fahrzeug und die Integritätsdaten in einem Abschnitt des flüchtigen Speichers gespeichert werden, wobei der Abschnitt des flüchtigen Speichers dazu konfiguriert ist, gespeicherte Daten während eines Neustarts eines Betriebssystems des Fahrzeugs zu halten, Bewirken, unter Verwendung der Verarbeitungsschaltlogik, dass das Betriebssystem des Fahrzeugs neu gestartet wird, nach dem Neustart, Validieren, unter Verwendung der Verarbeitungsschaltlogik, der im flüchtigen Speicher gespeicherten Informationen basierend auf den Integritätsdaten und, als Reaktion auf das Validieren, Bewirken, dass die Informationen über das Fahrzeug im nichtflüchtigen Speicher gespeichert werden.
  16. Computerlesbares Medium nach Anspruch 15, wobei die Integritätsdaten eine zyklische Redundanzprüfung (CRC) umfassen.
  17. Computerlesbares Medium nach Anspruch 15, wobei der flüchtige Speicher einen Direktzugriffsspeicher (RAM) umfasst.
  18. Computerlesbares Medium nach Anspruch 15, wobei der Abschnitt des flüchtigen Speichers ein fest zugeordneter Abschnitt des flüchtigen Speichers ist, der für die Informationen und die Integritätsdaten reserviert ist.
  19. Computerlesbares Medium nach Anspruch 15, wobei das Bewirken, dass der Prozessor das Fehlerereignis erkennt, das Erkennen eines Systemabsturzes umfasst.
  20. Computerlesbares Medium nach Anspruch 15, wobei die Informationen einen Schnappschuss eines Zustands der Software im Fahrzeug umfassen.
DE102022122167.9A 2021-09-02 2022-09-01 Verfahren zur ecu-echtzeit-absturzmeldung und wiederherstellung Pending DE102022122167A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202163240190P 2021-09-02 2021-09-02
US63/240,190 2021-09-02
US17/567,062 US11398117B1 (en) 2021-09-02 2021-12-31 Method for real-time ECU crash reporting and recovery
US17/567,062 2021-12-31

Publications (1)

Publication Number Publication Date
DE102022122167A1 true DE102022122167A1 (de) 2023-03-02

Family

ID=82483975

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022122167.9A Pending DE102022122167A1 (de) 2021-09-02 2022-09-01 Verfahren zur ecu-echtzeit-absturzmeldung und wiederherstellung

Country Status (3)

Country Link
US (2) US11398117B1 (de)
CN (1) CN115756908A (de)
DE (1) DE102022122167A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11934812B2 (en) * 2021-09-02 2024-03-19 Rivian Ip Holdings, Llc On-target unit testing
US11734156B2 (en) * 2021-09-23 2023-08-22 Microsoft Technology Licensing, Llc Crash localization using crash frame sequence labelling
CN115933584B (zh) * 2022-10-27 2024-06-11 重庆赛力斯凤凰智创科技有限公司 一种车载控制器测试系统、方法、计算机设备和存储介质
CN116795584B (zh) * 2023-08-28 2023-11-17 上海鉴智其迹科技有限公司 一种校验方法、装置、电子设备及存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170111353A (ko) * 2016-03-28 2017-10-12 에스케이하이닉스 주식회사 비휘발성 메모리 모듈의 커맨드 어드레스 스누핑
US20210118054A1 (en) * 2016-12-01 2021-04-22 Trovata, Inc. Resource exchange system
US10289421B2 (en) * 2017-02-17 2019-05-14 Dell Products, L.P. Booting of IHS from SSD using PCIe
CN207529370U (zh) * 2017-11-30 2018-06-22 比亚迪股份有限公司 故障信息存储系统
US11173921B2 (en) * 2018-11-19 2021-11-16 Micron Technology, Inc. Sensor fusion to determine reliability of autonomous vehicle operation
US11188407B1 (en) * 2019-05-15 2021-11-30 Amazon Technologies, Inc. Obtaining computer crash analysis data
FR3106677B1 (fr) * 2020-01-23 2022-07-22 Continental Automotive Procédé de mise à jour d’une liste d’instructions d’amorçage d’une unité de contrôle électronique
CN113302614B (zh) * 2021-04-25 2023-02-03 华为技术有限公司 数据管理方法、装置和终端设备

Also Published As

Publication number Publication date
CN115756908A (zh) 2023-03-07
US11398117B1 (en) 2022-07-26
US20230071884A1 (en) 2023-03-09

Similar Documents

Publication Publication Date Title
US11422794B2 (en) Using data deltas in controllers and managing interdependencies between software versions in controllers using tool chain
DE102022122167A1 (de) Verfahren zur ecu-echtzeit-absturzmeldung und wiederherstellung
DE102022122064A1 (de) System und verfahren für verbesserte ecu-ausfallerkennung in fahrzeugflotte
CN111385191A (zh) 车载互联网关、车辆ota升级系统和方法、计算机存储介质
DE112020005928T5 (de) Masteragent und verteilte Agentenarchitektur für Fahrzeuge
DE102022122188A1 (de) System und verfahren zum ermöglichen persistenter fahrzeugsoftwareschnittstellen
DE102022122162A1 (de) Eingebettete systemzeiterfassung bei automobilen
DE102022122159A1 (de) Verbessertes gezieltes komponententesten
DE102022120276A1 (de) Austausch von flüchtigen schlüsseln zwischen fahrzeugsoftwareknoten
DE102022122160A1 (de) E2e-synchronisation
CN116418832A (zh) 用于在车辆车队中进行增强ecu失效检测的系统和方法

Legal Events

Date Code Title Description
R012 Request for examination validly filed