Vehicle, and program update method

Abstract

A vehicle according to the present invention comprises ECUs that each have one or a plurality of processors and a storage medium in which a program executed by the one or plurality of processors is stored. The ECUs include a first ECU and one or a plurality of second ECUs. The storage medium of the first ECU includes a non-volatile storage medium comprising regions that are divided into a greater number than the number of second ECUs. Each of the divided regions is treated either as a first region that has a boot image corresponding to one second ECU written thereto and is read at the time of startup of the corresponding second ECU, or as a second region that is not read at the time of startup of any second ECU. The number of first regions provided is the same as the number of second ECUs. The program of an execution agent ECU, which is configured as the first ECU or one second ECU, includes one or a plurality of commands. The one or plurality of commands causes or cause the one or plurality of processors of the execution agent ECU to execute processing for causing an update target ECU, which was selected from among the second ECU(s) as the target for updating the boot image, to store the post-update new boot image in the second region, and processing for setting the region to which the pre-update boot image is written as the second region.

Description

Vehicle and program update method

[0001] The present invention relates to the technical field of updating software in an information processing device mounted on a vehicle.

[0002] Due to the electronic control of vehicles, many information processing devices such as ECUs (Electronic Control Units) are installed in vehicles. Such information processing devices undergo updates to resolve software program bugs and improve performance (see, for example, Patent Document 1).

[0003] JP 2023-052938 A

[0004] Software program updates also include a boot image that is loaded when the ECU is started. If the capacity of a storage medium such as a flash memory is sufficient, the boot image can be updated while the vehicle is running using an over-the-air (OTA) method. However, if the capacity of the storage medium such as a flash memory is small and there is not enough space to store multiple boot images, the update must be performed using an external terminal, which is inconvenient.

[0005] An object of the present disclosure is to improve the convenience of updating an ECU.

[0006] A vehicle according to one aspect of the present technology includes an ECU having one or more processors and a storage medium storing a program executed by the one or more processors, the ECU including a first ECU and one or more second ECUs, the storage medium in the first ECU including a non-volatile storage medium having areas divided into a number of areas greater than the number of the second ECUs, and each of the divided areas includes a first area into which a boot image corresponding to any of the second ECUs is written and which is read at the time of startup of the corresponding second ECU, and a second area into which a boot image corresponding to any of the second ECUs is written and which is read at the time of startup of the corresponding second ECU. and a second area that is not included in the updated boot image, and the first area is provided in the same number as the number of the second ECUs, and the program in the executing ECU, which is either the first ECU or the second ECU, includes one or more instructions, and the one or more instructions cause the one or more processors in the executing ECU to execute the following process for an update target ECU selected from the second ECUs as a target for updating the boot image: storing the new updated boot image in the second area; and setting the area in which the pre-update boot image is written as the second area.

[0007] According to the present technology, it is possible to improve the convenience of updating an ECU.

[0008] 1 is a block diagram showing an example of the configuration of a vehicle; FIG. 2 is a block diagram showing an example of the configuration of an ECU; FIG. 3 is a diagram for explaining each area provided in the ROM of the first ECU; FIG. 4 is a diagram showing a state before a boot image is updated for each area provided in the ROM of the first ECU; FIG. 5 is a diagram showing a state during writing of a boot image for each area provided in the ROM of the first ECU; FIG. 6 is a diagram showing a state after writing of a boot image for each area provided in the ROM of the first ECU; FIG. 7 is a flowchart showing an example of processing executed by a CPU of an ECU for updating a boot image; FIG. 8 is a diagram showing a state before a boot image is updated for each area provided in the ROM of the first ECU of a modified example; FIG. 9 is a diagram showing a state during writing of a boot image for each area provided in the ROM of the first ECU of a modified example; FIG. 10 is a diagram showing a state after writing of a boot image for each area provided in the ROM of the first ECU of a modified example; FIG. 11 is a diagram showing a state during copying of a boot image for each area provided in the ROM of the first ECU of a modified example; 1 is a block diagram illustrating an example of a vehicle configuration in which a wireless communication unit is provided as a second ECU, and a boot image of a first ECU is updated in the same manner as the second ECU.

[0009] 1. Vehicle Configuration One embodiment of a vehicle 100 according to the present disclosure will be described with reference to the accompanying drawings. As shown in Fig. 1, the vehicle 100 includes a plurality of ECUs. Specifically, the plurality of ECUs includes a first ECU 1 and one or more second ECUs 2.

