Method and device for a vehicle-related telematics service

Translation of description of equivalent WO 03105093 A1

p0001Method and apparatus for a vehicle-related telematics service

p0002State of the art

p0003The invention relates to a method and apparatus for a vehicle-related telematics service, such as interacting with at least one functionality in a vehicle over an air interface, such as a mobile radio network, in particular in connection with the remote diagnosis of motor vehicles.

p0004The increasing networking of control devices in motor vehicles today still offers better possibilities for intervening on the functions in the motor vehicle, for example, improved diagnostics in the event of a fault or remote control options of functions and / or components of the vehicle. In this context, there are concepts, by means of a mobile telephones, Einwirkens reliably and securely to the functionality in the vehicle access over any distance, for example via a remote diagnosis reliable and high quality error analysis by a service center or a remote diagnosis server, the appropriate diagnosis database includes conduct. According to these approaches, integrated communication systems such as mobile telephones and / or GSM-based telematics terminals are used to perform a data transfer between connected to a vehicle network control devices and / or components and the server of the service center in the vehicle. A proposal for such a system is described in DE 100 26 754 AI. A concrete realization with respect to the transfer content between the server and terminal and with regard to the configuration of the terminal or server are not specified.

p0005ADVANTAGES OF THE INVENTION By dividing the functions, such as diagnostics, between terminal and server (partitioning of partial functions) a significant Ressourcenerspamis is achieved in the vehicle terminal. It is particularly advantageous that uncritical, vehicle-specific functions with which the action is controlled on the selected functionality, are not kept in the vehicle terminal, but in the server and are transmitted from there via the air interface. This avoids that an additional, specially tailored to the application in particular in terms specified by the vehicle network timing constraints application protocol for the air interface is required, it may be that resorting to usual standard protocols for the air interface. In addition allows the transmission of vehicle-specific information on the air interface a single, parameterized 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 be adapted to changing equipment of vehicles.

p0006When remote diagnostics are changes or improvements in relation to the diagnosis itself, provided these do not occur in the onboard control units of the vehicle, the server possible. This concerns above all the progress and extent (transmitted data) of the remote diagnostic session.

p0007Particular advantages are achieved in conjunction with the remote diagnosis if the commands of the vehicle-specific diagnostic protocol over the air interface from the server are transferred to the terminal.

p0008By saving resources in the vehicle terminal, in particular by outsourcing non-time operations in the server of the service center an easy and quick reaction to the vehicle network in the terminal is possible.

p0009Thus, the overall result is an efficient and implementable especially with little effort Procedure for acting on a vehicle functionality, especially for remote diagnostics, Femwartung, remote control, software download, etc. in motor vehicles. Further advantages result from the following description of exemplary embodiments and from the dependent claims.

p0010drawing

p0011The invention is illustrated below with reference to the drawing

p0012Embodiments using the remote diagnosis of a motor vehicle described in detail.

p0013Figure 1 shows a schematic diagram of a remote diagnostic system.

p0014In Figure 2 is shown as an overview representation, the division of diagnostic functionality between vehicle-and serversei TIGEM part of the system. In particular, this results also embodiments of the vehicle terminal or the server of the

p0015Service center.

p0016Figure 3 shows a flow diagram illustrating the basic sequence of remote diagnosis, in particular in view of the transmission between the server and terminal and in

p0017With regard to the functions of the terminal or the server in a preferred

p0018is exemplary.

p0019Figure 4 shows the communication between server and terminal and between

p0020Terminal to be diagnosed and control unit as well as the processes occurring in the respective units processes in detail based on a preferred embodiment.

p0021Description of embodiments

p0022Figure 1 shows an overview diagram of a system for a vehicle-related telematics service, said information between a vehicle (there terminal) and a server via a mobile phone network or via a data network such as the Internet exchanged. Such a configuration is used in conjunction with functions for remote operation, diagnostics, remote monitoring, software download, etc.. Remote action or remote the Femsteuerung of vehicle functions, in particular comfort functions such as turning on the heater, etc., and querying vehicle statuses and / or operating parameters is understood essentially. Here, the user initiates a communication with the vehicle via a central server or to communicate directly with the vehicle. Femdiagnose including the remote reading of diagnostic data from the vehicle, their analysis and possibly generating a recommendation for further action. Analysis of the data and generation of the recommendation is carried out by a central server connected to the vehicle via a mobile radio network, via a wired network and / or via a data network such as the internet in the car is connected. It should also be mentioned in this context as a function of the so-called software download or the remote Flashing, by which a new program code or parameters on software-configurable systems in the vehicle, for example, control units, applied to the functionality or performance to increase. Again, the communication over a cellular network, a wired network and / or for example, the Internet is starting from a central computer (server) or service center. Remote maintenance is essentially the monitoring of vehicle status and access to maintenance data in the vehicle from a central point, to verify whether, when and what action to preserve the specified condition are performed. One example is the dynamic adaptation of maintenance intervals. In general, these functions are subsumed here under the concept of vehicle-related telematics service.

