REMOTE VEHICLE DIAGNOSTICS USING UNMODIFIED STANDARDIZED DIAGNOSTIC APPLICATIONS

Abstract

In the field of automotive diagnostics, the invention provides equipment and methods for remote vehicle diagnostics using vehicle diagnostic applications conforming to the SAE J2534 or ISO 22900-2:2022 D-PDU or TMC RP1210 standard. A diagnostic application conforming to SAE J2534 is installed on a remote device (201) while the primary SAE J2534 DLL is pre-installed in a device (101) local to the vehicle (111) being inspected. To keep the application and the primary DLL without modification from their standardized local use, the invention provides for modifying the Windows registry entry of the remote device normally associated with the primary DLL to identify a new DLL, called the linking DLL, configured to route, via the communication network (210) and a linking software agent (205) of the local device (101), a data stream between said diagnostic application and the SAE J2534 DLL of the VCI interface (110) connected to the vehicle.Figure for the abridged version: Fig.2.

Description

Title of the invention: REMOTE VEHICLE DIAGNOSIS USING UNMODIFIED STANDARDIZED DIAGNOSTIC APPLICATIONS FIELD OF THE INVENTION

[0001] The invention relates to the field of automotive diagnostics and maintenance and in particular remote diagnostics using vehicle diagnostic applications conforming to certain standards, such as the SAE J2534 standard of December 2004 also known as the “Passthru” standard. PRIOR TECHNIQUES

[0002] Many of a vehicle's functions are controlled by on-board Electronic Control Units (ECUs), otherwise known as "calculators". These communicate with each other via an on-board communication bus. Communication protocols, such as CAN - Controller Area Network - vary from one manufacturer to another.

[0003] ECU calculators can be analyzed, configured, programmed or reprogrammed during vehicle repair and maintenance operations (RMI - Repair and Maintenance Information). Each manufacturer has thus developed its own software or "vehicle diagnostic application" which communicates with a box connected to the vehicle (via its OBD - On Board Diagnostic socket), known as a vehicle communication interface (VCI - Vehicle Communication Interface), to enable diagnosis of its vehicles.

[0004] However, in order for all independent operators, such as authorized dealers, repairers and garages, to be able to work on these computers, standards have been established which define the application programming interfaces (APIs) that these vehicle diagnostic applications and VCI interfaces must comply with in order to communicate with each other. The main standards include SAE J2534 (in particular specification J2534-1 of December 2004), ISO 22900-2:2022 D-PDU and TMC RP1210 (September 2006).

[0005] Furthermore, many organizations, such as the European Commission, have legislated to require manufacturers to make a version of their vehicle diagnostic software application available to independent operators. We are particularly familiar with Regulation (EC) No. 715 / 2007 (Euro 5 / 6) and its implementing regulations No. 692 / 2008 and No. 566 / 2011 (together the "Euro 5 standard") which defined these constraints imposed on car manufacturers to provide the technical information essential to diagnosis, repair, maintenance and servicing of their vehicles, including the ability to program or reprogram computers.

[0006] In fact, independent multi-brand operators can use vehicle diagnostic applications from multiple manufacturers, generally for a fee for limited periods or uses. However, this situation presents many difficulties, including the need to open and manage as many customer accounts as there are manufacturers, but also the need to use several computers when these vehicle diagnostic applications are not compatible with each other. In addition, there is a need to be trained in all these applications used, as well as to ensure their regular updating. It is then common for these independent operators to turn to multi-brand vehicle diagnostic applications whose services are reduced or degraded compared to manufacturer applications, or even to subcontract the diagnostic operation to an official repairer of the manufacturer.

[0007] In view of this observation, remote vehicle diagnostic systems have been proposed comprising a third-party assistance center (hotline) which controls and directs, via a communication network, a specific remote diagnostic operation. Publication EP3690579 illustrates such a system.

[0008] These systems advantageously allow the independent operator to keep the vehicle to be repaired in his workshop, while reducing costs and management thanks to pooling between several independent operators subscribing to the system.

[0009] These systems, however, require the development of specific remote vehicle diagnostic applications, for example by modifying the code of the applications compliant with the above standards in order to integrate additional functionalities such as those ensuring communications via the communication network, typically the Internet. This would guarantee to independent operators that the manufacturer's official vehicle diagnostic application is used to carry out the diagnostic operation.

[0010] This situation is nevertheless not entirely satisfactory because it is necessary to wait for each manufacturer to agree to implement such modifications. On the other hand, it would be preferable to allow the reuse of applications compliant with the standards and the corresponding VCI interfaces also compliant with the standards, without having to modify their code. Statement of the invention

[0011] The inventors have found that these standards require the installation, on the same computer as the vehicle diagnostic application conforming to one of the standards, of a primary dynamic link library (or DLL for “Dynamic Link Library”), itself conforming to the standard, which is dedicated to the VCI interface. The application of vehicle diagnostics and the primary dynamic link library thus communicate via the API of the implemented standard.

[0012] These standards also require updating the Windows registry (trade name) of the computer to indicate the local location of this primary dynamic link library allowing its loading by the application and thus communication between the vehicle diagnostic application and the VCI interface, either directly or via a VCI interface driver also installed on the computer local to the vehicle being inspected.

[0013] The present invention aims to solve the aforementioned drawback by making it possible to circumvent these limitations of the mentioned standards, in order to allow remote use of already existing vehicle diagnostic applications and standardized VCI interfaces without modification of the binary code of the existing components.