[0010] Here, the first ECU 1 is a NASECU that functions as a NAS (Network Attached Storage) in which data at the time of startup of each second ECU 2, specifically, boot images, are collected and stored.

[0011] The second ECU 2 may be provided for each control object, such as an ACECU (Air Conditioner ECU), an engine control ECU, a charge control ECU, an airbag ECU, or a display control ECU.

[0012] In the following description, an example will be given in which the vehicle 100 is equipped with four second ECUs 2, specifically, a second ECU 2a, a second ECU 2b, a second ECU 2c, and a second ECU 2d. However, the number of second ECUs 2 equipped in the vehicle 100 is not limited to this, and the vehicle 100 may be equipped with one second ECU 2, or two, three, or five or more second ECUs 2.

[0013] The second ECU 2a, which is one aspect of the second ECU 2, is a CECU (Central ECU). The second ECU 2a, which is a CECU, is a control unit that performs overall control of the vehicle 100, and performs overall control of the vehicle 100 by appropriately issuing instructions to the first ECU 1 and other second ECUs 2, such as the second ECU 2b, the second ECU 2c, and the second ECU 2d.

[0014] The vehicle 100 includes a first ECU 1 and various second ECUs 2 as well as a wireless communication unit 3 for performing wireless communication and a bus 4 .

[0015] The first ECU 1, various second ECUs 2, and wireless communication unit 3 are capable of communicating with each other via a bus 4. The bus 4 is configured to use, for example, CAN (Controller Area Network (registered trademark)) communication, and allows information to be transmitted and received between devices such as ECUs.

[0016] The wireless communication unit 3 is a vehicle communication device that communicates data with other devices via an external communication network. The wireless communication unit 3 can acquire data for updating the above-mentioned programs from an external file server via the OTA method, for example. The acquired data is provided to the ECU that performs the update process via the bus 4.

[0017] In the following description, the second ECU 2a is used as the ECU that performs the update process of the program in the second ECU 2. However, this is merely an example, and the update process may be performed by the first ECU 1, by a second ECU 2 other than the second ECU 2a, or by a control unit provided in the vehicle 100 other than the first ECU 1 or the second ECU 2.

[0018] In the following description, the ECU that mainly executes the program update process may be referred to as the "main executing ECU."

[0019] The second ECU 2a controls the wireless communication unit 3 to perform wireless communication with the outside of the vehicle 100. This allows the second ECU 2a to obtain program update data from an external device.

[0020] In the following description, a boot image will be used as an example of program update data. The boot image is data that is read when the second ECU 2 starts up, and is updated as appropriate to improve the functionality of the second ECU 2 or to fix defects. The boot image may also be downgraded if there is a problem with the updated program. In the following description, the term "boot image update" will be used to refer to both boot image updates and downgrades.

[0021] An example of the configuration of the first ECU 1 and the second ECU 2 is shown in FIG.

[0022] Each of the ECUs, such as the first ECU 1 and the second ECU 2 , includes a microcomputer 5 and a communication circuit 6 .

[0023] The microcomputer 5 includes a CPU (Central Processing Unit) 7 , a ROM (Read Only Memory) 8 , and a RAM (Random Access Memory) 9 .

[0024] The CPU 7, ROM 8, and RAM 9 are interconnected by an in-chip bus 10 so as to be able to communicate with each other.

[0025] The CPU 7 executes various processes according to programs stored in the ROM 8 or programs loaded into the RAM 9 .

[0026] The second ECU 2a, which is the executing ECU, performs processes of decrypting the update boot image, checking the version, and determining whether or not to perform the update process. The second ECU 2a then performs processes of transmitting the decrypted update boot image to the second ECU 2 to be updated.

[0027] At least a part of these processes may be executed in the second ECU 2 to be updated.

[0028] The ROM 8 is a non-volatile memory such as a flash memory. The first ECU 1 is a NASECU, and the flash memory serving as the ROM 8 of the first ECU 1 stores boot images of the second ECUs 2 in a consolidated manner. This will be described in detail later.

[0029] The RAM 9 stores temporary data and the like that is required when the CPU 7 performs predetermined processing.

[0030] The communication circuit 6 controls data communication via the bus 4 in accordance with the CAN communication standard.

[0031] 2. Example of information stored in the ROM of the first ECU

