WO2021255984A1 - 電子制御装置および制御用ソフトウェアの更新方法 - Google Patents

電子制御装置および制御用ソフトウェアの更新方法 Download PDF

Info

Publication number
WO2021255984A1
WO2021255984A1 PCT/JP2021/004264 JP2021004264W WO2021255984A1 WO 2021255984 A1 WO2021255984 A1 WO 2021255984A1 JP 2021004264 W JP2021004264 W JP 2021004264W WO 2021255984 A1 WO2021255984 A1 WO 2021255984A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
control software
validity
volatile memory
control device
Prior art date
Application number
PCT/JP2021/004264
Other languages
English (en)
French (fr)
Inventor
駿 衣笠
健治 安藤
雄介 阿部
Original Assignee
日立Astemo株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立Astemo株式会社 filed Critical 日立Astemo株式会社
Priority to DE112021002282.2T priority Critical patent/DE112021002282T5/de
Priority to US18/010,297 priority patent/US20230252153A1/en
Priority to JP2022532271A priority patent/JPWO2021255984A1/ja
Publication of WO2021255984A1 publication Critical patent/WO2021255984A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Definitions

  • the present invention relates to an electronic control device, and more particularly to an technique for updating control software in an in-vehicle electronic control device mounted on an automobile.
  • control program control software
  • control data are written in a non-volatile memory such as a flash ROM (Read Only Memory) built in a microcomputer. ing.
  • the control program and control data written in the flash ROM may be rewritten and updated.
  • Proposals for rewriting techniques for control programs in electronic control devices include JP-A-2019-109745, JP-A-2017-199120, JP-A-2016-167113, and the like.
  • the present inventors stored the boot software (boot loader) and the control software in the flash ROM, and assigned the following functions to the boot loader.
  • control software can be divided into a plurality of areas (division units) according to its role and the data to be held.
  • the address range for which the sum value, CRC value, hash value, etc. are calculated that is, the start point address and end point address of each division unit
  • the validity confirmation information for confirming the validity such as the storage address of the expected value is required, and the validity confirmation information is stored as a fixed value in the boot loader.
  • An object of the present disclosure is to provide a technique for reprogramming control software, which enables software having a different memory map to be written to the non-volatile memory of an electronic control device.
  • An electronic control device includes a microcomputer including a CPU and a non-volatile memory.
  • the non-volatile memory includes boot software, control software, and validity confirmation information for confirming the validity of the control software.
  • the storage area of the validity confirmation information in the non-volatile memory is different from the storage area of the boot software.
  • control software and the validity confirmation information can be rewritten in the update (reprogramming) of the control software, so that the software having a different memory map is non-volatile. It becomes possible to write to the memory.
  • FIG. 1 is a diagram showing a configuration example of an electronic control device according to an embodiment.
  • FIG. 2 is a diagram showing a first configuration example of software stored in the flash ROM of FIG.
  • FIG. 3 is a diagram showing a second configuration example of the software stored in the flash ROM of FIG.
  • FIG. 4 is a diagram showing a configuration example of software stored in the flash ROM according to the comparative example.
  • FIG. 5 is a diagram showing a first configuration example of the address header.
  • FIG. 6 is a diagram showing a second configuration example of the address header.
  • FIG. 7 is a diagram showing a third configuration example of the address header.
  • FIG. 8 is a diagram showing a fourth configuration example of the address header.
  • FIG. 9 is a diagram showing a fifth configuration example of the address header.
  • FIG. 1 is a diagram showing a configuration example of an electronic control device according to an embodiment.
  • FIG. 2 is a diagram showing a first configuration example of software stored in the flash ROM of FIG.
  • FIG. 10 is a flowchart illustrating the operation of the electronic control device at the time of activation.
  • FIG. 11 is a flowchart for confirming the validity of the control software using the address header.
  • FIG. 12 is a configuration example in which the address header is stored in the free address of the data flash.
  • FIG. 13 is a diagram showing a configuration example of the address header of FIG.
  • FIG. 14 is a flowchart for confirming the validity of the control software using the address header stored in the data flash.
  • FIG. 15 is a diagram showing another configuration example of the address header of FIG.
  • FIG. 16 is a diagram showing a reprogramming data package consisting of software, address headers, and metadata.
  • FIG. 1 is a diagram showing a configuration example of an electronic control device according to an embodiment.
  • An in-vehicle electronic control unit (ECU) 1 mounted on an automobile includes a microcomputer (MC) 2.
  • the microcomputer 2 holds at least one central processing unit (CPU) 3 that performs arithmetic processing based on software, at least one volatile RAM (Random Access Memory) 4, and programs and data. It is equipped with at least one flash ROM 6, a communication module 5 for communicating with at least one external device, a bus BUS or the like for interconnecting circuits (3, 4, 5, 6).
  • the microcomputer 2 When the power is turned on to the ECU 1, the microcomputer 2 is activated 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.
  • the vehicle-mounted electronic control device 1 controls, for example, fuel injection / ignition of an engine.
  • the volatile RAM 4 is a volatile memory, and data in the middle of calculation by the CPU 3 is temporarily stored.
  • the volatile RAM 4 can be, for example, a static random access memory (SRAM).
  • the flash ROM 6 is a non-volatile memory that can be electrically erased and written.
  • the non-volatile memory is described as a 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.
  • the first storage area 61 will be described as a code flash 61
  • the second storage area 62 will be described as a data flash 62. As shown in FIG.
  • 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 the data erase unit, and the write block WB indicates the data write unit.
  • One erase block EB includes a plurality of write blocks WB. That is, the flash ROM 6 can erase data in units of erase blocks EB of a certain size, and can write data in units of write blocks WB having a size smaller than that of the erase block EB.
  • 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, but the present invention is limited thereto.
  • the number of blocks of the erase block EB and the number of blocks of the write block WB can be changed.
  • the communication module 5 is a communication unit, and for example, the diagnostic tool 7 can be connected when the software of the electronic control device 1 is rewritten.
  • FIG. 2 is a diagram showing a first configuration example of the software stored in the flash ROM of FIG.
  • the code flash 61 of the flash ROM 6 stores boot software (hereinafter referred to as a boot loader) 10, an address header 20, and control software SFT.
  • the data flash 62 of the flash ROM 6 stores a data flash storage 30 that constitutes control data, a control table, and the like.
  • the data flash storage 30 is referred to by the CPU 3 that executes the control software SFT, and the electronic control device 1 executes desired control.
  • the boot loader 10 has an initialization function such as a register built in the microcomputer 2, a RAM 4 and peripheral devices (not shown), a rewriting (update or reprogramming) function of the control software SFT, and the validity of the control software SFT. It has a function to confirm the sex.
  • the control software SFT can be logically divided into multiple areas according to the role and the data to be held.
  • the control software SFT may be integrated.
  • the plurality of regions are shown as a division unit 11, a division unit 12, ..., A division unit 1N.
  • the address header 20 is stored in the flash ROM 6 in a storage area different from the storage area of the boot loader 10.
  • the address header 20 includes legitimacy confirmation information (also referred to as legitimacy verification information) for confirming the legitimacy of the control software SFT.
  • the validity confirmation information can also be called divided information.
  • the validity confirmation information is embedded, for example, with the number of division units of the control software SFT, the start point address and end point address or size information for each division unit, and the validation value (expected value EV) for each division unit.
  • the start point address, end point address, etc. of the existing area are held.
  • FIGS. 5 to 9 described later can be referred to. As shown in FIG.
  • the validation value for each division unit 11-1N is, for example, the area near the start address of the storage area of each division unit 11-1N, or the storage area of each division unit. It is preferable to store it in the area near the end point address.
  • the value for verifying the validity of the control software SFT is referred to as a validation value.
  • the validation value can also be said to be the expected value EV for those calculation results.
  • the boot loader 10 is a program that starts immediately after the microcomputer 2 starts, and after initializing the built-in register, RAM 4, peripheral devices (not shown) of the microcomputer 2, the validity of the control software SFT is confirmed. conduct.
  • This validity confirmation is performed for each of the division units 11-1N of the control software SFT based on the validity confirmation information stored in the address header 20, and for each division unit 11-1N, for example, a sum value or a thumb value or the like. It is performed by calculating a CRC (Cyclic Redundancy Check) value, a hash value, etc., and comparing it with a value (expected value EV) embedded in the flash ROM 6 in advance or a known value.
  • CRC Cyclic Redundancy Check
  • the boot loader 10 has a rewriting (reprogramming) function of the control software SFT.
  • the software rewriting function is provided in response to a software rewriting request transmitted from the diagnostic tool 7 connected from the outside. It will be activated. Subsequently, according to the request transmitted 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 transmission are further transmitted.
  • the address header (20) is written to the flash ROM 6. That is, the division unit 11-1N and the address header 20 constituting the control software SFT are targeted for reprogramming.
  • This series of erasing / writing operations is performed for each division unit 11-1N of the control software SFT.
  • the boot loader 10 also confirms the validity of the new control software (SFT) received from the diagnostic tool 7. This validity confirmation is also performed using a hash value, a digital signature, a sum value, a CRC, or the like.
  • FIG. 3 is a diagram showing a second configuration example of the software stored in the flash ROM of FIG. FIG. 3 is different from FIG. 2 in that the address header 20 is stored or written in the data flash 62 of the flash ROM 6 together with the data flash storage 30 constituting the control data and the like in FIG. 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. There is. Since the other configurations of FIG. 3 are the same as the other configurations of FIG. 2, overlapping description will be omitted. For a detailed configuration example of the address header 20, FIGS. 13 and 15 described later can be referred to.
  • the control software SFT division unit 11-in a storage area different from the boot loader 10. It is stored in the address header 20 which is the number of 1N and the division information, and the boot loader 10 is configured to refer to the storage area of the dress header 20 in the validity confirmation of the division unit 11-1N.
  • the address header 20 is paired with the control software SFT, and the address header 20 is also rewritten at the same time as the control software SFT when the control software SFT is reprogrammed.
  • the boot loader 10 does not need to be rewritten.
  • the memory map in the code flash 61 of the flash ROM 6 of the division unit 11-1N of the control software SFT is different before and after reprogramming, the validity of the control software SFT can be confirmed by the same boot loader 10. ..
  • FIG. 4 is a diagram showing a configuration example of software stored in the flash ROM according to the comparative example.
  • the boot loader 10R is stored in the code flash 61 of the flash ROM 6, and the address header 20R is stored in an area inside the boot loader 10R.
  • the address range for which the sum value, CRC value, hash value, etc. are calculated is to be calculated. That is, validity confirmation information such as the start point address of the division unit and the storage address of the end point and the expected value is required, and the validity confirmation information is stored in the boot loader as the address header 20R.
  • the reprogramming function of the boot loader 10R cannot be used to rewrite the boot loader 10R.
  • the debug port (not shown) of the microcomputer 2 is used, or the reprogramming software is expanded on the RAM 4 to reprogram the control software SFT. There is such a method.
  • the electronic control device 1 is sealed or the debug port is disabled, it is difficult to perform reprogramming. Further, it is necessary to incorporate in the boot loader 10R a mechanism for receiving the reprogramming software to be deployed in the RAM 4 via the communication module 5 in advance, and it is also necessary to prepare the reprogramming software itself to be deployed in the RAM 4. Therefore, it is difficult to implement without planned preparation. Also, when reprogramming is performed, it takes extra time to transfer the reprogramming software to the RAM 4, so that the time required for reprogramming increases.
  • the boot loader 10R is rewritten by a method that does not use the debug port, for example, the connection between the diagnostic tool 7 and the electronic control device 1 is lost during the rewriting, and the writing after the boot loader 10R is erased is written. Sometimes it fails. In this case, there is a risk that there is no way to restore the electronic control device 1. If this state occurs, there is no way to restore the electronic control device 1 other than the method using the debug port. To avoid these risks, it is desirable not to rewrite the boot loader.
  • the division unit 11-1N of the control software SFT in the code flash 61 of the flash ROM 6 is used without using a special reprogramming means such as the use of the reprogramming software developed via the debug port or the RAM. Even if the memory map of the above is different before and after reprogramming, the control software SFT can be written to the electronic control device 1.
  • Example 1 is a configuration example in which the address header 20 shown in FIG. 2 is stored in the code flash 61. Hereinafter, Example 1 will be described with reference to FIGS. 5 to 11.
  • FIG. 5 is a diagram showing a first configuration example of the address header.
  • the validity confirmation information stored in the address header 20 includes the number 201 of the division units of the control software SFT, the start point address 211-21N and the end point address 311- for each division unit 11-1N. Including 31N.
  • the validity confirmation information further includes an inverted value 201'of the number 201 of the division unit, an inverted value 211'-21N' of the start point address 211-21N, and an inverted value 311'- of the end point address 311-31N, respectively. 31N'and includes.
  • the inverted values 201', 211'-21N'and 311'-31N' are for verifying the validity of the data itself for the number of division units 201, the start point address 211-21N and the end point address 311-31N, respectively. It is a value. That is, the address header 20 is valid for the 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. It is retained as part of the sex confirmation information (divided information).
  • the address header 20 shown in FIG. 5 does not include information on the storage address information and size information of the validation value (expected value EV) for each division unit 11-1N. That is, in this example, as described with reference to FIG. 2, the validation value (expected value EV) for the division unit 11-1N is a region (or or) near the start address of the storage area of each division unit 11-1N. Since it is determined as a rule that the storage area is stored in the vicinity of the end point address of the storage area of each division unit), the storage address information and size of the validation value (expected value EV) are stored in the address header 20. It is not necessary to include information about the information.
  • FIG. 6 is a diagram showing a second configuration example of the address header.
  • either the start point address 211-21N or the end point address 311-31N may be replaced with size information.
  • FIG. 6 shows a configuration example in which the end point address is replaced with size information.
  • the difference between the address header 20 shown in FIG. 6 and FIG. 5 is 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 the point. That is, in FIG. 6, instead of the end point 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.
  • FIG. 6 shows a configuration example in which each end point address 311-31N in FIG. 5 is replaced with size information (411-41N), but each end point address 311-31N in FIG. 5 is not changed and each start point is not changed. Address 211-21N may be replaced with size information (411-41N).
  • FIG. 7 is a diagram showing a third configuration example of the address header.
  • the difference between the address header 20 shown in FIG. 7 and FIG. 5 is that in FIG. 7, the start point address 511-51N and the end point address 611-61N of the storage area of the validation value (expected value EV) of each division unit 11-1N are different. This is a point added to the address header 20. Further, an inverted value 511'-51N'for the start point address 511-51N and an end inverted value 611'-61N' for the end point address 611-61N are added to the address header 20. Since the other configurations of FIG. 7 are the same as the other configurations of FIG. 5, overlapping description will be omitted.
  • FIG. 8 is a diagram showing a fourth configuration example of the address header.
  • the difference between the address header 20 shown in FIG. 8 and FIG. 7 is that in FIG. 8, the size 411-41N of each division unit 11-1N and the inverted value 411'-41N'of each size of the division unit 11-1N are different.
  • Inversion value 711'of the provided points and the size of each validation value (expected value EV) of the division unit 11-1N 711-71N and the size of each validation value (expected value EV) of the division unit 11-1N. -71N' is provided. Since the other configurations of FIG. 8 are the same as the other configurations of FIG. 7, duplicated description will be omitted.
  • FIG. 9 is a diagram showing a fifth configuration example of the address header.
  • the difference between the address header 20 shown in FIG. 9 and FIG. 7 is that, in FIG. 9, the address header 20 is provided with a validation value 700 of the address header 20.
  • the validation value 700 can be, for example, a checksum, CRC, or hash value of the address header 20.
  • the validation value 700 can be, for example, a checksum, CRC, or hash value of the address header 20.
  • the validation value 700 of the address header 20 may be provided in the address header 20 of FIGS. 5 to 8.
  • FIG. 10 is a flowchart illustrating the operation of the electronic control device at the time of activation.
  • the boot loader 10 is first executed by the CPU 3 of the microcomputer 2 when the electronic control device 1 is started.
  • the operation at the time of starting the electronic control device 1 will be described step by step.
  • Step S1 In the execution of the boot loader 10, the internal registers, RAM, peripheral devices, and the like of the microcomputer 2 are first initialized. After that, the validity of the control software SFT written in the flash ROM 6 is verified (steps S2 to S5).
  • Step S2 The CPU 3 reads out the validity confirmation information (division information) stored in the address header 20.
  • Step S3 the CPU 3 has a size 411- of the number of division units 201 of the address header 20, the start point address 211-21N of the division unit 11-1N, and the end point address 311-31N of the division unit 11-1N or the division unit 11-1N.
  • the calculation range of the validation value is determined based on 41N or the like.
  • Step S4 the CPU 3 determines the number n of loops (LOOP) for calculating the validation value based on the number of division units 201 of the address header 20.
  • the number of loops n is 1 to N.
  • the CPU 3 calculates the validation value of the division unit 1n (step S41), compares the calculation result of the validation value with the expected value EV (step S42), and saves the comparison result in, for example, the RAM 4 or the built-in register (step S42). Step S43).
  • Step S5 the CPU 3 evaluates the comparison result. If it is determined that the control software SFT is valid in the evaluation of the comparison result (OK), the process proceeds to step S6. If it is determined that the control software SFT is not valid in the evaluation of the comparison result (NG), the process proceeds to step S7.
  • Step S6 The CPU 3 completes the execution of the boot loader 10 and jumps to the control software SFT. As a result, the CPU 3 shifts to the execution of the control software SFT.
  • Step S7 The CPU 3 does not jump to the control software SFT, but stays in the boot loader 10. In this case, if there is an additional required initialization process, it is executed and the control software SFT is in a state of waiting for rewriting (reprogramming).
  • step S4 as a method of verifying the validity of the control software SFT, there is a method of using one or more of a checksum, a CRC (Cyclic Redundancy Check), a hash value, and a digital signature.
  • a checksum is calculated for a target address range and compared with an expected value EV or a known correct answer value which is a correct answer value embedded in the flash ROM 6 in advance.
  • the value for verifying the correctness as described above is referred to as a validation value in the present specification.
  • the digital signature held in the flash ROM 6 is decrypted by the public key held in the flash ROM 6 in advance or the public key obtained by communication with the outside, and the hash value is taken out. After that, the legitimacy is verified by comparing the fetched hash value with the value calculated by the electronic control device 1 itself for the target address range.
  • This validity verification is performed for each of the division units 11-1N when the control software SFT is logically divided. If the validity of any one of the division units 11-1N cannot be confirmed, the jump to the control software SFT is not performed.
  • Example 1 the information group necessary for validity verification as described above is arranged in an area that can be rewritten from the outside and can be fixed or traced. Then, when verifying the validity, the above-mentioned problem is solved by referring to the area.
  • the information group necessary for validity verification is referred to as an address header 20.
  • the place 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 for storing the control software SFT, or the data flash 62 of the flash ROM 6 for storing the data (Example 2). It may be a fixed area or an arbitrary area in (see) or a fixed area or an arbitrary area in EEPROM.
  • the address header 20 may be arranged in an arbitrary area in 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 expands the contents of the stored address header 20 in the RAM 4 at any time.
  • FIG. 11 is a flowchart for confirming the validity of the control software using the address header. Hereinafter, the operation of confirming the validity of the control software will be described step by step.
  • Step S10 First, the number information 201 of the division unit in the address header 20 stored in the code flash 61 is referred to.
  • Step S11 Next, the number N of loops (LOOP) for calculating the validation value is determined.
  • the number of loops n is 1 to N.
  • Step S12 After that, for each division unit 11-1N, each start point address 211-21N, each end point address 311-31N, or each size information 411-41N is acquired with reference to the address header 20, and the validation value is based on the acquisition. Determine the calculation range.
  • Step S14 Expected value of validation value embedded in the area specified by the address header 20 stored in the code flash 61 (for example, 511-51N, 611-61N in FIG. 7, 511-51N, 711-71N in FIG. 8). EV is referenced.
  • Step S15 The calculated validation value and the expected value EV are compared, and if they match, the process proceeds to step S16, and if they do not match, the process proceeds to step S17.
  • Step S16 It is determined that the control software SFT written in the code flash 61 is valid.
  • Step S17 It is determined that the control software SFT written in the code flash 61 is not valid.
  • the place where the expected value EV of the validation value is stored can be determined from the relative value of the start point address 211-21N or the end point address 311-31N stored in the address header 20 (see FIGS. 5 and 6). It is not necessary to include information about the storage location of the expected value EV in the address header 20.
  • Verification of the validation value for the control software SFT is performed not only when the ECU 1 is started, but also immediately after reprogramming. This is an operation to verify whether the intended control software was written correctly, and when it is triggered by a request from a tool (diagnostic device) for reprogramming, or a request to end data communication. It may be performed as a post-processing.
  • the configuration of the division unit that is, the number of division units and the address arrangement do not change before and after reprogramming, it is not necessary to rewrite the address header 20, but if the configuration of the division unit changes, the address header 20 also changes according to the configuration. It needs to be rewritten.
  • the validation value verification process is dynamically performed according to the contents of the address header 20, so if the address header 20 is properly rewritten, the control software SFT is divided into units before and after reprogramming. Even if the configuration is different, the validation value related to the control software SFT can be verified without any problem.
  • 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.
  • Example 2 will be described with reference to FIGS. 12 to 16.
  • FIG. 12 is a configuration example in which the address header is stored in the free address of the data flash.
  • FIG. 13 is a diagram showing a configuration example of the address header 20 of FIG.
  • FIG. 14 is a flowchart for confirming the validity of the control software using the address header stored in the data flash.
  • FIG. 12 shows the address space of the RAM 4 and the address space of the code flash 61 and the data flash 62 of the flash ROM 6.
  • the code flash 61 stores the boot loader 10 and the division unit 11-1N of the control software SFT.
  • the data flash 62 stores the address header 20 and the data flash storage 30.
  • the RAM 4 stores a copy 20'of the address header 20 and a copy 30' of the data flash storage 30 by decompression software that expands the contents (20, 30) of the data flash 62 into the RAM 4 at any time.
  • the address header 20 and the copy 20'of the address header 20 have the number 201 of the division units of the control software SFT, the start point address 211-21N and the end point address 311- for each division unit 11-1N. 31N and the start point address 511-51N and the end point address 611-61N of the region in which the validation value for each division unit 11-1N is embedded are held.
  • either the start point address or the end point address is the size information (size of each division unit 11-1N size 411-41N, size of validation value of each division unit 11-1N). It may be replaced with 711-71N).
  • the value of the address header 20 refers to the value of the copy 20'of the address header 20 on the RAM 4.
  • the value on the RAM 4 may be referred to by using the same expansion software, or the address of the data flash 62. Header 20 may be referred to directly.
  • FIG. 14 is a flowchart for confirming the validity of the control software using the address header stored in the data flash.
  • the difference between the flowchart of FIG. 14 and the flowchart of FIG. 11 is that, as shown in step S10A, the address header 20 expanded in the RAM 4 (strictly speaking, a copy 20'of the address header 20) is referred to in FIG. That is.
  • the address headers described in steps S12 and S14 also correspond to the copy 20'of the address header 20. Since the other steps in FIG. 14 are the same as the other steps in FIG. 11, duplicated description will be omitted, but a brief description will be given below.
  • the address header 20 stored in the data flash 62 is expanded in the RAM 4.
  • the number information 201 of the division unit in the address header 20 is referred to via the address header 20 copy 20'expanded in the RAM 4 (step S10A), and the number N of loops for calculating the validation value is determined (step S11). ..
  • the address or the address size information is referred to (step S12)
  • the calculation range of the validation value is determined based on the reference, and the validation value is calculated (step S13).
  • 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). ), If both match, it is determined that the written control software SFT is valid (step S16). If the location where the expected value EV of the validation value is stored can be determined from the relative value of the address (start point address 211-21N, end point address 311-31N) stored in the address header 20, that information (511-31N). 51N, 611-61N) need not be included in the address header 20.
  • FIG. 15 is a diagram showing another configuration example of the address header 20 of FIG.
  • the difference between the address header 20 shown in FIG. 15 and the address header 20 shown in FIG. 13 is that the validation value 700 of the address header 20 itself is added in FIG. Since the other configurations of FIG. 15 are the same as the other configurations of FIG. 13, duplicated description will be omitted.
  • the validity of the address header 20 is confirmed by using the validation value 700 of the address header 20 itself in FIG. 15 as a part of the processing before reading the information in the address header 20, the processing at the time of starting the ECU 1, or the processing for expanding to the RAM 4. Is good to do. As a result, falsification of the address header 20 can be detected, and it is possible to avoid execution of malicious control software due to falsification of the address header 20.
  • Verification of the validation value for the control software SFT is performed 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 was written correctly, and when it is triggered by a request from a tool (diagnostic device) for reprogramming, or when data communication is terminated. It may be performed as a post-processing of the request.
  • the configuration of the division unit 11-1N that is, the number of division units 11-1N and the address arrangement do not change before and after reprogramming, it is not necessary to rewrite the address header 20, but if the configuration of the division unit 11-1N changes, It is necessary that the address header 20 is also rewritten according to the configuration.
  • the validation value verification process is dynamically performed according to the contents of the address header 20, so if the address header 20 is properly rewritten, the configuration of the division unit 11-1N is configured before and after reprogramming. Even if they are different, the validation value can be verified without any problem.
  • the address header 20 can be treated as software.
  • the address header 20 may be treated as a division unit of one software, or may be treated as being included in the division unit.
  • the address header 20 since the address header 20 is treated as data instead of software, the address header 20 is not updated in the reprogramming procedure. Therefore, when updating the address header 20, the address header 20 is updated by using the data writing service. In this case, a data identifier is assigned to the address header 20, data to be updated by using the identifier is specified as the address header 20, and the address header 20 is updated by sending data following the identifier. .. Alternatively, when the address header 20 is arranged in the fixed area, there is also a method of designating the data to be updated by directly specifying the address. Both the method of using the data identifier and the method of directly specifying the address can be applied to the second embodiment when the address header 20 is treated as data.
  • FIG. 16 is a diagram showing a reprogramming data package including control software, an address header, and metadata.
  • the address header 20 is treated as data, it is preferable to manage it as a set with the control software SFT.
  • the control software SFT For example, as shown in FIG. 16, if the set of the control software ROM file, the address header 20 ROM file, and the metadata 40 is managed as one reprogramming data 50, the memory map and address of the control software SFT are managed. It is possible to avoid a situation in which the validity verification of the control software SFT cannot be performed correctly due to the mismatch of the header 20.
  • the metadata 40 for example, an option for specifying the number of division units of the control software SFT, address size information, address size information and data identifier of the address header 20, and an information transfer method used at the time of reprogramming or data writing.
  • Information, information indicating the data format of the ROM file, and the like can be included.
  • the ROM file itself can hold the number of division units of the control software SFT and the address size information of the address header 20, in that case, the information does not need to be described in the metadata 40. good.
  • the division unit executed when the ECU 1 is started can be controlled. By using it, for example, it is possible to switch between the normal control mode and the factory inspection mode.
  • division units 11, 12, 13, and 14 exist on the code flash 61, and a set of division units 11, 12 and a set of division units 13, 14 are established as one control software SFT, respectively. It is assumed that the configuration is such that. Then, the boot loader 10 finds the jump destination after determining that the control software SFT is valid by the validity verification first among the information of the division units 11-14 included in the address header 20. It is assumed that the starting point address of the unit is used.
  • the address header 20 now contains the address size information of the division units 11 and 12 and the information that the number of division units is two.
  • the validity of the control software SFT is verified according to the flow of FIG. 11 or FIG. Assuming that the written control software SFT is judged to be valid and the starting address of the division unit first discovered by the boot loader 10 is that of the division unit 11, the boot loader 10 to the division unit 11 A jump 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 are not executed and the division units 11 and 12 are used. Only the control software SFT is executed.
  • the boot loader 10 starts the validity verification of the division units 13 and 14. Assuming that each of the division units 13 and 14 is judged to be valid by the validity verification and the starting point address of the division unit first discovered by the boot loader 10 is that of the division unit 13, the boot loader 10 to the division unit 13 A jump to occurs.
  • control software SFT consisting of division units 13 and 14 is independent and does not depend on the control software SFT consisting of division units 11 and 12, the division units 11 and 12 are not executed and the division is performed. Only the control software SFT consisting of the units 13 and 14 is executed.
  • the address header 20 is treated as data and the jump destination when the control software SFT is determined to be valid is determined based on the contents of the address header 20, only the address header 20 is used.
  • the division unit executed at startup can be controlled. By using this, for example, it is possible to switch between the normal control mode and the factory inspection mode.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)

