OTA Manager and Center, Update Control Methods, Non-Transitory Storage Media

Abstract

This invention relates to an OTA manager, an update control method, a non-transitory storage medium, and an OTA center. The OTA manager, configured to control software updates of multiple target ECUs installed in a vehicle, includes one or more processors. These processors are configured to receive software update data and update order information for the target ECUs from an OTA center. The update order information specifies the update order of the software for the target ECUs. The processors are configured to control the execution of software updates for the target ECUs using the update data based on the update order.

Description

Technical Field

[0001] This disclosure relates to an OTA manager, update control method, non-transitory storage medium, and OTA center for controlling software updates of an ECU (electronic control unit). Background Technology

[0002] Vehicles are equipped with multiple ECUs (Electronic Control Units) for controlling vehicle movements. Each ECU has a processor, temporary storage such as RAM, and non-volatile storage such as ROM. The processor executes software stored in the non-volatile storage to perform the ECU's control functions. The software stored in each ECU can be rewritten. By updating to a newer version of the software, the functionality of each ECU can be improved, and new vehicle control functions can be added.

[0003] As a technology for updating ECU software, OTA (Over-The-Air) technology is well-known. In OTA technology, the vehicle communication device connected to the vehicle network is wirelessly connected to a communication network such as the Internet. The software is downloaded from the OTA center via wireless communication and then installed. This allows for the updating and addition of ECU programs (see, for example, Japanese Patent Application Laid-Open No. 2004-326689).

[0004] When multiple ECUs are updated via OTA (Over-The-Air) events (events to update vehicle software), there are sometimes limitations on the order of updates. For example, if a new signal (such as a newly added signal due to a software update for the purpose of adding functions) is sent from ECU1 (which has been updated) to ECU2 (which operates using the old software) before the update, there is a possibility that ECU2, upon receiving the new signal, may interpret it as an unknown signal and make an incorrect judgment. Summary of the Invention

[0005] This disclosure provides an OTA manager, update control method, non-transitory storage medium, and OTA center that enable appropriate software updates when there are limitations on the order of software updates for multiple ECUs.

[0006] The OTA manager according to the first aspect of this disclosure is configured to control software updates of multiple target ECUs installed in a vehicle. The OTA manager includes one or more processors. These processors are configured to receive software update data and update order information of the target ECUs from an OTA center. The update order information specifies the update order of the software of the target ECUs. The processors are configured to use the update data based on the update order to control the execution of software updates for the target ECUs.

[0007] In the OTA manager according to the first aspect of this disclosure, the aforementioned one or more processors may be configured to obtain update availability information indicating whether a software update can be performed on the target ECU. The aforementioned one or more processors may be configured to determine, based on the update availability information, which is the first target ECU capable of performing a software update. The aforementioned one or more processors may be configured to control the execution of the software update for the first target ECU based on the update order.

[0008] In the OTA manager according to the first method of this disclosure, the aforementioned one or more processors may be configured to control the execution of software updates for the second update group before the first update group. The first update group and the second update group may be groups of multiple software updates. The first update group may include software updates related to a second target ECU that the aforementioned one or more processors determine cannot currently perform software updates. The second update group may not include software updates related to the second target ECU.

[0009] In the OTA manager involved in the first method of this disclosure, the priority of the software update of the first update group can be higher than the priority of the software update of the second update group.

[0010] In the OTA manager according to the first aspect of this disclosure, the aforementioned one or more processors can be configured to control the execution of software updates for the aforementioned target ECUs in parallel.

[0011] The update control method according to the second aspect of this disclosure is executed by a computer configured to control software updates of multiple target ECUs installed in a vehicle. The computer has one or more processors and a memory. The method includes receiving software update data and update order information of the target ECUs from an OTA (Over-The-Air) center. The update order information specifies the update order of the software of the target ECUs. The method includes controlling the execution of software updates of the target ECUs using the update data based on the update order.

[0012] The non-transitory storage medium involved in the third aspect of this disclosure stores commands executable by a computer configured to control software updates of multiple target ECUs installed in a vehicle, and to cause the computer to perform the following functions: The computer has one or more processors and a memory. The functions include receiving software update data and update order information of the target ECUs from an OTA (Over-The-Air) center. The update order information specifies the update order of the software of the target ECUs. The functions include controlling the execution of software updates of the target ECUs using the update data based on the update order.

