FIELD OF THE INVENTION

The present invention concerns diagnostics and repairs on vehicles and aims to improve correct identification of vehicles to be diagnosed and repaired.

BACKGROUND OF THE INVENTION

In order to communicate with a vehicle network through diagnostic services e.g. with an OBD (On Board Diagnostics) diagnostic tool or telematic devices such as on-board fleet management devices or OBD dongles, it is necessary to determ ine/select accurately the type of the vehicle to communicate with. Historically the first OBD diagnostic tools were only proposing a manual vehicle selection by the end-user. With the almost exponential multiplication of the vehicle models and system variants, OBD tool users have been appealed by automatic identification methods in these tools and such function became an important selection factor during the purchase of a diagnostic tool.

There are multiple techniques developed by OBD diagnostic tools manufacturers to automatically identify the vehicle model and variant to which the tool is connected. They generally all bear either on partial manual vehicle selection or input made by the user or on non-standard commands sent blindly to the vehicle when the use of standard (SAE J1979 or ISO15031 -5) commands is not sufficient.

In some cases, especially those for which the VIN number cannot be read through SAE J1979 or ISO15031 -5 communication, it is needed for the end user to make a partial vehicle selection manually before initiating the automatic identification process.

Instead or in addition to a partial manual selection, some manufacturers of equipments connected to the OBD plug make the choice to send blindly a set of commands through the OBD port and to analyse the received responses, if any, to try to determine the vehicle model. This method has two drawbacks:

- Sending non-standard commands to a vehicle that is not designed to process these commands may lead to unexpected result such as Warning lamp or message on the dashboard, faults logged in ECU and may even cause damages to the vehicle;

- Some vehicles of different types (different brand of a same group or model or variant) may provide responses which does not allow complete identification to the same command which may lead to inaccurate vehicle selection.

With respect to telematics devices the issue is also to recognize the vehicle type before proceeding to communication or extraction of data.

SUMMARY OF THE INVENTION

The present invention is an alternative of these two techniques with less drawbacks and better performance. Instead of actively communicating with systems over standard and/or VM specific communications lines and protocols, the principle of the invention is to passively listen to standard communication lines (e.g. as per SAE J1962 I ISO15031 -3) on vehicles OBD plugs to obtain information about the vehicle type.

More precisely, the present invention proposes a process of identifying a model and/or platform and/or brand of a vehicle through:

- connecting a vehicle identification device, having at least one vehicle communication interface, on at least one OBD plug of an OBD line of a tested vehicle, said vehicle identification device being associated with a first database of stored communication patterns corresponding to a list of models and/or platforms and/or brands of vehicles,

- listening to on line communication on the OBD port to detect data frames emitted by or between systems of said tested vehicle on said at least one communication line,

- extracting messages of said tested vehicle from said data frames,

- comparing said messages of said tested vehicle with stored messages within stored communication patterns in said first database to identify messages of the vehicle corresponding to messages of said stored communication patterns and,

- providing identification data of model and/or platform and/or brand of said tested vehicle when said messages of said vehicle are recognized as corresponding to a known communication pattern of at least one of said vehicles and/or platforms and/or brands of vehicles.

This process that uses passive listening as a first approach eliminates the risk to create unexpected fault on a vehicle as it does not send unexpected messages on the OBD bus.

In realization modes:

The former steps may be repeated to improve correspondence with said communication patterns in case match is found but the communication pattern is not complete.

In case no match is found between a specified number of extracted messages and messages in stored communication patterns or in case no match is found after a specified duration of listening, extracting and comparing, a process of refining vehicle identification may be initiated.

This permits to have a first selection of vehicles and refine the identification.

The process may comprise introducing a manual identification of the vehicle together with extracted message communication patterns in said first database to update said first database and reference said tested vehicle in said first database in case identification is possible.

This permits to enrich the tool with new vehicles.

In case vehicle identification is not complete or several vehicles correspond to a single pattern then the procedure of refining vehicle identification may be initiated.

This renders easier a further manual vehicle selection or even eliminate the need for manual selection.