Abstract

制御用ソフトウェアのリプログラミングにおいて、メモリマップが異なるソフトウェアを電子制御装置の不揮発性メモリに書き込むことを可能とする技術を提供することにある。 電子制御装置は、ＣＰＵと、不揮発性メモリと、を含むマイクロコンピュータを含む。前記不揮発性メモリは、起動用ソフトウェアと、制御用ソフトウェアと、前記制御用ソフトウェアの正当性を確認する為の正当性確認情報と、を含む。前記不揮発性メモリにおける前記正当性確認情報の格納領域は、前記起動用ソフトウェアの格納領域と異なる。

Description

電子制御装置および制御用ソフトウェアの更新方法
　本発明は、電子制御装置に関し、特に、自動車に搭載される車載用電子制御装置における制御用ソフトウェアの更新技術に関する。
　自動車に搭載される電子制御装置（ＥＣＵ：Electrical Control Unit）では、マイクロコンピュータに内蔵されたフラッシュＲＯＭ（Read Only Memory）などの不揮発性メモリに制御用プログラム（制御用ソフトウェア）や制御データが書き込まれている。フラッシュＲＯＭに書込まれた制御用プログラムや制御データを書換えて更新する場合がある。
　電子制御装置における制御用プログラムの書換え技術の提案として、特開２０１９-１０９７４５号公報、特開２０１７－１９９１２０号公報、特開２０１６－１６７１１３号公報等がある。
特開２０１９-１０９７４５号公報 特開２０１７－１９９１２０号公報 特開２０１６－１６７１１３号公報
以下に説明する技術は公知とされた技術ではなく、本発明前に本発明者らによって検討された技術である。
　本発明者らは、フラッシュＲＯＭに、起動用ソフトウェア（ブートローダー）と制御用ソフトウェアと格納し、ブートローダーに、以下の機能を割り当てた。
　１）マイクロコンピュータに内蔵されたレジスタ、ＲＡＭ（Random Access Memory）および周辺機器などの初期化機能　２）制御用ソフトウェアの書き換え（更新またはリプログラミング）機能　３）制御用ソフトウェアの正当性を確認する機能ここで、制御用ソフトウェアはその役割や保持するデータによって複数の領域（分割単位）に分けることができる。
　制御用ソフトウェアや制御用ソフトウェアの各分割単位に対する正当性確認を行う場合は、サム値やＣＲＣ値やハッシュ値などの算出を行う対象となるアドレス範囲、すなわち各分割単位の始点アドレスおよび終点アドレスと、期待値の格納アドレスといった正当性を確認するための正当性確認情報が必要であり、それらの正当性確認情報はブートローダー中に固定値として格納されている。
　したがって、制御用ソフトウェアのリプログラミングにおいて、メモリマップの変更を伴う場合、すなわち制御用ソフトウェアの分割の様態に対する変更を伴う場合、ブートローダーも同時に書き換える必要がある。しかし、リプログラミング機能をブートローダーが担う場合、ブートローダーが自身を書き換えることは不可能である。
　本開示の課題は、制御用ソフトウェアのリプログラミングにおいて、メモリマップが異なるソフトウェアを電子制御装置の不揮発性メモリに書き込むことを可能とする技術を提供することにある。
　その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
　本開示のうち代表的なものの概要を簡単に説明すれば下記の通りである。
　一実施の形態に従う電子制御装置は、ＣＰＵと、不揮発性メモリと、を含むマイクロコンピュータを含み。前記不揮発性メモリは、起動用ソフトウェアと、制御用ソフトウェアと、前記制御用ソフトウェアの正当性を確認する為の正当性確認情報と、を含む。前記不揮発性メモリにおける前記正当性確認情報の格納領域は、前記起動用ソフトウェアの格納領域と異なる。
　上記一実施の形態に係る電子制御装置によれば、制御用ソフトウェアの更新（リプログラミング）において、制御用ソフトウェアと正当性確認情報とを書き替えることができるので、メモリマップが異なるソフトウェアを不揮発性メモリに書き込むことが可能となる。
図１は、実施の形態に係る電子制御装置の構成例を示す図である。 図２は、図１のフラッシュＲＯＭに格納されたソフトウェアの第１の構成例を示す図である。 図３は、図１のフラッシュＲＯＭに格納されたソフトウェアの第２の構成例を示す図である。 図４は、比較例に係るフラッシュＲＯＭに格納されたソフトウェアの構成例を示す図である。 図５は、アドレスヘッダの第１構成例を示す図である。 図６は、アドレスヘッダの第２構成例を示す図である。 図７は、アドレスヘッダの第３構成例を示す図である。 図８は、アドレスヘッダの第４構成例を示す図である。 図９は、アドレスヘッダの第５構成例を示す図である。 図１０は、電子制御装置の起動時の動作を説明するフローチャート図である。 図１１は、アドレスヘッダを用いた制御用ソフトウェアの正当性確認を行う際のフローチャートである。 図１２は、アドレスヘッダをデータフラッシュのフリーアドレスに格納する場合の構成例である。 図１３は、図１２のアドレスヘッダの構成例を示す図である。 図１４は、データフラッシュに格納されたアドレスヘッダを用いた制御用ソフトウェアの正当性確認を行う際のフローチャートである。 図１５は、図１２のアドレスヘッダの他の構成例を示す図である。 図１６は、ソフトウェア、アドレスヘッダ、メタデータからなるリプログラミングデータパッケージを示す図である。
　以下、実施形態、および、実施例について、図面を用いて説明する。ただし、以下の説明において、同一構成要素には同一符号を付し繰り返しの説明を省略することがある。なお、図面は説明をより明確にするため、実際の態様に比べ、模式的に表される場合があるが、あくまで一例であって、本発明の解釈を限定するものではない。
　（実施の形態）
　（電子制御装置の全体構成）
　図１は、実施の形態に係る電子制御装置の構成例を示す図である。自動車に搭載される車載用電子制御装置（ＥＣＵ：Electrical Control Unit）１は、マイクロコンピュータ（ＭＣ）２を含む。マイクロコンピュータ２は、ソフトウェアに基づいて演算処理を実施する少なくとも１つの中央処理装置（ＣＰＵ：Central Processor Unit）３と、少なくとも１つの揮発性ＲＡＭ（Random Access Memory）４と、プログラムやデータを保持する少なくとも１つのフラッシュＲＯＭ６と、少なくとも１つの外部と通信を行うための通信モジュール５と、各回路（３、４、５、６）を相互に接続するバスＢＵＳ等を搭載している。ＥＣＵ１に電源が投入されると、マイクロコンピュータ２が起動してフラッシュＲＯＭ６に書き込まれたソフトウェアがＣＰＵ３によって実行される。マイクロコンピュータ２は様々な機能が割り当てられた複数の外部端子を含み、それらの複数の外部端子には対応した外部装置が設けられている。不揮発性メモリであるフラッシュＲＯＭ６に記憶されている制御用ソフトウェアによって対象の外部装置の制御を行う。自動車においては、車載用電子制御装１は、例えば、エンジンの燃料噴射・点火を制御する。
　揮発性ＲＡＭ４は、揮発性メモリであり、ＣＰＵ３の演算途中のデータが一時的に格納される。揮発性ＲＡＭ４は、一例では、スタチック型ランダムアクセスメモリ（ＳＲＡＭ）とすることができる。
　フラッシュＲＯＭ６は、電気的に消去および書き込み可能な不揮発性メモリである。図１では、不揮発性メモリをフラッシュＲＯＭ６として説明するが、フラッシュＲＯＭ６はＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）とされても良い。フラッシュＲＯＭ６のアドレス空間は、ソフトウェアが主に格納される第１格納領域６１と、データが主に格納される第２格納領域６２とを含む。なお、以下の説明では、第１格納領域６１はコードフラッシュ６１として説明し、第２格納領域６２はデータフラッシュ６２として説明する。図１に示す様に、コードフラッシュ６１およびデータフラッシュ６２のおのおのは複数の消去ブロックＥＢを有しており、また、コードフラッシュ６１およびデータフラッシュ６２のおのおのは複数の書込みブロックＷＢを有している。消去ブロックＥＢのおのおのはデータの消去単位を示し、書込みブロックＷＢはデータの書き込み単位を示している。１つの消去ブロックＥＢには、複数の書込みブロックＷＢが含まれる。つまり、フラッシュＲＯＭ６は、ある大きさの消去ブロックＥＢ単位でデータの消去が可能であり、消去ブロックＥＢよりも小さい大きさの書込みブロックＷＢ単位でデータの書き込みが可能である。図１には、コードフラッシュ６１およびデータフラッシュ６２のおのおのが２つの消去ブロックＥＢを含み、各消去ブロックＥＢが４つの書込みブロックＷＢを含む構成例が例示的に示されているが、これに限定されるわけではなく、消去ブロックＥＢのブロック数や書込みブロックＷＢのブロック数は変更可能である。
　通信モジュール５は、通信部であり、たとえば、電子制御装置１のソフトウェア書き換え時において、診断ツール７を接続することができる。
　（フラッシュＲＯＭに格納されたソフトウェアの第１の構成例）　図２は、図１のフラッシュＲＯＭに格納されたソフトウェアの第１の構成例を示す図である。図２に示す様に、フラッシュＲＯＭ６のコードフラッシュ６１には、起動用ソフトウェア（以下、ブートローダーと言う）１０、アドレスヘッダ２０と、制御用ソフトウェアＳＦＴが格納されている。フラッシュＲＯＭ６のデータフラッシュ６２には、制御データや制御テーブル等を構成するデータフラッシュ格納物３０が格納されている。データフラッシュ格納物３０は、制御用ソフトウェアＳＦＴを実行するＣＰＵ３により参照され、電子制御装置１が所望の制御を実行する。
　ブートローダー１０は、マイクロコンピュータ２に内蔵されたレジスタ、ＲＡＭ４および周辺機器（不図示）などの初期化機能、制御用ソフトウェアＳＦＴの書き換え（更新またはリプログラミング）機能、および、制御用ソフトウェアＳＦＴの正当性を確認する機能を有する。
　制御ソフトウェアＳＦＴは、役割や保持するデータによって論理的に複数の領域に分けることができる。制御ソフトウェアＳＦＴは、一体の場合もある。図２には、この複数の領域が、分割単位１１、分割単位１２、・・、分割単位１Ｎとして示されている。
　アドレスヘッダ２０は、フラッシュＲＯＭ６において、ブートローダー１０の格納領域とは異なる格納領域に格納されている。アドレスヘッダ２０は、制御用ソフトウェアＳＦＴの正当性を確認する為の正当性確認情報（正当性検証情報ともいう）を含む。正当性確認情報は、分割情報と言うことも可能である。正当性確認情報は、たとえば、制御用ソフトウェアＳＦＴの分割単位の個数と、それぞれの分割単位に対する始点アドレスと終点アドレスまたはサイズ情報と、それぞれの分割単位に対するバリデーション値（期待値ＥＶ）が埋め込まれている領域の始点アドレスと終点アドレス等が保持されている。アドレスヘッダ２０の詳細な構成例は、後述される図５～図９を参照することができる。それぞれの分割単位１１－１Ｎに対するバリデーション値は、図２に示す様に、たとえば、それぞれの分割単位１１－１Ｎの格納領域の先頭アドレスの近傍付近の領域、または、それぞれの分割単位の格納領域の終点アドレスの近傍付近の領域に格納するのが好ましい。本明細書では、制御用ソフトウェアＳＦＴの正当性を検証するための値を、バリデーション値と呼ぶこととする。バリデーション値は、サム値やＣＲＣ（Cyclic Redundancy Check）値、ハッシュ値などを計算により求めた場合においては、それらの計算結果に対する期待値ＥＶと言うこともできる。
　ブートローダー１０は、マイクロコンピュータ２の起動直後に起動するプログラムとされ、マイクロコンピュータ２の内蔵レジスタやＲＡＭ４、周辺機器（不図示）などの初期化を行った後、制御ソフトウェアＳＦＴの正当性確認を行う。この正当性確認は、アドレスヘッダ２０に格納された正当性確認情報に基づいて制御用ソフトウェアＳＦＴの分割単位１１－１Ｎそれぞれに対して実施され、分割単位１１－１Ｎごとに、例えば、サム値やＣＲＣ（Cyclic Redundancy Check）値、ハッシュ値などを計算し、それをあらかじめフラッシュＲＯＭ６に埋め込まれた値（期待値ＥＶ）や、既知の値と比較することで行われる。
　また、ブートローダー１０は制御用ソフトウェアＳＦＴの書き換え（リプログラミング）機能を有しており、例えば、ＥＣＵ１では、外部から接続された診断ツール７より送信されるソフトウェア書き換え要求に応じてソフトウェア書き換え機能が有効化される。続けて診断ツール７から送信されてくる要求にしたがいフラッシュＲＯＭ６に書き込まれている制御用ソフトウェアＳＦＴおよびアドレスヘッダ２０の両方を消去し、さらに送信されてきた新規な制御用ソフトウェア（ＳＦＴ）および新規なアドレスヘッダ（２０）をフラッシュＲＯＭ６に書き込む。つまり、制御用ソフトウェアＳＦＴを構成する分割単位１１－１Ｎとアドレスヘッダ２０とがリプログラミングの対象とされている。この消去・書き込みの一連の操作は、制御用ソフトウェアＳＦＴの分割単位１１－１Ｎごとに行われる。また、ブートローダー１０は、診断ツール７から受領した新規な制御用ソフトウェア（ＳＦＴ）に対しても正当性確認を実施する。この正当性確認も、ハッシュ値やデジタル署名、サム値やＣＲＣなどを利用して行われる。
　（フラッシュＲＯＭに格納されたソフトウェアの第２の構成例）
　図３は、図１のフラッシュＲＯＭに格納されたソフトウェアの第２の構成例を示す図である。図３が図２と異なる点は、図３において、アドレスヘッダ２０が、制御データ等を構成するデータフラッシュ格納物３０と共に、フラッシュＲＯＭ６のデータフラッシュ６２に格納ないし書き込まれている点である。つまり、ブートローダー１０はフラッシュＲＯＭ６のコードフラッシュ６１の所望の格納領域に格納され、アドレスヘッダ２０は、ブートローダー１０の格納領域と異なる、フラッシュＲＯＭ６のデータフラッシュ６２の所望の格納領域に格納されている。図３の他の構成は、図２の他の構成と同じであるので、重複する説明は省略する。なお、アドレスヘッダ２０の詳細な構成例は、後述される図１３、図１５を参照することができる。
　実施の形態では、車載用電子制御装置１のソフトウェア書き換え時およびソフトウェア起動時における制御用ソフトウェア６の正当性確認において、ブートローダー１０とは別の格納領域に、制御用ソフトウェアＳＦＴの分割単位１１－１Ｎの個数および分割情報であるアドレスヘッダ２０に保持し、ブートローダー１０は分割単位１１－１Ｎの正当性確認においてドレスヘッダ２０の格納領域を参照する構成とする。
　実施の形態によれば、アドレスヘッダ２０は制御用ソフトウェアＳＦＴと対になっており、制御用ソフトウェアＳＦＴのリプログラミング時にはアドレスヘッダ２０も制御用ソフトウェアＳＦＴと同時に書き換えられる。ブートローダー１０は書き替える必要はない。これにより、制御用ソフトウェアＳＦＴの分割単位１１－１ＮのフラッシュＲＯＭ６のコードフラッシュ６１におけるメモリマップがリプログラミング前後で異なっても、同一のブートローダー１０で制御用ソフトウェアＳＦＴの正当性確認が可能となる。
　（比較例）
　図４は比較例に係るフラッシュＲＯＭに格納されたソフトウェアの構成例を示す図である。図４では、ブートローダー１０ＲはフラッシュＲＯＭ６のコードフラッシュ６１に格納され、アドレスヘッダ２０Ｒは、ブートローダー１０Ｒの内部の領域に格納されている。
　図４のように、制御用ソフトウェアＳＦＴや制御用ソフトウェアＳＦＴの分割単位（１１－１Ｎ）に対する正当性確認を行う場合は、サム値やＣＲＣ値やハッシュ値などの算出を行う対象となるアドレス範囲、すなわち分割単位の始点アドレスや終点と期待値の格納アドレスといった正当性確認情報が必要であり、それらの正当性確認情報はブートローダー中に、アドレスヘッダ２０Ｒとして格納されている。
　したがって、制御用ソフトウェアＳＦＴのリプログラミングにおいて、メモリマップの変更を伴う場合、すなわち制御用ソフトウェアＳＦＴの分割の様態に対する変更を伴う場合、ブートローダー１０Ｒおよびアドレスヘッダ２０Ｒも同時に書き換える必要がある。しかし、リプログラミング機能をブートローダー１０Ｒが担う場合、ブートローダー１０Ｒがブートローダー１０Ｒ自身を書き換えることは不可能である。
　上記の議論から、ブートローダー１０Ｒを書き換えるためにはブートローダー１０Ｒが備えるリプログラミング機能は利用できない。ブートローダー１０Ｒに依らないリプログラミング手段としては、マイクロコンピュータ２が有するデバッグポート（不図示）を利用するか、リプログラミング用ソフトウェアをＲＡＭ４上に展開して制御用ソフトウェアＳＦＴのリプログラミングを実施する、といった方法がある。
　しかし、電子制御装置１が封止されていたり、デバッグポートが無効化されていたりすると、リプログラミングの実施が困難である。また、あらかじめＲＡＭ４に展開するためのリプログラミング用ソフトウェアを通信モジュール５経由で受領するための仕組みをブートローダー１０Ｒに組み込む必要があるうえ、ＲＡＭ４に展開するリプログラミング用ソフトウェアそのものを用意する必要もあるため、計画的な準備なしには実施が困難である。また、リプログラミングを実施する場合も、ＲＡＭ４にリプログラミング用ソフトウェアを転送するための時間が余分にかかるため、リプログラミングにかかる時間が増大する。
　さらに、デバッグポートを用いない方法でブートローダー１０Ｒを書き換える際、例えば、書き換えの途中で診断ツール７と電子制御装置１との接続が失われるなどといった要因で、ブートローダー１０Ｒの消去後の書き込みが失敗する場合もある。この場合、電子制御装置１を復帰させる方法がなくなるというリスクがある。この状態に陥ってしまうと、デバッグポートを用いる方法以外に、電子制御装置１を復帰する方法がなくなってしまう。こうしたリスクを回避するためには、ブートローダーは書き換えないことが望ましい。
　本実施の形態によれば、デバッグポート経由またはＲＡＭに展開するリプログラミング用ソフトウェアの利用といった特殊なリプログラミング手段を用いずに、フラッシュＲＯＭ６のコードフラッシュ６１における制御用ソフトウェアＳＦＴの分割単位１１－１Ｎのメモリマップがリプログラミング前後で異なる場合であっても、制御用ソフトウェアＳＦＴを電子制御装置１に書き込むことが可能となる。
　実施例１は、図２に示したアドレスヘッダ２０をコードフラッシュ６１に格納した構成例である。以下、実施例１について図５～図１１を用いて説明する。
　図５は、アドレスヘッダの第１構成例を示す図である。図５に示す様に、アドレスヘッダ２０に格納された正当性確認情報は、制御用ソフトウェアＳＦＴの分割単位の個数２０１と、それぞれの分割単位１１－１Ｎに対する始点アドレス２１１－２１Ｎと終点アドレス３１１－３１Ｎとを含む。正当性確認情報は、さらに、分割単位の個数２０１の反転値２０１’と、始点アドレス２１１－２１Ｎのそれぞれの反転値２１１’－２１Ｎ’と、終点アドレス３１１－３１Ｎのそれぞれの反転値３１１’－３１Ｎ’と、を含む。反転値２０１’、２１１’－２１Ｎ’および３１１’－３１Ｎ’のおのおのは、分割単位の個数２０１、始点アドレス２１１－２１Ｎおよび終点アドレス３１１－３１Ｎのおのおののデータ自体の正当性を検証するための値とされている。つまり、アドレスヘッダ２０は、アドレスヘッダ２０の正当性確認情報自体（分割情報自体）の正当性を検証するための反転値（２０１’、２１１’－２１Ｎ’、３１１’－３１Ｎ’）を、正当性確認情報（分割情報）の一部として保持している。
　なお、図５に示すアドレスヘッダ２０は、それぞれの分割単位１１－１Ｎに対するバリデーション値（期待値ＥＶ）の格納アドレス情報やサイズ情報に関する情報を含んでいない。つまり、この例では、図２で説明した様に、分割単位１１－１Ｎに対するバリデーション値（期待値ＥＶ）は、それぞれの分割単位１１－１Ｎの格納領域の先頭アドレスの近傍付近の領域（または、それぞれの分割単位の格納領域の終点アドレスの近傍付近の領域）に格納されていることがルールとして決められているので、アドレスヘッダ２０には、バリデーション値（期待値ＥＶ）の格納アドレス情報やサイズ情報に関する情報を含ませなくてもよい。
　図６は、アドレスヘッダの第２構成例を示す図である。図５において、各始点アドレス２１１－２１Ｎまたは終点アドレス３１１－３１Ｎのいずれか一方は、サイズ情報に置き換えてもよい。例として図６に終点アドレスをサイズ情報に置き換えた構成例を示す。図６に示すアドレスヘッダ２０が図５と異なる点は、図６において、分割単位１１－１Ｎのサイズ４１１－４１Ｎと、分割単位１１－１Ｎのサイズの反転値４１１’－４１Ｎ’が設けられている点である。つまり、図６では、図５の分割単位１１－１Ｎに対する終点アドレス３１１－３１Ｎの代わりに、分割単位１１－１Ｎのサイズ４１１－４１Ｎがアドレスヘッダ２０の正当性確認情報に格納される。図６の他の構成は、図５の他の構成と同じであるので、重複する説明は省略する。なお、図６は、図５の各終点アドレス３１１－３１Ｎをサイズ情報（４１１－４１Ｎ）に置き換えた構成例を示したが、図５の各終点アドレス３１１－３１Ｎは変更せずに、各始点アドレス２１１－２１Ｎをサイズ情報（４１１－４１Ｎ）に置き換えてもよい。
　図７は、アドレスヘッダの第３構成例を示す図である。図７に示すアドレスヘッダ２０が図５と異なる点は、図７において、分割単位１１－１Ｎのおのおののバリデーション値（期待値ＥＶ）の格納領域の始点アドレス５１１－５１Ｎと終点アドレス６１１－６１Ｎがアドレスヘッダ２０に追加されている点である。また、始点アドレス５１１－５１Ｎのおのおの反転値５１１’－５１Ｎ’と、終点アドレス６１１－６１Ｎのおのおの終反転値６１１’－６１Ｎ’とがアドレスヘッダ２０に追加されている。図７の他の構成は、図５の他の構成と同じであるので、重複する説明は省略する。
　図８は、アドレスヘッダの第４構成例を示す図である。図８に示すアドレスヘッダ２０が図７と異なる点は、図８において、分割単位１１－１Ｎのおのおののサイズ４１１－４１Ｎと分割単位１１－１Ｎのおのおのサイズの反転値４１１’－４１Ｎ’とが設けられている点と、分割単位１１－１Ｎのおのおののバリデーション値（期待値ＥＶ）のサイズ７１１－７１Ｎと分割単位１１－１Ｎのおのおののバリデーション値（期待値ＥＶ）のサイズの反転値７１１’－７１Ｎ’とが設けられている点とである。図８の他の構成は、図７の他の構成と同じであるので、重複する説明は省略する。
　図９は、アドレスヘッダの第５構成例を示す図である。図９に示すアドレスヘッダ２０が図７と異なる点は、図９において、アドレスヘッダ２０に、アドレスヘッダ２０のバリデーション値７００が設けられている点である。これにより、アドレスヘッダ２０の正当性を確認することが可能である。バリデーション値７００は、例えば、アドレスヘッダ２０のチェックサム，ＣＲＣ、また、ハッシュ値とすることができる。これにより、アドレスヘッダ２０の中の情報に対する読み出しの前、あるいは、電子制御装置１の起動時の処理として、アドレスヘッダ２０の正当性確認を行うことで、アドレスヘッダ２０の改ざんを検知することができる。これによって、アドレスヘッダ２０の改ざんによる悪意のある制御用ソフトウェアの実行を回避することができる。図９の他の構成は、図７の他の構成と同じであるので、重複する説明は省略する。なお、アドレスヘッダ２０のバリデーション値７００は、図５～図８のアドレスヘッダ２０に設けても良い。
　（電子制御装置の起動時の動作）
　図１０は、電子制御装置の起動時の動作を説明するフローチャート図である。電子制御装置１の起動時にマイクロコンピュータ２のＣＰＵ３により最初に実行されるのはブートローダー１０である。以下、電子制御装置１の起動時の動作をステップごとに説明する。
　（ステップＳ１）
　ブートローダー１０の実行では、最初にマイクロコンピュータ２の内蔵レジスタ、ＲＡＭ、周辺機器などの初期化を実行する。その後、フラッシュＲＯＭ６に書き込まれている制御用ソフトウェアＳＦＴの正当性を検証する（ステップＳ２～Ｓ５）。
　（ステップＳ２）
　ＣＰＵ３は、アドレスヘッダ２０に保存されている正当性確認情報（分割情報）を読み出す。
　（ステップＳ３）
　次に、ＣＰＵ３は、アドレスヘッダ２０の分割単位数２０１、分割単位１１－１Ｎの始点アドレス２１１－２１Ｎ、および、分割単位１１－１Ｎの終点アドレス３１１－３１Ｎあるいは分割単位１１－１Ｎのサイズ４１１－４１Ｎなどに基づいて、バリデーション値の計算範囲を確定する。
　（ステップＳ４）
　次に、ＣＰＵ３は、アドレスヘッダ２０の分割単位数２０１に基づいてバリデーション値を計算するループ（ＬＯＯＰ）の回数ｎを決定する。この例では、ループ回数ｎは、１～Ｎまでとされる。そして、ＣＰＵ３は、分割単位１ｎのバリデーション値を計算し（ステップＳ４１）、バリデーション値の計算結果を期待値ＥＶと比較し（ステップＳ４２）、比較結果を、たとえば、ＲＡＭ４や内蔵レジスタに保存する（ステップＳ４３）。
　（ステップＳ５）
　次に、ＣＰＵ３は、比較結果の評価を実施する。比較結果の評価において、制御用ソフトウェアＳＦＴが正当であると判定されれば（ＯＫ）、ステップＳ６へ移行する。比較結果の評価において、制御用ソフトウェアＳＦＴが正当ではないと判定されれば（ＮＧ）、ステップＳ７へ移行する。
　（ステップＳ６）
　ＣＰＵ３は、ブートローダー１０の実行を完了し、制御用ソフトウェアＳＦＴへジャンプする。これにより、ＣＰＵ３は、制御用ソフトウェアＳＦＴの実行へ移行する。
　（ステップＳ７）
　ＣＰＵ３は、制御用ソフトウェアＳＦＴへジャンプせず、ブートローダー１０内に留まる。この場合は、追加で必要な初期化処理があればそれを実行し、制御用ソフトウェアＳＦＴの書き換え（リプログラミング）を待つ状態となる。
　ステップＳ４において、制御用ソフトウェアＳＦＴの正当性検証の方法としては、チェックサム、ＣＲＣ（Cyclic Redundancy Check）、ハッシュ値、デジタル署名のうち１つまたは２つ以上を利用する方法がある。例えば、チェックサムを利用する方法では、対象とするアドレス範囲に対してチェックサムを計算し、それをあらかじめフラッシュＲＯＭ６に埋め込まれた正解値である期待値ＥＶまたは既知の正解値と比較することで、制御用ソフトウェアＳＦＴの正当性を検証する。上記のような正当性を検証するための値を、本明細書では、バリデーション値と呼んでいる。
　デジタル署名の場合は、フラッシュＲＯＭ６に保持しているデジタル署名を、あらかじめフラッシュＲＯＭ６に保持した公開鍵または外部との通信によって入手した公開鍵によって復号し、ハッシュ値を取り出す。その後、取り出したハッシュ値を、電子制御装置１自身が、対象とするアドレス範囲に対して計算した値と比較することで正当性を検証する。
　この正当性検証は、制御用ソフトウェアＳＦＴが論理的に分割される場合、その分割単位１１－１Ｎそれぞれに対して行われる。そして、分割単位１１－１Ｎのうちひとつでも正当性が確認できなかった場合は制御用ソフトウェアＳＦＴへのジャンプは行われない。
　上述のように、正当性検証のためには、制御用ソフトウェアＳＦＴの分割単位１１－１Ｎそれぞれに対する分割情報と、場合によっては正当性確認値の正解値（期待値ＥＶ）が埋め込まれている場所の情報が必要となる。それらの情報が、図４の比較例で示した様に、ブートローダー１０の内部に保持されており、リプログラミング機能をブートローダー１０が担っている場合、リプログラミング時にはブートローダー１０は書き換わらない。したがって、制御用ソフトウェアＳＦＴの分割の様態がリプログラミング前後で異なる場合、ブートローダー１０は制御用ソフトウェアＳＦＴの正当性確認を正しく行えなくなる。
　実施例１では、上述したような正当性検証のために必要な情報群を、外部からの書き換えが可能であって、かつ固定もしくは追跡可能な領域へ配置する。そして、正当性検証の際はその領域を参照することで前述した課題を解決する。正当性検証のために必要な情報群を、本明細書では、アドレスヘッダ２０と呼んでいる。アドレスヘッダ２０を配置する場所は、例えば、制御用ソフトウェアＳＦＴを格納するフラッシュＲＯＭ６のコードフラッシュ６１の中の固定領域または任意領域でもよいし、データを格納するフラッシュＲＯＭ６のデータフラッシュ６２（実施例２参照）の中の固定領域または任意領域やＥＥＰＲＯＭの中の固定領域または任意領域でもよい。
　アドレスヘッダ２０をデータフラッシュ６２やＥＥＰＲＯＭの中の任意領域、つまり、フリーアドレスの格納領域に配置してもよい。この場合には、格納されているアドレスヘッダ２０の内容をＲＡＭ４に随時展開するソフトウェアを利用して追跡可能性を確保するのが好ましい。
　（制御用ソフトウェアの正当性確認）
　図１１は、アドレスヘッダを用いた制御用ソフトウェアの正当性確認を行う際のフローチャートである。以下、制御用ソフトウェアの正当性確認の動作をステップごとに説明する。
　（ステップＳ１０）
　まず初めに、コードフラッシュ６１に格納されるアドレスヘッダ２０中の分割単位の個数情報２０１を参照する。
　（ステップＳ１１）
　次に、バリデーション値を計算するループ（ＬＯＯＰ）の回数Ｎを決定する。この例では、ループ回数ｎは、１～Ｎである。
　（ステップＳ１２）
　その後、各分割単位１１－１Ｎについて、各始点アドレス２１１－２１Ｎまたは各終点アドレス３１１－３１Ｎまたは各サイズ情報４１１－４１Ｎを、アドレスヘッダ２０を参照して取得し、それをもとにバリデーション値の計算範囲を確定する。
　（ステップＳ１３）
　そして、バリデーション値の計算を行う。
　（ステップＳ１４）
　コードフラッシュ６１に格納されるアドレスヘッダ２０によって指定される領域（たとえば、図７の５１１－５１Ｎ、６１１－６１Ｎ、図８の５１１－５１Ｎ，７１１－７１Ｎ）に埋め込まれているバリデーション値の期待値ＥＶが参照される。
　（ステップＳ１５）
　計算されたバリデーション値と期待値ＥＶとが比較し、両者が一致する場合はステップＳ１６へ移行し、両者が不一致の場合はステップＳ１７へ移行する。
　（ステップＳ１６）
　コードフラッシュ６１に書き込まれている制御用ソフトウェアＳＦＴが正当であると判断される。
　（ステップＳ１７）
　コードフラッシュ６１に書き込まれている制御用ソフトウェアＳＦＴが正当ではないと判断される。
　なお、バリデーション値の期待値ＥＶが格納される場所が、アドレスヘッダ２０に格納される始点アドレス２１１－２１Ｎまたは終点アドレス３１１－３１Ｎの相対値から決定できる場合（図５、図６参照）は、期待値ＥＶの格納場所に関する情報をアドレスヘッダ２０に含める必要はない。
　なお、図９に示すアドレスヘッダ２０自身のバリデーション値７００を付加した構成の場合、図１０や図１１に示されるアドレスヘッダ２０中の情報に対する読み出しの前、あるいは、ＥＣＵ１の起動時の処理として、バリデーション値７００を用いてアドレスヘッダ２０の正当性確認を行うのが良い。これにより、アドレスヘッダ２０の改ざんを検知することができるので、アドレスヘッダ２０の改ざんによる悪意のあるソフトウェアの実行を回避することができる。
　制御用ソフトウェアＳＦＴに関するバリデーション値の検証は、ＥＣＵ１の起動時のほか、リプログラミング直後にも行われる。これは、意図した制御用ソフトウェアが正しく書き込まれたかどうかを検証するための操作であり、リプログラミングを行うためのツール（診断装置）からのリクエストをトリガーとして行われる場合や、データ通信の終了リクエストの後処理として行われる場合が考えられる。
　リプログラミング前後で分割単位の構成、つまり分割単位の個数やアドレス配置が変化しない場合はアドレスヘッダ２０を書き換える必要はないが、分割単位の構成が変わる場合は、その構成に合わせてアドレスヘッダ２０も書き換わっていることが必要となる。バリデーション値の検証処理は、図１１のように、アドレスヘッダ２０の内容によって動的に行われるため、アドレスヘッダ２０が適切に書き換わっていれば、リプログラミング前後で制御用ソフトウェアＳＦＴの分割単位の構成が異なっていても、問題なく制御用ソフトウェアＳＦＴに係るバリデーション値を検証することができる。
　実施例１では、アドレスヘッダ２０をコードフラッシュ６１の所望のアドレス領域に格納する構成例を説明した。実施例２は、図３に示したアドレスヘッダ２０をデータフラッシュ６２の所望のアドレス領域に格納する構成例である。以下、実施例２について図１２～図１６を用いて説明する。
　図１２は、アドレスヘッダをデータフラッシュのフリーアドレスに格納する場合の構成例である。図１３は、図１２のアドレスヘッダ２０の構成例を示す図である。図１４は、データフラッシュに格納されたアドレスヘッダを用いた制御用ソフトウェアの正当性確認を行う際のフローチャートである。
　図１２には、ＲＡＭ４のアドレス空間と、フラッシュＲＯＭ６のコードフラッシュ６１およびデータフラッシュ６２のアドレス空間が示されている。コードフラッシュ６１には、ブートローダー１０と、制御用ソフトウェアＳＦＴの分割単位１１－１Ｎとが格納される。データフラッシュ６２には、アドレスヘッダ２０と、データフラッシュ格納物３０とが格納される。ＲＡＭ４には、データフラッシュ６２の内容（２０、３０）をＲＡＭ４に随時展開する展開ソフトウェアによって、アドレスヘッダ２０のコピー２０’およびデータフラッシュ格納物３０のコピー３０’が格納されている。
　図１３に示す様に、アドレスヘッダ２０およびアドレスヘッダ２０のコピー２０’は、制御用ソフトウェアＳＦＴの分割単位の個数２０１と、それぞれの分割単位１１－１Ｎに対する始点アドレス２１１－２１Ｎと終点アドレス３１１－３１Ｎと、それぞれの分割単位１１－１Ｎに対するバリデーション値が埋め込まれている領域の始点アドレス５１１－５１Ｎおよび終点アドレス６１１－６１Ｎが保持されている。なお、図６と図８の関係と同様に、各始点アドレスまたは終点アドレスのいずれかは、サイズ情報（各分割単位１１－１Ｎのサイズ４１１－４１Ｎ，各分割単位１１－１Ｎのバリデーション値のサイズ７１１－７１Ｎ）に置き換えてもよい。
　アドレスヘッダ２０の値を参照する場合は、ＲＡＭ４上のアドレスヘッダ２０のコピー２０’の値を参照する。アドレスヘッダ２０を、データフラッシュ６２のフリーアドレスではなく、データフラッシュ６２の固定領域に配置する場合、同様の展開ソフトウェアを利用してＲＡＭ４上の値を参照してもいいし、データフラッシュ６２のアドレスヘッダ２０を直接参照してもよい。
　図１４は、データフラッシュに格納されたアドレスヘッダを用いた制御用ソフトウェアの正当性確認を行う際のフローチャートである。図１４のフローチャートが図１１のフローチャートと異なる点は、図１４において、ステップＳ１０Ａに示す様に、ＲＡＭ４に展開されたアドレスヘッダ２０（厳密には、アドレスヘッダ２０のコピー２０’）が参照されることである。この場合、ステップＳ１２、Ｓ１４に記載のアドレスヘッダも、アドレスヘッダ２０のコピー２０’に対応する。図１４の他のステップは、図１１の他のステップと同じであるので、重複する説明は省略するが、以下に簡単に説明する。
　まず初めに、データフラッシュ６２に格納されるアドレスヘッダ２０はＲＡＭ４に展開されている。アドレスヘッダ２０中の分割単位の個数情報２０１をＲＡＭ４に展開されたアドレスヘッダ２０コピー２０’を経由して参照し（ステップＳ１０Ａ）、バリデーション値を計算するループの回数Ｎを決定する（ステップＳ１１）。その後、各分割単位について、アドレスまたはアドレス・サイズ情報を参照し（ステップＳ１２）、それをもとにバリデーション値の計算範囲を確定し、バリデーション値の計算を行う（ステップＳ１３）。
　計算したバリデーション値は、データフラッシュ６２に格納されるアドレスヘッダ２０（厳密には、アドレスヘッダ２０のコピー２０’）によって指定される領域に埋め込まれている期待値ＥＶと比較され（ステップＳ１４、Ｓ１５）、両者が一致すれば書き込まれている制御用ソフトウェアＳＦＴが正当であると判断される（ステップＳ１６）。なお、バリデーション値の期待値ＥＶが格納される場所が、アドレスヘッダ２０に格納されるアドレス（始点アドレス２１１－２１Ｎ、終点アドレス３１１－３１Ｎ）の相対値から決定できる場合は、その情報（５１１－５１Ｎ，６１１－６１Ｎ）をアドレスヘッダ２０に含める必要はない。
　図１５は、図１２のアドレスヘッダ２０の他の構成例を示す図である。図１５に示すアドレスヘッダ２０が図１３に示すアドレスヘッダ２０と異なる点は、図１５において、アドレスヘッダ２０自身のバリデーション値７００を付加した点である。図１５の他の構成は、図１３の他の構成と同じであるので、重複する説明は省略する。
　アドレスヘッダ２０中の情報に対する読み出しの前、あるいはＥＣＵ１の起動時の処理、あるいはＲＡＭ４への展開処理の一環として、図１５のアドレスヘッダ２０自身のバリデーション値７００を用い、アドレスヘッダ２０の正当性確認を行うのが良い。これにより、アドレスヘッダ２０の改ざんを検知することができので、アドレスヘッダ２０の改ざんによる悪意のある制御用ソフトウェアの実行を回避することができる。
　制御用ソフトウェアＳＦＴに関するバリデーション値の検証は、ＥＣＵ１の起動時のほか、リプログラミング直後にも行われる。これは、意図した制御用ソフトウェアＳＦＴが正しく書き込まれたかどうかを検証するための操作であり、リプログラミングを行うためのツール（診断器）からのリクエストをトリガーとして行われる場合や、データ通信の終了リクエストの後処理として行われる場合が考えられる。
　リプログラミング前後で分割単位１１－１Ｎの構成、つまり分割単位１１－１Ｎの個数やアドレス配置が変化しない場合はアドレスヘッダ２０を書き換える必要はないが、分割単位１１－１Ｎの構成が変わる場合は、その構成に合わせてアドレスヘッダ２０も書き換わっていることが必要となる。バリデーション値の検証処理は、図１４のように、アドレスヘッダ２０の内容によって動的に行われるため、アドレスヘッダ２０が適切に書き換わっていれば、リプログラミング前後で分割単位１１－１Ｎの構成が異なっていても問題なくバリデーション値を検証することができる。
　アドレスヘッダ２０の書き換え方法について以下説明する。
　実施例１においては、制御用ソフトウェアＳＦＴのリプログラミングと同様に書き換える方法がある。この場合、アドレスヘッダ２０はソフトウェアとして扱うことができる。アドレスヘッダ２０はひとつのソフトウェアの分割単位として扱ってもよいし、分割単位に内包されるものとして扱ってもよい。
　実施例２では、アドレスヘッダ２０をソフトウェアではなくデータとして扱っているため、リプログラミングの手続きではアドレスヘッダ２０が更新されない。そのため、アドレスヘッダ２０を更新する場合、データ書き込み用のサービスを用いてアドレスヘッダ２０を更新する。この場合、アドレスヘッダ２０にデータ識別子を付与して、当該識別子を利用することで更新するデータをアドレスヘッダ２０として指定し、その識別子に続いてデータを送付することで、アドレスヘッダ２０を更新する。あるいは、固定領域にアドレスヘッダ２０が配置されている場合、アドレスを直接指定することで、更新するデータを指定する方法もある。データ識別子を利用する方法でも、アドレスを直接指定する方法でも、アドレスヘッダ２０をデータとして扱う場合は実施例２に適用することが可能である。
　図１６は、制御用ソフトウェア、アドレスヘッダ、メタデータからなるリプログラミングデータパッケージを示す図である。アドレスヘッダ２０をデータとして扱う場合、制御用ソフトウェアＳＦＴとの組として管理するのが好ましい。例えば、図１６のように、制御用ソフトウェアのＲＯＭファイルと、アドレスヘッダ２０のＲＯＭファイルと、メタデータ４０の組をひとつのリプログラミングデータ５０として管理すれば、制御用ソフトウェアＳＦＴのメモリマップとアドレスヘッダ２０の不一致によって制御用ソフトウェアＳＦＴの正当性検証が正しく行えないという事態は回避することができる。
　メタデータ４０には、例えば、制御用ソフトウェアＳＦＴの分割単位の個数やアドレス・サイズ情報、アドレスヘッダ２０のアドレス・サイズ情報やデータ識別子、リプログラミングやデータ書き込み時に使用する情報転送方式を指定するオプション情報、ＲＯＭファイルのデータ形式を示す情報などを含めることができる。ただし、制御用ソフトウェアＳＦＴの分割単位の個数やアドレスヘッダ２０のアドレス・サイズ情報はＲＯＭファイルそのものが保持することも可能であるため、その場合はメタデータ４０には当該情報を記載しなくてもよい。
　さらに、アドレスヘッダ２０をデータとして扱う場合、かつ制御用ソフトウェアＳＦＴが正当であると判断された場合のジャンプ先がアドレスヘッダ２０の内容をもとに決定される場合、アドレスヘッダ２０のみを書き換えることでコードフラッシュ６１に格納される制御用ソフトウェアＳＦＴの分割単位１１－１Ｎのうち、ＥＣＵ１の起動時に実行される分割単位を制御することができる。それを利用すると、例えば、通常制御モードと工場検査モードとの切り替えなどが可能となる。
　例えば、コードフラッシュ６１上には分割単位１１、１２、１３、１４が存在して、かつ分割単位１１、１２の組、および、分割単位１３、１４の組でそれぞれ１つの制御用ソフトウェアＳＦＴとして成立するような構成となっていた場合を仮定する。そして、ブートローダー１０は正当性検証によって制御用ソフトウェアＳＦＴが正当であると判断した後にジャンプする先を、アドレスヘッダ２０に含まれている分割単位１１－１４の情報のうち、最初に発見した分割単位の始点アドレスとする場合を仮定する。
　上記２つの仮定のもと、いま、アドレスヘッダ２０には分割単位１１、１２のアドレス・サイズ情報と分割単位の個数は２個であるという情報が含まれているとする。この状態でＥＣＵ１が起動すると、図１１または図１４のフローに従い制御用ソフトウェアＳＦＴの正当性が検証される。書き込まれている制御用ソフトウェアＳＦＴが正当であると判断され、かつブートローダー１０が最初に発見する分割単位の始点アドレスが分割単位１１のものであるとすると、ブートローダー１０から分割単位１１へのジャンプが発生する。
分割単位１１、１２からなる制御用ソフトウェアＳＦＴが、分割単位１３、１４からなる制御用ソフトウェアＳＦＴに依存しない独立なものであれば、分割単位１３、１４は実行されず、分割単位１１、１２からなる制御用ソフトウェアＳＦＴのみが実行される状態となる。
　ここで、データ書き込みサービスによってアドレスヘッダ２０が書き換えられ、アドレスヘッダ２０に含まれる情報が分割単位１３、１４のアドレス・サイズ情報と分割単位の個数は２個であるというものに変わったとする。この状態でＥＣＵ１が再起動すると、ブートローダー１０は分割単位１３、１４の正当性検証を開始する。正当性検証により分割単位１３、１４それぞれが正当であると判断され、かつブートローダー１０が最初に発見する分割単位の始点アドレスが分割単位１３のものであるとすると、ブートローダー１０から分割単位１３へのジャンプが発生する。先ほどと同様に、分割単位１３、１４からなる制御用ソフトウェアＳＦＴが、分割単位１１、１２からなる制御用ソフトウェアＳＦＴに依存しない独立なものであれば、分割単位１１、１２は実行されず、分割単位１３、１４からなる制御用ソフトウェアＳＦＴのみが実行される状態になる。
　以上のように、アドレスヘッダ２０をデータとして扱う場合、かつ制御用ソフトウェアＳＦＴが正当であると判断された場合のジャンプ先がアドレスヘッダ２０の内容をもとに決定される場合、アドレスヘッダ２０のみを書き換えることで、コードフラッシュ６１に格納される制御用ソフトウェアＳＦＴの分割単位のうち、起動時に実行される分割単位を制御することができる。これを利用すると、例えば、通常制御モードと工場検査モードとの切り替えなどが可能となる。
　以上、本発明者によってなされた発明を実施形態および実施例に基づき具体的に説明したが、本発明は、上記実施形態および実施例に限定されるものではなく、種々変更可能であることはいうまでもない。
１：ＥＣＵ、２：マイコン、３：ＣＰＵ、４：ＲＡＭ、５：通信モジュール、６：フラッシュＲＯＭ、１０：ブートローダー、１１～１Ｎ：制御ソフトウェアの分割単位、２０：アドレスヘッダ、２０´：ＲＡＭ上に展開したアドレスヘッダ、３０：データフラッシュ格納物、３０´：ＲＡＭ上に展開したデータフラッシュ格納物、４０：メタデータ、５０：リプログラミングデータパッケージ、２０１：分割単位数、２０１´：分割単位数の反転値、２１１～２１Ｎ：分割単位１Ｎの始点アドレス、２１１´～２１Ｎ´：分割単位１Ｎの始点アドレスの反転値、３１１～３１Ｎ：分割単位１Ｎの終点アドレス、３１１´～３１Ｎ´：分割単位１Ｎの終点アドレスの反転値、４１１～４１Ｎ：分割単位１Ｎのサイズ、４１１´～４１Ｎ´：分割単位１Ｎのサイズの反転値、５１１～５１Ｎ：分割単位１Ｎのバリデーション値始点アドレス、５１１´～５１Ｎ´：分割単位１Ｎのバリデーション値始点アドレスの反転値、６１１～６１Ｎ：分割単位１Ｎのバリデーション値終点アドレス、６１１´～６１Ｎ´：分割単位１Ｎのバリデーション値終点アドレスの反転値、７００：アドレスヘッダのバリデーション値

