-
Die Erfindung betrifft eine Kommunikationsschnittstelle in einem Fahrzeug zwischen einer Head Unit und mindestens einem ersten Human Interface Device (HID) und einem zweiten Human Interface Device (HID), wobei ein Datenaustausch zwischen der Head Unit und dem ersten Human Interface Device über eine erste Kommunikationsstrecke stattfindet und wobei ein Datenaustausch zwischen der Head Unit und dem zweiten Human Interface Device über eine zweite Kommunikationsstrecke stattfindet.
-
In modernen Kraftfahrzeugen wird eine große Anzahl an Sensoreinrichtungen, Steuergeräten und Steuerungscomputern verbaut. Diese Elemente sind in der Regel über ein Bordnetz miteinander verbunden, das häufig als Bussystem realisiert ist. Über das Bussystem können Daten untereinander ausgetauscht werden. Über eine Schnittstelle können zusätzlich externe übergeordnete Systeme angesprochen werden. Die Steuergeräte, Steuerungscomputer und Sensorvorrichtungen, im Folgenden insgesamt als Steuergeräte bezeichnet, sind dazu ausgelegt, verschiedene im Fahrzeug anfallende Überwachungs- und Steuerungsfunktionen durchzuführen. Dazu gehört unter anderem die Steuerung und/oder Überwachung der Motor und Getriebe-Steuerungen oder auch von Antiblockiersystemen. Zum Teil müssen diese Systeme in Echtzeit beziehungsweise mit möglichst wenig Zeitverzögerung arbeiten, da wichtige Prozesse, wie beispielweise die Bremsverzögerung, gesteuert werden müssen.
-
Daneben müssen unterschiedliche Funktionen durch einen Nutzer beziehungsweise einen Fahrer des Fahrzeugs einstellbar sein. Diese Einstellungen werden durch Eingabegeräte ermöglicht, die eine Kommunikationsschnittstelle benötigen, um beispielsweise mit einer Head Unit kommunizieren zu können.
-
Die
US 2012/0192119 A1 zeigt beispielsweise ein Verfahren zur Implementierung von USB-Kommunikation mit einer Schnittstelle, bei der wenigstens eine Geste und ein Winkel einer Fingerposition für ein berührungsresistentes Eingabegerät gemessen wird. Dabei werden in Echtzeit Tastbild-Informationen von einem Tastsensor aufgenommen, um die entsprechenden Parameter zu erhalten. Diese Informationen werden in UBS-HID Nachrichten umgewandelt, welche an ein Host-Gerät übertragen werden.
-
Die aus dem Stand der Technik bekannten Kommunikationsschnittstellen in Fahrzeugen weisen den Nachteil auf, dass sie teilweise stark latenzbehaftet sind und/oder einen vergleichsweise aufwendigen Stack erfordern.
-
Der Erfindung liegt daher die Aufgabe zugrunde, eine Kommunikationsschnittstelle in einem Fahrzeug anzugeben, die flexibel, latenzarm und vergleichsweise leichtgewichtig ist.
-
Diese Aufgabe ist bei der vorliegenden Erfindung durch die Merkmale des Kennzeichnungsteils des Patentanspruchs 1 dadurch gelöst, dass die Kommunikationsschnittstelle zentral definiert ist, sodass sie für alle Kommunikationsstrecken ihre Gültigkeit besitzt.
-
Ein Human Interface Device ist eine Art Computer, der direkt mit Menschen interagiert, meist auch Input von Menschen entgegennimmt, und gegebenenfalls auch Output an Menschen zurückgibt. Der Begriff HID wird häufig im Zusammenhang mit USB Geräten, dann in Verbindung mit USB-HID verwendet. Im Rahmen dieser Anmeldung können als Human Interface Device beispielsweise Tastaturen, Mäuse, Joysticks, Grafiktabletts, aber auch insbesondere Displays beziehungsweise Tabletcomputer zu verstehen sein. Denkbar sind entsprechend auch im Fahrzeug integrierte Tasten, beispielsweise am Lenkrad, aber auch Möglichkeiten der Sprachsteuerung und/oder Gestensteuerung.
-
Eine Head Unit ist im Rahmen des Infotainmentsystems, welches in einem Fahrzeug die Zusammenführung von Autoradio, Navigationssystem, Freisprecheinrichtung, Fahrassistenzsysteme und weitere Funktionen in einer zentralen Bedieneinheit vereint, die Haupteinheit dieses Systems. Die Haupteinheit umfasst eine oder mehrere Hauptplatinen, die mit Prozessoren und dergleichen ausgestattet sind und das Herz des Infotainmentsystems bilden.
-
Eine zentral definierte Kommunikationsschnittstelle bietet den Vorteil einer definierten generischen Kommunikation, die für unterschiedlichste Anwendungen genutzt werden kann.
-
Weitere bevorzugte Ausgestaltungen der Erfindung ergeben sich aus den übrigen, in den Unteransprüchen genannten Merkmalen.
-
Bei einer ersten Ausgestaltung der erfindungsgemäßen Kommunikationsschnittstelle ist ein Transport-Layer vorgesehen, der eine Segmentierung von zu übertragenen Daten ermöglicht. Der Transport-Layer, beziehungsweise ein sendender Knoten des Transport-Layers kann selbstständig versuchen, eine Nachricht zu senden. Wenn die Anfrage nach beispielsweise 1 s nicht erfolgreich ausgeführt werden konnte, wird ein Timeout-Signal ausgegeben. In Abhängigkeit vom Anwendungsfall kann entschieden werden, eine Nachricht erneut zu senden. Wenn zum Beispiel ein „Knopfdruck“ mit einer Verzögerung von 1 s gesendet wird, ist die verzögerte Reaktion des Systems für den Benutzer nicht nachvollziehbar.
-
Bei einer weiteren Ausgestaltung der erfindungsgemäßen Kommunikationsschnittstelle ist ein Applikations-Layer vorgesehen, der einen bidirektionalen Datenaustausch zwischen der Head Unit und dem ersten Human Interface Device und/oder dem zweiten Human Interface Device ermöglicht. Da das Human Interface Device der Datenstamm ist, muss er notwendige Werte beinhalten.
-
Ferner ist bei einer weiteren Ausgestaltung der Erfindung vorgesehen, dass aktuelle Stati des ersten Human Interface Device und/oder dem zweiten Human Interface Device mitteilbar und/oder anfragbar sind. Alle eingebundenen Human Interface Devices müssen ihren aktuellen Status übermitteln beziehungsweise übersenden Statusmitteilungen. Die Statusmeldungen können auch über bestimmte Befehle abgefragt werden.
-
Darüber hinaus ist bei einer weiteren Ausgestaltung vorgesehen, dass eine Änderung des aktuellen Zustandes des ersten Human Interface Device und/oder dem zweiten Human Interface Device anfragbar sind. Dabei kann vorgesehen sein, dass jede Statusänderung eines eingebundenen Human Interface Devices durch die Human Interface Devices an die Head Unit übermittelt werden. Eine Status-Meldung ist als Datenoperations-Meldung zu verstehen. Diese enthält unter anderem einen HID-Befehl.
-
Bei einer weiteren vorteilhaften Ausgestaltung der erfindungsgemäßen Kommunikationsschnittstelle ist vorgesehen, dass eine durch das erste Human Interface Device und/oder durch das zweite Human Interface Device ausgeführte Operation einem Kommando zuordenbar ist, das in einem Kommandokatalog definiert ist. Die Befehle und ihre Datenstruktur können in anwendungsfallabhängigen Kommandokatalogen hinterlegt sein. Dabei ist denkbar, dass über einen Befehl beziehungsweise eine Abfrage alle für das jeweilige Human Interface Device unterstützte Kommandos abfragbar sind.
-
Beispielhaft, aber nicht als abschließende Aufzählung zu verstehen, sind die folgenden Befehle möglich:
- Eine GET-Anfrage löst eine Anforderung für einen unterstützten Befehl aus. Durch Senden einer FetchALL/Reset.GET-Anfrage wird das Human Interface Device mit allen entsprechenden Status-Nachrichten antworten, um den aktuellen Status des HID bereitzustellen, ohne dass jede Eigenschaft einzeln angefordert werden muss.
-
Allgemein zeigt eine STATUS-Meldung an, dass sich ein Status eines Human Interface Device geändert hat. Als STATUS-Meldung kann das HID seinen Start anzeigen, zum Beispiel wenn das HID später gestartet wurde als ein entsprechendes Gegenstück. Dies kann auch ein Zurücksetzen des HID signalisieren. Nach einer FetchAll/Reset.STATUS-Nachricht fordert das Gegenstück den aktuellen Status für alle Befehle, weil Werte im Cache möglicherweise ungültig geworden sind.
-
Eine CommandSupport-Anfrage kann eine dynamische Kommunikation der, innerhalb des Kommandokatalogs definierten, vom Human Interface Device unterstützten Kommandos bewirken.
-
Bei einer besonders bevorzugten Ausgestaltung der Erfindung ist vorgesehen, dass die zentral definierte Kommunikationsschnittstelle den ISO TP-Standard nutzt. Um den Austausch verschiedener Informationen zu trennen, werden HID-Befehle als erste Parameter im ISO TP-Datenrahmen genutzt. Die Befehle und ihre Datenstruktur sind dann entsprechend in anwendungsfallabhängigen Kommandokatalogen definiert. Das erste Byte eines ISO TP-Datenrahmens enthält den HID-Befehl. Innerhalb einer Nachricht wird die Big-Endian Byte-Reihenfolge verwendet, sofern dies durch ein Kommando vorteilhafterweise nicht gegenteilig spezifiziert wurde. Dies kann beispielsweise der Fall sein, wenn über einen Befehl beziehungsweise eine Abfrage alle für das jeweilige Human Interface Device unterstützte Kommandos abgefragt werden. Als Datentyp für einen Befehl ist nur ein Vielfaches von Bytes zulässig. Wenn ein Wert nicht genau in ein oder mehrere Bytes passt, werden nicht verwendete Bits und Bytes mit Nullen aufgefüllt.
-
Für eine vergleichsweise einfach gestaltete Kommunikation ist bei einer weiteren Ausgestaltung der erfindungsgemäßen Kommunikationsschnittstelle wenigstens ein Fahrzeugdatenbus, insbesondere CAN-Bus, zur Signalübertragung vorgesehen. Ein Fahrzeugdatenbus hat den Vorteil, dass in der Regel mehrere gleichberechtigte Steuergeräte miteinander verbunden werden können. Das CAN-Netzwerk arbeitet beispielsweise nach einer Linienstruktur. Stichleitungen sind dabei im eingeschränkten Umfang zulässig, ebenso ein sternförmiger Bus. Der sternförmige Bus hat allerdings den Nachteil, dass dieser meist vom Zentralrechner gesteuert wird, da alle Informationen den Zentralrechner passieren müssen. Somit wäre beim Ausfall des Zentralrechners das gesamte System funktionsunfähig. Daneben ist bei Stichleitungen und auch bei der sternförmigen Architektur der Leitungswellenwiderstand etwas aufwendiger zu bestimmen.
-
Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Kommunikationsschnittstelle sieht vor, dass von der Head Unit ein Videosignal auf das erste Human Interface Device und/oder das zweite Human Interface Device übertragbar ist. Dabei kann vorgesehen sein, dass zwei Displays die Kommunikationsschnittstelle als Human Interface Device benötigen, beispielsweise zum Ein-/Ausschalten der Display-Beleuchtung. Beide Displays implementieren einen gemeinsamen Kommandokatalog mit einer individuellen Kommunikationsstrecke. In der Head Unit kann auf eine Implementierung zurückgegriffen werden. Eines der beiden Displays benötigt eine Schnittstelle für Touch-Eingaben, welche durch das andere Display nicht unterstützt werden. Das Touchdisplay kann einen weiteren Kommandokatalog implementieren, ohne Seiteneffekte auf das erste Display. Weitere Touch-Geräte könnten dann wiederum auf den bereits implementierten Kommandokatalog zurückgreifen.
-
Entsprechend ist bei einem weiteren Ausführungsbeispiel der Erfindung mindestens ein drittes Human Interfache Device vorgesehen, wobei das erste Human Interface Device über einen ersten Fahrzeugdatenbus mit der Head Unit verbunden ist und wobei das zweite Human Interface Device und das dritte Human Interface Device über einen zweiten Fahrzeugdatenbus mit der Head Unit verbunden sind. Durch eine Datenbusstruktur und eine generische Kommunikationsschnittstelle ist es ohne Weiteres möglich, dass sich verschiedene Geräte zumindest teilweise die gleiche kommunikationsstrecke teilen.
-
Die verschiedenen in dieser Anmeldung genannten Ausführungsformen der Erfindung sind, sofern im Einzelfall nicht anders ausgeführt, mit Vorteil miteinander kombinierbar.
-
Die Erfindung wird nachfolgend in Ausführungsbeispielen anhand der zugehörigen Zeichnungen erläutert. Es zeigen:
- 1 eine Spezifikationsstruktur eines Ausführungsbeispiels einer Kommunikationsschnittstelle,
- 2 eine schematische Darstellung einer Systemkonfiguration für Ein- und Ausgabegeräte eines Ausführungsbeispiels einer Kommunikationsschnittstelle,
- 3 einen Kommunikationskanal der Kommunikationsschnittstelle,
- 4 ein Ausführungsbeispiel eines Datenrahmens für eine Kommunikationsschnittstelle,
- 5 die Signifikanz eines Bits innerhalb eines Bytes der Kommunikationsschnittstelle,
- 6 das Auffüllen mit Nullen für nicht zutreffende Bits der Kommunikationsschnittstelle,
- 7 mögliche Richtungen der Kommunikationen der Kommunikationsschnittstelle,
- 8 den schematischen Ablauf des Sendens neuer Daten über die Kommunikationsschnittstelle,
- 9 den schematischen Ablauf des Abfragens aktueller Daten über die Kommunikationsschnittstelle,
- 10 den schematischen Ablauf für das Ändern von Daten über die Kommunikationsschnittstelle,
- 11 eine schematische Darstellung für den Start beziehungsweise Reset der Human Interface Devices und
- 12 eine schematische Darstellung für das Abrufen aller Daten über die Kommunikationsschnittstelle.
-
1 zeigt, dass für spezifische Funktionen 102 einer Kommunikationsschnittstelle 10 eine Datenfestlegung 104 existiert, die in 1 mit 106 als HID Commands gekennzeichnet ist, die eine konkrete Implementierung beschreibt. Die allgemeingültige Kommunikationsschnittstelle 10 nutzt dabei den ISO TP-Standard 108.
-
2 zeigt eine Kommunikationsschnittstelle 10 in einem Fahrzeug zwischen einer Head Unit 12 und mehreren Human Interface Devices 14. Zur Anbindung wird ein generischer Ansatz genutzt, bei dem die Kommunikationsschnittstelle 10 zentral definiert wird und für alle Kommunikationsstrecken, die diese Kommunikationsschnittstelle 10 nutzen, ihre Gültigkeit besitzt.. Von der Head Unit 12 werden Videosignale 16 zu mehreren Human Interface Devices 14 unabhängig übertragen. Eine Kommunikationsstrecke wird dabei durch separate CAN-Bus 20 Verbindungen realisiert. Die Kommunikationsschnittstelle 10 nutzt in diesem Ausführungsbeispiel eine aufweckfähige 2 Mbit/sec High Speed CAN-Verbindung.
-
3 zeigt, dass für jede Verbindung auf Anwendungsebene ein bidirektionaler Kommunikationskanal 30 etabliert wird. Für eine Richtung werden separate CAN-IDs für die Datenübertragung und für die ISO TP-Segmentierungssteuerung genutzt.
-
Eine Anforderungsnachricht überträgt Daten von LCU A 32 zu LCU B 34. Die Antwortnachricht 36 wird nur für die ISO TP Flow Control Frames verwendet. Dies geschieht, um Kollisionen zu verhindern, wenn zwei Geräte gleichzeitig segmentierte TP-Nachrichten senden wollen. Um Daten von LCU B 32 zu LCU A 34 zu übertragen, muss ein sekundärer Kommunikationskanal mit Anfrage- und Antwortnachricht verwendet werden. Für jeden Befehlskatalog ist ein separater Kommunikationskanal zu verwenden.
-
4 zeigt einen Datenrahmen 38 nach dem ISO TP Standard. Um den Austausch verschiedener Informationen zu trennen, werden HID-Befehle 40 als erster Parameter im ISO TP-Datenrahmen verwendet. Die Befehle und ihre Datenstruktur werden in anwendungsfallabhängigen HID-Kommandokatalogen definiert. Das erste Byte eines ISO TP-Datenrahmens enthält den HID-Befehl. Innerhalb einer Nachricht ist die Big-Endian-Byte-Reihenfolge zu verwenden, sofern dies nicht kommandospezifisch, aufgrund applikativer Vorteile, gegenteilig spezifiziert wird. Dies ist der Fall, wenn über einen Befehl beziehungsweise eine Abfrage alle für das jeweilige Human Interface Device unterstützte Kommandos abgefragt werden.
-
5 zeigt die in dem Ausführungsbeispiel zu verwendende Aufteilung der Signifikanz der Bits in einem Byte 42.
-
6 zeigt, dass als Datentyp für einen Befehl nur ein Vielfaches von Bytes 42 zulässig ist, die in der Darstellung in 6 in ihrer Relevanz von oben nach unten abnehmen. Wenn ein Wert nicht genau in ein oder mehrere Bytes passt, werden nicht verwendete Bits und Bytes mit Nullen aufgefüllt. In 6 ist ein Beispiel für einen 10-Bit-Wert innerhalb einer drei Byte langen Nachricht dargestellt.
-
In 7 wird dargestellt, dass es möglich ist, Daten als Folge einer Statusänderung zu senden, den aktuellen Status abzufragen oder eine Statusaktualisierung anzufordern. Das Human Interface Device 14 ist der Datenstamm und überträgt Änderungen und Aktionen als STATUS-Nachricht 44 an die Head Unit 12. Die Head Unit 12 kann durch Senden einer GET-Nachricht 46 Daten anfordern und durch Senden einer SETGET-Nachricht 48 eine Datenänderung anfordern.
-
8 zeigt, dass alle Human Interface Devices 14 ihren aktuellen Status durch Senden von STATUS-Nachrichten 44 liefern. Jede interne Statusänderung eines Human Interface Devices 14 ist der Head Unit 12 durch Senden einer STATUS-Nachricht 44 mit den neuen gültigen Informationen zu melden, die durch einen TakeOverValue 50 registriert werden. Eine STATUS-Nachricht 44 ist eine Datenoperationsnachricht und enthält einen HID-Befehl als ersten Parameter. Die folgenden Bytes enthalten die Daten, wie sie im Kommandokatalog definiert sind.
-
9 zeigt, dass durch Senden einer GET-Nachricht 46 von der Head Unit 12 eine STATUS-Nachricht 44 angefordert werden kann. Eine GET-Nachricht 46 enthält den HID-Befehl als ersten Parameter.
-
10 zeigt, dass es möglich ist, verschiedene Daten im Human Interface Device 14 zu ändern. Beispielsweise kann ein System-Aktor 52 eine Eigenschaft mit Hilfe der Head Unit 14 ändern. Die Head Unit 14 ist in der Lage, SETGET-Nachrichten 48 für angegebene Befehle zu senden, um eine Eigenschaftsänderung anzufordern. Eine SETGET-Nachricht 48 ist eine Datenoperationsnachricht und enthält den HID-Befehl als ersten Parameter. Die folgenden Bytes enthalten die Daten, wie sie im HID-Befehlskatalog definiert sind. SETGET-Nachrichten 48 müssen durch Senden einer STATUS-Nachricht 44 mit dem neuen eingestellten Wert beantwortet werden. Kann eine SETGET-Nachricht 48 nicht durch das Human Interface Device 14 behandelt werden, weil zum Beispiel die angeforderte Änderung den Wertebereich für diesen Befehl überschritten hat, kann die STATUS-Nachricht 44 den letzten gültigen Wert enthalten.
-
11 zeigt, dass während des Startvorgangs entweder das Human Interface Device 14 oder das Gegenstück schneller starten kann. Jede LCU muss in der Lage sein, die Kommunikation innerhalb von 600 ms aufzubauen. Falls das Human Interface Device 14 schneller ist - in 11 durch A dargestellt - ist die Nachricht FetchAll/Reset.STATUS 54 nicht relevant. Das Gegenstück muss alle Eigenschaften anfordern, sobald es bereit ist. Wenn das Human Interface Device 14 später startet - in 11 durch B dargestellt - muss es seinen Start anzeigen, um die Verfügbarkeit neuer Daten zu signalisieren, weil FetchAll/Reset.GET-Nachrichten 56 nicht beantwortet werden. Zu diesem Zweck muss das Human Interface Device 14 eine eine FetchAll/Reset.STATUS-Nachricht 54 senden.
-
Nach einer FetchAll/Reset.STATUS-Nachricht 54 sollte das Gegenstück den aktuellen Status für alle Befehle abfragen - durch D dargestellt -, wie dies bei einem regulären Start ebenfalls ausgeführt werden würde, da Werte im Cache möglicherweise ungültig geworden sind. Die Head Unit 12 darf eine Wiederholung der FetchAll/Reset.GET-Nachricht 56 durchführen - mit C dargestellt -, um den Start des Human Interface Device 14 zu überwachen. Wenn in dem funktionsspezifischen Kommandokatalog keine Definitionen vorgenommen werden, führt die Head Unit 12 einen Wiederholungsversuch mit 1 s (nach dem gemeldeten Standard-Timeout) durch. Die Übermittlung aller Daten ist in 11 durch E verdeutlicht.
-
12 zeigt, dass es möglich ist eine STATUS-Nachricht 44 für alle unterstützten Befehle 58 auf einmal zu erhalten, um zu vermeiden, dass der aktuelle Status für jeden Befehl einzeln abgerufen wird. Das Senden einer FetchAll/Reset.GET-Nachricht 58 an das Human Interface Device 14 muss vom Gerät mit allen unterstützten STATUS-Nachrichten 44 beantwortet werden. Eine FetchAII.GET-Nachricht enthält wie jede GET-Nachricht 44 den HID-Befehl als ersten Parameter. Die folgenden Bytes werden nicht verwendet.
-
Bezugszeichenliste
-
- 10
- Kommunikationsschnittstelle
- 12
- Head Unit
- 14
- Human Interface Device
- 16
- Videosignale
- 28
- CAN-Bus
- 30
- Bidirektionaler Kommunikationskanal
- 32
- LCU A
- 34
- LCU B
- 36
- Antwortnachricht
- 38
- Datenrahmen
- 40
- HID-Befehl
- 42
- Byte
- 44
- STATUS-Nachricht
- 46
- GET-Nachricht
- 48
- SETGET-Nachricht
- 50
- TakeOverValue
- 52
- System-Aktor
- 54
- FetchAll/Reset.STATUS-Nachricht
- 56
- FetchAll/Reset.GET-Nachricht
- 58
- Unterstützte Befehle
- 102
- Spezifische Funktion
- 104
- Datenfestlegung
- 106
- HID-Command
- 108
- ISO TP-Standard
-
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 2012/0192119 A1 [0004]
