WO2022053341A1 - Kommunikationsschnittstelle - Google Patents

Kommunikationsschnittstelle Download PDF

Info

Publication number
WO2022053341A1
WO2022053341A1 PCT/EP2021/073818 EP2021073818W WO2022053341A1 WO 2022053341 A1 WO2022053341 A1 WO 2022053341A1 EP 2021073818 W EP2021073818 W EP 2021073818W WO 2022053341 A1 WO2022053341 A1 WO 2022053341A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface device
human interface
communication
communication interface
head unit
Prior art date
Application number
PCT/EP2021/073818
Other languages
English (en)
French (fr)
Inventor
Roy Bühring
Original Assignee
Volkswagen Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Volkswagen Aktiengesellschaft filed Critical Volkswagen Aktiengesellschaft
Priority to CN202180055141.1A priority Critical patent/CN116018783A/zh
Priority to US18/044,305 priority patent/US20240031198A1/en
Publication of WO2022053341A1 publication Critical patent/WO2022053341A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40104—Security; Encryption; Content protection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Definitions

  • the invention relates to a communication interface in a vehicle between a head unit and at least a first human interface device (HID) and a second human interface device (HID), data being exchanged between the head unit and the first human interface device via a first communication path and wherein data is exchanged between the head unit and the second human interface device via a second communication path.
  • HID human interface device
  • HID human interface device
  • control devices A large number of sensor devices, control units and control computers are installed in modern motor vehicles. These elements are usually connected to one another via an on-board network, which is often implemented as a bus system. Data can be exchanged with each other via the bus system. External higher-level systems can also be addressed via an interface.
  • the control devices, control computers and sensor devices collectively referred to below as control devices, are designed to carry out various monitoring and control functions occurring in the vehicle. This includes, among other things, the control and/or monitoring of the engine and transmission controls or anti-lock braking systems. Some of these systems have to work in real time or with as little time delay as possible, since important processes such as braking deceleration have to be controlled.
  • US 2012/0192119 A1 shows a method for implementing USB communication with an interface in which at least one gesture and an angle of a finger position for a touch-resistant input device are measured.
  • tactile image information is recorded by a tactile sensor in real time in order to to get parameters. This information is converted into UBS-HID messages, which are transmitted to a host device.
  • the communication interfaces in vehicles known from the prior art have the disadvantage that they are sometimes subject to a high degree of latency and/or require a comparatively complex stack.
  • the invention is therefore based on the object of specifying a communication interface in a vehicle that is flexible, has low latency and is comparatively lightweight.
  • a human interface device is a type of computer that interacts directly with people, usually also accepts input from people and, if necessary, also returns output to people.
  • HID is often used in connection with USB devices, then in connection with USB-HID.
  • keyboards, mice, joysticks, graphics tablets, but also, in particular, displays or tablet computers can be understood as human interface devices.
  • buttons integrated in the vehicle are also conceivable, for example on the steering wheel, but also options for voice control and/or gesture control.
  • a head unit is the main unit of the infotainment system, which combines the car radio, navigation system, hands-free system, driver assistance systems and other functions in a vehicle in a central control unit.
  • the main unit comprises one or more main circuit boards, which are equipped with processors and the like and form the heart of the infotainment system.
  • a centrally defined communication interface offers the advantage of defined generic communication that can be used for a wide variety of applications.
  • a transport layer which enables data to be transmitted to be segmented.
  • the transport layer or a sending node of the transport layer can independently attempt to send a message. If the request could not be successfully executed after e.g. 1 s, a timeout signal is output. Depending on the use case, it can be decided to resend a message. For example, if a "button press" is sent with a delay of 1 s, the delayed reaction of the system is not understandable for the user.
  • an application layer is provided which enables bidirectional data exchange between the head unit and the first human interface device and/or the second human interface device. Since the Human Interface Device is the master data, it must contain the necessary values.
  • current statuses of the first human interface device and/or the second human interface device can be communicated and/or queried. All integrated human interface devices must transmit their current status or transmit status messages. The status messages can also be queried using certain commands.
  • a further embodiment provides that a change in the current status of the first human interface device and/or the second human interface device can be requested. It can be provided that each status change of an integrated human interface device is transmitted to the head unit by the human interface device.
  • a status message is to be understood as a data operation message. This contains, among other things, a HID command.
  • an operation carried out by the first human interface device and/or by the second human interface device can be assigned to a command that is defined in a command catalog.
  • the commands and their data structure can be stored in application-dependent command catalogues. It is conceivable that all commands supported for the respective human interface device can be queried via a command or a query.
  • the following commands are possible as examples, but should not be understood as an exhaustive list:
  • a GET request triggers a request for a supported command.
  • the human interface device By sending a FetchALL/Reset.GET request, the human interface device will respond with all appropriate status messages to provide the current status of the HID without having to request each property individually.
  • a STATUS message indicates that a status of a human interface device has changed.
  • the HID can indicate its start, for example if the HID started later than a corresponding counterpart. This can also signal a reset of the HID.
  • the counterpart requests the current status for all commands because values in the cache may have become invalid.
  • a CommandSupport request can cause dynamic communication of the commands supported by the human interface device that are defined within the command catalog.
  • the centrally defined communication interface uses the ISO TP standard.
  • HID commands are used as the first parameters in the ISO TP data frame.
  • the commands and their data structure are then defined accordingly in application-dependent command catalogues.
  • the first byte of an ISO TP data frame contains the HID command.
  • the big-endian byte order is used within a message, provided this has not been specified to the contrary by a command. This can be the case, for example, if all commands supported for the respective human interface device are queried via a command or a query. Only a multiple of bytes is permitted as a data type for an instruction. If a value does not fit exactly into one or more bytes, unused bits and bytes are zero-padded.
  • At least one vehicle data bus in particular a CAN bus, is provided for signal transmission for communication that is comparatively simple.
  • a vehicle data bus has the advantage that, as a rule, several equal control units are connected to one another can become.
  • the CAN network works according to a line structure. Spur lines are permitted to a limited extent, as is a star-shaped bus.
  • the star-shaped bus has the disadvantage that it is usually controlled by the central computer, since all information has to pass through the central computer. Thus, if the central computer fails, the entire system would be inoperable.
  • the line characteristic impedance is somewhat more complex to determine for stub lines and also for the star-shaped architecture.
  • a further exemplary embodiment of the communication interface according to the invention provides that a video signal can be transmitted from the head unit to the first human interface device and/or the second human interface device.
  • two displays require the communication interface as a human interface device, for example to switch the display lighting on/off. Both displays implement a common catalog of commands with an individual communication path. An implementation can be accessed in the head unit.
  • One of the two displays requires an interface for touch inputs, which the other display does not support.
  • the touch display can implement another command catalog without side effects on the first display. Other touch devices could then in turn use the command catalog that has already been implemented.
  • At least a third human interface device is provided, the first human interface device being connected to the head unit via a first vehicle data bus, and the second human interface device and the third human interface device being connected to the head unit via a second vehicle data bus connected to the head unit.
  • a data bus structure and a generic communication interface make it easily possible for different devices to at least partially share the same communication path.
  • FIG. 1 shows a specification structure of an embodiment of a communication interface
  • FIG. 2 shows a schematic representation of a system configuration for input and output devices of an exemplary embodiment of a communication interface
  • Figure 3 a communication channel of the communication interface
  • FIG. 4 shows an exemplary embodiment of a data frame for a communication interface
  • FIG. 5 the significance of a bit within a byte of the communication interface
  • FIG. 6 the padding with zeros for non-applicable bits of the communication interface
  • FIG. 8 shows the schematic sequence of sending new data via the communication interface
  • FIG. 9 shows the schematic process of querying current data via the communication interface
  • FIG. 10 shows the schematic sequence for changing data via the communication interface
  • Figure 11 is a schematic representation of the start or reset of the human interface devices.
  • FIG. 12 shows a schematic representation for the retrieval of all data via the communication interface.
  • FIG. 1 shows that a data definition 104 exists for specific functions 102 of a communication interface 10, which is identified in FIG. 1 with 106 as HID Commands, which describes a specific implementation.
  • the universal communication interface 10 uses the ISO TP standard 108.
  • Figure 2 shows a communication interface 10 in a vehicle between a head unit 12 and a plurality of human interface devices 14.
  • a generic approach is used for the connection, in which the communication interface 10 is defined centrally and its validity is valid for all communication links that use this communication interface 10 owns ..
  • video signals 16 are transmitted to a plurality of human interface devices 14 independently.
  • a communication route is realized by separate CAN bus 20 connections.
  • the communication interface 10 uses a wake-up capable 2 Mbit/sec high-speed CAN connection.
  • FIG. 3 shows that a bidirectional communication channel 30 is established for each application-level connection. For one direction, separate CAN IDs are used for data transmission and for ISO TP segmentation control.
  • a request message transfers data from LCU A 32 to LCU B 34.
  • the response message 36 is only used for the ISO TP Flow Control Frames. This is done to prevent collisions when two devices want to send segmented TP messages at the same time.
  • a secondary communication channel with request and response message must be used. A separate communication channel must be used for each command catalog.
  • FIG. 4 shows a data frame 38 according to the ISO TP standard.
  • HID commands 40 are used as the first parameter in the ISO TP data frame.
  • the commands and their data structure are defined in application-dependent HID command catalogs.
  • the first byte of an ISO TP data frame contains the HID command.
  • the big endian byte order is to be used within a message, unless this is specified to the contrary in a command-specific manner due to application advantages. This is the case when all commands supported for the respective human interface device are queried via a command or a query.
  • Figure 5 shows the division of the significance of the bits in a byte 42 to be used in the exemplary embodiment.
  • FIG. 6 shows that only a multiple of bytes 42 is permissible as a data type for an instruction, the relevance of which decreases from top to bottom in the representation in FIG. If a value does not fit exactly into one or more bytes, unused bits and bytes are included filled with zeros.
  • FIG. 6 shows an example of a 10-bit value within a three-byte message.
  • FIG. 7 shows that it is possible to send data as a result of a status change, to query the current status or to request a status update.
  • the human interface device 14 is the data master and transmits changes and actions as a STATUS message 44 to the head unit 12.
  • the head unit 12 can request data by sending a GET message 46 and request a data change by sending a SETGET message 48.
  • FIG. 8 shows that all human interface devices 14 provide their current status by sending STATUS messages 44 . Any internal status change of a human interface device 14 is to be reported to the head unit 12 by sending a STATUS message 44 with the new valid information registered by a TakeOverValue 50 .
  • a STATUS message 44 is a data operation message and contains a HID command as the first parameter. The following bytes contain the data as defined in the command catalog.
  • FIG. 9 shows that a STATUS message 44 can be requested by the head unit 12 by sending a GET message 46 .
  • a GET message 46 contains the HID command as the first parameter.
  • FIG. 10 shows that it is possible to change various data in the human interface device 14.
  • a system actor 52 can change a property using the head unit 14 .
  • the head unit 14 is capable of sending SETGET messages 48 for specified commands to request a property change.
  • a SETGET message 48 is a data operation message and contains the HID command as the first parameter. The following bytes contain the data as defined in the H ID command catalog.
  • SETGET messages 48 must be answered by sending a STATUS message 44 with the new set value. If a SETGET message 48 cannot be handled by the human interface device 14, for example because the requested change has exceeded the value range for that command, the STATUS message 44 can contain the last valid value.
  • FIG. 11 shows that either the human interface device 14 or the counterpart can start faster during the starting process.
  • Each LCU must be able to communicate set up within 600 ms. If the human interface device 14 is faster - represented by A in Figure 11 - the FetchAII/Reset.STATUS message 54 is not relevant. The mate must request all properties as soon as it is ready. When the human interface device 14 later starts - represented by B in Figure 11 - it must indicate its start to signal the availability of new data because FetchAII/Reset.GET messages 56 are not answered. For this purpose, the Human Interface Device 14 must send a FetchAII/Reset.STATUS message 54 .
  • the mate After a FetchAII/Reset.STATUS message 54, the mate should query the current status for all commands - represented by D - as it would on a regular start as well, since values in the cache may have become invalid.
  • the head unit 12 is allowed to repeat the FetchAII/Reset.GET message 56 - shown with C - to monitor the start of the human interface device 14. If no definitions are made in the function-specific command catalog, the head unit 12 performs a retry with 1 s (after the reported standard timeout). The transmission of all data is illustrated by E in FIG.
  • Figure 12 shows that it is possible to receive a STATUS message 44 for all supported commands 58 at once to avoid getting the current status for each command individually.
  • Sending a FetchAII/Reset.GET message 58 to the Human Interface Device 14 must be answered by the device with all supported STATUS messages 44.
  • a FetchAII.GET message contains the HID command as the first parameter. The following bytes are not used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