Claims (11)

  1. 　ＣＰＵと、不揮発性メモリと、を含むマイクロコンピュータを含み、
    　前記不揮発性メモリは、
    　　起動用ソフトウェアと、
    　　制御用ソフトウェアと、
    　　前記制御用ソフトウェアの正当性を確認する為の正当性確認情報と、を含み、
    　前記不揮発性メモリにおける前記正当性確認情報の格納領域は、前記起動用ソフトウェアの格納領域と異なる、電子制御装置。
  2. 　請求項１の電子制御装置であって、
    　前記マイクロコンピュータは、さらに、外部との通信を行うための通信部を含み、
    　前記起動用ソフトウェアは、前記制御用ソフトウェアのリプログラミング機能を有し、
    　前記リプログラミング機能において、
    　　前記制御用ソフトウェアと前記正当性確認情報とを前記不揮発性メモリから消去し、
    　　前記通信部からの新規な制御用ソフトウェアと新規な正当性確認情報とを前記不揮発性メモリへ書き込み、
    　　前記不揮発性メモリに書き込まれた前記正当性確認情報に基づいて、前記不揮発性メモリに書き込まれた前記制御用ソフトウェアの正当性を検証する、電子制御装置。
  3. 　請求項２の電子制御装置であって、
    　前記起動用ソフトウェアは、前記正当性確認情報に基づいて前記制御用ソフトウェアの正当性を検証し、
    　前記制御用ソフトウェアの正当性が確認された後、前記ＣＰＵは前記制御用ソフトウェアへジャンプする、電子制御装置。
  4. 　請求項２の電子制御装置であって、
    　前記不揮発性メモリは、
    　　主にソフトウェアが格納される第１格納領域と、
    　　主にデータが格納される第２格納領域と、を含み、
    　前記起動用ソフトウェアおよび前記制御用ソフトウェアは前記第１格納領域に格納され、
    　前記正当性確認情報は、前記第１格納領域、または、前記第２格納領域に格納される、電子制御装置。
  5. 　請求項４の電子制御装置であって、
    　前記マイクロコンピュータは、さらに、揮発性メモリを含み、
    　前記正当性確認情報が前記第２格納領域に格納された場合において、
    　　前記第２格納領域に格納された前記正当性確認情報は、前記揮発性メモリに展開され、
    　　前記揮発性メモリに展開された前記正当性確認情報を参照することにより、前記不揮発性メモリに書き込まれた前記正当性確認情報に基づいた前記制御用ソフトウェアの正当性の検証を行う、電子制御装置。
  6. 　請求項４の電子制御装置であって、
    　前記不揮発性メモリは、消去ブロックと、前記消去ブロックに対応して設けられた複数の書込みブロックと、を含み、
    　前記消去ブロックの単位でデータの消去が可能であり、
    　前記書込みブロックの単位でデータの書き込みが可能である、電子制御装置。
  7. 　請求項４の電子制御装置であって、
    　前記制御用ソフトウェアは、前記第１格納領域に、複数の分割単位に分割されて格納され、
    　前記複数の分割単位のおのおのは、期待値を含み、
    　前記正当性確認情報は、
    　　前記複数の分割単位の分割単位数と、
    　　前記複数の分割単位のおのおのの始点アドレスと、
    　　前記複数の分割単位のおのおのの終点アドレスまたはサイズ情報と、を含み、
    　前記制御用ソフトウェアの正当性の検証は、前記複数の分割単位のそれぞれに対して実施され、前記複数の分割単位ごとに、対応する始点アドレスと対応する終点アドレスまたは対応するサイズ情報に基づいて、サム値、Cyclic Redundancy Check（ＣＲＣ）値または、ハッシュ値を計算することによりバリデーション値を計算し、前記バリデーション値と対応する期待値とを比較することで行われる、電子制御装置。
  8. 　請求項７の電子制御装置であって、
    　前記正当性確認情報は、さらに、前記分割単位数の反転値と、前記始点アドレスの反転値または前記サイズ情報の反転値と、を含む、電子制御装置。
  9. 　請求項８の電子制御装置であって、
    　前記正当性確認情報は、さらに、
    　　前記複数の分割単位のおのおのの対応する期待値の始点アドレスと、
    　　前記複数の分割単位のおのおのの対応する期待値の終点アドレスまたはサイズ情報と、とを含む、電子制御装置。
  10. 　請求項９の電子制御装置であって、
    　前記正当性確認情報は、さらに、前記正当性確認情報のバリデーション値を含む、電子制御装置。
  11. 　ＣＰＵと不揮発性メモリと外部との通信を行うための通信部とを含むマイクロコンピュータを含み、前記不揮発性メモリは起動用ソフトウェアと制御用ソフトウェアと前記制御用ソフトウェアの正当性を確認する為の正当性確認情報とを含み、前記不揮発性メモリにおける前記正当性確認情報の格納領域は、前記起動用ソフトウェアの格納領域と異なる電子制御装置の前記制御用ソフトウェアの更新方法であって、
    　前記起動用ソフトウェアの前記制御用ソフトウェアのリプログラミング機能を有効化し、
    　前記制御用ソフトウェアと前記正当性確認情報とを前記不揮発性メモリから消去し、
    　前記通信部からの新規な制御用ソフトウェアと新規な正当性確認情報とを前記不揮発性メモリへ書き込み、
    　前記不揮発性メモリに書き込まれた前記正当性確認情報に基づいて、前記不揮発性メモリに書き込まれた前記制御用ソフトウェアの正当性を検証する、
    　制御用ソフトウェアの更新方法。
