FR3113150A1 - Formatting fault information by filtering - Google Patents

Abstract

The invention relates to a method and a device for formatting fault information from at least one computer included in a land motor vehicle. FIG. 1

Description

Formatting fault information by filtering

The present invention belongs to the field of on-board electronics in a land motor vehicle. In particular, it concerns the management of the transmission of frames comprising information on vehicle faults, the faults being identified by the vehicle's computers.

“Motor land vehicle” means any type of vehicle such as a motor vehicle, a moped, a motorcycle, a storage robot in a warehouse, etc.

“Information on a fault” means any type of data characterizing, for example, a state, a hardware, software or even functional error or even an operating parameter of a device, typically a sensor and/or an actuator, of the connected vehicle. to a calculator.

The evolution of electronics in today's motor vehicles has made it possible, in particular, since the advent and integration of so-called Over The Air connection technologies (wireless connection of the 3G/4G type, WIFI, etc.) to develop a multitude of functionalities grouped under the term connected services. These connected services, depending on the use that can be made of them, are subject to different constraints or regulations. We can cite, for example, without this being exhaustive, the general data protection regulation RGDP (respect for privacy) for personal services applicable in Europe, or the RMI regulation (Repair and Maintenance Information, information on repair and maintenance in French) relating to the repair and maintenance of a motor vehicle requiring the car manufacturer to make this type of information available without discrimination to any repairer in its own network or an independent network.

However, these regulations do not detail either the mechanisms that must be developed or the way to implement them in a vehicle to allow the development of the desired connected services while guaranteeing that these services cannot affect the primary performance of the vehicle during its use.

Most of today's car manufacturers already have connectivity systems built into their vehicles because the development of this type of service (connected services) is booming.

Data collection is usually carried out using a connectivity box. The connectivity box is also called TCU, Telematics control unit, for telematics control unit in French.

To do this, the connectivity box is connected to a multiplexed communication network that can be of different technologies (CAN, CAN FD, Flexray, Ethernet, etc.) and has a central memory allowing it to temporarily store data circulating its network. then to transmit them by wireless network (3G/4G, WIFI, …) to a server or a connected tool.

When designing a vehicle, the manufacturer sizes its architecture (choice of internal network technologies, digital resources of the computers) taking into account a price/performance balance. This often imposes a dimensioning of the resources according to the services required for the operation of the vehicle during its launch, but more difficultly takes into account connectivity needs that may appear in the series life of the vehicle in which new players not known at the time of the launch. initial design of the vehicle may offer new services to the customer and in fact require access to vehicle data.

A particularly interesting feature requested by many players in connected services is that of recovering faults that may have been detected and stored in a vehicle's computers. A computer is also called ECU, for electronic control unit, electronic control unit in French.

This functionality is of obvious interest in the context of a maintenance / repair service, but also for a manufacturer or a supplier with the aim of improving the quality of a product, or even a specific service offered by the insurers for example.

Fault information retrieval is a feature already used in repair garages. To obtain this fault information, an operator connects a diagnostic tool to the centralized regulatory socket (OBD socket SAEJ1962 compliant) and by means of a diagnostic request compliant with a communication protocol such as UDS (Unified Diagnostic Services: ISO14229) for example transmits the appropriate command to a computer of the vehicle and obtains in response the list of faults stored in this computer.

However, such a process is restrictive in that it requires in particular a passage to the garage.

Other wireless transmission methods, over the air, have been proposed to recover fault information. Such processes must take into account various constraints and in particular:

• the capacities (throughput, computing resources in particular) of the internal networks of the vehicle and of the devices present on these networks;
• the needs of these networks in certain situations, typically when the vehicle is running and particularly significant when the driving of the vehicle is automated.

Also, the designers of these processes are confronted with a trade-off between the costs of the networks/devices (high flow rates and computing resources are expensive) and the need to make the transmission of faults available in all situations (autonomous driving for example) .

In the case of cost optimization, the networks and devices present on the networks are sized as accurately as possible in terms of speed and computing resources. Therefore, the manufacturer must restrict the provision of fault information to specific situations where the vehicle is available without being overly strained (typically after the engine has been switched off, battery full, or when the vehicle, if it is electric , is in charge).

This is particularly restrictive and tends to limit the opening of fault information to service providers.

The present invention improves the situation.