[0032] As described above, the boot image of each second ECU 2 is stored in the flash memory serving as the ROM 8 of the first ECU 1. Here, the ROM 8 of the first ECU 1 will be referred to as a ROM 8a.

[0033] The ROM 8a is divided into multiple areas. The areas in the ROM 8a may be physically divided into different chips, or may be virtually divided into areas provided on a single chip.

[0034] An example of the ROM 8a is shown in Fig. 3. The ROM 8a of the first ECU 1 has an area where the boot image of the second ECU 2 is stored and other areas, and Fig. 3 shows an excerpt of the area where the boot image of the second ECU 2 is stored. Here, the area where the boot image of the second ECU 2 is stored is referred to as the "boot image area ArB."

[0035] The boot image area ArB is divided into a plurality of divided areas, each of which has a uniform size of "X Bytes."

[0036] The ROM 8a is provided with a first area Ar1 in which the boot image of the second ECU 2 is stored and is read at startup, and a second area Ar2 that is not read at startup of any of the second ECUs 2. That is, each divided area is either the first area Ar1 or the second area Ar2.

[0037] FIG. 4 shows the ROM 8a in the example shown in FIG. 1 in which the vehicle 100 is equipped with four second ECUs 2.

[0038] The boot image area ArB is divided into five divided areas, which is one more than the number of second ECUs 2.

[0039] Specifically, the boot image area ArB is divided into a first area Ar1a in which a boot image for the second ECU 2a is stored, a first area Ar1b in which a boot image for the second ECU 2b is stored, a first area Ar1c in which a boot image for the second ECU 2c is stored, a first area Ar1d in which a boot image for the second ECU 2d is stored, and a second area Ar2 which is an unused area that is not read at startup.

[0040] The "unused area" means an area that is not used when the second ECU 2 is started up, and is an area that is used when updating the boot image of the second ECU 2. In other words, the second area Ar2 can be regarded as a spare area or an update work area.

[0041] The data size of the boot image for the second ECU 2a is set to "Y1 Byte." Similarly, the data size of the boot image for the second ECU 2b is set to "Y2 Byte," the data size of the boot image for the second ECU 2c is set to "Y3 Byte," and the data size of the boot image for the second ECU 2d is set to "Y4 Byte."

[0042] Each of the first area Ar1 and the second area Ar2 is an area of ​​"X Bytes." Here, "X" is set to the largest value among "Y1," "Y2," "Y3," and "Y4." For example, if "Y2" is the largest size among "Y1," "Y2," "Y3," and "Y4," "X" is set to a size that allows for a small margin over "Y2."

[0043] This small margin is provided because the data size of the boot image before and after the update is not necessarily the same.

[0044] 4 shows an example of the state of the boot image before updating. The second ECU 2 to be updated is the second ECU 2b, and the boot image is the boot image for the second ECU 2b. The divided areas included in the boot image area ArB are referred to as boot image areas ArBa, ArBb, ArBc, ArBd, and ArBe, in ascending order of addresses.

[0045] The changes in the information stored in the boot image area ArB during the boot image update process are shown in Figure 5 and subsequent figures. In each figure, the boot image newly downloaded for update is also referred to as the "new boot image." As mentioned above, the new boot image may be an older version of the boot image to avoid fatal defects in the current version.

[0046] 5, a new boot image is stored in the boot image area ArBe, which is the second area Ar2 in the ROM 8a of the first ECU 1 serving as the NASECU. That is, while the new boot image is being written, data of the new boot image is sequentially written to the second area Ar2.

[0047] The boot image that has been read at the time of startup of the second ECU 2b and that is stored in the first area Ar1b is referred to as the "old boot image."

[0048] FIG. 6 shows the state after writing of the new boot image to the second area Ar2 has been completed.

[0049] As shown in Fig. 6, a new boot image has been written to the boot image area ArBe, which was the second area Ar2 in Fig. 5, and the boot image area ArBb, which was the first area Arlb in Fig. 5, has been made an unused area. Note that the unused area may still have the old boot image stored therein, or the old boot image may have been deleted.

[0050] In addition, the boot image area ArBb, which was the first area Ar1b in Figure 5, has been reset as the second area Ar2, and the boot image area ArBe, which was the second area Ar2 in Figure 5, has been newly reset as the first area Ar1b.

[0051] These resettings mean changing the settings of the boot loader of the second ECU 2b, and also mean changing the area to be read at startup from the boot image area ArBb to the boot image area ArBe.

