EP1994723A1 - Verfahren zur datenkommunikation mit einem bei einem kraftfahrzeug angeordneten kommunikationsteilnehmer mit dynamischer adressvergabe - Google Patents

Verfahren zur datenkommunikation mit einem bei einem kraftfahrzeug angeordneten kommunikationsteilnehmer mit dynamischer adressvergabe

Info

Publication number
EP1994723A1
EP1994723A1 EP07711819A EP07711819A EP1994723A1 EP 1994723 A1 EP1994723 A1 EP 1994723A1 EP 07711819 A EP07711819 A EP 07711819A EP 07711819 A EP07711819 A EP 07711819A EP 1994723 A1 EP1994723 A1 EP 1994723A1
Authority
EP
European Patent Office
Prior art keywords
communication
vehicle
address
motor vehicle
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07711819A
Other languages
English (en)
French (fr)
Inventor
Guenter Bruenner
Martin Baumgartner
Klaus Rebhan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
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 Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Publication of EP1994723A1 publication Critical patent/EP1994723A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • the invention relates to a method for data communication between a first communication station arranged in a motor vehicle and a second communication station arranged outside the motor vehicle, in which the first communication station can be addressed by the second communication station by means of a network address.
  • Such OBD access allows a point-to-point connection to an outside of the motor vehicle arranged communication participants, however, brings some disadvantages.
  • the amount of transferable data rates is limited and relatively low due to the bus system.
  • For the data transfer special hardware is required, which brings additional costs.
  • a separate communication infrastructure must be set up. Furthermore, it is only possible to communicate with a single communication partner at a time.
  • the object of the invention is to provide a simple method for data communication between a first arranged in a motor vehicle communication subscriber and a second arranged outside the motor vehicle communication subscriber, which allows the addressing of a large number of motor vehicles.
  • the network address of the first communication subscriber is determined by an address management unit arranged outside the motor vehicle and transmitted by the address management unit to the first communication user. This enables dynamic address assignment.
  • the first communication user can be addressed by means of the dynamically assigned network address for other communication users.
  • the network address is assigned to a central gateway (ZGW) of the motor vehicle, via which the entire data communication of the motor vehicle runs to the outside or from the outside. Since usually only a single such ZGW is present in the motor vehicle, the assigned network address then effectively refers to the motor vehicle as such. So it is the motor vehicle itself by means of him dynamic allocated network address for other communication participants, such as a diagnostic tester, addressable.
  • the ZGW is in such a case the first communication participant within the meaning of the invention.
  • a network address assigned to a motor vehicle need only be unique within the respective network.
  • the number of available network addresses of a network which is usually limited, then only needs to be sufficiently large that all motor vehicles that are to be integrated simultaneously in the network, different network addresses can be assigned.
  • Non-unique network addresses must be available to all potentially in-network vehicles.
  • the address management unit is designed as a DHCP server. This offers the advantage that state-of-the-art and reasonably priced devices and methods for implementing the invention can find application.
  • a request message containing a unique vehicle identifier of the motor vehicle is transmitted to the address management unit by a communication user arranged at the motor vehicle, for example the ZGW.
  • the request message essentially consists of the unique vehicle identifier itself.
  • the request message can also be provided by a the communication device arranged the motor vehicle are sent, which is not identical to the first communication participant in the sense of the invention.
  • the request message is sent by the ZGW.
  • a motor vehicle By sending the request message, a motor vehicle can effectively log on to the network as soon as it is physically connected to it. He is then assigned a network address, through which it is addressable for other network participants. Instead of a request message that contains a vehicle identifier or consists essentially in this vehicle identifier, any other request message can in principle be sent for this purpose. However, it offers advantages if a unique vehicle identifier is known by the address management unit. Namely, an association between the unique vehicle identifier and the assigned network address is made possible.
  • assignment data for the association between the unique vehicle identifier sent for the request and the subsequently determined network address are stored in the address management unit.
  • the storage can be done for example in list or table form.
  • the assignment is also possible with hindsight, i. It can be determined which motor vehicle was assigned to which network address. For example, for each ever or in a certain period of time integrated into the network motor vehicle, a network history are stored at the address management unit, which documents at what time the motor vehicle or its vehicle identifier which network address was assigned.
  • the address management unit is predestined, due to the fact that it assigns the network addresses to motor vehicles integrated in the network, to store such assignment data for later use, for instance for the possibility of interrogation by a network subscriber.
  • the address management unit can therefore also fulfill the task of an address switching unit, in which the network identifier belonging to a vehicle identifier can be queried by other communication users.
  • the functionality of the reproduction of assignment data is shifted to a separate address switching unit executed separately by the address management unit on request of a network participant.
  • assignment data for the association between the unique vehicle identifier sent for the request and the subsequently determined network address are stored in an address switching unit in which the network address belonging to a vehicle identifier can be interrogated by other communication users.
  • the assignment data can be transmitted from the address management unit to the separately executed address switching unit.
  • DNS Domain Name Server
  • the address switching unit is designed as a DNS server. This offers the advantage that state-of-the-art and reasonably priced devices and methods for implementing the invention can find application.
  • the unique vehicle identifier is preferably the chassis number of the motor vehicle.
  • the chassis number is a widely used and proven identifier for identifying a motor vehicle. From the prior art methods and devices are known to store the chassis number of a motor vehicle in data form in the motor vehicle and possibly output communication technology.
  • the determination or assignment of the network address by the address management unit can also be carried out according to a preferred embodiment of the invention depending on the vehicle identifier.
  • the assigned network address may, for example, depend on the vehicle identifier in such a way that a certain vehicle is preferably allocated a specific network address, for example a network address which has already been allocated to the same vehicle earlier.
  • the communication between the first and the second communication subscriber via a standard interface, in particular an Ethernet interface.
  • the communication between the first and the second communication subscriber preferably takes place via a standard protocol, in particular TCP / IP.
  • TCP / IP a standard protocol
  • the assignment according to the invention of a network address, for example an IP address allows the use of most modern network technologies and the associated devices and methods.
  • the uses of standard devices and methods usually brings great cost advantages and high reliability, especially in high volumes.
  • very high data rates are transferable. For example, a data transmission via Ethernet with up to twenty times the data rate compared to OBD.
  • the invention allows a comfortable addressing of all communication users. If the communication technology used so provides, the simultaneous communication of a communication subscriber with several other communication participants is also possible.
  • a network according to the invention in particular an Ethernet network, allows a diagnostic tester to communicate simultaneously with a plurality of vehicles and / or for a plurality of diagnostic testers to communicate simultaneously with a vehicle.
  • an input data stream transmitted by the second communication user during data communication is converted on the vehicle side in the first communication user into a diagnostic data stream in the data format of a conventional diagnostic communication by means of a vehicle access application.
  • the diagnostic data stream is therefore reconstructed on the vehicle side.
  • the diagnostic messages present in the second communication subscriber for example a diagnostic tester, in the data format of a conventional diagnostic communication, ie in the conventional diagnostic message format, are therefore preferably only preprocessed, for example packetized, in the diagnostic tester by means of the selected standard technology, for example TCP / IP over Ethernet, to that first communication participants can be transmitted.
  • the data only has to be viewed up to the transport level (and above).
  • the data processing in the lower communication levels is done by the standard components of the standard technology used.
  • the data stream arriving at the first communication station is converted back into the diagnostic message format by the corresponding processing steps of the vehicle access application which are inverse to the preprocessing.
  • the consideration can be limited to the transport level.
  • the same diagnosis messages are present which were initially present on the other side of the communication connection at the second communication participant.
  • the thus reconstructed diagnostic data stream can then be further processed in the same manner on the vehicle side, as is known from conventional diagnostic communication. It is thus a very simple vehicle-side implementation of the method possible in which hardly or no vehicle components must be changed.
  • the described method provides a very slim transmission protocol with very low overhead for the transmission of standardized diagnosis messages.
  • standard diagnostic messages can be transferred without delay, secured, without large intermediate buffers in the vehicle and out of the vehicle.
  • a multiplexer control bytes allows the extension to other types of data as diagnostic messages.
  • the OBD access, in particular the OBD connector, of the motor vehicle can continue to be used in a conventional manner.
  • a separate connection is provided for the other communication technology used, eg Ethernet.
  • free contacts of the OBD connector are used, to which the signals of the other communication technology used, eg Ethernet, are launched. It must then be provided no additional connector.
  • the conventional OBD connection and the additional communication connection, eg Ethernet are combined in one plug-in connection. It This saves the cost of additional connectors. It also eliminates the time and expense of actually plugging multiple plugs.
  • a gateway unit similar to the CFFS described in WO 2005/076103 A2 can be used on the vehicle side.
  • the unique vehicle identification of the motor vehicle can also be queried by a network subscriber arranged outside the motor vehicle.
  • a query message is sent to the network address assigned to the motor vehicle by the querying network subscriber.
  • the motor vehicle responds to this query message with a response message containing the unique vehicle identifier of the motor vehicle. It is also a non-directional query of all vehicles in a network or network segment by means of broadcast possible (for example, request on the broadcast address, all vehicles in a subnet answer).
  • the querying network subscriber can basically be any other network subscriber, for example another motor vehicle integrated in the network.
  • the query can also be linked to the condition of an authorization.
  • the query can be permitted, for example, only those network users who have a separate authorization to do so.
  • the polling network participant may also be a network-side vehicle detection service.
  • a list of several, preferably all, current or ever or in a certain period registered in the network motor vehicles are created. This can be advantageous, for example, for documentation purposes in vehicle production or vehicle service.
  • Purpose of the query of the vehicle identifier by the querying network subscriber may be to allow an association between vehicle identifiers and network addresses.
  • the list of a vehicle recognition service preferably also permits an assignment between the vehicle identifiers and one or more assigned network addresses.
  • Such an association between the network address and the received vehicle identifier is generally easily possible for the querying network subscriber if the latter has previously addressed the respective motor vehicle deliberately via its network address and has then received the vehicle identifier as an immediate response. Nevertheless, it may be advantageous if, in addition to the vehicle identifier, the network address is also transmitted to the polling network subscriber. The assignment can be further simplified.
  • the network subscriber receiving the vehicle identification can thereby also make an association between the network address and the vehicle identification in cases in which the vehicle identification has been sent to him unsolicited or at the request of another network subscriber.
  • a motor vehicle after the assignment of a network address by the address management unit, to automatically transmit its unique vehicle identifier together with the assigned network address to a vehicle recognition service. If this is done in such a way for all motor vehicles registered on the network, the vehicle recognition service is fully informed about the association between network addresses and vehicle identifications.
  • a query without detailed consideration of the respective network address is sent to all currently registered in the network vehicles.
  • Such a vehicle detection service is preferably provided in addition to an address management unit and possibly an address switching unit. It can also completely or partially fulfill the task of an address switching unit if the assignment list of the vehicle recognition service allows an association between vehicle identifications and network addresses which can be interrogated by other communication users.
  • An address switching unit may also serve for queries of the type which network address is assigned to which vehicle identification, while a vehicle recognition service is used for queries of the type which motor vehicle is currently integrated in a network. The possibility of direct query or controlled by another event output of the vehicle identifier access to an address management unit or an address switching unit can be avoided if such a unit is overloaded, unavailable or failed.
  • a diagnostic tester directly (without network) to the motor vehicle.
  • the direct query of the vehicle identifier can also be used to determine the vehicle identifier by the diagnostic tester.
  • a network subscriber may also be simpler for a network subscriber to make a direct query of the unique vehicle identifier with a current or potential communication partner than to inquire with the address management unit or the address switching unit.
  • network subscribers who are not authorized to query the assignment data of the address management unit or of the address switching unit can be given the option of querying the unique vehicle identifier of a current or potential communication partner in individual cases.
  • the second communication subscriber according to the invention is designed according to a preferred embodiment of the invention as a diagnostic tester.
  • the diagnostic tester can then address a motor vehicle with which it is to be connected, for example for diagnostic purposes, using its network address. If only the vehicle identifier of the motor vehicle is known in the diagnostic tester, the current network address assigned to the vehicle identifier can optionally be queried by an address switching unit. If a vehicle recognition service is available, it may also be requested by the diagnostic tester at the vehicle recognition service whether the relevant motor vehicle is currently integrated in the network.
  • Fig. 2 shows the essential processing steps of a preferred embodiment of a vehicle access application
  • FIG 3 shows the essential signal flows in a preferred embodiment of a method according to the invention.
  • the central gateway (CCW) 1 of a motor vehicle communicates with a diagnostic tester 2 for diagnostic purposes.
  • the diagnostic communication is shown by arrow 3.
  • the diagnostic communication takes place via an Ethemet connection.
  • the vehicle For communication in the network, the vehicle is assigned an IP address.
  • the vehicle is assigned an IP address by the DHCP server 5 when the vehicle is connected to the network.
  • the vehicle transmits its chassis number, also called VIN (vehicle identification number) (arrow 6), to the DHCP server 5.
  • VIN vehicle identification number
  • the DHCP server tells the vehicle or the CCW 1 in return an IP address (arrow 7).
  • the DHCP server 5 assignment data for assignment between VIN and assigned IP address to a not specifically graphically represented DNS server on.
  • the DNS server is thus later able to output the network address to a specific chassis number.
  • a vehicle detection service 4 is provided on the network side. After the IP address has been assigned, the ZGVV 1 of the vehicle sends by broadcast (arrow 8) the chassis number of the vehicle to the network-side vehicle recognition service 4. This broadcast 8 is received and evaluated by the network-side vehicle recognition service 4. The network-side vehicle recognition service 4 uses the received chassis numbers to create a list of all vehicles currently connected to the network with chassis number and IP address.
  • the ZGW 1 of the vehicle also provides on separate external query (arrow 9) the chassis number of the vehicle to the network-side vehicle detection service. 4
  • the function of the component VCM 10 (Vehicle Configuration Management) likewise shown in FIG. 3 and connected to the ZGW 1 is essentially known from the prior art.
  • the function VCM 10 provides the chassis number in this example.
  • the component UGW 11 likewise shown in FIG. 3 and connected to the ZGW 1 essentially corresponds to a CFFS known from WO 2005/076103 A2. Unlike FIG. 3, functions VCM 10 and UGW 11 may also be performed by ZGW 1.
  • FIG. 1 and FIG. 2 show details of the diagnostic communication 3 between the ZGW 1 and the diagnostic tester 2.
  • Fig. 1 shows the communication-technical layers of a diagnostic message to be sent.
  • the diagnostic message is present as such (layer "application") in the diagnostic tester
  • each diagnosis message is provided with a header (packet header, layer “packetization”).
  • packet header For transport via the Ethemet connection, several diagnostic messages, including the respective packaging headers, are provided with a TCP header.
  • TCP header For transport via the Ethemet connection, several diagnostic messages, including the respective packaging headers, are provided with a TCP header.
  • the result is a data stream at the transport level ("Transport" layer), a special consideration of the preprocessing of the items to be sent Diagnostic data in the diagnostic tester only needs to be up to the transport level (and above).
  • the data processing in the lower communication levels (layers “Internet” and “Data Link” in Fig. 1) is handled by standard Ethernet components integrated into the diagnostic tester.
  • the data stream at the transport level is transmitted to the CCW 1 of the motor vehicle by means of the Ethemet connection.
  • FIG. 2 shows the essential processing steps of a vehicle-side vehicle access application.
  • the vehicle access application 200 is executed by the ZGW 1.
  • FIG. 2 shows, inter alia, the processing of the data stream arriving via the Ethemet connection, which arrives on a diagnostic port 100 of the vehicle access application 200.
  • Ethernet standard components are provided for diagnostic communication (arrow 3 in Fig. 3).
  • the Ethernet standard components are to be taken from the data stream created at diagnostic level 2 at the transport level.
  • the diagnostic messages that were previously present at the diagnostic tester are reconstructed.
  • the individual packets in each case a diagnosis message provided with a packaging header
  • a subsequent socket handler 102 also separates the individual diagnostic messages from the particular packet header.
  • the diagnostic messages are thus at the output of the vehicle access application 200 in the same form as if they had entered the vehicle in a conventional manner and can be further processed in a manner known in the art without the need for special hardware components.
  • the diagnostic messages are forwarded to a UGW 11, which essentially corresponds to a CFFS known from WO 2005/076103 A2. It can also be seen in FIG. 2 that the connection of the motor vehicle to the vehicle recognition service 4 already described in connection with FIG. 3 is also implemented in the vehicle access application 200 in the present case.
  • the vehicle access application 200 Upon receipt of an IP address or upon a separate request, the vehicle access application 200 sends the vehicle identifier 103 via the vehicle identification port 104.
  • control data stream can be transmitted data which are independent of the diagnostic data stream and which are not mapped by means of diagnostic communication.
  • An example of this is the query of terminal information, which is present as a CAN message 105 and is transmitted to the tester 2 via the control data stream from the motor vehicle.
  • the control port 106 is used.
  • the response to a request is assigned to the requesting tester by means of an allocation table 107.
  • the packet format in the control data stream is selected identical to the format of the diagnostic data stream, a multiplexer allows the addition of further control messages.

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)
  • Small-Scale Networks (AREA)

