FIELD OF THE INVENTION

The present invention relates to methods to write requests on a vehicle diagnosis bus. This kind of method is used by a diagnosis plug-in device designed and configured to collect various static and dynamic data on rolling vehicles and to transmit this data wirelessly to one or more remote server(s). Such diagnosis plug-in device (otherwise called OBD plug-in device) is coupled to the diagnose plug port/connector of the vehicle and collect various static and dynamic data from onboard ECUs (Electronic Control Unit) by the use of request/answers services.

BACKGROUND OF THE DISCLOSURE

There is an increasing need to collect information about motor vehicles, either for fleet management, insurance personalized charge policy, traffic jam management, or other purposes.

One popular solution to remotely collect and transmit various data like vehicle speed, fuel consumption, vehicle geolocation, etc., is to add a plug-in device that can be plugged into the OBD plug (sometimes called OBDII plug/port/connector or Diagnose plug port/connector which form a communication interface). The diagnosis plug-in device (‘Diag plug in Device in short) is sometimes called ‘Dongle’ or ‘dongle unit’. The desired data is collected using messages on a serial bus (often CAN bus or J1850 or J1708 or Ethernet or sometimes K-line). Each vehicle manufacturer has its own messages definition. Practically, even each technical platform have its own messages definition (several commercial variants may be derived from one technical platform).

A subset of services (question/answers) is defined by a OBD standard ISO 15031. This minimal subset originates from pollution monitoring purposes. Additional services may be available in the standard or Out of the standard.

These services are used in garage/maintenance environment by a device called “diagnosis tool” otherwise called “Scan Tool”. In most cases, the diagnosis tool is used when the vehicle is at null speed, i.e. in a repair shop. Such diagnosis tool is plugged momentarily only.

According to another standpoint, the multiplex bus system is a success and recently bus loads has undergone a trend to increase a lot. In many configurations, particularly the up-to-date configurations, the bus used by the diagnosis tool to access onboard ECUs is a bus where prevail many free running frames broadcasted by various onboard ECUs whenever they are active. This free running broadcasted frames represent a significant load on the bus.

Practically, CAN bus is the foremost bus serving as diagnosis bus, whereas other types of bus are also used.

However, it is admitted that a load of 50% for CAN bus is the limit beyond which collision rate become significant and can entail delays in the transmission of some messages.

Therefore, when using a diagnosis plug-in device to retrieve data on the diagnosis bus, notably if this requires to use request/answer services, this tends to increase the bus load of the diagnosis bus. The inventors have endeavored to mitigate this effect, which is the purpose of the present disclosure.

SUMMARY OF THE DISCLOSURE

According to one aspect of the present invention, it is disclosed a method carried out in a system, the system comprising at least a diagnosis plug-in device (1) a host server (2), one or more on-board ECUs (3), the method comprising the following steps:

/a/ detect a Bus Active condition, either via an electrical pin on the diagnosis plug (‘Key On’) or via an analysis of activity level on at least one Diagnosis bus accessible at the diagnosis plug,

/b/ cause the diagnosis plug-in device to listen only on the at least one Diagnosis bus after the Bus Active condition is detected, namely in a passive mode,

/c/ determine a write enable condition, according to evolution of bus load level (on the diagnosis bus) and/or after a certain time elapsed since Bus Active condition was true,

/e/ whenever the write enable condition becomes true, carry out the request/answer services to write requests on the diagnosis bus and retrieve, in the corresponding answers, various data from the board ECUs (3), to be decoded and forwarded to a client fleet management system.

Thanks to these dispositions, messages broadcasted from the board ECUs are not disturbed by the presence of the diagnosis plug-in device which remains mute during a certain time after activation of the bus. There may be some initialization processes between different ECUs that take place just after bus activation, and these initialization processes needs not be disturbed by extraneous request services that might placed on the bus by some diagnosis plug-in device.

In various embodiments of the invention, one may possibly have recourse in addition to one and/or other of the following arrangements.

According to one particular option, the method may further comprise:

/e1/ determining, on a short term basis, a cyclic pattern of messages circulating on the bus, with at least busy instants and quiet instants

