Electronic Control Unit

Abstract

Provided is a technology that makes it possible to write software that have different memory maps into the non-volatile memory of an electronic control device during the reprogramming of control software. An electronic control device that includes a microcomputer that includes a CPU and non-volatile memory. The non-volatile memory includes startup software, control software, and validity verification information for verifying the validity of the control software. The validity verification information and the startup software are stored at different storage areas of the non-volatile memory.

Description

[Technical field]

[0001] The present invention relates to an electronic control device, and more particularly to a technology for updating control software in an on-board electronic control device installed in an automobile. [Background technology]

[0002] In the electronic control unit (ECU: Electrical Control Unit) installed in an automobile, the control program (control software) and control data are written in non-volatile memory such as a flash ROM (Read Only Memory) built into the microcomputer. There are cases where the control program and control data written in the flash ROM need to be rewritten and updated.

[0003] Proposals for rewriting control programs in electronic control devices include JP 2019-109745 A, JP 2017-199120 A, and JP 2016-167113 A. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2019-109745 A [Patent Document 2] JP 2017-199120 A [Patent Document 3] JP 2016-167113 A Summary of the Invention [Problem to be solved by the invention]

[0005] The technology described below is not a publicly known technology, but a technology that was investigated by the present inventors prior to the present invention.

[0006] The inventors stored startup software (boot loader) and control software in a flash ROM, and assigned the following functions to the boot loader:

[0007] 1) A function to initialize the registers, RAM (Random Access Memory), and peripheral devices built into the microcomputer. 2) A function to rewrite (update or reprogram) the control software. 3) A function to verify the validity of the control software. Here, control software can be divided into multiple areas (division units) depending on its role and the data it holds.

[0008] When verifying the validity of the control software or each division unit of the control software, validity verification information is required to verify the validity, such as the address range for which sum values, CRC values, hash values, etc. are calculated, i.e., the start and end addresses of each division unit, and the storage address of the expected value, and this validity verification information is stored as a fixed value in the boot loader.

[0009] Therefore, when reprogramming the control software involves a change in the memory map, that is, when a change is made to the manner in which the control software is divided, the boot loader must also be rewritten at the same time. However, when the reprogramming function is performed by the boot loader, the boot loader cannot rewrite itself.

[0010] An object of the present disclosure is to provide a technology that enables software with a different memory map to be written to the non-volatile memory of an electronic control device when reprogramming control software.

[0011] Other objects and novel features will become apparent from the description of this specification and the accompanying drawings. [Means for solving the problem]

[0012] A brief summary of representative aspects of this disclosure is as follows.

[0013] An electronic control device according to one embodiment includes a microcomputer including a CPU and a non-volatile memory. The non-volatile memory includes start-up software, control software, and validation information for validating the validity of the control software. A storage area of ​​the validation information in the non-volatile memory is different from a storage area of ​​the start-up software. Effect of the Invention

[0014] According to the electronic control device of the above embodiment, when updating (reprogramming) the control software, the control software and the validity confirmation information can be rewritten, making it possible to write software with a different memory map into the non-volatile memory. [Brief description of the drawings]

[0015] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of an electronic control device according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing a first example of the configuration of software stored in the flash ROM of FIG. [Diagram 3] FIG. 3 is a diagram showing a second example of the configuration of software stored in the flash ROM of FIG. [Figure 4] FIG. 4 is a diagram showing an example of the configuration of software stored in a flash ROM according to a comparative example. [Diagram 5] FIG. 5 is a diagram illustrating a first configuration example of an address header. [Figure 6] FIG. 6 is a diagram showing a second configuration example of the address header. [Figure 7] FIG. 7 is a diagram illustrating a third configuration example of the address header. [Figure 8] FIG. 8 is a diagram showing a fourth configuration example of the address header. [Figure 9]FIG. 9 is a diagram illustrating a fifth configuration example of the address header. [Figure 10] FIG. 10 is a flow chart illustrating the operation of the electronic control unit at the time of startup. [Figure 11] FIG. 11 is a flowchart showing a process for verifying the validity of control software using an address header. [Figure 12] FIG. 12 shows an example of a configuration in which the address header is stored in a free address of the data flash. [Figure 13] FIG. 13 is a diagram showing an example of the structure of the address header in FIG. [Figure 14] FIG. 14 is a flowchart for verifying the validity of the control software using the address header stored in the data flash. [Figure 15] FIG. 15 is a diagram showing another example of the structure of the address header in FIG. [Figure 16] FIG. 16 is a diagram showing a reprogramming data package consisting of software, address headers, and metadata. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Hereinafter, the embodiments and examples will be described with reference to the drawings. However, in the following description, the same components are given the same reference numerals and repeated description may be omitted. Note that the drawings may be shown more diagrammatically than the actual embodiment in order to make the description clearer, but they are merely examples and do not limit the interpretation of the present invention.