To this end, a first aspect of the invention relates to a method for formatting fault information from at least one computer included on a land motor vehicle, the vehicle further comprising a connectivity box configured for the transmission and the reception of data respectively to and from at least one network external to the vehicle and comprising a processing box distinct from the computer and from the connectivity box, the method comprising, at the level of the processing box and when the vehicle is in operation, the steps of :

• reception from the computer of at least one frame comprising the fault information and of information on the state of the vehicle at the time of the detection of the fault;
• generation of at least one modified frame by filtering the status information in the received frame, the modified frame comprising the fault information;
• transmission to the connectivity box of the modified frame.

Such filtering advantageously reduces the size of the frame and therefore frees up bandwidth on the network in charge of transmitting the modified frame to the connectivity box.

In addition to reducing the congestion of the internal network located between the processing box and the connectivity box, the filtering further reduces the congestion of the input interfaces of the connectivity box. These interfaces indeed include buffer memories, buffer in English, quickly saturated if the size of the frames which are received there is not controlled.

“Fault information from at least one computer” is understood to mean any type of data characterizing, for example, a state, a hardware, software or even functional error or even an operating parameter of a device, typically a sensor and/or a actuator, of the vehicle connected to the computer. The fault may thus directly concern the computer and/or any sensor and/or actuator connected or even controlled by the computer.

In one embodiment, the filtered state information is encoded in three bytes.

In one embodiment, the modified frame further comprises a predetermined identifier configured to indicate to the connectivity box that it is a frame comprising fault information and to indicate to the connectivity box that the vehicle is in operation .

The deletion of the status information is particularly relevant when it is combined with the addition of the predetermined identifier, provided in the specific case of a feedback of fault information when the vehicle is running.

In addition, the stress on the internal networks on which these frames pass, received frame and modified frame, and the devices present on these networks, computers, processing device and connectivity box, is reduced to a minimum.

On the one hand, the computers only manage the feedback of fault information in frames, the frames received, in a format that is suitable for them. They do not need to manage requests, potentially concomitant, consuming additional digital resources according to a standardized protocol such as the UDS for the transmission of fault information. The UDS is Unified Diagnostic Services: ISO14229, for unified diagnostic services.

In addition, the processing box, separate from the connectivity box, can be located at a location closer, in terms of networks, to the computers because it is not subject to the same physical constraints (proximity to the antenna, cooling, etc.) than the connectivity box.

On the other hand, the use of the predetermined identifier avoids the saturation of the input interfaces of the connectivity box. Indeed, the connectivity box has several input interfaces, also called mailbox for mail box in French, very popular and whose number is limited, because directly linked to a number of physical components present on the printed circuit.

In one embodiment, the predetermined identifier is 11 encoded bits. In one embodiment, the predetermined identifier is encoded according to a non-extended CAN protocol.

The term "non-extended CAN protocol" means the CAN protocol, for Controller Area Network in English and control zone network in French, in which a message identifier is coded on 11 bits.

In one embodiment, the predetermined identifier is positioned on at least one bit of the modified frame having the greatest weight.

A second aspect of the invention relates to a computer program comprising instructions for implementing the method according to the first aspect of the invention, when these instructions are executed by a processor.

A third aspect of the invention relates to a processing box for formatting fault information received from at least one computer included on a land motor vehicle, the box comprising at least one processor and at least one memory arranged to perform , when the vehicle is in operation, the operations of:

• reception from the computer of at least one frame comprising the fault information and of information on the state of the vehicle at the time of the detection of the fault;
• generation of at least one modified frame by filtering the status information in the received frame, the modified frame comprising the fault information;
• transmission to the connectivity box of the modified frame.

A fourth aspect of the invention relates to a vehicle comprising the processing box according to the third aspect of the invention.

Other characteristics and advantages of the invention will appear on examination of the detailed description below, and of the appended drawings in which:

is a diagram illustrating the background of the invention according to one embodiment of the invention;

is a diagram illustrating the steps of a method according to one embodiment of the invention;

is a diagram illustrating frames according to one embodiment of the invention;

illustrates the structure of a device according to one embodiment of the invention.

The invention is described below in its non-limiting application to the case of a motor vehicle comprising a computer, a processing box and a connectivity box. Such an application is purely illustrative and reduced to a few components for the sake of clarity but, in practice, the invention is used by several tens or hundreds of components, computers in particular.

There illustrates a context of application of the invention, according to one embodiment.

A motor vehicle VEH comprises a computer CLCTR, a processing box BT and a connectivity box BC. In the terminology used by the applicant, the BC connectivity box is also called BSRF, for radio frequency easement box, and the BT processing box is also called BSI, for intelligent easement box.