PCT/JP2021/004264 2020-06-17 2021-02-05 電子制御装置および制御用ソフトウェアの更新方法 WO2021255984A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE112021002282.2T DE112021002282T5 (de) 2020-06-17 2021-02-05 Elektronische steuervorrichtung und aktualisierungsverfahren für steuerungssoftware
US18/010,297 US20230252153A1 (en) 2020-06-17 2021-02-05 Electronic control device and updating method for control software
JP2022532271A JPWO2021255984A1 (ja) 2020-06-17 2021-02-05

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-104293 2020-06-17
JP2020104293 2020-06-17

Publications (1)

Publication Number Publication Date
WO2021255984A1 true WO2021255984A1 (ja) 2021-12-23

Family

ID=79267776

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/004264 WO2021255984A1 (ja) 2020-06-17 2021-02-05 電子制御装置および制御用ソフトウェアの更新方法

Country Status (4)

Country Link
US (1) US20230252153A1 (ja)
JP (1) JPWO2021255984A1 (ja)
DE (1) DE112021002282T5 (ja)
WO (1) WO2021255984A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003196097A (ja) * 2001-12-26 2003-07-11 Fujitsu Ltd プロセッサおよびそのブート方法
JP2007257473A (ja) * 2006-03-24 2007-10-04 Mitsubishi Electric Corp 車載制御装置
JP2014179047A (ja) * 2013-03-15 2014-09-25 Ricoh Co Ltd 情報処理装置
JP2019061520A (ja) * 2017-09-27 2019-04-18 日立オートモティブシステムズ株式会社 電子制御装置及び制御プログラム検証方法
JP2019109745A (ja) * 2017-12-19 2019-07-04 日立オートモティブシステムズ株式会社 自動車用電子制御装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3583829B2 (ja) * 1995-04-13 2004-11-04 株式会社日立製作所 外部記憶サブシステムの制御方法および制御装置
JP4212503B2 (ja) * 2004-03-30 2009-01-21 シャープ株式会社 制御システム、制御装置、記憶装置、及びコンピュータプログラム
JP2016167113A (ja) 2015-03-09 2016-09-15 富士重工業株式会社 車載用制御ユニット
JP6441171B2 (ja) * 2015-06-12 2018-12-19 東芝メモリ株式会社 メモリシステム
TWI557561B (zh) * 2016-02-05 2016-11-11 群聯電子股份有限公司 記憶體管理方法、記憶體控制電路單元與記憶體儲存裝置
JP6448571B2 (ja) * 2016-03-08 2019-01-09 東芝メモリ株式会社 ストレージシステム、情報処理システムおよび制御方法
JP6699324B2 (ja) 2016-04-26 2020-05-27 株式会社デンソー 電子制御装置及びデータ書換えシステム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003196097A (ja) * 2001-12-26 2003-07-11 Fujitsu Ltd プロセッサおよびそのブート方法
JP2007257473A (ja) * 2006-03-24 2007-10-04 Mitsubishi Electric Corp 車載制御装置
JP2014179047A (ja) * 2013-03-15 2014-09-25 Ricoh Co Ltd 情報処理装置
JP2019061520A (ja) * 2017-09-27 2019-04-18 日立オートモティブシステムズ株式会社 電子制御装置及び制御プログラム検証方法
JP2019109745A (ja) * 2017-12-19 2019-07-04 日立オートモティブシステムズ株式会社 自動車用電子制御装置

