Patent Description:
In the context of vehicle control units programming, a so called "diagnostic tool" is generally used, i.e. a computer comprising interface means compatible with a vehicle network to which the control unit is operationally associated, as shown in <NPL>) ; and <CIT>. Typically, the OBD/OBD2 socket is used to connect the diagnostic tool to the vehicle network.

The diagnostic tool, generally supplied to workshops, for simplicity "tool", performs some fundamental operations, including checking the compatibility between the application file previously stored in a static memory of the tool and the hardware of the control unit to be transferred to.

The application file consists of an executable portion, hereinafter referred to as application and a relative header hereinafter referred to as AAH by the acronym "App Admin header".

Some information is contained in a further header called "Textual Header for Diagnostics Tool" hereinafter referred to as THDT for convenience. This header, together with the application file defines the so-called "package".

The THDT contains a number of instructions. An instruction indicates the portion (Appfile) of the file (PackApp) to be loaded, the memory address of the control unit to be written and any commands that the tool must execute or submit to the control unit via UDS communication protocol acronym of "Unified Diagnostic Services "(Unified diagnostic services) used in vehicle control units in accordance with the ISO <NUM>-<NUM> standard.

The package (PackApp) stored in the tool memory, therefore includes the aforementioned THDT header and the application file(s) (Appfile) to be loaded, but the THDT header, unlike the application file, is not loaded into the control unit, as it relates solely to the transfer instructions.

The application file is generally in hexadecimal format (HEX) and in the AAH is stored.

The package containing TDHT + AAH + application is generally formatted in hx2 format or another equivalent format. The "+" symbols indicate data queuing.

The tool, therefore, is configured to read the information contained in both THDT and AAH, to interrogate the vehicle control unit using the UDS protocol and to verify the compatibility between hardware and software and the integrity of the application file and if the checks are positive it proceeds to transfer the application file in accordance with THDT instructions.

During the transfer, the tool issues commands to the ECU (boot loader) about, for example, the non-volatile memory allocation in which the application file must be written. Data transfer takes a very long time due to the intrinsic characteristics of vehicular CAN networks. Although vehicle processing units, nowadays, have large computing capabilities, the transfer of these application files can take up to <NUM> minutes or more.

It is evident that the greater the transfer time, the greater the probability that an external disturbance could lead to the failure of the loading procedure itself with the risk of the control unit damage.

The UDS protocol provides for the transfer of compressed files, but this is not useful, since, by compressing the application file, the tool can no longer perform the aforementioned compatibility checks, which are essential for safeguarding the integrity of the vehicle control units.

On the other hand, such a long data transfer time is not acceptable, both during the maintenance of a vehicle, and especially along with the production chain of the same vehicle. If not specifically excluded in the detailed description that follows, what is described in this chapter is to be considered as an integral part of the detailed description.

The object of the present invention is to make the transfer of application files faster without sacrificing the safety conferred by the known loading systems described above.

The basic idea of the present invention is.

The THDT is built in such a way as to instruct the vehicle ECU to write the AAH and the decompressed application sequentially in the non-volatile memory of the same and so as to check the CRC at the end of the of both writings. In other words, it is selectively compressed a part of the package and prevented the tool from verifying the integrity of the application file through CRC. This fact implies that the THDT is configured to indicate the separate transfer of the AAH and the application, specifying that the application is compressed, and making sure that once written in the non-volatile memory of the vehicle ECU, the AAH and its decompressed application are written consequentially. Thus, the control unit can verify the CRC of the entire application file in a transparent way with respect to the compression/decompression procedures.

In other words, until decompression, AAH and application are treated as two separate data streams, while the original application file is recomposed after its writing in the non-volatile memory of the vehicle ECU.

Advantageously, the loading times of the application file are reduced even by <NUM>% with a considerable saving of time and a significant reduction in the risk of corruption of the transferred file.

Preferably, the application is previously converted into binary format before being compressed, therefore, the vehicle control unit, after decompressing the application, reconverts it to hexadecimal format.

Further objects and advantages of the present invention will become clear from the following detailed description of an example of its embodiments (and its variants) and from the annexed drawings given purely by way of nonlimiting explanation, in which:.

It is worth pointing out that some steps of the diagram of <FIG> are performed by a first processing unit while other steps are performed by at least a second processing unit.

It should also be noted that the terms "first", "second", "third", "upper", "lower" and the like can be used here to distinguish various elements. These terms do not imply a spatial, sequential or hierarchical order for the modified elements unless it is specifically indicated or inferred from the text.

The elements and features illustrated in the various preferred embodiments, including the drawings, can be combined with each other without however departing from the scope of the present application as described below.

<FIG> represents the hardware infrastructure generally used to transfer an application file to a vehicle ECU. This comprises processing means, a static memory SM1, i.e. non-volatile, in addition obviously to a volatile memory (RAM) not indicated and interface means NI1, generally of the CAN or LIN type.

The diagnostic tool, Tool, also includes processing means, an SM2 static memory in addition to volatile memory and a NI2 network interface that allows the tool to interface with the vehicle ECU through, for example, the OBD socket of the vehicle data network.