[0014] For this purpose, the invention relates to a remote vehicle diagnostic device, comprising: - a communication interface with a communication network, and - a vehicle diagnostic application compliant with one of the SAE standards J2534, ISO 22900-2 D-PDU and TMC RP 1210 and capable of communicating with a vehicle communication interface, VCI, through the use of a primary dynamic link library, DLL, associated with the VCI interface and compliant with said standard, said diagnostic application being configured to use an operating system (OS) registry entry to identify the primary DLL,

[0015] characterized in that the remote diagnostic device comprises a link DLL capable of routing, via the communication network, a data flow (eg a message) between said vehicle diagnostic application and a remote primary DLL configured to communicate locally with a VCI interface connected to the vehicle, said registry entry being configured to identify the link DLL in place of a primary DLL associated with the VCI interface.

[0016] The invention therefore provides for diverting the use of the Windows registry used by the vehicle diagnostic application to indicate a DLL carrying out the communication operations, and no longer the conventional primary DLL. Thus, the vehicle diagnostic application can be transferred to a remote device without modifying either the latter or the primary DLL.

[0017] The invention also relates to a remote vehicle diagnostic system, comprising: - a remote diagnostic device connected to a communications network and comprising a vehicle diagnostic application compliant with one of the SAE J2534, ISO 22900-2 D-PDU and TMC standards RP 1210 and capable of communicating with a vehicle communication interface, VCI, by the use of a primary dynamic link library, DLL, associated with the VCI interface and conforming to said standard, said diagnostic application being configured to use an operating system (OS) registry entry in order to identify the primary DLL, and - a device local to the vehicle, connected to the communication network and comprising a primary DLL configured to communicate locally with a VCI interface connected to a vehicle to be diagnosed,

[0018] characterized in that the remote diagnostic device comprises a link DLL capable of routing, via the communication network and a link software agent of the local device, a data flow between said vehicle diagnostic application and the primary DLL of the VCI interface connected to the vehicle, said registry entry being configured to identify the link DLL in place of a primary DLL associated with the VCI interface.

[0019] For its part, the addition, at the local device level, of a linking software agent carrying out the inverse operations of the linking library also makes it possible to keep the primary DLL of the VCI interface without any modification.

[0020] The invention also relates to a method for remote diagnosis of a vehicle, comprising, at the level of a remote diagnosis device of a device local to said vehicle, the following steps: - obtain a vehicle diagnostic application compliant with one of the SAE J2534, ISO 22900-2 D-PDU and TMC RP1210 standards and capable of communicating with a vehicle communication interface, VCI, by the use of a primary dynamic link library, DLL, associated with the VCI interface and compliant with said standard, said diagnostic application being configured to use an operating system (OS) registry entry to identify the primary DLL, - configure the registry entry to identify, instead of a primary DLL associated with the VCI interface, a link DLL capable of routing, via a communication network, a data flow between said vehicle diagnostic application and a remote primary DLL configured to communicate locally with the VCI interface connected to the vehicle, and - load the link DLL during an execution of the vehicle diagnostic application so that a diagnostic message generated by the vehicle diagnostic application is routed over the communication network to the remote primary DLL and the VCI interface connected to the vehicle.

[0021] Optional features of embodiments of the invention are defined in the appended claims. Some of these features are explained below with reference to a device or a process, while they can be transposed into process or device characteristics respectively.

[0022] In one embodiment, the linking DLL and / or the linking software agent comprises a converter capable of encapsulating the data stream into one or more structured data frames, for example JSON (JavaScript Object Notation) or markup such as XML (extensible Markup Language) or HTML (HyperText Markup Language), or of de-encapsulating one or more structured data frames into said data stream, so as to exchange structured data frames over the communication network, typically the Internet. This simplified format, JSON type, makes it possible to reduce the volume of data exchanged, and thus accelerate the processing time of the diagnostic operations taking into account the distance.

[0023] Thus, the method may comprise a step of converting the diagnostic message by encapsulation into one or more structured data frames before routing to the VCI interface via the communication network.

[0024] In another embodiment, a VCI interface identifier is added to the structured data frame so as to route said frame to a primary DLL (via a link agent dedicated or common to several DLLs, and consequently route the frame to a desired VCI interface) corresponding to said identifier among several primary DLLs accessible on the communication network. This makes it possible to ensure the correct remote control of a VCI among a potential pool of several VCIs (because of several users).

[0025] In another embodiment, the linking DLL and the linking software agent are configured to establish a web socket type communication channel between them, over the communication network. This arrangement makes it possible to accelerate the processing time of the diagnostic operations taking into account the distance.

[0026] In another embodiment, the link DLL and / or the link software agent comprises a routing filter configured to determine, based on a filtering criterion, whether a message received for routing is to be deleted without routing it. In this way, certain unnecessary protocol frames can be deleted, reducing the latency times of the exchanges between the application and the remote primary DLL.

[0027] Thus, the method may comprise a step of filtering messages received for routing comprising determining, as a function of a filtering criterion, whether a received message is to be deleted and, if so, deleting said message without routing it.

[0028] According to a static configuration, the filtering criterion deletes a message of type VBAT relating to a query on the battery level of the vehicle, of type FwVersion relating to a query on the firmware version embedded in the VCI interface, of type DllVersion relating to a query on the version of the DLL primary and / or ApiVersion type relating to a query on the API version implemented by the primary DLL.