Also Published As

Publication number Publication date
JPWO2021255984A1 (ja) 2021-12-23
US20230252153A1 (en) 2023-08-10
DE112021002282T5 (de) 2023-04-13

Similar Documents

Publication Publication Date Title
US11436002B2 (en) Systems and methods for failsafe firmware upgrades
CN110178114B (zh) 车辆控制装置以及程序更新系统
US7404028B2 (en) ECU identification retention across reprogramming events
JP7013918B2 (ja) 車両制御装置、プログラム更新方法およびプログラム
TWI805946B (zh) 內嵌式系統及控制非揮發性記憶體之方法
JP4480815B2 (ja) メモリ書き換え方法及びコンピュータシステム
US20060218340A1 (en) Data validity determining method for flash EEPROM and electronic control system
CN112685338A (zh) 包括安全可修补rom的半导体装置及其修补方法
KR102598510B1 (ko) 소프트웨어의 무결성 검증 방법 및 그 장치
JP2018160207A (ja) 車載制御装置、及び、プログラム更新ソフトウェア
JP7224472B2 (ja) 車両制御装置、更新プログラム、プログラム更新システム、及び書込み装置
WO2021171906A1 (ja) 情報処理装置、及びプログラム起動方法
WO2021255984A1 (ja) 電子制御装置および制御用ソフトウェアの更新方法
US11169828B2 (en) Electronic control unit and method for verifying control program
US11768669B2 (en) Installing application program code on a vehicle control system
BR102022000011A2 (pt) Ota mestre, método de controle de atualização, meio de armazenamento não transitório, e veículo
CN111079194A (zh) 计算装置和用于该计算装置的运行方法
US20230185564A1 (en) Control device and management method
JP6699591B2 (ja) エンジン制御装置
JP6568826B2 (ja) 電子制御装置
US20230418591A1 (en) Firmware update method of a flash bootloader in a micro controller unit for a vehicle
US20240220625A1 (en) Method of updating software of electronic control unit of vehicle
WO2021166603A1 (ja) 情報処理装置、プログラム更新システム、及びプログラム更新方法
JP2023016643A (ja) 電子制御装置
CN113946356A (zh) 电子控制器程序的更新方法、装置、电子控制器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21826632

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022532271

Country of ref document: JP

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 21826632

Country of ref document: EP

Kind code of ref document: A1