JP7302250B2 - electronic controller - Google Patents

Description

The present disclosure relates to electronic controllers.

2. Description of the Related Art There is known a technique for updating software of a control device when the control device is unable to operate because power supply to the control device by the control device is stopped (see, for example, Patent Literature 1). .

Japanese Patent No. 4809418

In the technique described in Patent Document 1, software is updated when the ignition switch is turned off. Therefore, at least until the update of the software is completed, power supply from the main relay to the electronic control unit is continued by relay control, for example. However, as the scale of software increases, the time required to update the software increases. Therefore, the relay control time becomes longer and the load on the battery increases.

One aspect of the present disclosure is to provide an electronic control device capable of quickly completing software update while avoiding an increase in relay control time.

An electronic control unit (2, 22, 52) in one aspect of the present disclosure includes a first storage unit (11), an inspection unit (13, S301, S407, S421), a processing unit (10, S505, S513), , a determination unit (13, S403) and an update unit (13, 15, S405). The first storage stores software. The inspection unit inspects whether the software to be activated is proper software when the electronic control unit is activated. The processing unit executes processing based on the software stored in the first storage unit when the inspection unit obtains an inspection result that the software to be activated is proper software. The determination unit determines whether or not the software stored in the first storage unit needs to be updated when the electronic control unit is started. The update unit transfers the update software stored in the second storage unit (12, 32, 62) to the first storage unit when the determination unit determines that the update is necessary. update the software stored in When the software stored in the first storage unit is updated by the update unit, the inspection unit transfers the updating software stored in the second storage unit to the first storage unit in parallel with the processing of: It is configured to check whether the software to be activated is proper software.

According to the electronic control device configured in this manner, when the electronic control device is activated, it is determined whether or not the software stored in the first storage unit needs to be updated. When it is determined that update is necessary, the update software stored in the second storage is transferred to the first storage to update the software stored in the first storage. Therefore, the relay control period can be shortened and the load on the battery can be reduced compared to the case where equivalent transfer is performed during the relay control after the ignition switch is turned off.

Moreover, when the process of transferring the update software stored in the second storage unit to the first storage unit is executed, the inspection unit, in parallel with the transfer processing by the update unit, determines whether the software to be activated is appropriate. software. Therefore, after the process of transferring the update software stored in the second storage unit to the first storage unit is executed, the software stored in the first storage unit is read again, and then the software is changed to the correct software. Transfer and check can be completed more quickly than in the case of checking whether or not the transfer and check are executed in parallel. Therefore, it is possible to suppress deterioration in the start-up performance of the electronic control unit due to the execution of the software update.

FIG. 1 is a block diagram showing the configuration of an in-vehicle network system including a vehicle control device according to the first embodiment. FIG. 2 is an explanatory diagram for explaining the states of the first memory and the second memory before updating software is stored in the second memory. FIG. 3 is an explanatory diagram for explaining the states of the first memory and the second memory immediately after updating software is stored in the second memory. FIG. 4 is an explanatory diagram for explaining the states of the first memory and the second memory immediately after the bootloader is transferred from the second memory to the first memory. FIG. 5 is an explanatory diagram for explaining the states of the first memory and the second memory immediately after the application 1 is transferred from the second memory to the first memory. FIG. 6 is an explanatory diagram for explaining the states of the first memory and the second memory after the transfer from the second memory to the application N is completed. FIG. 7 is a flow chart of installation processing during relay control executed by the CPU. FIG. 8 is a flowchart of boot loader update processing executed by the CPU. FIG. 9 is a flowchart of secure boot processing executed in the HSM. FIG. 10 is a flowchart of application n verification processing executed in the HSM. FIG. 11 is a flow chart of soft activation processing executed by the CPU. FIG. 12 is a timing chart when transfer is executed in the relay control section. FIG. 13 is a timing chart in the case of executing transfer after IG-ON and then executing secure boot. FIG. 14 is a timing chart when transfer is executed after IG-ON and secure boot is executed in parallel with the transfer. FIG. 15 is a block diagram showing the configuration of an in-vehicle network system including the vehicle control device of the second embodiment. FIG. 16 is a block diagram showing the configuration of an in-vehicle network system including the vehicle control device of the third embodiment.

The electronic control unit described above will now be described with reference to exemplary embodiments.
(1) First embodiment [Configuration of electronic control unit and in-vehicle network system]
As shown in FIG. 1, the in-vehicle network system 1 includes an ECU 2, a repromaster ECU 3, a DCM 5, a main relay 6, and the like. ECU is an abbreviation for Electronic Control Unit. DCM is an abbreviation for Data Communication Module. The ECU 2 is configured to communicate with the Repromaster ECU 3 via the global bus 7 . The ECU 2 is configured to receive power via the main relay 6 . The in-vehicle network system 1 includes a plurality of ECUs in addition to the ECU 2, but they are omitted from FIG.