BC, BT and CLCTR are connected by at least one internal network to the vehicle. Such a network is typically a CAN network, for Controller Area Network, and/or Ethernet. Several networks can be present, for example linked together by BT or BC.

BC is used to make the link with external networks accessible by radio frequency links. Such networks are for example a wifi network, 3G, 4G, 5G, sidelink PC5, bluetooth, etc.

Such external networks make the link between the vehicle VEH and an SRVR server. Such an SRVR itself acts as the interface between vehicles, for example from the same manufacturer, and service providers such as a maintenance service, insurance or even a mapping service.

There illustrates a method, according to one embodiment of the invention.

The method is implemented when the vehicle is in operation. In one embodiment, the vehicle is in operation when at least one engine of the vehicle is on (internal combustion engine running and/or electric motor in operation, for example). In another embodiment, the vehicle is in operation when the vehicle is moving.

At a step 10, the controller CLCTR detects a fault and generates fault information DTC. For example, a reversing camera controller detects that an obstacle is constantly detected, which is for example due to the presence of dirt (typically mud) on the sensor.

At a step 12, a frame FR(DTC) is transmitted by CLCTR to the processing unit BT. The format of the FR(DTC) frame is detailed below with reference to the . The FR(DTC) frame includes the DTC fault information.

Upon receipt of F _R (DTC), an acknowledgment message Ack is transmitted to CLCTR in a step 14.

At a step 16, F _R (DTC) is processed and a modified frame F _M (DTC) is generated. The detail of the processing and format of F _M (DTC) is detailed below with reference to the .

At a step 18, F _M (DTC) is transmitted to the connectivity box BC and an acknowledgment is sent to BT by BC on receipt of F _M (DTC) at a step 20.

F _R (DTC) can be temporarily stored by BT waiting for BC acknowledgment while BT processes another F _R (DTC) frame, if BT's temporary storage capacities are sufficient (more than one memory buffer) . If BT does not have sufficient temporary storage capacities, BT may decide not to receive and process other F _R (DTCs) and therefore no longer transmit acknowledgments to CLTCR.

At a step 22, F _M (DTC) is received by BC.

In one embodiment, BC then recovers the DTC fault information from F _M (DTC). BC then transmits by radio frequency, over the air, DTC, to the SRVR server. DTC is then stored by SRVR and transmitted to a service provider, registered with the server, SRVR at the request of said service provider. In one embodiment, DTC is automatically transmitted by SRVR when SRVR receives DTC from BC.

In one embodiment, BC stores DTC and waits to receive a request from SRVR and/or a service provider to transmit DTC.

Other information, such as a vehicle identifier, such as VIN for Vehicle Identification Number, can be added to DTC when sending to SRVR or the service provider.

The detail of the processing of FR(DTC) into FM(DTC) by BC is illustrated in the , according to one embodiment.

The processing described here with reference to the by BT is advantageously integrated into the DEH functionality, for Default Event History, or JDD Journal Des Faults, which consists in storing in addition to fault information a time of appearance or disappearance of these faults as well as the mileage of the vehicle at the when these failures appeared. This feature is interesting because it makes it possible to keep a trace between two revisions of the vehicle of a fault that may have been detected by the vehicle in a particular condition, sometimes with a customer feeling without this trace having been able to be kept in the memory. of the computer that performed this detection. A vehicle's computers do not store faults in memory when they have not reappeared for forty restarts (freeing of the dedicated memory).

F _R (DTC) comprises in detail at least two sub-frames F _R 1 and F _R 2 coded according to the CAN protocol. In one embodiment, a third subframe is comprised by F _R (DTC).

In the , several pieces of information are available, those on the left correspond to the frames received by BT and those on the right to the frames transmitted to BC.

In the left part in the first frame we find:

The ID information which corresponds to an 11-bit identifier number of the CAN frame making it possible to know the identity of the computer sending the DTC. This ID therefore carries the same value in frames 1 and 2.

The Hder parameter which represents the number of the frame so that the information receiver can know whether it is the first frame F _R 1 or the second FR2 of the same DTC.

The Dfault_cde parameter which represents the anomaly code, it adopts the coding format proposed by the UDS on three bytes.

The Date parameter, which corresponds to the value of a counter representing the date when the detection occurred.

In the second frame, which has the same ID as the first frame sent by this same computer, we also find the parameters:

Hder with a value different from that provided in the first frame of the event for this same parameter,