p00231 shows a vehicle-side member 1 and a server-side part 2. Both parts are connected via a communication interface 3, in particular an air interface, for example, over a cellular network with each other. The vehicle-side part consists of a terminal 4, for example a telematics terminal which is connected via a further interface 5 with the vehicle electronics. 6 The server-side portion 2 consists of a server 7, which is for example operated by a service center, the vehicle manufacturer or a supplier, and is connected to a data memory 9 connected via an interface 8, in the example in the context of a database vehicle-related data and / or commands and / or programs are stored. As described in detail below, are in the illustrated client-server system partitioned sub-functions, ie, the server and the client assigned to certain functionalities of a telematics service. In this case of a complete cross-linking to be diagnosed or to be controlled of the control units in the vehicle having the terminal, for example, through a CAN bus and the availability of the interface 3, in particular of a mobile radio interface in the motor vehicle, is assumed. The known, various methods for the collection of diagnostic data, for example via a CAN bus interface, can be divided into non-time-critical and time-critical applications. Among the non-time-critical applications heard for example the sequence control of the diagnostic tester, with access to a database, and the diagnostic protocol itself, for example, the protocol KWP2000 or variants. Time-critical applications are the transport protocol of the Vehicle network (eg CAN Transport Protocol) or variants thereof, the communication layer (eg CAN-Kom unikationsschicht) and the bus (eg CAN bus) itself. It is essential that in implementing the telematics function in the motor vehicle, the time-critical operations against the more uncertain mobile channel are decoupled. Therefore, all or part of the relevant functions of the vehicle to be outsourced, in which there are no tight time requirements, particularly requirements related to a minimum or maximum amount of time between command and response during data transmission. In an extreme case, therefore, remains, only the time critical data transport on the vehicle bus (for example CAN bus or the like), which is realized by functions of the transport protocol such as the fragmentation and defragmentation of complex messages back to the client or vehicle. The functionality of the generally complex and vehicle-specific service protocol (eg diagnostic log) is doing outsourced to a corresponding server (eg diagnostics server). In the application of remote diagnostics additional information between the server application (sequence control for the whole process) and the client application, in addition to the transfer of vehicle-specific diagnostic commands on the basis of the diagnostic protocol used in each case also transmitted (flow control for data acquisition). These sequencers are used to activate the diagnostic process, the configuration of the client application and the subsequent transmission of results to the server-side data analysis. In the example shown, in which all non-time operations have been outsourced from the onboard component in the server-side part of the system, there is the system architecture shown in FIG. 2 In other embodiments, only a portion of the non time-critical operations can be paged while a part in the vehicle-side terminal remains. For example, imagine that vehicle-specific data and / or vehicle-specific diagnostic commands that are not outsourced security reasons, remain in the vehicle-side part of the system.

p0024In conjunction with other telematic services such as the remote control of components, software download, etc. is outsourced to the manner described uncritical applications, while time-critical applications remain in the vehicle terminal.

p0025In Figure 2, the vehicle terminal (client) 4 and the server 7 is illustrated, which are connected to one another via an air interface 3rd In the preferred embodiment If it is at the air interface 3 to a conventional, based for example on the GSM-standard cellular network. In other applications, it is mobile networks that use different standards. The server includes the following modules: 7d a mobile radio communication protocol module 7a, a Mobilfunkkomii unications module 7b, a flow control module 7c and a vehicle-specific diagnostic protocol module. The vehicle terminal also includes a communication protocol module 4a, 4b, a module for communicating via the mobile radio interface, a module 4c for CAN communication, as well as a transport protocol module 4d. Further, a sequence controller 4e is provided in the vehicle terminal. The modules thereby represent preferably software programs.

p0026These functional units have the following tasks:

p0027The mobile communication modules 4b, 7b, which are both on the device as provided in the server, this for stable data transfer, the connection setup or dismantling, data security, where appropriate, the encryption, packetization, etc. These objects are realized by conventional communication functional units and eg in the context of the GSM standards are available.

