WO2003105434A1 - Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug - Google Patents

Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug Download PDF

Info

Publication number
WO2003105434A1
WO2003105434A1 PCT/DE2003/001625 DE0301625W WO03105434A1 WO 2003105434 A1 WO2003105434 A1 WO 2003105434A1 DE 0301625 W DE0301625 W DE 0301625W WO 03105434 A1 WO03105434 A1 WO 03105434A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
server
information
client
data
Prior art date
Application number
PCT/DE2003/001625
Other languages
English (en)
French (fr)
Inventor
Thomas Sonnenrein
Norbert Bauer
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to EP03756942A priority Critical patent/EP1518383B1/de
Priority to US10/514,023 priority patent/US20050154500A1/en
Priority to JP2004512373A priority patent/JP2005529424A/ja
Publication of WO2003105434A1 publication Critical patent/WO2003105434A1/de

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications

Definitions

  • the invention relates to a method and device for transmitting, transmitting and / or receiving information in connection with a vehicle, in particular for remote diagnosis, remote control and / or remote control of a component / function of the vehicle.
  • DE 100 26 754 AI describes a method and a device for transmitting, transmitting and / or receiving information in connection with a vehicle.
  • a mobile radio network according to the GSM standard or according to the UMTS standard is proposed as an example of the telecommunications network, while the Internet is mentioned as an example of the data network.
  • the specific configuration in particular with regard to flexibility and / or reliability and / or security of the information exchange and / or with regard to the reduction in effort, particularly in the case of the end devices in the vehicle.
  • the communication of mobile devices with stationary computers on the Internet via standardized communication channels, for example using the WAP protocol, can already Existing telematics terminals in the vehicle that have appropriate access can be used to carry out vehicle-related telematics applications such as remote polling and / or remote control of vehicle components and / or to carry out remote diagnosis without the need to completely redesign this terminal with the corresponding effort.
  • vehicle-related telematics applications such as remote polling and / or remote control of vehicle components and / or to carry out remote diagnosis without the need to completely redesign this terminal with the corresponding effort.
  • the use of the WAP protocol is particularly advantageous since its powerful transmission and / or security mechanisms can be used for the specific application in the mobile area, in particular for the vehicle-related telematics applications mentioned, such as the remote diagnosis of motor vehicle control units.
  • Another positive effect of using this protocol is that resources such as memory and computing power are saved for the end devices, since this protocol is specially designed for end devices with few resources.
  • the transmitted WAP content in the form of WML pages, statically and dynamically generated content, e.g. to interact with the user, the
  • WAP browsers are provided by the server in the end device.
  • the WML pages can also contain so-called WML scripts, which enable the description of more complex processes in the end device. Parts of the end device applications such.
  • B. Remote diagnosis does not have to be explicitly implemented there, but is already implemented in the WAP stack and can be used universally.
  • the WAP standard provides an interface (EFI interface) with the aid of which the WAP browser (and thus indirectly the server) can communicate with independent external applications on the mobile terminal via a standardized function interface.
  • EFI interface an interface
  • Mechanisms are offered that allow communication with software components that are not in the browser are included, such as the diagnostic interface to the control devices to be diagnosed, facilitate.
  • the communication between the terminal and the server is predefined within the framework
  • the existing security mechanisms can be used after the telematics service has been activated
  • Figure 1 shows an overview of a system for a vehicle-related telematics service, while on the basis of Figure 2
  • FIG. 3 shows a suitable exemplary embodiment of transmission steps via the interface between the telematics terminal and the server.
  • FIGS. 4 and 5 show flow diagrams which outline the program sequences in the telematics terminal or in the server using the example of the communication shown in FIG. 3. Description of exemplary embodiments
  • Figure 1 shows an overview of a system for a vehicle-related telematics service, wherein information between a vehicle (there terminal) and a server via a mobile network or via a data network, such as that
  • Such a configuration is used in connection with functions for remote operation, remote diagnosis, remote maintenance, software download, etc.
  • the remote control of vehicle functions, in particular comfort functions such as switching on the auxiliary heating, etc., as well as the interrogation of vehicle statuses and / or are essentially carried out under remote control or remote interrogation
  • Remote diagnosis includes the remote reading of diagnostic data from the vehicle, its analysis and, if necessary, the generation of a recommendation for further action.
  • the data is analyzed and the recommendation generated by a central one
  • Server that is connected to the vehicle via a mobile radio network, via a wired network and / or via a data network such as the Internet with the motor vehicle.
  • a mobile radio network via a wired network and / or via a data network such as the Internet with the motor vehicle.
  • the so-called software download or remote flashing is also to be mentioned as a function, with the aid of which a new program code or parameters are applied to software-configurable systems in the vehicle, for example control units, in order to increase the functionality or performance increase.
  • communication takes place via a mobile radio network, a wired network and / or, for example, the Internet, starting from a central computer (server) or service center.
  • Remote maintenance is essentially the monitoring of the vehicle condition and
  • FIG. 1 shows an overview of a remote diagnostic system.
  • the vehicle electronics 1 On the vehicle side, the vehicle electronics 1 is shown, for example, a control unit network which is connected via a predetermined interface 2 to the vehicle-side part 3 of the remote diagnosis system, in particular to a telematics terminal.
  • This vehicle-side application uses the integrated in the vehicle electronics
  • Diagnostic mechanisms for example, for recording fault memory contents.
  • the vehicle-side part of the remote diagnosis system 3 accesses the vehicle network and thus the vehicle electronics 1 and / or the control devices to be diagnosed via the interface 2, for example via a CAN bus or a K line, within the framework of a predetermined communication protocol.
  • the vehicle-side part described is connected to the central part 5 of the remote diagnosis system via a further interface 4.
  • This central part preferably represents the server or the computer system of a service center. In the preferred exemplary embodiment, this server works as many as possible at the
  • Remote diagnostics so that as few resources as possible have to be kept in the vehicle terminal. For example, it essentially takes over the configuration of the diagnostic unit in the vehicle at the start of the diagnosis, the control of this unit during the process and the evaluation of the determined data. For this purpose, he particularly uses vehicle-specific data and commands that are stored in the data memory 6.
  • the server is an Internet server.
  • the transmission path 4 between server and client is in the preferred embodiment because of the properties with regard to coverage,
  • the protocol used in connection with the remote diagnosis for information exchange is a standardized protocol which is adapted to the special requirements of a mobile radio network.
  • the wireless application protocol (WAP) has proven to be suitable.
  • the WAP is a standardized worldwide
  • Each WAP-capable device has a special WAP browser for interpreting and visualizing the standardized transmission content.
  • the transferred content is realized in the form of WML pages. These pages can also contain so-called WML scripts, which enable the description of more complex processes in the end device.
  • WML scripts which enable the description of more complex processes in the end device.
  • EFI interface standardized function interface
  • the security mechanisms of the protocol are used in the specific application for the remote diagnosis of motor vehicles or automotive components. This means that no additional functional units in the terminal are required to ensure the security of the data transfer and / or to provide access rights.
  • FIG. 2 shows a diagram which represents a realization of a remote diagnosis system with WAP communication.
  • the vehicle-side part 10 (terminal) essentially consists of a module 10a, which comprises the functionalities of the diagnostic application, a module 10c, the WAP browser and one
  • Communication module lOd which sends information to the mobile network and receives it from there.
  • the module 10a is connected to other control units and / or components of the vehicle via a bus system 12 (diagnostic bus), for example a CAJM bus. Information, data and / or commands are exchanged via these interfaces.
  • the module 10a is linked to the web browser 10c via a further interface 10b (EFI interface).
  • the communication module 10d sends or receives via a transmitter or receiver 14, e.g. a mobile radio device, data to or via the air interface 16.
  • an operating system for organizing the processes and in the module 10c the so-called WAP stack is provided, which contains the functionalities for implementing the WAP protocol.
  • the vehicle-side part of the system is integrated in a telematics terminal.
  • This also contains the described GSM module for mobile communications and the WAP stack for Internet functionality.
  • the connection to the diagnostic bus, usually via CAN, is also available.
  • WAP Mobile radio standards such as GPRS or UMTS are well suited, as they have a fast connection, short delay times and a high data transmission rate at low cost.
  • the communication between the vehicle terminal and the central computer unit takes place via a mobile radio network 16.
  • the central processing unit 18 in particular a web server, receives data from the vehicle-side part of the system from a transceiver 20 of the mobile radio interface directly or via a gateway computer or sends data on this. If a gateway computer is used on the network side, this forms the WAP gateway (the WAP stack is implemented here).
  • the dialing of the mobile device 14 into the Internet usually takes place in such a gateway.
  • the gateway computer also includes the communication interface to the mobile network and the interface to the web server. On the one hand, the WAP gateway has the task of implementing a protocol from
  • WAP on the Internet format HTTP and vice versa, on the other hand to compress and precompile the WML pages and scripts received from the requested web server before sending them back to the mobile subscriber.
  • the server 18 itself takes over this gateway function (module 18a, mobile radio network interface module 18b), while in another embodiment a gateway computer connected to the server via an Internet connection takes over the tasks described.
  • the web server 18 for example of a service center, has the task of the diagnostic server.
  • the software (module 18c) implemented in the web server 18 answers the
  • the responses are dynamically generated with the aid of predefined, server-side scripts (programs) and a database 22, which contains all the necessary data for identifying, configuring and executing the diagnostic application in the vehicle for the corresponding inquirer.
  • Tasks of the web server are, on the one hand, general web server tasks, such as processing inquiries, distribution of pages or files to the correct recipient, communication management, etc., and also the higher-level process control of the diagnosis and configuration of the diagnosis application in the client via dynamically generated WML pages and scripts, the storage and administration of the data necessary for vehicle diagnosis in a database, the administration of the database itself, the Evaluation of the user data coming from the vehicle, the provision or the dynamic generation of the surface for the remote diagnosis application in the vehicle.
  • the determination of the useful data error memory
  • diagnosis itself is carried out in accordance with known diagnostic methods which are implemented in the vehicle.
  • WML pages and WML scripts for controlling the diagnostic processes are transferred from the server to the terminal device and processed by it.
  • the remote diagnosis communication is activated by the service center.
  • the initiation takes place via the
  • Such a process is specified / standardized in the WAP standard as a so-called push.
  • the remote diagnostic unit in the vehicle contains mechanisms and functions for the independent execution of the diagnostic processes.
  • Control unit error memories for data acquisition are read out by remote-controlled functions in the telematics terminal.
  • This contains functional units such as the transport protocol layer for CAN bus data, the protocol layer necessary for the logical diagnosis process and a corresponding sequence control. It is also provided that the necessary data for the corresponding protocol layers and for the sequence control at the beginning of the diagnostic process is downloaded from the diagnostic server and with the aid of
  • Protocol macros and communication parameters to configure the layers This has the consequence that in addition to the actual control commands for remote control of the remote diagnostic functions, parameters and diagnostic macros may also have to be transmitted.
  • the data required for parameterization is also permanently stored in the telematics terminal, which makes it unnecessary to transfer it from the server to the client.
  • the unit in the vehicle does not carry out the diagnostic process independently, but only passes the data coming from the server to the control device to be diagnosed. Diagnostic protocol functionalities in the vehicle are thereby greatly reduced and reduced to a minimum. They remain almost completely in the server. In this case, the individual diagnostic commands are transmitted transparently via the air interface. Only a few simply structured messages are generated in the vehicle. For the data content transferred during the diagnostic process, this means that, in addition to the actual diagnostic data (error memory contents), additional diagnostic commands are transmitted, e.g. after the KWP 2000-
  • Diagnostic protocol standard are specified.
  • hybrid forms of the two extreme variants of the partitioning of diagnostic functions described between the telematics terminal and the service center are used. For example, there is a parallel transmission of commands for window control of the overall functions and individual commands of the diagnostic protocol, which are not fixed in the
  • FIG. 3 shows the vehicle-side part 52 of the diagnostic system on the left-hand side, and the network-side part 50 on the right-hand side.
  • the arrows represent the flow of information, with a chronological order from top to bottom
  • step C1 the client requests a remote diagnosis start page to the service center.
  • this message is sent as a URL address that is stored in the terminal.
  • the request is triggered by a corresponding activation of the remote diagnosis by an operator, for example by means of a switch attached to the vehicle, an input, a
  • step S1 the server sends the terminal a WAP page for activating the remote diagnosis in the vehicle.
  • the page is implemented as a WML page.
  • the two steps mentioned represent the sub-process "Request of the remote diagnosis service".
  • the client In the next step C2 after receiving the WAP page, the client either automatically or user-initiates the transmission of a login page. Their URL was in the previously received page.
  • the server then provides the desired login page in step S2, with a reference to a login script.
  • the page is also sent here as a WML page with a corresponding script reference.
  • information about the loaded login page is possibly output on a display for the user.
  • the client automatically requests a login script for authentication and / or user identification at the server (service provider).
  • the URL for this is provided by means of the script reference in the WML
  • the server transmits the requested login script as a WML script for reading out the user data in the vehicle. This is carried out automatically by the client or by input from the operator.
  • the client then sends the data (user identification data) to the server in step C4 with the request for the next WAP page. The transmitted are then in the server
  • Steps S2 to C4 represent the subsection user identification and authentication.
  • the server starts remote diagnosis by creating a WAP page in step S4 (as a WML page with a script reference).
  • This WAP page contains a reference to the WML script for the identification of the motor vehicle.
  • the transmission of the login confirmation is possibly output as user information on a display.
  • the next step C5 the
  • Client requests a script to read out the motor vehicle identification data to the server.
  • the URL address required for this is contained in the script reference of step S4.
  • the server takes up this request and transmits a script for reading out the motor vehicle identification data to the client as part of step S5 as a WML script.
  • the corresponding identification data are then read out in the client and together with the request to the next WAP page with data in the step C6 sent to the server.
  • the transmitted vehicle identification data (vehicle type, software version if applicable, etc.), possibly with GPS position data, are checked in the server.
  • the diagnostic processes and the necessary parameters are selected from its database. This completes the sub-step of vehicle identification (S4 to C6) and the next WML page is at
  • the server then sends a diagnostic follow-up page in step S6. a. with status information including a reference to a diagnostic script to the client. This is done as
  • the client After receiving the information in step S6, the client sends the request to the server with which it requests the transmission of the diagnostic script for reading out the diagnostic data.
  • the URL address is taken from the script reference in step S6. Then in the server based on this
  • Step S7 Request generated the diagnostic script (WML script) and transferred to the client in step S7.
  • the fault memories on the vehicle side are then read out by executing the diagnostic script and transferred to the server with the request from the next WML page in step C8.
  • Steps S6 to C8 represent the partial area of reading out the diagnostic data, which in principle also consists of several
  • Runs that is, can be done with several partial scripts. For example, a script can be provided for each control device. The part operation in this area is then carried out several times.
  • the diagnostic data (error codes) are evaluated with the help of the database, evaluated if necessary, and a diagnostic results page is generated dynamically.
  • the result page is then transmitted to the client as a WML page in step S8. Based on the transmission of the results page, the diagnosis result is output on the client
  • Step S8 thus represents the partial area of the determination of the diagnosis result and its output.
  • the client if necessary, manually initiates a further request to the server with which it requests a WAP page with a follow-up recommendation.
  • the URL for this can either be stored in the end device or together with the Diagnosis results page have been transmitted.
  • a follow-up recommendation is generated from the database in the server that receives this request, a recommendation page is set up and the diagnostic process is ended.
  • the server sends the recommendation page to the client as a WML page.
  • the determined follow-up recommendation is output by the client on a display.
  • the EFI interface specified in the WAP standard is often accessed on the client side when executing the WML scripts mentioned.
  • the scenario described above is one possible implementation that can vary greatly depending on the individual case.
  • the procedure for external diagnosis always includes the following sub-steps, which are described above as sub-processes:
  • sub-steps can be partially exchanged in the order, with sub-step 6 possibly also being omitted.
  • the number or length of the individual communication steps depends on the number of units to be diagnosed in the vehicle.
  • the sequence shown takes place completely automatically at the time of activation of the external diagnosis until the diagnosis result is output without further interaction with the user.
  • the scripts are executed by transmitting predefined commands via the CAN connection to the control unit to be diagnosed.
  • the data determined by this are transmitted to the client via the CAN connection and sent by the client to the server via the air interface.
  • the procedure described above is implemented by corresponding programs in the server and in the microcomputer of the terminal, which are an independent part of the described invention. Examples of such programs are outlined in FIGS. 4 (for the server) and 5 (for the terminal).
  • the program according to FIG. 4 is started by a request to initiate the external diagnosis.
  • the server sends a predetermined WAP page for activation.
  • the server only responds to incoming requests. I.e. the server is in a kind of "inactive status" as long as no request arrives. Communication is ended for the server as soon as no further request comes from the client.
  • the receipt of a request (URL address) for a login page is expected. If a request is received, step 103 follows. If no request is received, the communication has ended unsuccessfully from the point of view of the server.
  • the server replies in accordance with the request with the login page and script reference.
  • step 105 the receipt of a request (URL address) for a login script is expected. If a request is received, step 106 follows. If no request is received, the communication from the server's point of view has ended unsuccessfully. In step 106, the server sends a login script in accordance with the request. Then, in step 107, the receipt of a request (URL address) for a next page and the receipt of user identification and authentication data are expected.
  • step 108 If a request and data is received correctly, step 108 follows. If no request and / data and / or received, the communication is ended unsuccessfully. In step 108, the user identification and authentication data are checked. Do they match pre-stored data, i.e. if the sender is authorized, step 109 follows. Otherwise, a WML page for the error message is generated and sent to the client as
  • step 123 Communication is ended (step 104).
  • step 109 the server sends, in accordance with the request, a subsequent page dynamically generated on the basis of the previously received data with confirmation of the login including a script reference to a vehicle identification script. Then in step 110 the receipt of a request (URL address) for the
  • step 111 follows. If no request is received, the communication has ended unsuccessfully. In step 111, the server sends the vehicle identification script in accordance with the request. Then, in step 112, the receipt of a request (URL address) for a subsequent page including data for the vehicle identification is expected. Will a request complete
  • Receive data follows step 113. If no request or no data is received communication ended.
  • the server generates a diagnostic script for the corresponding vehicle from its database in accordance with the transmitted vehicle data. If no script can be generated for the transmitted data, either a standard script is used or the process is ended (step 124). An error message in the form of a WML page or a reference to one is then sent back (step 125).
  • the server sends a subsequent page together with a reference to the diagnostic script (URL address) in accordance with the request. Then, in step 115, the script is expected to receive a request (URL address). If a request is received, step 116 follows. If no request or no data is received, the communication has ended unsuccessfully.
  • step 116 the server sends the diagnostic script in accordance with the request. Then, in step 117, the receipt of a request (URL address) for a subsequent page including diagnostic data is expected. If a request including data is received (see step 126), step 118 follows. If no data is received, the communication is terminated / ended. Then an error message in the form of a WML page or a reference to one is sent back (step 127). In step 118, the server determines the diagnostic result using its database in accordance with the transmitted diagnostic data. In the following step 119, the server sends the diagnostic results page in accordance with the request. Then, in step 120, the receipt of a request (URL address) for a recommendation page is expected. If a request is received, step follows
  • step 121 the server determines recommendations for the further procedure with the aid of its database in accordance with the transmitted diagnostic data.
  • step 122 the server sends the recommendation page to the client in accordance with the request (and ends the communication in step 104 and thus the
  • the client In order to be able to establish a connection on the server side between the actually independent and anonymous requests from the client, the client is assigned a one-time session TD at the beginning of the communication (after login) with which he then identifies himself with each request. This enables the server to identify which to whom
  • the program according to FIG. 5 is started by activation by a user.
  • the client sends a request (predetermined URL address) to the request.
  • step 201 the Checked receipt of an activation page. If, for example, a page is received within a set time, step 202 follows. If no request is received, the communication is terminated / ended unsuccessfully (step 204). In step 202, the client sends a request for a login page to the server (URL address). The receipt of a corresponding page is then checked in step 205. If, for example, a page is received within a set time, step 206 follows. If no page is received, the communication is interrupted / ended (step 204). In step 206, the client sends a request for a login script. The receipt of the script is then checked in step 207. If, for example, the script is received within a specified time, step 208 follows. If no script is received, the
  • step 208 the user identification data are fetched from a memory (use of EFI interface) and sent to the server, and a subsequent page is requested.
  • the receipt of a subsequent page, including login confirmation and script reference, is then checked in step 210.
  • a subsequent page with the corresponding information is received within a specified time, step 211 follows. If no page or no confirmation is received, the communication is terminated / ended (step 204).
  • step 211 a request for a vehicle identification script is sent.
  • the receipt of a script is then checked in step 212.
  • Receive a script within a set time follows step 213. If no script is received, the communication is terminated / ended unsuccessfully (step 204).
  • step 213 the vehicle identification data are determined (for example from a memory in the terminal or by request from the control devices / components to be diagnosed (use of EFI interface) and a request for a subsequent page including identification data is sent. Subsequently in step 214 the receipt of a diagnostic page is sent Reference to the
  • step 215 follows. If no data is received, the communication is terminated / ended unsuccessfully (step 204). In step 215, the request for a diagnostic script is made. The receipt of a diagnostic script is then checked in step 216. E.g. receive a request within a set time follows
  • Step 217 If no WML script is received, communication is terminated / ended (step 204).
  • the diagnostic data are determined by appropriate communication with the control devices to be diagnosed (use of EFI interface) and sent with a request for a subsequent page.
  • the receipt of a result page is then checked in step 218. If, for example, a request including data is received within a specified time, step 219 follows Received answer page, the communication is aborted / ended unsuccessfully (step 204).
  • step 219 it is determined based on the result whether a recommendation page should be requested. If no, the process is ended (step 204), if yes, a corresponding request is sent (step 220). The receipt of a recommendation page is then checked in step 222.
  • step 223 follows. If no page is received, communication is terminated / ended (step 204). In step 223, the recommendation page is displayed and the communication and thus the external diagnosis process is ended in accordance with step 204. In the meantime, the pages received are usually displayed (contains from

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Vehicle Cleaning, Maintenance, Repair, Refitting, And Outriggers (AREA)

Abstract

Es wird ein Verfahren und Vorrichtung zur Übertragung, zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug vorgeschlagen, wobei die Übertragung von Informationen, zur Realisierung einer fahrzeugbezogenen Fernkontrolle dienen, über ein Mobilfunknetz erfolgt. Die Kommunikation findet dabei auf der Basis eines standardisierten, an die Gegebenheiten des Mobilfunknetzes angepassten Protokolls, vorzugsweise des WAP-Protokolls, statt.

Description

VERFAHREN UND VORRICHTUNG ZUM SENDEN UND/ODER ZUM EMPFANG VON INFORMATIONEN IN VERBINDUNG MIT EINEM FAHRZEUG
Stand der Technik
Die Erfindung betrifft ein Verfahren und Vorrichtung zur Übertragung, zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug, insbesondere zur Ferndiagnose, Fernsteuerung und/oder Fernbedienung einer Komponente/Funktion des Fahrzeugs.
In der DE 100 26 754 AI ist ein Verfahren und eine Vorrichtung zur Übertragung, zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug beschrieben, Es findet ein Datenaustausch über ein Telekommunikationsnetz und/oder ein Datennetz zur Realisierung einer Fernwartung, einer Ferndiagnose und/oder einer Fernsteuerung eines Kraftfahrzeugs, einer seiner Komponenten und/oder Funktionen statt. Als Beispiel für das Telekommunikationsnetz wird dabei ein Mobilfunknetz nach dem GSM-Standard oder nach dem UMTS-Standard vorgeschlagen, während als Beispiel für das Datennetz das Internet erwähnt ist. Hinweise auf die konkrete Ausgestaltung insbesondere im Hinblick auf Flexibilität und/oder Zuverlässigkeit und/oder Sicherheit des Informationsaustausches und/oder im Hinblick auf die Aufwandsreduzierung vor allem bei den Endgeräten im Fahrzeug werden nicht gegeben.
Vorteile der Erfindung
Durch die Kommunikation von mobilen Endgeräten mit stationären Rechnern im Internet über standardisierte Kommunikations wege, z.B. über das WAP-Protokoll, können bereits vorhandene Telematikendgeräte im Fahrzeug, die über einen entsprechenden Zugang verfügen, zur Durchführung von fahrzeugbezogenen Telematikanwendungen wie beispielsweise Fernabfrage und/oder Fernsteuerung von Fahrzeugkomponenten und/oder der Durchführung einer Ferndiagnose benutzt werden, ohne dass eine völlige Neukonzeption dieser Endgerät mit dem entsprechenden Aufwand notwendig sind.
Besonders vorteilhaft ist die Verwendung des WAP-Protokolls, da dessen leistungsfähige Übertragungs- und/oder Sicherheitsmechanismen für die spezifische Anwendung im mobilen Bereich, insbesondere für die genannten fahrzeugbezogenen Telematikanwendungen wie die Ferndiagnose von Kraftfahrzeugsteuergeräten, genutzt werden können.
Ein weiterer positiver Effekt der Verwendung dieses Protokolls ist, dass Ressourcen wie Speicher- und Rechenleistung bei den Endgeräten eingespart werden, da dieses Protokoll speziell für Endgeräte mit wenig Ressourcen ausgelegt ist. Bei der Verwendung dieses
Protokolls werden keine zusätzlichen Funktionseinheiten für die Datenübertragung und die Visualisierung der Inhalte benötigt werden. Dies wird allein durch die Verwendung eines an sich bekannten WAP-Browsers und dem zugehörigen WAP- Kommunikationsstack erreicht. Besonders günstig im Hinblick auf die Einsparung von Ressourcen im Endgerät ist die Nutzung des WAP-Protokolls, wenn dieses im Endgerät ohnehin vorhanden ist für andere Dienste, wie z. B. mobile Internet. Die Synergie, die durch die Nutzung des Protokolls erreicht wird, ist daher beachtlich.
Durch die Realisierung der übertragenen WAP-Inhalte in Form von WML-Seiten können statisch und auch dynamisch generierte Inhalte, z.B. zur Interaktion mit dem Nutzer, dem
WAP-Browser im Endgerät vom Server bereitgestellt werden. Dabei können die WML- Seiten auch sogenannte WML-Skripte enthalten, welche die Beschreibung komplexerer Abläufe im Endgerät ermöglichen. Teile der Endgeräte- Applikationen wie z. B. Ferndiagnose müssen dadurch nicht selbst explizit dort umgesetzt werden, sondern sind im WAP-Stack bereits realisiert und universell nutzbar.
Besonders vorteilhaft ist, dass der WAP-Standard eine Schnittstelle bereitstellt (EFI- Interface) mit deren Hilfe der WAP-Browser (und damit indirekt der Server) mit eigenständigen, externen Applikationen auf dem mobilen Endgerät über ein standardisiertes Funktions-Interface kommunizieren können. Somit werden Mechanismen angeboten, die die Kommunikation mit Softwarekomponenten, die nicht im Browser enthalten sind wie z.B. die Diagnoseschnittstelle zu den zu diagnostizierenden Steuergeräte, erleichtern.
Besonders vorteilhaft ist, dass zusätzlich zu den obengenannten fahrzeugbezogenen Telematikanwendungen wie die Ferndiagnose von Kraftfahrzeugsteuergeräten auch weitere Telematikdienste wie Pannenruf, Notruf oder Verkehrsinformation über das standardisierte Protokoll realisierbar sind.
Besonders vorteilhaft ist, dass unter Verwendung des standardisierten Protokolls die Kommunikation zwischen Endgerät und Server im Rahmen fest vorgegebener
Teilschritte als Frage-Antwort-Kommunikation aufbauend auf standardisierten Datenrahmen und -inhalte (WML, WML-Script) realisiert wird.
In besonders vorteilhafter Weise ist durch Ausnutzung der bestehenden Sicherheitsmechanismen möglich, nach Aktivierung des Telematikdienstes durch
Nutzeridentiiϊkation, Authentifizierung und/oder Fahrzeugidentifikation eine besonders sichere und zuverlässige Realisierung des Informationsaustausches bereitzustellen.
Die Verwendung eines an mobile Anwendungen angepassten Protokollstandards (z.B. WAP) zeigt besonders vorteilhafte Ergebnisse in Verbindung mit Telematikdiensten bei
Kraftfahrzeugen über Mobilfunknetze.
Weitere Vorteile ergeben sich aus der nachfolgenden Beschreibung sowie aus den abhängigen Patentansprüchen.
Zeichnung
Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten Ausführungsformen näher erläutert. Figur 1 zeigt dabei ein Übersichtsbild eines Systems für einen fahrzeugbezogenen Telematikdienst, während anhand Figur 2 ein
Realisierungsbeispiel eines solchen Systems auf der Basis des WAP-Protokolls gezeigt ist. Figur 3 zeigt ein geeignetes Ausführungsbeispiel von Übertragungsschritten über die Schnittstelle zwischen Telematikendgerät und Server. Die Figuren 4 und 5 zeigen Flussdiagramme, welche die Programmabläufe im Telematikendgerät bzw. im Server am Beispiel der in Figur 3 dargestellten Kommunikation skizzieren. Beschreibung von Ausführungsbeispielen
Figur 1 zeigt ein Übersichtsbild eines Systems für einen fahrzeugbezogenen Telematikdienst, wobei Informationen zwischen einem Fahrzeug (dort Endgerät) und einem Server über ein Mobilfunknetz bzw. über ein Datennetz, wie beispielsweise das
Internet, ausgetauscht werden. Eine derartige Konfiguration wird in Verbindung mit Funktionen zur Fernwirkung, Ferndiagnose, Fernwartung, Software Download, etc. eingesetzt. Unter Fernwirkung bzw. Fernabfrage wird dabei im wesentlichen die Fernsteuerung von Fahrzeugfunktionen, insbesondere Komfortfunktionen wie das Einschalten der Standheizung, etc., sowie das Abfragen von Fahrzeugstati und/oder
Betriebsparametern verstanden. Dabei initiiert der Nutzer eine Kommunikation mit dem Fahrzeug über einen zentralen Server oder er kommuniziert direkt mit dem Fahrzeug. Ferndiagnose umfasst das Fernauslesen von Diagnosedaten aus dem Fahrzeug, deren Analyse und ggf. das Erzeugen einer Empfehlung für das weitergehende Handeln. Analyse der Daten und Generierung der Empfehlung erfolgt dabei durch einen zentralen
Server, der mit dem Fahrzeug über ein Mobilfunknetz, über ein drahtgebundenes Netz und/oder über ein Datennetz wie beispielsweise das Internet mit dem Kraftfahrzeug in Verbindung steht. Ferner ist in diesem Zusammenhang als Funktion der sogenannte Software-Download bzw. das Remote-Flashing zu nennen, mit deren Hilfe ein neuer Programmcode oder Parameter auf per Software konfigurierbare Systeme im Fahrzeug, beispielsweise Steuergeräte, aufgebracht werden, um die Funktionalitäten oder die Leistungsfähigkeit zu erhöhen. Auch hier erfolgt die Kommunikation über ein Mobilfunknetz, ein drahtgebundenes Netz und/oder beispielsweise das Internet ausgehend von einem zentralen Rechner (Server) bzw. Service-Center. Fernwartung stellt im wesentlichen die Überwachung des Fahrzeugzustandes und den
Zugriff auf die Wartungsdaten im Fahrzeug von einer zentralen Stelle aus dar, um zu überprüfen, ob, wann und welche Maßnahmen zur Wahrung des Sollzustandes durchgeführt werden. Ein Beispiel hierfür ist das dynamische Anpassen von Wartungsintervallen. Allgemein werden diese Funktionalitäten hier unter dem Begriff der fahrzeugbezogenen Fernkontrolle subsumiert.
Alle genannten Funktionen bzw. Dienste werden über die nachfolgend beschriebene Schnittstelle zwischen dem Kraftfahrzeug (dort dem Endgerät) und einem zentralen Rechner, insbesondere einem Server in einem Service-Center oder beim Fahrzeughersteller oder beim Komponentenzulieferer, realisiert. Sofern notwendig erfolgt die Steuerung von Komponenten und/oder Funktionen im Fahrzeug über eine nachfolgend ebenfalls beschriebene Schnittstelle zwischen Endgerät und der betroffenen Fahrzeugkomponente. Im Folgenden wird die Ausführung anhand des Dienstes „Ferndiagnose" dargestellt, in entsprechender Weise erfolgt die Anwendung der Schnittstelle auch in Verbindung vielen anderen Diensten, wie z. B. den oben genannten.
Figur 1 zeigt eine Übersichtsdarstellung eines Ferndiagnosesystems. Fahrzeugseitig ist die Fahrzeugelektronik 1 beispielsweise ein Steuergeräteverbund dargestellt, welcher über eine vorbestimmte Schnittstelle 2 mit dem fahrzeugseitigen Teil 3 des Ferndiagnosesystems, insbesondere mit einem Telematikendgerät verbunden ist. Diese fahrzeugseitige Applikation nutzt die in der Fahrzeugelektronik integrierten
Diagnosemechanismen (Onboard-Diagnose) beispielsweise zur Erfassung von Fehlerspeicherinhalten. Der fahrzeugseitige Teil des Ferndiagnosesystems 3 greift über die Schnittstelle 2 beispielsweise über einen CAN-Bus oder eine K-Leitung im Rahmen eines vorgegebenen Kommunikationsprotokoll auf das Fahrzeugnetzwerk und somit auf die Fahrzeugelektronik 1 bzw. die zu diagnostizierende Steuergeräte zu.
Der beschriebene fahrzeugseitige Teil ist über eine weitere Schnittstelle 4 mit dem zentralen Teil 5 des Ferndiagnosesystems verbunden. Dieser zentrale Teil stellt vorzugsweise den Server bzw. das Rechnersystem eines Service-Centers dar. Im bevorzugten Ausführungsbeispiel arbeitet dieser Server möglichst viele der bei der
Ferndiagnose anfallenden Aufgaben ab, so dass im Fahrzeugendgerät möglichst wenig Ressourcen vorgehalten werden müssen. Beispielsweise übernimmt er im wesentlichen die Konfiguration der Diagnoseeinheit im Fahrzeug zu Beginn der Diagnose, die Steuerung dieser Einheit während des Vorgangs und die Auswertung der ermittelten Daten. Dazu greift er insbesondere auf fahrzeugindividuelle Daten und Befehle zurück, die im Datenspeicher 6 gespeichert sind. Im bevorzugten Ausführungsbeispiel ist der Server ein Internet-Server.
Die Übertragungsstrecke 4 zwischen Server und Client (Fahrzeugendgerät) ist im bevorzugten Ausführungsbeispiel wegen den Eigenschaften bezüglich Abdeckung,
Verfügbarkeit und Kosten eine Mobilfunkschnittstelle. Das in Verbindung mit der Ferndiagnose zum Informationsaustausch eingesetzte Protokoll ist ein standardisiertes Protokoll, welches an die speziellen Anforderung eines Mobilfunknetzes angepasst ist. Im Zusammenhang mit der oben beschriebenen Anwendung hat sich das wireless application protocol (WAP) als geeignet erwiesen. Das WAP ist eine weltweit standardisierte
Kommunikation von mobilen Endgeräten mit stationären Rechnern im Internet. Es besteht aus verschiedenen Einzelprotokollen, die den vollständigen Kommunikationsvorgang beschreiben. Dabei verfügt jedes WAP-fähige Endgerät über einen speziellen WAP-Browser zur Interpretation und Visualisierung der standardisierten Übertragungsinhalte. Die übertragenen Inhalte werden in Form von WML-Seiten realisiert. Diese Seiten können auch sogenannte WML-Skripte enthalten, die die Beschreibung komplexerer Abläufe im Endgerät ermöglichen. Ferner gibt es ein standardisiertes Funktionsinterface (EFI-Interface), welches Bestandteil des WAP- Browsers ist und zur Kommunikation mit Softwarekomponenten, die nicht im Browser enthalten sind, also insbesondere Fahrzeugfunktionen, Diagnosefunktionen, etc, dient.
Neben den geschilderten Kernfähigkeiten des WAP-Protokolls werden in der spezifischen Anwendung zur Ferndiagnose von Kraftfahrzeugen bzw. Kraftfalirzeugkomponenten die Sicherheitsmechanismen des Protokolls eingesetzt. Damit sind keine zusätzlichen Funktionseinheiten im Endgerät zur Gewährleistung der Sicherheit des Datentransfers und/oder zur Bereitstellung von Zugriffsrechten notwendig.
Figur 2 zeigt ein Schaubild, welches eine Realisierung eines Ferndiagnosesystems mit WAP-Kommunikation darstellt. Der fahrzeugseitige Teil 10 (Endgerät) besteht im Wesentlichen aus einem Modul 10a, welches die Funktionalitäten der Diagnoseanwendung umfasst, aus einem Modul 10c, dem WAP-Browser und einem
Kommunikationsmodul lOd, welches Information ins Mobilfunknetz sendet und von dort empfängt. Das Modul 10a ist über ein Bussystem 12 (Diagnosebus), beispielsweise ein CAJM-Bus, mit anderen Steuereinheiten und/oder Komponenten des Fahrzeugs verbunden. Über diese Schnittstellen werden Informationen, Daten und/oder Befehle ausgetauscht. Über eine weitere Schnittstelle 10b (EFI-Schnittstelle) ist das Modul 10a mit dem Web-Browser 10c verknüpft. Das Kommunikationsmodul lOd sendet bzw. empfängt über einen Sender bzw. Empfänger 14, z.B. ein Mobilfunkgerät, Daten zur bzw. über die Luftschnittstelle 16. Ferner ist (in Figur 2 nicht dargestellt) ein Betriebssystem zur Organistaion der Abläufe sowie im Modul 10c der sogenannte WAP-Stack vorgesehen, der die Funktionalitäten zur Realisierung des WAP-Protokolls enthält.
Der fahrzeugseitige Teil des Systems ist in einem Ausführungsbeispiel in einem Telematikendgerät integriert. In diesem ist auch das geschilderte GSM-Modul für den Mobilfunkverkehr und der WAP-Stack für die Internetfunktionalität enthalten. Die Anbindung an den Diagnose-Bus, meistens über CAN, ist ebenfalls vorhanden. Anstelle des GSM-Standards oder ergänzend hierzu sind für die Kommunikation über WAP auch Mobilfunkstandards wie GPRS oder UMTS gut geeignet, da diese einen schnellen Verbindungsaufbau, geringe Verzögerungszeiten und eine hohe Datenübertragungsrate zu geringen Kosten vorweisen.
Die Kommunikation zwischen Fahrzeugendgerät und zentraler Rechnereinheit erfolgt über ein Mobilfunknetz 16. Die zentrale Recheneinheit 18, insbesondere ein Web-Server, empfängt von einer Sende-/Empfangseinrichtung 20 der Mobilfunkschnittstelle direkt oder über einen Gateway-Rechner Daten vom fahrzeugseitigen Teil des Systems oder sendet Daten an diesen. Wird ein Gateway-Rechner auf der Netzwerkseite eingesetzt, bildet dieser das WAP-Gateway (hier wird der WAP-stack implementiert). Üblicherweise findet in einem solchen Gateway die Einwahl des Mobilfunkgerätes 14 in das Internet statt. Neben dem WAP-Modul umfasst der Gateway-recher insbesondere auch die Kommunikationsschnittstelle zum Mobilfunknetz sowie die Schnittstelle zum Web- Server. Das WAP-Gateway hat einerseits die Aufgabe, eine Protokollumsetzung von
WAP- auf das Internet-Format HTTP und umgekehrt vorzunehmen, andererseits eine Kompression und Vorkompilierung der vom angefragten Web-Server erhaltenen WML- Seiten und — Skripte durchzuführen, bevor diese an den Mobilfunkteilnehmer zurückgeschickt werden. Diese Gateway-Funktion übernimmt wie in Figur 2 dargestellt der Server 18 selbst (Modul 18a, Mobilfunknetzschnittstellenmodul 18b), während in anderen Ausführung ein mit dem Server über eine Internetverbindung verbundener Gatewayrechner die geschilderten Aufgaben übernimmt.
Der Web-Server 18 beispielsweise eines Service-Center hat die Aufgabe des Diagnose- Servers. Die im Web-Server 18 implementierte Software (Modul 18c) beantwortet die
Anfragen des Clients (Endgerät) mit dynamisch generierten Antwortseiten und -Skripten. Die dynamische Generierung der Antworten erfolgt mit Hilfe von vorgegeben, serverseitigen Skripten (Programme) und einer Datenbank 22, die alle notwendigen Daten zur Identifikation, Konfiguration und Ausführung der Diagnoseapplikation im Fahrzeug für den entsprechenden Anfragenden beinhaltet. Aufgaben des Web-Servers sind zum einen allgemeine Web-Server-Aufgaben, z.B. Bearbeitung von Anfragen, Verteilung der Seiten oder Dateien an den richtigen Empfänger, das Kommunikations- Management, etc., ferner die übergeordnete Ablaufsteuerung der Diagnose und Konfiguration der Diagnoseapplikation im Client über dynamisch generierte WML- Seiten und -Skripte, das Vorhalten und Verwalten der für die Fahrzeugdiagnose notwendigen Daten in einer Datenbank, das Verwalten der Datenbank selbst, die Auswertung der vom Fahrzeug kommenden Nutzdaten, das Vorhalten bzw. die dynamische Generierung der Oberfläche für die Ferndiagnoseapplikation im Fahrzeug. Das Ermitteln der Nutzdaten (Fehlerspeicher), das heißt die Diagnose selbst, wird dabei nach bekannten Diagnosemethoden, die im Fahrzeug implementiert sind, durchgeführt.
Während des Diagnosevorgangs werden WML-Seiten und WML-Skripte zur Steuerung der Diagnoseabläufe vom Server zum Endgerät übertragen und von diesem verarbeitet. Dabei werden u. a. Daten daraus auf den CAN-Bus umgesetzt. Auf ein eigenimplementiertes Mensch-Maschinen-Interface im fahrzeugseitigen Teil des Systems wird dabei verzichtet, da dieses durch die Anzeige der WML-Seiten im WAP-Browser realisiert ist.
Ein Beispiel für die Kommunikation zwischen Server 50 und fahrzeugseitigem Teil 52 ist anhand Figur 3 dargestellt. Im dargestellten Fall beginnt die Initiierung des
Kommunikationsvorgangs durch eine Bedienperson, z.B. den Fahrer des Kraftfahrzeugs.
In anderen Ausführungen wird die Aktivierung der Ferndiagnosekommunikation durch das Service-Center vorgenommen. In einer Ausführung erfolgt die Initiierung über den
Server, in dem dieser vorab zur Darstellung der Figur 3 als zusätzlichen Schritt den Client zum Aufbau einer Kommunikationsverbindung auffordert, z. B. über eine SMS an den
Client. Ein solcher Vorgang ist im WAP-Standard als sog. Push spezifiziert / standardisiert.
Die für die Ferndiagnose relevanten Inhalte bzw. Daten, die neben den eigentlichen Diagnosedaten auch Kommandos zur Steuerung und Konfiguration der im Fahrzeug integrierten Ferndiagnosefunktionalität beinhalten, sind je nach Ausführung unterschiedlich strukturiert. In einer ersten Ausführung enthält die Ferndiagnoseeinheit im Fahrzeug Mechanismen und Funktionen für die eigenständige Durchführung der Diagnosevorgänge. Das Auslesen von Steuergerätefehlerspeichern zur Datenerfassung erfolgt durch ferngesteuerte Funktionen im Telematikendgerät. In diesem sind funktionale Einheiten wie die Transportprotokollschicht für CAN-Bus-Daten, die für den logischen Diagnosevorgang notwendige Protokollschicht und eine entsprechende Ablaufsteuerung enthalten. Dabei ist auch vorgesehen, die erforderlichen Daten für die entsprechenden Protokollschichten und für die Ablaufsteuerung zu Beginn des Diagnosevorgangs vom Diagnose-Server herunterzuladen und mit Hilfe von
Protokollmakros und Kommunikationsparametern die Schichten zu konfigurieren. Dies hat zur Folge, dass neben den eigentlichen Steuerkommandos zur Femsteuerung der Ferndiagnosefunktionen gegebenenfalls auch Parameter und Diagnosemakros übertragen werden müssen. Die für die Parametrisierung notwenigen Daten werden prinzipiell auch dauerhaft im Telematikendgerät vorgehalten, was deren Übertragung vom Server zum Client überflüssig macht. In einer zweiten Ausführung ist die Übertragung von
Kommandos auf der Ebene des Diagnoseprotokolls vorgesehen. In diesem Fall führt die Einheit im Fahrzeug den Diagnosevorgang nicht eigenständig durch, sondern reicht nur die vom Server kommenden Daten an das zu diagnostizierende Steuergerät durch. Dadurch werden Diagnoseprotokollfunktionalitäten im Fahrzeug sehr stark und bis auf ein Minimum reduziert. Sie verbleiben nahezu vollständig im Server. In diesem Fall werden die einzelnen Diagnosekommandos transparent über die Luftschnittstelle übertragen. Lediglich einige wenige einfach strukturierte Nachrichten werden im Fahrzeug generiert. Dies bedeutet für die während des Diagnosevorgangs übertragenen Dateninhalte, dass neben den eigentlichen Diagnosedaten (Fehlerspeicherinhalte) zusätzlich Diagnosekommandos übertragen werden, die z.B. nach dem KWP 2000-
Diagnoseprotokollstandard spezifiziert sind. In einer dritten Ausführung werden Mischformen der beiden geschilderten, extremen Varianten der Partitionierung von Diagnosefunktionen zwischen Telematikendgerät und Service-Center eingesetzt. Beispielsweise erfolgt eine parallele Übertragung von Kommandos zur Fenisteuerung der Gesamtfunktionen und einzelne Kommandos des Diagnoseprotokolls, die nicht fest im
Endgerät integriert sind.
Die Darstellung in Figur 3 zeigt auf der linken Seite den fahrzeugseitigen Teil 52 des Diagnosesystems, auf der rechten Seite den netzwerkseitigen Teil 50. Die Pfeile stellen den Informationsfluss dar, wobei von oben nach unten eine zeitliche Reihenfolge der
Anfragen und Antworten im Rahmen der Kommunikation dargestellt ist. Die dargestellten Kommunikationsschritte sind dabei beispielhaft. Ihre Anzahl kann beispielsweise durch Zusammenfassung einzelner Teilabläufe in einem Kommunikationsvorgang auch reduziert werden.
Zunächst erfolgt im Schritt Cl die Anfrage einer Ferndiagnosestartseite an das Service- Center durch den Client. Im bevorzugten Ausführungsbeispiel wird diese Nachricht als URL-Adresse gesendet, die im Endgerät gespeichert ist. Ausgelöst wird die Anfrage durch eine entsprechende Aktivierung der Ferndiagnose durch eine Bedienperson, beispielsweise mittels eines im Fahrzeug angebrachten Schalters, einer Eingabe, einer
Befehlskombination, oder aufgrund einer über Mobilfunk (von einer Bedienperson, vom Service-Center, etc.) übermittelten Aufforderung. Die Antwort des Servers ist im Schritt Sl dargestellt. Im bevorzugten Ausführungsbeispiel sendet der Server dem Endgerät eine WAP-Seite zur Aktivierung der Ferndiagnose im Fahrzeug dar. Die Seite wird dabei als WML-Seite realisiert. Die beiden genannten Schritte stellen den Teilvorgang „Anfrage des Ferndiagnosedienstes" dar.
Im nächsten Schritt C2 nach Empfang der WAP-Seite fordert der Client entweder automatisch oder Nutzer-initiiert die Übermittlung einer Login-Seite an. Deren URL befand sich in der zuvor erhaltenen Seite. Der Server stellt daraufhin im Schritt S2 die gewünschte Login-Seite bereit, mit einem Verweis auf ein Login-Skript. Die Seite wird auch hier als WML-Seite mit einem entsprechenden Skriptverweis gesendet. Im Client wird gegebenenfalls eine Information über die geladene Login-Seite auf einem Display für den Nutzer ausgegeben. Im nächsten Schritt C3 erfolgt eine automatische Anfrage eines Login-Skripts durch den Client zur Authentifizierung und/oder Nutzeridentifikation beim Server (Dienstleister). Die URL dazuwird mittels des Skiptverweises in der WML-
Seite ermittelt. Im darauffolgenden Schritt S3 übermittelt der Server das angeforderte Login-Skript als WML-Skript zum Auslesen der Nutzerdaten im Fahrzeug. Dieses wird vom Client automatisch oder durch Eingabe der Bedienperson ausgeführt. Daraufhin sendet der Client im Schritt C4 mit der Anfrage für die nächste WAP-Seite die Daten (Nutzeridentifikationsdaten) an den Server. Im Server werden dann die übermittelten
Nutzerdaten überprüft und bei Korrektheit dieser Daten der Ferndiagnose-Vorgang fortgeführt, im anderen Fall abgebrochen oder Schritt S3 wiederholt. Die Schritte S2 bis C4 stellen dabei den Teilabschnitt Nutzeridentifikation und Authentifizierung dar.
Sind die Nutzerdaten also in Ordnung, so beginnt der Server mit der Ferndiagnose, indem er im Schritt S4 eine WAP-Seite (als WML-Seite mit Skriptverweis) ,die nach erfolgreicher Identifikation des Users u. a. eine Login-Bestätigung übermittelt. Diese WAP-Seite enthält dabei einen Verweis auf das WML-Skript für die Identifikation des Kraftfahrzeugs. Im Client wird die Übermittlung der Loginbestätigung gegebenenfalls als Nutzerinformation auf einem Display ausgegeben. Im nächsten Schritt C5 sendet der
Client eine Anfrage eines Skripts zum Auslesen der Kraftfahrzeugidentifikationsdaten an den Server. Die dazu benötigte URL-Adresse ist im Skriptverweis des Schrittes S4 enthalten. Der Server nimmt diese Anfrage auf und übermittelt im Rahmen des Schrittes S5 als WML-Skript ein Skript zum Auslesen der Kraftfahrzeugidentifikationsdaten an den Client . Daraufhin werden im Client die entsprechenden Identifikationsdaten ausgelesen und zusammen mit der Anfrage der nächsten WAP-Seite mit Daten im Schritt C6 an den Server geschickt. Die übermittelten KFZ-Identifikationsdaten (Fahrzeugtyp, ggf. Softwarestand, etc.), gegebenenfalls mit GPS-Positionsdaten, werden im Server überprüft. Abhängig von den Daten werden die Diagnoseabläufe und die notwendigen Parameter aus seiner Datenbank ausgewählt. Damit ist der Teilschritt der Fahrzeugidentifikation (S4 bis C6) abgeschlossen und die nächste WML-Seite wird beim
Server angefragt. Die URL dazu wurde im soeben ausgeführten Teilschritt an den Client mitübermittelt.
Der Server sendet daraufhin im Schritt S6 eine Diagnose-Folgeseite u. a. mit Statusinformation samt Verweis auf ein Diagnose-Skript an den Client. Diese erfolgt als
WML-Seite mit Skript-Verweis. Im Client wird gegebenenfalls der Diagnosestart dem Nutzer auf einem Display dargestellt. Nach Empfang der Informationen in Schritt S6 sendet der Client die Anfrage zum Server, mit der er die Übertragung des Diagnoseskripts zum Auslesen der Diagnosedaten anfordert. Die URL- Adresse wird aus dem Skriptverweis im Schritt S6 entnommen. Im Server wird dann auf der Basis dieser
Anfrage das Diagnose-Skript (WML-Skript) generiert und im Schritt S7 zum Client übertragen. Daraufhin werden unter Ausführung des Diagnose-Skripts die Fehlerspeicher auf der Fahrzeugseite ausgelesen und mit der Anfrage der nächsten WML-Seite im Schritt C8 zum Server übertragen. Die Schritte S6 bis C8 stellen dabei den Teilbereich des Auslesens der Diagnosedaten dar, welches grundsätzlich auch in mehreren
Durchläufen, das heißt mit mehreren Teilskripten erfolgen kann. Beispielsweise kann je Steuergerät ein Skript vorgesehen sein. Der Teil Vorgang in diesem Bereich wird dann mehrfach durchgeführt.
Mit Hilfe einer im vorhergehenden Schritt erhaltenenURL-Adresse wird eine WAP-
Folgeseite, die das Diagnoseergebnis enthält, angefragt. Im Server werden die Diagnosedaten (Fehlercodes) mit Hilfe der Datenbank ausgewertet, ggf. bewertet und dynamisch eine Diagnose-Ergebnisseite generiert. Die Ergebnisseite wird dann im Schritt S8 als WML-Seite an den Client übermittelt. Aufgrund der Übermittlung der Ergebnisseite erfolgt im Client die Ausgabe des Diagnose-Ergebnisses auf einem
Display. Schritt S8 stellt somit den Teilbereich des Ermitteins des Diagnose-Ergebnisses und seine Ausgabe dar.
Im darauf folgenden Schritt C9 sendet der Client ggf. manuell initiiert eine weitere Anfrage an den Server, mit der er eine WAP-Seite mit Folgeempfehlung anfordert. Die
URL dazu kann entweder im Endgerät gespeichert vorliegen oder zusammen mit der Diagnose-Ergebnisseite übermittelt worden sein. Im Server, der diese Anfrage empfängt, wird aus der Datenbank abhängig vom erkannten Fehler oder den erkannten Fehlem eine Folgeempfehlung generiert, eine Empfehlungsseite aufgebaut und der Diagnosevorgang beendet. Im Schritt S9 sendet der Server die Empfehlungsseite als WML-Seite an den Client. Die ermittelte Folgeempfehlung wird vom Client auf einem Display ausgegeben.
Ergänzend sei erwähnt, dass in den WML-Skripten oder Seiten (je nach Implementierung) zum Abschluss der Befehl für den Browser vorhanden ist, die nächste WML-Seite aufzusuchen und die damit verbundenen Daten zu laden sowie ggf. im Client ermittelte Daten mit der Anfrage an den Server zu übertragen.
Im vorgestellten Übertragungsszenario wird auf Client-Seite bei der Ausführung der genannten WML-Skripte desöfteren auf die im WAP-Standard spezifizierte EFI- Schnittstelle zugegriffen. Das oben beschriebene Szenario ist eine mögliche Ausführung, die je nach Einzelfall stark variieren kann. Die Vorgehensweise zur Femdiagnose sieht jedoch immer die folgende Teilschritte vor, die oben als Teilvorgang beschrieben sind:
1. Anfrage des Femdiagnosedienstes
2. Nutzeridentifikation und -authentifizierung
3. Kraftfahrzeugidentifikation 4. Diagnosedaten auslesen
5. Diagnoseergebnisse ermitteln
6. Folgeempfehlung ermitteln
Dabei können diese Teilschritte in der Reihenfolge teilweise getauscht werden, wobei der Teilschritt 6 gegebenenfalls auch entfallen kann.
Die Zahl bzw. die Länge der einzelnen Kommunikationsschritte hängt von der Anzahl der zu diagnostizierenden Einheiten im Fahrzeug ab. Der dargestellte Ablauf erfolgt zum Zeitpunkt der Aktivierung der Femdiagnose bis zur Ausgabe des Diagnoseergebnisses vollkommen automatisch ohne weitere Interaktion mit dem Nutzer.
Im Client werden die Skripte durch Übermittlung vorgegebener Befehle über die CAN- Verbindung an das zu diagnostizierende Steuergerät ausgeführt. Die von diesem ermittelten Daten werden über die CAN-Verbindung zum Client übertragen und von diesem über die Luftschnittstelle an den Server gesendet. Die oben beschriebene Vorgehensweise wird durch entsprechende Programme im Server und im Mikrocomputer des Endgerät realisiert, die selbständiger Bestandteil der beschriebenen Erfindung sind. Beispiele für solche Programme sind in den Figuren 4 (für den Server) und 5 (für das Endgerät) skizziert.
Das Programm gemäß Figur 4 wird durch eine Anfrage zur Einleitung der Femdiagnose gestartet. Im Schritt 100 sendet der Server eine vorbestimmte WAP-Seite zur Aktivierung. Der Server reagiert stets nur auf hereinkommende Anfragen. D. h. der Server ist in einer Art "inaktivem Status" solange keine Anfrage eintrifft.. Die Kommunikation ist für den Server beendet, sobald keine Anfrage vom Client mehr kommt. In Schritt 102 wird der Empfang einer Anfrage (URL-Adresse) für eine Login- Seite erwartet. Wird eine Anfrage empfangen, folgt Schritt 103. Wird keine Anfrage empfangen, ist die Kommunikation aus Sicht des Servers erfolglos beendet . Im Schritt 103 antwortet der Server nach Maßgabe der Anfrage mit der Login-Seite samt Skriptverweis. Daraufhin wird in Schritt 105 der Empfang einer Anfrage (URL-Adresse) für ein Login-Skript erwartetWird eine Anfrage empfangen, folgt Schritt 106. Wird keine Anfrage empfangen, ist die Kommunikation aus Sicht des Servers erfolglos beendet. Im Schritt 106 sendet der Server nach Maßgabe der Anfrage ein Login-Skript. Daraufhin wird in Schritt 107 der Empfang einer Anfrage (URL-Adresse) für eine nächste Seite sowie der Empfang von Nutzeridentifikations- und Authentifizierungsdaten erwartet.
Wird eine Anfrage und Daten korrekt empfangen, folgt Schritt 108. Wird keine Anfrage und/Daten und/oder empfangen, wird ist die Kommunikation erfolglos beendet. In Schritt 108 werden die Nutzeridentifikations- und Authentifizierungsdaten überprüft. Stimmen sie mit vorgespeicherten Daten überein, d.h. ist der Sender berechtigt, folgt Schritt 109. Andernfalls wird eine WML-Seite zur Fehlermeldung generiert und an den Client als
Antwort auf seine fehlerhafte Anfrage geschickt (Schritt 123). Die Kommunikation ist damit beendet (Schritt 104). Im Schritt 109 sendet der Server nach Maßgabe der Anfrage eine anhand der vorher erhaltenen Daten dynamisch generierte Folgeseite mit Bestätigung des Login samt Skriptverweis auf eine Fahrzeugidentifikationsskript. Daraufhin wird in Schritt 110 der Empfang einer Anfrage (URL-Adresse) für das
Fahrzeugidentifikationsskript erwartet. Wird eine Anfrage empfangen, folgt Schritt 111. Wird keine Anfrage empfangen, ist die Kommunikation erfolglos beendet . Im Schritt 111 sendet der Server nach Maßgabe der Anfrage das Fahrzeugidentifikationsskript. Daraufhin wird in Schritt 112 der Empfang einer Anfrage (URL-Adresse) für eine Folgeseite samt Daten für die Fahrzeugidentifikation erwartet. Wird eine Anfrage samt
Daten empfangen, folgt Schritt 113. Wird keine Anfrage oder keine Daten empfangen, ist die Kommunikation beendet. Im Schritt 113 erzeugt der Server nach Maßgabe der übermittelten Fahrzeugdaten ein Diagnoseskript für das entsprechende Fahrzeug aus seiner Datenbank. Kann für die übermittelten Daten kein Skript erzeugt werden, wird entweder ein Standardskript verwendet oder der Vorgang beendet (Schritt 124). Dann wird eine Fehlermeldung in Form einer WML-Seite oder ein Verweis auf eine solche zurückgeschickt (Schritt 125). Im folgenden Schritt 114 sendet der Server nach Maßgabe der Anfrage eine Folgeseite samt Verweis auf das Diagnoseskript (URL-Adresse). Daraufhin wird in Schritt 115 der Empfang einer Anfrage (URL-Adresse) für das Skript erwartet. Wird eine Anfrage empfangen, folgt Schritt 116. Wird keine Anfrage oder keine Daten empfangen, ist die Kommunikation erfolglos abgeschlossen. Im Schritt 116 sendet der Server nach Maßgabe der Anfrage das Diagnoseskript. Daraufhin wird in Schritt 117 der Empfang einer Anfrage (URL-Adresse) für eine Folgeseite samt Diagnosedaten erwartet. Wird eine Anfrage samt Daten empfangen (siehe Schritt 126), folgt Schritt 118. Werden keine Daten empfangen, wird die Kommunikation abgebrochen / beendet. Dann wird eine Fehlermeldung in Form einer WML-Seite oder ein Verweis auf eine solche zurückgeschickt (Schritt 127). Im Schritt 118 ermittelt der Server nach Maßgabe der übermittelten Diagnosedaten das Diagnoseergebnis mit Hilfe seiner Datenbank. Im folgenden Schritt 119 sendet der Server nach Maßgabe der Anfrage die Diagnoseergebnisseite. Daraufhin wird in Schritt 120 der Empfang einer Anfrage (URL- Adresse) für eine Empfehlungsseite erwartet. Wird eine Anfrage empfangen, folgt Schritt
121. Wird keine Anfrage empfangen, ist diese Kommunikation erfolglos abgeschlossen (Schritt 104). Im Schritt 121 ermittelt der Server nach Maßgabe der übermittelten Diagnosedaten Empfehlungen für das weitere Vorgehen mit Hilfe seiner Datenbank. Im folgenden Schritt 122 sendet der Server nach Maßgabe der Anfrage die Empfehlungsseite an den Client (und beendet in Schritt 104 die Kommunikation und damit den
Femdiagnosevorgang ).
Um auf Serverseite einen Zusammenhang zwischen den eigentlich unabhängigen und anonymen Anfragen des Clients herstellen zu können, wird diesem zu Beginn der Kommunikation (nach dem Login) eine einmalige Session-TD vergeben mit der er sich ab dann bei jeder Anfrage identifiziert. Dadurch kann der Server erkennen zu wem welche
Anfrage gehört. Diese Art des Sessionmanagement ist im Internetbereich bekannt und weit verbreitet.
Das Programm gemäß Figur 5 wird durch die Aktivierung durch einen Nutzer gestartet. Im Schritt 200 sendet der Client eine Anfrage (vorbestimmte URL-Adresse) an den
Server, mit der der Start der Femdiagnose angefordert wird. In Schritt 201 wird der Empfang einer Aktivierungsseite überprüft. Wird z.B. innerhalb einer festgesetzten Zeit eine Seite empfangen, folgt Schritt 202. Wird keine Anfrage empfangen, wird die Kommunikation erfolglos abgebrochen / beendet (Schritt 204). Im Schritt 202 sendet der Client eine Anfrage nach einer Login-Seite an den Server (URL-Adresse). Daraufhin wird in Schritt 205 der Empfang einer entsprechenden Seite überprüft. Wird z.B. innerhalb einer festgesetzten Zeit eine Seite empfangen, folgt Schritt 206. Wird keine Seite empfangen, wird die Kommunikation abgebrochen / beendet (Schritt 204). Im Schritt 206 sendet der Client eine Anfrage nach einem Login-Skript. Daraufhin wird in Schritt 207 der Empfang des Skripts überprüft. Wird z.B. innerhalb einer festgesetzten Zeit das Skript empfangen, folgt Schritt 208. Wird kein Skript empfangen, wird die
Kommunikation abgebrochen / beendet (Schritt 204). In Schritt 208 werden die Nutzeridentifikationsdaten aus einem Speicher (Einsatz EFI-Schnittstelle) geholt und an den Server gesendet sowie eine Folgeseite angefragt. Daraufhin wird in Schritt 210 der Empfang einer Folgeseite samt Loginbestätigung und Skriptverweis überprüft. Wird z.B. innerhalb einer festgesetzten Zeit eine Folgeseite mit den entsprechenden Angaben empfangen, folgt Schritt 211. Wird keine Seite oder keine Bestätigung empfangen, wird die Kommunikation abgebrochen / beendet (Schritt 204). Im Schritt 211 wird eine Anfrage für ein Fahrzeugidentifikationsskript gesendet. Daraufhin wird in Schritt 212 der Empfang eines Skripts überprüft. Wird z.B. innerhalb einer festgesetzten Zeit eine Skript empfangen, folgt Schritt 213. Wird kein Skript empfangen, wird die Kommunikation erfolglos abgebrochen / beendet (Schritt 204). Im Schritt 213 werden die Fahrzeugidentifikationsdaten ermittelt (z.B. aus einem Speicher im Endgerät oder durch Anfrage bei den zu diagnostizierenden Steuergeräten / Komponenten (Einsatz EFI- Schnittstelle) und eine Anfrage nach einer Folgeseite samt Identifikationsdaten gesendet. Daraufhin wird in Schritt 214 der Empfang einer Diagnoseseite samt Verweis auf das
Skript überprüft. Wird z.B. innerhalb einer festgesetzten Zeit eine Seite empfangen, folgt Schritt 215. Werden keine Daten empfangen, wird die Kommunikation erfolglos abgebrochen / beendet (Schritt 204). Im Schritt 215 erfolgt die Anfrage nach einem Diagnoseskript. Daraufhin wird in Schritt 216 der Empfang eines Diagnoseskripts überprüft. Wird z.B. innerhalb einer festgesetzten Zeit eine Anfrage empfangen, folgt
Schritt 217. Wird kein WML-Skript empfangen, wird die Kommunikation abgebrochen / beendet (Schritt 204). Im Schritt 217 werden durch entsprechende Kommunikation mit den zu diagnostizierenden Steuergeräten die Diagnosedaten ermittelt (Einsatz EFI- Schnittstelle) und mit einer Anfrage nach einer Folgeseite gesendet. Daraufhin wird in Schritt 218 der Empfang einer Ergebnisseite überprüft. Wird z.B. innerhalb einer festgesetzten Zeit eine Anfrage samt Daten empfangen, folgt Schritt 219. Wird keine Antwortseite empfangen, wird die Kommunikation erfolglos abgebrochen / beendet (Schritt 204). Im Schritt 219 wird auf der Basis des Ergebnisses ermittelt, ob einer Empfehlungsseite angefordert werden soll. Wenn nein, wird der Vorgang beendet (Schritt 204), wenn ja erfolgt das Senden einer entsprechenden Anfrage (Schritt 220). Daraufhin wird in Schritt 222 der Empfang einer Empfehlungsseite überprüft. Wird z.B. innerhalb einer festgesetzten Zeit eine Seite empfangen, folgt Schritt 223. Wird keine Seite empfangen, wird die Kommunikation abgebrochen / beendet (Schritt 204). Im Schritt 223 wird die Empfehlungsseite angezeigt und die Kommunikation und damit den Femdiagnosevorgang gemäß Schritt 204 beendet. Zwischendurch erfolgt gewöhnlich auch die Anzeige der erhaltenen Seiten (enthält vom
Server generierte Status-Infos).

Claims

Patentansprüche
1. Verfahren zur Übertragung von Informationen in Verbindung mit einem Fahrzeug, wobei fahrzeugseitig ein Client, netzwerkseitig ein Server vorgesehen ist, wobei zwischen Server und Client und/oder umgekehrt eine Kommunikation über ein Mobilfunknetz erfolgt, dadurch gekennzeichnet, dass die Informationen zur Realisierung einer fahrzeugbezogenen Femkontrolle dienen und die Kommunikation auf der Basis eines standardisierten, an die Gegebenheiten des Mobilfunknetzes angepassten Protokolls, vorzugsweise des WAP-Protokolls, erfolgt.
2. Verfahren zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug wobei fahrzeugseitig ein Client vorgesehen ist, der über ein Mobilfunknetz mit einem Server kommuniziert, dadurch gekennzeichnet, dass die Informationen zur Realisierung einer fahrzeugbezogenen Femkontrolle dienen, dass mittels gesendeter Anfragen Informationen, insbesondere Befehle, abgerufen und empfangen werden, abhängig von den Informationen Daten ermittelt werden und an den Server übermittelt werden.
3. Verfahren zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug wobei netzwerkseitig ein Server vorgesehen ist, der über ein Mobilfunknetz mit einem fahrzeugseitigen Client kommuniziert, dadurch gekennzeichnet, dass die Informationen zur Realisierung einer fahrzeugbezogenen Femkontrolle dienen, dass die Informationen auf der Basis einer empfangenen Anfrage ausgewählt und gesendet werden, dass femer Daten empfangen werden, verarbeitet und die Ergebnisse zurückgesendet werden.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die gesendeten Anfragen auf der Verwendung von URL-Adressen basieren.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Informationen WAP-Seiten sind, die als WML-Seite übermittelt werden und die Verweise auf Skripte und/oder weitere, evtl. dynamisch generierte Daten enthalten.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Informationen Skripte sind, die als WML-Skripte übermittelt werden und die zur Ausführung bestimmter Aktionen im fahrzeugseitigen Client dienen.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zur Femdiagnose die Skripte das ggf. fahrzeugspezifische Diagnoseprotokoll oder sonstige fahrzeugspezifische Informationen enthalten.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die die Kommunikation mit wenigstens einer eigenständigen, externen Applikation, die im mobilen Client implementiert ist, über ein standardisiertes Funktions-Interface zwischen dem Mobilfunkkommunikationsteil und der Applikation, die EFI- Schnittstelle, erfolgt.
9. Vorrichtung zur Übertragung von Informationen in Verbindung mit einem Fahrzeug, mit einem fahrzeugseitigen Client und einem netzwerkseitigen Server, die über ein
Mobilfunknetz miteinander kommunizieren, dadurch gekennzeichnet, dass die Informationen zur Realisierung einer fahrzeugbezogenen Femkontrolle dienen und Server und Client Mittel umfassen, welche die Kommunikation auf der Basis eines standardisierten, an die Gegebenheiten des Mobilfunknetzes angepassten Protokolls, vorzugsweise des WAP-Protokolls, durchführen.
10. Vorrichtung zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug, mit einem fahrzeugseitigen Client, der über ein Mobilfunknetz mit einem Server kommuniziert, dadurch gekennzeichnet, dass die Informationen zur Realisierung einer fahrzeugbezogenen Femkontrolle dienen, dass der Client Module umfasst, die mittels gesendeter Anfragen Informationen, insbesondere Befehle, abrufen und empfangen, dass der Client femer Mittel umfasst, die abhängig von den Informationen Daten ermitteln und senden.
11. Vorrichtung nach Anspruch 10, dadurch gekennzeichnet, dass im Client wenigstens eine eigenständige, externe Applikation implementiert ist und ein standardisiertes
Funktions-Interface zwischen dem Mobilfunkkommunikationsteil und der Applikation, die EFI-Schnittstelle, vorhanden ist, über die mit der Applikation kommuniziert wird.
12. Vorrichtung zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug, mit einem netzwerkseitigen Server, der über eine Mobilfunknetz mit einem fahrzeugseitigen Client kommuniziert, dadurch gekennzeichnet, dass die Informationen zur Realisierung einer fahrzeugbezogenen Femkontrolle dienen, dass der Server Mittel umfasst, die die Informationen auf der Basis einer empfangenen Anfrage auswählen und zurücksenden, dass der Server femer Mittel umfasst, die
Daten empfangen, verarbeiten und die Ergebnisse zurücksenden.
13. Computerprogramm mit Programmcode-Mitteln, um alle Schritte von jedem beliebigen der Ansprüche 1 bis 8 durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.
14. Compute rogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um das Verfahren nach jedem beliebigen der Ansprüche 1 bis 8 durchzuführen, wenn das Programmprodukt auf einem Computer ausgeführt wird
PCT/DE2003/001625 2002-06-10 2003-05-20 Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug WO2003105434A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP03756942A EP1518383B1 (de) 2002-06-10 2003-05-20 Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug
US10/514,023 US20050154500A1 (en) 2002-06-10 2003-05-20 Method and device for emitting and/or receiving information relating to a vehicle
JP2004512373A JP2005529424A (ja) 2002-06-10 2003-05-20 車両に関連する情報を伝送する方法および装置、車両に関連する情報を送受信する方法および装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10225786.8 2002-06-10
DE10225786A DE10225786A1 (de) 2002-06-10 2002-06-10 Verfahren und Vorrichtung zur Übertragung, zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug

Publications (1)

Publication Number Publication Date
WO2003105434A1 true WO2003105434A1 (de) 2003-12-18

Family

ID=29718944

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2003/001625 WO2003105434A1 (de) 2002-06-10 2003-05-20 Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug

Country Status (5)

Country Link
US (1) US20050154500A1 (de)
EP (1) EP1518383B1 (de)
JP (1) JP2005529424A (de)
DE (1) DE10225786A1 (de)
WO (1) WO2003105434A1 (de)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004106883A1 (en) * 2003-05-28 2004-12-09 Wherenet Corp Vehicle tag used for transmitting vehicle telemetry data, system and method for transmitting vehicle telemetry data
EP1560143A2 (de) * 2004-01-28 2005-08-03 Luigi Cassi Telemetriesystem für eine Fahrzeugflotte
EP1798620A1 (de) * 2005-12-15 2007-06-20 Siemens Aktiengesellschaft System und Verfahren zur Fernanalyse, Fernwartung und/oder Fehlerbehebung eines technischen Gerätes
US20080187292A1 (en) * 2005-01-19 2008-08-07 Nxp B.V. Device for and Method of Providing Operating Data and/or Data Associated with Playback Data to a Remote Device
CN102833318A (zh) * 2012-07-31 2012-12-19 北京世纪联成科技有限公司 一种车载服务的数据解析处理方法
US10703309B2 (en) 2013-02-08 2020-07-07 Bayerische Motoren Werke Aktiengesellschaft Method and device for connecting a diagnostic unit to a control unit in a motor vehicle
US10963825B2 (en) 2013-09-23 2021-03-30 Farmobile, Llc Farming data collection and exchange system
CN113689592A (zh) * 2021-08-31 2021-11-23 重庆长安汽车股份有限公司 一种基于wifi网络的近程文件传输方法及系统

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100523228B1 (ko) * 2001-05-08 2005-10-20 히다치 겡키 가부시키 가이샤 작업기계, 작업기계의 고장진단시스템, 작업기계의메인티넌스시스템
WO2003105094A1 (de) * 2002-06-10 2003-12-18 Robert Boshc Gmbh Verfahren und vorrichtung für einen fahrzeugbezogenen telematikdienst
US20040049325A1 (en) * 2002-09-06 2004-03-11 Omega Patents, L.L.C. Vehicle control system with selectable vehicle style image and associated methods
JP3849675B2 (ja) * 2003-07-25 2006-11-22 トヨタ自動車株式会社 車両診断方法、車両診断システム、車両およびセンター
DE10348255A1 (de) * 2003-10-16 2005-05-12 Bosch Gmbh Robert Verfahren und Vorrichtung zur Umstellung eines ersten Modus einer Steuereinrichtung in einen zweiten Modus über einen Daten-Bus
US7584029B2 (en) * 2003-12-31 2009-09-01 Teradyne, Inc. Telematics-based vehicle data acquisition architecture
US8195428B2 (en) * 2004-02-25 2012-06-05 General Motors Llc Method and system for providing automated vehicle diagnostic function utilizing a telematics unit
US20060271255A1 (en) * 2004-12-30 2006-11-30 Teradyne, Inc. System and method for vehicle diagnostics and prognostics
US7359774B2 (en) * 2005-02-09 2008-04-15 General Motors Corproation Telematic service system and method
JP2006295715A (ja) * 2005-04-13 2006-10-26 Toyota Motor Corp 車両遠隔操作装置及びシステム
US20070043489A1 (en) * 2005-08-19 2007-02-22 Alrabady Ansaf I System and method for controlling access to mobile devices
SE532087C2 (sv) * 2005-08-25 2009-10-20 Scania Cv Ab Sändande av data från ett fordonsupportcenter till ett fordon
DE102005048337B4 (de) 2005-10-10 2022-12-15 Robert Bosch Gmbh Verfahren zur Erhaltung und Anpassung von Betriebsfunktionen eines Kraftfahrzeugs
US7920944B2 (en) * 2005-10-21 2011-04-05 General Motors Llc Vehicle diagnostic test and reporting method
DE102006039690A1 (de) 2006-08-24 2008-02-28 Bayerische Motoren Werke Ag Fahrzeugdaten-Erfassungssystem
US8645017B2 (en) * 2008-05-07 2014-02-04 Bosch Automotive Service Solutions Llc Dynamic discovery of vehicle communication interface device and method
US8856134B2 (en) * 2008-05-09 2014-10-07 The Boeing Company Aircraft maintenance data retrieval for portable devices
US8661032B2 (en) * 2008-08-28 2014-02-25 Autodata Solutions Company Vocabulary engine
JP5633262B2 (ja) * 2010-01-07 2014-12-03 株式会社デンソー 車両用情報記憶装置、車両診断システム、プログラム
EP2362316A1 (de) * 2010-02-22 2011-08-31 EchoStar Global B.V. Surveillance et contrôle du fonctionnement de dispositifs dans un réseau distribué de dispositifs de diffusion
SE535369C2 (sv) * 2010-11-29 2012-07-10 Scania Cv Ab Fjärrdiagnostisering av fordon
DE102011076638A1 (de) * 2011-05-27 2012-11-29 Stephan Kaufmann Verfahren zur Fahrzeugkommunikation über ein fahrzeugimplementiertes Fahrzeugdiagnosesystem, Schnittstellenmodul sowie Fahrzeugdiagnose-Schnittstelle und Diagnose- und Steuerungsnetz für eine Vielzahl von Fahrzeugen
US9699587B2 (en) 2013-03-01 2017-07-04 General Motors Llc Provisioning automotive SIM cards without removal from vehicle
JP6111757B2 (ja) * 2013-03-14 2017-04-12 株式会社リコー 通信システム、通信端末、および端末プログラム
FR3021147B1 (fr) * 2014-05-16 2017-12-22 Thales Sa Dispositif de controle des donnees portees par un equipement embarque, systeme de collecte de taxe et procede associes
US10176067B1 (en) * 2014-05-29 2019-01-08 Amazon Technologies, Inc. On-demand diagnostics in a virtual environment
TWI569995B (zh) * 2014-05-30 2017-02-11 Icm Inc Information gateway and its interference with vehicle operation
US9628565B2 (en) 2014-07-23 2017-04-18 Here Global B.V. Highly assisted driving platform
US9056616B1 (en) * 2014-09-23 2015-06-16 State Farm Mutual Automobile Insurance Student driver feedback system allowing entry of tagged events by instructors during driving tests
US9373203B1 (en) 2014-09-23 2016-06-21 State Farm Mutual Automobile Insurance Company Real-time driver monitoring and feedback reporting system
FR3034910B1 (fr) * 2015-04-10 2018-04-27 Psa Automobiles Sa. Procede de realisation d’actions a distance dans des equipements electroniques communicants de vehicules, et dispositif de communication associe
US10373523B1 (en) 2015-04-29 2019-08-06 State Farm Mutual Automobile Insurance Company Driver organization and management for driver's education
US9586591B1 (en) 2015-05-04 2017-03-07 State Farm Mutual Automobile Insurance Company Real-time driver observation and progress monitoring
DE102015209515A1 (de) * 2015-05-22 2016-11-24 Robert Bosch Gmbh Vorrichtung zum drahtlosen Senden und/oder Empfangen von Signalen
CN105717814A (zh) * 2016-03-18 2016-06-29 浙江吉利控股集团有限公司 车辆远程控制系统及其控制方法
DE102016108997A1 (de) * 2016-05-17 2017-11-23 Knorr-Bremse Systeme für Schienenfahrzeuge GmbH Vorrichtung zum Auslesen von Daten aus einem sicherheitskritischen Steuergerät
CN107612954A (zh) * 2016-07-12 2018-01-19 鸿富锦精密电子(天津)有限公司 控制终端、移动设备、移动设备控制系统及方法
DE102016221056A1 (de) * 2016-10-26 2018-04-26 Robert Bosch Gmbh Vorrichtung, Fortbewegungsmittel und Verfahren zur Mobilkommunikation eines Fortbewegungsmittels
CN108513635B (zh) * 2018-03-30 2021-08-10 深圳市元征软件开发有限公司 车辆检测方法、用户设备、服务器及车辆检测系统
DE102018215636A1 (de) * 2018-09-13 2020-03-19 Volkswagen Aktiengesellschaft Verfahren, Computerprogramme und Vorrichtungen für eine Netzwerkkomponente und für ein Endgerät, Netzwerkkomponente, Endgerät, System
JP6837508B2 (ja) 2019-03-26 2021-03-03 本田技研工業株式会社 車両制御システム
CN114253251A (zh) * 2022-01-20 2022-03-29 深圳市元征科技股份有限公司 车辆远程诊断方法、装置、设备连接器及存储介质

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
EP0918423A2 (de) * 1997-10-15 1999-05-26 Nokia Mobile Phones Ltd. Mobiles Telefon für Internet-Anwendungen
DE10001130A1 (de) * 1999-01-15 2000-07-27 Cummins Engine Co Inc System und Verfahren zur Übertragung von Anwendungssoftware zu einem eingebauten Fahrzeugcomputer
EP1058220A1 (de) * 1999-06-04 2000-12-06 DaimlerChrysler AG Kommunikationssystem für ein Fahrzeug
US6181994B1 (en) * 1999-04-07 2001-01-30 International Business Machines Corporation Method and system for vehicle initiated delivery of advanced diagnostics based on the determined need by vehicle
WO2001035373A1 (en) * 1999-11-11 2001-05-17 Volvo Lastvagnar Ab System and method for communication between vehicles and a supervisor station
DE10113232A1 (de) * 2000-03-30 2001-10-11 Tenovis Gmbh & Co Kg Fernsteuerungssystem und Verfahren zur Steuerung und/oder Nutzung von Leistungsmerkmalsdaten des Fernsteuerungssytems
WO2001081107A1 (de) * 2000-04-20 2001-11-01 Webasto Thermosysteme International Gmbh Verfahren zum ansteuern einer fahrzeugzusatzeinrichtung sowie fernsteuerbare fahrzeugzusatzeinrichtung
DE10026754A1 (de) 2000-05-30 2001-12-13 Bosch Gmbh Robert Vorrichtung zur Steuerung einer Funktion in einem Kraftfahrzeug
US20010055165A1 (en) * 2000-04-21 2001-12-27 Mccarthy Kevin C. Vehicle mirror assembly communicating wirelessly with vehicle accessories and occupants

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6505248B1 (en) * 1999-03-24 2003-01-07 Gte Data Services Incorporated Method and system for monitoring and dynamically reporting a status of a remote server
JP2003509918A (ja) * 1999-09-02 2003-03-11 ノキア モービル フォーンズ リミテッド サーバからの位置決め情報にアクセスするための無線通信端末
US7844687B1 (en) * 1999-10-06 2010-11-30 Gelvin David C Method for internetworked hybrid wireless integrated network sensors (WINS)
US6370455B1 (en) * 2000-09-05 2002-04-09 Hunter Engineering Company Method and apparatus for networked wheel alignment communications and service
US7600014B2 (en) * 2000-11-16 2009-10-06 Symantec Corporation Method and system for monitoring the performance of a distributed application
EP1241857A1 (de) * 2001-03-15 2002-09-18 Nokia Corporation Verfahren zum Zugreifen auf Datei gespeichtern in einem Mobielendgerät mit Internet Protokol Unterstützung
US20020186845A1 (en) * 2001-06-11 2002-12-12 Santanu Dutta Method and apparatus for remotely disabling and enabling access to secure transaction functions of a mobile terminal
US7039622B2 (en) * 2001-09-12 2006-05-02 Sas Institute Inc. Computer-implemented knowledge repository interface system and method
US20030126271A1 (en) * 2001-12-27 2003-07-03 Mowry Kevin Curtis Method and apparatus for enabling an external function from a WAP environment
US6918055B2 (en) * 2002-03-26 2005-07-12 Sun Microsystems, Inc. Service operations on a computer system
US7689334B2 (en) * 2006-09-28 2010-03-30 Perkins Engines Company Limited Engine diagnostic method
US20100087981A1 (en) * 2008-10-02 2010-04-08 Daniel Guadalupe Orozco-Perez Versatile vehicular care assistant system and method
US8700255B2 (en) * 2008-10-08 2014-04-15 Trimble Navigation Limited Devices, systems, and methods for monitoring driver and vehicle behavior

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
EP0918423A2 (de) * 1997-10-15 1999-05-26 Nokia Mobile Phones Ltd. Mobiles Telefon für Internet-Anwendungen
DE10001130A1 (de) * 1999-01-15 2000-07-27 Cummins Engine Co Inc System und Verfahren zur Übertragung von Anwendungssoftware zu einem eingebauten Fahrzeugcomputer
US6181994B1 (en) * 1999-04-07 2001-01-30 International Business Machines Corporation Method and system for vehicle initiated delivery of advanced diagnostics based on the determined need by vehicle
EP1058220A1 (de) * 1999-06-04 2000-12-06 DaimlerChrysler AG Kommunikationssystem für ein Fahrzeug
WO2001035373A1 (en) * 1999-11-11 2001-05-17 Volvo Lastvagnar Ab System and method for communication between vehicles and a supervisor station
DE10113232A1 (de) * 2000-03-30 2001-10-11 Tenovis Gmbh & Co Kg Fernsteuerungssystem und Verfahren zur Steuerung und/oder Nutzung von Leistungsmerkmalsdaten des Fernsteuerungssytems
WO2001081107A1 (de) * 2000-04-20 2001-11-01 Webasto Thermosysteme International Gmbh Verfahren zum ansteuern einer fahrzeugzusatzeinrichtung sowie fernsteuerbare fahrzeugzusatzeinrichtung
US20010055165A1 (en) * 2000-04-21 2001-12-27 Mccarthy Kevin C. Vehicle mirror assembly communicating wirelessly with vehicle accessories and occupants
DE10026754A1 (de) 2000-05-30 2001-12-13 Bosch Gmbh Robert Vorrichtung zur Steuerung einer Funktion in einem Kraftfahrzeug

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004106883A1 (en) * 2003-05-28 2004-12-09 Wherenet Corp Vehicle tag used for transmitting vehicle telemetry data, system and method for transmitting vehicle telemetry data
EP1560143A2 (de) * 2004-01-28 2005-08-03 Luigi Cassi Telemetriesystem für eine Fahrzeugflotte
EP1560143A3 (de) * 2004-01-28 2007-06-20 Luigi Cassi Telemetriesystem für eine Fahrzeugflotte
US20080187292A1 (en) * 2005-01-19 2008-08-07 Nxp B.V. Device for and Method of Providing Operating Data and/or Data Associated with Playback Data to a Remote Device
US9183489B2 (en) * 2005-01-19 2015-11-10 Nxp B.V. Device for and method of providing operating data and/or data associated with playback data to a remote device
EP1798620A1 (de) * 2005-12-15 2007-06-20 Siemens Aktiengesellschaft System und Verfahren zur Fernanalyse, Fernwartung und/oder Fehlerbehebung eines technischen Gerätes
CN102833318A (zh) * 2012-07-31 2012-12-19 北京世纪联成科技有限公司 一种车载服务的数据解析处理方法
US10703309B2 (en) 2013-02-08 2020-07-07 Bayerische Motoren Werke Aktiengesellschaft Method and device for connecting a diagnostic unit to a control unit in a motor vehicle
US10963825B2 (en) 2013-09-23 2021-03-30 Farmobile, Llc Farming data collection and exchange system
US11107017B2 (en) 2013-09-23 2021-08-31 Farmobile, Llc Farming data collection and exchange system
US11126937B2 (en) 2013-09-23 2021-09-21 Farmobile, Llc Farming data collection and exchange system
US11151485B2 (en) 2013-09-23 2021-10-19 Farmobile, Llc Farming data collection and exchange system
US11164116B2 (en) 2013-09-23 2021-11-02 Farmobile, Llc Farming data collection and exchange system
US11361260B2 (en) 2013-09-23 2022-06-14 Farmobile, Llc Farming data collection and exchange system
US11361261B2 (en) 2013-09-23 2022-06-14 Farmobile, Llc Farming data collection and exchange system
US11410094B2 (en) 2013-09-23 2022-08-09 Farmobile, Llc Farming data collection and exchange system
US11507899B2 (en) 2013-09-23 2022-11-22 Farmobile, Llc Farming data collection and exchange system
US11941554B2 (en) 2013-09-23 2024-03-26 AGI Suretrack LLC Farming data collection and exchange system
CN113689592A (zh) * 2021-08-31 2021-11-23 重庆长安汽车股份有限公司 一种基于wifi网络的近程文件传输方法及系统

Also Published As

Publication number Publication date
JP2005529424A (ja) 2005-09-29
DE10225786A1 (de) 2004-01-08
EP1518383A1 (de) 2005-03-30
US20050154500A1 (en) 2005-07-14
EP1518383B1 (de) 2012-07-25

Similar Documents

Publication Publication Date Title
EP1518383B1 (de) Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug
EP1516291B1 (de) Verfahren und vorrichtung für einen fahrzeugbezogenen telematikdienst
DE69737486T2 (de) Mobiles, tragbares, drahtloses Kommunikationssystem
DE60300432T2 (de) Vorrichtung und Verfahren zur Optimierung des Netzwerkverkehrs
DE69838262T2 (de) Allgemeine benutzer-authentifizierung für netz-rechner
EP1516292B1 (de) Verfahren und vorrichtung für einen fahrzeugbezogenen telematikdienst
DE10026918B4 (de) Virtueller Netzwerkadapter
DE60025195T2 (de) Entfernter datenzugang und steuerungssystem
DE102016218982B3 (de) Verfahren zur Kommunikation von Fahrzeugen
DE10057638A1 (de) Verfahren zur Dokumentation von Daten eines Verkehrsmittels
WO2007098844A1 (de) Kraftfahrzeugdiagnose und fahrzeugannahme
WO2004019209A1 (de) Vorrichtung zum zugriff auf ein fahrzeugssteuersystem über eine drahtlose verbindung
WO2002021350A1 (de) Kurznachrichtendienst bestellwesen
DE112005003597T5 (de) Bedienung eines Mobilgeräts
DE10329871B4 (de) Verfahren und System zur telemetrischen Diagnose elektronischer Einrichtungen eines Fahrzeugs
DE10225787A1 (de) Verfahren und Vorrichtung zur Übertragung, zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug zum Steuern einer Funktion
EP3158465B1 (de) Verfahren, vorrichtung und system zum aufbau und zum betrieb eines drahtlosen netzwerks
WO2003016856A2 (de) Kommunikationsverfahren und kommunikationsmodul
DE10257030A1 (de) Verfahren und Vorrichtung für einen fahrzeugbezogenen Telematikdienst
WO2005104055A2 (de) Verfahren und system zur fernüberwachung, fernsteuerung und/oder ferndiagnose eines gerätes
EP1814763B1 (de) Verfahren und System zur Bereitstellung von internen diagnoserelevanten Informationen in einem Fahrzeug
DE10257788A1 (de) Verfahren zur informativen Unterstützung eines Fahrzeugführers mittels eines Fahrzeug-Multimediasystems
DE10260404A1 (de) System und Verfahren zur Überwachung von technischen Anlagen und Objekten
DE102022001848B3 (de) Verfahren zum nutzerbezogenen Einrichten eines Endgerätes
DE102018006028A1 (de) Verfahren zum Sammeln von Daten eines Fahrzeuges während einer Testfahrt

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003756942

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10514023

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2004512373

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2003756942

Country of ref document: EP