The repro master ECU 3 is an ECU that manages reprogramming (that is, program update) of the ECUs (for example, the ECU 2) included in the in-vehicle network system 1. FIG. When update software is provided from a device outside the vehicle, the repro master ECU 3 provides the update software to the ECU (for example, the ECU 2) included in the in-vehicle network system 1. FIG. In the case of this embodiment, the Repromaster ECU 3 is an ECU that functions as a gateway. The repro master ECU 3 relays data transmitted and received between the devices forming the in-vehicle network system 1 and between the devices forming the in-vehicle network system 1 and devices outside the vehicle. The DCM 5 is a wireless communication device for communicating with devices outside the vehicle.

The main relay 6 is configured to supply electric power from the power supply side to onboard equipment such as the ECU 2 when the ignition is turned on (hereinafter referred to as IG-ON). When the ignition is turned off (hereinafter referred to as IG-OFF), control (hereinafter referred to as relay control) continues to supply electric power from the power supply side to the vehicle-mounted equipment such as the ECU 2 for a predetermined period of time. ) is configured to run

ECU2 is provided with CPU10, the 1st memory 11, the 2nd memory 12, HSM13, and DMAC15. CPU is an abbreviation for Central Processing Unit. HSM is an abbreviation for Hardware Security Module. DMAC is an abbreviation for DMA Controller. DMA is an abbreviation for Direct Memory Access.

The CPU 10 is configured to execute various processes based on software stored in the first memory 11 . For example, when the ECU 2 controls the controlled object, the CPU 10 executes processing for controlling the controlled object based on the control program stored in the first memory 11 . In addition, the CPU 10 also executes processing for updating software stored in the first memory 11, and the like, which will be described later in detail.

The first memory 11 and the second memory 12 are composed of nonvolatile memories (for example, flash memories). The first memory 11 stores software executed by the CPU 10 when the ECU 2 operates. The second memory 12 stores update software when the software stored in the first memory 11 is updated.

The HSM 13 is a device that executes processing (hereinafter also referred to as secure boot) for checking whether or not software to be activated (that is, software to be executed by the CPU 10) is proper software when the ECU 2 is activated. is. As a result of the inspection, if the software is proper software, the HSM 13 notifies the CPU 10 that the software can be activated. As a result of the inspection, if the software is not proper software, the HSM 13 notifies the CPU 10 that activation is impossible. For example, when the HSM 13 detects that software has been tampered with, the HSM 13 notifies the CPU 10 that activation is not possible. Based on the notification from the HSM 13, the CPU 10 activates the software only when it is notified that the software can be activated. This can prevent the CPU 10 from starting unauthorized software.

The DMAC 15 is a device configured to control DMA transfers performed between devices within the ECU 2 . Although details will be described later, in the case of this embodiment, DMA transfer is executed under the control of the DMAC 15 when transferring the update software stored in the second memory 12 to the first memory 11 . As a result, data can be transferred from the first memory 11 to the second memory 12 without going through the CPU 10, and data can be transferred more quickly than when data is transferred through the CPU 10. FIG. Also, if the DMAC 15 executes DMA transfer, the load on the CPU 10 and the HSM 13 can be reduced compared to the case of transferring data via the CPU 10 .

[State Transition of First Memory 11 and Second Memory 12]
Next, state transitions of the first memory 11 and the second memory 12 will be described with reference to FIGS. 2 to 6. FIG. In this embodiment, the first memory 11 and the second memory 12 store a boot loader and N applications from application 1 to application N. FIG. Also, the first memory 11 and the second memory 12 are configured to store state information indicating the state of the software stored in the first memory 11 and the second memory 12 in association with the software. State information is information for maintaining memory consistency between the first memory 11 and the second memory 12 . In this embodiment, the MSI protocol is adopted as a protocol for updating state information. In the MSI protocol, one of update state M, shared state S, and invalid state I is set as the state of each piece of software.

When software update is unnecessary, the same software is stored in both the first memory 11 and the second memory 12, as shown in FIG. In FIG. 2, in order to clearly show that the same software is stored in both the first memory 11 and the second memory 12, version information of each software is also shown. In the present embodiment, if the version information matches in both the first memory 11 and the second memory 12, it means that the same software is stored in both the first memory 11 and the second memory 12. .