p0028That provided in the vehicle terminal CAN communication module 4c provides a hardware-independent software interface for transmitting data over a CAN bus to connected control units represent. This includes the initialization and control of the CAN controller, the transmission and reception of CAN modules and overflow -Fehlerbehandlungen and alarms. Furthermore, the module includes the functions de r OSI Layer 1 and 2 (physical layer, data link layer). The software modules operates within the bounds of CAN specification. In other embodiments, a different bus systems instead of the CAN bus used (standardized or customized), wherein the software module is then implemented on the basis of a corresponding specification.

p0029The sequencer 7c in the server parses the diagnostic basic functions into separate processes or diagnostic services, takes care of initializing the process, controls and terminates the diagnostic process, processes the required parameter and optionally protocol mechanisms for the diagnostic process and controls the overall process time. the determined diagnostic data are furthermore here analyzed, optionally carried out a generation of a recommendation. Further, the control flow accepts the access to the diagnostic database of the server. The sequence controller is a software module, which for the particular application is designed. An example is outlined below with reference to remote diagnosis in Figures 3 and 4. FIG.

p0030In a corresponding manner, a flow control module 4e is provided in the vehicle terminal. Also this software module is designed for the particular application. An example is outlined below with reference to remote diagnosis in Figures 3 and 4. FIG. This processing generates a server request to perform remote diagnostics. You configure the functions in the vehicle, for example by setting a tester-present message, set the timing parameters for the transport protocol and optionally adjusting the parameters for the CAN communication. The scheduler also performs the diagnostic communication through by cyclic generation of tester-present messages to be diagnosed controllers. Further, the data transmitted from the server diagnostic commands are implemented on the CAN transport protocol from her. In addition, the flow chart transfers the data to the server and is for this purpose determined in the vehicle diagnosis data on the mobile radio interface to. In addition, measures have been taken, the evaluated results of the error analysis which are received from the server are displayed with which in one embodiment. Further, the control flow accepts the termination of the diagnostic communication by stopping the generation of tester-present messages. Moreover, in one embodiment, the automatic termination of an interrupted diagnosis procedure, eg timeout or watchdog, is performed for the reception of server commands.

p0031The envisaged in the client 4 transport protocol module 4d performs the transmission of complex messages or data units via a CAN bus, perform the decoupling of the diagnostic protocol of the physical transmission medium before and provides the services of the OSI layer 3 (network layer) available, as well as the connection between the OSI layer 2 (Data link layer) and 7 (application layer). There are as so segmentation and collection of data of the data link layer made from the transport protocol module, that is the flow control of individual messages including management and allocation of physical CAN messages to logical messages or data units and error detection. A realization is the commonly used ISO transport protocol (ISO 15765-2), where in other applications also special variants of this Protocol be used. This also applies when using other bus systems for communication with the vehicle control unit.

p0032The associated with the server diagnostic protocol module 7d includes the diagnostic layer in a preferred application, the specified ISO diagnosis protocol KWP2000, said depending on the embodiment and variations thereof are used. In this diagnostic protocol module specific diagnostic services are defined, which are used differently depending on the vehicle manufacturer and / or type of vehicle and partly contain different additional services. The diagnostic protocol module evaluates the diagnostic requests. Further objects, which are solved by the module, the conversion of services in a functional interface to the application layer, the direct use of specific services and the exception handling in use of unknown services. An example of the implementation of such a module is removable from the procedures described below.

p0033The basic approach in the context of remote diagnosis is that after activation of the remote diagnosis by an operator, for example the user of the motor vehicle, and / or the service provider and / or the vehicle manufacturer and / or a fitter a workshop after the completion of measures to establish a connection between terminal and server, the commands of the vehicle-specific diagnostic protocol on the air interface from the server are transferred to the terminal. The vehicle-specific diagnostic protocol commands are thereby read out from the diagnostic server to identify the under diagnosis motor vehicle from a database. The terminal is the transmitted diagnostic commands to the vehicle network. The done, for example, that the received commands are converted into commands for the diagnose and control unit via the interface to the vehicle network, in particular via a CAN bus to be sent to the control unit. The response of this control unit is received as a data message from the vehicle network in the appropriate format via the vehicle network interface and is then implemented by the terminal in response messages for the server. These are then transmitted to the mobile radio interface, which will be sent the message via a proposed transmission protocol (for example, as part of the GSM standard) to the server. In summary sets the client in the preferred embodiment, therefore, the transmitted from the server diagnostic protocol (KWP2000) to the CAN- Transport protocol and vice versa. The sequence control of the procedure described for the maintenance of diagnostic communication in the vehicle takes place in the terminal self-sufficient, for example, by so-called tester-present messages. These are defined in the KWP2000-Spezifιkation and serve to meet the time requirements of the vehicle network. This decoupling of the time-critical diagnostic communication in the vehicle is achieved by the non-time diagnosis processes in the server. Result is thus a flexible configuration of the vehicle-specific diagnostic communication in the vehicle which is not encumbered by problems of the air interface and the diagnostic processes in the server.

