DE102022124470B3

DE102022124470B3 - Verfahren zur Steuerung einer Diagnosesession eines Fahrzeugs, Computerprogram, Vorrichtung und Fahrzeug

Info

Publication number: DE102022124470B3
Application number: DE102022124470.9A
Authority: DE
Inventors: Tobias Heinemann; Christoph Wierer; Bernhard Sass; Bernd Brandl; Ibrahim Ghalawinji
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2022-09-23
Filing date: 2022-09-23
Publication date: 2023-07-27
Anticipated expiration: 2042-09-24
Also published as: WO2024061477A1

Abstract

Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Verfahren 100 zur Steuerung einer Diagnosesession eines Fahrzeugs. Das Verfahren 100 umfasst Senden 110, an einen Server, eines Bereitschaftssignals indikativ für eine Bereitschaft für die Diagnosesession. Außerdem umfasst das Verfahren 100 zumindest eines von Empfangen 120, von dem Server, eines ersten zyklischen Heartbeatsignals oder Senden 120, an den Server, eines zweiten zyklischen Heartbeatsignals. Ferner umfasst das Verfahren 100 Initialisieren 130 einer Diagnosesession basierend auf dem ersten zyklischen Heartbeatsignal und/oder dem zweiten zyklischen Heartbeatsignal.

Description

Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf Verfahren zur Steuerung einer Diagnosesession für eines Fahrzeugs, ein Computerprogram, eine Vorrichtung und ein Fahrzeug, insbesondere aber nicht ausschließlich auf ein Konzept zum Initialisieren einer Diagnosesession basierend auf einem ersten zyklischen Heartbeatsignal und/oder einem zweiten zyklischen Heartbeatsignal.
Bei einer Überwachung eines Fahrzeugs, bzw. einer Diagnose eines Fahrzeugs findet eine Informationsübertragung zwischen dem Fahrzeug und einem Server, z. B. einem Backend, statt. Auf Grundlage dieser Informationsübertragung kann ein Status eines Fahrzeugs überwacht werden. Beispielsweise kann eine Fehlersuche oder Fehlerbehebung im Fahrzeug aus der Ferne durch den Server gewährleistet werden. Die Bestimmung eines Zeitpunkts der Überwachung oder ein Ablauf der Überwachung kann hierbei von einer Vielzahl an Parameter abhängen. Dadurch kann eine Initialisierung oder eine Durchführung einer Überwachung erschwert werden.
US 2020 / 0 226 852 A1 offenbart ein Verfahren zur Fernüberwachung umfassend Senden einer Verbindungsanfrage, Senden von Heartbeatdaten und Bestimmen, basierend auf den Heartbeatdaten, ob eine Verbindung unterbrochen wird.
Es besteht daher ein Bedarf ein verbessertes Verfahren zur Steuerung einer Diagnosesession eines Fahrzeugs zu Verfügung zu stellen. Diesem Bedarf tragen die Verfahren, die Vorrichtung, das Computerprogram, sowie das Fahrzeug nach dem unabhängigen Ansprüchen Rechnung.
Ausführungsbeispiele basieren auf dem Kerngedanken, dass ein Verfahren zur Steuerung einer Diagnosesession eines Fahrzeugs basierend auf einem ersten zyklischen Heartbeatsignal und/oder einem zweiten zyklischen Heartbeatsignal initialisiert werden kann. Dadurch kann beispielsweise ein Zeitpunkt für die Initialisierung der Diagnosesession bestimmt werden. Der Zeitpunkt kann z. B. von einem Status des Fahrzeugs, einem Standort des Fahrzeugs, einer Anwesenheit eines Nutzers abhängig sein.
Ausführungsbeispiele betreffen ein Verfahren zur Steuerung einer Diagnosesession eines Fahrzeugs. Das Verfahren kann insbesondere durch ein Fahrzeugendgerät durchgeführt werden. Das Verfahren umfasst Senden, an einen Server, eines Bereitschaftssignals indikativ für eine Bereitschaft für die Diagnosesession. Außerdem umfasst das Verfahren zumindest eines von Empfangen, von dem Server, eines ersten zyklischen Heartbeatsignals oder Senden, an den Server, eines zweiten zyklischen Heartbeatsignals. Ferner umfasst das Verfahren Initialisieren einer Diagnosesession basierend auf dem ersten zyklischen Heartbeatsignal und/oder dem zweiten zyklischen Heartbeatsignal. Durch das Empfangen/Senden des ersten/zweiten zyklischen Heartbeatsignals kann eine Information über eine Möglichkeit einer Initialisierung einer Diagnosesession durch den/das Server/Fahrzeugendgerät übertragen werden. Dadurch kann eine Initialisierung der Diagnosesession verbessert werden. Insbesondere kann die Initialisierung der Diagnosesession dann erfolgen, wenn sowohl der Server als auch das Fahrzeugendgerät eine Durchführung einer Diagnosesession ermöglichen können.
In einem Ausführungsbeispiel kann das erste zyklische Heartbeatsignal und das zweite zyklische Heartbeatsignal indikativ für einen Parameter der Diagnosesession sein. Das erste/zweite zyklische Heartbeatsignal kann also zur Übertragung von Parameter der Diagnosesession genutzt werden. Dadurch kann eine Informationsübertragung während der Diagnosesession vereinfacht werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Beenden der Diagnosesession, wenn weder das erste zyklische Heartbeatsignal empfangen noch das zweite zyklische Heartbeatsignal gesendet werden kann. Durch das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann eine Unterbrechung in der Diagnosesession bestimmt werden. Dadurch kann eine Diagnosesession, beispielsweise bei einer fehlerhaften Kommunikation zwischen dem Fahrzeugendgerät und dem Server, schneller beendet werden. Durch ein Beenden der Diagnosesession kann ein ursprünglicher Status des Fahrzeugs wieder hergestellt werden, wodurch die Sicherheit (z. B., eine Cybersicherheit einer Firewall, eine Betriebssicherheit einer Diagnosesession) erhöht werden kann.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Ändern einer Firewalleinstellung während einer Durchführung der Diagnosesession. Durch die Änderung der Firewalleinstellung kann eine Kommunikation zwischen der Fahrzeugendgerät und dem Server vereinfacht werden und/oder eine Möglichkeit Diagnoseschritte durchzuführen verbessert werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Bestimmen eines Status des Fahrzeugs und Beenden der Diagnosesession basierend auf dem bestimmten Status des Fahrzeugs. Beispielsweise kann ein Nutzer den Motor des Fahrzeugs starten, um wegzufahren. Durch das Wegfahren kann eine Verbindung zwischen dem Fahrzeugendgerät und dem Server verschlechtert werden. Dementsprechend könnte vorsorglich die Diagnosesession beendet werden, bevor diese unterbrochen wird. Dadurch kann eine Verlässlichkeit der Diagnosesession erhöht werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Erhalten zumindest eines Kriteriums von einer Anwesenheit eines Nutzers des Fahrzeugs, Erhalten einer Zustimmung des Nutzers und/oder Bestimmen eines Status des Fahrzeugs. Die Diagnosesession kann nur dann initialisiert werden, wenn zumindest eines der Kriterien erhalten wurde. Dadurch kann sichergestellt werden, dass eine Diagnosesession nur unter bestimmten Voraussetzungen gestartet werden kann, wodurch ein Missbrauch erschwert werden kann.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Erhalten von Umgebungsinformationen und/oder Positionsinformation. Das zweite zyklische Heartbeatsignal kann ferner indikativ für die Umgebungsinformation und/oder Positionsinformation sein. Dadurch kann der Server über Bedingungen für die Diagnosesession informiert werden. Beispielsweise kann für eine geplante Aktion ein Freiraum um das Fahrzeug benötigt werden. Durch das zweite zyklische Heartbeatsignal kann diese Information an den Server übermittelt, wodurch eine Diagnosesession verbessert werden kann, beispielsweise bestimmte Diagnoseschritte ermöglicht werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Empfangen, von dem Server, eines Anfragesignals indikativ für eine Anfrage einer Initialisierung der Diagnosesession. Ferner kann das Bereitschaftssignal ein Antwortsignal indikativ für eine Antwort auf das Anfragesignal sein. Dadurch kann ein Server aktiv eine beispielsweise benötigte Diagnosesession starten.
In einem Ausführungsbeispiel kann das erste zyklische Heartbeatsignal indikativ für ein Löschen eines Fahrzeugfehlerspeichers sein. Ferner kann das Verfahren umfassen Löschen eines Fahrzeugfehlerspeichers basierend auf dem ersten zyklischen Heartbeatsignal. Dadurch kann das Fahrzeug beispielsweise wieder in einen betriebsbereiten Status versetzt werden. Durch die Integration der Information in das erste zyklische Heartbeatsignal kann ein Datentransfer minimiert werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Bestimmen eines betriebsbereiten Status des Fahrzeugs und Senden eines finalen Heartbeatsignals des zweiten zyklischen Heartbeatsignals indikativ für den betriebsbereiten Status. Ferner kann das Verfahren umfassen Beenden der Diagnosesession. Dadurch kann das Fahrzeugendgerät nach einer erfolgreichen Diagnosesession, beispielsweise nach Behebung eines fehlerhaften Status des Fahrzeugs, die Diagnosesession beenden, wodurch ein weiterer Datentransfer vermieden werden kann.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Bestimmen eines Status des Fahrzeugs und Bestimmen einer verbleibenden Diagnosesessionzeit basierend auf dem Status des Fahrzeugs. Das zweite zyklische Heartbeatsignal kann ferner indikativ sein für die verbleibende Diagnosesessionzeit. Beispielsweise kann die Diagnosesessionzeit von einem Ladezustand einer Batterie des Fahrzeugs abhängen. Der Server kann darüber informiert werden, welche Diagnosesessionzeit noch zur Verfügung steht. Dadurch kann eine Steuerung der Diagnosesession verbessert werden, beispielsweise können noch durchzuführende Aufgaben dementsprechend geplant oder auf eine spätere Diagnosesession verschoben werden.
Ausführungsbeispiele betreffen ein Verfahren zur Steuerung einer Diagnosesession eines Fahrzeugs. Das Verfahren kann insbesondere durch einen Server, wie z. B. ein Backend, durchgeführt werden. Das Verfahren umfasst Empfangen, von einem Fahrzeugendgerät, eines Bereitschaftssignals indikativ für eine Bereitschaft für die Diagnosesession. Weiterhin umfasst das Verfahren Senden, an das Fahrzeugendgerät, eines ersten zyklischen Heartbeatsignals und/oder Empfangen, von dem Fahrzeugendgerät, eines zweiten zyklischen Heartbeatsignals. Ferner umfasst das Verfahren Initialisieren einer Diagnosesession basierend auf dem ersten zyklischen Heartbeatsignal und/oder dem zweiten zyklische Heartbeatsignal. Dadurch kann eine Initialisierung der Diagnosesession verbessert werden. Insbesondere kann die Initialisierung der Diagnosesession dann erfolgen, wenn sowohl der Server als auch das Fahrzeugendgerät eine Durchführung einer Diagnosesession ermöglichen können.
In einem Ausführungsbeispiel kann das erste zyklische Heartbeatsignal indikativ für eine Statusanfrage des Fahrzeugs und das zweite zyklische Heartbeatsignal indikativ für einen Status des Fahrzeugs sein. Ferner kann das Verfahren umfassen Bestimmen einer verbleibenden Diagnosesessionzeit basierend auf dem Status des Fahrzeugs. Dadurch kann eine Steuerung der Diagnosesession verbessert, beispielsweise können noch durchzuführende Aufgaben dementsprechend geplant oder auf eine spätere Diagnosesession verschoben werden.
Ausführungsbeispiele schaffen auch ein Computerprogramm zur Durchführung eines der hierin beschriebenen Verfahren, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft.
Ein weiteres Ausführungsbeispiel ist eine Vorrichtung zur Steuerung einer Diagnosesession eines Fahrzeugs. Die Vorrichtung umfasst eine Schnittstelle zur Kommunikation mit anderen Kommunikationseinrichtungen (z. B. dem Server oder einem Fahrzeugendgerät) und eine Datenverarbeitungsschaltung, die zur Durchführung zumindest eines der hierin beschriebenen Verfahren ausgebildet ist. Ausführungsbeispiele schaffen darüber hinaus ein Fahrzeug mit einer Vorrichtung wie hierin beschrieben.
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:

1 zeigt eine schematische Darstellung eines Verfahrens zur Steuerung einer Diagnosesession eines Fahrzeugs;
2 zeigt eine schematische Darstellung eines weiteren Verfahrens zur Steuerung einer Diagnosesession eines Fahrzeugs;
3 zeigt ein Flussdiagramm einer Diagnosesession; und
4 zeigt ein Blockdiagram eines Ausführungsbeispiels einer Vorrichtung zur Steuerung einer Diagnosesession eines Fahrzeugs.

Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein.
1 zeigt eine schematische Darstellung eines Verfahrens 100 zur Steuerung einer Diagnosesession eines Fahrzeugs. Das Verfahren 100 kann insbesondere durch ein Fahrzeugendgerät durchgeführt werden. Das Verfahren 100 umfasst Senden 110, an einen Server, eines Bereitschaftssignals indikativ für eine Bereitschaft für die Diagnosesession. Das Bereitschaftssignal kann von dem Fahrzeugendgerät gesendet werden, wenn eine Diagnosesession von Seiten des Fahrzeugs initialisiert werden kann.
Außerdem umfasst das Verfahren 100 Empfangen 120, von dem Server, eines ersten zyklischen Heartbeatsignals und/oder Senden, an den Server, eines zweiten zyklischen Heartbeatsignals. Das erste zyklische Heartbeatsignal kann insbesondere dazu dienen, dem Fahrzeug eine intakte Kommunikationsverbindung zum Server anzuzeigen. Das zweite zyklische Heartbeatsignal kann insbesondere dazu dienen, dem Server eine intakte Kommunikationsverbindung zum Fahrzeug anzuzeigen. Das erste/zweite zyklische Heartbeatsignal kann also eine Durchführung der Diagnosesession verbessern. Das Fahrzeug und/oder der Server können Informationen über die Verbindung zueinander erhalten. Das erste/zweite zyklische Heartbeatsignal kann beispielsweise ein periodisches Signal. Das erste zyklische Heartbeatsignal kann beispielsweise in zeitlichen Abständen von höchstens 80 s, oder 70 s, oder 60 s und/oder von mindestens 30 s, oder 40 s, oder 50 s empfangen werden. Das zweite zyklische Heartbeatsignal kann beispielsweise in zeitlichen Abständen von höchstens 80 s, oder 70 s, oder 60 s und/oder von mindestens 30 s, oder 40 s, oder 50 s gesendet werden. Alternativ kann das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal in kürzeren Abständen gesendet werden, beispielsweise höchstens alle 10s, oder 5s, oder 2s. Dies kann vorteilhaft sein, wenn ein erhöhter Bedarf an Informationsaustausch zwischen dem Fahrzeugendgerät und dem Server besteht. Beispielsweise können dadurch Änderungen des Status des Fahrzeugs schneller an den Server gesendet werden.
Ferner umfasst das Verfahren 100 Initialisieren 130 einer Diagnosesession basierend auf dem ersten zyklischen Heartbeatsignal und/oder dem zweiten zyklischen Heartbeatsignal. Die Diagnosesession kann sowohl von dem Fahrzeug als auch dem Server initialisiert werden. Insbesondere kann eine Initialisierung von Fahrzeug und Server zum Aufbau der Diagnosesession erforderlich sein.
Eine Diagnosesession kann insbesondere zur Überwachung, beispielsweise zur Wartung, des Fahrzeugs dienen. Beispielweise kann während der Diagnosesession ein Informationsaustausch zwischen dem Fahrzeugendgerät und dem Server zur Überwachung des Fahrzeugs, beispielweise eines Status des Fahrzeugs, stattfinden. Der Informationsaustausch kann hierbei von dem Fahrzeugendgerät zum Server erfolgen, beispielsweise um dem Server Information über das Fahrzeug zu übermitteln. Zusätzlich kann auch ein Informationsaustausch vom Server zum Fahrzeugendgerät erfolgen, beispielsweise um Steuerungsbefehle an das Fahrzeug zu senden.
Prinzipiell kann eine Diagnosesession in verschiedene Teil-Diagnosesession unterteilt sein. Die verschiedenen Teil-Diagnosesession können unterschiedliche Funktionalitäten zur Verfügung stellen. In einer ersten Teil-Diagnosesession kann beispielsweise nur ein Informationsaustausch vom Fahrzeugendgerät zum Server erfolgen. Die erste Teil-Diagnosesession kann also als read-only Diagnosesession betrachtet werden. Insbesondere können in einer read-only Diagnosesession eben lediglich Information vom Fahrzeugendgerät an den Server gesendet werden. Dadurch kann ein Informationsaustausch ermöglicht werden, ohne Parameter des Fahrzeugs oder des Fahrzeugendgeräts, beispielsweise eine Firewalleinstellung zu verändern. Eine Sicherheit des Fahrzeugendgeräts oder des Fahrzeugs kann daher von der read-only Diagnosesession nicht betroffen sein.
In einer zweiten Teil-Diagnosesession kann beispielsweise zusätzlich ein Informationsaustausch vom Server zum Fahrzeugendgerät erfolgen. Die zweite Teil-Diagnosesession kann also all full-access Diagnosesession betrachtet werden. Beispielsweise kann der Server einen Steuerungsbefehl an das Fahrzeugendgerät senden. Das Steuerungsbefehl kann von dem zweiten zyklischen Heartbeatsignal umfasst sein. Alternativ kann der Steuerungsbefehl von einem separaten Signal, beispielsweise einem Steuerungssignal, umfasst sein. Das Steuerungssignal kann nicht von dem ersten zyklischen Heartbeatsignal umfasst sein. Eine Funktionalität der Diagnosesession kann damit erhöht werden. Zur Durchführung einer full-access Diagnosesession kann es erforderlich sein, einen Parameter, beispielsweise eine Firewalleinstellung des Fahrzeugs oder des Fahrzeugendgeräts zu verändern, wodurch eine Sicherheit des Fahrzeugendgeräts oder des Fahrzeugs verringert werden kann.
Durch die Unterteilung in verschiedene Teil-Diagnosesessions kann eine Dauer in einem kritischen Status des Fahrzeugs, beispielsweise in einer full-access Diagnosesession, verringert werden. Beispielsweise kann für die Durchführung bestimmter Diagnoseschritte eine Änderung der Firewalleinstellung des Fahrzeugs und/oder des Fahrzeugendgeräts erforderlich sein. Dadurch kann eine Sicherheit, beispielsweise gegen Angriffe, verringert werden, weshalb diese Einstellung der Firewall möglichst nur zur Durchführung der bestimmten Diagnoseschritte aufrechterhalten werden sollte. Durch die Verwendung einer full-access Diagnosesession in Kombination mit einer read-only Diagnosesession kann eine Dauer eines sicherheitskritischen Status des Fahrzeugs minimiert werden. Beispielsweise kann in einer read-only Diagnosesession zuerst ein Erhalten von Information durch den Server stattfinden. Basierend auf den erhaltenen Informationen kann dann eine full-access Diagnosesession initialisiert werden. Dadurch kann eine Dauer des Fahrzeugs bzw. des Fahrzeugendgeräts in einer full-access Diagnosesession verringert werden, wodurch ein Energieverbrauch verringert werden, beispielsweise ein Energieverbrauch der Fahrzeugbatterie.
Mittels des ersten zyklischen Heartbeatsignals und/oder des zweiten zyklischen Heartbeatsignals kann eine Statusüberwachung des Fahrzeugs und/oder der Kommunikationsverbindung zwischen dem Fahrzeugendgerät und dem Server erfolgen. Das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann ein keepalive-Signal sein. Das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann indikativ dafür sein, dass die Diagnosesession durchgeführt werden kann. Solange das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal empfangen/gesendet werden kann, kann die Diagnosesession aufrechterhalten werden.
Der Informationsaustausch kann über das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal erfolgen. Das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann also die auszutauschenden Informationen umfassen. Beispielsweise kann das Fahrzeugendgerät eine Information über einen Status des Fahrzeugs mit dem zweiten zyklischen Heartbeatsignal an den Server senden. In einem Ausführungsbeispiel kann das Bereitschaftssignal von einem ersten Heartbeatsignal des zweiten zyklischen Heartbeatsignal umfasst sein oder dieses sein. Beispielsweise kann also die Bereitschaft für die Diagnosesession mittels des zweiten zyklischen Heartbeatsignals gesendet werden.
Mit dem ersten zyklischen Heartbeatsignal und/oder dem zweiten zyklischen Heartbeatsignal kann die Verbindung zwischen dem Fahrzeugendgerät und dem Server überwacht werden. Damit kann eine Diagnosesession, also beispielsweise ein Übertragen von Informationen zur Fehlersuche und Fehlerbehebung im Fahrzeug aus der Ferne gewährleistet werden. In anderen Systemen ist es nicht möglich eine unterbrochene Verbindung zwischen dem Fahrzeugendgerät und dem Server zu detektieren. Es kann lediglich durch das Abwarten (Timeout) einer Anfrage, wenn keine Antwort erfolgt, indirekt bestimmt werden, dass keine Verbindung existiert. Ein Verbindungszustand zwischen dem Fahrzeugendgerät und dem Fahrzeug kann hierbei aber nicht bestimmt werden. Durch die Verwendung des ersten zyklischen Heartbeatsignals und/oder des zweiten zyklischen Heartbeatsignals kann der Zustand der Verbindung zwischen dem Fahrzeugendgerät und dem Server bestimmt werden. Dadurch kann eine Steuerung der Diagnosesession für das Fahrzeug verbessert werden.
Das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann insbesondere während einer Dauer der Diagnosesession gesendet werden. Dadurch kann die Verbindung zwischen dem Fahrzeugendgerät und dem Server und optional gleichzeitig ein Status des Fahrzeugs überwacht werden. Durch das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann eine zyklische und/oder Event-getriggerte Überwachung des Status des Fahrzeugs durchgeführt werden. Ein Event kann eine Statusänderung des Fahrzeugs sein, beispielsweise ein Öffnen einer Tür, ein zu stark entladener Batteriezustand, eine Änderung eines Bewegungszustands des Fahrzeugs. Damit kann auf eine Statusänderung des Fahrzeugs reagiert werden. Beispielsweise kann eine Diagnosesession beendet werden, wenn eine Ansteuerung mit einem hohen Energieverbrauch vorliegt oder ein Bewegungszustand des Fahrzeugs geändert wird.
Im Allgemeinen kann ein Kommunikationsgerät, z. B. der Server und/oder das Fahrzeugendgerät, ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Das Fahrzeugendgerät kann beispielsweise ein Steuergerät des Fahrzeugs sein. Das Fahrzeugendgerät kann also in das Fahrzeug integriert sein. Alternativ kann das Fahrzeugendgerät ein Benutzerendgerät sein. Ein Benutzerendgerät kann dazu geeignet sein, von einem Nutzer getragen zu werden. Beispielsweise kann das Benutzerendgerät ein Smartphone, eine Smartwatch, ein Virtual-Reality-Headset sein. Auf dem Benutzerendgerät kann eine Software installiert sein, beispielsweise eine Software eines Herstellers des Fahrzeugs, die eine Kommunikation mit dem Fahrzeug ermöglicht. Das Benutzerendgerät kann von dem Fahrzeug Daten betreffend einer Diagnosesession empfangen und diese an den Server weiterleiten bzw. vom Server empfangen und an das Fahrzeug weiterleiten. Das Benutzerendgerät kann also beispielsweise wie ein Relay agieren. Dadurch kann eine Kommunikationsverbindung zwischen dem Fahrzeugendgerät und dem Server zur Steuerung der Diagnosesession des Fahrzeugs verwendet werden. Beispielsweise kann das Fahrzeugendgerät dazu konfiguriert sein, einen Zugang zu dem Fahrzeug zu ermöglichen, z. B. kann das Fahrzeugendgerät als smart key konfiguriert sein. Dadurch kann sichergestellt werden, dass Daten für die Diagnosesession von dem Fahrzeug nur an ein zertifiziertes Fahrzeugendgerät gesendet werden.
Eine Verbindung zwischen dem Server und dem Fahrzeugendgerät kann eine drahtlose Verbindung sein, z. B. eine mmWellen-basierte Verbindung über das mobile Kommunikationssystem (z. B. unter Verwendung von Trägerfrequenzen von mindestens 20 GHz), oder sie kann mit niedrigeren Trägerfrequenzen erfolgen, z. B. unter Verwendung von Trägerfrequenzen von höchstens 7,5 GHz. Die drahtlose Verbindung zwischen dem Server und dem Fahrzeugendgerät kann beispielsweise über die Protokolle des Mobilkommunikationssystems oder über ein Nahbereichskommunikationssystem, wie ein drahtloses lokales Netzwerk, hergestellt werden.
In einem Ausführungsbeispiel kann das erste zyklische Heartbeatsignal und das zweite zyklische Heartbeatsignal indikativ für einen Parameter der Diagnosesession sein. Der Parameter der Diagnosesession kann beispielsweise eine Information über einen Status des Fahrzeugs, eine Anfrage des Servers (z. B. für benötigte Informationen), ein Steuerungsbefehl des Fahrzeugs, z. B. zum Verändern einer Position und/oder Ausrichtung eines Außenspiegel, ein Steuerungsbefehl für das Fahrzeugendgerät, z. B. zum Ändern der Firewalleinstellung sein. Dadurch kann der Informationsaustausch zwischen dem Fahrzeugendgerät und dem Server vereinfacht mittels des ersten zyklischen Heartbeatsignals und/oder des zweiten zyklischen Heartbeatsignal erfolgen.
Das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann dazu verwendet werden die Diagnosesession zu beenden. In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Beenden der Diagnosesession, wenn weder das erste zyklische Heartbeatsignal empfangen und/oder das zweite zyklische Heartbeatsignal gesendet werden kann. Sofern das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal nicht mehr empfangen/gesendet werden kann, kann eine Verbindung zwischen dem Fahrzeugendgerät und dem Server gestört oder unterbrochen sein. In diesem Fall kann die Diagnosesession beendet werden, beispielsweise um einen sicherheitskritischen Status des Fahrzeugs bzw. des Fahrzeugendgeräts zu beenden. Beispielsweise kann bei einer fehlerhaften Kommunikation zwischen dem Fahrzeugendgerät und dem Server die Diagnosesession beendet werden. Während der Diagnosesession kann es erforderlich sein eine Sicherheitseinstellung des Fahrzeugs oder Fahrzeugendgeräts zu deaktivieren, wodurch eine Wahrscheinlichkeit für einen Angriff steigen kann. Durch ein verbessertes Beenden der Diagnosesession kann eine Sicherheit des Fahrzeugendgeräts oder Fahrzeugs wieder erhöht werden.
Die Diagnosesession kann beendet werden, wenn eine bestimmte Anzahl an ersten zyklischen Heartbeatsignalen und/oder zweiten zyklischen Heartbeatsignalen nicht empfangen/gesendet werden konnte. Beispielsweise kann die Diagnosesession beendet werden, wenn ein Heartbeatsignal des ersten zyklischen Heartbeatsignals und/oder des zweiten zyklischen Heartbeatsignal nicht empfangen/gesendet werden konnte. Optional oder alternativ kann die Diagnosesession beendet werden, wenn eine Mehrzahl an aufeinanderfolgenden Heartbeatsignalen des ersten zyklischen Heartbeatsignals und/oder des zweiten zyklischen Heartbeatsignal nicht empfangen/gesendet werden konnte. Dadurch kann die Diagnosesession bei einer Unterbrechung der Kommunikationsverbindung unterbrochen werden. Optional oder alternativ kann die Diagnosesession beendet werden, wenn in einem definierten Zeitintervall eine Mehrzahl an Heartbeatsignalen des ersten zyklischen Heartbeatsignals und/oder des zweiten zyklischen Heartbeatsignal nicht empfangen/gesendet werden konnte. Dadurch kann die Diagnosesession bei einer ungenügenden Qualität der Kommunikationsverbindung beendet werden.
Optional kann, wenn die Diagnosesession basierend auf einem fehlenden ersten zyklischen Heartbeatsignal und/oder einem fehlenden zweiten zyklischen Heartbeatsignal beendet wurde, das Fahrzeug und/oder das Fahrzeugendgerät in einen Ausgangsstatus vor Initialisierung der Diagnosesession zurückgesetzt werden. Dadurch kann sichergestellt werden, dass durch die Diagnosesession keine Änderung am Fahrzeug und/oder dem Fahrzeugendgerät durchgeführt wurde, welche eine Funktionalität des Fahrzeugs und/oder des Fahrzeugendgeräts beeinträchtigt. Gewollte Änderung, welche während der Diagnosesession durchgeführt wurden, beispielsweise um einen Fehler zu beseitigen, sind hiervon ausgenommen. Gewollte Änderung können beispielsweise Änderungen während der Diagnosesession sein, die einen Fehler beseitigt haben. Beispielsweise kann zu Beginn einer Diagnosesession ein Fahrzeug zwei verschieden Fehler aufweisen. Eine Diagnosesession kann basierend auf einem fehlenden ersten zyklischen Heartbeatsignal beendet worden sein, nachdem ein erster Fehler beseitig wurde. Dieser erste Fehler kann dann beseitigt bleiben, wenn das Fahrzeug in den Ausgangszustand zurückgesetzt wird.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Ändern einer Firewalleinstellung während einer Durchführung der Diagnosesession. Durch die Änderung der Firewalleinstellung kann eine Funktion für die Diagnosesession, beispielsweise für bestimmte Diagnoseschritte erlaubt werden. Eine Änderung kann auch eine Aktualisierung der Firewalleinstellung und/oder der Firewall, beispielsweise durch ein Softwareupdate, sein. Durch die Änderung der Firewalleinstellung können insbesondere verschiedenen Remote-Operationen für den Server ermöglicht werden. Beispielsweise können einem Nutzer des Fahrzeugs Informationen über ein Display im Fahrzeug und/oder des Fahrzeugendgeräts angezeigt werden, z. B. eine verbleibende Diagnosesessionzeit oder eine aktuell durchgeführte Aktion, eine dritte Partei, die die Diagnosesession durchführt.
Das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann dazu verwendet eine zyklische und/oder Event-getriggerte Überwachung des Hochvolt- und/oder Niedervolt-Powermanagement durchzuführen. Dadurch kann ein Batteriezustand des Fahrzeugs überwacht werden. Beispielsweise kann basierend auf dem Batteriezustand des Fahrzeugs eine verbleibende Diagnosesessionzeit, bis es zu einer zu starken Entladung der Batterie kommt, bestimmt werden. In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Bestimmen eines Status des Fahrzeugs und Beenden der Diagnosesession basierend auf dem bestimmten Status des Fahrzeugs. Die Diagnosesession kann beispielsweise basierend auf dem Batteriezustand des Fahrzeugs oder einer Änderung eines Bewegungszustands des Fahrzeugsbeendet werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Erhalten zumindest eines Kriteriums von einer Anwesenheit eines Nutzers des Fahrzeugs, Erhalten einer Zustimmung des Nutzers und/oder Bestimmen eines Status des Fahrzeugs. Das Erhalten kann durch ein Bestimmen, beispielsweise mittels eines Sensors des Fahrzeugs erfolgen. Das Fahrzeug kann beispielsweise eine Anwesenheit des Nutzers durch Bestimmen eines Nutzerendgeräts, welches als smart key für das Fahrzeug konfiguriert ist, bestimmen. Optional oder alternativ kann das Erhalten durch ein Empfangen erfolgen. Das Fahrzeugendgerät kann in das Fahrzeug integriert sein. Beispielsweise kann das Fahrzeugendgerät von einem Nutzer, beispielsweise einem Smartphone eines Nutzers oder von einem Display des Fahrzeugs (das der Nutzer zur Einwilligung berühren kann), ein Einwilligungssignal indikativ für eine Einwilligung in eine Diagnosesession erhalten. Dadurch kann für eine Diagnosesession, die einer Einwilligung des Nutzers bedarf, diese Einwilligung erhalten werden. Beispielsweise kann ein Zeitpunkt für eine Diagnosesession genauer bestimmt werden, weil eine Nutzungsabsicht des Fahrzeugs durch den Nutzer berücksichtigt werden kann. Insbesondere kann nur für bestimmte Teil-Diagnosesessions, z. B., eine full-access Diagnosesession, eine Einwilligung erforderlich. Für eine read-only Diagnosesession kann beispielsweise keine oder eine weniger strenge Einwilligung erforderlich sein.
Eine Einwilligung in eine Diagnosesession kann beispielsweise durch eine Einwilligung in allgemeine Geschäftsbedingungen gegeben werden. Diese Einwilligung kann dann beispielsweise verwendet werden um eine read-only Diagnosesession zu initialisieren. Für eine full-access Diagnosesession hingegen kann eine zusätzliche Bedingung, beispielsweise eine andere Einwilligung, beispielsweise eine Identifikation über eine Applikation auf einem Benutzerendgerät (z. B., dem Fahrzeugendgerät) oder eine Anwesenheit eines Nutzers beim Fahrzeug erforderlich sein. Dadurch kann eine Initialisierung einer sicherheitskritischen Teil-Diagnosesession, z. B., einer full-access Diagnosesession, an eine Vielzahl an Bedingungen geknüpft werden.
Optional oder alternativ kann das Erhalten ein Empfangen von dem Fahrzeug umfassen. Das Fahrzeugendgerät kann ein Benutzerendgerät sein und von dem Fahrzeug ein Statussignal indikativ für den Status des Fahrzeugs erhalten. Dadurch kann das Fahrzeugendgerät das Bereitschaftssignal basierend auf dem Statussignal an den Server senden, beispielsweise wenn eine Diagnosesession wegen eines fehlerhaften Status des Fahrzeugs erforderlich sein kann.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Erhalten von Umgebungsinformationen und/oder Positionsinformationen. Das zweite zyklische Heartbeatsignal kann ferner indikativ für die Umgebungsinformation und/oder Positionsinformation sein. Dadurch, dass das zweite zyklische Heartbeatsignal indikativ für die Umgebungsinformation und/oder die Positionsinformation sein kann, kann diese an den Server gesendet werden. Dadurch kann eine Diagnosesession oder ein Diagnoseschritt basierend auf der Umgebungsinformation und/oder der Positionsinformation durchgeführt werden. Die Umgebungsinformation kann mit einem Sensor des Fahrzeugs bestimmt werden, beispielsweise einem UWB-Sensor, einem Ultraschallsensor, einem LIDAR-Sensor, einem RADAR-Sensor. Die Positionsinformation kann beispielsweise mittels GPS bestimmt werden.
Beispielsweise kann eine full-access Diagnosesession nur für eine bestimmte Position des Fahrzeugs initialisiert werden, z. B. in einer Werkstatt. Beispielsweise kann ein bestimmter Diagnoseschritt nur in einer bestimmten Umgebung ausgeführt werden. Für einen Diagnoseschritt kann ein Ausfahren der Außenspiegel oder der Anhängerkupplung erforderlich sein. Dementsprechend kann dieser Diagnoseschritt nur dann ausgeführt werden, wenn die Umgebung um das Fahrzeug frei ist. Die Information über die freie Umgebung kann mittels des zweiten zyklische Heartbeatsignals gesendet werden. Es kann die Sensorinformation an den Server gesendet werden. Alternativ kann auch nur eine Information über die freie Umgebung an den Server gesendet werden. Dadurch kann ein Datenvolumen verringert werden.
Ein Empfangen der Umgebungsinformation ermöglicht eine Überwachung eines Sensors des Fahrzeugs. Dadurch kann der Server Aktoren im Fahrzeug, beispielsweise zum Ausfahren der Außenspiegel zielgerichtet ansteuern, um z. B. eine Stellung der Außenspiegel temporär, für den Diagnoseschritt, zu verändern. Durch diese Überwachung können diverse Diagnoseschritte ermöglicht werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Senden von Statusinformationen an den Server. Die Statusinformation kann indikativ für den Status des Fahrzeugs sein. Die Statusinformation kann von dem zweiten zyklischen Heartbeatsignal umfasst sein. Beispielsweise kann ein bestimmter Diagnoseschritt nur bei einem Status des Fahrzeugs durchgeführt werden, z. B. bei einer geschlossenen Frontklappe. Eine Überwachung der Frontklappe kann in der Diagnosesession mehrere sicherheitskritische Diagnosesession-Ansteuerungen ermöglichen, wie z.B. die eines Elektrolüfter, von Kühlerjalousien oder einen Motorlauf. Ferner können Änderungen des Status des Fahrzeugs dadurch an den Server übermittelt werden, wodurch dieser geeignete Maßnahmen durchführen kann, z. B. die Diagnosesession bei eine Änderung eines Bewegungszustands des Fahrzeugs zu beenden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Bestimmen eines Status des Fahrzeugs und Bestimmen einer verbleibenden Diagnosesessionzeit basierend auf dem Status des Fahrzeugs. Das zweite zyklische Heartbeatsignal kann ferner indikativ sein für die verbleibende Diagnosesessionzeit. Beispielsweise kann die Diagnosesessionzeit von einem Ladezustand einer Batterie des Fahrzeugs abhängen oder einem Terminplan eines Nutzers des Fahrzeugs. Der Server kann darüber informiert werden, welche Diagnosesessionzeit noch zur Verfügung steht. Dadurch kann eine Steuerung der Diagnosesession verbessert werden, beispielsweise können noch durchzuführende Aufgaben dementsprechend geplant oder auf eine spätere Diagnosesession verschoben werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Empfangen, von dem Server, eines Anfragesignals indikativ für eine Anfrage einer Initialisierung der Diagnosesession. Ferner kann das Bereitschaftssignal ein Antwortsignal indikativ für eine Antwort auf das Anfragesignal sein. Dadurch kann ein Server aktiv eine benötigte Diagnosesession starten.
In einem Ausführungsbeispiel kann das erste zyklische Heartbeatsignal indikativ für ein Löschen eines Fahrzeugfehlerspeichers sein. Ferner kann das Verfahren umfassen Löschen eines Fahrzeugfehlerspeichers basierend auf dem ersten zyklischen Heartbeatsignal. Beispielsweise kann ein Status des Fahrzeugs fehlerhaft sein. Das Fahrzeug kann dann ein Bereitschaftssignal an den Server senden und eine Diagnosesession kann initialisiert werden. Wenn in der Diagnosesession der fehlerhafte Status des Fahrzeugs behoben werden kann, kann der Server die Information zum Löschen des Fahrzeugfehlerspeichers an das Fahrzeugendgerät senden. Dadurch kann das Fahrzeug in einen betriebsbereiten Status versetzt werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Bestimmen eines betriebsbereiten Status des Fahrzeugs und Senden eines finalen Heartbeatsignals des zweiten zyklischen Heartbeatsignals indikativ für den betriebsbereiten Status. Ferner kann das Verfahren umfassen Beenden der Diagnosesession. Dadurch kann das Fahrzeugendgerät eine Information an den Server senden, dass eine Diagnosesession beendet werden kann. Dementsprechend kann der Server informiert werden, dass ein fehlendes Senden des zweiten zyklischen Heartbeatsignals nicht durch eine unterbrochene Kommunikationsverbindung hervorgerufen sein kann, sondern dass Senden des zweiten zyklischen Heartbeatsignals beendet wurde.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten beschriebenen Ausführungsbeispielen erwähnt. Das in 1 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren unten beschriebenen Ausführungsbeispielen (z. B. 2 - 4) erwähnt wurden.
2 zeigt eine schematische Darstellung eines weiteren Verfahrens 200 zur Steuerung einer Diagnosesession eines Fahrzeugs. Das Verfahren 200 kann von einem Server, beispielsweise einem Backend, durchgeführt werden. Das Verfahren 200 kann von einem Gegenpart eines Fahrzeugendgeräts, welches das Verfahren in 1 durchführen kann, durchgeführt werden. Beispielsweise können der Server, der ein Verfahren 200 ausführt, und das Fahrzeugendgerät, welches ein Verfahren wie in 1 beschrieben ausführt, in einem Gesamtsystem miteinander Information austauschen, um beide Verfahren durchzuführen (siehe z. B. 3).
Das Verfahren 200 umfasst Empfangen 210, von einem Fahrzeugendgerät, eines Bereitschaftssignals indikativ für eine Bereitschaft für die Diagnosesession. Weiterhin umfasst das Verfahren 200 Senden 220, an das Fahrzeug, eines ersten zyklischen Heartbeatsignals und/oder Empfangen, von dem Fahrzeug, eines zweiten zyklischen Heartbeatsignals. Ferner umfasst das Verfahren 200 Initialisieren 230 einer Diagnosesession basierend auf dem ersten zyklischen Heartbeatsignal und/oder dem zweiten zyklische Heartbeatsignal. Dadurch kann eine Initialisierung der Diagnosesession verbessert werden. Insbesondere kann die Initialisierung der Diagnosesession dann erfolgen, wenn sowohl der Server als auch das Fahrzeugendgerät eine Durchführung einer Diagnosesession ermöglichen können.
In einem Ausführungsbeispiel kann das erste zyklische Heartbeatsignal indikativ für eine Statusanfrage des Fahrzeugs und das zweite zyklische Heartbeatsignal indikativ für einen Status des Fahrzeugs sein. Ferner kann das Verfahren umfassen Bestimmen einer verbleibenden Diagnosesessionzeit basierend auf dem Status des Fahrzeugs. Dadurch kann eine Steuerung der Diagnosesession verbessert, beispielsweise können noch durchzuführende Aufgaben dementsprechend geplant oder auf eine spätere Diagnosesession verschoben werden.
In einer full-access Diagnosesession kann der Server bestimmen, ob ein Beenden der full-access Diagnosesession erforderlich ist, wenn das zweite zyklische Heartbeatsignal nicht mehr empfangen werden kann durch den Server. Beispielsweise kann der Server ein Stopheartbeatsignal an das Fahrzeugendgerät senden, indikativ für ein Beenden des Sendens des zweiten zyklischen Heartbeatsignal. Danach kann der Server die full-access Diagnosesession beenden. Optional kann der Server die full-access Diagnosesession nur beenden, wenn von dem Fahrzeugendgerät eine Antwort auf das Stopheartbeatsignal empfangen wurde oder wenn eine Timeoutzeit für ein Empfangen einer Antwort überschritten ist.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in 2 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1) und/oder unten beschriebenen Ausführungsbeispielen (z. B. 3 - 4) erwähnt wurden.
3 zeigt ein Flussdiagramm einer Diagnosesession 300. Die Diagnosesession 300 umfasst eine erste Teil-Diagnosesessions 302 und eine zweite Teil-Diagnosesession 304. Die erste Teil-Diagnosesession 302 ist eine read-only Diagnosesession. Die zweite Teil-Diagnosesession 304 ist eine full-access Diagnosesession.
Die erste Teil-Diagnosesession 302 und die zweite Teil-Diagnosesession 304 können zu unterschiedlichen Zeitpunkten gestartet werden. In 310 kann die erste Teil-Diagnosesession 302, auch als Info-Session 302 bezeichnet, gestartet werden. In der Info-Session 302 kann lediglich ein zweites zyklisches Heartbeatsignal von dem Fahrzeugendgerät an den Server, beispielsweise einen Backend Client, gesendet werden. Da es sich bei der Info-Session 302 lediglich um eine Teil-Diagnosesession zur Informationsübertragung vom Fahrzeugendgerät (beispielsweise umfasst vom Fahrzeug) zum Server handeln kann, kann ein Empfangen eines ersten zyklischen Heartbeatsignals entfallen. Insbesondere kann das Fahrzeugendgerät keine Information darüber benötigen, ob der Server an das Fahrzeugendgerät Information übertragen kann. In der Info-Session 302 kann keine Informationsübertragung vom Server erfolgen. Ein Zeitlimit der Info-Session 302 kann vordefiniert sein. Dadurch kann das Fahrzeug nach Ablauf des Zeitlimits die Info-Session 302 beenden.
Der Server kann insbesondere den Backend Client und den Backend-Service umfassen. Der Backend Client kann beispielsweise eine künstliche Intelligenz oder ein Programm sein, welches zur Durchführung der Diagnosesession 300 angelernt oder konfiguriert ist.
In 350 kann die zweite Teil-Diagnosesession 304, auch als Diag-Session 304 bezeichnet, gestartet werden. In der Diag-Session 304 können dynamische Anfragen für dynamische Diagnoseschritte für Test-Routinen vom Server an das Fahrzeugendgerät gesendet werden, insbesondere mittels des ersten zyklischen Heartbeatsignals oder einem Steuerungssignal. Für die dynamischen Anfragen kann kein Zeitlimit existieren. Ferner kann in der Diag- Session 304 eine kontinuierliche Überwachung der Kommunikationsverbindung zwischen dem Server und dem Fahrzeugendgerät erfolgen, insbesondere durch das erste zyklische Heartbeatsignal und das zweite zyklische Heartbeatsignal. Außerdem kann in der Diag-Session 304 das Fahrzeugendgerät relevante Informationen für den Server hinsichtlich des Status des Fahrzeugs an den Server senden. Beispielsweise können Information über einen Batteriezustand, den Status des Fahrzeugs (z. B., verriegelt, entriegelt) und/oder der Türen des Fahrzeugs gesendet werden.
Prinzipiell kann der Backend dient (agent) entscheiden welche Teil-Diagnosesession 302, 304 gestartet wird. Die Info-Session 302 kann ein vordefiniertes Zeitlimit haben. Das vordefinierte Zeitlimit kann in dem Fahrzeugendgerät gespeichert sein. Insbesondere kann für die Durchführung der Info-Session 302 kein erstes zyklisches Heartbeatsignal erforderlich sein. Die Diag-Session 304 kann kein vordefiniertes Zeitlimit haben. Ferner kann in der Diag-Session 304 das zweite zyklische Heartbeatsignal erforderlich sein. Optional kann ein Parameter wie beispielsweise eine Anwesenheit eines Nutzers, ein Status des Fahrzeugs, ein Standort des Fahrzeugs zum Starten 350 der Diag-Session 304 erforderlich sein. Falls diese Bedingung nicht erfüllt ist, kann das Fahrzeugendgerät ein Starten 350 der Diag-Session 304 ablehnen.
In 312/352 kann der Backend Client ein Anfragesignal an das Fahrzeugendgerät senden. Dieses Anfragesignal kann zur Anfrage einer Info-Session 302/Diag-Session 304 dienen. Mit dem Anfragesignal kann der Backend Client auch eine spezifische Bedingung zur Initialisierung der Info-Session 302/Diag-Session 304 senden. Beispielsweise kann eine Anwesenheit eines Nutzers oder eine Änderung des Status des Fahrzeugs in einen Diagnosestatus erforderlich sein.
In 314/354 kann das Fahrzeug durch das Fahrzeugendgerät basierend auf dem Anfragesignal aufgeweckt werden. Ferner kann ein Status des Fahrzeugs durch das Fahrzeugendgerät auf einen für die Info-Session 302/Diag-Session 304 geeigneten Status geändert werden. Falls eine Initialisierung der Info-Session 302/Diag-Session 304 nicht möglich ist, z. B., weil die spezifische Bedingung nicht erfüllt ist, kann in 316/356 eine Akzeptanzsignal/Ablehnungssignal indikativ für eine Akzeptanz/Ablehnung der Anfrage für die Info-Session 302/Diag-Session 304 an einen Backend Client gesendet werden.
In 318/358 kann das zweite zyklische Heartbeatsignal an den Backend Client und in 358 kann optional das erste zyklische Heartbeatsignal an das Fahrzeugendgerät von dem Backend Client gesendet werden. Dies kann insbesondere erfolgen, wenn das Fahrzeug in einem Diagnosestatus ist und die Diagnosesession, auch Heartbeatsession genannt, aktiv ist. Die Heartbeatsession kann so lange aktiv sein, wie das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal gesendet wird.
In 320/360 wird das zweite zyklische Heartbeatsignal vom Backend Service an den Backend Client gesendet. Das erste zyklische Heartbeatsignal und/oder das zweite zyklische Heartbeatsignal kann als keepalive-Signal gesendet werden. In der Info-Session 302 kann mittels des zweiten zyklischen Heartbeatsignals eine weitere Information gesendet werden, beispielsweise ein Batteriezustand, ein Status einer Tür. Insbesondere kann dadurch eine Information über ein Event gesendet werden, beispielsweise ein Öffnen einer Tür. Ferner kann das zweite zyklische Heartbeatsignal kritische Informationen für die Diagnosesession umfassen, beispielsweise ein Ladezustand der Fahrzeugbatterie. Bei einer zu stark entladenen Fahrzeugbatterie kann eine sofortige Beendigung der Diagnosesession erforderlich sein.
In der Diag-Session 304 kann der Backend Client das erste zyklische Heartbeatsignal in 361 senden. Sofern das Fahrzeugendgerät das erste zyklische Heartbeatsignal nicht empfangen kann, beispielsweise mehrere nacheinander folgender Heartbeatsignale des ersten Heartbeatsignals, kann das Fahrzeugendgerät die Diag-Session 304 beenden. Dadurch kann eine Sicherheit des Fahrzeugendgeräts erhöht werden.
In 322/362 kann ein Stopsignal von dem Backend Client an den Backend Service gesendet werden. Von dem Backend Client kann das Stopsignal in 324/364 an das Fahrzeugendgerät gesendet werden. Das Stopsignal kann insbesondere durch ein finales Heartbeatsignal des ersten zyklischen Heartbeatsignal umfasst oder dieses sein. Sofern in der Info-Session 302 kein erstes zyklisches Heartbeatsignal von dem Backend Client gesendet wird, kann die Info-Session 302 durch das Fahrzeugendgerät beendet werden.
In 326/356 kann eine Bestätigungsnachricht vom Fahrzeugendgerät an den Backend Client gesendet werden, dass die Diagnosesession beendet werden kann. Diese Bestätigung kann beispielsweise von einem finalen Heartbeatsignal des zweiten zyklischen Heartbeatsignal umfasst sein oder dieses sein. Das Fahrzeugendgerät kann einen Status des Fahrzeugs nach Beendigung des Sendes des zweiten zyklischen Heartbeatsignals ändern, beispielsweise kann es einen Energiesparmodus des Fahrzeugs triggern.
Die Diag-Session 304 kann beispielsweise nur durch ein Stopsignal 362 beendet werden. Ferner kann das Fahrzeugendgerät die Beendigung der Diag-Session 304 nur dann mit einer Bestätigungsnachricht in 366 bestätigen, wenn ein Status des Fahrzeugs vorliegt, beispielsweise ein Status vor Beginn der Diag-Session 304. Beispielsweise kann, wenn ein Status des Fahrzeugs von vor der Diag-Session nicht wieder hergestellt werden kann, das Fahrzeugendgerät eine Nicht-Bestätigungsnachricht indikativ für ein Problem mit der Widerherstellung des Status des Fahrzeugs in 366 senden. In diesem Fall kann der Backend Client Maßnahmen ergreifen, um eine Widerherstellung des Status des Fahrzeugs zu ermöglichen, z. B., einen Nutzer kontaktieren, einen Diagnoseschritt wiederholen.
Die Info-Session 302 und/oder die Diag-Session 304 kann auch durch das Fahrzeugendgerät beendet werden, beispielsweise wenn ein Motor des Fahrzeugs gestartet wird, ein zu stark entladener Batteriezustand vorliegt.
Die Info-Session 302 kann dazu dienen Information für eine Diag-Session 304 zu erhalten. Dadurch kann eine Dauer einer sicherheitskritischeren Diag-Session 304 verringert oder eine Diag-Session vollkommen vermieden werden. In 330 kann eine Diagnosesession unterbrochen werden, nachdem eine Info-Session 302 durchgeführt wurde. Während der Unterbrechung kann eine Auswertung der von dem Fahrzeug erhaltenen Informationen erfolgen. Hierzu kann insbesondere keines des ersten zyklischen Heartbeatsignals und zweiten zyklischen Heartbeatsignals erforderlich sein. Basierend auf einer Auswertung der Information kann dann bestimmt werden, ob eine Diag-Session 304 erforderlich ist. Falls eine Diag-Session 304 erforderlich ist, kann diese im Anschluss an die Info-Session 302 bzw. die Auswertung initialisiert werden.
Für die Diag-Session 304 kann das Fahrzeugendgerät in 370 eine Anfrage erhalten eine Firewalleinstellung zu ändern, beispielsweise durch ein Installieren einer speziellen Firewall, geeignet für ein Diag-Session 304. Beispielsweise kann die spezielle Firewall ein Regelset umfassen, welches temporär (für die Dauer der Diag-Session 304) aktiviert werden kann, wodurch eine zentrale Firewalleinstellung geändert oder unterdrückt werden kann. Die spezielle Firewall kann in 372 durch das Fahrzeugendgerät aktiviert werden. Dadurch kann der Backend Client einen besseren Zugang zu dem Fahrzeugendgerät oder dem Fahrzeug erhalten. Mit einem Beenden der Diag-Session 304 kann die Firewall in 374 auf einen ursprünglichen Status zurückgesetzt werden. Dadurch kann eine normale Sicherheit des Fahrzeugendgeräts wieder hergestellt werden.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in 2 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1) und/oder unten beschriebenen Ausführungsbeispielen (z. B. 3 - 4) erwähnt wurden.
4 zeigt ein Blockdiagram eines Ausführungsbeispiels einer Vorrichtung 30 zur Steuerung einer Diagnosesession eines Fahrzeugs 400. Die Vorrichtung 30, umfasst eine Schnittstelle 32 zur Kommunikation mit einem Benutzerendgerät (beispielsweise dem Server oder dem Fahrzeugendgerät). Die Vorrichtung 30 umfasst ferner eine Datenverarbeitungsschaltung 34, das zur Durchführung zumindest eines der hierin beschriebenen Verfahren ausgebildet ist, beispielsweise das Verfahren, welches mit Bezug zu 1 für das Fahrzeugendgerät oder mit Bezug zu 2 für den Server beschrieben ist. Weitere Ausführungsbeispiele sind ein Fahrzeug 400 mit einer Vorrichtung 30.
Die in 4 gezeigte Schnittstelle 32 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten. Die Schnittstelle 32 kann beispielsweise ausgebildet sein, um über ein (Funk)-Netzwerk oder ein lokales Verbindungsnetzwerk mit anderen Netzwerkkomponenten zu kommunizieren.
In Ausführungsbeispielen kann die Datenverarbeitungsschaltung 34 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Datenverarbeitungsschaltung 34 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern kann die Datenverarbeitungsschaltung 34 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung der Datenverarbeitungsschaltung 34 denkbar.
Wie in 4 dargestellt, kann die Schnittstelle 32 mit der jeweiligen Datenverarbeitungsschaltung 34 der Vorrichtung 30 gekoppelt sein. In Beispielen kann die Vorrichtung 30 durch eine oder mehrere Verarbeitungseinheiten, ein oder mehrere Verarbeitungsgeräte, ein beliebiges Mittel zur Verarbeitung, wie z.B. einen Prozessor, einen Computer oder eine programmierbare Hardwarekomponente, die mit entsprechend angepasster Software betrieben werden kann, implementiert werden. Ebenso können die beschriebenen Funktionen der Datenverarbeitungsschaltung 34 auch in Software implementiert werden, die dann auf einer oder mehreren programmierbaren Hardwarekomponenten ausgeführt wird. Solche Hardwarekomponenten können ein Mehrzweckprozessor, ein digitaler Signalprozessor (DSP), ein Mikrocontroller usw. sein. Die Datenverarbeitungsschaltung 34 kann in der Lage sein, die Schnittstelle 32 zu steuern, so dass jede Datenübertragung, die über die Schnittstelle 32 erfolgt, und/oder jede Interaktion, an der die Schnittstelle 32 beteiligt sein kann, von der Datenverarbeitungsschaltung 34 gesteuert werden kann.
In einer Ausführungsform kann die Vorrichtung 30 einen Speicher und mindestens eine Datenverarbeitungsschaltung 34 umfassen, die funktionsfähig mit dem Speicher gekoppelt und so konfiguriert ist, dass sie die eines der oben beschriebenen Verfahren durchführt.
In Beispielen kann die Schnittstelle 32 jedem Mittel zum Erhalten, Empfangen, Übertragen oder Bereitstellen von analogen oder digitalen Signalen oder Informationen entsprechen, z. B. jedem Anschluss, Kontakt, Stift, Register, Eingangsanschluss, Ausgangsanschluss, Leiter, Spur usw., der die Bereitstellung oder den Erhalt eines Signals oder einer Information ermöglicht. Die Schnittstelle 32 kann drahtlos oder drahtgebunden sein und können so konfiguriert sein, dass sie mit weiteren internen oder externen Komponenten kommunizieren können, z. B. Signale oder Informationen senden oder empfangen können.
In zumindest manchen Ausführungsbeispielen kann das Fahrzeug 400 beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Bus, einem Motorrad, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen. Die Vorrichtung 30 kann beispielsweise ein Teil eines Steuergeräts des Fahrzeugs 400 sein.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den oben beschriebenen Ausführungsbeispielen erwähnt. Das in 3 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. 1 - 2) beschriebenen Ausführungsbeispielen erwähnt wurden.
Weitere Ausführungsbeispiele sind Computerprogramme zur Durchführung eines der hierin beschriebenen Verfahren, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft. Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-Ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einer programmierbaren Hardwarekomponente derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird.
Eine programmierbare Hardwarekomponente kann durch einen Prozessor, einen Computerprozessor (CPU = Central Processing Unit), einen Grafikprozessor (GPU = Graphics Processing Unit), einen Computer, ein Computersystem, einen anwendungsspezifischen integrierten Schaltkreis (ASIC = Application-Specific Integrated Circuit), einen integrierten Schaltkreis (IC = Integrated Circuit), ein Ein-Chip-System (SOC = System on Chip), ein programmierbares Logikelement oder ein feldprogrammierbares Gatterarray mit einem Mikroprozessor (FPGA = Field Programmable Gate Array) gebildet sein.
Das digitale Speichermedium kann daher maschinen- oder computerlesbar sein. Manche Ausführungsbeispiele umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem oder einer programmierbare Hardwarekomponente derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird. Ein Ausführungsbeispiel ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Programm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Programm, Firmware, Computerprogramm oder Computerprogrammprodukt mit einem Programmcode oder als Daten implementiert sein, wobei der Programmcode oder die Daten dahin gehend wirksam ist bzw. sind, eines der Verfahren durchzuführen, wenn das Programm auf einem Prozessor oder einer programmierbaren Hardwarekomponente abläuft. Der Programmcode oder die Daten kann bzw. können beispielsweise auch auf einem maschinenlesbaren Träger oder Datenträger gespeichert sein. Der Programmcode oder die Daten können unter anderem als Quellcode, Maschinencode oder Bytecode sowie als anderer Zwischencode vorliegen.
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.
Bezugszeichenliste

