FR2923040A1 - Software content diagnosing method for electronic control unit of motor vehicle, involves recuperating information from image, and automatically diagnosing software content of logic controller based on recuperated information - Google Patents

Abstract

The method involves editing an electrically EPROM of a logic controller to obtain an electrically EPROM image of each of software components. The coherence information, reference information, and validation information are recuperated from the image, where the coherence, reference and validation information respectively indicate coherence between the components, identify one of the components and indicate validation of content of the component after reprogramming. A software content of a logic controller is automatically diagnosed based on the recuperated information.

Description

1

The present invention relates to a method for diagnosing an electronic system with software components. The invention finds a particularly important application in the automotive field, where the various onboard electronic systems of an automobile may be subject to verification, including a software integrity check, after their entry into service or marketing. Indeed, a motor vehicle commonly includes several electronic systems dedicated to the management of vehicle functions, such as for example the control of the engine propelling the vehicle, the management of the air conditioning of the passenger compartment, the management of the links of the vehicle on the ground (braking, suspension), etc.

Such systems essentially comprise electronic control units or "calculators" ECU (acronym for "Electronic Control Unit"), integrating software and using or transmitting information on the communication buses of the vehicle, in conjunction with other elements peripherals such as sensors and / or actuators.

The operating software stored in memory of a computer of this type integrates in particular a plurality of software components, provided to cooperate in the execution of the function for which the computer is provided. A software component is therefore understood as a subset of the computer's operating software, which constitutes an independent module used as part of this operating system and which is specifically designed to work without problems with the other components of that computer. this. One of the constraints of such a calculator is that related to the complexity of the software components constituting its operating system, in particular for their analysis in a context of return after sale of the calculator to the manufacturer.

Indeed, after its design and supply to a customer, for example a car manufacturer, the operating software stored in the computer's memory is conventionally provided to be modified. In particular, when the vehicle manufacturer wishes to replace in the computer memory a software version with a new version. This software update operation may consist of reprogramming all or part of the software components constituting the operating software of the computer, each software component can indeed be reprogrammed independently of the others. Consequently, in the case of return after sale of the calculator to its manufacturer, for example following a malfunction or a failure, the analysis by the manufacturer of the calculator is made complex because of the lack of knowledge of his computer. exact content, related to possible uploads of one or more new versions of the software after its delivery or a change of software content related to an electronic component malfunction. The control of the software content of the computer in return after sales is therefore very often based on an empirical analysis of it and on the experience of the operator in charge of carrying out this analysis. The object of the present invention is to remedy these drawbacks by proposing a method for diagnosing the software content of a computer, which makes it possible to perform this operation in a simplified, reliable and automatic manner. With this object in view, the subject of the invention is a method for diagnosing the software content (also called software integrity diagnosis) of a computer equipped with a memory storing a plurality of software components, the method being remarkable in that it comprises the following steps: - editing of the memory of said computer, so as to obtain a memory image of each of said software components; Recovering, for each of said software components, from its memory image, coherence information adapted to indicate the coherence of said software component with other software components within the computer, reference information adapted to identifying said software component and a validation information adapted to indicate a validation of the content of said component after possible reprogramming; automatic determination of the diagnosis of the software content of the computer, according to at least a part of said retrieved information. According to a variant of the invention, the diagnostic determination step comprises an analysis of at least a part of said information for each software component 25 taken independently. Advantageously, said analysis consists in determining an absent or present status of said information. In addition, it is suggested to analyze in combination the coherence information with the validation information of said software component. According to one embodiment, the diagnostic determination step comprises an analysis of at least a portion of said information of each software component considered relative to each other. Advantageously, it is proposed to compare together the coherence information of each software component. Preferably, the diagnostic determination step comprises comparing at least a portion of said information of each software component with their assigned values during a design phase of the software content of the computer. According to an advantageous embodiment, the diagnostic method compares at least the coherence information and / or the reference information recovered with their value (s) affected during the phase of the invention. computer software content design.

In addition, the method can recover the code of each software component and compare it with the code stored during the design phase. The method according to the invention can be implemented in a computer intended to be embedded in a motor vehicle, dedicated to the management of a function of the vehicle.

