Method and device for a vehicle-related telematics service

State of the art

The invention relates to a method and device for a vehicle-related telematics service, such as the effect on at least one functionality in a vehicle via an air interface, eg a mobile radio network, in particular in connection with the remote diagnostics of motor vehicles.

The increasing networking of control devices in today's motor vehicles offers ever greater possibilities of action on functionalities in the motor vehicle, for example, better diagnoses in the event of a fault or possibilities for remote control of functions and / or components of the vehicle. In this context, concepts with the aid of a mobile radio-assisted effect reliably and securely access the functionality in the vehicle at any distance, for example via remote diagnostics, reliable and high-quality fault analyzes by a service center or a remote diagnosis server Database. According to these approaches, integrated communication systems, such as mobile telephones and / or GSM-based telematics terminals, are used in the vehicle in order to carry out a data transmission between the control devices and / or components connected to a vehicle network and the server of the service center. DE 100 26 754 A1 describes a proposal for such a system. A concrete implementation with regard to the transmission contents between the server and the terminal and with regard to the configuration of the terminal or server are not specified.

DE 100 26 754 A1 (cover of claim 1) shows a radio connection of a motor vehicle for diagnostic purposes as an immobilizer and for activation of vehicle functions from outside. The partitioning of the functionalities remains completely open.

The same applies to US Pat. No. 6,181,994. This shows measures for the remote diagnosis of motor vehicles. The motor vehicle transmits data from which the diagnosis can be carried out to a central device which evaluates this data and transmits the result back to the vehicle. Here too, the concrete partitioning of the functionalities is open.

EP 718 614 A2 also deals with the topic of remote diagnostics. The diagnostic data are evaluated in the vehicle and a prepared fault message is transmitted to a control center.

Advantages of the invention

By dividing the functions, eg diagnostic functions, between the terminal and the server (partitioning of sub-functions), a considerable resource saving is achieved in the vehicle device. It is particularly advantageous that time-critical, vehicle-specific functions with which the influence on the selected functionality is controlled are not held in the vehicle implement, but in the server and are transmitted by the latter via the air interface. This avoids the need for an additional application protocol for the air interface specifically tailored to the application, in particular with regard to the time boundary conditions specified by the vehicle network, so that standard standard protocols for the air interface can be used. In addition, the transmission of vehicle-specific information via the air interface permits a uniform, parameterizable functionality in the terminal as well as a vehicle-independent implementation in the terminal. A particularly high flexibility of the system is achieved, which can also adapt itself to changing equipment of the vehicles.

In the case of remote diagnostics, changes or improvements in the diagnosis itself are possible, provided they do not run onboard in the control units of the vehicle, in the server. This applies in particular to the sequence and scope (transmitted data) of the remote diagnosis process.

Special advantages are achieved in connection with the remote diagnostics when the commands of the vehicle-specific diagnostic protocol are transmitted from the server to the terminal via the air interface.

The resource savings in the vehicle implement, in particular by the outsourcing of time-uncritical operations into the server of the service center, makes it possible to implement the vehicle network in the terminal in a simple and rapid manner.

This results in an overall efficient and, above all, low-cost implementation of a vehicle functionality, in particular for remote diagnostics, remote maintenance, remote control, software download, etc. in motor vehicles.

Further advantages result from the following description of exemplary embodiments and from the dependent patent claims.

drawing

The invention is explained in more detail below with reference to the embodiments shown in the drawing with reference to the remote diagnostics of a motor vehicle.<ul><li>FIG. 1 shows a basic diagram of a remote diagnostic system.</li><li>In FIG. 2, the breakdown of the diagnostic functionality between the vehicle side and the server side of the system is shown as an overview. In particular, this also results in configurations of the vehicle-driving device or of the server of the service center.</li><li>FIG. 3 shows a flow diagram which illustrates the basic sequence of the remote diagnosis, in particular with regard to the transmission between the server and the terminal as well as with regard to the functions of the terminal or the server in a preferred exemplary embodiment.</li><li>FIG. 4 shows the communication between the server and the terminal as well as between the terminal and the control unit to be diagnosed, as well as the operations taking place in the respective units in detail with reference to a preferred exemplary embodiment.</li></ul>

DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 1 shows an overview of a system for a vehicle-related telematics service, wherein information is exchanged between a vehicle (there terminal) and a server via a mobile radio network or via a data network, such as, for example, the Internet. Such a configuration is used in conjunction with functions for remote control, remote diagnostics, remote maintenance, software download, etc. Remote control or remote sensing is essentially understood to mean the remote control of vehicle functions, in particular comfort functions such as switching on the auxiliary heating, etc., as well as the querying of vehicle status and / or operating parameters. In this case, the user initiates a communication with the vehicle via a central server or communicates directly with the vehicle. Remote diagnostics include the remote reading of diagnostic data from the vehicle, its analysis and, if necessary, the creation of a recommendation for further action. Analysis of the data and generation of the recommendation is carried out by a central server which is connected to the vehicle via a mobile radio network, via a wired network and / or via a data network, such as, for example, the Internet with the motor vehicle. Furthermore, in this connection, the so-called software download or remote flashing, with the aid of which a new program code or parameter can be applied to software-configurable systems in the vehicle, for example control units, in order to increase the functionalities or the performance increase. Here, too, communication takes place via a mobile radio network, a wired network and / or, for example, the Internet from a central computer (server) or service center. Remote maintenance essentially represents the monitoring of the vehicle condition and the access to the maintenance data in the vehicle from a central location in order to check whether, when and which measures are taken to maintain the desired condition. One example of this is the dynamic adjustment of maintenance intervals. In general, these functionalities are subsumed under the concept of vehicle-related telematics services.

1 shows a part 1 on the vehicle side as well as a part 2 on the server side. Both parts are connected to each other via a communication network 3, in particular an air interface, for example via a mobile radio network. The part on the vehicle side consists of a terminal 4, for example a telematics terminal, which is connected to the vehicle electronics unit 6 via a further interface 5. The server-side part 2 consists of a server 7, which is operated, for example, by a service center, the vehicle manufacturer or a supplier, and which is connected via an interface 8 to a data store 9, in which, for example, vehicle-related data, / Or commands and / or programs. As described in detail below, sub-functions are partitioned in the client-server system shown, ie certain functionalities of a telematics service are assigned to the server and the client. In this case, a complete networking of the control devices to be diagnosed or controlled in the vehicle with the terminal, for example, by means of a CAN bus, as well as the availability of the interface 3, in particular a mobile radio interface in the motor vehicle, is assumed. The known, different methods for the detection of diagnostic data, for example via a CAN-bus interface, can be divided into non-time-critical and time-critical applications. The non-time-critical applications include, for example, the sequence control of the diagnostic tester, with access to a database, as well as the diagnosis protocol itself, for example the protocol KWP2000 or variants thereof. Time-critical applications are the transport protocol of the vehicle network (eg, CAN transport protocol), or variants thereof, its communication layer (eg CAN communication layer) and the bus (eg CAN bus) itself. It is essential that during the implementation of the telematics function in the The time-critical processes are decoupled from the more uncertain mobile radio channel. Therefore, all or some of the relevant functions are outsourced from the vehicle which are not subject to tight time requirements, in particular requirements regarding a minimum or maximum duration between command and response during data transmission. In the extreme case, therefore, only the time-critical data transport on the vehicle bus (eg CAN bus or the like), which is implemented by functions of the transport protocol such as, for example, the fragmentation and defragmentation of complex messages, remains on the client or vehicle side. The functionality of the usually more complex and vehicle-specific service protocol (eg diagnostic protocol) is then transferred to a corresponding server (eg diagnostics server). In addition to the transmission of vehicle-specific diagnostic commands on the basis of the diagnostics protocol used in each case, additional information is transferred between the server application (sequence control for the overall process) and the client application (sequence control for data acquisition) in the application of the remote diagnostics. These sequencers are used to activate the diagnostic process, the configuration of the client application, and the subsequent transmission of results from the server-side data analysis. In the illustrated example, in which all time-uncritical processes were transferred from the vehicle-side part into the server-side part of the system, the system architecture shown in FIG. 2 results. In other embodiments, only a portion of the non-critical processes are stored while a portion remains in the vehicle-side terminal. For example, it is conceivable that vehicle-specific data and / or special vehicle-specific diagnostic commands, which are not outsourced for safety reasons, remain in the vehicle-side part of the system.

In connection with other telematics services such as the remote control of components, the software download, etc., time-critical applications are outsourced in the manner described, while time-critical applications remain in the vehicle implement.

FIG. 2 shows the vehicle driver unit (client) 4 as well as the server 7, which are connected to one another via an air interface 3. In the preferred exemplary embodiment, the air interface 3 is a conventional mobile radio network, for example based on the GSM standard. Other applications are mobile networks that work with other standards. The server comprises the following modules: a mobile radio communication protocol module 7a, a mobile communication module 7b, a sequence control module 7c as well as a vehicle-specific diagnostic protocol module 7d. The vehicle device also comprises a communication protocol module 4a, a module 4b for communication via the mobile radio interface, a module 4c for CAN communication, and a transport protocol module 4d. Furthermore, an exhaust control 4e is provided in the vehicle equipment. The modules preferably represent software programs.