[0052] As can be seen from FIGS. 4 and 5, the boot image area ArBe, which was set as the second area Ar2 before the boot image update, is used as a work area for updating the boot image during the update process.

[0053] As can be seen from FIG. 6, the boot image area ArBb set as the second area Ar2 after the boot image is updated is an area that is used as a working area the next time the boot image is updated.

[0054] 3. Processing Example An example of processing executed by the CPU 7 of the second ECU 2a as the executing ECU is shown in FIG.

[0055] In step S101, the CPU 7 of the second ECU 2a receives an update request. This update request may be received from the second ECU 2 or from a server that distributes the boot image.

[0056] For example, when an update request is received from the second ECU 2, the CPU 7 of the second ECU 2a executes a process of checking with the server whether a new boot image has been released in step S101. Furthermore, when an update request is received from the server, the CPU 7 of the second ECU 2a may determine in step S101 whether it is the right time to update the boot image.

[0057] In step S102, the CPU 7 of the second ECU 2a acquires a new boot image from the server.

[0058] In step S103, the CPU 7 of the second ECU 2a performs a process of identifying the second ECU 2 to be updated.

[0059] In step S104, the CPU 7 of the second ECU 2a determines whether or not to execute a boot image update process, including determining whether or not a new boot image has already been stored and determining whether or not the timing for updating the boot image is appropriate.

[0060] If it is determined that the boot image update process is not to be executed (step S104: No determination), the CPU 7 of the second ECU 2a ends the series of processes shown in FIG. 7 without executing the processes from step S105 onwards.

[0061] On the other hand, if it is determined that the boot image update process is to be executed (step S104: Yes), the CPU 7 of the second ECU 2a performs a process of identifying the second area Ar2, which is an unused area, in step S105. This process is executed because the second area Ar2 is not fixed but may vary, as described above.

[0062] In step S106, the CPU 7 of the second ECU 2a executes a process of writing a new boot image to the second area Ar2, which is an unused area.

[0063] In step S107, the CPU 7 of the second ECU 2 a changes the setting of the boot loader. As a result of this setting change, the area that is read by the boot loader of the second ECU 2 to be updated at startup is changed to the area that was set as the second area Ar2 before the update.

[0064] 4. Example of information stored in the ROM of the first ECU according to the modified example In the example described above, each divided area of ​​the boot image area ArB is the same size. However, if the data size of the boot image of each second ECU 2 varies and only the data size of the boot image of a specific second ECU 2 is extremely large, it is difficult to effectively use the boot image area ArB.

[0065] In this modified example, this point is improved, and each divided area of ​​the boot image area ArB is determined based on the data size of each boot image to be stored. This will be specifically described with reference to FIG.

[0066] The boot image area ArB is divided into five areas as in the previous example, and is named boot image areas ArBa, ArBb, ArBc, ArBd, and ArBe in ascending order of address.

[0067] The boot image area ArBa is an area where the boot image for the second ECU 2a is stored, and its size is "Y1 Byte", which is the size of the boot image of the second ECU 2a, plus a small margin of "n Byte", i.e., "Y1 + n Byte".

[0068] Similarly, the boot image area ArBb is an area where the boot image for the second ECU 2b is stored, and is an area of ​​"Y2+n bytes", which is the size of the boot image of the second ECU 2b, "Y2 bytes", with a margin of "n bytes".

[0069] In addition, the boot image area ArBc is an area where the boot image for the second ECU 2c is stored, and is an area of ​​"Y3+n Bytes", which is the size of the boot image of the second ECU 2c, "Y3 Bytes", with a margin of "n Bytes".

[0070] The boot image area ArBd is an area where the boot image for the second ECU 2d is stored, and is an area of ​​"Y4+n Bytes", which is the size of the boot image of the second ECU 2d, "Y4 Bytes", with an additional "n Bytes" margin.

[0071] Finally, the size of the boot image area ArBe is set based on Y2, which is the largest size among Y1 to Y4. That is, the size of the boot image area ArBe is set to "Y2+n bytes."

[0072] Although the margin provided for each divided area is set to "n Bytes" here, it may be set to a different size for each divided area. In particular, since the size of the boot image changes after updating each boot image, "n Bytes" also changes. In other words, the margins of each divided area may be different from each other.

[0073] 8 shows an example of the state of the boot image before updating. The boot image areas ArBa, ArBb, ArBc, and ArBd are all designated as the first area Ar1. The boot image area ArBe is designated as the second area Ar2, which is an unused area.