[0017] (Embodiment) (Overall configuration of electronic control device) FIG. 1 is a diagram showing a configuration example of an electronic control device according to an embodiment. An in-vehicle electronic control device (ECU: Electrical Control Unit) 1 mounted on an automobile includes a microcomputer (MC) 2. The microcomputer 2 is equipped with at least one central processing unit (CPU: Central Processor Unit) 3 that performs arithmetic processing based on software, at least one volatile RAM (Random Access Memory) 4, at least one flash ROM 6 that holds programs and data, at least one communication module 5 for communicating with the outside, and a bus BUS that connects each circuit (3, 4, 5, 6) to each other. When the power supply to the ECU 1 is turned on, the microcomputer 2 starts up and the software written in the flash ROM 6 is executed by the CPU 3. The microcomputer 2 includes a plurality of external terminals to which various functions are assigned, and the plurality of external terminals are provided with corresponding external devices. The target external device is controlled by the control software stored in the flash ROM 6, which is a non-volatile memory. In an automobile, the in-vehicle electronic control device 1 controls, for example, fuel injection and ignition of the engine.

[0018] The volatile RAM 4 is a volatile memory that temporarily stores data during the calculations of the CPU 3. The volatile RAM 4 can be, for example, a static random access memory (SRAM).

[0019] The flash ROM 6 is a non-volatile memory that can be electrically erased and written. In FIG. 1, the non-volatile memory is described as the flash ROM 6, but the flash ROM 6 may be an EEPROM (Electrically Erasable Programmable Read-Only Memory). The address space of the flash ROM 6 includes a first storage area 61 in which software is mainly stored, and a second storage area 62 in which data is mainly stored. In the following description, the first storage area 61 is described as the code flash 61, and the second storage area 62 is described as the data flash 62. As shown in FIG. 1, each of the code flash 61 and the data flash 62 has a plurality of erase blocks EB, and each of the code flash 61 and the data flash 62 has a plurality of write blocks WB. Each of the erase blocks EB indicates a data erase unit, and each of the write blocks WB indicates a data write unit. One erase block EB includes a plurality of write blocks WB. That is, the flash ROM 6 allows data to be erased in units of erase blocks EB of a certain size, and allows data to be written in units of write blocks WB of a size smaller than the erase blocks EB. Although Fig. 1 shows an exemplary configuration in which each of the code flash 61 and the data flash 62 includes two erase blocks EB, and each erase block EB includes four write blocks WB, this is not limiting, and the number of blocks in the erase blocks EB and the number of blocks in the write blocks WB can be changed.

[0020] The communication module 5 is a communication section, and can connect to a diagnostic tool 7 when, for example, software in the electronic control unit 1 is rewritten.

[0021] (First Configuration Example of Software Stored in Flash ROM) Fig. 2 is a diagram showing a first configuration example of software stored in the flash ROM of Fig. 1. As shown in Fig. 2, start-up software (hereinafter referred to as boot loader) 10, an address header 20, and control software SFT are stored in code flash 61 of flash ROM 6. Data flash 62 of flash ROM 6 stores data flash contents 30 that constitute control data, control tables, etc. The data flash contents 30 are referenced by CPU 3 that executes the control software SFT, and electronic control device 1 executes the desired control.

[0022] The boot loader 10 has a function of initializing the registers, RAM 4 and peripheral devices (not shown) built into the microcomputer 2, a function of rewriting (updating or reprogramming) the control software SFT, and a function of verifying the validity of the control software SFT.

[0023] The control software SFT can be logically divided into multiple areas according to the roles and data it holds. The control software SFT may be a single piece of software. In Fig. 2, these multiple areas are shown as division unit 11, division unit 12, ..., division unit 1N.

[0024] The address header 20 is stored in a storage area in the flash ROM 6 that is different from the storage area of ​​the boot loader 10. The address header 20 includes validity confirmation information (also called validity verification information) for verifying the validity of the control software SFT. The validity confirmation information can also be called division information. The validity confirmation information holds, for example, the number of division units of the control software SFT, the start address and the end address or size information for each division unit, and the start address and the end address of the area in which the validation value (expected value EV) for each division unit is embedded. For a detailed configuration example of the address header 20, refer to Figs. 5 to 9 described later. It is preferable that the validation value for each division unit 11-1N is stored, for example, in an area near the start address of the storage area of ​​each division unit 11-1N or in an area near the end address of the storage area of ​​each division unit, as shown in Fig. 2. In this specification, a value for verifying the validity of the control software SFT is called a validation value. When a sum value, CRC (Cyclic Redundancy Check) value, hash value, or the like is calculated, the validation value can also be considered as the expected value EV of the calculation result.

[0025] The boot loader 10 is a program that is started immediately after the start-up of the microcomputer 2, and after initializing the built-in registers, RAM 4, peripheral devices (not shown), etc. of the microcomputer 2, it checks the validity of the control software SFT. This validity check is performed for each division unit 11-1N of the control software SFT based on the validity check information stored in the address header 20, and is performed by calculating, for example, a sum value, a CRC (Cyclic Redundancy Check) value, a hash value, etc. for each division unit 11-1N and comparing it with a value (expected value EV) previously embedded in the flash ROM 6 or a known value.