[0013] The OTA center involved in the fourth aspect of this disclosure is configured to communicate with an OTA manager via a network, the OTA manager being configured to control software updates for multiple target ECUs. The OTA manager is installed in a vehicle. The OTA center has one or more processors. The one or more processors are configured to send software update data and update order information of the target ECUs to the OTA manager. The update order information specifies the update order of the software of the target ECUs. The one or more processors are configured to cause the OTA manager to perform software updates for the multiple target ECUs based on the update order by sending the update data and the update order information.

[0014] According to this disclosure, an OTA manager, update control method, update control program, and OTA center can be provided to appropriately perform software updates when there are limitations on the order of software updates for multiple ECUs. Attached Figure Description

[0015] Hereinafter, the features, advantages, technical and industrial importance of exemplary embodiments of the present invention will be described with reference to the accompanying drawings, in which the same reference numerals denote the same components, wherein:

[0016] Figure 1 This is a block diagram illustrating an example of the overall structure of a network system involved in one implementation.

[0017] Figure 2 It means Figure 1 The diagram shows a simplified example of the structure of an OTA center.

[0018] Figure 3 It means Figure 1 A block diagram illustrating a simplified structure of an OTA manager.

[0019] Figure 4 It means Figure 1 The diagram shown is a functional block diagram of an example of an OTA center.

[0020] Figure 5 It means Figure 1 The diagram shown is a functional block diagram of an example OTA manager.

[0021] Figure 6 This is a diagram used to illustrate an example of whether or not information can be updated.

[0022] Figure 7 This is a diagram used to illustrate an example of updating order information.

[0023] Figure 8 It means Figure 1The flowchart shown is an example of a control process performed by the OTA manager.

[0024] Figure 9 This is a diagram used to illustrate other examples of update order information. Detailed Implementation

[0025] Figure 1 This is a block diagram illustrating an example of the overall structure of a network system involved in one implementation. Figure 2 It means Figure 1 The diagram shows a simplified example of the structure of an OTA center. Figure 3 It means Figure 1 A block diagram illustrating a simplified structure of an OTA manager.

[0026] Figure 1 The network system shown is used to update the software of the ECUs (Electronic Control Units) 13a-13d installed in the vehicle. The network system includes an OTA center 1, a communication network 5, and an in-vehicle network 2 installed in the vehicle.

[0027] The OTA center 1 can communicate with the OTA manager 11 installed in the vehicle via a communication network 5 such as the Internet, through wireless means. The OTA center 1 manages software updates for the ECUs 13a to 13d installed in the vehicle.

[0028] like Figure 2 As shown, the OTA center 1 includes a CPU 21, RAM 22, a storage device 23, and a communication device 24. The storage device 23 includes a hard disk, SSD, or other read / write storage medium. The storage device 23 stores programs used for software update management, information used in software update management, and ECU update data. The CPU 21 executes control processing by using RAM 22 as its working area to run programs read from the storage device 23. The communication device 24 communicates with the OTA manager 11 via the communication network 5.

[0029] like Figure 1As shown, the vehicle network 2 includes an OTA manager 11, a communication module 12, multiple ECUs 13a-13d, and an HMI (Human Machine Interface; for example, a display device of a car navigation system capable of input operation) 14. The OTA manager 11 is connected to the communication module 12 via bus 15a. The OTA manager 11 is connected to ECUs 13a and 13b via bus 15b. The OTA manager 11 is connected to ECUs 13c and 13d via bus 15c. The OTA manager 11 is connected to the HMI 14 via bus 15d. The OTA manager 11 wirelessly communicates with the OTA center 1 via the communication module 12. The OTA manager 11 controls the software updates of the ECUs 13a-13d that are the targets of software updates (in cases called "SW"), and in cases called "target ECUs". The communication module 12 is a communication device that connects the vehicle network 2 to the OTA center 1. The ECUs 13a-13d control the operation of various parts of the vehicle. During software update processing for ECUs 13a to 13d, HMI 14 is used for various displays, including showing the existence of update data, displaying consent request screens for users and administrators to agree to software updates, and displaying update results. Furthermore, in Figure 1 Four ECUs 13a to 13d are illustrated, but the number of ECUs is not limited. More than one target ECU can function as an OTA manager 11.