However, such version information is merely a concept introduced in this embodiment for simply explaining whether or not the same software is stored in the first memory 11 and the second memory 12 . That is, in terms of implementation, it may be configured such that whether or not the same software is stored in the first memory 11 and the second memory 12 can be determined by information other than the version information. Information other than the version information may be, for example, a hash value generated from each piece of software or update date/time information of each piece of software.

As shown in FIG. 2, when the same software is stored in both the first memory 11 and the second memory 12, the state information corresponding to the software stored in the first memory 11 and the second memory 12 is , are in the shared state S. On the other hand, the ECU 2 may receive update software from outside the vehicle via the in-vehicle network. When the ECU 2 receives the update software, the update software is stored in the second memory 12 as shown in FIG.

At this stage, the consistency between the first memory 11 and the second memory 12 is lost. changed to M. The example shown in FIG. 3 is an example in which all the software has been rewritten in the second memory 12 and the state information corresponding to each of all the software is in the update state M. In the example shown in FIG. At this time, since the first memory 11 is not rewritten, all the state information corresponding to the software stored in the first memory 11 remains in the shared state S.

Next, when the IG is turned off while the update software is stored in the second memory 12, the CPU 10 and the HSM 13 execute processing described later, and the update software stored in the second memory 12 is updated. A bootloader is transferred to the first memory 11 . When this transfer is completed, as shown in FIG. 4, the bootloaders stored in the first memory 11 and the second memory 12 are the same, and the states corresponding to the bootloaders in the first memory 11 and the second memory 12 are the same. The information is changed to the shared state S. Also, at this stage, the state information corresponding to each application from application 1 to application N in the second memory 12 is changed to invalid state I.

Next, when the IG-ON is turned on in a state where the transfer of the boot loader is completed, the CPU 10 and the HSM 13 execute processing described later, and update application 1 to application N stored in the second memory 12 are updated. is transferred to the first memory 11 . When the transfer of the application 1 is completed, as shown in FIG. 5, the application 1 stored in each of the first memory 11 and the second memory 12 becomes the same and corresponds to the application 1 in the first memory 11 and the second memory 12. state information is changed to shared state S. After that, the application 2 and subsequent ones are also transferred in order, and the state information corresponding to the application 2 and later in the first memory 11 and the second memory 12 is changed to the sharing state S as shown in FIG.

In this manner, the ECU 2 can determine whether or not the software stored in the first storage unit needs to be updated based on the state information as described above. Therefore, old software and new software can be managed based on the state information, and consistency between the first storage unit and the second storage unit can be appropriately guaranteed.

[Processing executed in CPU 10 and HSM 13]
Next, processing executed by the CPU 10 and the HSM 13 will be described with reference to flowcharts of FIGS. 7 to 11. FIG.

[Processing executed in CPU 10 when IG-OFF]
The installation process during relay control shown in FIG. 7 is executed by the CPU 10 when the IG is turned off in the vehicle. When this process is started, the CPU 10 refers to the state of the boot loader in the second memory 12 in S101. Subsequently, in S103, the CPU 10 determines whether the state of the boot loader in the second memory 12 is the update state M or not. If the state of the boot loader in the second memory 12 is the update state M, the determination result in S103 is TRUE, and in S105 the CPU 10 executes boot loader update processing.

The boot loader update process executed in S105 is a process as shown in FIG. 8 in detail. After starting the boot loader update process, in S201, the CPU 10 starts DMA transfer of the boot loader. Specifically, the CPU 10 instructs the DMAC 15 to start DMA transfer, and the DMAC 15 that receives the instruction transfers the boot loader from the second memory 12 to the first memory 11 . The CPU 10 waits for completion of the DMA transfer in S203.

After completing the DMA transfer of the bootloader, the CPU 10 changes the state information corresponding to the bootloader in the first memory 11 to the shared state S in S205. At S<b>207 , the CPU 10 changes the state information corresponding to the bootloader in the second memory 12 to the shared state S. After completing S207, the process shown in FIG. 8 is terminated. After completing the process shown in FIG. 8, the process proceeds to S107 in FIG. On the other hand, if the state of the boot loader in the second memory 12 is not the update state M in S103, the determination result in S103 becomes FALSE, and the process proceeds to S107.

When proceeding from S103 or S105 to S107, the CPU 10 substitutes the initial value 1 for the variable n. In S<b>109 , the CPU 10 refers to the state of the application n in the second memory 12 . Subsequently, in S<b>111 , the CPU 10 determines whether the state of the application n in the second memory 12 is the update state M or not. If the state of the application n in the second memory 12 is the update state M, the determination result in S111 becomes TRUE, and in S113, the CPU 10 changes the state of the application n in the first memory 11 to the disabled state I. . After completing S113, the process proceeds to S115. On the other hand, if the state of the application n in the second memory 12 is not the update state M in S111, the determination result in S111 becomes FALSE, and the process proceeds to S115.