p0034Figure 3 shows a flowchart of the overall process, which is divided into five basic sub-steps. The detailed processes within such a partial operation can be varied depending on the vehicle type, the possibly present case of failure and / or the particular implementation of the system in the diagnostic server. In the first step 100 to start the diagnosis with a corresponding request to the server takes place. Capitalization is the generated by the driver or user of the motor vehicle by call or the like to the service center a prompt on the server to the client in the vehicle to develop a diagnostic compound in the preferred embodiment. The client then establishes the requested connection. In other embodiments, the diagnostic connection is set up by a request from the client. The construction of the actual diagnostic connection is made here by the server or the client. In the next step 200, the configuration of the remote diagnosis functionality is carried in the vehicle by the server. Here, the flow control, the transport layer and, optionally, the CAN communication to the specific vehicle is adjusted. This is done by commands and data from the server, the reads from a database for the particular vehicle or vehicle type / and / or Austattungsvariante this. When activating the server receives for example by means of an identification code information about the vehicle to be diagnosed. With this information it reads from vehicle-specific parameters from the database, which he then sent to the client to configure the remote diagnosis functionality.

p0035After the partial steps activation (100) and initialization (200) is shown the sub-step execution of the diagnostic process (301 to 303) as an example of a controller. First, the diagnostic mode, in step 301 by the server to be diagnosed in the control unit, where it is necessary, initiated, so that the Control unit for executing the diagnostic function is capable. Furthermore, the identification of the control unit, for example, its software level for adapting the diagnostic commands to the special control device type occurs. This, too, is optional and is used if this example, due to the number of soft stalls has proved necessary. Thereafter, the selected diagnostic commands are transmitted from the server to the client in the vehicle. Examples of such diagnostic commands the reading of at least one error memory of the controller concerned, the reading of stored ambient parameters of an error that has occurred and / or the retrieval of additional actual values ​​from the corresponding control unit.

p0036In step 302, the client sets the diagnosis or the transmitted commands to the vehicle network. In the subsequent step 303, the response of the control device on the one or more transmitted commands which must occur, for example within a certain period of time is received, from the client via is converted to the communication interface to the server and sent back to this. The steps 301 to 303 are then repeated for each to be diagnosed control unit or if the diagnostic commands are sent one at a time or in groups successively repeated for each diagnostic command or diagnostic command group. If the diagnosis is completed for a control unit, is sent as a diagnostic command an end command, which may have disabled the diagnostic mode in the control unit and this restored to the normal operating mode.

p0037The fourth sub-step concerns the evaluation of the data obtained in the server (step 400). The server evaluates according to a specific algorithm, if necessary, the collected error information, determines a diagnostic result and / or recommendations for further action. In the following step 500, then the results obtained by the server are transmitted to the terminal and displayed by this in the vehicle. This fifth partial step therefore reflects the result output. In this step, the transmission and display of a recommendation for further action in case of failure is also provided in an embodiment, for example, "visit workshop", etc.

p00384 shows an exemplary communication scenario between a remote diagnosis server, a telematics terminal, and a control unit. The communication scenario will stall for the implementation of the third partial step in Figure 3 illustrates in detail. Basic communication is specified by ISO 14230-3 diagnosis protocol KWP2000. In other embodiments are used vendor-specific variants of this diagnostic protocol or other diagnostic protocols accordingly. Depending on the embodiment varies the sequence of steps and the amount of steps in the individual applications. Figure 4 shows a preferred implementation of the communication between a remote diagnosis server I, a telematics terminal arranged in the vehicle to be diagnosed II and a controller III. The communication is based on the diagnostic protocol KWP2000, which is specified in ISO 14230-3. The error detection and setting the fault memory is carried out in most cases by known diagnostic methods to be diagnosed by the control unit located there or there read in software.

p0039In Figure 4, the individual communication between the three participating units are shown, from top to bottom a chronological sequence to be expressed. In the units software programs are available that produce to over Mitt lumbar messages, evaluate, etc.