These functional units have the following functions:

The mobile radio communication modules 4b, 7b, which are provided both in the terminal and in the server, are used for stable data transmission, for establishing the connection, for data security, possibly for encryption, packetization, etc. These tasks are realized by conventional communication function units and Are available, for example, within the framework of the GSM standards. The CAN communication module 4c provided in the vehicle device is a hardware-independent software interface for transmitting data via a CAN bus to connected control devices. This includes the initialization and control of the CAN controller, the transmission and reception of CAN modules as well as overflow Error handling and wake-up functions. The module also includes the functions of OSI layers 1 and 2 (Physical Layer, Data Link Layer). The software module works within the scope of the valid CAN specification. In other embodiments, a different bus system is used instead of the CAN bus (standardized or customer-specific), whereby the software module is then implemented on the basis of a corresponding specification.

The sequence control 7c in the server decomposes the basic diagnostic functions into individual subprocesses or diagnostic services, assumes the initialization of the process, controls and terminates the diagnostic process, processes the necessary parameter and possibly protocol mechanisms for the diagnostic process, and controls the overall process in time. Furthermore, the diagnosis data determined are evaluated here, if necessary, a recommendation is carried out. In addition, the sequence control accesses the server's diagnostic database. The sequence control is a software module designed for the specific application. An example is outlined below with reference to the remote diagnostics in FIGS. 3 and 4.

A sequence control module 4e is provided in a corresponding manner in the vehicle equipment. This software module is also designed for the special application. An example is outlined below with reference to the remote diagnostics in FIGS. 3 and 4. This sequence control generates a server request for performing a remote diagnosis. It configures the functions in the vehicle, for example, by setting a tester-present message, setting the timing parameters for the transport protocol and, if necessary, setting the parameters for the CAN communication. The sequence control also performs the diagnostic communication by cyclically generating tester-present messages with the control units to be diagnosed. It also converts the diagnostic commands transferred from the server to the CAN transport protocol. In addition, the flow chart transfers the data to the server and, for this purpose, converts the diagnostic data determined in the vehicle to the mobile radio interface. In addition, measures are taken in which, in one exemplary embodiment, the evaluated results of the error analysis which are transmitted by the server are displayed. Furthermore, the sequence control assumes the termination of the diagnostic communication by stopping the generation of tester-present messages. In an exemplary embodiment, the automatic termination of an interrupted diagnostic process, for example by timeout or watchdog for receiving server commands, is also carried out.

The transport protocol module 4d provided in the client 4 performs the transmission of complex messages or data units via a CAN bus, assumes the decoupling of the diagnostic protocol from the physical transmission medium, and provides the services of the OSI layer 3 (network layer) , As well as the connection between the OSI layer 2 (data link layer) and 7 (application layer). The segmentation and acquisition of data from the data link layer, ie the control of the data flow of individual messages, including administration and assignment of physical CAN messages to logical messages or data units, as well as fault detection, are carried out as a transport protocol module. One implementation is the widely-used ISO transport protocol (ISO 15765-2), whereby in other applications also special variants of this protocol are used. This also applies to the use of other bus systems for communicating with the vehicle control devices.

The diagnosis protocol module 7d associated with the server comprises the diagnostic layer, which in a preferred application contains the diagnostic protocol KWP2000 specified according to ISO, whereby variants of this are also used, depending on the exemplary embodiment. In this diagnostic protocol module, special diagnostic services are defined, which are used differently depending on the motor vehicle manufacturer and / or the type of motor vehicle and, in some cases, contain different auxiliary services. The diagnostic protocol module evaluates the diagnostic inquiries. Other tasks solved by the module are the conversion of services into a functional interface for the application layer, the direct use of specific services, and the exception handling of unknown services. An example for the realization of such a module can be gathered from the procedures described below.