Die Erfindung betrifft eine Kommunikationsschnittstelle (10) in einem Fahrzeug zwischen einer Head Unit (12) und Human Interface Devices (14), die flexibel, latenzarm und vergleichsweise leichtgewichtig ist, wird dadurch gekennzeichnet, dass die Kommunikationsschnittstelle (10) zentral definiert ist, sodass sie für alle Kommunikationsstrecken ihre Gültigkeit besitzt.

Description

Beschreibung
Kommunikationsschnittstelle
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 FetchAII/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:
Figur 1 eine Spezifikationsstruktur eines Ausführungsbeispiels einer Kommunikationsschnittstelle, Figur 2 eine schematische Darstellung einer Systemkonfiguration für Ein- und Ausgabegeräte eines Ausführungsbeispiels einer Kommunikationsschnittstelle,
Figur 3 einen Kommunikationskanal der Kommunikationsschnittstelle,
Figur 4 ein Ausführungsbeispiel eines Datenrahmens für eine Kommunikationsschnittstelle,
Figur 5 die Signifikanz eines Bits innerhalb eines Bytes der Kommunikationsschnittstelle,
Figur 6 das Auffüllen mit Nullen für nicht zutreffende Bits der Kommunikationsschnittstelle,
Figur 7 mögliche Richtungen der Kommunikationen der Kommunikationsschnittstelle,
Figur 8 den schematischen Ablauf des Sendens neuer Daten über die Kommunikationsschnittstelle,
Figur 9 den schematischen Ablauf des Abfragens aktueller Daten über die Kommunikationsschnittstelle,
Figur 10 den schematischen Ablauf für das Ändern von Daten über die Kommunikationsschnittstelle,
Figur 11 eine schematische Darstellung für den Start beziehungsweise Reset der Human Interface Devices und
Figur 12 eine schematische Darstellung für das Abrufen aller Daten über die Kommunikationsschnittstelle.
Figur 1 zeigt, dass für spezifische Funktionen 102 einer Kommunikationsschnittstelle 10 eine Datenfestlegung 104 existiert, die in Figur 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. Figur 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.
Figur 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.
Figur 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.
Figur 5 zeigt die in dem Ausführungsbeispiel zu verwendende Aufteilung der Signifikanz der Bits in einem Byte 42.
Figur 6 zeigt, dass als Datentyp für einen Befehl nur ein Vielfaches von Bytes 42 zulässig ist, die in der Darstellung in Figur 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 Figur 6 ist ein Beispiel für einen 10-Bit-Wert innerhalb einer drei Byte langen Nachricht dargestellt.
In Figur 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.
Figur 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.
Figur 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.
Figur 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 H ID-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.
Figur 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 Figur 11 durch A dargestellt - ist die Nachricht FetchAII/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 Figur 11 durch B dargestellt - muss es seinen Start anzeigen, um die Verfügbarkeit neuer Daten zu signalisieren, weil FetchAII/Reset.GET- Nachrichten 56 nicht beantwortet werden. Zu diesem Zweck muss das Human Interface Device 14 eine eine FetchAII/Reset.STATUS-Nachricht 54 senden.
Nach einer FetchAII/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 FetchAII/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 Figur 11 durch E verdeutlicht.
Figur 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 FetchAII/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
Kommunikationsschnittstelle
Head Unit
Human Interface Device
Videosignale
CAN-Bus
Bidirektionaler Kommunikationskanal
LCU A
LCU B
Antwortnachricht
Datenrahmen
HID-Befehl
Byte
STATUS-Nachricht
GET-Nachricht
SETGET-Nach richt
TakeOverValue
System-Aktor
FetchAII/Reset.STATUS-Nach richt
FetchAII/Reset.GET-Nach richt
Unterstützte Befehle
Spezifische Funktion
Datenfestlegung
HID-Command
ISO TP-Standard