[0029] According to a dynamic configuration, the routing filter is configured to determine a type of message routed recurrently and, in response, to configure said filtering criterion so as to delete any subsequent message of said type over at least a predefined period. By "recurrently", it is meant a message whose average transmission frequency is greater than a threshold value, for example more than ten transmissions of the message of the same type per minute (sliding time window).

[0030] In one embodiment, the VCI interface connected to the vehicle forms a device separate from the local device. This arrangement allows independent operators to maintain their current computer architecture, involving the presence of a computer to which the VCI interface is connected (generally by cable). In a particular embodiment, the local device comprises a driver associated with the VCI interface to route data between the primary DLL and the VCI interface external to the local device. The driver makes it possible in particular to adapt to different configuration sets implemented in the Firmware embedded on the VCI.

[0031] In another embodiment, the local device forms the VCI interface connected to the vehicle. This arrangement allows independent operators to avoid the use of an additional computer.

[0032] The present invention also relates to a computer program comprising instructions for implementing the above method, when this program is executed by a processor. This program can use any programming language (for example, an object language or other), and be in the form of an interpretable source code, a partially compiled code or a fully compiled code.

[0033] The invention also relates to a non-transitory recording medium readable by a computer on which a program is recorded for implementing the above method, when this program is executed by a processor.

[0034] At least a portion of the methods of the invention may be computer-implemented. Accordingly, the present invention may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be collectively referred to herein as a "circuit," "module," or "system." In addition, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium. Brief description of the drawings

[0035] Other features and advantages of the invention will become apparent in the description below, illustrated by the attached figures which illustrate exemplary embodiments which are not in any limiting nature.

[0036] [Fig.l] schematically illustrates the architecture of a vehicle diagnostic system according to known standards.

[0037] [Fig.lA] illustrates Windows registry entries in accordance with SAE J2534.

[0038] [Fig. 1B] illustrates a method of loading and unloading a SAE J2534 DLL.

[0039] [Fig.2] schematically illustrates the architecture of a remote vehicle diagnostic system according to embodiments of the invention.

[0040] [Fig.3] schematically illustrates an implementation of the link between the vehicle diagnostic application and the SAE J2534 DLL according to embodiments of the invention.

[0041] [Fig.4] schematically illustrates the management of the links in the event of a plurality of vehicle diagnostic applications on the remote device according to embodiments of the invention.

[0042] [Fig.5] schematically illustrates a device hardware structure for an implementation of the invention. DETAILED DESCRIPTION

[0043] In the field of automotive diagnostics and maintenance, the present invention proposes equipment and methods for remote vehicle diagnostics using vehicle diagnostic applications compliant with certain standards / norms dedicated to in situ diagnostics, such as the SAE J2534 standards (in particular specification J2534-1 of December 2004), ISO 22900-2:2022 D-PDU and TMC RP1210 (September 2006).

[0044] [Fig.l] schematically illustrates the architecture of a vehicle diagnostic system 100 according to these standards. The examples given below are primarily based on the SAE J2534 standard, which is reproduced identically in the ISO 22900-2:2022 D-PDU standard. The TMC RP1210 standard presents similar mechanisms.

[0045] The system 100 is typically implemented in a garage for light vehicles.

[0046] It comprises a computer or "host system" 101 for an operator, typically technician in the workshop, and a VCI box called “VCI interface” 110 or “pass-thru device” in the SAE standard.

[0047] The VCI interface 110 is connected to the vehicle 111 to be inspected by a cable connected to an OSB socket, typically SAE J1962, of the vehicle. The connection protocols and communication with the vehicle's on-board ECUs 111 are defined by the manufacturer, and are therefore not further described.

[0048] On the other side, the VCI interface 110 is connected to the host system 101 by another cable (RS-232, USB, Ethernet, IEEE 1394) or even wirelessly (Bluetooth - commercial name, WiFi - commercial name). The host system 101 hosts one or more manufacturer vehicle diagnostic applications 102, for example a so-called Euro5 application.

[0049] The VCI interface 110 thus interfaces the host system 101 with the on-board systems of the vehicle 111, in particular performs a translation or conversion, without interpretation of a message or data frame, between the communication protocols used by the on-board systems and the communication protocol used by the host system (the diagnostic application) outside the vehicle.

[0050] The above-mentioned standards more particularly define the application programming interfaces (APIs) between the vehicle diagnostic applications 102 and the VCI interfaces 110.

[0051] "norm" and "standard" are used herein as synonyms. By "compliant with the standard" or "standard-compliant", it is understood that a piece of equipment or software module implements the API of the standard, therefore including the functions defined in the standard, to communicate with another piece of equipment or software module that is also compliant with the standard. The API contains a set of routines or functions that can be used to communicate with another software component.

[0052] A vehicle diagnostic application 102 compliant with the standard uses the common API of the standard, e.g. SAE J2534, which allows it to communicate with the VCI interface 110 (connected to the vehicle), itself compliant with the standard, and thus control the communications between the VCI interface 110 and the vehicle 111.

[0053] In practice, compliance of the VCI interface 110 with the standard is obtained by installing and using a dynamic link library or “DLL” (Dynamic Link Library) implementing the API of the standard. For the purposes hereinafter, this DLL is referred to as the “primary DLL” and is referenced 104 in the Figure.

[0054] The standard, such as SAE J2534, in fact provides that the manufacturer of a VCI interface 110 provides a software driver ("primary driver" hereinafter) dedicated to the VCI interface allowing its hardware support by the host system and provides an installation and configuration program for the operating system OS (for example Windows - commercial name) of the computer 101, which program installs the primary DLL and other required files, and also updates the registry 103 of the OS. For this purpose, the installation program provided with the VCI interface creates a specific registry entry for the VCI interface, as illustrated in the example of [Fig.lA] specific to the SAE J2534 standard.