[0026] The boot loader 10 also has a function of rewriting (reprogramming) the control software SFT. For example, in the ECU 1, the software rewrite function is enabled in response to a software rewrite request sent from the diagnostic tool 7 connected from the outside. Then, in response to the request sent from the diagnostic tool 7, both the control software SFT and the address header 20 written in the flash ROM 6 are erased, and the new control software (SFT) and the new address header (20) sent are written to the flash ROM 6. In other words, the division unit 11-1N and the address header 20 constituting the control software SFT are the targets of reprogramming. This series of operations of erasing and writing is performed for each division unit 11-1N of the control software SFT. The boot loader 10 also performs validity check on the new control software (SFT) received from the diagnostic tool 7. This validity check is also performed using a hash value, a digital signature, a sum value, a CRC, or the like.

[0027] (Second configuration example of software stored in flash ROM) FIG. 3 is a diagram showing a second configuration example of the software stored in the flash ROM of FIG. 1. FIG. 3 differs from FIG. 2 in that in FIG. 3, the address header 20 is stored or written in the data flash 62 of the flash ROM 6 together with the data flash contents 30 constituting the control data and the like. That is, the boot loader 10 is stored in a desired storage area of ​​the code flash 61 of the flash ROM 6, and the address header 20 is stored in a desired storage area of ​​the data flash 62 of the flash ROM 6, which is different from the storage area of ​​the boot loader 10. The other configurations of FIG. 3 are the same as those of FIG. 2, so that the overlapping explanations will be omitted. For a detailed configuration example of the address header 20, refer to FIG. 13 and FIG. 15 described later.

[0028] In the embodiment, when confirming the validity of the control software 6 when rewriting software in the in-vehicle electronic control device 1 or starting up the software, the number of division units 11-1N of the control software SFT and division information are stored in an address header 20 in a storage area separate from the boot loader 10, and the boot loader 10 is configured to refer to the storage area of ​​the address header 20 when confirming the validity of the division unit 11-1N.

[0029] According to the embodiment, the address header 20 is paired with the control software SFT, and when the control software SFT is reprogrammed, the address header 20 is rewritten at the same time as the control software SFT. There is no need to rewrite the boot loader 10. As a result, even if the memory map in the code flash 61 of the flash ROM 6 of the division unit 11-1N of the control software SFT differs before and after reprogramming, the validity of the control software SFT can be confirmed with the same boot loader 10.

[0030] (Comparative Example) Fig. 4 is a diagram showing an example of the configuration of software stored in a flash ROM according to a comparative example. In Fig. 4, a boot loader 10R is stored in a code flash 61 of the flash ROM 6, and an address header 20R is stored in an area inside the boot loader 10R.

[0031] As shown in FIG. 4, when validating the control software SFT or the division unit (11-1N) of the control software SFT, validity confirmation information is required, such as the address range for which the sum value, CRC value, hash value, etc. are calculated, that is, the start address and end address of the division unit and the storage address of the expected value, and this validity confirmation information is stored in the boot loader as an address header 20R.

[0032] Therefore, when reprogramming the control software SFT involves a change in the memory map, that is, when a change is made to the division mode of the control software SFT, it is necessary to simultaneously rewrite the boot loader 10R and the address header 20R. However, when the reprogramming function is performed by the boot loader 10R, it is impossible for the boot loader 10R to rewrite itself.

[0033] From the above discussion, the reprogramming function of the boot loader 10R cannot be used to rewrite the boot loader 10R. As a reprogramming means that does not rely on the boot loader 10R, there are a method of using a debug port (not shown) of the microcomputer 2, or a method of developing reprogramming software on the RAM 4 and reprogramming the control software SFT.

[0034] However, if the electronic control device 1 is sealed or the debug port is disabled, it is difficult to perform reprogramming. In addition, it is necessary to incorporate a mechanism for receiving the reprogramming software to be loaded in the RAM 4 via the communication module 5 in the boot loader 10R in advance, and it is also necessary to prepare the reprogramming software itself to be loaded in the RAM 4, so that it is difficult to perform reprogramming without careful planning. In addition, even when reprogramming is performed, it takes extra time to transfer the reprogramming software to the RAM 4, which increases the time required for reprogramming.

[0035] Furthermore, when rewriting the boot loader 10R by a method that does not use the debug port, for example, the writing of the boot loader 10R after erasure may fail due to factors such as loss of connection between the diagnostic tool 7 and the electronic control device 1 during the rewriting. In this case, there is a risk that there will be no way to restore the electronic control device 1. If this state occurs, there will be no way to restore the electronic control device 1 other than by using the debug port. In order to avoid such risks, it is desirable not to rewrite the boot loader.