Claims

Patentansprüche Kommunikationsschnittstelle (10) in einem Fahrzeug zwischen einer Head Unit (12) und mindestens einem ersten Human Interface Device (HID) (14) und einem zweiten Human Interface Device (HID) (14) wobei ein Datenaustausch zwischen der Head Unit (12) und dem ersten Human Interface Device (14) über eine erste Kommunikationsstrecke stattfindet und wobei ein Datenaustausch zwischen der Head Unit (12) und dem zweiten Human Interface Device (14) über eine zweite Kommunikationsstrecke stattfindet, dadurch gekennzeichnet, dass die Kommunikationsschnittstelle (10) zentral definiert ist, sodass sie für alle Kommunikationsstrecken ihre Gültigkeit besitzt, dadurch gekennzeichnet, dass mindestens ein drittes Human Interfache Device (14) vorgesehen ist, dass das erste Human Interface Device (14) über einen ersten Fahrzeugdatenbus mit der Head Unit (12) verbunden ist und dass das zweite Human Interface Device und das dritte Human Interface Device (14) über einen zweiten Fahrzeugdatenbus mit der Head Unit (12) verbunden sind. Kommunikationsschnittstelle (10) nach Anspruch 1, dadurch gekennzeichnet, dass ein Transport- Layer vorgesehen ist, der eine Segmentierung von zu übertragenen Daten ermöglicht. Kommunikationsschnittstelle (10) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein Applikations-Layer vorgesehen ist, der einen bidirektionalen Datenaustausch zwischen der Head Unit (12) und dem ersten Human Interface Device (14) und/oder dem zweiten Human Interface Device (14) ermöglicht. Kommunikationsschnittstelle (10) nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass aktuelle Stati des ersten Human Interface Device (14) und/oder dem zweiten Human Interface Device (14) mitteilbar und/oder anfragbar sind. Kommunikationsschnittstelle (10) nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass eine Änderung des aktuellen Zustandes des ersten Human Interface Device (14) und/oder dem zweiten Human Interface Device (14) anfragbar sind. Kommunikationsschnittstelle (10) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass eine durch das erste Human Interface Device (14) und/oder durch das zweite Human Interface Device (14) ausgeführte Operation einem Kommando zuordenbar ist, das in einem Kommandokatalog definiert ist. Kommunikationsschnittstelle (10) nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die zentral definierte Kommunikationsschnittstelle (10) den ISO TP-Standard nutzt. Kommunikationsschnittstelle (10) nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass wenigstens ein Fahrzeugdatenbus, insbesondere CAN-Bus (18), zur Signalübertragung vorgesehen ist. Kommunikationsschnittstelle (10) nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass von der Head Unit (12) ein Videosignal (16) auf das erste Human Interface Device (14) und/oder das zweite Human Interface Device (14) übertragbar ist.
PCT/EP2021/073818 2020-09-08 2021-08-27 Kommunikationsschnittstelle WO2022053341A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180055141.1A CN116018783A (zh) 2020-09-08 2021-08-27 通信接口
US18/044,305 US20240031198A1 (en) 2020-09-08 2021-08-27 Communication Interface

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020211233.9A DE102020211233B4 (de) 2020-09-08 2020-09-08 Kommunikationsschnittstelle
DE102020211233.9 2020-09-08