[0074] The manner in which the information stored in the boot image area ArB changes during the process of updating the boot image is shown in FIG. 9 and subsequent figures.

[0075] As shown in FIG. 9, a new boot image is stored in a boot image area ArBe, which is the second area Ar2 in the ROM 8a of the first ECU 1 as the NASECU.

[0076] The boot image that has been read at the time of startup of the second ECU 2b and that is stored in the first area Ar1b is set as the old boot image.

[0077] FIG. 10 shows the state after writing of the new boot image to the second area Ar2 has been completed.

[0078] As shown in Fig. 10, a new boot image has been written to the boot image area ArBe, which was the second area Ar2 in Fig. 9, and the boot image area ArBb, which was the first area Arlb in Fig. 5, has been made an unused area. Note that the unused area may still have the old boot image stored therein, or the old boot image may have been deleted.

[0079] In addition, the boot image area ArBb, which was the first area Ar1b in Figure 9, is temporarily set as the second area Ar2, and the boot image area ArBe, which was the second area Ar2 in Figure 5, is temporarily set as the first area Ar1b.

[0080] The temporary setting of the first area Ar1 and the second area Ar2 is intended to ensure operation when the second ECU 2b to be updated is restarted during the boot image update, for example. As a result, during the boot image update, the area to be read at startup in the boot loader of the second ECU 2b is temporarily changed from the boot image area ArBb to the boot image area ArBe.

[0081] Next, the boot image for the second ECU 2b written in the boot image area ArBe is copied to the boot image area ArBb, which is temporarily set as the second area Ar2. That is, the new boot image is copied to the area where the old boot image was originally stored.

[0082] Even during copying, the boot image area ArBe remains set as the first area Ar1b, and the boot image area ArBb remains set as the second area Ar2.

[0083] The state after copying of the new boot image is complete is shown in Fig. 12. As shown in the figure, the boot image area ArBb into which the new boot image has been copied is set again as the first area Ar1b, and the boot image area ArBe into which the new boot image was originally written is returned to the second area Ar2.

[0084] As can be seen from each of FIGS. 8 to 11, in this modified example, the second area Ar2 is an area that is used only during the update work.

[0085] As can be seen from FIGS. 8 and 12, the boot loader settings do not change before and after the update, except during the update of the boot image, and the area that is read when each second ECU 2 is started does not change.

[0086] By adopting such a configuration, in the vehicle 100 in the modified example, it becomes possible to set each divided area of ​​the boot image area ArB to a compact size, thereby making it possible to reduce the size of the flash memory as the ROM 8a of the first ECU 1.

[0087] 5. Example of processing according to the modified example An example of processing executed by the CPU 7 of the second ECU 2a as the executing ECU in this modified example is shown in Fig. 13. Note that the same steps as those in Fig. 7 are given the same step numbers, and descriptions thereof will be omitted as appropriate.

[0088] After executing the processes of steps S101 to S103, the CPU 7 of the second ECU 2a determines whether or not to execute the update process for the boot image in step S104. If it is determined that the update process is not to be executed (step S104: No), the CPU 7 of the second ECU 2a ends the series of processes shown in FIG.

[0089] On the other hand, if it is determined that the update process is to be executed (step S104: Yes), the CPU 7 of the second ECU 2a stores the new boot image in the second area Ar2, which is an unused area, i.e., the boot image area ArBe, in step S106. Note that in this modification, a specific area, i.e., the boot image area ArBe, is always set as the second area Ar2 before updating the boot image, so the process of specifying the second area Ar2 in step S105 in the previous example is not necessary.

[0090] In step S111, the CPU 7 of the second ECU 2a changes the setting of the boot loader. In this change, the boot image area ArBb, where the old boot image is stored, is temporarily set to the second area Ar2. In this process, the boot image area ArBe, where the new boot image is stored, is temporarily set to the first area Ar1b.

[0091] In step S112, the CPU 7 of the second ECU 2a executes a process of copying the new boot image from the boot image area ArBe in which the new boot image is stored to the boot image area ArBb in which the old boot image was written.

[0092] After copying the new boot image, the CPU 7 of the second ECU 2a again changes the boot loader settings in step S113. This process changes the boot loader settings back to the state before the update. Specifically, the boot image area ArBe, where the new boot image was initially stored, is reconfigured as the second area Ar2. The boot image area ArBb, where the old boot image was stored, is reconfigured as the first area Ar1b.