The patterns may comprise identified messages with identifier data, data length, periodicity, and said comparing said message of said tested vehicle with stored messages within stored communication patterns in said first database may comprise comparing at least said identifier data, data length, periodicity to identify messages of the tested vehicle. In case the vehicle identification device comprises a second database comprising query messages for receiving VIN data associated with at least a group of models and/or platforms and/or brands of vehicles of said list and said vehicle identification device comprising means for emitting said query messages on said OBD plug communication line, the process may comprise emitting said query messages for receiving VIN data for a partially identified vehicle of said group by said vehicle identification device and providing a complete identification of the model of the vehicle based on said VIN data.

This provides identification based on the VIN data without the risk of sending non-recognized messages on the OBD bus of the vehicle.

In case said vehicle identification device comprises a communication port to the internet, said providing a complete identification of the model of the vehicle based on said VIN data may comprise connecting to a VIN decoding service provider and obtaining data from said VIN decoding service provider based on said VIN number or part of said VIN number.

The first database may comprise at least for some vehicles, vehicle data comprising vehicle VIN data, manufacturer group, brand, model year, and said process may comprise processing or displaying said data of an identified vehicle by said vehicle identification device.

This provides essential information to the user.

Said first database may comprise further vehicles identification parameters such as aftersales cataloging vehicle identification number or engine type and said process may comprise using said parameters by said vehicle identification device to provide additional information for repairing the vehicle or ordering repair parts.

The invention concerns further a vehicle identification device of a computerized type comprising a vehicle communication interface on at least one OBD plug of a vehicle, a communication port to the internet, storage means for said first database and calculation means comprising software configured for carrying out the process of the invention.

In case the vehicle identification device is embedded in a diagnostic tool or linked to a diagnostic tool, such diagnostic tool may comprise further a user interface and a diagnostic module for providing diagnostics on said vehicle.

The invention concerns also a software comprising instruction for carrying out all or part of the process when such program is executed by a computerized system and a non-transitory storage media such as CD ROM, DVD ROM, USB memory stick, ROM, hard disk, SSD or any other nonvolatile memory device, readable by a computerized system on which the program is recorded.

BRIEF DESCRIPTION OF THE DRAWINGS

A detailed description of exemplary embodiments of the invention will be discussed hereunder in reference to the attached drawings where:

Figure 1 : is an exemplary flowchart of an identification method of the present disclosure;

Figure 2: is a detail of part of the flowchart of figure 1 ;

Figure 3: is an exemplary extract of communication on a diagnostic port of a vehicle;

Figure 4A: is a list of messages seen on a first vehicle diagnostic port;

Figure 4B: is a list of messages seen on a second vehicle diagnostic port;

Figure 5: is an example of data organization in a first database of communication patterns and vehicles;

Figure 6: is a schematic of a diagnostic tool according to the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The present invention concerns an identification process for vehicles based on the detection of specific signature of the vehicle in messages exchanges over a vehicle communication network accessible through the OBD port of the vehicle.

On all modern vehicles, the systems fitted on the vehicle continuously exchange data between each other over vehicle communications networks (most commonly CAN, but other technologies are used such as LIN, flexray etc..).

The exchanged data is defined in message sets specific to a vehicle model or platform. Most of the messages defined in the message sets are sent periodically and some other messages are sent “on-event”.

A message set being specific to a model or a platform, knowing the message set present on the OBD communication port of a vehicle allows deducing from it at least the brand and model or platform of this vehicle.

Vehicle networks are often accessible through the standard lines of OBD port (as per J1962 I ISO15031 -3), it is therefore possible to listen to the communications on these vehicle networks and get an overview of part of the message sets used by the vehicle and detect communication patterns which such as fingerprints are unique to a vehicle or group of vehicles. In figure 3 is an example of communication data recorded on the standard CAN OBD2 pin contacts 6 and 14 of an OBD port of a vehicle.