Publications (1)

Publication Number Publication Date
WO2022053341A1 true WO2022053341A1 (de) 2022-03-17

Family

ID=77693526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/073818 WO2022053341A1 (de) 2020-09-08 2021-08-27 Kommunikationsschnittstelle

Country Status (4)

Country Link
US (1) US20240031198A1 (de)
CN (1) CN116018783A (de)
DE (1) DE102020211233B4 (de)
WO (1) WO2022053341A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120192119A1 (en) 2011-01-24 2012-07-26 Lester F. Ludwig Usb hid device abstraction for hdtp user interfaces
US20150051787A1 (en) * 2013-08-14 2015-02-19 Hti Ip, L.L.C. Providing communications between a vehicle control device and a user device via a head unit

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011106358A1 (de) 2011-07-02 2012-03-15 Daimler Ag Fahrerinformationssystem für einen Kraftwagen
US9144094B2 (en) 2012-10-29 2015-09-22 Qualcomm Incorporated Establishing a wireless display session between a computing device and a vehicle head unit
US9460037B2 (en) 2013-09-26 2016-10-04 Delphi Technologies, Inc. Flexible mobile device connectivity to automotive systems with USB hubs

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120192119A1 (en) 2011-01-24 2012-07-26 Lester F. Ludwig Usb hid device abstraction for hdtp user interfaces
US20150051787A1 (en) * 2013-08-14 2015-02-19 Hti Ip, L.L.C. Providing communications between a vehicle control device and a user device via a head unit