Mleage corresponding to the mileage of the vehicle memorized when the anomaly was detected.

Lfe_sition corresponding to the state of the vehicle at the time of DTC detection. Lfe_sition is coded on three bytes in F _R 2.

The transformation carried out by BT is represented on the right part of the :

To transmit DTC to BC received from CLCTR, BT adds a specific predetermined identifier represented by the element: "Identif". This is an 11-bit value (CAN protocol not extended) which will precisely allow BC to determine among all the frames it receives those which relate to fault events. Thus, the predetermined identifier is configured to indicate to the connectivity box that it is a frame comprising fault information and to indicate to the connectivity box that the vehicle is in operation.

So that BT can know the computer at the initiative of the DTC transmission, BT must collect the ID received and place it in the frame that it will transmit to BC.

It is also possible that the BT processing box itself has a fault. In this case, the ECU is the same as BT or it is a subcomponent of BT, and a specific ID is chosen by BT.

The Hder, Dfault_cde, Mleage and Date information will also be transmitted on different frame locations (bytes bx).

On the other hand, the Lfe_sition state information is filtered by BT in step 16. The Lfe_sition state information is therefore not present in the frame F _M (DTC) and its subframes F _M 1 and F _M 2. It is not useful to transmit Lfe_sition in particular because the identifier Identif makes it possible for BC, SRVR and/or the service provider to identify the situation of the vehicle, Identif being only added in the specific case where the vehicle is in operation.

Note that the Date information transmitted over 4 bytes in F _R 1 must be split into two and transmitted to BC in two separate frames (F _M 1 and F _M 2).

There represents an example of a device D included in the vehicle VEH or else in the server SRVR. This device D can be used as a centralized device in charge of at least certain steps of the method described above with reference to the . In one embodiment, it corresponds for example to CLCTR, BT and/or BC.

This device D can take the form of a box comprising printed circuits, of any type of computer or even of a smartphone.

The device D comprises a random access memory 1 for storing instructions for the implementation by a processor 2 of at least one step of the methods as described above. The device also comprises a mass memory 3 for storing data intended to be kept after the implementation of the method.

The device D may further comprise a digital signal processor (DSP) 4. This DSP 4 receives data to shape, demodulate and amplify, in a manner known per se, this data.

The device also comprises an input interface 5 for receiving data implemented by methods according to the invention and an output interface 6 for transmitting data implemented by the method.

The present invention is not limited to the embodiments described above by way of examples; it extends to other variants.

Thus, an embodiment corresponding to an exemplary electronic architecture has been described (a computer CLTR, a processing box BT, a connectivity box BC, etc.) for a motor vehicle. The present invention is also applicable to other electronic architectures (different number of computers, etc.).

Claims (9)

Method for formatting fault information from at least one computer (CLCTR; BT) included in a motorized land vehicle (VEH), the vehicle further comprising a connectivity box (BC) configured for transmission and reception of data respectively to and from at least one network external to the vehicle and comprising a processing box (BT) separate from the computer and from the connectivity box, the method comprising, at the level of the processing box and when the vehicle is in operation , the steps of:

• reception from the computer of at least one frame comprising the fault information and of information on the state of the vehicle at the time of the detection of the fault;
• generating (16) at least one modified frame by filtering the status information in the received frame, the modified frame including the fault information;
• transmission to the connectivity box of the modified frame.

Method according to claim 1, in which the filtered state information is coded on three bytes. Method according to one of the preceding claims, in which the modified frame further comprises a predetermined identifier configured to indicate to the connectivity box that it is a frame comprising fault information and to indicate to the connectivity box that the vehicle is in operation. A method according to claim 3, wherein the predetermined identifier is 11 bits. Method according to claim 4, in which the identifier is encoded according to a non-extended CAN protocol. Method according to one of Claims 3 to 5, in which the predetermined identifier is positioned on at least one bit of the modified frame having the greatest weight. Computer program comprising instructions for implementing the method according to any one of the preceding claims, when these instructions are executed by a processor (2). Processing box (D; BT) for formatting fault information received from at least one computer included on a land motor vehicle, the box comprising at least one processor and at least one memory arranged to perform, when the vehicle is in operation, the operations of:

• reception from the computer of at least one frame comprising the fault information and of information on the state of the vehicle at the time of the detection of the fault;
• generation of at least one modified frame by filtering the status information in the received frame, the modified frame comprising the fault information;
• transmission to the connectivity box of the modified frame.

Land motor vehicle comprising the processing box according to claim 8.