[0030] like Figure 3 As shown, the OTA manager 11 includes a microcomputer 35 and a communication device 36. The microcomputer 35 includes a CPU 31, RAM 32, ROM 33, and a storage device 34. The CPU 31 executes control processing by using RAM 32 as its working area to execute programs read from ROM 33. The communication device 36 connects via... Figure 1 The buses 15a-15d shown communicate with communication modules 12, ECUs 13a-13d, and HMI 14.

[0031] Here, the software update process consists of a download phase, an installation phase, and an activation phase. In the download phase, update data is downloaded from the OTA center 1 to the OTA manager 11. In the installation phase, the OTA manager 11 transfers the downloaded update data to the target ECU and installs the update data (update software) in the target ECU's storage area. In the activation phase, the updated software installed on the target ECU is made effective.

[0032] Downloading involves receiving update data from the OTA center 1 for updating the ECU software and storing the received update data in storage device 34. The download phase includes not only receiving the update data but also controlling a series of download-related processes, such as determining whether the download is executable and verifying the update data. Installation involves writing the updated program (updated software) into the non-volatile memory of the target ECU based on the downloaded update data. The installation phase includes not only executing the installation but also controlling a series of installation-related processes, such as determining whether the installation is executable, transferring the update data, and verifying the updated program. Activation is the process of activating (enabling) the installed updated program. The activation phase includes not only executing the activation but also controlling a series of activation-related processes, such as determining whether the activation is executable and verifying the execution result.

[0033] The update data sent from OTA Center 1 to OTA Manager 11 may include any one of the following: ECU update software, compressed data obtained by compressing update software, split update software, or split data obtained by compressing data. Additionally, the update data may include an identifier (ECUID) identifying the target ECU and an identifier (ECU software ID) identifying the software before the update. The update data is downloaded as a distribution data package. The distribution data package includes update data for one or more ECUs.

[0034] When the update data includes the update software itself, during the installation phase, the OTA manager 11 transfers the update data (i.e., the update software) to the target ECU. Alternatively, when the update data includes compressed data, differential data, or split data of the update software, the OTA manager 11 can transfer the update data to the target ECU, and the target ECU can generate the update software based on the update data. Or, the OTA manager 11 can generate the update software based on the update data and then transfer the update software to the target ECU. Here, the generation of the update software can be performed through the decompression of compressed data, or a combination of differential or split data.

[0035] The installation of the updated software can be performed by the target ECU based on an installation request from the OTA manager 11. Alternatively, the target ECU, upon receiving the update data, can install the updated software independently without explicit instructions from the OTA manager 11.

[0036] The target ECU can activate the updated software based on an activation request from the OTA manager 11. Alternatively, the target ECU, upon receiving the update data, can activate the updated software independently without explicit instructions from the OTA manager 11.

[0037] Figure 4 yes Figure 1The diagram shown is an example of the functional block diagram of OTA Center 1. Figure 4 As shown, the OTA center 1 includes a storage unit 26, a communication unit 27, and a control unit 28. The communication unit 27 and the control unit 28 communicate via... Figure 2 The CPU 21 shown uses RAM 22 to execute programs stored in storage device 23. Storage unit 26 can be... Figure 2 The storage device 23 shown is implemented.

[0038] Figure 5 yes Figure 1 The above is an example of a functional block diagram of OTA Manager 11. Figure 5 As shown, the OTA manager 11 includes a storage unit 37, a communication unit 38, and a control unit 39. The communication unit 38 and the control unit 39 communicate via... Figure 3 The CPU 31 shown uses RAM 32 to execute programs stored in ROM 33. The storage unit 37 consists of... Figure 3 The storage device 34 shown is implemented.

[0039] Figure 6 This is a diagram illustrating an example of whether updateability information is possible. Updateability information indicates whether, based on the vehicle's state, a software update can be performed on each ECU (including each ECU of the target ECU).