p0040Once the subtasks 1 and 2 (see Figure 3, steps 100 and 200) of the diagnostic mode is activated in under diagnosis control unit in a first step Sl. For this, the server sends a corresponding diagnostic command (start diagnostic session request). This is received by the terminal and the interface to be diagnosed controller relayed (step S2) or first converted into a suitable vehicle for the network format (eg. By means of a table) and then added to the vehicle network. The to be diagnosed control unit responds with an appropriate answer (start-diagnostic-session Response), which indicates whether the diagnostic mode is started or not. This information sends the to be diagnosed control unit in step S3 to the terminal, which in turn (possibly after conversion to the intended format) transmits the information to the server in step S4.

p0041Then, for flow control and to meet the time requirement in the vehicle power from the terminal II to the control unit III in step S5, a command is sent (tester-present Request), which is answered in step S6 of the control unit with an appropriate answer (tester-present Response) , This communication is executed in the following during the diagnostic process, if the server no other diagnosis-command is to be forwarded or to be passed no response to the server by the control unit. Therefore, steps S5 and S6 are repeated several times, as long as received until the expected command from the server. not If any of these events occur, the communication between terminal and controller is interrupted._,

p0042After receiving the response in step S4, the server sends in step S7, a command (Read ECU Identification Request) that requests the identifcation of about diagnostierenden controller. This command is received by the terminal and possibly converted and then transmitted in step SS to the controller. The control unit reads from its memory then at least one identification parameter and sends these to the terminal device (Read ECU Identification Response, step S9). This information is then transmitted to possibly implement the terminal II in the step S10 to the server. On the basis of the identification parameter, the server detects the control unit, where appropriate, its software version and optionally the vehicle, and selects from the database corresponding parameters. Meanwhile, running, as illustrated by the steps Sl l and S12, between the terminal and to be diagnosed control unit, the above-described tester-present communication from which ensures that the communication between terminal and controller is maintained, the controller remains in diagnostic mode and no violation of the boundary conditions for the communication in the vehicle network, which leads to the termination occurs.

p0043In the next steps the fault memory to be diagnosed control unit are read. Given the server transmits after receiving the message in step S10 and read out the control unit-specific parameters to the terminal in step S13 a request (Read DTC request). In this request, the control unit-specific parameters are included in which, for example, we specify which fault memory are read. This request is optionally transmitted in step S14 from terminal by conversion to the control unit. The controller executes the received command and sends the error memory contents as a message read-DTC response in step S 15 to the terminal. The message read-DTC response therefore contains the relevant fault memory contents. The answer is possibly transmitted from the terminal to implement the step S 16 to the server. Then, S17 and S18, the above-mentioned tester-present communication between terminal and controller is carried out until the next receipt of a message from the server in steps.

p0044In the subsequent, optional partial step that pertains to the defect entries ambient parameters are read. For this purpose, the server sends after receipt of the Message in step S16, and after evaluation of the error messages in step S19 to the terminal a request (Read Freeze Frame Request), which optionally passes this by implementing the step S20 to the control unit. Depending on the version reads the controller then the desired parameters to the stored Fehlem out or the server specified with reference to the contents of the fault memory the content of his message, so that only certain ambient parameters are requested with this message. The control apparatus in any event, responds with a corresponding response (Read-Freeze Frame - Response) in which the parameters requested in one way or another are included. In step S21, the response is sent to the terminal to which the reply again if necessary after conversion in the step S22 to the server transfer. In steps S23 and S24 again carried the tester-present communication.

p0045In the subsequent sub-step, after the fault memory and associated environmental parameters are read out and transferred, the diagnostic mode is disabled in the control unit. For this purpose, the server sends a request to exit the diagnostic process (Stop-diagnostic-session request) to the terminal. This gives the quit request to the control unit (step S26), which with a corresponding response signal (stop Diagnostic Session Response) in step 27, with which the control unit notifies the completion of the diagnostic mode responds. This information is transmitted from the terminal in step S28 to the server. Then (step S29) are carried on 4 and 5 with respect to evaluation and display of diagnostic results and, if the subtasks Recommendations outlined above.

p0046The communication scenario depicted is an example. In other embodiments, the steps for activating and deactivating the diagnostic mode in the control unit and / or identification of the control unit and / or for reading the associated environmental parameters are missing.

p0047The actual technical implementation of the communication represented by finds appropriate software programs held in server, terminal and control unit, which each are also part of the invention itself.