/e2/ place write requests on the diagnosis bus at quiet instants, preferably only at quiet instants and not at busy instants.

Advantageously, a short term analysis of messages circulating in the bus leads to the determination of short term cyclic pattern; thus, the normal operation of the bus used for diagnosis is not disturbed by the request/answers carried out by the diagnosis plug-in device; said otherwise the rate of collisions is not increased despite the additional requests/answers emanating from the diagnosis plug-in device.

According to one particular option, the method may be such that, at step /e/ and/or at step /e1/ and /e2/,

request/answer services are carried out with a strategy which is contextual to current speed of the vehicle.

Thus, write enable condition can be set according to context; slowing down or disabling write when vehicle speed >50 Km/h; slowing down write rate as long as the vehicle speed increases;

According to one particular option, the method may further comprise:

/d1/ determining vehicle type, and defining therefrom a firewall filter, said firewall filter being subsequently used at step /e/ to inhibit certain request/answer services.

Thereby, according to the relevant vehicle type(s), some request(s), which are known to be detrimental to the proper operation of the bus (or detrimental to the proper operation of some functions vehicle), are not used and eliminated by the firewall filter.

According to one particular option, the method may further comprise:

/d2/ determine vehicle type, wherein the write enable condition is disabled for certain particular vehicle type.

Vehicle with known problem are handled by a listen-only mode, or only at null speed. Ineligibility to write requests can be declared according to VIN or vehicle type.

According to one particular option, the method may further comprise:

/d3/ determine vehicle type, namely Make/Model/Year/Powertrain,

/d4/ provide a database of overall bus load reference overall timecharts per vehicle type, each timechart exhibiting eras of low bus load and eras of high bus load,

/d5/ write requests at moments when the bus load is of low bus load;

High and low bus load eras are known “in advance” on a microscopic basis; thereby there is no need to proceed to real time analysis.

thereby there is no need to ‘manual’ input of vehicle type, automatic recognition of vehicle type is done.

Advantageously the normal operation of the bus used for diagnosis is not disturbed by the request/answers carried out by the diagnosis plug-in device; said otherwise the rate of collisions is not increased despite the additional request answer from the diagnosis plug-in device. Time charts are established beforehand; there is less need to monitor or short-term cyclic patterns in that case.

According to one particular option, the step of determining vehicle type is made either from a VIN retrieved from the bus and/or from a frame profile determined according to characteristics of the received frame-IDs on the diagnosis bus;

When the VIN is easily accessible, vehicle type is easy to determine; however, even though VIN is not available, the diagnosis plug-in device can correctly handle communication with the available request/answer services.

According to one option, the diagnosis bus of interest is a CAN-type bus, at a bit rate of 250 kbits/s or 500 kbits/s.

CAN-type bus tends to be standard, with an increasing number of messages circulating on the bus, with a busload generally comprised between 10% and 50%.

According to another option the diagnosis bus of interest can be FDCAN or Ethernet.

According to one option, the method may be such that the write enable condition is set to be true after a first period of time since Bus Active condition was true, and the first period of time DT1is predefined and comprised between 1 s and 20 s, preferably between 3 s and 10 s.

Determining the frame profile by listening on the CAN bus requires few time.

According to one option, the method may be such that a Bus Active condition is determined to be true when, on at least one accessible bus, a mean number of frames per time unit increases more than a first predefined threshold.

This method enables to recognize the activation of the diagnosis bus, irrespective of electrical conditions and irrespective of various functional sequences, and irrespective of powertrain type (electric, hybri . . . ).

According to a further option, the method may be such that a Bus Active condition is determined to become false, wherein a mean number of frames per time unit is lower than a second predefined threshold. Therefore, the diagnosis plug-in device can stop placing write requests as soon as the bus is shutdown, including if the engine control unit is operating under Power latch phase after the engine has been stopped.

The present invention also targets a OBD plug in device, configured to carry out the method set out above.

The present invention also targets a system, including the OBD plug in device, the host server configured to carry out the method set out above.