[0055] In this Figure, the registry base comprises several registry entries 103-i which each comprise a set of information relating to the VCI interfaces pre-installed on the host system 101. In particular, each entry 103-i specific to a VCI interface 110 comprises a field, “FunctionLibrary” in the SAE standard, identifying the corresponding primary DLL, for example by indicating the local access path to it.

[0056] In use, as illustrated by [Fig.lB], the vehicle diagnostic application 102 uses the register 103 to present to the local operator the list of VCI interfaces available for use from the application. Once a VCI interface has been selected by the operator, the corresponding register entry 103-i is used to retrieve all information regarding the VCI interface so that the appropriate primary DLL 104 is loaded for use.

[0057] When starting the vehicle diagnostic application 102 (step 10), it is determined whether a VCI interface is selected (step 11). This is the case, for example, if there is only one VCI interface pre-installed on the computer 101. If not, the registry entries 103-i are scanned to present the operator with the list of available VCI interfaces (step 12). The names of the VCI interfaces, "Name" field of [Fig. 1A], can, for example, be presented to the operator on a screen for selection. In step 13, the latter selects one of the VCI interfaces (using a user interface on the computer 101, not shown). The location of the associated primary DLL is retrieved in step 14 using the "FunctionLibrary" field (in the SAE standard) of the entry 103-i corresponding to the selection. The primary DLL is then loaded in step 15, for example using the Windows function "LoadLibrary".A dynamic correspondence is then performed in step 16 between the functions / routines of the standardized API and the functions of the primary DLL thus loaded.

[0058] Step 17 consists of carrying out diagnostic operations on the vehicle using the application 102. The diagnostic operations may include operations for interrogating on-board computers, but also operations for configuring, programming or reprogramming the computers.

[0059] In practice, the executed vehicle diagnostic application 102 establishes and manages a connection with the VCI interface 110, via the loaded primary DLL 104 and the possible primary driver, by calling dedicated API functions of the standard, for example the commands PassThruOpen, PassThruClose, PassThruConnect, PassThruDisconnect, etc. in the SAE standard.

[0060] For example, the local operator decides on diagnostic actions to be taken via a user interface allowing interaction with the vehicle diagnostic application 102 being executed. In response to the operator selecting an action, the vehicle diagnostic application 102 uses the API of the standard to generate manufacturer command / diagnostic messages to the primary DLL. The latter is capable, i.e. configured, to transmit this command to the VCI interface (via the primary driver if provided). For example, the application 102 calls the PassThruWriteMsgs function of the API (in the SAE standard) to send a new command message, which is received by the primary DLL 104 which transmits it to the VCI interface associated with it.

[0061] If a response is generated, it takes the return path: the vehicle diagnostic application 102 which must retrieve the response message from the VCI interface calls the PassThruReadMsgs function of the API proposed by the primary DLL 104 to read this response message. The response message can thus be displayed to the operator.

[0062] Step 18 of unloading the primary DLL 104 occurs at the end of the diagnostic operation, when closing the application 102 or when changing the VCI interface 110.

[0063] [Fig. 2] schematically illustrates the architecture of a remote vehicle diagnostic system 200 according to embodiments of the invention. This architecture incorporates the above components but in a remote configuration, namely:

[0064] at a remote diagnostic device 201 connected to a communication network 210, the unchanged vehicle diagnostic application 102, compliant with the SAE J2534, ISO 22900-2 D-PDU or TMC RP 1210 standard implemented, as well as the registry 103 listing the information relating to the VCI interfaces pre-installed on the remote equipment 201, and

[0065] at the local operator's computer 101, still the primary DLL 104 unchanged, conforming to the standard, configured to communicate locally with the targeted VCI interface 110 which is connected to the vehicle 111 to be diagnosed.

[0066] In one scenario, the site local to the vehicle is an independent garage while the remote site is a support center (hotline) shared between several garages or a center of a manufacturer. This allows independent garages to outsource the management of multiple manufacturer applications 102, while benefiting from complete manufacturer diagnostic services.

[0067] In another scenario, the local site to the vehicle is a private home or a place where the broken-down vehicle is immobilized while the remote site is an automotive expert center, for example a garage. An independent garage can thus intervene remotely with its customers, avoiding occupation of its garage and improving its responsiveness.

[0068] The invention therefore makes it possible to carry out diagnostic operations with any vehicle diagnostic application compliant with the chosen standard which constrains these applications to run locally only and not remotely from the vehicle, but also with any VCI interface compliant with the chosen standard, i.e. supplied with a possible primary driver and a primary DLL implementing the API of the standard. No modification of these software components is necessary. This is made possible by the introduction of new intermediate components as described below, one of which, of the same DLL nature as the primary DLL, tricks the vehicle diagnostic application to allow intermediate communication via the communication network.

[0069] The communication network can be any type of data network, wired or wireless, including a Wifi network (trade name), the Internet network, a local area network LAN or WLAN, a mobile telephone network (4G, 5G, etc.).

[0070] According to the invention, the remote diagnostic device 201 comprises a link DLL 204 in place of the primary DLL which is itself stored remotely on the local computer 101. For this purpose, the registry entry 103-i is therefore configured to identify the link DLL in place of a primary DLL associated with the VCI interface as required by the standard, in particular by changing the “FunctionLibrary” path to indicate the local access path to the link DLL 204.