The structure of the data exchanged are normalized in communication protocols such as CAN protocol or others comprises a frame Id 20, a data length 21 for such frame and data 31 of the frame 41 . A plurality of data frames 40 may be emitted on the bus depending on the status of the vehicle, locked, contact on, motor on, such plurality of data frames defining communication patterns.

Figure 4A shows an example of communication pattern 50 comprising frames emitted for a vehicle A and figure 4B shows a communication pattern 51 comprising frames emitted for a vehicle B and it can be seen that IDs 20a, 20b correspond to different length 21 a, 21 b, periodicity 22a, 22b and count 23a, 23b in a time of record of the OBD data.

When developing OBD diagnostic applications or other applications such as vehicle parameters survey on the vehicle identification device, it is then possible to record the messages exchanged on the OBD bus of the vehicle, this providing communication patterns of vehicles which may be added to a database of stored vehicles communication patterns which can be seen as a database of “known vehicle fingerprints”.

This permits to associate the vehicle identification device with a first database of stored communication patterns 50, 51 , ... corresponding to a list of models and/or platforms and/or brands of vehicles. In such database some frames may be common for several vehicles and the communication patterns are distributed within the database.

In case several vehicles share a same communication pattern, identification of the communication pattern may permit to detect at least a group of said vehicles and/or platforms and/or brands of vehicles thus providing to the user a partial identification which can be refined more easily.

As shown in figure 5, the first database can link data frames with vehicles. In such example, Hexadecimal Id 20 of data frames, their length 21 , periodicity 22, count 23 are linked to vehicles and are recorded in the first database. The vehicles being referenced as group 24 which is the manufacturer group company, brand, the vehicle brand 25, model 26, year of manufacturing 27, vehicle identification number and if needed other identification parameters such as aftersales cataloging vehicle identification number 29 or engine type number 30.

In such first database, various messages are recorded and correspondence between vehicles and a group of messages can be obtained. As a same frame may be found in several vehicles, the identification process will need several frames to provide the pattern of frames of the vehicle to complete identification.

Therefore, when obtaining a communication pattern exchanged on the OBD bus of a vehicle under test, it is possible to compare the frames emitted by a vehicle with the communication patterns 50, 51 , ... stored in the first database or “known vehicles fingerprint database” and obtain either a unique vehicle model or a list of probable vehicle models matching this fingerprint/communication pattern.

When identification of a unique type of vehicle cannot be obtained (e.g. several vehicles share identical patterns), the vehicle selection can then eventually be complemented/refined by using commonly used techniques based on active communication with the vehicle systems. This may be based on Requests/Responses using commands adapted in view of the partial identification already obtained and user manual selection and/or input. Since passive listening is used, it is possible to start the vehicle identification process as soon as the vehicle communication interface is plugged on the OBD port of the vehicle without user action, so that when the user opens the diagnostic software user interface and message frames are extracted on the communication link, at least a preliminary identification can be provided.

If the communication pattern already corresponds to a unique vehicle in the first database, the right vehicle selection is instantaneously and automatically made.

In case of a vehicle does not provide sufficiently identifiable frames when its systems are asleep, the operator can be invited to realize additional actions such as ignition on or engine start to obtain a more complete frame pattern.

In figure 1 , the process then starts with 10 connecting the vehicle identification device 1 represented schematically in figure 6, having its vehicle communication interface 2, on the OBD plug 61 of a tested vehicle 60.

The tool then listens in step 100 of figure 1 to communication on the OBD bus to detect data frames, such as 40 in figure 3, emitted by or between systems of said tested vehicle on said at least one communication line,

From these frames, the tool extracts in step 105 of figure 1 messages 41 of said tested vehicle from said data frames 40,

The tool then compares in step 110 said messages of said tested vehicle with stored messages within stored communication patterns in said first database 4 which can be embedded in the tool or remote to identify messages of the vehicle corresponding to messages of said stored communication patterns. The tool then provides identification data 135 of the type/model and/or platform and/or brand of said tested vehicle when said messages of said vehicle are recognized as corresponding to a communication pattern of at least one of said vehicles and/or platforms and/or brands of vehicles. This can be repeated e.g. with additional actions from the operator such as ignition on, engine start or other actions required by the vehicle identification device to detect other frames to refine identification.

