SECURITY METHOD FOR PROGRAMMING A COMPUTER PROGRAM ON A CONTROL UNIT

Abstract

The invention relates to a security method for programming a computer program on a control unit, comprising the following steps executed by a processor in a software build environment in the order mentioned: a. Providing a complete computer program containing user data in a first data format; b. Converting the payload data from a first data format into a second data format and using a flash toolchain adapting the data for infrastructure data and creating a plurality of separate flash containers therefrom, where security mechanisms are checked and checksums are created using the Flashtoolchain, and wherein such a flash container in the second data format comprises payload data with at least one logical block based on at least part of the provided computer program, as well as infrastructure data; c. Flashing at least one flash container created using the flash tool chain from the SoftwareBuild environment to a control unit using a flash tool; d. Uploading at least a portion of the at least one flash container from the control unit to the SoftwareBuild environment; and e. in the SoftwareBuild environment, comparing the uploaded portion of the payload with the originally provided payload and forming a difference. With the validation procedure proposed here, the error-free adaptation of the infrastructure data of a control unit can be reliably verified.

Description

[0001] The invention relates to a security method for programming a computer program on a control unit, as well as to a motor vehicle with such a control unit securely programmed by means of such a security method.

[0002] To perform its function correctly, an ECU (e.g., embedded in a motor vehicle's electronic architecture) requires a computer program, known as software. This computer program is applied (programmed) to the ECU using a process called flashing. This computer program can be represented in various formats: - Intel HEX format (often used by development tools, such as compilers) - ODX / PDX format (used in vehicle production and workshops, i.e. in customer service).

[0003] The ODX / PDX format contains the (Intel) HEX components. It also contains technical and logistics data relevant to production at the vehicle plant. The HEX components in the ODX / PDX format can also be encrypted, signed, and compressed. - When creating HEX files, a list of all objects contained in such a HEX file, along with their addresses, can be created if necessary. This list is generally referred to as a MAP file (Memory by Address Program). This file shows, for example, the memory locations containing payload data and the locations of infrastructure data. - The contents of an ECU, especially its microcontroller(s), can be read using suitable hardware and software. This document describes this process from the ECU's perspective. Uploading means transporting data from the ECU (to the outside), i.e., into the SoftwareBuild environment.

[0004] For logistical reasons and due to the complexity and size of the computer program, the entire ECU program is divided (split or broken down) into various so-called flash containers. Each flash container itself consists of one or, if distributed across multiple cores of a µC (microcontroller), several logical blocks.

[0005] To comply with legal and customer requirements, and to avoid misconfigurations when flashing the various FlashContainers, the overall program is enriched with a variety of verification mechanisms, information, and certificates. Each logical block of a FlashContainer contains infrastructure data and payload data and is composed of three parts, for example: - Prologue, - User data (application data or program code), and - Epilogue.

[0006] The prologue and epilogue contain only infrastructure data. All of the above-mentioned information is incorporated here. The control unit uses this data, among other things, to ensure the integrity and correct configuration, as well as the legitimacy of the entire program. A multi-level toolchain (Flash toolchain) updates the above-mentioned information in the infrastructure data (e.g., prologues and / or epilogues) of the logical blocks. Due to the conversion and fragmentation, it is difficult to determine whether an error has occurred.

[0007] US 2006 / 0041 854 A1 discloses a system and method for programming microcontrollers.

[0008] The publication by NIKHIL, KJ; PREMANANDA, BS: Generation of Flash Containers in PDX Format for Automotive Secure Gateway. In: Proc. 2021 IEEE Mysore Sub Section International Conference (MysuruCon), Hassan, India, 2021, pp. 272-278. - Electronic ISBN: 978-1-6654-3888-9 discloses various technologies and components involved in creating a secure automotive data connection and presents an algorithm for generating flash containers in PDX format.

[0009] Based on this, the present invention is based on the object of at least partially overcoming the disadvantages known from the prior art. The features of the invention arise from the independent claims, for which advantageous embodiments are presented in the dependent claims. The features of the claims can be combined in any technically reasonable manner, whereby the explanations from the following description and features from the figures, which comprise additional embodiments of the invention, can also be consulted for this purpose.

[0010] The invention relates to a security method for programming a computer program on a control unit, comprising the following steps executed by a processor in a software build environment in the order mentioned: a. Providing a complete computer program containing user data in a first data format; b. Converting the payload data from a first data format into a second data format and, using a flash tool chain, adapting the data for infrastructure data and creating a plurality of separate flash containers therefrom, wherein security mechanisms are checked and checksums are formed using the flash tool chain, and wherein such a flash container in the second data format comprises payload data with at least one logical block based on at least part of the provided computer program, as well as infrastructure data; c. Flashing at least one FlashContainer created using the Flashtoolchain from the SoftwareBuild environment to a control unit using a flash tool; d. Uploading at least a portion of the at least one flash container from the control unit to the SoftwareBuild environment; and e. in the SoftwareBuild environment, comparing the uploaded portion of the payload with the originally provided payload and forming a difference.

[0011] Unless explicitly stated otherwise, ordinal numbers used in the preceding and following descriptions serve only to clearly distinguish them and do not reflect the order or ranking of the designated components. An ordinal number greater than one does not necessarily imply that another such component must be present.

[0012] This describes a method for securing any flash container (for example, in HCP1) with regard to the integrity of the payload data through the flash toolchain. This secures both the flash process and the creation of the flash container. The method is based on a comparison of input data with data read back from the ECU, i.e., uploaded. This serves to secure the integrity of the payload data (or net data) through the process in the flash toolchain or the programming sequence itself.

[0013] The computer program often consists of a multitude of individual subcomponents, which must later be integrated together in the production line to achieve the desired functionality of the control unit or a number of subunits, such as microcontrollers. Errors must not be introduced by a new computer program, but especially when integrating various program components into a complete computer program. This must be ensured.

[0014] The complete computer program is programmed, for example, on a single control unit, which may comprise a single or multiple microcontrollers. Alternatively, the computer program is deployed on a platform, such as a so-called HCP (High Performance Computing Platform), of which there are various variants, currently HCP1 to HCP5. Such a computer program contains only user data for the intended hardware architecture (i.e., for at least one control unit).

[0015] The (complete) computer program is first converted from a first data format into a second data format, for example, the HEX standard (.hex files, also known as Intel Hex format), which is used for the technical integration of the control unit. Infrastructure data (e.g., listed in a prologue and epilogue) is also required. A so-called flash toolchain is used for this purpose, which adapts the data from the computer program to the corresponding infrastructure data and combines it with the payload data into a flash container. This flash container is thus entirely available in the second data format.

[0016] The second data format is, for example, an ODX standard or PDX standard (.pdx file), which is later flashed onto the control unit both in production and in customer service. The structure of the flash container for the entire software in a control unit is shown as an example in Fig. 1. There, the titles reflect the scope under consideration, whereby this process is also transferable to the remaining parts of the computer program.

[0017] The so-called flashing is performed by a flash tool. Such a flash tool is, for example, standardized (known, for example, as ODIS or the registered trademark IDEX®). Flashing is preferably performed via the same physical path as will later be used in the production line and / or in customer service (for example, during maintenance and / or retrofitting).

[0018] Here, the originally provided payload data in the first data format is to be compared as the input artifact with the output artifact, namely the flash container in the second data format. The process flow from steps a to c corresponds, for example, to the normal process for programming a corresponding control unit in a production line. The process flow of the subsequent part of the process is described as follows:

[0019] The individual flash containers were flashed from the SoftwareBuild environment to the desired ECU via a (virtual) diagnostic address (step c). After successful flashing, it should be ensured that, with the exception of permitted exceptions (differences in the infrastructure data of the individual logical flash blocks), there are no or only predefined or traceable differences to the input artifacts. This ensures that the payload of the computer program has not been corrupted by the flash toolchain or the programming process itself, i.e., that the integration of the individual subcomponents into the complete computer program has been carried out correctly.It should be noted at this point that such a complete computer program has approximately 30,000 different parameters that must interact with the algorithms already provided in the computer program or in a control unit (i.e., these are parameterized by them). For example, one such parameter is the vehicle mass, to which, among other things, an (electronic) damping system, braking system, and / or tire pressure system must react accordingly.

[0020] When comparing the input artifact (e.g., .hex at the µC level) for the ECU with the output artifact from the ECU (e.g., .hex at the µC level), differences become apparent. If these differences can be narrowed down to purely infrastructure data (e.g., the epilogues and prologues) of the logical blocks or exclusively to predefined or traceable differences from the input artifacts, it is ensured that the content of the computer program's payload in the ECU was not altered during the creation of the flash containers.

[0021] It should be noted that the validation process is fully automated, i.e., without human intervention, for example, by a dedicated build server. Alternatively or additionally, the comparison in step d. can be performed in a sufficiently reliable manner by a computer alone. Preferably, flashing and / or uploading, as well as any other steps described below (such as creating a dump), are performed automatically, i.e., without human intervention. For example, the process is firmly integrated into a (self-running) test algorithm for quality assurance.

[0022] An automation program implemented in any programming language, such as Perl, Python or Java, provides the tools: - Flashtoolchain (used in step b.) - Standard Flashtool (used in step c.) - Upload in step d. via tool, for example the Infineon® Memtool - Comparison tool in step e., preferably including a prior MAP file analysis started automatically: The automation program itself receives the program file in an initial data format (for example, via command line parameters). In another embodiment, the file is also selected by a user via a GUI (graphical user interface).

[0023] Using this file as a parameter, the flash toolchain is started in step b., which then creates the corresponding flash containers in a second data format and returns a value via the output. For example, 0 (zero) represents an error or 1 (one) represents success.

[0024] The automation program uses the return value to decide whether normal program flow can be continued. If this is not the case, in one embodiment, the flash tool chain process is restarted until a predetermined (arbitrarily set) number of repetitions are reached in order to achieve a positive result. If this is not possible, the automation tool aborts and manual intervention is required. If the outcome is positive, a standard flash tool (step c.) is started and the files in the second data format are transferred via the command line. In another embodiment, the use of an API (Application Programming Interface) of the standard flash tool is also possible. The return value of the (preferably standard) flash tool (for error or success) is automatically evaluated.

[0025] The automation program uses the return value to determine whether normal program flow can continue. If this is not the case, in one embodiment, the flash tool process is restarted until a predetermined (arbitrarily set) number of repetitions is reached to achieve a positive result. If this is not possible, the automation tool aborts, and manual intervention is required.

[0026] If the outcome is positive, an upload (using a memory upload tool) is started in step d. to read the memory contents from the control unit. In an alternative embodiment, the automation tool first determines from the MAP file the memory sections required for the current process in order to upload only the relevant memory sections from the control unit in question and save them in an initial data format. The automation tool then starts a comparison tool (step e.) (for example, Beyond Compare® or 010Edit) and passes the program section read from the control unit and the file with the original program via command line parameters in order to compare the two. The automation tool uses a return value from the comparison tool to determine whether the original program is identical, i.e., whether the original program is intact (for example, 0 for an error or 1 for success).

[0027] In an alternative embodiment, in step d., the complete program is read from the control unit in a first data format, and the comparison tool is then parameterized with information from the MAP file so that only the relevant memory areas are compared. The automation program automatically decides, based on the return value, whether the comparison was successful. If so, the program execution is completed successfully. If this is not the case, in one embodiment, the execution is restarted when the (preferably standard) flash tool is executed up to a predetermined (arbitrarily set number) of repetitions. If no positive result is achieved after the specified number of repetitions, the program execution aborts, and manual intervention is required.

[0028] In one embodiment, a certificate is created (automatically) when error-freeness is determined. This certificate is preferably secured against alteration in a database (e.g., stored as a blockchain, preferably as an NFT (non-fungible token) or information that can be retrieved via an NFT). The creation of the error-free certificate is preferably protected from human intervention (falsification of the result) by the algorithm's execution.

[0029] In one embodiment, in the event of a defect, i.e. without freedom from errors, the flashing is (automatically) repeated and / or (if necessary after a fixed number of retries) aborted and an error message is generated, preferably the control unit or motor vehicle in question is removed from the production line for a separate, for example human, error check.

[0030] A defect, i.e., an error found through automated comparison, leads to the re-execution of the flash toolchain (in step b). A persistent error (i.e., one that persists across the majority of iterations) triggers a warning message and, for example, requires manual rework. In one embodiment, a preliminary error analysis is performed using artificial intelligence, preferably a neural network, particularly preferably a large language model.

[0031] It should be noted that the control unit is preferably embedded in a motor vehicle. Alternatively, the control unit is configured for another device. In one embodiment, a computer program is programmed onto a control unit outside of a motor vehicle and is only released for use in a motor vehicle upon correct execution (preferably with a corresponding certificate).

[0032] It is further proposed in an advantageous embodiment of the validation method that freedom from errors is determined in the software build environment if no difference or only a difference concerning the infrastructure data has been detected.

[0033] In this embodiment, no changes to the payload data are permitted. This allows for the highest security standards. Infrastructure data (e.g., data relating to the prologue and epilogue) is preferably not uploaded. Alternatively or additionally, for example, by analyzing the MAP file from the software build environment, it is possible to determine from the content which areas are to be assigned to the infrastructure data and are not taken into account in the comparison. Alternatively or additionally, a (at least logically) separate comparison is performed for the infrastructure data, for example, separately for the (optionally available) prologue and / or epilogue, whereby it is checked which differences exist and whether these differences are permissible or necessary.

[0034] It is further proposed in an advantageous embodiment of the protection method that immediately after flashing in step c. at least one dump is generated and uploaded to the SoftwareBuild environment in step d.

[0035] In one embodiment, .hex dumps are read directly via the development interface (e.g., FETK, Fast ECU Interface) on the ECU's microcontrollers (e.g., Infineon® TriCore) after flashing the flash containers. Preferably, the same physical path is not used for uploading from the ECU; instead, if there are multiple microcontrollers, the respective individual flash container is read from each microcontroller itself, for example, via a JTKTO interface.

[0036] It is further proposed in an advantageous embodiment of the protection method that in step d. the at least one dump is checked for error-freeness as a complete file or at the level of the relevant flash container.

[0037] These dumps, for example .hex files, can be read out both as a complete (.hex) file and at the level of individual flash containers to make the comparison clearer.

[0038] It is further proposed in an advantageous embodiment of the security method that the binary identity is checked during the comparison in step d.

[0039] For maximum accuracy and thus security, error-freeness can only be considered given if a binary identity is present, preferably exclusively for the payload data of the flash container in question.

[0040] It is further proposed in an advantageous embodiment of the protection method that the computer program is provided in the software build environment in a HEX standard and is converted into an ODX standard or PDX standard by means of the flash tool chain.

[0041] The conversion of the data format is necessary to allow development or programming activities (in a first data format, for example, the HEX standard) and to ensure sufficiently secure certification (security mechanisms) in the production line and in the vehicle (in another data format, for example, the ODX standard or PDX standard). ODX stands for Open Diagnostic Data eXchange and represents a standardized protocol. Alternatively, a so-called PDX standard is used. This is a compressed ODX data format.

[0042] It is further proposed in an advantageous embodiment of the protection method that a flash container comprises several logical blocks which are distributed over several cores of a microcontroller.

[0043] As already mentioned above, the protection method can also be used for microcontrollers with a plurality of cores, in which the flash containers are distributed across the multiple cores and also include several logical blocks.

[0044] According to a further aspect, a motor vehicle is proposed, comprising at least one embedded control unit and a plurality of units to be controlled by the control unit and sensors to be read out, wherein the embedded control unit can be communicatively connected to a software build environment, preferably via a diagnostic interface, wherein a security method according to an embodiment according to the above description can be executed by the software build environment and the control unit.

[0045] The motor vehicle is designed to transport goods and / or people. It has a conventional, preferably (particularly preferably battery-electric) drive train. In one embodiment, a vehicle platform is formed, which comprises a bodyshell, a chassis, and / or a drive train, and a transport cell is mounted on this vehicle platform. In one embodiment, the vehicle platform is already equipped with an embedded (preferably standardized) control unit, for example, the HCP1.

[0046] To equip the motor vehicle's control unit with a designated computer program, the program can be connected to a software build environment (i.e., for data exchange), preferably via a diagnostic interface. This connection is wired or wireless (for example, via 5G [fifth generation] or a local wireless network such as WLAN [wireless local area network]). A virtual data interface is provided at the program level.

[0047] The intended computer program is flashed or the flash containers are transferred to the control unit via the communicating connection. This is preferably carried out automatically by a workstation in a production line, whereby the infrastructure data (for example, the prologue and / or epilogue) is checked for admissibility and correct application using the embedded security mechanisms and only then is it programmed onto the relevant control unit. During this process, the data format is converted, namely during the so-called flashing. The subsequent (preferably immediately) verification process simply, preferably automatically, ensures that programming on the control unit was successful. In addition, a certificate is preferably created, which excludes human intervention (falsification of the result) due to the algorithm's execution.

[0048] The invention described above is explained in detail below against the relevant technical background with reference to the accompanying drawings, which show preferred embodiments. The invention is in no way limited by the purely schematic drawings, whereby it should be noted that the drawings are not to scale and are not suitable for defining proportions. It is shown in Fig. 1: a graphical interface output from a computer program with multiple Flash containers; Fig. 2: a schematic plan view of a motor vehicle; and Fig. 3: a flowchart of a hedging procedure.

[0049] In Fig. 1 shows a graphical interface output of a computer program (overall file 6) with multiple flash containers 5. A plurality of (here purely optionally nine) flash containers 5 are shown in the software build environment 3, each containing infrastructure data (for example, prologue and / or epilogue) and user data. The computer program is flashed for the control unit 1, and only those parts of the flash containers 5 are programmed (via the diagnostic interface 10) that are relevant for the current motor vehicle 8 (cf. Fig. 3) shall apply.

[0050] In Fig. 2 shows a schematic top view of a motor vehicle 8 with a control unit 1 and a plurality of sensors 9 (here purely schematically and by way of example: an exterior camera, a distance sensor, and a pair of active shock absorbers). A controller, preferably a microcontroller 7 with a plurality of cores, is provided for each sensor 9 itself and / or centrally. The control unit 1 can be communicatively connected to the software build environment 3 via a diagnostic interface 10 via a communicative (here purely optionally wireless) connection 12. The software build environment 3 comprises a corresponding counter interface 11 and a processor 2, which is configured to execute and monitor the validation method.

[0051] In Fig.3 shows a flowchart of a security method. In a step a., a computer program containing payload data and infrastructure data in a first data format is provided in the software build environment 3. Then, a step b. is carried out, namely the payload data and infrastructure data are converted from a first data format into a second data format and, using a flash tool chain, the infrastructure data (for example, prologue and / or epilogue) is adapted to create a plurality of separate flash containers 5. Security mechanisms are checked and checksums are formed using the flash tool chain, and such a flash container 5 in the second data format comprises payload data with at least one logical block based on at least part of the provided computer program, as well as infrastructure data. In a step c.At least one of the flash containers 5 from the software build environment 3 is programmed onto a control unit 1 using a flash tool, i.e., the flashing is carried out. This step a., step b., and / or step c. is carried out conventionally in one embodiment. In a (new) step d., at least a portion of the at least one converted flash container 5 is uploaded from the control unit 1 to the software build environment 3, for example, as .hex dumps. Subsequently, in a step e., the uploaded portion of the payload is compared with the originally provided payload in the software build environment 3, and a difference is calculated. From the difference, a conclusion is drawn (without human intervention, i.e., automatically), namely whether the programming of the computer program is error-free or not.From this, a conclusion is drawn (preferably without human intervention, i.e., automatically), namely whether the programming is correct (if error-free), needs to be repeated (if an error is present), or a separate test is necessary. Preferably, a certificate is created if error-free, and / or a human-readable log is generated if an error is present.

[0052] With the validation procedure proposed here, the error-free adaptation of the infrastructure data of a control unit can be reliably verified. List of reference symbols 1 control unit 2 processors 3 SoftwareBuild environment 4 Data 5 Flash containers 6 Total file 7 microcontrollers 8 Motor vehicle 9 Sensor 10 Diagnostic interface 11 Counter interface 12 communicative connection

Claims

[1] A security method for programming a computer program on a control unit (1), comprising the following steps performed by a processor (2) in a software build environment (3) in the order mentioned: a. Providing a complete computer program containing user data in a first data format; b. Converting the user data from a first data format into a second data format and using a flash tool chain adapting the data (4) for infrastructure data and creating a plurality of separate flash containers (5) therefrom, where security mechanisms are checked and checksums are created using the Flashtoolchain, and wherein such a flash container (5) in the second data format comprises payload data with at least one logical block based on at least part of the provided computer program, as well as infrastructure data; c. Flashing at least one flash container (5) created using the flash tool chain from the software build environment (3) to a control unit (1) using a flash tool; d. Uploading at least a part of the at least one flash container (5) from the control unit (1) into the software build environment (3); and e. in the SoftwareBuild environment (3), comparing the uploaded part of the payload with the originally provided payload and forming a difference. [2] The safeguarding method according to claim 1, wherein freedom from errors is determined in the software build environment (3) if no difference or only a difference concerning the infrastructure data has been determined. [3] The security method according to claim 1 or claim 2, wherein immediately after the flashing in step c. at least one dump is generated and uploaded to the software build environment (3) in step d. [4] The backup method according to claim 3, wherein in step d. the at least one dump is checked for error-freeness as a complete file (6) or at the level of the relevant flash container (5). [5] Security method according to one of the preceding claims, wherein the binary identity is checked during the comparison in step d. [6] The security method according to any one of the preceding claims, wherein the computer program is provided in the software build environment (3) in a HEX standard and is converted into an ODX standard or PDX standard by means of the flash tool chain. [7] Protection method according to one of the preceding claims, wherein a flash container (5) comprises a plurality of logical blocks which are distributed over a plurality of cores of a microcontroller (7). [8] Motor vehicle (8), comprising at least one embedded control unit (1) and a plurality of units to be controlled by the control unit (1) and sensors (9) to be read out, wherein the embedded control unit (1) is communicatively connectable to a software build environment (3), preferably via a diagnostic interface (10), wherein a security method according to one of the preceding claims can be executed by the software build environment (3) and the control unit (1).

Images