When proceeding from S111 or S113 to S115, the CPU 10 adds an increment value of 1 to the variable n. In S117, the CPU 10 determines whether or not the variable n exceeds the number N of apps. If the variable n is equal to or less than the number N of applications, the judgment result in S117 becomes FALSE, and the process returns to S109. As a result, S109 to S117 are repeated while the variable n is equal to or less than the number N of applications. In this repeated process, the application 2 and subsequent applications are processed in order. When the application N+1 is to be processed, the determination result in S117 becomes TRUE, and the processing shown in FIG. 7 is terminated.

[Processing executed in HSM 13 when IG-ON]
Next, secure boot processing shown in FIG. 9 will be described. The secure boot process is executed by the HSM 13 triggered by IG-ON in the vehicle. When starting this process, the HSM 13 verifies the boot loader in the first memory 11 in S301. Subsequently, in S303, the HSM 13 determines whether or not the boot loader in the first memory 11 has been tampered with. If there is no tampering, the judgment result in S303 becomes TRUE, and in S305, the HSM 13 notifies the CPU 10 that the boot loader can be activated.

Subsequently, in S307, the HSM 13 substitutes the initial value 1 for the variable n. In S309, the HSM 13 executes verification processing for the application n. The verification process of application n executed in S309 is a process as shown in FIG. 10 in detail. When the verification process for application n is started, the HSM 13 refers to the state of application n in the first memory 11 in S401. Subsequently, in S<b>403 , the HSM 13 determines whether the state of the application n in the first memory 11 is the invalid state I or not.

If the state of the application n in the first memory 11 is the disabled state I, the determination result in S403 is TRUE, and the HSM 13 starts DMA transfer of the application n in S405. Specifically, the HSM 13 commands the DMAC 15 to start DMA transfer, and the DMAC 15 that receives the command transfers the application n from the second memory 12 to the first memory 11 . During the DMA transfer, the HSM 13 snoops the memory bus to obtain the app n being transferred and verifies the app n in S407. The HSM 13 waits for completion of the DMA transfer in S409. When the DMA transfer of the application n is completed, the HSM 13 changes the state information corresponding to the application n in the first memory 11 to the shared state S in S411. In S<b>413 , the HSM 13 changes the state information corresponding to the application n in the second memory 12 to the shared state S. After completing S413, the process proceeds to S415.

On the other hand, if the state of the application n in the first memory 11 is not the invalid state I in S403, the judgment result in S403 becomes FALSE, and the HSM 13 acquires the application n from the first memory 11 in S421, Verify app n. That is, if the state of the application n in the first memory 11 is the disabled state I, the application n is DMA-transferred. is not in the invalid state I, the application n is not DMA-transferred, so the application n is read from the first memory 11 in S421. After completing S421, the process proceeds to S415.

When proceeding from S413 or S421 to S415, the HSM 13 determines whether or not there has been tampering. If there is no tampering, the judgment result in S415 becomes TRUE, and in S417, the HSM 13 notifies the CPU 10 that application n can be started. On the other hand, if there is tampering, the determination result in S415 becomes FALSE, and in S419, the HSM 13 notifies the CPU 10 that application n cannot be started. After completing S417 or S419, the process shown in FIG. 10 is terminated. After completing the process shown in FIG. 10, the process proceeds to S311 in FIG.

In S311, the CPU 10 adds an increment value of 1 to the variable n. In S313, the CPU 10 determines whether or not the variable n exceeds the number N of apps. If the variable n is equal to or less than the number N of applications, the determination result in S313 becomes FALSE, and the process returns to S309. As a result, S309 to S313 are repeated while the variable n is equal to or less than the number N of applications. In this repeated process, the application 2 and subsequent applications are processed in order. When the application N+1 is processed, the determination result in S313 becomes TRUE, and the processing shown in FIG. 9 ends. On the other hand, if there is tampering in S303, the determination result in S303 becomes FALSE, and in S315, the HSM 13 notifies the CPU 10 that the boot loader cannot be activated. After completing S315, the process shown in FIG. 9 ends.

[Processing executed in CPU 10 when IG-ON]
Next, the software activation process shown in FIG. 11 will be described. The soft activation process is executed by the CPU 10 when the ignition is turned on in the vehicle. When the soft boot process is executed by the CPU 10, the secure boot process shown in FIGS. 9 and 10 is executed in the HSM 13. FIG. As a result, the HSM 13 and the CPU 10 cooperate with each other, and when the boot loader and each application from application 1 to application N are determined to be proper software in the HSM 13 , these software are started in the CPU 10 in order. On the other hand, if the HSM 13 determines that any one of the boot loader and the applications 1 to N is illegal software, the CPU 10 stops starting the software that is determined to be illegal, and the ECU 2 prevent it from working.