[0071] To make the VCI interface available in the application 102, the latter is installed on the remote device 201 according to the conventional procedure described above. A dedicated registry entry 103-i is therefore created whose “FunctionLibrary” path locates the installed primary DLL. However, the latter will not be used locally and can therefore be deleted. On the other hand, it is the value in the registry entry which is modified according to the invention to now indicate the link DLL 204.

[0072] The linker DLL 204 may be installed conventionally by an installation script or program. The installation script or program may further modify the registry entry 103-i discussed above.

[0073] For the purposes of the invention, the link DLL 204 allows communication with the local device 101. Also, the link DLL is able to (configured to) route, via the communication network 210, a data flow between said vehicle diagnostic application and the remote primary DLL 104. The data flow is formed of messages conforming to the API of the standard as exchanged, typically diagnostic commands generated by the application 102 or responses generated by the computers of the vehicle 111 inspected and sent back to the primary DLL 104.

[0074] As described below in connection with Figures 3 and 4, the linker DLL 204 has a dual function for the purpose of performing data routing.

[0075] In the transmission direction, it is configured to cut the data stream received from the application 102 into data frames that can be exported over an IP network protocol. (Internet Protocol), in particular according to a structured language, such as JSON. It thus encapsulates the data (raw data as received) in frames provided by the network protocol (typically of limited size). It therefore has a first conversion and encapsulation function. It is further configured to transmit these data frames from the remote device 201 to the local computer 101, to a dedicated agent described below. It therefore has a second function of communication with the dedicated agent.

[0076] The communication of frames on the communication network 210 can be carried out with any communication protocol, including the suite of internet protocols, and in particular http (Hypertext Transfer Protocol), HTTPs, etc.