Also Published As

Publication number Publication date
DE102020211233B4 (de) 2023-01-19
DE102020211233A1 (de) 2022-03-10
CN116018783A (zh) 2023-04-25
US20240031198A1 (en) 2024-01-25

Similar Documents

Publication Publication Date Title
EP3429136B1 (de) Verfahren zur übertragung von daten über einen seriellen kommunikationsbus, entsprechend ausgelegter busschnittstelle sowie entsprechend ausgelegtem computerprogramm
EP2030116B1 (de) Kommunikationsbaustein
DE19963610B4 (de) Kommunikationssystem für Fahrzeugsteuerungen
DE69723726T2 (de) Anwendungsprogrammierungsschnittstelle für Datenübertragung und Busverwaltung einer Busstruktur
DE19637312A1 (de) Verfahren zur Kontrolle der Verbindungen eines Übertragungssystems und Komponente zur Durchführung des Verfahrens
EP2090031B1 (de) Verfahren und anordnung zur kommunikation auf einem lin-bus
WO1999030459A2 (de) Verfahren zur koordination von netzwerkkomponenten
WO2007093546A2 (de) Gateway zum automatischen routen von nachrichten zwischen bussen
WO2007134922A1 (de) Mehrprozessor-gateway
DE102009027625A1 (de) Elektrische Schaltung zur Übertragung von Signalen zwischen zwei Mastern und einem oder mehreren Slaves
EP1370914A1 (de) Verfahren zum betreiben eines verteilten sicherheitsrelevanten systems
DE102019106551A1 (de) Mehrfach-steuergerät für ein fahrzeug
EP0509114B1 (de) Verfahren zum Übertragen von Daten an mehrere Datenstationen
DE102020211233B4 (de) Kommunikationsschnittstelle
EP1410577B1 (de) Netzwerkkomponente für ein optisches netzwerk mit notlauffunktion, insbesondere für ein optisches netzwerk in ringtopologie
DE102006004191B4 (de) Deterministisches Kommunikations-System
DE102016008957B4 (de) Direkter Zugriff auf Bussignale in einem Kraftfahrzeug
DE60210521T2 (de) Datenübertragungs-Datenempfangssystem, Verfahren zur Wiederherstellung einer Verbindung und Nachrichtenübertragungs-/Nachrichtenempfangsvorrichtung
DE102019125493A1 (de) Slaveeinrichtung, Bussystem und Verfahren
DE10239846B4 (de) Fail-Silent-Steuergerät
DE102022124559A1 (de) Anhängernetzwerksystem zur Datenkommunikation in einem Anhängerfahrzeug sowie Anhängerfahrzeug damit und Verfahren dafür
DE102011083001B4 (de) Teilnehmer eines Kommunikationsnetzwerks und Verfahren zur deterministischen Übertragung über ein Kommunikationsmedium des Kommunikationsnetzwerks
EP4187858A1 (de) Eine sekundärsteuereinheit für ein fahrzeug mit einer primärsteuereinheit und einem datenübertragungsweg
DE102017215969A1 (de) Schienenfahrzeug mit Mehrkernrechenleistung
WO2017148743A1 (de) Speicherdirektzugriffssteuereinrichtung für eine einen arbeitsspeicher aufweisende recheneinheit

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 18044305

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 21766673

Country of ref document: EP

Kind code of ref document: A1