-
Die Erfindung betrifft ein Verfahren zur Fehlerhandhabung bei einem Informationsaustausch zwischen wenigstens einer Steuereinrichtung eines Fahrzeugs und einem Backend-Service eines Fahrzeug-Backends des Fahrzeugs gemäß dem Oberbegriff von Patentanspruch 1.
-
Die heutigen Fahrzeuge beinhalten zahlreiche vernetzte Steuereinrichtungen beziehungsweise Steuergeräte (engl.) „Electronic Control Unit“ (ECU), die Information, Datensätze beziehungsweise Daten von einem Fahrzeug-Backend über ein Backend-Service beziehen oder an diese übermitteln. Diese Kommunikation beziehungsweise dieser Informations-/ Datenverkehr ermöglicht unter anderem Funktionalitäten wie das Beziehen von Live-Verkehrsdaten oder die Bereitstellung von Software-Updates für die Steuereinrichtungen, insbesondere kabellos (engl.) „Over-the-Air“. Hierbei kommuniziert eine Steuereinrichtung in der Regel nicht direkt mit einem Backend-Service im Fahrzeug-Backend, sondern über eine zentrale Telekommunikationseinheit (engl.) „Telematics Control Unit“ (TCU), die beispielsweise über ein Mobilfunkmodul oder weitere Datenübermittlungseinrichtungen verfügt. Im Fahrzeug-Backend selbst wird die Nachricht von einem zentralen Gateway empfangen, welches die Fahrzeug-Nachrichten dann an das eigentliche Backend-Service weiterleitet. Das heißt, zwischen Steuereinrichtung und das Backend-Service wird keine direkte Punkt-zu-Punkt-Verbindung aufgebaut; die Kommunikation erfolgt stattdessen über mehrere Endpunkte.
-
Die TCU stellt zwar eine abgesicherte Verbindung zum Fahrzeug-Backend sicher, aber die eingesetzten Protokolle garantieren keine Zustellung der Nachrichten, zumindest nicht auf applikativer Ebene. Zudem ist eine Absicherung der Zustellung von Nachrichten auf Transportebene über mehrere Endpunkte und Systemgrenzen hinweg nicht möglich. So kann es gemäß dem heutigen Stand der Technik dazu kommen, dass einzelne Nachrichten auf dem Kommunikationsweg verloren gehen. Die ECU beziehungsweise die Steuereinrichtungen haben keine Information darüber, ob die Nachricht an das Backend-Service erfolgreich zugestellt wurde und können somit im Falle einer fehlenden Zustellung gegebenenfalls die Nachricht erneut übermitteln.
-
Aus der
US 2013/0013676 A1 sind beispielsweise bereits ein Verfahren und ein System zur Bereitstellung einer kontinuierlichen interaktiven Kommunikation zwischen Geräten in einem elektronischen Netzwerk offenbart. Es wird ein Nachrichtenspeicher bereitgestellt, der es ermöglicht, Nachrichten zu speichern, während der Client offline oder anderweitig nicht verfügbar ist. Das Verfahren und System kann mit jedem adressierbaren Gerät im elektronischen Netzwerk betrieben werden. Das Kommunikationsverfahren und -system verwenden eine grafische Benutzeroberfläche, um die Anwendungen, die zur Interaktion mit dem elektronischen Netzwerk verwendet werden, virtuell darzustellen. Diese grafischen Darstellungen werden verwendet, um das Senden und Empfangen von Nachrichten über das elektronische Netz zu erleichtern. Die Anwendungen sind entsprechend ihrer zunehmenden Leistungsfähigkeit und Spezifizierung in verschiedene Ebenen unterteilt.
-
Es ist somit nicht neu, dass immer mehr vernetzte Fahrzeug-Funktionalitäten eine abgesicherte Kommunikation mit dem Fahrzeug-Backend beziehungsweise mit einem konkreten Service im Fahrzeug-Backend erfordern. Unter einer abgesicherten Kommunikation ist in diesem Fall zu verstehen, dass es nicht akzeptabel ist, wenn einzelne Nachrichten auf dem Kommunikationsweg verloren gehen. Die Steuereinrichtung muss dabei eindeutig feststellen können, ob die Nachricht an das Backend-Service zugestellt wurde oder nicht. Nur so ist eine Wiederholungsstrategie für einzelne Nachrichten aus Sicht der Steuereinrichtungen sicherzustellen. Das Backend-Service wiederum muss die Nachrichten eindeutig einer Steuereinrichtung zuordnen können. Zudem gilt zu beachten, dass die Anzahl der ausgetauschten Nachrichten zwischen einer Steuereinrichtung und dem Fahrzeug-Backend geringgehalten werden muss. Die Absicherung muss somit auf Applikationsebene erfolgen, da die Kommunikation über verschiedene Endpunkte erfolgt und damit eine Lösung auf Transportschicht nicht möglich ist.
-
Aufgabe der Erfindung ist es, ein Verfahren bereitzustellen, mittels welchem eine Absicherung insbesondere auf einer Applikationsebene bei einer Fehlerhandhabung bei einem Informationsaustausch zwischen wenigstens einer Steuereinrichtung und einem Backend-Service eines Fahrzeugs möglich ist.
-
Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 gelöst. Weitere vorteilhafte Ausgestaltungen sind aus den abhängigen Ansprüchen zu entnehmen.
-
Ein Aspekt der Erfindung betrifft ein Verfahren zur Fehlerhandhabung bei einem Informationsaustausch zwischen wenigstens einer Steuereinrichtung eines Fahrzeugs und einem Backend-Service eines Fahrzeug-Backends des Fahrzeugs. Hierbei werden Informationen, insbesondere Datenpakete und/oder Signale zwischen dem Fahrzeug-Backend und der wenigstens einen Steuereinrichtung übermittelt und empfangen, wobei das Backend-Service insbesondere als Übermittlungsprogramm angewendet wird. Durch den Informationsaustausch werden Funktionalitäten der Steuereinrichtung getriggert. Es ist ebenso möglich, sämtliche Informationen an verschiedene Steuereinrichtungen zur Steuerung verschiedener Funktionalität zu übermitteln, wobei die Übermittlungsstruktur beispielsweise mit einer Priorisierung versehen wird. Zur Fehlerhandhabung ist hierbei eine Vielzahl von Verfahrensschritte vorgesehen, wobei in einem ersten Verfahrensschritt ein Übermitteln wenigstens einer Information von der Steuereinrichtung an das Backend-Service durchgeführt wird. Eine solche Information ist beispielsweise mit der Anwendung einer Funktionalität verbunden. In einem weiteren Verfahrensschritt wird eine eindeutige Sicherstellung einer Zustellung der übermittelten Information durchgeführt, wodurch sowohl die Funktionalität beispielsweise gestartet und/oder protokolliert wird als auch die Information für weitere Informationsketten des Fahrzeug-Backends zur Verfügung steht. Schließlich wird in einem weiteren Verfahrensschritt eine eindeutige Zuordnung der Information an die Steuereinrichtung durch das Backend-Service durchgeführt, welche eine Durchführung einer Wiederholungsstrategie für den Informationsaustausch, der wenigstens eine Information, ermöglicht und wodurch beispielweise eine elektronische Verbindung bestätigt wird. Insbesondere wird die ursprüngliche Information nun in eine eindeutig zugeordnete Information umgewandelt, welche zusätzliche Information und/oder Daten über die zugeordnete Steuereinrichtung aufweist.
-
Um die Aufgabe der Erfindung zu lösen, ist es erfindungsgemäß vorgesehen, dass in einem weiteren Verfahrensschritt, die wenigstens eine zugeordnete Information der Steuereinrichtung um definierte Metadaten erweitert wird und dadurch eine eindeutige Anfrage-ID beziehungsweise Identifikationsinformation enthält, die zur Identifizierung der wenigstens einen zugeordneten Information auf Seite des Backend-Services und/oder auf Seite der Steuereinrichtung angewendet wird. In anderen Worten wird die ursprüngliche bereits zugeordnete Information mit einer weiteren Identifikationsinformation geprägt und wird für beide Enden des Informationsaustausches bereitgestellt. Somit ist eine besonders abgesicherte Kommunikation bereitgestellt, mittels welcher Informationen, Datenpakete oder einzelne Nachrichten auf dem Kommunikationsweg nicht verloren gehen. Die Steuereinrichtung kann dabei feststellen, ob die Nachricht dem Backend-Service zugestellt wurde oder nicht und dadurch ist auch die Wiederholungsstrategie für einzelne Nachrichten aus Sicht der Steuereinrichtungen sichergestellt. Dieses Verfahren beziehungsweise diese Absicherung ist insbesondere für die sonst nicht so sichere Applikationsebene vorteilhaft.
-
In einer vorteilhaften Ausgestaltung der Erfindung ist es vorgesehen, dass nach Empfangen der übermittelten Information mittels des Backend-Services eine Bestätigungsinformation an die Steuereinrichtung übermittelt wird, wodurch die Kommunikation bestätigt wird. Dadurch sind die beiden Enden des Informationsaustausches in der Lage, in einem vorgegebenen Zeitraum die notwendigen Informationen mit einer hohen Wahrscheinlichkeit erfolgreich zu übermitteln.
-
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist es vorgesehen, dass die Bestätigungsinformation eine eindeutige Kennziffer zum Identifizieren der Steuereinrichtung hinzugefügt wird, wodurch auch hier eine höhere und eindeutige Sicherheit des Empfangens der richtigen Information bereitgestellt wird.
-
Weiterhin vorteilhaft hat sich eine Ausgestaltung der Erfindung erwiesen, in welcher der Bestätigungsinformation dieselbe Anfrage-ID der Steuereinrichtung hinzugefügt wird. Insbesondere wird hierbei eine eindeutige Zuweisung sämtlicher Informationen mit der Anfrage-ID erweitert und für weitere Vorgehensschritte gruppiert und/oder geprägt.
-
Ebenso vorteilhaft ist eine Ausgestaltung der Erfindung, in welcher der Bestätigungsinformation weitere Datenpakete und/oder Informationen für die Steuereinrichtung hinzugefügt werden. Dadurch werden nicht nur weitere Informationen übermittelt, sondern die Übertragungsleistung gesteigert, da bei der ersten Übermittlung bereits Informationen fließen, die später nicht nochmal versendet werden müssen und eine neue Verbindung benötigen (engl. „Piggybacking“). Dies ist jedoch beispielsweise durch die Leistung des Breitbandanschlusses begrenzt, wodurch insbesondere wichtige Identifikationsinformationen priorisiert sind.
-
Schließlich ist es in einer vorteilhaften Ausgestaltung der Erfindung vorgesehen, dass bei Nichterhalt der Bestätigungsinformation durch die Steuereinrichtung die Wiederholungsstrategie angewendet wird und die ursprüngliche Information erneut an das Backend-Service gesendet wird. Insbesondere ist hierbei eine Wiederholung der Übermittlung möglich, als auch eine Protokollierung von Fehlschlägen und somit eine Weiterentwicklung oder eine Fehlermeldung durchführbar.
-
Insbesondere ist es vorgesehen, dass der initiale Datenversand zur Realisierung entsprechender Funktionalitäten vom Backend aus an das Fahrzeug erfolgt. Der Gesamtablauf entspricht in der Regel einem (engl.) „Request/Response-Pattern“, bei dem das Backend dem Fahrzeug ein Datenpaket sendet, ein Beispiel für (engl.) „Request“ wäre ein Befehl zur Verriegelung des Fahrzeugs und das Fahrzeug die erfolgreiche Verarbeitung des Datenpakets anschließend bestätigt, ein Beispiel für (engl.) „Response“ wäre eine Bestätigung: „Fahrzeug erfolgreich verriegelt“. Diese Funktionalitäten initiiert der Kunde nicht im/am Fahrzeug selbst, sondern über eine Remote-Schnittstelle, wie zum Beispiel eine Smartphone-App, entsprechend (engl.) „offboard“. Ebenso ist der initiale Datenversand auch in die andere Richtung möglich, nämlich vom Fahrzeug an das Backend, insbesondere onboard-getriggert. Durch die anschließende Bestätigungsnachricht vom Backend an Fahrzeug kann sichergestellt werden, dass das Backend die Fahrzeuginformation, zum Beispiel Entriegelung, Zündungswechsel, Alarm der Alarmanlage, erhalten hat.
-
Weitere Vorteile, Merkmale und Einzelheiten der Erfindung ergeben sich aus der nachfolgenden Beschreibung eines bevorzugten Ausführungsbeispiels sowie anhand der Zeichnung. Die vorstehend in der Beschreibung genannten Merkmale und Merkmalskombinationen sowie die nachfolgend in der Figurenbeschreibung genannten und/oder in der einzigen Figur alleine gezeigten Merkmale und Merkmalskombinationen sind nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar, ohne den Rahmen der Erfindung zu verlassen.
-
Dabei zeigt die einzige Figur (Fig.) ein Bilddiagramm zur Darstellung des erfindungsgemäßen Verfahrens.
-
In den Figuren sich gleiche und funktionsgleiche Elemente mit den gleichen Bezugszeichen versehen.
-
Die einzige Figur (Fig.) zeigt ein Bilddiagramm zur Darstellung eines Verfahrens zur Fehlerhandhabung bei einem Informationsaustausch zwischen wenigstens einer Steuereinrichtung 12 eines Fahrzeugs 16 und ein Backend-Service 14 eines Fahrzeug-Backends des Fahrzeugs 16.
-
In einem ersten Verfahrensschritt wird ein Übermitteln wenigstens einer Information 10 von der Steuereinrichtung 12 an das Backend-Service 14 durchgeführt, in einem zweiten Verfahrensschritt wird eine eindeutige Sicherstellung einer Zustellung der übermittelten Information 10 durchgeführt. Dies wird über die Bestätigungsinformation 18 und eine entsprechende Wiederholstrategie beim Ausbleiben der Bestätigungsinformation 18 sichergestellt. Es ist zudem möglich, dass nach Empfangen der übermittelten Information 10 mittels des Backend-Services 14 eine Bestätigungsinformation 18 an die Steuereinrichtung 12 übermittelt wird. In einem anschließenden dritten Verfahrensschritt wird eine eindeutige Zuordnung der Information 10 an die Steuereinrichtung 12 durch das Backend-Service 14 durchgeführt, wodurch eine zugeordnete Information 10a bereitgestellt wird.
-
In einem weiteren vierten Verfahrensschritt wird die wenigstens eine zugeordnete Information 10a der Steuereinrichtung 12 um definierte Metadaten erweitert und enthält dadurch eine eindeutige Anfrage-ID ID, die zur Identifizierung der wenigstens einen zugeordneten Information 10a auf Seite des Backend-Services 14 und/oder auf Seite der Steuereinrichtung 12 angewendet wird. Ebenso ist es möglich, dass die Bestätigungsinformation 18 eine eindeutige Kennziffer zum Identifizieren der Steuereinrichtung 12 hinzugefügt wird und dass der Bestätigungsinformation 18 dieselbe Anfrage-ID ID der Steuereinrichtung 12 hinzugefügt wird. Alternativ kann der Bestätigungsinformation 18 weitere Datenpakete und/oder Informationen für die Steuereinrichtung 12 hinzugefügt werden. Schließlich kann zu Absicherung bei Nichterhalt der Bestätigungsinformation 18 durch die Steuereinrichtung 12 die Wiederholungsstrategie angewendet und die ursprüngliche Information 10 erneut an das Backend-Service 14 gesendet werden.
-
Die heutigen Fahrzeuge 16 beinhalten zahlreiche vernetzte Steuereinrichtungen 12 beziehungsweise ECU die Information, Datensätze beziehungsweise Daten von einem Fahrzeug-Backend über ein Backend-Service 14 beziehen oder an diese übermitteln. Diese Kommunikation beziehungsweise dieser Informations-/ Datenverkehr ermöglicht unter anderem Funktionalitäten wie das Beziehen von Live-Verkehrsdaten oder die Bereitstellung von Software-Updates für die Steuereinrichtungen 12, insbesondere kabellos (engl.) „Over-the-Air“. Hierbei kommuniziert eine Steuereinrichtung 12 in der Regel nicht direkt mit dem Backend-Service 14 im Fahrzeug-Backend, sondern über eine zentrale Telekommunikationseinheit, die beispielsweise über ein Mobilfunkmodul oder weitere Datenübermittlungseinrichtungen verfügt. Im Fahrzeug-Backend selbst wird die Nachricht von einem zentralen Gateway 13 empfangen, welches die Fahrzeug-Nachrichten dann an das eigentliche Ziel-Service des Backend-Services 14 weiterleitet. Das heißt, zwischen Steuereinrichtung 12 und Ziel-Service wird keine direkte Punkt-zu-Punkt-Verbindung aufgebaut, die Kommunikation erfolgt stattdessen über mehrere Endpunkte.
-
Die einzige Figur (Fig.) zeigt hierbei in Kästen von links nach rechts verschiedene Punkte des Informationsaustausches, wobei zunächst die ECU oder eine Steuereinrichtung 12 des Fahrzeugs 16 dargestellt wird. Darauffolgend wird die zentrale Telekommunikationseinheit TCU in nächsten Kasten dargestellt, die beispielweise über ein Mobilfunkmodul 30 verfügt. Ebenfalls darauffolgend wird im dritten Kasten ein Gateway 13 des Fahrzeug-Backends dargestellt und im letzten Kasten das Backend-Service 14 als ein Ende des Informationsaustausches.
-
So wird eine Anforderung REQ aus der ECU an das Backend-Service gesendet, welche an jedem Punkt des Informationsaustausches ankommt und weiter übermittelt wird. Das Backend-Service 14 sendet eine Anforderungsantwort RESP, welche auch die Bestätigungsinformation 18 ist. Insbesondere wird hierbei für den Informationsaustausch ein „Request/Response-Pattern“ angewendet, welches Anforderungen REQ und Anforderungsantworten RESP in jeweilige Richtungen übermittelt. Zur Darstellung der Anforderung REQ und der Anforderungsantwort RESP sind diese strukturell dargestellt. Beide weisen Bytes auf, wobei Byte 1 mit B1, Byte 2 mit B2, Byte 3 mit B3, Byte 4 mit B4, Byte 5 mit B5, Byte 6 mit B6 und weitere Bytes mit BN dargestellt sind.
-
Die Anforderung REQ und somit die Nachricht der ECU, beispielweise „REQUEST_EVENT_ECU1“, wird um Byte 1 B1 und Byte 2 B2 ergänzt. In anderen Worten wird in der Anforderung REQ dem ersten Byte 1 B1 die eindeutige Kennziffer der Steuereinrichtung 12 zugewiesen und trägt somit die Information der ECU. Byte 2 B2 trägt die Anfrage-ID ID und somit die Identifizierung der Nachricht und Byte 3 B3 eine Länge des eigentlichen Datensatzes, welche insbesondere variabel ist. Die weiteren Bytes 4-N B4, B5, B6, BN tragen weitere Nutzdaten N (engl.) „payload“.
-
Ähnlich wie bei der Anforderung REQ ist die Anforderungsantwort RESP aufgebaut. Das Backend-Service 14 im Fahrzeug-Backend quittiert die Nachricht, indem es eine Bestätigungsinformation 18 beziehungsweise ein „ACK“ (engl.) „Acknowledge“ sowie die Kennziffer der ECU beziehungsweise der Steuereinrichtung 12 und die ursprüngliche Anfrage-ID ID in der Bestätigungs-Nachricht, beispielweise „RESPONSE_EVENT_ECU1_ACK“, beziehungsweise in der Anforderungsantwort RESP an die Steuereinrichtung 12 mitsendet. Hierbei trägt Byte 1 B1 die eindeutige Kennziffer ECU der Steuereinrichtung 12 und Byte 2 B2 die Anfrage-ID ID, welche die eindeutige Identifikation der zu bestätigenden Anforderung REQ ist. Byte 3 B3 trägt das ACK, nämlich die eindeutige Kennziffer zur Identifizierung einer Bestätigungsinformation 18 in der Nachricht.
-
Bezugszeichenliste
-
- 10
- Information
- 10a
- zugewiesene Information
- 12
- Steuereinrichtung
- 13
- Gateway
- 14
- Backend-Service
- 16
- Fahrzeug
- 18
- Bestätigungsinformation
- ID
- Anfrage-ID
- B1-BN
- Bytes
- REQ
- Anforderung
- RESP
- Anforderungsantwort
- ECU
- Motorsteuerung
- TCU
- Telekommunikationseinheit
- AKC
- Acknowledge
- D
- Nutzdaten
-
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 2013/0013676 A1 [0004]