If a match is found at test 120 but if the match doesn’t allow accurate identification or is not complete at test 130, the sequence is repeated.

If no match is found at test 120 and no match is found in step 190 after a defined duration, a process of refining identification 150 may be initiated. Otherwise the sequence is repeated.

If the communication pattern is complete in test 130, then vehicle identification 135 is tested to check whether a single vehicle matches with a single vehicle first database pattern. If the identification of a single vehicle is not complete or is not possible at test 140, then the procedure of refining vehicle identification 150 is initiated.

This identification may use the VIN Vehicle Identification Number or a part thereof which provides the necessary information to determine the exact type of vehicle. It should be noted that serial number data in the VIN number may not be retrieved for confidential personal information protection.

This procedure exemplified in figure 2 may comprise checking at 300 if a VIN query message can be found in the additional or second database 4’. If the VIN query message for the model or brand is found, the VIN query message is sent in step 305, the VIN is received and through a connection to a VIN decoding service which can be handled by an external VIN service provider 320 the vehicle information data is obtained 330 and displayed 180 on the tool to process diagnostics 400.

When the VIN decoding service is external, said vehicle identification device 1 comprising a communication port 3 to the internet 500 e.g. through radio telecommunication, such as GSM, 3G, 4G, 5G, or Wifi or wired, providing a complete identification of the model of the vehicle based on said VIN data can be done through connecting to an external provider which provides VIN description services and obtaining data from said external provider based on said VIN number.

If the VIN query cannot be found, manual selection of the vehicle 170 by the user is initiated. Back to figure 1 , when identification of a new vehicle is done, either with assisted or manual selection, the vehicle together with its extracted message communication pattern is introduced in the first database at step 200 to update said database and reference said new vehicle in said database.

The first database 4 may also comprise at least for some vehicles, vehicle data comprising vehicle VIN number 28 possibly without the vehicle serial number as discussed earlier, manufacturer group 24, brand 25, model, year 27. The process may then comprise displaying said VIN number 28, manufacturer group 24, brand 25, model, year 27 of an identified vehicle by said vehicle identification device if such is provided with a display or a tool embedding such.

When the vehicle identification device is used with a diagnostic tool or used within a diagnostic process, the first database may comprise further additional identification parameters such as aftersales cataloging vehicle identification number 29 or engine type number 30.

In such case a diagnostic process may use such additional identification parameters for diagnostic or repair purposes such as ordering repair parts.

The vehicle identification device 1 as exemplified in figure 6 is of a computer type comprising a vehicle communication interface 2, on at least one OBD plug, an internet communication port 3, storage means for the first database 4 and possibly a second database 4’ of VIN queries and calculation means with a processor board 7, memory 8 including nonvolatile memory for storing programs including said process and volatile memory as found in computerized systems and comprises the necessary software for carrying out the process of the invention.

In case the vehicle identification device is part of a diagnostic tool such as workshop computerized diagnostic tool or a fleet management tool it may comprise a user interface such as screen 5 and keyboard 6 and a diagnostic or data treatment module 9.

The invention which was described hereabove mainly in the frame of providing diagnostics on a vehicle may also be used in a telematics device such as used in fleet management to record or transmit vehicle data I I to a remote server or other applications. The invention is not limited to the above description and in example, the device and process may comprise additional features related to vehicle diagnosis such as additional databases and diagnostic processes and the internet communication port may be of any type such as wired, WIFI, GSM or any other telecom radio protocols.

List of references:

1 - Vehicle identification device

2 - communication interface

3 - communication port

4 - first database

5 - screen

6 - keyboard

7- processor board

8 - memory

9 - diagnostic module

20, 21 a, 21 b - Hex ID

21 ,21 a, 21 b - length

22, 22a, 22b - periodicity

23, 23a, 23b - count

31 - Data

40 - data frames

41 - message

50, 51 - communication patterns

60 - vehicle

61 - OBD plug