[0040] In this embodiment, the ECU installed in the vehicle includes: ECUs that can perform software updates when the vehicle is parked but cannot perform software updates when the vehicle is moving (this is referred to as a "driving-related ECU"); and ECUs that can perform software updates both when the vehicle is parked and when the vehicle is moving (this is referred to as a "non-driving-related ECU"). Driving-related ECUs are ECUs that perform controls related to the vehicle's movement. For example, driving-related ECUs include ECUs that control the engine, brakes, and steering system. Non-driving-related ECUs are ECUs that perform controls unrelated to the vehicle's movement. For example, non-driving-related ECUs include ECUs that control the audio system and the air conditioning system. Here, when parked, for example, the ignition switch is on and the vehicle speed is zero (the vehicle is not moving). When moving, for example, the ignition switch is on and the vehicle speed is greater than zero (the vehicle is moving).

[0041] Figure 6 The update availability information indicates that software updates for all ECUs (ECU1 through ECU7) installed in the vehicle can be performed while the vehicle is parked. On the other hand, Figure 6The update availability information indicates that only ECU1, ECU4, ECU5, and ECU7 can be updated while the vehicle is in motion. Here, ECU1, ECU4, ECU5, and ECU7 are non-driving-related ECUs. ECU2, ECU3, and ECU6 are driving-related ECUs.

[0042] The OTA manager 11 stores update availability information. The OTA manager 11 determines the vehicle's status (parked or moving) by monitoring the ignition power supply status and vehicle speed. Based on this determination and the update availability information, the OTA manager 11 determines the ECU that can receive a software update. The ignition power supply status can be monitored, for example, using signals received from a device that monitors the power supply status. The vehicle speed status can be monitored, for example, using signals received from the ECU that controls the vehicle speed. An example of a target ECU that can receive a software update is the first target ECU. An example of a target ECU that cannot receive a software update is the second target ECU.

[0043] Figure 7 This is a diagram illustrating an example of update sequence information. Update sequence information indicates the order in which the ECU's software is updated.

[0044] In this embodiment, multiple software programs can be installed and run on a single ECU, and the software is updated in a predetermined order.

[0045] The following is for reference Figure 7 The following example illustrates the update order information in detail. Figure 7 The update order information shown indicates that the target ECUs for software updates are ECU1, ECU3, and ECU4. Furthermore, in update group 1 of the update order information, it is shown that after updating software a1 (not shown) installed on target ECU1 to software A1, software A1 is updated to software A2, and then software A2 is updated to software A3. Next, it is shown that after updating software a2 (not shown) installed on target ECU3 to software A4, software A4 is updated to software A5. Then, it is shown that after updating software a3 (not shown) installed on target ECU4 to software A6, software A6 is updated to software A7. That is, update group 1 specifies that the update process for target ECU1, ECU3, and ECU4 is performed in the order of software A1, A2, A3, A4, A5, A6, and A7. Update group 1 is an example of the first update group.

[0046] Furthermore, in update group 2, it is shown that after updating software b1 (not shown) installed on target ECU1 to software B1, software B1 is updated to software B2. Then, it is shown that software b2 (not shown) installed on target ECU4 is updated to software B3. That is, update group 2 specifies that update processing is performed on target ECU1 and ECU4 in the order of software B1, B2, and B3. Update group 2 is an example of the second update group.

[0047] In addition, such as Figure 7 As shown, the update order information specifies that update group 1 (update groups A1, A2, A3, A4, A5, A6, and A7) has priority 1, and update group 2 (update groups B1, B2, and B3) has priority 2. That is, the update priority of update group 1 is specified as higher than that of update group 2 in the update order information. Figure 7 The update order information shown specifies the software update order as "A1, A2, A3, A4, A5, A6, A7, B1, B2, B3".

[0048] Here, to prevent erroneous judgments by the ECU, the update order shown in the update group must be followed. Specifically, the update order shown in update group 1 (update order of A1, A2, A3, A4, A5, A6, A7) and the update order shown in update group 2 (update order of B1, B2, B3) must be followed. On the other hand, the software update order shown in the update group priority is, for example, an order corresponding to the importance of the update, and does not need to be followed. Specifically, there may be a situation where the update of update group 2 (priority 2) is performed before update group 1 (priority 1).

[0049] Figure 8 This is a flowchart illustrating an example of the control processing performed by the OTA manager 11 in this embodiment. Hereinafter, according to... Figure 8 The flowchart shown illustrates the control processing involved in this embodiment.