Other characteristics and advantages of the present invention will emerge more clearly on reading the following description given by way of illustrative and nonlimiting example and with reference to the appended figures in which: FIG. 1 illustrates an example of the stored software content in a memory of a calculator; FIG. 2 is a logic diagram schematizing the main operations necessary for establishing the diagnosis of the software content of the computer according to the invention. FIG. 1 shows the software content of an ECU ECU stored in a memory 10 thereof, for example an EEPROM (acronym for "Electrically Erasable Programmable Read-Only Memory", ie "erasable read-only memory" electrically and programmable) or a so-called "flash memory." In the diagram, three software components, respectively 11, 12 and 13, are represented by way of non-limiting example in themselves and thus constitute the software content of the memory 10 of the ECU calculator A much larger number of software components 11, 12, 13 is generally found in reality, but the example here is limited to three for the sake of clarity.A product reference ECU Ref is classically assigned to the calculator ECU We have seen that the purpose of the invention is to enable the computer software content analysis to be performed simply, reliably and automatically when the latter is returned to its manufacturer. t following a breakdown, for example, knowing that all or part of the software content of the calculator could be modified after its design. The manufacturer who returned the computer ignores the modified content of the calculator. It is then proposed to use a certain amount of information produced for each software component of the computer during its software design phase and to cross-check this information as produced at the end of the design phase. industrialization information to qualify this information, with the information of the same type, retrieved from the ECU computer as returned to the manufacturer following the detection of a malfunction. The industrialization information is stored in an industrialization information database, in which one can find all the industrialization information of each of the software components of the ECU and their location in the memory, from of the product reference Ref_ECU identifying the ECU calculator. The information used in the context of the present invention and which will be described in more detail later, are known information as such and associated with particular functions already provided within each software component, but absolutely not related to the diagnosis to date. Another characteristic related to this information is their generic nature, insofar as it is typically information present in all software components produced, regardless of the envisaged vehicle application or the client to which the computer is provided. In particular, it is proposed to use, in addition to the code constituting the software component itself, information relating respectively to the coherence strategy, to the reprogramming strategy and to the SEO strategy of a given software component. . Each software component 11, 12 and 13 comprises in fact, in addition to the code itself, respectively 11c, 12c and 13c, coherence information, respectively 11a, 12a and 13a, reference information, respectively 11b, 12b and 13b, and a validation information, respectively 11d, 12d and 13d. The coherence information 11a, 12a, 13a is related to the coherence strategy of the software component 11, 12, 13, which must make it possible to ensure that a software component of the ECU calculator is coherent with another software component of the calculator ECU, in particular that there is no contradiction between the data constituting them. This coherence information item 11a, 12a, 13a is conventionally arranged at the beginning of the software component 11, 12, 13. The reference information item 11b, 12b, 13b is manufacturer-specific information, related to the referencing strategy, for it is possible to identify the software component 11, 12, 13 and corresponds to a production serial number of said software component 11, 12, 13. Finally, the validation information 11d, 12d, 13d is itself information normally used in the part of the reprogramming function of the component by the customer. The validation information 11d, 12d, 13d typically includes a security key used as a marker in the software code to certify that the reprogramming was successful. Typically, this validation information 11d, 12d, 13d is written at the end of the software component 11, 12, 13 after any reprogramming.

This information will therefore be used according to the invention for the purpose of establishing the diagnosis of the calculator, in particular by combining them with the industrialization information, that is to say, the same information, but as produced at the output of design before production and delivery to the customer. To do this, with reference to FIG. 2, an operation 20 for editing the memory 10 of the ECU computer (also called "DUMP" in technical jargon) is implemented, making it possible to obtain the associated memory image. each software component 11, 12, 13 of the ECU calculator, that is to say obtaining a representation of the total content of the memory for each component.

From the memory image thus obtained associated with each software component 11, 12, 13 of the ECU computer, a step 30 is implemented for recovering, for each software component, the aforementioned information, which will be used in all or part for the diagnosis, namely the coherence information 11a, 12a, 13a, the reference information 11b, 12b, 13b, the validation information 11d, 12d, 13d and the code 11c, 12c, 13c. The establishment 40 of the diagnosis then relies on various analyzes, taken alone or in combination, to which will be discussed in more detail below, among which: an analysis of at least a portion of the information retrieved for each software component 11, 12 , 13 taken independently of one another, an analysis of at least a portion of the information retrieved for each software component 11, 12, 13 considered relative to each other and an analysis to compare at least a portion of the information retrieved for each software component 11, 12, 13 with the corresponding industrialization information stored respectively for each of the software components 11, 12, 13.

Each of these analyzes is capable of providing diagnostic results on its own but, in a particularly advantageous embodiment, the diagnosis is preferably established on the basis of a combination of these different analyzes. Still with reference to FIG. 2, a preliminary analysis 50 consists in determining an absent status ABS or present PRE for each of the information retrieved for each of said software components 11, 12, 13 and, in the case where the information concerned is determined as being present, to check whether it is different DIFF or identical ID with respect to the corresponding industrialization information for the software component 11, 12, 13 in question. The absent ABS status is in fact the absence of written information at the location expected in the memory for the information concerned.