Although the vehicle control unit is indicated with the initials ECU generally to indicate the engine control units, this can be any on-board processing unit, such as, for example, the so-called VCU vehicle control unit, etc. As known, the tool can perform various operations, from reading the faults stored in the ECU to programming the control unit itself. The control unit is generally equipped with a so-called boot loader, that is a firmware which, when the control unit is turned on, loads the operating instructions from the static memory SM1 into the volatile memory of the same. The application file containing these instructions is indicated with Appfile and includes an Application portion containing the instructions themselves and a relative first header AAH, see <FIG>, containing at least one field indicating a CRC value necessary to check the integrity of the application file before and/or after its transfer from SM2 memory to SM1 memory. The first heading AAH, see <FIG>, generally also includes a second HWver field necessary to contain a value indicating a hardware and/or boot loader version of the vehicle ECU to which the application file is intended. Generally, but not necessarily, the application file is encapsulated in a so-called package, here called PackApp, see <FIG> and <FIG>, which includes a second header THDT which contains the necessary instructions during the transfer of the application file from the tool to the vehicle control unit.

A typical containing instruction in the THDT is formatted as follows:.

<FIG> shows the field Instruction1 which indicates an instruction intended for the diagnostic tool that manages the control unit subject of the transfer.

According to the present invention, schematized with the help of <FIG>, the application file, whose CRC refers to the integrity of the entire application file, is broken up into header and application portion and the application portion is compressed (Step <NUM>), with a possible prior conversion (Step <NUM>) from hexadecimal to binary format, thus obtaining a modified application file Appfile*, where the header is unaltered, but the application portion is compressed.

Compression is performed by a lossless algorithm, preferably LZMA.

The package is now further modified so that the transfer does not concern the entire modified application file Appfile* but its distinct portions AAH and Application*.

In this way, there are two essential advantages:.

In addition, in the fields Instruction1, Instruction2 are made so that the writing of AAH and Appfile takes place in consecutive memory allocations of the vehicle ECU so that for the control unit the segmentation of the application file and its writing at several times is transparent.

Thus, once written, the control unit can verify its integrity using the relating CRC.

As mentioned above, the presence of the second header THTD essentially depends on the diagnostic tool. In fact, the tool can itself be configured, by means of its firmware, to manipulate the application file from Appfile to Appfile* and manage the separate transfer of the AAH and Application* portions.

As illustrated, the present invention relates to a method for generating an application file containing instructions for a vehicle control unit. The application file (Appfile) includes a first header (AAH) comprising at least one field showing a CRC value calculated on the entire application file, an executable portion (Application), the method comprising a step (Step <NUM>) to generate a modified application file (Appfile*) comprising said first header (AAH), unaltered, and the executable portion (Application*) compressed by means of a lossless compression algorithm. Preferably, when the application file is in hexadecimal format then the generation of the modified application file comprises the preliminary step (Step <NUM>) of converting only the executable portion of the file (Application) into binary format.

The invention also relates to a method of generating an application package (PackApp*) for a diagnostic tool (TOOL) configured to verify the compatibility (Step Y) of the application package with the vehicle control unit. The method comprises a second step (Step <NUM>) to put before said modified application file (Appfile*), according to the above, a second header (THTD*) containing instructions to cause.

The invention, with reference to <FIG>, also concerns a method for transferring an application file to a vehicle control unit using a diagnostic tool. The application file (Appfile), as described above, includes.

The method further includes the step (Step <NUM>) of verifying the integrity of the application file written in the non-volatile memory (SM1) of the vehicle control unit (ECU) by the vehicle control unit itself using said CRC.

Preferably, it is expected to cause the diagnostic tool to be inhibited, at least temporarily, by verifying the integrity of the modified application file (Appfile*) using said CRC. This inhibition can for example be controlled by means of a field contained in the THTD.

The present invention also relates to a system suitable for autonomously analysing an application file and automatically manipulating it as described above, in order to compress only the application portion.

The present invention also relates to a diagnostic tool containing, in a relative static memory SM2, an application file manipulated according to the present invention.

Furthermore, the present invention also relates to a memory medium containing an application file, which when executed by a vehicle control unit, causes the separate transfer (Step <NUM>) of a first data stream (AHH) in uncompressed format containing a value of CRC and a second compressed data stream (Application*) and the storage (Step <NUM>) of the second data stream, previously decompressed (Step <NUM>) by the vehicle control unit, in a first non-volatile memory (SM1) of the vehicle control unit, consecutively to said first data flow so as to define an application file (Appfile) and the verification (Step <NUM>) of the integrity of the application file written in the memory (SM1) by means of said CRC value.

The present invention can be advantageously realized by means of a computer program which comprises coding means for carrying out one or more steps of the method, when this program is executed on a computer. Therefore it is intended that the scope of protection extends to said computer program and further to computer readable means comprising a recorded message, said computer readable means comprising program coding means for carrying out one or more steps of the method. , when said program is run on a computer.

Implementation variants of the described non-limiting example are possible, without however departing from the scope of protection of the present invention.

Claim 1:
Method of generating an application package (PackApp*) for a diagnostic tool (TOOL) configured to check the compatibility (Step Y) of the application package with the vehicle control unit, the method comprising generating an application file (Appfile) containing instructions for a vehicle ECU, the application file comprising
- a first header (AAH) comprising at least one field showing a CRC value calculated on the entire application file,
- an executable portion (Application),
the method further comprises a step (Step1) of generating a modified application file (Appfile*) comprising
- said first heading (AAH), unaltered, and
- the executable portion (Application*) compressed using a lossless compression algorithm,
- a second step (Step <NUM>) of putting forward said modified application file (Appfile*), a second header (THTD*) containing instructions to cause
- the transfer (Step <NUM>) of said modified application file (Appfile*) through two distinct transfers respectively of said first header (AHH) and said executable portion (Application*) compressed, and to cause
- the execution of the following steps by the vehicle control unit:
+ (Step <NUM>) prior decompression of the compressed executable portion (Application*) and
+ (Step <NUM>) storage, in a first non-volatile memory (SM1) of the vehicle control unit, of the executable portion (Application), decompressed, consecutively to said first header (AHH).