[0050] Through OTA Manager 11 (see reference) Figure 5 The communication unit 38 receives software update data and update order information sent from the OTA center 1 due to OTA activities (see reference). Figure 7 ), from this point on Figure 8 The process is shown. Software update data and update order information are received and stored in storage unit 37, for example, in the IG-ON state (the state where the ignition switch power is on).

[0051] In step S1, the control unit 39 determines whether the information is updatable based on the information stored in the storage unit 37 (refer to...). Figure 6This is used to determine which ECU in the target ECU is currently capable of software updates. The following uses... Figure 6 The availability of update information will be explained in detail below. For example, using... Figure 6 As explained, the control unit 39 determines the vehicle's status (parked or moving) by monitoring the status of the ignition switch power supply and the vehicle speed. Based on the vehicle status determination and update availability information, the control unit 39 determines the ECUs eligible for software updates. For example, assuming the target ECUs are ECU1, ECU3, and ECU4. In step S1, when the vehicle is moving, the control unit 39 refers to... Figure 6 The update availability information shown determines whether the target ECUs, ECU1 and ECU4, are eligible for software updates. Additionally, in step S1, when the vehicle is stationary, the control unit 39 refers to... Figure 6 The available update information is used to determine which ECUs are eligible for software updates: target ECU1, ECU3, and ECU4. The process then proceeds to step S2.

[0052] In step S2, the control unit 39, based on the update order information stored in the storage unit 37 (refer to...), Figure 7 This is used to determine which software in the target ECU, identified as capable of software updates in step S1, needs to be updated. Hereinafter, we will use... Figure 7 The update order information shown is an example of the update order information when the target ECUs are ECU1, ECU3, and ECU4.

[0053] When the vehicle is parked, the control unit 39 determines that the ECUs that can be updated in step S1 are target ECU1, ECU3, and ECU4 (see reference). Figure 6 Therefore, in step S2, the control unit 39 is based on... Figure 7 The update order information shown determines which software in target ECU1, ECU3, and ECU4 needs to be updated. For example, if it is the beginning... Figure 8When the flowchart processing is completed and step S2 is executed for the first time, the control unit 39 determines to update the software a1 (not shown) of ECU1 to software A1. Furthermore, if the update of the software of ECU1 to software A2 is completed, the control unit 39 determines to update the software A2 of ECU1 to software A3. Similarly, if the update of the software of ECU1 to software A3 is completed, the control unit 39 determines to update the software a2 (not shown) of ECU3 to software A4. Finally, if the update of the software of ECU4 to software A7 is completed, the control unit 39 determines to update the software b1 (not shown) of ECU1 to software B1. In this way, software updates can be performed on all target ECUs while the vehicle is stationary. Therefore, according to the software update order shown in the update order information (i.e., ...), Figure 7 The order shown is: A1, A2, A3, A4, A5, A6, A7, B1, B2, B3) to determine which software needs to be updated.

[0054] Furthermore, while the vehicle is in motion, the control unit 39 determines that the ECUs capable of software updates in step S1 are target ECU1 and ECU4 (i.e., target ECU3 cannot be updated) (see reference). Figure 6 In step S2, control unit 39 does not decide to execute a software update for update group 1 (priority 1), which includes software updates for the target ECU 3 that cannot be updated. Control unit 39 then decides which software update to execute from update group 2 (priority 2). For example, if it is the beginning... Figure 8 When the flowchart processing is completed and step S2 is executed for the first time, the control unit 39 decides to update the software b1 (not shown) of ECU1 to software B1. Alternatively, for example, if the update of the software of ECU1 to software B2 is completed, the control unit 39 decides to update the software b2 (not shown) of ECU4 to software B3. Thus, when the vehicle is in motion, the control unit 39 does not decide to execute the software update of update group 1, which includes the software update of the target ECU3 that cannot be updated, but instead decides to execute the software update of update group 2, which does not include the software update of the target ECU3 that cannot be updated. That is, when the vehicle is in motion, the control unit 39 follows the software update order shown in the update order information (i.e., ...). Figure 7 The order shown is: A1, A2, A3, A4, A5, A6, A7, B1, B2, B3. Different orders determine the software to be updated. Following the processing in step 2 described above, the process moves to step S3.