When the process shown in FIG. 11 is started, in S501, the CPU 10 waits for notification of boot loader startability. In S<b>503 , the CPU 10 determines whether or not the boot loader can be activated based on the notification from the HSM 13 . When the above S305 is executed in the HSM 13, the HSM 13 notifies the CPU 10 that the boot loader can be activated. In this case, it is determined to be TRUE in S503 and the process proceeds to S505. On the other hand, when the above S315 is executed in the HSM 13, the HSM 13 notifies the CPU 10 that the boot loader cannot be activated. In this case, it is determined to be FALSE in S503, and the processing shown in FIG. 11 ends with an error. In the case of an error termination, the ECU 2 is in a state where it does not function normally. Therefore, it is only necessary to execute a process corresponding to the occurrence of an error, such as recording the information as diagnostic information or the like.

When proceeding to S505, the CPU 10 executes the bootloader. Subsequently, in S507, the CPU 10 substitutes the initial value 1 for the variable n. In S<b>509 , the CPU 10 waits for notification of whether or not application n can be started. In S<b>511 , the CPU 10 determines whether or not the application n can be activated based on the notification from the HSM 13 . When the above S417 is executed in the HSM 13, the HSM 13 notifies the CPU 10 that application n can be started. In this case, it is determined to be TRUE in S511 and the process proceeds to S513. On the other hand, when the above-described S419 is executed in the HSM 13, the HSM 13 notifies the CPU 10 that application n cannot be started. In this case, it is judged as FALSE in S511, and the processing shown in FIG. 11 is ended with an error. In the case of error termination, the same processing as in the case of proceeding to error termination in S503 may be executed.

When proceeding to S513, the CPU 10 executes the application n. Subsequently, in S515, the CPU 10 adds an increment value of 1 to the variable n. In S517, the CPU 10 determines whether or not the variable n exceeds the number N of apps. If the variable n is equal to or less than the number N of applications, the determination result in S517 becomes FALSE, and the process returns to S509. As a result, S509 to S517 are repeated while the variable n is equal to or less than the number N of applications. In this repeated process, the application 2 and subsequent applications are sequentially processed, and if the determination result in S511 is TRUE, the application 2 and subsequent applications are activated in order. Also, if the determination result in S511 is FALSE, the processing shown in FIG. 10 ends with an error at that point. In the repeated process, when the application N+1 is to be processed, the determination result in S517 becomes TRUE, and the process shown in FIG. 11 is normally terminated.

[Comparison of relay control time and starting performance]
Next, based on timing charts shown in FIGS. to explain.

The example shown in FIG. 12 is an example in which DMA transfer from the bootloader to application N is executed in the relay control section after IG-OFF, and application N from the bootloader is activated after IG-ON. In this example, even after the IG-OFF, the power supply to the ECU 2 is continued by the main relay 6, and in the meantime, the software from the boot loader to the application N is DMA transferred from the second memory 12 to the first memory 11. be done. When the transfer of application N ends, the relay control ends. After that, when the IG-ON is turned on, the software stored in the first memory 11 is read in order from the boot loader to the application N. Software determined to be bootable in the secure boot process by the HSM 13 is sequentially booted by the CPU 10 .

On the other hand, the example shown in FIG. This is an example in which starting up to N is executed in order. In this example as well, the power supply to the ECU 2 is continued by the main relay 6 after the IG-OFF. However, unlike the example shown in FIG. 12, only the bootloader is DMA-transferred from the second memory 12 to the first memory 11 during relay control. Therefore, the relay control can be finished more quickly than the example shown in FIG. Therefore, from the viewpoint of suppressing the load on the battery, the example shown in FIG. 13 is more suitable than the example shown in FIG.

However, in the example shown in FIG. 13, DMA transfer from application 1 to application N is executed after IG-ON. In comparison, the activation start timing of application 1 is delayed. This is not a problem if the number of applications to be updated is small or the amount of data for each application is small, but if the number of applications to be updated is large or the amount of data for each application is large In this case, the time required for starting the ECU 2 increases.