30: Vorrichtung
32: Schnittstelle
34: Datenverarbeitungsschaltung
100: Verfahren zur Steuerung einer Diagnosesession eines Fahrzeugs
110: Senden, an einen Server, eines Bereitschaftssignals
120: zumindest eines von Empfangen oder Senden
130: Initialisieren der Diagnosesession
200: Verfahren zur Steuerung einer Diagnosesession eines Fahrzeugs
210: Empfangen, von einem Fahrzeugendgerät, eines Bereitschaftssignals
220: zumindest eines von Empfangen oder Senden
230: Initialisieren der Diagnosesession
300: Diagnosesession
302: erste Teil-Diagnosesession
304: zweite Teil-Diagnosesession
310: Starten erste Teil-Diagnosesession
350: Starten zweite Teil-Diagnosesession
312/352: Senden eines Anfragesignals
314/354: Aufwecken des Fahrzeugs
316/356: Senden eines Akzeptanzsignals/Ablehnungssignals
318/358: Senden des zweiten zyklischen Heartbeatsignals
320/360: Senden des zweiten zyklischen Heartbeatsignals
322/362: Senden eines Stopsignals
324/364: Senden eines Stopsignals
326/356: Senden einer Bestätigungsnachricht
330: Unterbrechen der Diagnosesession
361: Senden des ersten zyklischen Heartbeatsignals
370: Erhalten einer Anfrage
372: Aktivieren einer Firewalleinstellung
374: Herstellen eines ursprünglichen Status der Firewall
400: Fahrzeug