[0055] In step S3, the control unit 39 determines whether software to be updated (i.e., software to be updated exists) was determined in the processing of step S2. If the determination in step S3 is "yes", the process moves to step S4. If the determination in step S3 is "no", the process returns to step S1.

[0056] In step S4, the control unit 39 performs update processing related to the software to be updated as determined in step S2. Specifically, the control unit 39 reads the update data of the software to be updated as determined in step S2 from the storage unit 37. The control unit 39 sends the update data to the target ECU and installs the update software into the target ECU (writes the update software into the non-volatile memory of the target ECU). The control unit 39 activates (enables) the installed software (update software). Then, the process moves to step S5.

[0057] In step S5, the control unit 39 determines whether all software updates involved in this OTA activity have been performed. If the determination in step S5 is "yes", the process ends. Figure 8 If the determination in step S5 is "No", the process returns to step S1 to perform the remaining software update.

[0058] As explained above, in this embodiment, information based on the update order (see reference) is used. Figure 7 The software update sequence is used to control the execution of software updates for multiple target ECUs. Therefore, it is possible to properly execute multiple software updates (OTA activities) where the software update sequence is limited.

[0059] Furthermore, in this embodiment, based on whether the information can be updated (refer to...) Figure 6 Therefore, it is possible to perform software updates appropriately based on the software update sequence specified by the update availability information, taking into account whether there are limitations on the availability of software updates for the target ECU.

[0060] Additionally, in this embodiment, in the update group (refer to...) Figure 7 In the case where update group 1 includes software updates (updates to software A4 and A5) of ECUs that are currently not eligible for software updates, software updates can be performed on ECUs (e.g., ECU1) that are eligible for software updates in an order different from the software update order shown in the update order information (e.g., updates to software B1 can be performed before updates to software A1). Therefore, according to this embodiment, software updates can be performed according to a software update order that is not required to be followed (a priority-based update order). Thus, update processing can be efficiently advanced.

[0061] Variations

[0062] In the above-described embodiment, an example is given of updating the group (refer to) when the vehicle is in motion. Figure 7 In update group 1), if a software update (update to software A4 or A5) is included for an ECU (ECU3) whose software is currently not updatable, all software updates included in that update group will not be performed (retained). However, even while the vehicle is in motion, software updates in update groups that include software updates for ECUs whose software is currently not updatable can be performed to the extent feasible, while adhering to the software update order within that update group. For example, in... Figure 7 The update sequence information is shown, and the software update for target ECU3 (to software A4 and A5) cannot be performed because the vehicle is in motion (refer to...). Figure 6 This can be used to control the software update of target ECU1 (update to software A1, A2, A3) based on the update order within update group 1.

[0063] Furthermore, in the aforementioned situation (even when the vehicle is in motion, software updates for update groups, including those for ECUs whose software cannot currently be updated, are performed to the extent feasible, while adhering to the update order within that update group), it is possible to control the parallel execution of software updates for multiple target ECUs. For example, in [the context of...] Figure 7 In cases where the update sequence information is shown, and the software update of target ECU3 (to software A4 and A5) cannot be performed because the vehicle is in motion, the control for updating target ECU4 to software B3 can be executed in parallel with the execution of the update of target ECU1 to software A1. By controlling it in this way, software updates can be performed efficiently.

[0064] In addition, when the software updates of multiple update groups shown in the update sequence information have the same priority, it is possible to control the parallel execution of software updates for multiple target ECUs. Figure 9 Is for Figure 7 The update order information shown is appended to the graph for update group 3 (which has the same priority as update group 2). Figure 9 In the case of the update sequence information shown, for example, the control of updating target ECU4 to software C1 can be performed in parallel with the execution of the update from target ECU1 to software B1. By controlling it in this way, software updates can be performed efficiently.