On the other hand, the example shown in FIG. 14 is an example of executing the above process. In this example, only the bootloader is DMA-transferred in the relay control section after IG-OFF. This point is the same as the example shown in FIG. On the other hand, after IG-ON, the boot loader is activated and the DMA transfer from application 1 to application N is executed in order. Execute secure boot processing, and start each application that has undergone secure boot processing in order. As a result, the HSM 13 can acquire each application being transferred without reading each application after transfer from the first memory 11, and can check for falsification of the application, garbled data, and the like. Therefore, compared to the example shown in FIG. 13, the secure boot process by the HSM 13 can be executed more quickly, so that the activation of each application by the CPU 10 can be started more quickly. can be shorter than That is, by executing the above-described processing, it is possible to avoid an increase in relay control time to the same degree as in the example shown in FIG. 13, and to complete the software update more quickly than in the example shown in FIG.

It should be noted that there is no need to selectively select whether to update the software at the timing of IG-ON or to update the software at the timing of IG-OFF. should be selected. However, when updating the software at the timing of IG-ON, it is necessary to complete the update within a predetermined time specified by standards or the like. In this respect, according to the above-described process, the processing time after IG-ON can be reduced, so software that was difficult to update after IG-ON with the method shown in FIG. Such a technique may enable update after IG-ON. Therefore, the degree of freedom regarding software update timing is increased. In addition, if the number of updates after IG-ON increases, the update time after IG-OFF can be reduced by that amount, so the load on the battery can be reduced.

(2) Second Embodiment Next, a second embodiment will be described. In addition, each embodiment after 2nd Embodiment is embodiment which changed a part of structure illustrated in 1st Embodiment. Therefore, the differences from the first embodiment will be mainly described in detail, and the detailed description of the same parts as in the first embodiment will be omitted.

As shown in FIG. 15, the in-vehicle network system 21 includes an ECU 22, a repro master ECU 23, a DCM 5, a main relay 6, and the like. Although the second memory 12 was provided in the ECU 2 in the first embodiment, the second memory 32 is provided in the Repromaster ECU 23 in the second embodiment. In this respect, the second embodiment differs from the first embodiment. Further, in the second embodiment, when the IG-OFF is performed, power can be continuously supplied from the power supply side to both the ECU 22 and the repromaster ECU 23 via the main relay 6 .

In the case of the in-vehicle network system 21 configured in this manner, the ECU 22 and the Repromaster ECU 23 can perform data communication with each other via the global bus 7 . Therefore, the update software stored in the second memory 32 can be transmitted from the repro master ECU 23 to the ECU 22 via the global bus 7, and the update software received by the ECU 22 can be stored in the first memory 11. Therefore, although the specific configuration for transferring the update software from the second memory 32 to the first memory 11 is different from that of the first embodiment, the ECU 22 is otherwise the same as that of the first embodiment. By executing similar processing, it is possible to quickly complete the software update while avoiding an increase in relay control time.

Also in the second embodiment, the first memory 11 and the second memory 32 may be configured to store the state information indicating the state of the software stored therein in association with the software. As a result, regarding the software stored in the first memory 11, old software and new software can be managed based on the state information, and the consistency of the first memory 11 and the second memory 32 can be appropriately guaranteed. can.

Further, when software update is necessary, the HSM 13 examines whether or not the software for updating transferred to the first memory 11 is proper software. , HSM 13 may check whether or not the software stored in the first memory 11 is proper software. As a result, when the software needs to be updated, the HSM 13 can perform the inspection before the transfer to the first memory 11 is completed, so that the starting performance of the ECU 22 can be prevented from deteriorating.

(3) Third Embodiment Next, a third embodiment will be described.
As shown in FIG. 16, the in-vehicle network system 51 includes a first ECU 52, a second ECU 53, a repromaster ECU 2, a DCM 5, a main relay 6, and the like. In the first embodiment, the ECU 2 is provided with the first memory 11 and the second memory 12, but in the third embodiment, the first ECU 52 is provided with the first memory 11, and the second ECU 53 is provided with the second memory. 2 memory 62 is provided. In this respect, the third embodiment differs from the first embodiment. Further, in the third embodiment, when the IG-OFF is performed, the power source side is configured to be able to continue supplying power to both the first ECU 52 and the second ECU 53 via the main relay 6. there is Furthermore, the first ECU 52 and the second ECU 53 are configured to perform data communication with each other via the local bus 58 .

In the case of the in-vehicle network system 51 configured as described above, the update software stored in the second memory 62 is transmitted from the second ECU 53 to the first ECU 52 via the local bus 58, and the first ECU 52 The received update software can be stored in the first memory 11 . Therefore, although the specific configuration for transferring the update software from the second memory to the first memory 11 is different from that of the first embodiment, the other points are the same as those of the first embodiment in the first ECU 52 . By executing processing similar to the form, it is possible to quickly complete the software update while avoiding an increase in relay control time.