Claims

Ein Verfahren (100) zur Steuerung einer Diagnosesession eines Fahrzeugs, umfassend: Senden (110), an einen Server, eines Bereitschaftssignals indikativ für eine Bereitschaft für die Diagnosesession; zumindest eines von Empfangen (120), von dem Server, eines ersten zyklischen Heartbeatsignals oder Senden (120), an den Server, eines zweiten zyklischen Heartbeatsignals; und Initialisieren (130) der Diagnosesession basierend auf dem ersten zyklischen Heartbeatsignal oder dem zweiten zyklischen Heartbeatsignal.
Das Verfahren (100) nach Anspruch 1, wobei das erste zyklische Heartbeatsignal und das zweite zyklische Heartbeatsignal indikativ für einen Parameter der Diagnosesession sind.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, ferner umfassend Beenden der Diagnosesession, wenn weder das erste zyklische Heartbeatsignal empfangen noch das zweite zyklische Heartbeatsignal gesendet werden kann.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, ferner umfassend Ändern einer Firewalleinstellung während einer Durchführung der Diagnosesession.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, ferner umfassend Bestimmen eines Status des Fahrzeugs; und Beenden der Diagnosesession basierend auf dem bestimmten Status des Fahrzeugs.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, ferner umfassend Erhalten zumindest eines Kriteriums von einer Anwesenheit eines Nutzers des Fahrzeugs oder Erhalten einer Zustimmung des Nutzers zum Initialisieren der Diagnosesession, wobei die Diagnosesession nur dann initialisiert werden kann, wenn zumindest eines der Kriterien erhalten wurde.
Das Verfahren (100) nach einem die vorhergehenden Ansprüche, ferner umfassend Erhalten zumindest eines von Umgebungsinformationen oder Positionsinformationen und wobei das zweite zyklische Heartbeatsignal ferner indikativ ist für zumindest eines von der Umgebungsinformation oder der Positionsinformation.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche ferner umfassend Empfangen, von dem Server, eines Anfragesignals indikativ für eine Anfrage einer Initialisierung der Diagnosesession, und wobei das Bereitschaftssignal ein Antwortsignals indikativ für eine Antwort auf das Anfragesignal ist.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, ferner umfassend Bestimmen eines betriebsbereiten Status des Fahrzeugs; Senden eines finalen Heartbeatsignals des zweiten zyklischen Heartbeatsignals indikativ für den betriebsbereiten Status; und Beenden der Diagnosesession.
Das Verfahren (100) nach einem der vorhergehenden Ansprüche, ferner umfassend Bestimmen eines Status des Fahrzeugs; Bestimmen einer verbleibenden Diagnosesessionzeit basierend auf dem Status des Fahrzeugs; und wobei das zweite zyklische Heartbeatsignal ferner indikativ ist für die verbleibende Diagnosesessionzeit.
Ein Verfahren (200) zur Steuerung einer Diagnosesession eines Fahrzeugs, umfassend: Empfangen (210), von einem Fahrzeugendgerät, eines Bereitschaftssignals indikativ für eine Bereitschaft für die Diagnosesession; zumindest eines von Senden (220), an das Fahrzeugendgerät, eines ersten zyklischen Heartbeatsignals oder Empfangen (220), von dem Fahrzeugendgerät, eines zweiten zyklischen Heartbeatsignals; und Initialisieren (230) einer Diagnosesession basierend auf dem ersten zyklischen Heartbeatsignal oder dem zweiten zyklische Heartbeatsignal.
Das Verfahren (200) nach Anspruch 11, wobei das erste zyklische Heartbeatsignal indikativ ist für eine Statusanfrage des Fahrzeugs und das zweite zyklische Heartbeatsignal indikativ ist für einen Status des Fahrzeugs; und ferner umfassend Bestimmen einer verbleibenden Diagnosesessionzeit basierend auf dem Status des Fahrzeugs.
Ein Computerprogramm zur Durchführung eines der Verfahren nach einem der vorhergehenden Ansprüche, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft.
Eine Vorrichtung (30) zur Steuerung einer Diagnosesession eines Fahrzeugs (400), umfassend eine Schnittstelle (32) zur Kommunikation mit einem Server oder einem Fahrzeugendgerät; und eine Datenverarbeitungsschaltung (34), die zur Durchführung zumindest eines der Verfahren (100, 200) nach einem der Ansprüche 1-12 ausgebildet ist.
Ein Fahrzeug (400) mit einer Vorrichtung (30) nach Anspruch 14.