[0093] <6. Others> In the above example, the wireless communication unit 3 is described as being different from the second ECU 2, but the wireless communication unit 3 may be provided as a communication ECU that controls overall communication. That is, the wireless communication unit 3 may be provided as a second ECU 2x as one aspect of the second ECU 2 as shown in Fig. 14, and in that case, the boot image of the wireless communication unit 3 can be updated by the above-mentioned method.

[0094] 15 , the ROM 8 a of the first ECU 1 may be provided with a boot image area ArBz serving as a first area Ar1z in which a boot image for the first ECU 1 is stored, boot image areas ArBa, ArBb, ArBc, and ArBd serving as a first area Ar1 in which a boot image for the second ECU 2 is stored, and a second area Ar2 that is an unused area.

[0095] These other examples are also applicable to the modified example shown in FIG. 8 and the like.

[0096] The second ECU 2 may be only an ECU that is OTA-enabled. For example, an ECU that is not OTA-enabled may be a third ECU, and its boot image may be stored in a ROM such as a flash memory in the third ECU. In other words, the boot image for the third ECU that is not OTA-enabled does not need to be collected in the ROM 8 a of the first ECU 1.

[0097] 7. Summary As described in the examples and the like, the vehicle 100 of the present technology includes an ECU having one or more processors (CPU 7) and a storage medium (ROM 8, 8a, or RAM 9) storing programs executed by the one or more processors, and the ECU includes a first ECU 1 and one or more second ECUs 2. The storage medium (ROM 8a) in the first ECU 1 includes a non-volatile storage medium (e.g., a flash memory) with areas (boot image areas ArB) divided into a number greater than the number of second ECUs 2, and each divided area includes a first area Ar1 into which a boot image corresponding to one of the second ECUs 2 is written and which is read upon startup of the corresponding second ECU 2, and a second area Ar2 into which none of the second ECUs 2 is read upon startup. The number of first areas Ar1 provided is equal to the number of second ECUs 2. Furthermore, the program in the executing ECU (the second ECU 2a, which is the CECU in the embodiment) designated as either the first ECU 1 or the second ECU 2 includes one or more instructions, and the one or more instructions cause one or more processors in the executing ECU to execute the following processes. The first process is to store a new updated boot image in the second area Ar2 for an update-target ECU (the second ECU 2b in the embodiment) selected from the second ECU 2 as the target for boot image update. The second process is to set the area where the pre-update boot image is written (the boot image area ArBb in the embodiment) as the second area Ar2. The first ECU 1 is, for example, a NASECU that aggregates the boot images of other ECUs, i.e., second ECUs 2. That is, each second ECU 2 accesses a non-volatile memory (ROM 8a), such as a flash memory, of the first ECU 1 upon startup to read and start up its boot image. This allows each second ECU 2 to have no nonvolatile memory such as a flash memory for storing a boot image, or to have only a small nonvolatile memory, thereby reducing the cost of the second ECU 2.Furthermore, if the non-volatile memory of the original second ECU 2 only had enough capacity to store one boot image, it would not be compatible with OTA. However, by storing the boot image in the non-volatile memory of the first ECU 1, even such a second ECU 2 can be updated using the second area Ar2, making it compatible with OTA. This allows each second ECU 2 to update its boot image, for example, while driving. Furthermore, compared to a configuration in which each second ECU 2 is equipped with non-volatile memory with a capacity at least twice the data size of the boot image for OTA compatibility, this configuration reduces the total capacity of the non-volatile memory of each ECU (first ECU 1 and second ECU 2), thereby reducing costs and saving resources, such as semiconductor materials, required for manufacturing the non-volatile memory. Furthermore, because the secure boot function for booting each second ECU 2 can be consolidated into the first ECU 1, only one location is required to store the program for the secure boot function, compared to when each ECU has a secure boot function. Since the second ECU 2 does not have a secure boot function, the number of development steps for the second ECU 2 can be reduced, making it possible to provide the second ECU 2 at a lower cost. Furthermore, since the function for updating the boot image for each ECU is also consolidated in the first ECU 1, only one location is required to store the program for the update function, compared to when each ECU has a boot image update function. Furthermore, since the second ECU 2 does not have an update function, the number of development steps for the second ECU 2 can be reduced, making it possible to provide the second ECU 2 at a lower cost.