In order to facilitate the reading of FIG. 2, the coherence information items 11a, 12a, 13a are represented by COH, those of validation 11d, 12d, 13d by VAL, those of reference 11b, 12b, 13b by REF and the code 11c, 12c, 13c by COD. The simple determination of the absent ABS status or present PRE information retrieved for each software component 11, 12, 13 taken independently of each other is already sufficient to establish a first diagnosis, without further reference to the industrialization information. Indeed, for a given software component, if, for example, the coherence information COH is present PRE and the validation information VAL is ABS absent, then it can be deduced that a write operation has was initiated without having been terminated, the coherence information COH being indeed located at the beginning of the software component 11, 12, 13 and the validation information at the end, and in which case diagnosing a loss of power during the operation writing. By way of example again, if the coherence information COH is present PRE and information is also present at the validation location at the end of the software component but is however invalid, then a loss of power during an operation erase memory can be diagnosed. Another example of a diagnostic establishment based on a simple analysis of the status absent or present information retrieved for each software component taken independently of each other, is to analyze the status for the REF reference information. If the latter is absent ABS, then we can diagnose that it is an invalid component. As already seen above, the establishment 40 of the diagnosis may consist of analyzing at least a portion of the information retrieved for each software component 11, 12, 13, also considering them relative to each other. Such a comparative analysis of the corresponding information of each software component 11, 12, 13 is based in particular on the comparison between them COH coherence information associated with each of the software components 11, 12, 13. Indeed, if for example two information of COH coherence respectively recovered from a first and a second software component are not consistent with each other, it means that the two software components concerned are incompatible. Finally, the establishment 40 of the diagnosis can also be seen based on a comparison, component by component, information retrieved from each software component with the corresponding industrialization information for each of these software components. As we have seen, from the ECU ECU reference Ref ECU, we can find in the database all the industrialization information 7 available for all the software components 11, 12, 13 constituting the ECU calculator. Thus, for example, if the COH coherence and COD code information for a given component are different from the industrialization information, it can be diagnosed that the component has been reprogrammed. According to another example, if the REF reference information is identical ID to the corresponding industrialization information and the component's COD code is on the other hand different from the output industrialization code, one can diagnose for example a content corrupted for the software component in question.

According to the preferred embodiment, all the different analyzes detailed above are then advantageously recombined in step 40 to establish the diagnosis of the computer software content returned to the after-sales teams, allowing at least to indicate to these teams if the content and in particular which component has been reprogrammed or not, corrupted or not, or to indicate possible causes of anomalies etc. The choice of the various information retrieved for the purpose of this diagnosis and their attached properties advantageously makes it possible to establish a diagnosis automatically and without the need for this on the part of the after-sales teams a level of competence and high experience in the field.

Claims (10)

A method for diagnosing the software content of a computer (ECU) equipped with a memory (10) storing a plurality of software components (11, 12, 13), characterized in that it comprises the following steps: 20) of the memory of said computer, so as to obtain a memory image of each of said software components; recovering (30), for each of said software components from its memory image, coherence information (COH, 11a, 12a, 13a) adapted to indicate the coherence of said software component with other software components within the computer, a reference information (REF, 11b, 12b, 13b) adapted to identify said software component and a validation information (VAL, 11d, 12d, 13d) adapted to indicate a validation of the content of said component after possible reprogramming; automatic determination (40) of the diagnosis of the software content of the computer (10), as a function of at least a part of said retrieved information. 2. Method according to claim 1, characterized in that the step of determining the diagnosis comprises an analysis of at least a part of said information for each software component taken independently. 3. Method according to claim 2, characterized in that said analysis consists in determining an absent status (ABS) or present (PRE) of said information. 4. Method according to claim 2 or 3, characterized in that it consists in analyzing in combination the coherence information with the validation information of said software component. 5. Method according to any one of claims 1 to 4, characterized in that the step of determining the diagnosis comprises an analysis of at least a portion of said information of each software component considered relative to each other. 6. Method according to claim 5, characterized in that it consists in comparing together the coherence information of each software component. 7. Method according to any one of claims 1 to 6, characterized in that the step of determining the diagnosis comprises a comparison of at least a portion of said information of each software component with their values assigned during a phase of computer software content design. 8. Method according to claim 7, characterized in that it consists in comparing at least the coherence information and / or the retrieved reference information (s) with their value (s) affected (s) during the design phase of the software content of the calculator. 9. The method of claim 7 or 8, characterized in that it consists in recovering the code (COD, 11c, 12c, 13c) of each software component and comparing said retrieved code with the code stored during the phase. Design. 10. Method according to any one of the preceding claims, characterized in that the computer is a computer intended to be embedded in a motor vehicle, dedicated to the management of a vehicle function.