[0065] Furthermore, in the above-described embodiment, the case where the ECU mounted in the vehicle is a single-database memory ECU was explained. Therefore, in the above-described embodiment, the case where... Figure 8Step S4 involves installing the update software into the target ECU (single-library memory ECU) and activating the update software as a software update process. Here, the ECU can be either a single-library memory ECU (single-sided memory ECU) with one data storage area (library) for storing software, or a dual-library memory ECU (dual-sided memory ECU) with two data storage areas (libraries) for storing software. In a single-library memory ECU, installing and activating the update software in a data storage area affects the ECU's software. Conversely, in a dual-library memory ECU, either of the two data storage areas (including cases where two data storage areas are virtually constituted) is used as the data storage area to be read (application surface), and the software stored in the data storage area to be read is executed. During the execution of the software in the data storage area to be read (application surface), the update software can be written in the background to the data storage area of ​​the other data storage area (non-application surface), which is not the data storage area to be read. During activation in the software update process, by switching the data storage area to be read, the updated software can be activated (enabled). Furthermore, in this embodiment described above, the ECU mounted in the vehicle can be a dual-database memory ECU. In this case, an updated version of the software is pre-installed in the data storage area outside the usage area, as... Figure 8 The software update process in step S4 is activated by switching the data storage area from the non-use area to the use area.

[0066] Furthermore, the OTA center 1 illustrated in this embodiment can also be implemented as a management method executed by a computer equipped with a processor (CPU), memory, and communication device, or a management program executed by such a computer, or a non-transitory storage medium storing the management program. Similarly, the OTA manager 11 illustrated in this embodiment can also be implemented as a control method executed by a vehicle-mounted computer equipped with a processor (CPU), memory, and communication device, or a control program executed by such a vehicle-mounted computer, or a non-transitory storage medium storing the control program. The OTA center 1 may have one or more processors. The OTA manager 11 may have one or more processors.

[0067] The technology disclosed herein can be utilized in network systems used for updating the program of an ECU (Electronic Control Unit).

Claims

1. An OTA manager configured to control software updates for multiple target ECUs installed in a vehicle, characterized in that, The OTA manager includes one or more processors, and the one or more processors are configured as follows: The system receives software update data and update order information for the target ECU from the OTA center. The update order information specifies the update order of the software for the target ECU. The execution of software updates for the target ECU is controlled using the update data based on the software update order. The configuration of one or more processors is as follows: Obtain update availability information indicating whether a software update can be performed on the target ECU. Based on the update availability information, the first target ECU among the target ECUs that is capable of performing a software update is determined. The execution of the software update for the first target ECU is controlled based on the update order. The one or more processors are configured to control the execution of software updates for the second update group before the first update group. The first update group and the second update group are groups of multiple software updates. The first update group includes software updates involving a second target ECU that the one or more processors determine cannot be updated. The second update group does not include software updates involving the second target ECU.

2. The OTA manager according to claim 1, characterized in that, The software updates in the first update group have a higher priority than the software updates in the second update group.

3. The OTA manager according to claim 1 or 2, characterized in that, The one or more processors are configured to control the execution of software updates for the target ECU in parallel.

4. An update control method, executed by a computer configured to control software updates of a plurality of target ECUs mounted in a vehicle, said computer having one or more processors and memories. The update control method is characterized by including: Receive software update data and update order information for the target ECU from the OTA center, wherein the update order information specifies the update order of the software for the target ECU; The software update is controlled by using the update data based on the software update order; Obtain updateability information indicating whether a software update can be performed on the target ECU; Based on the updateability information, determine the first target ECU among the target ECUs that is capable of performing a software update; The execution of the software update for the first target ECU is controlled based on the update order; as well as The execution of software updates for the second update group is controlled before the first update group. The first update group and the second update group are groups of multiple software updates. The first update group includes software updates related to a second target ECU that is determined by one or more processors to be unable to perform software updates. The second update group does not include software updates related to the second target ECU.

5. A non-transitory storage medium storing commands executable by a computer configured to control software updates of a plurality of target ECUs mounted in a vehicle, wherein the computer has one or more processors and a memory. The non-transitory storage medium is characterized in that, The functions include: Receive software update data and update order information for the target ECU from the OTA center, wherein the update order information specifies the update order of the software for the target ECU; The software update is controlled by using the update data based on the software update order; Obtain updateability information indicating whether a software update can be performed on the target ECU; Based on the updateability information, determine the first target ECU among the target ECUs that is capable of performing a software update; The execution of the software update for the first target ECU is controlled based on the update order; as well as The execution of software updates for the second update group is controlled before the first update group. The first update group and the second update group are groups of multiple software updates. The first update group includes software updates related to a second target ECU that is determined by one or more processors to be unable to perform software updates. The second update group does not include software updates related to the second target ECU.

Images