[0098] In the vehicle 100, one or more instructions may cause one or more processors (CPU 7) in the executing ECU (the second ECU 2a, which is the CECU in this embodiment) to execute a process of setting an area (the boot image area ArBe in this embodiment) in the boot loader of the ECU to be updated (the second ECU 2b in this embodiment) where a new boot image after the update has been written as an area to be read at startup. This causes the ECU to be started based on the new boot image after the update the next time it is started. The process of setting the area to be read by the boot loader, which is a preparatory process, can be executed while the ECU to be updated is running. This process can therefore be completed while the vehicle is running, improving convenience.

[0099] In the vehicle 100, each of the divided areas (boot image areas ArBa, ArBb, ...) may be of the same size. For example, the same size means a size larger than the boot image with the largest data capacity among the boot images for each second ECU 2. As a result, the unused area that was the first area Ar1 before the update and is newly set as the second area Ar2 after the update has a capacity large enough to write the boot image of any second ECU 2. Therefore, the update process for all second ECUs 2 can be performed without any problems.

[0100] In the vehicle 100, the size of each divided area (boot image area ArBa, ArBb, ...) may be set to a size that conforms to the maximum size of the boot image for each second ECU 2. For example, the size of each first area Ar1 and second area Ar2 may be set to the maximum size of the boot image with a small margin (n bytes). This makes it possible to keep the capacity of the non-volatile storage medium (ROM 8a) small even when the sizes of the first area Ar1 and the second area Ar2 are unified. This therefore achieves a cost reduction effect for the storage medium.

[0101] In the vehicle 100, the number of divided areas (boot image areas ArBa, ArBb, ...) may be one more than the number of second ECUs 2. That is, there is only one second area Ar2. This allows the size of the second area Ar2, which is an excess area that is not read when the second ECU 2 is started, to be reduced.

[0102] In the vehicle 100, one or more instructions may cause one or more processors (CPU 7) in an executing ECU (second ECU 2a, which is a CECU in the embodiment) to execute the following operations: copying the new updated boot image using an area where the new updated boot image is stored (boot image area ArBe in the embodiment) as the source area and an area where the pre-update boot image (old boot image) is stored (boot image area ArBb in the embodiment) as the destination area; and setting the source area as the second area Ar2 again. As a result, the new boot image is moved to the area where the old boot image was originally stored. In other words, the second area Ar2 is always the same area (boot image area ArBe in the embodiment) when a new boot image update is started. This eliminates the need for a process such as checking the second area Ar2 at the start of the update, thereby simplifying the program.

[0103] In the vehicle 100, the one or more instructions may cause one or more processors (CPU 7) in the executing ECU (second ECU 2a, which is the CECU in the embodiment) to execute a process in the boot loader of the update target ECU (second ECU 2b in the embodiment) to set a source area (boot image area ArBe in the embodiment) as an area to be read at startup before the copying process, and set a destination area (boot image area ArBb in the embodiment) as an area to be read at startup after the copying process. As a result, while copying the new boot image, the source area is set as the area to be read at startup. Therefore, even during copying, the startup process of the update target ECU is performed based on the boot image stored in a complete state, thereby avoiding a problem such as the update target ECU being unable to start up even if a restart is unexpectedly performed.

[0104] In the vehicle 100, the size of the second area Ar2, which is the area of ​​the duplication source (in the embodiment, the boot image area ArBe), may be set to a size that conforms to the maximum size of the boot image for each second ECU 2 (in the embodiment, "Y2 Bytes"). For example, the size of the second area Ar2, which is the area of ​​the duplication source, i.e., the size of the second area Ar2 as the surplus area, is set to the maximum size of the boot image with a small margin (n Bytes). This makes it possible to keep the capacity of the second area Ar2 small, thereby achieving a cost reduction effect for the non-volatile storage medium (ROM 8a).

[0105] In the vehicle 100, the size of each first area Ar1 may be set to a size that conforms to the size of the boot image of the corresponding second ECU 2. For example, if there is a second ECU 2 with a small boot image size and a second ECU 2 with a large boot image size, the first area Ar1 corresponding to the former second ECU 2 is set to a size that is smaller than the first area Ar1 corresponding to the latter second ECU 2. This allows the first area Ar1 to be compact without leaving excessive space, making it possible to keep the capacity of the non-volatile storage medium (ROM 8a) small and achieving a cost reduction effect for the storage medium.