[0036] According to this embodiment, it is possible to write the control software SFT to the electronic control device 1 without using special reprogramming means such as via a debug port or using reprogramming software expanded in RAM, even if the memory map of the division unit 11-1N of the control software SFT in the code flash 61 of the flash ROM 6 is different before and after reprogramming. EXAMPLES

[0037] The first embodiment is a configuration example in which the address header 20 shown in Fig. 2 is stored in the code flash 61. The first embodiment will be described below with reference to Figs.

[0038] Fig. 5 is a diagram showing a first configuration example of the address header. As shown in Fig. 5, the validity confirmation information stored in the address header 20 includes the number 201 of division units of the control software SFT, and the start address 211-21N and the end address 311-31N for each division unit 11-1N. The validity confirmation information further includes an inverted value 201' of the number 201 of division units, an inverted value 211'-21N' of each of the start address 211-21N, and an inverted value 311'-31N' of each of the end address 311-31N. Each of the inverted values ​​201', 211'-21N', and 311'-31N' is a value for verifying the validity of each of the data itself of the number 201 of division units, the start address 211-21N, and the end address 311-31N. That is, the address header 20 holds inverted values ​​(201', 211'-21N', 311'-31N') for verifying the validity of the validity confirmation information itself (division information itself) of the address header 20 as part of the validity confirmation information (division information).

[0039] 5 does not include information on the storage address information or size information of the validation value (expected value EV) for each division unit 11-1N. In other words, in this example, as explained in FIG. 2, it is determined as a rule that the validation value (expected value EV) for each division unit 11-1N is stored in an area near the start address of the storage area of ​​each division unit 11-1N (or an area near the end address of the storage area of ​​each division unit), so the address header 20 does not need to include information on the storage address information or size information of the validation value (expected value EV).

[0040] FIG. 6 is a diagram showing a second configuration example of the address header. In FIG. 5, either one of the start address 211-21N or the end address 311-31N may be replaced with size information. As an example, FIG. 6 shows a configuration example in which the end address is replaced with size information. The address header 20 shown in FIG. 6 differs from FIG. 5 in that in FIG. 6, the size 411-41N of the division unit 11-1N and the inverted value 411'-41N' of the size of the division unit 11-1N are provided. That is, in FIG. 6, instead of the end address 311-31N for the division unit 11-1N in FIG. 5, the size 411-41N of the division unit 11-1N is stored in the validity confirmation information of the address header 20. The other configurations in FIG. 6 are the same as those in FIG. 5, so duplicated explanations will be omitted. Although FIG. 6 shows an example of a configuration in which each of the end addresses 311-31N in FIG. 5 is replaced with size information (411-41N), each of the start addresses 211-21N may be replaced with size information (411-41N) without changing each of the end addresses 311-31N in FIG.

[0041] Fig. 7 is a diagram showing a third configuration example of an address header. The address header 20 shown in Fig. 7 differs from Fig. 5 in that a start address 511-51N and an end address 611-61N of a storage area of ​​each validation value (expected value EV) of the division unit 11-1N are added to the address header 20 in Fig. 7. In addition, an inverted value 511'-51N' of each start address 511-51N and an end inverted value 611'-61N' of each end address 611-61N are added to the address header 20. The other configurations in Fig. 7 are the same as those in Fig. 5, so a duplicated description will be omitted.

[0042] Fig. 8 is a diagram showing a fourth configuration example of the address header. The address header 20 shown in Fig. 8 differs from Fig. 7 in that in Fig. 8, a size 411-41N of each division unit 11-1N and an inverted value 411'-41N' of each size of the division unit 11-1N are provided, and a size 711-71N of each validation value (expected value EV) of each division unit 11-1N and an inverted value 711'-71N' of the size of each validation value (expected value EV) of each division unit 11-1N are provided. The other configurations of Fig. 8 are the same as those of Fig. 7, so duplicated explanations will be omitted.

[0043] FIG. 9 is a diagram showing a fifth configuration example of the address header. The address header 20 shown in FIG. 9 is different from FIG. 7 in that a validation value 700 of the address header 20 is provided in the address header 20 in FIG. 9. This makes it possible to confirm the validity of the address header 20. The validation value 700 can be, for example, a checksum, CRC, or hash value of the address header 20. This makes it possible to detect tampering with the address header 20 by confirming the validity of the address header 20 before reading information in the address header 20 or as a process at the time of starting the electronic control device 1. This makes it possible to avoid the execution of malicious control software caused by tampering with the address header 20. The other configurations of FIG. 9 are the same as those of FIG. 7, so that repeated explanations will be omitted. The validation value 700 of the address header 20 may be provided in the address headers 20 of FIG. 5 to FIG. 8.

[0044] (Operation of electronic control unit at start-up) 10 is a flow chart for explaining the operation at the time of starting up the electronic control unit 1. When starting up the electronic control unit 1, the first thing executed by the CPU 3 of the microcomputer 2 is the boot loader 10. Below, the operation at the time of starting up the electronic control unit 1 will be explained step by step.

[0045] (Step S1) When the boot loader 10 is executed, it first initializes the built-in registers, RAM, peripheral devices, etc. of the microcomputer 2. Then, it verifies the validity of the control software SFT written in the flash ROM 6 (steps S2 to S5).

[0046] (Step S2) The CPU 3 reads out the validation information (division information) stored in the address header 20 .

[0047] (Step S3) Next, CPU 3 determines the calculation range of the validation value based on division unit number 201 of address header 20, start address 211-21N of division unit 11-1N, and end address 311-31N of division unit 11-1N or size 411-41N of division unit 11-1N.

[0048] (Step S4) Next, the CPU 3 determines the number of loops n for calculating the validation value based on the division unit number 201 of the address header 20. In this example, the number of loops n is set to 1 to N. Then, the CPU 3 calculates the validation value for division unit 1n (step S41), compares the calculation result of the validation value with the expected value EV (step S42), and stores the comparison result in, for example, the RAM 4 or an internal register (step S43).

[0049] (Step S5) Next, the CPU 3 evaluates the comparison result. If the comparison result indicates that the control software SFT is authentic (OK), the process proceeds to step S6. If the comparison result indicates that the control software SFT is not authentic (NG), the process proceeds to step S7.

[0050] (Step S6) The CPU 3 completes the execution of the boot loader 10 and jumps to the control software SFT, whereby the CPU 3 transitions to the execution of the control software SFT.

[0051] (Step S7) The CPU 3 does not jump to the control software SFT, but remains in the boot loader 10. In this case, if there is additional initialization processing required, it executes it and waits for rewriting (reprogramming) of the control software SFT.

[0052] In step S4, the method of validating the control software SFT may use one or more of a checksum, a CRC (Cyclic Redundancy Check), a hash value, and a digital signature. For example, in the method of using a checksum, a checksum is calculated for a target address range, and the validity of the control software SFT is verified by comparing the checksum with an expected value EV, which is a correct value embedded in advance in the flash ROM 6, or a known correct value. In this specification, the value for validating the above-mentioned validity is called a validation value.

[0053] In the case of a digital signature, the digital signature stored in the flash ROM 6 is decrypted using a public key previously stored in the flash ROM 6 or a public key obtained through communication with an external party, and a hash value is extracted. The electronic control unit 1 then compares the extracted hash value with a value calculated by itself for the target address range to verify its authenticity.

[0054] When the control software SFT is logically divided, this validity verification is performed for each of the division units 11-1N. If the validity of even one of the division units 11-1N cannot be confirmed, a jump to the control software SFT is not performed.

[0055] As described above, validity verification requires division information for each division unit 11-1N of the control software SFT and, in some cases, information on the location where the correct answer value (expected value EV) of the validity confirmation value is embedded. If such information is held inside the boot loader 10 as shown in the comparative example of Fig. 4 and the boot loader 10 is responsible for the reprogramming function, the boot loader 10 is not rewritten during reprogramming. Therefore, if the division mode of the control software SFT is different before and after reprogramming, the boot loader 10 will not be able to correctly verify the validity of the control software SFT.

[0056] In the first embodiment, the above-mentioned information group required for validity verification is arranged in an area that can be rewritten from the outside and is fixed or traceable. Then, when validity verification is performed, the above-mentioned problem is solved by referring to that area. In this specification, the information group required for validity verification is called an address header 20. The location where the address header 20 is arranged may be, for example, a fixed area or an arbitrary area in the code flash 61 of the flash ROM 6 that stores the control software SFT, or a fixed area or an arbitrary area in the data flash 62 (see the second embodiment) of the flash ROM 6 that stores data, or a fixed area or an arbitrary area in the EEPROM.

[0057] The address header 20 may be placed in any area of ​​the data flash 62 or EEPROM, that is, in a free address storage area. In this case, it is preferable to ensure traceability by using software that loads the contents of the stored address header 20 into the RAM 4 as needed.

[0058] (Verification of control software validity) 11 is a flowchart for verifying the validity of control software using an address header. The operation for verifying the validity of control software will be explained below step by step.

[0059] (Step S10) First, the division unit number information 201 in the address header 20 stored in the code flash 61 is referenced.

[0060] (Step S11) Next, the number of loops N for calculating the validation value is determined. In this example, the number of loops n is 1 to N.

[0061] (Step S12) Thereafter, for each division unit 11-1N, each start address 211-21N, each end address 311-31N, or each size information 411-41N is acquired by referring to the address header 20, and the calculation range of the validation value is determined based on this.

[0062] (Step S13) Then, the validation value is calculated.

[0063] (Step S14) The expected value EV of the validation value embedded in an area (for example, 511-51N, 611-61N in FIG. 7, 511-51N, 711-71N in FIG. 8) specified by the address header 20 stored in the code flash 61 is referenced.

[0064] (Step S15) The calculated validation value is compared with the expected value EV, and if they match, the process proceeds to step S16, and if they do not match, the process proceeds to step S17.

[0065] (Step S16) The control software SFT written in the code flash 61 is determined to be valid.

[0066] (Step S17) It is determined that the control software SFT written in the code flash 61 is not valid.

[0067] In addition, if the location where the expected value EV of the validation value is stored can be determined from the relative value of the start address 211-21N or the end address 311-31N stored in the address header 20 (see Figures 5 and 6), there is no need to include information regarding the storage location of the expected value EV in the address header 20.

[0068] In the case of the configuration in which the validation value 700 of the address header 20 itself shown in Fig. 9 is added, it is preferable to check the validity of the address header 20 using the validation value 700 before reading the information in the address header 20 shown in Fig. 10 or 11, or as a process at the start-up of the ECU 1. This makes it possible to detect tampering with the address header 20, and therefore makes it possible to prevent the execution of malicious software due to tampering with the address header 20.

[0069] The validation values ​​for the control software SFT are verified not only when the ECU 1 is started, but also immediately after reprogramming. This is an operation to verify whether the intended control software has been written correctly, and may be triggered by a request from a reprogramming tool (diagnostic device) or as post-processing of a data communication termination request.

[0070] If the configuration of the division units, that is, the number of division units and address arrangement, does not change before and after reprogramming, there is no need to rewrite the address header 20, but if the configuration of the division units changes, it is necessary to rewrite the address header 20 to match that configuration. Since the validation process of the validation value is dynamically performed according to the contents of the address header 20 as shown in Fig. 11, as long as the address header 20 is appropriately rewritten, the validation value related to the control software SFT can be verified without any problem even if the configuration of the division units of the control software SFT is different before and after reprogramming. EXAMPLES

[0071] In the first embodiment, a configuration example has been described in which the address header 20 is stored in a desired address area of ​​the code flash 61. The second embodiment is a configuration example in which the address header 20 shown in Fig. 3 is stored in a desired address area of ​​the data flash 62. Hereinafter, the second embodiment will be described with reference to Figs. 12 to 16.

[0072] Fig. 12 shows a configuration example when the address header is stored in a free address in the data flash. Fig. 13 shows a configuration example of the address header 20 in Fig. 12. Fig. 14 is a flowchart for verifying the validity of the control software using the address header stored in the data flash.

[0073] 12 shows the address space of RAM 4 and the address spaces of code flash 61 and data flash 62 of flash ROM 6. The code flash 61 stores a boot loader 10 and division units 11-1N of the control software SFT. The data flash 62 stores an address header 20 and data flash contents 30. A copy 20' of the address header 20 and a copy 30' of the data flash contents 30 are stored in RAM 4 by expansion software that expands the contents (20, 30) of the data flash 62 into RAM 4 as needed.

[0074] As shown in Fig. 13, the address header 20 and the copy 20' of the address header 20 hold the number 201 of division units of the control software SFT, the start address 211-21N and the end address 311-31N for each division unit 11-1N, and the start address 511-51N and the end address 611-61N of the area in which the validation value for each division unit 11-1N is embedded. As in the relationship between Fig. 6 and Fig. 8, either the start address or the end address may be replaced with size information (size 411-41N of each division unit 11-1N, size 711-71N of the validation value of each division unit 11-1N).

[0075] When referencing the value of the address header 20, the value of the copy 20' of the address header 20 in the RAM 4 is referenced. When the address header 20 is placed in a fixed area of ​​the data flash 62 rather than in a free address of the data flash 62, the value in the RAM 4 may be referenced using similar expansion software, or the address header 20 in the data flash 62 may be referenced directly.

[0076] Fig. 14 is a flowchart for verifying the validity of control software using an address header stored in a data flash. The flowchart in Fig. 14 differs from the flowchart in Fig. 11 in that, as shown in step S10A in Fig. 14, the address header 20 (strictly speaking, a copy 20' of the address header 20) expanded in the RAM 4 is referenced. In this case, the address header described in steps S12 and S14 also corresponds to the copy 20' of the address header 20. The other steps in Fig. 14 are the same as those in Fig. 11, so repeated explanations will be omitted, but will be briefly explained below.

[0077] First, the address header 20 stored in the data flash 62 is expanded in the RAM 4. The division unit count information 201 in the address header 20 is referenced via the address header 20 copy 20' expanded in the RAM 4 (step S10A), and the number of loops N for calculating the validation value is determined (step S11). After that, the address or address size information is referenced for each division unit (step S12), and the calculation range of the validation value is determined based on that, and the validation value is calculated (step S13).

[0078] The calculated validation value is compared with the expected value EV embedded in the area specified by the address header 20 (strictly speaking, the copy 20' of the address header 20) stored in the data flash 62 (steps S14, S15), and if the two match, the written control software SFT is determined to be valid (step S16). Note that if the location where the expected value EV of the validation value is stored can be determined from the relative values ​​of the addresses (start addresses 211-21N, end addresses 311-31N) stored in the address header 20, it is not necessary to include that information (511-51N, 611-61N) in the address header 20.

[0079] Fig. 15 is a diagram showing another example of the configuration of the address header 20 in Fig. 12. The address header 20 shown in Fig. 15 differs from the address header 20 shown in Fig. 13 in that a validation value 700 of the address header 20 itself is added in Fig. 15. The other configurations of Fig. 15 are the same as those of Fig. 13, so duplicated explanations will be omitted.

[0080] Before reading the information in the address header 20, or as part of the process at the start of the ECU 1, or the process of loading into the RAM 4, it is advisable to use the validation value 700 of the address header 20 itself in Fig. 15 to check the validity of the address header 20. This makes it possible to detect tampering with the address header 20, and therefore makes it possible to prevent malicious control software from being executed due to tampering with the address header 20.

[0081] The validation values ​​for the control software SFT are verified not only when the ECU 1 is started, but also immediately after reprogramming. This is an operation to verify whether the intended control software SFT has been written correctly, and may be triggered by a request from a reprogramming tool (diagnostic device) or as post-processing of a data communication termination request.

[0082] If the configuration of division unit 11-1N, that is, the number of division units 11-1N and address arrangement, does not change before and after reprogramming, there is no need to rewrite address header 20, but if the configuration of division unit 11-1N changes, address header 20 must also be rewritten to match the configuration. Since the validation process of the validation value is dynamically performed according to the contents of address header 20 as shown in Fig. 14, as long as address header 20 is appropriately rewritten, the validation value can be verified without problems even if the configuration of division unit 11-1N is different before and after reprogramming.

[0083] A method for rewriting the address header 20 will be described below.

[0084] In the first embodiment, there is a method of rewriting in the same way as reprogramming the control software SFT. In this case, the address header 20 can be treated as software. The address header 20 may be treated as a division unit of one piece of software, or may be treated as something included in the division unit.

[0085] In the second embodiment, since the address header 20 is treated as data, not as software, the address header 20 is not updated in the reprogramming procedure. Therefore, when updating the address header 20, a data writing service is used to update the address header 20. In this case, a data identifier is added to the address header 20, and the data to be updated is specified as the address header 20 by using the identifier, and the address header 20 is updated by sending the data following the identifier. Alternatively, when the address header 20 is placed in a fixed area, there is also a method of specifying the data to be updated by directly specifying the address. Either the method of using a data identifier or the method of directly specifying an address can be applied to the second embodiment when the address header 20 is treated as data.

[0086] Fig. 16 is a diagram showing a reprogramming data package consisting of control software, an address header, and metadata. When the address header 20 is treated as data, it is preferable to manage it as a set with the control software SFT. For example, as shown in Fig. 16, if a set of the ROM file of the control software, the ROM file of the address header 20, and the metadata 40 is managed as one reprogramming data 50, it is possible to avoid a situation in which the validity of the control software SFT cannot be correctly verified due to a mismatch between the memory map of the control software SFT and the address header 20.

[0087] The metadata 40 can include, for example, the number of division units of the control software SFT, address size information, address size information and data identifier of the address header 20, option information specifying the information transfer method used during reprogramming or data writing, information indicating the data format of the ROM file, etc. However, since the number of division units of the control software SFT and the address size information of the address header 20 can be held by the ROM file itself, in that case the metadata 40 does not need to include that information.

[0088] Furthermore, when the address header 20 is treated as data and the jump destination when the control software SFT is judged to be valid is determined based on the contents of the address header 20, it is possible to control the division unit executed at the start of the ECU 1 among the division units 11-1N of the control software SFT stored in the code flash 61 by rewriting only the address header 20. By utilizing this, it is possible to switch between a normal control mode and a factory inspection mode, for example.

[0089] For example, assume that division units 11, 12, 13, and 14 exist on the code flash 61, and that the pair of division units 11 and 12 and the pair of division units 13 and 14 each constitute one piece of control software SFT. Also assume that the boot loader 10 determines that the control software SFT is valid through validity verification and then sets the jump destination to the start address of the first division unit found among the information on division units 11-14 included in the address header 20.

[0090] Based on the above two assumptions, it is assumed that the address header 20 contains address and size information of the division units 11 and 12 and information that the number of division units is two. When the ECU 1 starts up in this state, the validity of the control software SFT is verified according to the flow of Figure 11 or Figure 14. If it is determined that the written control software SFT is valid and the start address of the division unit that the boot loader 10 first finds is that of the division unit 11, a jump from the boot loader 10 to the division unit 11 occurs. If the control software SFT consisting of division units 11 and 12 is independent and does not depend on the control software SFT consisting of division units 13 and 14, the division units 13 and 14 will not be executed, and only the control software SFT consisting of division units 11 and 12 will be executed.

[0091] Here, it is assumed that the address header 20 is rewritten by the data writing service, and the information contained in the address header 20 is changed to the address and size information of the division units 13 and 14 and the number of division units is changed to two. When the ECU 1 is restarted in this state, the boot loader 10 starts verifying the validity of the division units 13 and 14. If the validity verification determines that the division units 13 and 14 are each valid, and if the start address of the division unit that the boot loader 10 first finds is that of the division unit 13, a jump from the boot loader 10 to the division unit 13 occurs. As in the previous case, if the control software SFT consisting of the division units 13 and 14 is independent and does not depend on the control software SFT consisting of the division units 11 and 12, the division units 11 and 12 will not be executed, and only the control software SFT consisting of the division units 13 and 14 will be executed.

[0092] As described above, when the address header 20 is treated as data and the jump destination when the control software SFT is judged to be valid is determined based on the contents of the address header 20, it is possible to control the division unit executed at startup among the division units of the control software SFT stored in the code flash 61 by rewriting only the address header 20. By utilizing this, it is possible to switch between a normal control mode and a factory inspection mode, for example.

[0093] The invention made by the inventor has been specifically described above based on the embodiment and examples. However, it goes without saying that the present invention is not limited to the above embodiment and examples, and various modifications are possible. [Explanation of symbols]

[0094] 1: ECU, 2: microcomputer, 3: CPU, 4: RAM, 5: communication module, 6: flash ROM, 10: boot loader, 11 to 1N: division units of control software, 20: address header, 20´: address header expanded on RAM, 30: data flash contents, 30´: data flash contents expanded on RAM, 40: metadata, 50: reprogramming data package, 201: number of division units, 201´: inverted value of number of division units, 211 to 21N: start address of division unit 1N, 211´ to 21N´: start address of division unit 1N Inverted value, 311~31N: End address of division unit 1N, 311´~31N´: Inverted value of the end address of division unit 1N, 411~41N: Size of division unit 1N, 411´~41N´: Inverted value of the size of division unit 1N, 511~51N: Start address of validation value of division unit 1N, 511´~51N´: Inverted value of the start address of validation value of division unit 1N, 611~61N: End address of validation value of division unit 1N, 611´~61N´: Inverted value of the end address of validation value of division unit 1N, 700: Validation value of address header

Claims

1. A microcomputer including a CPU and a non-volatile memory, The non-volatile memory includes: Start-up software, Control software; and validation information for validating the validity of the control software, a storage area of ​​the validation information in the non-volatile memory is different from a storage area of ​​the boot software, The microcomputer further includes a communication unit for communicating with an external device, the start-up software has a function of reprogramming the control software; In the reprogramming function, erasing the control software and the validation information from the non-volatile memory; writing new control software and new validation information from the communication unit into the non-volatile memory; verifying the authenticity of the control software written in the non-volatile memory based on the authenticity confirmation information written in the non-volatile memory; The non-volatile memory includes: a first storage area in which software is mainly stored; a second storage area in which data is mainly stored; the startup software and the control software are stored in the first storage area; the validation information is stored in the first storage area or the second storage area; the control software is divided into a plurality of division units and stored in the first storage area, Each of the plurality of division units includes an expectation value; The validation information is The number of division units of the plurality of division units; A start address of each of the plurality of division units; An end address or size information of each of the plurality of division units; An electronic control device in which verification of the validity of the control software is performed for each of the multiple division units, and for each of the multiple division units, a validation value is calculated by calculating a sum value, a Cyclic Redundancy Check (CRC) value, or a hash value based on a corresponding start address and a corresponding end address or corresponding size information, and the validation value is compared with a corresponding expected value.

2. 2. The electronic control device of claim 1, the start-up software verifies the authenticity of the control software based on the authenticity confirmation information; After the validity of the control software is confirmed, the CPU jumps to the control software.

3. 2. The electronic control device of claim 1, The microcomputer further includes a volatile memory; When the validation information is stored in the second storage area, The validation information stored in the second storage area is expanded in the volatile memory; An electronic control device that verifies the validity of the control software based on the validity confirmation information written in the non-volatile memory by referring to the validity confirmation information expanded in the volatile memory.

4. 2. The electronic control device of claim 1, the non-volatile memory includes an erase block and a plurality of write blocks provided corresponding to the erase block; Data can be erased in units of the erase block, An electronic control device capable of writing data in units of the write block.

5. 2. The electronic control device of claim 1, The electronic control device, wherein the validation information further includes an inverted value of the division unit number, and an inverted value of the start point address or an inverted value of the size information.

6. 6. The electronic control device of claim 5, The validation information further comprises: A start address of an expected value corresponding to each of the plurality of division units; and an end address or size information of an expected value corresponding to each of the plurality of division units.

7. 7. The electronic control device of claim 6, The validation information further comprises a validation value of the validation information.

Images