Also in the third embodiment, the first memory 11 and the second memory 62 may be configured to store the state information indicating the state of the software stored therein in association with the software. As a result, regarding the software stored in the first memory 11, old software and new software can be managed based on the state information, and the consistency of the first memory 11 and the second memory 62 can be appropriately guaranteed. can.

Further, when software update is necessary, the HSM 13 examines whether or not the software for updating transferred to the first memory 11 is proper software. , HSM 13 may check whether or not the software stored in the first memory 11 is proper software. As a result, when the software needs to be updated, the HSM 13 can perform the inspection before the transfer to the first memory 11 is completed, so that the starting performance of the first ECU 52 can be prevented from deteriorating.

(4) Other Embodiments Although the electronic control device has been described above using exemplary embodiments, the above-described embodiments are merely examples as one aspect of the present disclosure. That is, the present disclosure is not limited to the exemplary embodiments described above, and can be embodied in various forms without departing from the technical spirit of the present disclosure.

For example, in the above-described embodiment, three examples are shown for the locations where the second memories 12, 32, and 62 are arranged. The second memory may be located anywhere as long as the software can be transferred to the memory 11 .

Also, in the first embodiment, an example of performing DMA transfer from the first memory 11 to the second memory 12 has been described, but whether or not to perform DMA transfer is optional. Also, although not mentioned in the second and third embodiments, whether or not the ECUs 22 and 52 perform DMA transfer inside the ECUs 22 and 52 in the second and third embodiments is optional.

The ECUs 2, 22, 52 and techniques described in this disclosure are provided by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. It may be realized by Alternatively, the ECUs 2, 22, 52 and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits. Alternatively, the ECUs 2, 22, 52 and techniques described in this disclosure can be configured with a processor and memory and one or more hardware logic circuits programmed to perform one or more functions. may be implemented by one or more dedicated computers configured by a combination of Computer programs may also be stored as computer-executable instructions on a computer-readable non-transitional tangible storage medium. The method of realizing the function of each part included in the ECUs 2, 22, 52 does not necessarily include software, and all the functions may be realized using one or more pieces of hardware. .

In addition to the above, the functions realized by one component in each of the above embodiments may be configured to be realized by a plurality of components. Moreover, the function realized by a plurality of components may be realized by a single component. Also, part of the configuration of each of the above embodiments may be omitted. Also, at least part of the configuration of each of the above embodiments may be added, replaced, etc. with respect to the configuration of the other above embodiments.

In addition to the above-described electronic control device, various other devices such as an in-vehicle network system having the electronic control device as a component, a program for making a computer function as the electronic control device, a non-transition tangible recording medium recording this program, etc. The present disclosure can also be implemented in a form.

In addition, in each of the embodiments described above, the ECUs 2, 22, and 52 correspond to the electronic control unit referred to in the present disclosure. The first memory 11 corresponds to the first storage section referred to in the present disclosure. The second memories 12, 32, 62 correspond to the second storage section referred to in the present disclosure. The HSM 13 that executes S301, S407 and S421 corresponds to the inspection unit referred to in the present disclosure. The CPU 10 that executes S505 and S513 corresponds to the processing unit referred to in the present disclosure. The HSM 13 that executes S403 corresponds to the determination unit referred to in the present disclosure. The HSM 13 that executes S405 and the DMAC 15 that executes DMA transfer correspond to the update unit referred to in the present disclosure.

(5) Supplement As is clear from the exemplary embodiments described above, the electronic control device of the present disclosure may further include the following configurations.

(A) For example, the second storage section may be provided inside the electronic control unit. In this case, all the necessary components are located inside the electronic control unit. Therefore, in cases where relay control is required, for example, the number of devices that require relay control can be reduced and the load on the battery can be reduced compared to the case where some components are located outside the electronic control device. can do.

(B) For example, the first storage unit and the second storage unit may be configured to store state information indicating the state of the software stored therein in association with the software. The determination unit may be configured to determine whether the software stored in the first storage unit needs to be updated based on the state information. In this case, old software and new software can be managed based on the state information, and consistency between the first storage unit and the second storage unit can be appropriately guaranteed.

(C) For example, when the judging unit determines that an update is necessary, the inspecting unit examines the updating software transferred to the first storage unit by the updating unit to determine whether the software is proper software. If the determination unit determines that the update is unnecessary, the software stored in the first storage unit is inspected to determine whether or not the software is proper software. may be In this case, since the inspection can be performed by the inspection unit before the transfer by the update unit is completed, it is possible to suppress deterioration in the start-up performance of the electronic control unit.