[0106] The program update method of the present technology is a program update method executed by a processor (CPU 7) of an execution subject ECU (in the embodiment, the second ECU 2a is the CECU) which is set to either a first ECU 1 or a second ECU 2 provided in a vehicle 100, and for an update target ECU (in the embodiment, the second ECU 2b) selected as an update target for a boot image from one or more second ECUs 2 provided separately from the first ECU 1, a boot image to be read at the time of startup of the second ECU 2 is stored in a second area Ar2 different from a first area Ar1 in which the boot image is stored. The program update method includes a step of storing a new boot image after the update and a step of setting the area where the pre-update boot image is written (in this embodiment, boot image area ArBb) as a second area Ar2, the first ECU 1 includes a non-volatile storage medium (ROM 8a) having areas divided into a number greater than the number of second ECUs 2, the first area Ar1 and the second area Ar2 are each divided area in the storage medium (boot image areas ArBa, ArBb, ArBc, ...), and the number of first areas Ar1 provided is equal to the number of second ECUs 2. By using such a program update method, it is possible to obtain the various functions and effects described above.

[0107] The above-described embodiments and modifications can be combined as appropriate.

[0108] 1 First EC2 2 Second EC2a 2 Second EC2b 2 Second EC2c 2 Second EC2d 2 Second EC2x 7 CPU (Proscenic) 8 ROM (Memory Media) 8a ROM (Memory Media) 9 RAM (Memory Media) 100 Ar1 First Domain Ar1a First Domain Ar1b First Domain Ar1c First Domain Ar1d First Domain Ar1x First Domain Ar1z First Domain Ar2 Second Domain

Claims

1. An ECU having one or more processors and a storage medium storing a program executed by the one or more processors, wherein the ECU includes a first ECU and one or more second ECUs, the storage medium in the first ECU includes a non-volatile storage medium having areas divided into a number greater than the number of the second ECUs, each of the divided areas including a first area into which a boot image corresponding to one of the second ECUs is written and which is read at the time of startup of the corresponding second ECU, and a second area which is not read at the time of startup of any of the second ECUs, the number of first areas being the same as the number of second ECUs, the program in the executing ECU, which is either the first ECU or the second ECU, includes one or more instructions, the one or more instructions causing the one or more processors in the executing ECU to: store the new updated boot image in the second area for an update target ECU selected from among the second ECUs as the target for updating the boot image; and setting the area in which the boot image before update is written as the second area.

2. The vehicle described in claim 1, wherein the one or more instructions cause the one or more processors in the executing ECU to execute a process of setting the area in the boot loader of the ECU to which the new boot image after the update has been written as an area to be read at startup.

3. The vehicle according to claim 1, wherein each of the divided areas has the same size.

4. The vehicle according to claim 3, wherein the size of each of the divided areas is set to a size that conforms to the maximum size of the boot image for each of the second ECUs.

5. The vehicle according to claim 1, wherein the number of the divided areas is one more than the number of the second ECUs.

6. The vehicle described in claim 1, wherein the one or more instructions cause the one or more processors in the executing ECU to execute the following processes: copying the new updated boot image, with the area in which the new updated boot image is stored as the source area and the area in which the pre-updated boot image is stored as the destination area; and setting the source area as the second area again.

7. The vehicle described in claim 6, wherein the one or more instructions cause the one or more processors in the executing ECU to execute a process in the boot loader of the ECU to set the source area as an area to be read at startup before the copying process, and set the destination area as an area to be read at startup after the copying process.

8. The vehicle according to claim 6, wherein the size of the second area that is the source of duplication is set to a size that conforms to the maximum size of the boot image for each of the second ECUs.

9. The vehicle according to claim 6, wherein the size of each of the first areas is set to a size that conforms to the size of the boot image of the corresponding second ECU.

10. A program update method executed by a processor of an executing ECU, which is either a first ECU or a second ECU provided in a vehicle, comprising: a step of storing a new updated boot image for an update target ECU selected as a target for boot image update from one or more second ECUs provided separately from the first ECU in a second area different from a first area in which the boot image read when the second ECU is started is stored; and a step of setting the area in which the pre-update boot image is written as the second area, wherein the first ECU is provided with a non-volatile storage medium having areas divided into a number greater than the number of second ECUs, the first area and the second area being each of the divided areas in the storage medium, and the number of first areas provided is the same as the number of second ECUs.

Images