[0077] In the reception direction, it operates the reciprocal functions: it communicates with the dedicated agent and receives data frames, in particular according to a structured language, JSON type; then it reconstitutes a data flow (by de-encapsulating the data from these received frames. A vehicle response message conforming to the API is thus reformed.

[0078] As illustrated in the Figure, the local computer 101 comprises a reciprocal communication agent of the link DLL 104, to establish communication between these two entities and operate the reciprocal functions. This agent is called “link software agent” hereinafter and bears the reference 205. Due to its central role in the local computer 101 which can be connected (successively) to several different VCI interfaces, the link software agent 205 can also be seen as a VCI server.

[0079] Generally, in the reception direction, the link software agent 205 reconstructs the initial data stream (i.e., the diagnostic messages conforming to the API of the standard) by de-encapsulating the data from the frames that it receives from the link DLL 204, then transmits this reconstructed stream to the primary DLL 104 (via the API of the standard) for communication to the VCI interface driver or directly to the VCI interface as in the prior art. Also, the primary DLL 104 is retrieved and then loaded during the execution of the link software agent 205, thus making it possible to perform a dynamic correspondence of the functions of the primary DLL 104 with those of the link software agent 205.In the transmission direction, the link software agent 205 cuts a data stream (response message conforming to the API of the standard) received from the primary DLL 204 (initially from the VCI interface 110) into data frames exportable on the link protocol, then transmits these data frames to the link DLL 204 of the remote device 201.

[0080] In an architectural variant which does away with the use of a computer on the local site, the liaison agent 205 and the possible primary driver can be embedded in the VCI interface 110. Thus the “local device” is formed of the single interface VCI. The latter includes, in this case, a communication interface with the 210 network.

[0081] [Fig.2] illustrates a communication network 210 comprising one or more equipment 206 capable of providing one or more functions relating to the communication of data frames between the remote device 201 and the local device 101.

[0082] A router-type device 206 makes it possible to route these frames within a network, for example a company network, to which the two devices belong.

[0083] A gateway-type device 206 is used when the two devices belong to separate networks and ensures the interconnection between these networks and the routing of frames from one network to the other. Such a gateway can also provide communications security services, for example include an OAuth2 server (commercial name) for authentication of remote devices wishing to access the connection agent (VCI server) 205.

[0084] The local site, for example the computer 201, can further be equipped with a firewall configured to limit access to the connection agent (VCI server) 205 via a single port, for example port 443 for http.

[0085] [Fig.3] schematically illustrates an implementation of the link between the vehicle diagnostic application 102 and the primary DLL 104. In this configuration, the link DLL 204 and the link software agent 205 establish a web socket type communication channel, on the communication network 210.

[0086] In the Figure, the link DLL 204 is represented as two modules, one 204-1 for data stream conversion and the other 204-2 for communication on the communication network 210. Similarly, the link agent 205 comprises a first module 205-2 for communication on the communication network 210 and a second module 205-1 for data stream conversion.

[0087] As explained above, modules 204-1 and 205-1 perform a conversion between a data flow conforming to the API of the standard and data frames structured for example in JSON format (either in the transmission direction or in the reception direction).

[0088] In one embodiment, these modules 204-1 and 205-1 comprise a routing filter designed to determine, based on a filtering criterion, whether a message received for routing is to be deleted without routing it. Indeed, the remote use of the vehicle diagnostic application 102 initially designed to be directly connected to the VCI interface can cause performance problems. In particular, the protocol of the aforementioned standards is a synchronous protocol in which the application 102 waits to receive a response before sending a next message. The exchanges are therefore slowed down and can conflict with predefined timeouts at the level of the on-board computers, which are often less than 100 ms.

[0089] The filtering provided in modules 204-1 and 205-1 thus makes it possible to delete non-essential protocol frames.

[0090] Filtering can be static. For example, some messages are identifiable by a specific format or field value. A blacklist of message types to be deleted under routing (or alternatively a whitelist of message types to be routed without deletion, the others being to be deleted) can be provided. The module therefore simply compares the type of a new message received with the types in the list, and in the case of an unauthorized message, deletes it.By way of illustration, the VBAT type messages relating to a query on the battery level of the inspected vehicle, the FwVersion type messages relating to a query on the firmware version (“embedded software”) embedded in the VCI interface, the DllVersion type messages relating to a query on the version of the primary DLL and / or the ApiVersion type messages relating to a query on the API version implemented by the primary DLL can be systematically deleted or their routing frequency can be reduced in particular by allowing one message to pass per predefined period (for example one message per minute instead of ten messages without filtering). Indeed, the frequency of these messages can reach several tens per minute and thus considerably reduces the performance of a remote use mode of the vehicle diagnostic application 102. .

[0091] These messages can be identified in the function call signaling of the standardized API. For illustration, the PassThruIoctl command of the SAE standard includes a loctlID parameter whose value identifies one of these types of messages, notably IoctlID=READ_VBATT to read the battery status. Similarly, the PassThruReadVersion command of the SAE standard returns the firmware, driver and API versions via the three parameters pFirmwareVersion, pDllVersion and pApiVersion respectively.

[0092] Filtering may also be dynamic. For example, the module first determines a message type that is routed too frequently, which may be one or more of those identified above. For illustration purposes, a message type is too frequently if its transmission frequency is greater than a threshold value, for example ten transmissions per minute. If the determination is positive, any subsequent message having this message type is deleted without routing or, alternatively, the routing frequency is reduced by, for example, allowing only one message to pass per predefined time unit.

[0093] Preferably, the response obtained from the vehicle for the single query transmitted to it is saved in the cache of the link DLL 204, so as to provide a copy of this response to any new message of the same type which is deleted. Thus, the vehicle diagnostic application 102, unmodified, is not confronted with blocking timeouts (query without response).

[0094] Undeleted messages are communicated to the communication module 204-2 or 205-2.

[0095] As indicated above, the linking DLL 204 and the linking software agent 205, via these two modules 204-2 and 205-2, establish a web socket type communication channel, on the communication network 210.

[0096] Given the client-server scheme of the web socket technology, the remote device 201 may be provided with a web socket server 304. The web socket server 304 may be integrated into the link DLL 204 or advantageously be an independent module (available off the shelf, for example an Open Source library) that the link DLL 204 loads on demand. Alternatively, the web socket server, referenced 305, is hosted on the local device 101.

[0097] When the independent operator calls the remote service, the communication module 205-2 of the agent 205 connects to the remote device 201 by establishing a Web Socket connection with the server 304. For its part, the module 204-2 of the link DLL 204 also establishes a Web Socket connection with the server 304 (internally in the remote device 201) if the latter is not directly integrated into the link DLL. A communication channel between the two modules 204-2 and 205-2 is thus established by web sockets.

[0098] The use of the vehicle diagnostic application 102 is always in accordance with the method of [Fig.1B]. The arrangements according to the invention are transparent for this application and for the primary DLL 104.

[0099] Steps 10, 11, 12, 13 and 14 remain unchanged.

[0100] Given the modification of the “FunctionLibrary” field to indicate the link DLL 204, step 15 makes it possible to retrieve and load (Windows function “LoadLibrary”) said link DLL 204 and no longer the primary DLL 104. The dynamic correspondence of step 16 is then carried out with the functions of the link DLL 204 thus loaded.

[0101] This leads to the diagnostic operations on the vehicle, still generated using the application 102, (step 17) taking place as follows.

[0102] The independent operator calling the remote service, its communication module 205-2 has established a Web Socket connection with the web socket server 304. The connection between the VCI interface 110 and the primary DLL 104 is, for its part, managed in a conventional manner.

[0103] When the link DLL 204 is loaded following the selection on the remote device 201 of the VCI interface used by the independent operator, the communication module 204-2 also establishes a Web Socket connection with the server 304. The communication channel between the link DLL 204 and the link agent 205 is thus established.

[0104] When a diagnostic message is generated by the vehicle diagnostic application 102, it is handled by the linker DLL 204 in accordance with the dynamic correspondence of step 16. The module 204-1 optionally filters (delete) the message if it is of a prohibited type, otherwise converts it into structured data frames, JSON type.

[0105] Each frame typically includes in a header an identifier of the target VCI (and therefore of the associated link agent 205) such as a serial number of this VCI. Alternatively, a primary DLL identifier 204 or a link agent identifier 205 could be used. This identifier may have been entered or selected manually by the remote operator during the initialization of the procedure. For example, the list of VCI identifiers available to the remote operator is stored in a server of the communication network (Internet server) and is updated by the local operators each time a new VCI is installed on their local devices.

[0106] These frames are passed to the module 204-2 which transmits them to the local device 101 whose address (and port) is associated, in a routing table for example within the communication network server, with the VCI identifier. This transmission is carried out using the http or HTTPS protocol within the web socket connection. In this case, the module 205-2 can take the form of an http server with which the module 204-2 communicates.

[0107] The received frames are passed to the module 205-1 using the VCI identifier present in each frame. The module 205-1 then deencapsulates these frames so as to reform the diagnostic message.

[0108] The latter is transmitted by the linking agent 205 to the primary DLL 104. This transmission is based on the dynamic correspondence carried out between the linking agent 205 and the primary DLL 104 when the latter is loaded.

[0109] The rest of the transmission of the diagnostic message to the VCI interface is conventional.

[0110] The transmission of response messages (from the computers to the application 102) follows the same mechanisms, in the opposite direction.

[0111] [Fig.4] schematically illustrates the management of the links in the event of a plurality of vehicle diagnostic applications 102 on the remote device 201.

[0112] A remote operator or expert, user of the remote device 201, can carry out several diagnostic operations in parallel or over time on behalf of the same garage (as in [Fig.4]) or on behalf of several garages (in which case several local devices 101 are implemented, connected to the remote device 201 by the network 210).

[0113] The remote operator has several manufacturer applications 102 which may come from the same manufacturer or from several different manufacturers, here three applications APP_A, APP_B and APP_C. For each application, a VCI interface is selected (step 13) allowing the loading of a respective binding DLL 204. In the illustrated example, the operator selects the VCI1 interface "service 1" via the application APP_A. As a result, the binding DLL "service 1" is loaded by APP_A. The Figure only illustrates the loaded binding DLLs and not the pre-installed ones (possibly more numerous) which are not used. Similarly, the operator selects the VCI2 interface "service 2" via the application APP_B, as a result, the binding DLL "service 2" is loaded by APP_B. Also, the operator selects the VCI3 interface "service 3" via the application APP_C, as a result, the binding DLL "service 3" is loaded by APP_C.

[0114] On the side of the local operator or local operators calling on the services of the remote operator, the link agent(s) 205 are launched. A choice of VCI interfaces to be used can be proposed to the local operator in a similar way to the choice in the vehicle diagnostic application 102, so as to allow the loading of the appropriate primary DLL 104 but also of the conversion module 205-1 adapted to the link DLL 205.

[0115] In the example of [Fig.4], the local operator launches three connection agents 205 to manage three VCI interfaces, VCI1, VCI2 and VCI3 at different times. Indeed, at a given time, the computer 101 is connected to a single VCI interface. The primary DLLs and modules 205-1 “service 1”, “service 2”, “service 3” are therefore loaded at three different times. Of course, these can be loaded simultaneously but on several host computers 101 (on the same site or on separate sites).

[0116] In one embodiment, the communication module 205-2 is common to several conversion modules 205-1 when these are instantiated. Also, the module 205-2 is able to route the received data frames to the instantiated conversion module 205-1.

[0117] Alternatively, each link software agent 205 has its own communication module 205-2.

[0118] [Fig. 5] schematically illustrates a hardware structure of a device 500 of the remote diagnostic system 200 according to the invention. Such a device may be the remote device 201, the local device 101 and / or the VCI interface 110.

[0119] The device 500 may be a portable device such as a smartphone, a digital tablet, a laptop, a personal assistant, or be a fixed device such as a desktop computer or an interactive terminal. More generally, any computer device capable of implementing the processing mentioned above may be used.

[0120] The device 500 comprises a communication bus 501 to which are preferably connected:

[0121] - one or more central processing units 502, such as one or more processors CPU and / or one or more processors or GPU graphics cards and / or one or more microprocessors;

[0122] - a storage memory 503, of the ROM and / or hard disk and / or memory type flash, for the storage of computer programs 509 intended to implement the invention but also of any data necessary for the execution of the programs, including DLLs;

[0123] - a random access memory 504, of the RAM or video RAM (VRAM) type, for storage executable code of computer programs as well as the registers adapted to record variables and parameters necessary for their execution;

[0124] - one or more communication interfaces 505 connected to an external network NET communication, typically the communication network 210, and / or to equipment, for example serial cable, RS-232, USB, Ethernet, IEEE1394, Bluetooth;

[0125] - one or more I / O inputs / outputs 506 allowing a user to interact directly with the 509 programs of the invention being executed. Typically, the inputs / outputs may include a screen serving as a graphical interface with the user and / or a keyboard or other pointing means allowing the user to initiate, for example, the execution of programs 509 and the selection of options and / or a speaker.

[0126] Preferably, the communication bus ensures communication and interoperability between the different elements included in the device or connected to it. The representation of the bus is not limiting and, in particular, the central unit can be used to communicate instructions to any element of the device directly or by means of another element of the computing device.

[0127] The executable code stored in memory may be received by means of the NET communication network, via the interface, in order to be stored there before execution. Alternatively, the executable code is not stored in non-volatile memory but may be loaded into volatile memory from a remote server via the NET communication network for direct execution. This is the case in particular for web applications (web apps).

[0128] The central unit is preferably adapted to control and direct the execution of the instructions or parts of software code of the program(s) according to the invention. When the power is switched on, the program(s) which are stored in non-volatile memory or on the remote server are transferred / loaded into the RAM, which then contains the executable code of the program(s), as well as registers for storing the variables and parameters necessary for implementing the invention.

[0129] In one embodiment, the processing operations according to the invention are carried out locally by the user device, preferably in real time or quasi-real time. In this case, the programs in memory implement all of the processing operations described below.

[0130] The NET communication network can be any wired or wireless computer network or a mobile telephone network allowing connection to a computer network such as the Internet.

[0131] The preceding examples are only embodiments of the invention which is not limited thereto.

Claims

Claims

1. Device (201) for remote vehicle diagnosis, comprising: - a communication interface with a communication network (210), and - a vehicle diagnostic application (102) compliant with one of the SAE J2534, ISO 22900-2 D-PDU and TMC RP 1210 standards and capable of communicating with a vehicle communication interface, VCI, by the use of a primary dynamic link library, DLL, associated with the VCI interface and compliant with said standard, said diagnostic application being configured to use an operating system (OS) registry (103) entry (103-i) in order to identify the primary DLL, the remote diagnostic device (201) comprising a link DLL (204) capable of routing, via the communication network, a data flow between said vehicle diagnostic application and a remote primary DLL (104) configured to communicate locally with a VCI interface (110) connected to the vehicle (111), said register entry being configured to identify the link DLL instead of the primary DLL associated with the VCI interface, the remote diagnostic device being characterized in that the link DLL (204) comprises a routing filter (204-1, 205-1) configured to determine, as a function of a filtering criterion, whether a message received for routing is to be deleted without routing it, said filtering criterion deleting a VBAT type message relating to a query on the battery level of the vehicle, of the FwVersion type relating to a query on the firmware version embedded in the VCI interface,of type DllVersion relating to a query on the version of the primary DLL and / or of type ApiVersion relating to a query on the API version implemented by the primary DLL.,

2. A vehicle remote diagnostic system (200), comprising: - a remote diagnostic device (201) connected to a communication network (210) and comprising a vehicle diagnostic application (102) compliant with one of the SAE J2534, ISO 22900-2 D-PDU and TMC standards

3. RP1210 and capable of communicating with a vehicle communication interface, VCI, by using a primary dynamic link library, DLL, associated with the VCI interface and conforming to said standard, said diagnostic application being configured to use an operating system (OS) registry (103) entry (103-i) to identify the primary DLL, and - a device (101) local to the vehicle, connected to the communication network and comprising a primary DLL (104) configured to communicate locally with a VCI interface (110) connected to a vehicle (111) to be diagnosed, the remote diagnostic device (201) comprising a link DLL (204) capable of routing, via the communication network and a link software agent (205) of the local device (101), a data flow between said vehicle diagnostic application and the primary DLL (104) of the device (101) local to the vehicle, said registry entry being configured to identify the link DLL instead of the primary DLL associated with the VCI interface, the system being characterized in that the link DLL (204) and / or the link software agent (205) comprises a routing filter (204-1, 205-1) configured to determine, according to a filtering criterion, whether a message received for routing is to be deleted without routing it, said filtering criterion deleting a VBAT type message relating to a query on the battery level of the vehicle, of the FwVersion type relating to a query on the firmware version embedded in the VCI interface,of type DllVersion relating to a query on the version of the primary DLL and / or of type ApiVersion relating to a query on the API version implemented by the primary DLL., The system (200) of claim 2, wherein the linking DLL (204) and / or the linking software agent (205) comprises a converter (204-1, 205-1) capable of encapsulating the data stream into one or more structured data frames or of de-encapsulating one or more structured data frames into said data stream, so as to exchange structured data frames over the communication network.

4. The system (200) of claim 3, wherein the converter encapsulates the data stream into a JavaScript Object Notation, JSON, format structure.

5. The system (200) of claim 3, wherein a VCI interface identifier is added to the structured data frame so as to route said frame to a primary DLL corresponding to said identifier among several primary DLLs accessible on the communication network.

6. System (200) according to one of claims 2 to 5, wherein the linking DLL (204) and the linking software agent (205) are configured to establish a web socket type communication channel between them, on the communication network (210).

7. The system (200) of any one of claims 2 to 6, wherein the routing filter is configured to determine a type of message routed recurrently and, in response, to configure said filtering criterion to delete any subsequent message of said type over at least a predefined period.

8. System (200) according to one of claims 2 to 7, in which the VCI interface (110) connected to the vehicle (111) forms a device separate from the local device (101).

9. The system (200) of claim 8, wherein the local device (101) includes a driver associated with the VCI interface (110) for routing data between the primary DLL (204) and the VCI interface (110) external to the local device.

10. System (200) according to one of claims 2 to 7, wherein the local device forms the VCI interface (110) connected to the vehicle.

11. Method for remote diagnosis of a vehicle, comprising, at a device (201) for remote diagnosis of a local device (101) to said vehicle (111), the following steps: - obtaining a vehicle diagnostic application (102) compliant with one of the SAE J2534, ISO 22900-2 D-PDU and TMC RP1210 standards and capable of communicating with a vehicle communication interface, VCI, by the use of a primary dynamic link library, DLL, associated with the VCI interface and compliant with said standard, said diagnostic application being configured to use a operating system (OS) registry (103) entry (103-i) to identify the primary DLL, - configuring the registry entry to identify, instead of the primary DLL associated with the VCI interface, a link DLL (204) capable of routing, via a communication network (210) and a link software agent (205) of the local device (101), a data flow between said vehicle diagnostic application and a remote primary DLL (104) configured to communicate locally with the VCI interface (110) connected to the vehicle (111), and - loading (15) the link DLL during an execution of the vehicle diagnostic application so that a diagnostic message generated by the vehicle diagnostic application is routed over the communication network to the remote primary DLL and the VCI interface connected to the vehicle, the method being characterized in that it comprises a routing filtering operation (204-1, 205-1) determining, as a function of a filtering criterion, whether a message received for routing by the link DLL (204) and / or the link software agent (205) is to be deleted without routing it, said filtering criterion deleting a message of type VBAT relating to a query on the battery level of the vehicle, of type FwVersion relating to a query on the firmware version embedded in the VCI interface, of type DllVersion relating to a query on the version of the primary DLL and / or of type ApiVersion relating to a query on the API version implemented by the primary DLL.

Images