The basic procedure in the context of remote diagnostics is that after activation of the remote diagnosis by an operator, eg the user of the motor vehicle, and / or the service provider and / or the vehicle manufacturer and / or a mechanic of a workshop after completion of the connection setup steps Between the terminal and the server, the commands of the vehicle-specific diagnostic protocol are transmitted from the server to the terminal via the air interface. The vehicle-specific diagnostic protocol commands are read from a database by the diagnostic server after identification of the motor vehicle to be diagnosed. The terminal transfers the transmitted diagnostic commands to the vehicle network. This takes place, for example, by the fact that the received commands are implemented in commands for the diagnosing control unit and are sent to the control unit via the interface to the vehicle network, in particular via a CAN bus. The response of this control device is received as a data message from the vehicle network in the corresponding format via the vehicle network interface and is then converted by the terminal into response messages for the server. These are then transmitted to the mobile radio interface, which is sent to the server via an intended transmission protocol (for example within the framework of the GSM standard). In summary, the client in the preferred embodiment thus converts the diagnostic protocol (KWP2000) transferred from the server to the CAN transport protocol and vice versa. The sequence control of the described process for maintaining the diagnostic communication in the vehicle is self-sufficient in the terminal, for example, by means of so-called tester-present messages. These are defined in the KWP2000 specification and serve to meet the time requirements of the vehicle networks. This results in a decoupling of the time-critical diagnostic communication in the vehicle from the time-critical diagnostic sequences in the server. The result is thus a flexible configuration of the vehicle-specific diagnostic communication in the vehicle, which is not affected by possible problems of the air interface and the diagnostic processes in the server.

FIG. 3 shows a flow diagram of the overall process, which is divided into five basic substeps. The detailed sequences within such a partial operation can be varied depending on the type of vehicle, the possibly occurring fault and / or the respective implementation of the system in the diagnosis server. In the first step 100, the diagnosis is started with a corresponding inquiry to the server. In the preferred embodiment, the driver is activated by the driver or user of the motor vehicle, which, by means of a call or the like at the service center, generates a request from the server to the client in the vehicle to establish a diagnostic connection. The client then establishes the requested connection. In other embodiments, the diagnostic link is established by a request from the client. The actual diagnosis connection is established here by the server or the client. In the next step 200, the remote diagnostics functionality is configured in the vehicle by the server. The sequence control, the transport layer and, if appropriate, the CAN communication are adapted to the specific vehicle. This is done by means of commands or data from the server, which is read from a database for the particular vehicle or vehicle type / and / or equipment variant. During activation, the server receives, for example, information about the vehicle to be diagnosed by means of an identification ad code. Using this information, he reads vehicle-specific parameters from the database, which he then transmits to the client for the configuration of the remote diagnostics functionality.

After the substeps Activation (100) and Initialization (200), the substep step of the diagnosis process (301 to 303) is shown on an example of a control device. Initially, the diagnostic mode is initiated by the server in the control unit to be diagnosed, if necessary, so that the control unit is capable of performing the diagnostic function. Furthermore, the control unit is identified, eg its software status, for the adaptation of the diagnostic commands to the special control unit type. This, too, is optional and is used when, for example, this proves to be necessary because of the multiplicity of softstocks. The selected diagnostic commands are then transferred from the server to the client in the vehicle. Examples of such diagnostic commands are the reading out of at least one error memory of the affected control device, the reading out of stored environmental parameters of a detected error and / or the querying of additional actual values ​​from the corresponding control device.

In step 302, the client transfers the transmitted diagnostic command (s) to the vehicle network. In the subsequent step 303, the response of the control device to the transmitted command (s), which must occur, for example, within a certain time period, is received from the client over the transmission interface to the server and sent back to it. Steps 301 to 303 are then repeated for each control unit to be diagnosed or, if the diagnostic commands are sent one by one or in groups one after the other, for each individual diagnostic command or diagnostic command group. If the diagnosis for a control unit is terminated, an end command is sent as a diagnostic command, which, if necessary, deactivates the diagnostic mode in the control unit and returns it to the normal operating mode.

The fourth sub-step relates to the evaluation of the obtained data in the server (step 400). The server evaluates the collected error information according to a possibly specific algorithm, determines a diagnosis result and / or makes recommendations for the further procedure. In the next step 500, the results determined by the server are then transmitted to the terminal and displayed by the latter in the vehicle. This fifth substep thus represents the result output. In this embodiment, the transmission and display of a recommendation for the further procedure in the event of an error is also provided in one exemplary embodiment, eg, "visit a workshop", etc.

FIG. 4 shows an exemplary communication scenario between a remote diagnostic server, a telematics terminal and a control device. The communication scenario stalls an implementation of the third substep in FIG. 3 in detail. The basis of the communication is the diagnostic protocol KWP2000 specified according to ISO 14230-3. In other embodiments, manufacturer-specific variants of this diagnostic protocol or other diagnostic protocols are used accordingly. Depending on the exemplary embodiment, the sequence of the steps and the scope of the steps in the individual applications varies. FIG. 4 shows a preferred realization of the communication between a remote diagnosis server I, a telematics terminal II arranged in the vehicle, and a control device III to be diagnosed. The communication is based on the diagnostic protocol KWP2000, which is specified in ISO 14230-3. In most cases, the error detection and the setting of the error memories are performed by known diagnostic methods in the control unit to be diagnosed by software present there or read there.