Abstract

Bei einem Verfahren zur Datenkommunikation zwischen einem ersten bei einem Kraftfahrzeug angeordneten Kommunikationsteilnehmer und einem zweiten außerhalb des Kraftfahrzeugs angeordneten Kommunikationsteilnehmer, bei welchem der erste Kommunikationsteilnehmer durch den zweiten Kommunikationsteilnehmer mittels einer Netzwerkadresse adressierbar ist, wird die Netzwerkadresse des ersten Kommunikationsteilnehmers durch eine außerhalb des Kraftfahrzeugs angeordnete Adressverwaltungseinheit festgelegt und an den ersten Kommunikationsteilnehmer übertragen.

Description

VERFAHREN ZUR DATENKOMMUNIKATION MIT EINEM BEI EINEM KRAFTFAHRZEUG ANGEORDNETEN KOMMUNIKATIONSTEILNEHMER MIT DYNAMISCHER ADRESSVERGABE
Die Erfindung betrifft ein Verfahren zur Datenkommunikation zwischen einem ersten bei einem Kraftfahrzeug angeordneten Kommunikationsteilnehmer und einem zweiten außerhalb des Kraftfahrzeugs angeordneten Kommunikationsteilnehmer, bei welchem der erste Kommunikationsteilnehmer durch den zweiten Kommunikationsteilnehmer mittels einer Netzwerkadresse adressierbar ist.
Aus dem Stand der Technik sind verschiedene Verfahren zur Datenkommunikation zwischen einem ersten bei einem Kraftfahrzeug angeordneten Kommunikationsteilnehmer und einem zweiten außerhalb des Kraftfahrzeugs angeordneten Kommunikationsteilnehmer bekannt. Zur Verbindung des Kraftfahrzeugs mit einem externen bzw. außerhalb des Kraftfahrzeugs angeordneten Kommunikationsteilnehmer wird üblicherweise ein Bus-System in Form eines so genannten OBD-Zugangs (OBD = On-Board-Diagnose) verwendet.
Ein solcher OBD-Zugang erlaubt eine Punkt-zu-Punkt-Verbindung zu einem außerhalb des Kraftfahrzeugs angeordneten Kommunikationsteilnehmer, die jedoch einige Nachteile mit sich bringt. Die Menge der übertragbaren Datenraten ist aufgrund des Bus-Systems begrenzt und verhältnismäßig niedrig. Für die Datenübertragung ist spezielle Hardware erforderlich, was zusätzliche Kosten mit sich bringt. Außerdem muss eine eigene Kommunikationsinfrastruktur aufgebaut werden. Ferner kann jeweils nur mit einem einzigen Kommunikationspartner gleichzeitig kommuniziert werden.
Aus dem Stand der Technik sind auch verschiedene Ansätze bekannt, Technologien, welche in anderen technischen Bereichen mittlerweile zum Standard geworden sind, für Verfahren der eingangs genannten Gattung zu nutzen. Beispielsweise ist es bekannt, bei dem Kraftfahrzeug eine Ethemet-Schnittstelle vorzusehen und unter Nutzung einer Ethernet-Verbindung Daten zwischen einem ersten bei einem Kraftfahrzeug angeordneten Kommunikationsteilnehmer und einem zweiten außerhalb des Kraftfahrzeugs angeordneten Kommunikationsteilnehmer auszutauschen. Eine spezielle Variante eines solchen Verfahrens beschreibt die WO 2005/076103 A2. Nachteilig bei allen bekannten Verfahren dieser Art ist jedoch, dass sie mit einem hohen technischen Aufwand einhergehen, da in der Regel entweder fahrzeugseitig parallel zur bisherigen OBD-Schnittstelle völlig eigenständige zusätzliche Kommunikationsmechanismen bereitgestellt werden müssen oder bestehende Kommunikationsstrukturen (z.B. CAN-Bus) durch entsprechende Vorrichtungen und Verfahren zur Schnittstellenanpassung erweitert werden müssen.
Zudem besteht bei den aus dem Stand der Technik bekannten Verfahren der eingangs genannten Gattung der Nachteil, dass keine eindeutige Adressierung einer großen Anzahl von Kraftfahrzeugen möglich ist, da die Anzahl der in einem Netzwerk bzw. Sub-Netzwerk zur Verfügung stehenden Adressen in der Regel begrenzt ist.
Aufgabe der Erfindung ist es, ein einfaches Verfahren zur Datenkommunikation zwischen einem ersten bei einem Kraftfahrzeug angeordneten Kommunikationsteilnehmer und einem zweiten außerhalb des Kraftfahrzeugs angeordneten Kommunikationsteilnehmer zu schaffen, welches die Adressierung einer großen Anzahl von Kraftfahrzeugen erlaubt.
Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren gemäß Patentanspruch 1. Bevorzugte Ausführungsformen und vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Patentansprüchen.
Erfindungsgemäß wird die Netzwerkadresse des ersten Kommunikationsteilnehmers durch eine außerhalb des Kraftfahrzeugs angeordnete Adressverwaltungseinheit festgelegt und von der Adressverwaltungseinheit an den ersten Kommunikationsteilnehmer übertragen. Auf diese Weise wird eine dynamische Adressvergabe ermöglicht. Der erste Kommunikationsteilnehmer ist mittels der ihm dynamisch zugeteilten Netzwerkadresse für andere Kommunikationsteilnehmer adressierbar.
Vorzugsweise wird die Netzwerkadresse einem zentralen Gateway (ZGW) des Kraftfahrzeugs zugewiesen, über welches die gesamte Datenkommunikation des Kraftfahrzeugs nach außen bzw. von außen abläuft. Da in der Regel nur ein einziges solches ZGW im Kraftfahrzeug vorhanden ist, bezieht sich die vergebene Netzwerkadresse dann gewissermaßen auf das Kraftfahrzeug als solches. Es ist also das Kraftfahrzeug selbst mittels der ihm dynamisch zugeteilten Netzwerkadresse für andere Kommunikationsteilnehmer, beispielsweise einen Diagnosetester, adressierbar. Das ZGW ist in einem solchen Fall der erste Kommunikationsteilnehmer im Sinne der Erfindung.
Grundsätzlich kann auch mehreren bei einem einzigen Kraftfahrzeug angeordneten Kommunikationsteilnehmern jeweils eine Netzwerkadresse zugeteilt werden. Dieser Fall wird hier jedoch ohne Beschränkung der Allgemeinheit nicht weiter betrachtet.
Bei einer dynamischen Adressvergabe, wie sie durch die Erfindung ermöglicht wird, wird einem in ein Netzwerk einzubindenden Kraftfahrzeug keine dauerhaft eigene eindeutige Netzwerkadresse zugewiesen. Vielmehr kann ein und dieselbe Netzwerkadresse zu unterschiedlichen Zeiten unterschiedlichen Kraftfahrzeugen zugewiesen werden. Die Adressvergabe ist dann vergleichbar mit derjenigen bei einem für andere technische Bereiche bereits aus dem Stand der Technik bekannten DHCP-Server (DHCP = Dynamic Host Configuration Protocol).
Eine an ein Kraftfahrzeug zugewiesene Netzwerkadresse muss nur innerhalb des jeweiligen Netzwerks eindeutig sein. Die Anzahl verfügbarer Netzwerkadressen eines Netzwerks, die in der Regel beschränkt ist, muss dann lediglich ausreichend groß bemessen sein, dass allen Kraftfahrzeugen, die gleichzeitig in das Netzwerk eingebunden werden sollen, unterschiedliche Netzwerkadressen zugeteilt werden können. Es müssen nicht eindeutige Netzwerkadressen verfügbar sein für sämtliche potenziell in das Netzwerk einbindbaren Kraftfahrzeuge.
Vorzugsweise ist die Adressverwaltungseinheit als DHCP-Server ausgebildet. Dies bietet den Vorteil, dass aus dem Stand der Technik bekannte und preisgünstig verfügbare Vorrichtungen und Verfahren zur Umsetzung der Erfindung Anwendung finden können.
Gemäß einer bevorzugten Ausführungsform der Erfindung wird zur Anforderung einer Netzwerkadresse eine Anforderungsnachricht, welche eine eindeutige Fahrzeugkennung des Kraftfahrzeugs enthält, von einem bei dem Kraftfahrzeug angeordneten Kommunikationsteilnehmer, beispielsweise dem ZGW, an die Adressverwaltungseinheit übertragen. Vorzugsweise besteht die Anforderungsnachricht im Wesentlichen in der eindeutigen Fahrzeugkennung selbst. Grundsätzlich kann die Anforderungsnachricht auch von einem bei dem Kraftfahrzeug angeordneten Kommunikationsteilnehmer versendet werden, der nicht identisch ist mit dem ersten Kommunikationsteilnehmer im Sinne der Erfindung. Vorzugsweise wird die Anforderungsnachricht jedoch durch das ZGW versendet.
Durch das Senden der Anforderungsnachricht kann sich ein Kraftfahrzeug gewissermaßen am Netzwerk anmelden, sobald es physikalisch mit diesem verbunden ist. Ihm wird dann eine Netzwerkadresse zugeteilt, über die es für andere Netzwerkteilnehmer adressierbar ist. Statt einer Anforderungsnachricht, die eine Fahrzeugkennung enthält oder im Wesentlichen in dieser Fahrzeugkennung besteht, kann zu diesem Zweck grundsätzlich auch eine beliebige andere Anforderungsnachricht gesendet werden. Jedoch bietet es Vorteile, wenn eine eindeutige Fahrzeugkennung bei der Adressverwaltungseinheit bekannt ist. Es wird somit nämlich eine Zuordnung zwischen der eindeutigen Fahrzeugkennung und der vergebenen Netzwerkadresse ermöglicht.
Vorzugsweise werden Zuordnungsdaten für die Zuordnung zwischen der zur Anforderung gesendeten eindeutigen Fahrzeugkennung und der daraufhin festgelegten Netzwerkadresse bei der Adressverwaltungseinheit abgelegt.
Dadurch wird es ermöglicht, auch bei dynamischer Adressvergabe eindeutig festzustellen, welches Kraftfahrzeug welcher Netzwerkadresse zugeordnet ist. Die Ablage kann beispielsweise in Listen- oder Tabellenform erfolgen. Vorzugsweise ist die Zuordnung auch im Nachhinein möglich, d.h. es kann festgestellt werden, welches Kraftfahrzeug welcher Netzwerkadresse zugeordnet war. Beispielsweise kann für jedes jemals bzw. in einem bestimmten Zeitraum in das Netzwerk eingebundene Kraftfahrzeug eine Netzwerkhistorie bei der Adressverwaltungseinheit abgelegt werden, welche dokumentiert, zu welcher Zeit dem Kraftfahrzeug bzw. seiner Fahrzeugkennung welche Netzwerkadresse zugeordnet war.
Die Adressverwaltungseinheit ist aufgrund der Tatsache, dass sie die Netzwerkadressen an in das Netzwerk eingebundene Kraftfahrzeuge vergibt, prädestiniert, solche Zuordnungsdaten für eine spätere Verwendung, etwa für die Möglichkeit der Abfrage durch einen Netzwerkteilnehmer, abzulegen. Die Adressverwaltungseinheit kann daher auch die Aufgabe einer Adressvermittlungseinheit erfüllen, bei welcher die zu einer Fahrzeugkennung gehörige Netzwerkadresse durch andere Kommunikationsteilnehmer abfragbar ist. Gemäß einer bevorzugten Ausführungsform der Erfindung wird die Funktionalität der Wiedergabe von Zuordnungsdaten auf Anfrage eines Netzwerkteilnehmers jedoch auf eine gesonderte, von der Adressverwaltungseinheit getrennt ausgeführte Adressvermittlungseinheit verlagert. Vorzugsweise werden Zuordnungsdaten für die Zuordnung zwischen der zur Anforderung gesendeten eindeutigen Fahrzeugkennung und der daraufhin festgelegten Netzwerkadresse bei einer Adressvermittlungseinheit abgelegt, bei welcher die zu einer Fahrzeugkennung gehörige Netzwerkadresse durch andere Kommunikationsteilnehmer abfragbar ist. Die Zuordnungsdaten können hierzu von der Adressverwaltungseinheit an die getrennt ausgeführte Adressvermittlungseinheit übertragen werden.
Die Wiedergabe von Zuordnungsdaten durch die Adressvermittlungseinheit ist dann vergleichbar mit der Funktionalität eines für andere technische Bereiche bereits aus dem Stand der Technik bekannten DNS-Servers (DNS = Domain Name Server). Vorzugsweise ist die Adressvermittlungseinheit als DNS-Server ausgebildet. Dies bietet den Vorteil, dass aus dem Stand der Technik bekannte und preisgünstig verfügbare Vorrichtungen und Verfahren zur Umsetzung der Erfindung Anwendung finden können.
Bei der eindeutigen Fahrzeugkennung handelt es sich vorzugsweise um die Fahrgestellnummer des Kraftfahrzeugs. Die Fahrgestellnummer ist eine weit verbreitete und bewährte Kennung zur Identifikation eines Kraftfahrzeugs. Aus dem Stand der Technik sind Verfahren und Vorrichtungen bekannt, die Fahrgestellnummer eines Kraftfahrzeugs in Datenform bei dem Kraftfahrzeug zu speichern und gegebenenfalls kommunikationstechnisch auszugeben.
Die Festlegung bzw. Vergabe der Netzwerkadresse durch die Adressverwaltungseinheit kann gemäß einer bevorzugten Ausführungsform der Erfindung auch abhängig von der Fahrzeugkennung vorgenommen werden. Die vergebene Netzwerkadresse kann beispielsweise in solcher Weise von der Fahrzeugkennung abhängen, dass einem bestimmten Fahrzeug bevorzugt eine bestimmte Netzwerkadresse zugeteilt wird, beispielsweise eine Netzwerkadresse, die demselben Fahrzeug bereits früher zugeteilt worden war.
Vorzugsweise erfolgt bei der Erfindung die Kommunikation zwischen dem ersten und dem zweiten Kommunikationsteilnehmer über eine Standard-Schnittstelle, insbesondere eine Ethernet-Schnittstelle. Die Kommunikation zwischen dem ersten und dem zweiten Kommunikationsteilnehmer erfolgt vorzugsweise über ein Standard-Protokoll, insbesondere TCP/IP. Die erfindungsgemäße Zuweisung einer Netzwerkadresse, beispielsweise einer IP- Adresse, erlaubt die Nutzung der meisten modernen Netzwerk-Technologien sowie der zugehörigen Vorrichtungen und Verfahren. Die Nutzungen von Standard-Vorrichtungen und - Verfahren bringt in der Regel insbesondere bei hohen Stückzahlen große Kostenvorteile und hohe Zuverlässigkeit mit sich. Zudem sind sehr hohe Datenraten übertragbar. Beispielsweise kann eine Datenübertragung via Ethernet mit bis zu zwanzigfacher Datenrate gegenüber OBD erfolgen.
Die Erfindung erlaubt unter Nutzung der jeweiligen Kommunikationstechnologie eine komfortable Adressierung aller Kommunikationsteilnehmer. Sofern die verwendete Kommunikationstechnologie dies vorsieht, ist auch die gleichzeitige Kommunikation eines Kommunikationsteilnehmers mit mehreren anderen Kommunikationsteilnehmern möglich. Somit wird durch die erfindungsgemäße Einbindung von Fahrzeugen in ein Netzwerk, insbesondere ein Ethernet-Netzwerk, ermöglicht, dass ein Diagnosetester gleichzeitig mit mehreren Fahrzeugen kommuniziert und/oder dass mehrere Diagnosetester gleichzeitig mit einem Fahrzeug kommunizieren.
Gemäß einer bevorzugten Ausführungsform der Erfindung wird fahrzeugseitig bei dem ersten Kommunikationsteilnehmer ein während der Datenkommunikation von dem zweiten Kommunikationsteilnehmer übertragener Eingangsdatenstrom mittels einer Fahrzeugzugangsapplikation in einen Diagnosedatenstrom im Datenformat einer herkömmlichen Diagnosekommunikation umgesetzt. Der Diagnosedatenstrom wird also fahrzeugseitig rekonstruiert.
Vorteilhaft ist es dabei, die heute meist bereits vorhandenen und oft auch gesetzlich vorgeschriebenen Strukturen eines herkömmlichen OBD-Zugangs sowohl fahrzeugseitig, als auch auf der Seite des zweiten Kommunikationsteilnehmers, beispielsweise eines Diagnosetesters, so wenig wie möglich zu verändern.
Die bei dem zweiten Kommunikationsteilnehmer, beispielsweise einem Diagnosetester, im Datenformat einer herkömmlichen Diagnosekommunikation, d.h. im herkömmlichen Diagnosenachrichten-Format, vorliegenden Diagnosenachrichten werden bei dem Diagnosetester daher vorzugsweise lediglich so vorverarbeitet, beispielsweise paketiert, dass sie mittels der gewählten Standard-Technologie, beispielsweise TCP/IP over Ethernet, zu dem ersten Kommunikationsteilnehmer übertragen werden können. Bei der Vorverarbeitung muss eine Betrachtung der Daten lediglich bis zur Transportebene (und darüber) erfolgen. Die Datenverarbeitung in den niedrigeren kommunikationstechnischen Ebenen wird von den Standardkomponenten der verwendeten Standard-Technologie erledigt. Der bei dem ersten Kommunikationsteilnehmer ankommende Datenstrom wird durch die entsprechenden zur Vorverarbeitung inversen Verarbeitungsschritte der Fahrzeugzugangsapplikation wieder ins Diagnosenachrichten-Format umgesetzt. Auch dabei kann die Betrachtung auf die Transportebene beschränkt bleiben. Als Ergebnis liegen bei dem ersten Kommunikationsteilnehmer dieselben Diagnosenachrichten vor, die zunächst auf der anderen Seite der Kommunikationsverbindung bei dem zweiten Kommunikationsteilnehmer vorgelegen hatten. Der somit rekonstruierte Diagnosedatenstrom kann dann in derselben Art und Weise fahrzeugseitig weiterverarbeitet werden, wie dies von der herkömmlichen Diagnosekommunikation bekannt ist. Es ist somit eine sehr einfache fahrzeugseitige Umsetzung des Verfahrens möglich, bei welcher kaum bzw. keine Fahrzeugkomponenten verändert werden müssen.
Da die bei dem zweiten Kommunikationsteilnehmer vorliegenden Diagnosenachrichten lediglich an die verwendete Übertragungstechnologie angepasst und am Ende der Übertragungsstrecke bei dem ersten Kommunikationsteilnehmer werden müssen, sieht das beschriebene Verfahren ein sehr schlankes Übertragungsprotokoll mit sehr geringem Overhead zur Übertragung von standardisierten Diagnosenachrichten vor. Somit lassen sich Standard-Diagnosenachrichten verzugslos, gesichert, ohne große Zwischenpuffer in das Fahrzeug und aus dem Fahrzeug heraus übertragen. Vorzugsweise erlaubt ein Multiplexer (Kontrollbytes) die Erweiterung auf andere Datenarten als Diagnosenachrichten.
Vorzugsweise ist der OBD-Zugang, insbesondere der OBD-Stecker, des Kraftfahrzeugs weiterhin in konventioneller Art und Weise verwendbar. Im einfachsten Fall wird für die weitere verwendete Kommunikationstechnologie, z.B. Ethernet, ein gesonderter Anschluss vorgesehen. Gemäß einer besonders bevorzugten Ausführungsform der Erfindung werden jedoch freie Kontakte des OBD-Steckers genutzt, auf weiche die Signale der weiteren verwendeten Kommunikationstechnologie, z.B. Ethernet, aufgelegt werden. Es muss dann keine zusätzliche Steckverbindung vorgesehen werden. Der herkömmliche OBD-Anschluss und die zusätzliche Kommunikationsverbindung, z.B. Ethernet, sind in einer Steckverbindung zusammengefasst. Es werden dadurch die Kosten für zusätzliche Steckverbindungen eingespart. Außerdem entfallen Zeit und Aufwand für das tatsächliche Aufstecken mehrerer Stecker.
Zur fahrzeuginternen Verteilung der Signale verschiedener Datenanschlüsse (z.B. herkömmlicher OBD-Anschluss und Ethernet) kann fahrzeugseitig eine Gatewayeinheit vergleichbar dem in der WO 2005/076103 A2 beschriebenen CFFS verwendet werden.
Gemäß einer Weiterbildung der Erfindung ist die eindeutige Fahrzeugkennung des Kraftfahrzeugs zudem durch einen außerhalb des Kraftfahrzeugs angeordneten Netzwerkteilnehmer abfragbar. Vorzugsweise wird hierzu von dem abfragenden Netzwerkteilnehmer eine Abfragenachricht an die dem Kraftfahrzeug zugewiesene Netzwerkadresse gesendet. Das Kraftfahrzeug antwortet auf diese Abfragenachricht mit einer Antwortnachricht, welche die eindeutige Fahrzeugkennung des Kraftfahrzeugs enthält. Es ist auch eine ungerichtete Abfrage aller Fahrzeuge in einem Netzwerk bzw. Netzwerksegment mittels Broadcast möglich (z.B. Anfrage auf der Broadcast-Adresse, alle Fahrzeuge in einem Subnet antworten).
Der abfragende Netzwerkteilnehmer kann dabei grundsätzlich ein beliebiger anderer Netzwerkteilnehmer sein, etwa ein anderes ins Netzwerk eingebundenes Kraftfahrzeug. Die Abfrage kann auch an die Bedingung einer Berechtigung geknüpft sein. Die Abfrage kann beispielsweise nur solchen Netzwerkteilnehmern gestattet werden, die eine gesonderte Berechtigung hierzu besitzen.
Der abfragende Netzwerkteilnehmer kann auch ein netzwerkseitiger Fahrzeugerkennungsdienst sein. Bei diesem kann anhand der empfangenen Fahrzeugkennungen verschiedener Fahrzeuge eine Liste mehrerer, vorzugsweise aller, aktuell bzw. jemals bzw. in einem bestimmten Zeitraum im Netzwerk angemeldeten Kraftfahrzeuge erstellt werden. Dies kann etwa zu Dokumentationszwecken bei der Fahrzeugfertigung oder im Fahrzeugservice vorteilhaft sein.
Zweck der Abfrage der Fahrzeugkennung durch den abfragenden Netzwerkteilnehmer kann es sein, eine Zuordnung zwischen Fahrzeugkennungen und Netzwerkadressen zu ermöglichen. Vorzugsweise erlaubt auch die Liste eines Fahrzeugerkennungsdiensts eine Zuordnung zwischen den Fahrzeugkennungen und jeweils einer bzw. mehreren zugeteilten Netzwerkadressen. Eine solche Zuordnung zwischen Netzwerkadresse und empfangener Fahrzeugkennung ist für den abfragenden Netzwerkteilnehmer in der Regel leicht möglich, wenn dieser das jeweilige Kraftfahrzeug zuvor gezielt über dessen Netzwerkadresse angesprochen hat und als unmittelbare Antwort daraufhin die Fahrzeugkennung erhalten hat. Dennoch kann es vorteilhaft sein, wenn zusammen mit der Fahrzeugkennung zusätzlich auch die Netzwerkadresse an den abfragenden Netzwerkteilnehmer übertragen wird. Die Zuordnung kann dadurch weiter vereinfacht werden. Außerdem kann dadurch der die Fahrzeugkennung empfangende Netzwerkteilnehmer, beispielsweise ein Fahrzeugerkennungsdienst, eine Zuordnung zwischen Netzwerkadresse und Fahrzeugkennung auch in Fällen vornehmen, in welchen die Fahrzeugkennung unaufgefordert oder auf Anforderung eines anderen Netzwerkteilnehmers an ihn gesendet worden ist. Beispielsweise kann es vorteilhaft sein, dass ein Kraftfahrzeug nach der Zuweisung einer Netzwerkadresse durch die Adressverwaltungs- einheit selbsttätig seine eindeutige Fahrzeugkennung zusammen mit der zugeteilten Netzwerkadresse an einen Fahrzeugerkennungsdienst sendet. Wenn dies für alle am Netzwerk angemeldeten Kraftfahrzeuge in solcher Art und Weise erfolgt, ist der Fahrzeugerkennungsdienst in vollem Umfang über die Zuordnung zwischen Netzwerkadressen und Fahrzeug- kennungen informiert. Als anderes Beispiel für den Fall, dass die Fahrzeugkennung unaufgefordert oder auf Anforderung eines anderen Netzwerkteilnehmers an einen Fahrzeugerkennungsdienst gesendet wird, ist es auch denkbar, dass eine Abfrage ohne eingehende Berücksichtigung der jeweiligen Netzwerkadresse an alle aktuell im Netzwerk angemeldeten Fahrzeuge gesendet wird.
Ein solcher Fahrzeugerkennungsdienst, wie oben beschrieben, wird vorzugsweise zusätzlich zu einer Adressverwaltungseinheit und ggf. einer Adressvermittlungseinheit vorgesehen. Er kann auch ganz oder teilweise die Aufgabe einer Adressvermittlungseinheit erfüllen, wenn die Zuordnungsliste des Fahrzeugerkennungsdiensts eine Zuordnung zwischen Fahrzeug- kennungen und Netzwerkadressen erlaubt, welche durch andere Kommunikationsteilnehmer abfragbar ist. Es kann auch eine Adressvermittlungseinheit für Abfragen der Art dienen, welche Netzwerkadresse welcher Fahrzeugkennung zugeordnet ist, während ein Fahrzeugerkennungsdienst für Abfragen der Art dient, welches Kraftfahrzeug aktuell in ein Netzwerk eingebunden ist. Durch die Möglichkeit der direkten Abfrage bzw. der durch ein anderes Ereignis gesteuerten Ausgabe der Fahrzeugkennung kann ein Zugriff auf eine Adressverwaltungseinheit bzw. eine Adressvermittlungseinheit vermieden werden, wenn eine solche Einheit überlastet, nicht erreichbar oder ausgefallen ist.
Es ist auch möglich, einen Diagnosetester direkt (ohne Netzwerk) am Kraftfahrzeug anzuschließen. Im Fall einer solchen direkten Verbindung von Kraftfahrzeug und Diagnosetester kann die direkte Abfrage der Fahrzeugkennung ebenfalls genutzt werden, um die Fahrzeugkennung durch den Diagnosetester zu ermitteln.
Es kann für einen Netzwerkteilnehmer im Einzelfall auch kommunikationstechnisch einfacher sein, eine direkte Abfrage der eindeutigen Fahrzeugkennung bei einem aktuellen oder potenziellen Kommunikationspartner vorzunehmen, als diese bei der Adressverwaltungseinheit bzw. der Adressvermittlungseinheit zu erfragen. Ferner kann Netzwerkteilnehmern, die nicht zur Abfrage der Zuordnungsdaten der Adressverwaltungseinheit bzw. der Adressvermittlungseinheit berechtigt sind, die Möglichkeit gegeben werden, im Einzelfall die eindeutige Fahrzeugkennung eines aktuellen oder potenziellen Kommunikationspartners abzufragen.
Es sei darauf hingewiesen, dass die Möglichkeit der direkten Abfrage der Fahrzeugkennung auch unabhängig von der Erfindung bei Verfahren der eingangs genannten Gattung vorteilhaft sein kann.
Der zweite Kommunikationsteilnehmer im Sinne der Erfindung ist gemäß einer bevorzugten Ausführungsform der Erfindung als Diagnosetester ausgebildet. Der Diagnosetester kann ein Kraftfahrzeug, mit welchem er, beispielsweise zu Diagnosezwecken verbunden werden soll, dann anhand dessen Netzwerkadresse adressieren. Wenn bei dem Diagnosetester lediglich die Fahrzeugkennung des Kraftfahrzeugs bekannt ist, kann die der Fahrzeugkennung aktuelle zugeordnete Netzwerkadresse gegebenenfalls bei einer Adressvermittlungseinheit abgefragt werden. Sofern ein Fahrzeugerkennungsdienst vorhanden ist, kann gegebenenfalls auch durch den Diagnosetester bei dem Fahrzeugerkennungsdienst angefragt werden, ob das betreffende Kraftfahrzeug derzeit ins Netzwerk eingebunden ist. Eine bevorzugte Ausführungsform der Erfindung wird im Folgenden anhand der Zeichnungen näher beschrieben. Dabei zeigen die Zeichnungen im Einzelnen jeweils schematisch
Fig. 1 die kommunikationstechnischen Schichten einer zu versendenden Diagnosenachricht,
Fig. 2 die wesentlichen Verarbeitungsschritte einer bevorzugten Ausführungsform einer Fahrzeugzugangsapplikation und
Fig. 3 die wesentlichen Signalflüsse bei einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens.
Fig. 3 zeigt die wesentlichen Signalflüsse bei einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens. Das zentrale Gateway (ZGW) 1 eines Kraftfahrzeugs kommuniziert zu Diagnosezwecken mit einem Diagnosetester 2. Die Diagnosekommunikation ist durch Pfeil 3 dargestellt. Die Diagnosekommunikation erfolgt über eine Ethemet-Verbindung.
Für die Kommunikation im Netzwerk wird dem Fahrzeug eine IP-Adresse zugewiesen.
Es soll eine Vielzahl von verschiedenen Fahrzeugen mit dem Diagnosetester 2 verbindbar sein. Aufgrund der großen Zahl an Fahrzeugen muss die Zuweisung der IP-Adresse dynamisch erfolgen. Im vorliegenden Fall wird dem Fahrzeug beim Anschluss des Fahrzeuges an das Netzwerk eine IP-Adresse durch den DHCP-Server 5 zugewiesen. Bei diesem Vorgang übermittelt das Fahrzeug seine Fahrgestellnummer, auch VIN (vehicle identification number) genannt (Pfeil 6), an den DHCP-Server 5. Der DHCP-Server teilt dem Fahrzeug bzw. dem ZGW 1 im Gegenzug eine IP-Adresse zu (Pfeil 7).
Zudem gibt der DHCP-Server 5 Zuordnungsdaten zur Zuordnung zwischen Fahrgestellnummer und zugeteilter IP-Adresse an einen nicht eigens grafisch dargestellten DNS-Server weiter. Der DNS-Server ist somit später in der Lage, die Netzwerkadresse zu einer bestimmten Fahrgestellnummer auszugeben. Für die Identifikation des Fahrzeuges im Netzwerk sind zwei voneinander unabhängige Mechanismen vorgesehen. Zum einen eine Identifikation über den DHCP-Server 5 und den oben genannten DNS-Server.
Zum anderen ist netzwerkseitig ein Fahrzeugerkennungsdienst 4 vorgesehen. Nach erfolgter IP-Adressvergabe sendet das ZGVV 1 des Fahrzeugs per Broadcast (Pfeil 8) die Fahrgestellnummer des Fahrzeugs an den netzwerkseitigen Fahrzeugerkennungsdienst 4. Dieser Broadcast 8 wird vom netzwerkseitigen Fahrzeugerkennungsdienst 4 empfangen und ausgewertet. Der netzwerkseitige Fahrzeugerkennungsdienst 4 erstellt anhand der empfangenen Fahrgestellnummern eine Liste aller aktuell ins Netzwerk eingebundenen Fahrzeuge mit Fahrgestellnummer und IP-Adresse.
Das ZGW 1 des Fahrzeug liefert zudem auf gesonderte externe Abfrage (Pfeil 9) die Fahrgestellnummer des Fahrzeuges an den netzwerkseitigen Fahrzeugerkennungsdienst 4.
Die Funktion der ebenfalls in Fig. 3 dargestellten und mit dem ZGW 1 verbundenen Komponente VCM 10 (Vehicle Configuration Management) ist im Wesentlichen aus dem Stand der Technik bekannt. Die Funktion VCM 10 liefert im vorliegenden Beispiel die Fahrgestellnummer. Die ebenfalls in Fig. 3 dargestellte und mit dem ZGW 1 verbundene Komponente UGW 11 entspricht im Wesentlichen einem aus der WO 2005/076103 A2 bekannten CFFS. Anders als in Fig. 3 abgebildet können die Funktionen VCM 10 und UGW 11 ebenfalls durch das ZGW 1 ausgeführt werden.
Fig. 1 und Fig. 2 sind Details der Diagnosekommunikation 3 zwischen dem ZGW 1 und dem Diagnosetester 2 zu entnehmen.
Fig. 1 zeigt die kommunikationstechnischen Schichten einer zu versendenden Diagnosenachricht. Die Diagnosenachricht liegt zunächst als solche (Schicht „Applikation") bei dem Diagnosetester vor. Zur Paketierung wird jede Diagnosenachricht mit einem Header (Paketierungsheader, Schicht „Paketrierung") versehen. Zum Transport über die Ethemet- Verbindung werden mehrere Diagnosenachrichten inklusive der jeweiligen Paketierungsheader mit einem TCP-Header versehen. Das Ergebnis ist ein Datenstrom auf Transportebene (Schicht „Transport"). Eine besondere Betrachtung der Vorverarbeitung der zu versendenden Diagnosedaten bei dem Diagnosetester muss lediglich bis zur Transportebene (und darüber) erfolgen. Die Datenverarbeitung in den niedrigeren kommunikationstechnischen Ebenen (Schichten „Internet" und „Data Link" in Fig. 1) wird von Ethernet-Standardkomponenten, die in den Diagnosetester integriert sind, erledigt.
Der Datenstrom auf Transportebene wird mittels der Ethemetverbindung zum ZGW 1 des Kraftfahrzeugs übertragen.
Fig. 2 zeigt die wesentlichen Verarbeitungsschritte einer kraftfahrzeugseitigen Fahrzeugzugangsapplikation. Die Fahrzeugzugangsapplikation 200 wird durch das ZGW 1 ausgeführt. Aus Fig. 2 ersichtlich ist unter anderem die Verarbeitung des über die Ethemet- Verbindung ankommenden Datenstroms, der auf einem Diagnoseport 100 der Fahrzeugzugangsapplikation 200 ankommt.
Auch bei dem Fahrzeug, insbesondere bei dem ZGW 1 , sind zur Diagnosekommunikation (Pfeil 3 in Fig. 3) Ethernet-Standardkomponenten vorgesehen. Den Ethernet- Standardkomponenten ist der zuvor bei dem Diagnosetester 2 erstellte Datenstrom auf Transportebene zu entnehmen.
Aus dem auf dem Diagnoseport 100 der Fahrzeugzugangsapplikation 200 ankommenden Datenstrom werden die Diagnosenachrichten rekonstruiert, die zuvor bei dem Diagnosetester vorgelegen waren. Dazu werden zunächst in einem De-/Wrapper 101 die Einzelpakete (jeweils eine mit einem Paketierungsheader versehene Diagnosenachricht) extrahiert. Ein nachfolgender Socket-Handler 102 trennt zudem die einzelnen Diagnosenachrichten von dem jeweiligen Paketierungsheader. Die Diagnosenachrichten liegen somit am Ausgang der Fahrzeugzugangsapplikation 200 in derselben Form vor, als ob sie in herkömmlicher Art und Weise ins Fahrzeug gelangt wären und können in aus dem Stand der Technik bekannter Weise weiter verarbeitet werden, ohne dass besondere Hardware-Komponenten erforderlich wären.
Im dem in Fig. 2 abgebildeten Fall werden die Diagnosenachrichten an ein UGW 11 weitergegeben, welches im Wesentlichen einem aus der WO 2005/076103 A2 bekannten CFFS entspricht. In Fig. 2 erkennbar ist auch, dass die bereits im Zusammenhang mit Fig. 3 beschriebene Anbindung des Kraftfahrzeugs an den Fahrzeugerkennungsdienst 4 im vorliegenden Fall ebenfalls in der Fahrzeugzugangsapplikation 200 umgesetzt ist. Auf den Erhalt einer IP- Adresse hin bzw. auf gesonderte Anforderung hin versendet die Fahrzeugzugangsapplikation 200 die Fahrzeugkennung 103 über den Fahrzeugerkennungsport 104.
Über den in Fig. 2 ebenfalls erkennbaren Kontroll-Datenstrom lassen sich Daten übermitteln, die unabhängig vom Diagnosedatenstrom sind und die nicht mittels Diagnosekommunikation abgebildet werden. Beispiel hierfür ist die Abfrage von Klemmeninformation, welche als CAN- Botschaft 105 vorliegt und über den Kontroll-Datenstrom vom Kraftfahrzeug an den Tester 2 übermittelt wird. Genutzt wird dabei der Kontrollport 106. Im Falle mehrerer Tester wird die Antwort auf eine Anfrage mittels einer Zuordnungstabelle 107 dem jeweils anfragenden Tester zugeordnet. Das Paketierungsformat bei dem Kontroll-Datenstrom ist identisch zum Format des Diagnosedatenstroms gewählt, ein Multiplexer erlaubt das Hinzufügen von weiteren Kontrollnachrichten.

Claims

Patentansprüche
1. Verfahren zur Datenkommunikation zwischen einem ersten bei einem Kraftfahrzeug angeordneten Kommunikationsteilnehmer und einem zweiten außerhalb des Kraftfahrzeugs angeordneten Kommunikationsteilnehmer, bei welchem der erste Kommunikationsteilnehmer durch den zweiten Kommunikationsteilnehmer mittels einer Netzwerkadresse adressierbar ist, dadurch gekennzeichnet, dass die Netzwerkadresse des ersten Kommunikationsteilnehmers durch eine außerhalb des Kraftfahrzeugs angeordnete Adressverwaltungseinheit festgelegt wird und an den ersten Kommunikationsteilnehmer übertragen wird.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass zur Anforderung einer Netzwerkadresse eine Anforderungsnachricht, insbesondere enthaltend eine eindeutige Fahrzeugkennung des Kraftfahrzeugs, von einem bei dem Kraftfahrzeug angeordneten Kommunikationsteilnehmer an die Adressverwaltungseinheit übertragen wird.
3. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass Zuόrdnungsdaten für die Zuordnung zwischen der zur Anforderung gesendeten eindeutigen Fahrzeugkennung und der daraufhin festgelegten Netzwerkadresse bei der Adressverwaltungseinheit abgelegt werden.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass Zuordnungsdaten für die Zuordnung zwischen der zur Anforderung gesendeten eindeutigen Fahrzeugkennung und der daraufhin festgelegten Netzwerkadresse bei einer Adressvermittlungseinheit abgelegt werden, bei welcher die zu einer Fahrzeugkennung gehörige Netzwerkadresse durch andere Kommunikationsteilnehmer abfragbar ist.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der zweite Kommunikationsteilnehmer als Diagnosetester ausgebildet ist.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Kommunikation zwischen dem ersten und dem zweiten Kommunikationsteilnehmer über eine Standard-Schnittstelle, insbesondere eine Ethemet-Schnittstelle, erfolgt.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Kommunikation zwischen dem ersten und dem zweiten Kommunikationsteilnehmer über ein Standard-Protokoll, insbesondere TCP/IP, erfolgt.
8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass fahrzeugseitig bei dem ersten Kommunikationsteilnehmer ein während der Datenkommunikation von dem zweiten Kommunikationsteilnehmer übertragener Eingangsdatenstrom mittels einer Fahrzeugzugangsapplikation in einen Diagnosedatenstrom im Datenformat einer herkömmlichen Diagnosekommunikation umgesetzt wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Adressverwaltungseinheit als DHCP-Server ausgebildet ist und/oder dass die Adressvermittlungseinheit als DNS-Server ausgebildet ist.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die eindeutige Fahrzeugkennung eine Fahrgestellnummer ist.
EP07711819A 2006-03-13 2007-03-07 Verfahren zur datenkommunikation mit einem bei einem kraftfahrzeug angeordneten kommunikationsteilnehmer mit dynamischer adressvergabe Withdrawn EP1994723A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006011829.4A DE102006011829B4 (de) 2006-03-13 2006-03-13 Verfahren zur Datenkommunikation
PCT/EP2007/001948 WO2007104453A1 (de) 2006-03-13 2007-03-07 Verfahren zur datenkommunikation mit einem bei einem kraftfahrzeug angeordneten kommunikationsteilnehmer mit dynamischer adressvergabe

Publications (1)

Publication Number Publication Date
EP1994723A1 true EP1994723A1 (de) 2008-11-26

Family

ID=38055503

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07711819A Withdrawn EP1994723A1 (de) 2006-03-13 2007-03-07 Verfahren zur datenkommunikation mit einem bei einem kraftfahrzeug angeordneten kommunikationsteilnehmer mit dynamischer adressvergabe

Country Status (4)

Country Link
US (1) US8677019B2 (de)
EP (1) EP1994723A1 (de)
DE (1) DE102006011829B4 (de)
WO (1) WO2007104453A1 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9117319B2 (en) * 2005-06-30 2015-08-25 Innova Electronics, Inc. Handheld automotive diagnostic tool with VIN decoder and communication system
DE102011089397B4 (de) * 2011-12-21 2020-12-17 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Überwachen eines adaptiven Netzwerks
US20130339546A1 (en) * 2012-06-13 2013-12-19 Cellco Partnership D/B/A Verizon Wireless Device identification
FR2993425B1 (fr) * 2012-07-13 2014-07-18 Commissariat Energie Atomique Dispositif et procede pour generer une adresse internet protocol (ip) a partir d'un numero d'identification de vehicule (vin)
US10656280B2 (en) 2014-05-13 2020-05-19 Key Control Holding, Inc. Vehicle monitoring systems and methods
US9912634B2 (en) * 2015-03-12 2018-03-06 General Motors Llc Enhancing DNS availability
DE102015211146A1 (de) * 2015-06-17 2016-12-22 Bayerische Motoren Werke Aktiengesellschaft Verfahren, Haupteinheit, und Fahrzeug zum Einbringen von Anwendungen in die Haupteinheit des Fahrzeugs
JP7094670B2 (ja) * 2017-07-03 2022-07-04 矢崎総業株式会社 設定装置及びコンピュータ
KR102626252B1 (ko) * 2018-09-10 2024-01-17 현대자동차주식회사 충전기를 활용한 차량 상태 모니터링 및 진단 방법 및 시스템
US11574510B2 (en) 2020-03-30 2023-02-07 Innova Electronics Corporation Multi-functional automotive diagnostic tablet with interchangeable function-specific cartridges
US11967189B2 (en) 2020-04-20 2024-04-23 Innova Electronics Corporation Router for communicating vehicle data to a vehicle resource
US11651628B2 (en) 2020-04-20 2023-05-16 Innova Electronics Corporation Router for vehicle diagnostic system
US11777835B1 (en) * 2020-07-20 2023-10-03 Ethernovia Inc. Functional safety in a vehicle networking system

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5159592A (en) * 1990-10-29 1992-10-27 International Business Machines Corporation Network address management for a wired network supporting wireless communication to a plurality of mobile users
US5812819A (en) * 1995-06-05 1998-09-22 Shiva Corporation Remote access apparatus and method which allow dynamic internet protocol (IP) address management
US6219697B1 (en) * 1997-05-02 2001-04-17 3Com Corporation Method and apparatus for operating the internet protocol over a high-speed serial bus
US6263268B1 (en) * 1997-08-26 2001-07-17 Transcontech Corporation System and method for providing mobile automotive telemetry
US6968394B1 (en) * 1997-09-22 2005-11-22 Zaksat General Trading Co., Wll Asymmetric satellite-based internet service
US7136645B2 (en) * 1998-10-09 2006-11-14 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
DE19921845A1 (de) * 1999-05-11 2000-11-23 Bosch Gmbh Robert Diagnosetestvorrichtung für Kraftfahrzeuge mit programmierbaren Steuergeräten
US6362730B2 (en) * 1999-06-14 2002-03-26 Sun Microsystems, Inc. System and method for collecting vehicle information
US7734287B2 (en) * 2000-04-10 2010-06-08 I/O Controls Corporation System for providing remote access to diagnostic information over a wide area network
DE10019728A1 (de) * 2000-04-20 2001-10-25 Alcatel Sa Verfahren zum Aufbau einer Kommunikationsverbindung
JP3428567B2 (ja) * 2000-06-07 2003-07-22 東日本電信電話株式会社 移動体管理システム、移動体管理制御装置、移動通信装置及びコンピュータ読み取り可能な記憶媒体
US7260638B2 (en) * 2000-07-24 2007-08-21 Bluesocket, Inc. Method and system for enabling seamless roaming in a wireless network
US6751475B1 (en) * 2000-10-19 2004-06-15 At&T Wireless Services, Inc. Shared-revenue billing system for transmission of wireless data from a vehicle
US20020165952A1 (en) * 2000-10-20 2002-11-07 Sewell James M. Systems and methods for remote management of diagnostic devices and data associated therewith
DE10057638C2 (de) * 2000-11-21 2002-11-28 Daimler Chrysler Ag Verfahren zur Dokumentation von Daten eines Verkehrsmittels
US6728603B2 (en) * 2001-02-08 2004-04-27 Electronic Data Systems Corporation System and method for managing wireless vehicular communications
US20030034882A1 (en) * 2001-08-02 2003-02-20 International Business Machines Corporation Real time vehicle alert system
US6865460B2 (en) * 2001-10-29 2005-03-08 Visteon Global Technologies, Inc. Communication network for an automobile
US20030103482A1 (en) * 2001-12-04 2003-06-05 Van Bosch James A. Method of enabling communication with a wireless communication device
US7010762B2 (en) * 2002-02-27 2006-03-07 At&T Corp. Pre-loading content to caches for information appliances
US20030220994A1 (en) * 2002-02-28 2003-11-27 Chunrong Zhu Wireless network access system and method
US8327446B2 (en) * 2002-05-06 2012-12-04 Trend Micro Inc. Antivirus stand-alone network or internet appliance and methods therefor
DE10234850A1 (de) * 2002-07-31 2004-02-12 Robert Bosch Gmbh KFZ-Gateway-Aktivierung mit GPRS/UMTS-Anbindung
JP4168866B2 (ja) * 2003-07-25 2008-10-22 トヨタ自動車株式会社 車両情報通信方法、車両情報通信システムおよびセンター
US20050131595A1 (en) * 2003-12-12 2005-06-16 Eugene Luskin Enhanced vehicle event information
DE102004005680A1 (de) 2004-02-05 2005-08-25 Bayerische Motoren Werke Ag Vorrichtung und Verfahren zur Ansteuerung von Steuergeräten in einem Bordnetz eines Kraftfahrzeuges
US7630308B1 (en) * 2004-05-03 2009-12-08 Level 3 Communications, Llc Systems and methods for applying a variable encoding/decoding scheme in a communication network
JP3875697B2 (ja) * 2004-05-06 2007-01-31 松下電器産業株式会社 車載情報処理装置
KR100663412B1 (ko) * 2004-06-07 2007-01-02 삼성전자주식회사 차대번호를 이용하여 인터넷 프로토콜 주소를 설정하는 방법
US7123164B2 (en) * 2004-08-02 2006-10-17 Netistix Technologies Corporation Vehicle telemetric system
DE602005001841T2 (de) * 2005-01-14 2008-04-17 Alcatel Lucent Navigationsdienst
CN1848873B (zh) * 2005-04-15 2010-05-26 鸿富锦精密工业（深圳）有限公司 调制解调器测试系统及方法
US7469172B2 (en) * 2005-08-05 2008-12-23 Spx Corporation Wiring diagram with wire colors
US20080137590A1 (en) * 2006-12-06 2008-06-12 Idsc Holdings Llc Detachable wireless adapter for vehicle communication modules
US8280581B2 (en) * 2008-05-07 2012-10-02 Spx Corporation Dynamic discovery of vehicle communication interface device and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007104453A1 *

Also Published As

Publication number Publication date
US20090070488A1 (en) 2009-03-12
DE102006011829A1 (de) 2007-09-20
DE102006011829B4 (de) 2015-10-22
WO2007104453A1 (de) 2007-09-20
US8677019B2 (en) 2014-03-18

Similar Documents

Publication Publication Date Title
DE102006011829B4 (de) Verfahren zur Datenkommunikation
EP2622826B1 (de) Verfahren zur automatischen adressvergabe an gleichartige busteilnehmer
DE69829346T2 (de) Ein-/Ausgabevorrichtung für ein Peripheriegerät
EP1100230B1 (de) Datenübertragungssystem für Luftfahrzeuge
WO2003067853A2 (de) System und verfahren zur analyse eines netzwerks und/oder generierung der topologie eines netzwerks
EP2733910B1 (de) BUS-System, Verfahren zum Betrieb eines BUS-Systems und fluidisches System mit einem BUS-System
EP1155549B1 (de) Verfahren zum übertragen von ethernet-frames
DE102018129813A1 (de) Datenübertragungsverfahren und Automatisierungskommunikationsnetzwerk
WO2006128787A1 (de) Verfahren zum betreiben eines bussystems, bussystem und busteilnehmer
DE102006004191B4 (de) Deterministisches Kommunikations-System
DE102013227059A1 (de) Verfahren zur deterministischen datenübertragung in einem bussystem und bussystem
DE102019213322A1 (de) Ethernet Physical Layer Transceiver für Zweidraht-Bustopologie
EP2564576B1 (de) Verfahren zur bereitstellung einer kommunikation für mindestens ein gerät
EP1081921B1 (de) Verfahren zur Vergabe von IP-Adressen in Kommunikationsnetzen
EP3607437B1 (de) Verfahren zum konfigurieren zumindest eines geräts eines schienenfahrzeugs in einem netzwerk, computerprogramm und computerlesbares speichermedium
EP3669501B1 (de) Verfahren zum bereitstellen von datenpaketen aus einem can-bus; steuergerät sowie system mit einem can-bus
DE102015209361A1 (de) Paketbasiertes Kommunikationsnetz mit Autokonfigurierung lokaler Netzwerk-Adressen
EP3560153B1 (de) Verfahren zum betreiben einer datenverarbeitungsanlage, datenverarbeitungsanlage
EP1334589B1 (de) Datenübertragung
DE102017209428A1 (de) Verfahren und Vorrichtung zur Identifikation in einem Rechnernetzwerk
EP2933985A1 (de) Verwendung von Multicast DNS
EP3539308A1 (de) Verfahren zur datenübertragung in einem fahrzeug-kommunikationsnetzwerk, fahrzeug-kommunikationsnetzwerk, teilnehmer und fahrzeug
DE10343796B4 (de) Verfahren zur Verwaltung einer Gruppe von Netzzugangsservern
EP1430647B1 (de) Verfahren zum Betrieb eines Koppelknotens in einem Datennetz
DE102014014839A1 (de) Verfahren zur dynamischen Ermittlung von Kommunikationsbeziehungen von Datenpaketen in einem Fahrzeug-Bordnetz eines Kraftfahrzeugs

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080628

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB IT

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BAYERISCHE MOTOREN WERKE AKTIENGESELLSCHAFT

17Q First examination report despatched

Effective date: 20160129

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160609