(D) For example, the update unit may be configured to transfer the update software stored in the second storage unit to the first storage unit using a DMA transfer method. In this case, for example, when the processing section is configured by a CPU and the inspection section is configured by an HSM, the load on the CPU and HSM can be reduced. In addition, since the DMA transfer increases the efficiency of using the data transmission path, it is possible to speed up the processing compared to the case of transferring data by a method other than the DMA transfer.

(E) For example, the inspection unit may be configured to snoop a data transmission path used for transfer in the DMA transfer method to acquire update software transferred to the first storage unit. In this case, if the object to be transferred by DMA transfer is read out from the second storage unit, the inspection can be performed by the inspection unit, so there is no need to read out the object to be inspected from the first storage unit, and the processing speed is increased accordingly. can do.

(F) For example, the second storage section may be provided in another electronic device that is configured to communicate with the electronic control device via a communication path. The updating unit may be configured to acquire update software stored in the second storage unit from another electronic device and transfer the software to the first storage unit. In this case, the configuration of the electronic control units can be simplified by sharing one second storage unit among the plurality of electronic control units without providing the second storage unit for each electronic control unit. Cost increase can be suppressed.

DESCRIPTION OF SYMBOLS 1, 21, 51... In-vehicle network system 2, 22, 52, 53... ECU, 3, 23... Repro master ECU, 5... DCM, 6... Main relay, 7... Global bus, 58... Local bus, 10... CPU , 11...first memory, 12, 32, 62...second memory, 15...DMAC.

Claims (6)

An electronic control device (2, 22, 52),
a first storage unit (11) for storing software;
an inspection unit (13, S301, S407, S421) that inspects whether software to be activated is proper software when the electronic control unit is activated;
The processing unit (10, S505, S513) and
a judgment unit (13, S403) for judging whether the software stored in the first storage unit needs to be updated when the electronic control unit is started;
When the determination unit determines that the update is necessary, the update software stored in the second storage unit (12, 32, 62) is transferred to the first storage unit, and the update software is transferred to the first storage unit. an updating unit (13, 15, S405) for updating software stored in
with
When the software stored in the first storage unit is updated by the update unit, the inspection unit transfers update software stored in the second storage unit to the first storage unit. In parallel with, it is configured to inspect whether the software to be activated is proper software,
The second storage unit (12) is provided inside the electronic control unit,
The first storage unit and the second storage unit are configured to store state information indicating the state of the software stored therein in association with the software,
The determination unit is configured to determine whether or not software stored in the first storage unit needs to be updated based on the state information.
electronic controller. The electronic control device according to claim 1 ,
When the determination unit determines that the update is necessary, the inspection unit examines the update software transferred to the first storage unit by the update unit to determine whether the software is proper software. If the determination unit determines that the update is unnecessary, the software stored in the first storage unit is inspected to determine whether the software is proper software. An electronic control unit configured to: The electronic control device according to claim 2 ,
The electronic control device, wherein the update unit is configured to transfer the update software stored in the second storage unit to the first storage unit by a DMA transfer method. The electronic control device according to claim 3 ,
The inspection unit is configured to snoop a data transmission path used for transfer in the DMA transfer method and acquire update software transferred to the first storage unit. An electronic control device (2, 22, 52),
a first storage unit (11) for storing software;
an inspection unit (13, S301, S407, S421) that inspects whether software to be activated is proper software when the electronic control unit is activated;
The processing unit (10, S505, S513) and
a judgment unit (13, S403) for judging whether the software stored in the first storage unit needs to be updated when the electronic control unit is started;
When the determination unit determines that the update is necessary, the update software stored in the second storage unit (12, 32, 62) is transferred to the first storage unit, and the update software is transferred to the first storage unit. an updating unit (13, 15, S405) for updating software stored in
with
When the software stored in the first storage unit is updated by the update unit, the inspection unit transfers update software stored in the second storage unit to the first storage unit. In parallel with, it is configured to inspect whether the software to be activated is proper software,
The second storage unit (32, 62) is provided in another electronic device (23, 53) configured to be communicable with the electronic control device via a communication path,
The update unit is configured to acquire update software stored in the second storage unit from the other electronic device and transfer the software to the first storage unit,
The first storage unit and the second storage unit are configured to store state information indicating the state of the software stored therein in association with the software,
The determination unit is configured to determine whether or not software stored in the first storage unit needs to be updated based on the state information.
electronic controller. The electronic control device according to claim 5 ,
When the determination unit determines that the update is necessary, the inspection unit examines the update software transferred to the first storage unit by the update unit to determine whether the software is proper software. If the determination unit determines that the update is unnecessary, the software stored in the first storage unit is inspected to determine whether the software is proper software. An electronic control unit configured to:

Images