FIG. 4 shows the individual elements of a communication between the three units involved, wherein a chronological order is to be expressed from top to bottom. The units have software programs which generate, evaluate, etc. the messages to be transmitted.

After completion of the partial processes 1 and 2 (see FIG. 3, steps 100 and 200), in a first step S1 the diagnostic mode is activated in the control unit to be diagnosed. For this purpose, the server sends a corresponding diagnostic command (start diagnostic session request). This is received by the terminal and relayed via the interface to the diagnosing control unit (step S2) or converted first into a format suitable for the vehicle network (eg by means of a table) and then given to the vehicle network. The control unit to be diagnosed answers with a corresponding response (start diagnostic session response), which indicates whether the diagnostic mode is initiated or not. This information is sent by the control device to be diagnosed to the terminal in step S3, which in turn transmits the information to the server in step S4 (possibly after conversion to the format provided).

A command (tester-present request) is sent to the control device III from the terminal II to the control device III in step S5 for the sequence control and to meet the time request in the vehicle network. This command is answered by a corresponding response (tester-present response) in step S6 . In the following, this communication is carried out during the diagnostic process if no other diagnostic command is to be forwarded from the server or no response from the control unit is to be routed to the server. Therefore, steps S5 and S6 can also be repeated several times until the expected command is received by the server. If one of the above events does not occur, the communication between the terminal and the control unit is interrupted.

After receiving the answer in step S4, the server sends a command (Read ECU Identification Request) in step S7, which requests the identification of the control device to be diagnosed. This command is received by the terminal and possibly implemented, and then transmitted to the control unit in step S8. The control unit then reads out at least one identification parameter from its memory and sends it to the terminal (Read ECU Identification Response, step S9). This information is then transmitted to the server in step S 10, if necessary, after conversion from the terminal II. On the basis of the identification parameter, the server recognizes the control device, possibly its software status, as well as the vehicle, if necessary, and selects corresponding parameters from the database. In the meantime, as described with reference to steps S11 and S12, the tester-present communication described above, which ensures that the communication between the terminal and the control unit is maintained, remains between the terminal and the control unit to be diagnosed, and the control unit remains in the diagnosis mode No violation of the boundary conditions for the communication in the vehicle network leading to termination occurs.

In the next steps, the error memories of the control device to be diagnosed are read out. For this purpose, the server, after receiving the message in step S10 and reading out the controller-specific parameters to the terminal, transmits a corresponding inquiry (Read DTC Request) in step S13. This query contains the controller-specific parameters in which, for example, it is indicated which fault memories are to be read out. This request is transmitted in step S14 from the terminal, possibly after conversion, to the control device. The control unit executes the received commands and sends the error memory contents as a message read DTC response to the terminal in step S 15. The message Read DTC response therefore contains the relevant error memory contents. The response is transferred from the terminal to the server, if necessary, after conversion in step S 16. Then, in the steps S 17 and S 18, the above-mentioned tester-present communication between the terminal and the control unit is carried out until a new message is received from the server.

In the subsequent, optional sub-step, the environmental parameters associated with the error entries are read out. To this end, the server sends after receiving the message in step S16, and after evaluation of the error messages in step S19 to the terminal a request (Read-Freez e Frarne request), which optionally passes this by implementing the step S20 to the control unit . Depending on the execution, the control unit then reads the desired parameters for the stored errors or the server specifies the contents of its message based on the contents of the error memory so that only certain environment parameters are requested with this message. The controller, in any case, responds with a corresponding response (read-freeze frame response), which contains the parameters requested in one way or another. In step S21, the response is sent to the terminal, which in turn transfers the response to the server, if necessary after conversion in step S22. In steps S23 and S24 the tester-present communication is again performed.

In the subsequent substep, after the fault memory and associated environmental parameters are read and transmitted, the diagnostic mode in the control unit is deactivated. For this purpose, the server sends a request to terminate the diagnostic procedure (stop diagnostic session request) to the terminal. This transmits the request to terminate the control device (step S26), which responds with a corresponding response signal (stop diagnostic session response) in step 27, with which the control device communicates the termination of the diagnostic mode. This information is transmitted from the terminal to the server in step S28. Thereupon (step S29), the above-described partial processes 4 and 5 are forwarded with regard to evaluation and display of the diagnostic results and, if appropriate, recommendations.

The communication scenario illustrated is an example. In other embodiments, the steps for activating and deactivating the diagnostic mode in the control device and / or for identifying the control device and / or for reading the associated environmental parameters are missing.

The concrete technical realization of the illustrated communication takes place by corresponding software programs in the server, terminal and control unit, each of which is also part of the present invention.