hub, ota manager, distribution method, non-transitory storage medium

Abstract

The present application relates to a center, an OTA manager, a system, a distribution method, a non-transitory storage medium, and a vehicle. The center includes one or more processors configured to transmit update data of software of a plurality of electronic control units to be mounted on a vehicle and information related to an update sequence that defines steps of an update process of the software to an OTA manager, and the OTA manager includes one or more second processors configured to control the update of the software.

Description

Technical Field

[0001] This disclosure relates to a center for controlling software updates of electronic control units, an OTA manager, a system, a distribution method, a non-transitory storage medium, and a vehicle. Background Technology

[0002] Vehicles are equipped with multiple Electronic Control Units (ECUs) for controlling vehicle movements. Each ECU has a processor, temporary storage such as RAM, and non-volatile memory such as flash ROM. The processor executes software stored in the non-volatile memory to implement the control functions of the ECU. 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 the software of electronic control units (ECUs), OTA (Over-The-Air) technology is known as follows: An in-vehicle communication device connected to an in-vehicle network is wirelessly connected to a communication network such as the Internet. A device responsible for updating the vehicle's software downloads software from a server via wireless communication and installs the downloaded software into the ECU to update or add software to the ECU. For example, see Japanese Patent Application Laid-Open No. 2004-326689.

[0004] Vehicles are equipped with various types of electronic control units (ECUs), including those capable of independently performing software updates without being affected by other ECUs, and those that collaborate with other ECUs to advance software updates. When the vehicle side judges all the various specifications of such ECUs and performs software updates accordingly, the burden on the device controlling the vehicle-side software updates (OTA manager) increases. This can lead to situations where software updates are time-consuming or additional functional restrictions are added during the update process, resulting in inappropriate software update execution. Summary of the Invention

[0005] This disclosure provides a center, OTA manager, system, distribution method, non-transitory storage medium, and vehicle that can reduce the burden on devices controlling software updates on the vehicle side and properly perform software update processing for electronic control units.

[0006] The first aspect of this disclosure involves a central component comprising one or more processors configured to send update data of software from multiple electronic control units mounted in the vehicle and information related to an update sequence defining steps for updating the software to an OTA manager, wherein the OTA manager includes one or more second processors configured to control the updating of the software.

[0007] The second aspect of this disclosure involves a central component comprising one or more processors configured to send the update data to an OTA manager configured to transfer update data to multiple electronic control units mounted in a vehicle, and to send information related to the sequence of updates based on the update data to the OTA manager.

[0008] The OTA manager involved in the third aspect of this disclosure includes one or more processors configured to receive from a central location update data of software of multiple electronic control units mounted in a vehicle and information related to an update sequence that defines the steps of the software update process, and to control the update of the software of the multiple electronic control units based on the software update data and the information related to the update sequence.

[0009] The system involved in the fourth aspect of this disclosure includes: a center, including one or more first processors; and an OTA manager, having one or more second processors. The one or more first processors are configured to send update data of the software of multiple electronic control units installed in the vehicle and information related to an update sequence defining the steps of the software update process to the OTA manager. Furthermore, the one or more second processors are configured to receive the software update data and the information related to the update sequence from the center, and control the software update of the multiple electronic control units based on the software update data and the information related to the update sequence.

[0010] The fifth aspect of this disclosure is a distribution method performed by a central processing unit having one or more processors and memories. This distribution method includes sending update data of software from multiple electronic control units installed in a vehicle, along with information related to an update sequence defining the steps for updating the software, to an OTA manager configured to control the updates of the software.

[0011] The sixth aspect of this disclosure is a non-transitory storage medium storing instructions that can be executed by a computer having one or more processors and memories, and that cause the computer to perform the method of the fifth aspect described above.

[0012] The vehicles involved in the seventh method disclosed herein include the aforementioned third-party OTA managers.

[0013] According to various embodiments of this disclosure, a center, OTA manager, system, distribution method, non-transitory storage medium, and vehicle can be provided to appropriately perform software update processing for electronic control units while reducing the burden on devices that control software updates on the vehicle side. Attached Figure Description

[0014] 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 constituent elements, wherein:

[0015] Figure 1 It is a block diagram showing the overall structure of the network system involved in the implementation method.

[0016] Figure 2 It is a block diagram representing the simplified structure of the center.

[0017] Figure 3 This is the central functional block diagram.

[0018] Figure 4 This is a block diagram representing the simplified structure of the OTA manager.

[0019] Figure 5 This is a functional block diagram of the OTA Manager.

[0020] Figure 6A This is a block diagram illustrating an example of a simplified structure of an electronic control unit.

[0021] Figure 6B This is a block diagram illustrating an example of a simplified structure of an electronic control unit.

[0022] Figure 7 This is a diagram representing an example of category information.

[0023] Figure 8 This is a flowchart of the download processing steps performed by the center and OTA manager.

[0024] Figure 9A This is a flowchart illustrating the installation and activation process steps involved in Example 1, performed by the OTA manager and the target electronic control unit.

[0025] Figure 9B This is a flowchart illustrating the installation and activation process steps involved in Example 1, performed by the OTA manager and the target electronic control unit.

[0026] Figure 10AThis is a flowchart illustrating the installation and activation process steps involved in Example 2, performed by the OTA manager and the target electronic control unit.

[0027] Figure 10B This is a flowchart illustrating the installation and activation process steps involved in Example 2, performed by the OTA manager and the target electronic control unit. Detailed Implementation

[0028] In the network system for updating the software of the electronic control unit (ECU) disclosed herein, the central system sends the software update data and information related to the update sequence, which defines the steps of the software update process, to the OTA manager. Furthermore, the OTA manager controls the software update of the ECU based on the software update data and update sequence information received from the central system. This reduces the burden on the OTA manager and allows for the proper execution of the ECU software update process. Hereinafter, one embodiment of this disclosure will be described in detail with reference to the accompanying drawings.

[0029] System Structure

[0030] Figure 1 This is a block diagram illustrating the overall structure of a network system according to one embodiment of this disclosure. Figure 1 The network system shown is a system for updating the software of multiple electronic control units (ECUs) 50a to 50d installed in the vehicle, and has a center 10 located outside the vehicle and an in-vehicle network 90 built inside the vehicle.

[0031] (1) Center

[0032] The center 10 can communicate with the OTA manager 30 (described later) of the vehicle network 90 via the network 100 to send software update data for the electronic control units 50a-50d and information defining the update process steps, and receive notifications indicating the progress of the software update process. It controls and manages the software updates of multiple electronic control units 50a-50d connected to the OTA manager 30. The center 10 functions as a server.

[0033] Figure 2 It means Figure 1 A simplified block diagram of the structure of center 10. (See diagram below.) Figure 2As shown, the center 10 includes a CPU (Central Processing Unit) 11, RAM (Random Access Memory) 12, a storage device 13, and a communication device 14. The storage device 13 is a device equipped with a read / write storage medium such as a hard disk drive (HDD) or a solid-state drive (SSD), storing programs used for executing software update management, information used in software update control and management, and software update data for each electronic control unit. In the center 10, the CPU 11 executes programs read from the storage device 13 using the RAM 12 as its working area, thereby performing the prescribed processing related to software updates. The number of CPUs 11 is not limited to one. The communication device 14 is a device for communicating with the OTA manager 30 via the network 100.

[0034] Figure 3 yes Figure 2 The functional block diagram of center 10 is shown. Figure 3 The center 10 shown includes a storage unit 16, a communication unit 17, and a control unit 18. The functions of the storage unit 16 are achieved through... Figure 2 The storage device 13 shown is used for implementation. The functions of the communication unit 17 and the control unit 18 are achieved through... Figure 2 The CPU 11 shown uses RAM 12 to execute programs stored in storage device 13.

[0035] Storage unit 16 stores information related to software update processing for one or more electronic control units (ECUs) installed in the vehicle. As information related to software update processing, storage unit 16 stores update management information associated with information indicating software available for use in ECUs 50a-50d, and update data for the software of ECUs 50a-50d, for each vehicle identification information (vehicle ID) identifying the vehicle. For example, information indicating software available for use in ECUs 50a-50d can be defined as a combination of the latest version information of the software for multiple ECUs 50a-50d. Additionally, as information related to software update processing, storage unit 16 can store update status indicating the update status of software implemented in the vehicle. Furthermore, as information related to software update processing, storage unit 16 stores update sequence information related to instructions for controlling the OTA manager 30 and indicating steps of the software update processing. The information related to this update sequence defines steps of the software update processing, including at least verification, installation execution, and activation execution of the update data (updated software) of the ECU to be updated. The software update process steps can be defined for each of the multiple electronic control units 50a-50d (and their respective software), or they can be defined for each category of the non-volatile memory of the electronic control units 50a-50d (described later). Preferably, information related to the update sequence and the ECU_ID, which is a unique identifier for the electronic control unit, are stored in the storage unit 16 in an associated manner.

[0036] The communication unit 17 functions as a transmitter and receiver for sending and receiving data, information, and requests with the OTA manager 30. The communication unit 17 receives software update confirmation requests from the OTA manager 30 (receiving unit). An update confirmation request, for example, is information sent from the OTA manager 30 to the center 10 when the vehicle's power or ignition is turned on (hereinafter referred to as "power on"), and is used to request the center 10 to confirm the existence of update data for the electronic control units 50a to 50d based on the vehicle configuration information described later. Furthermore, in response to the update confirmation request received from the OTA manager 30, the communication unit 17 sends information indicating the presence or absence of update data to the OTA manager 30 (transmitting unit). Additionally, the communication unit 17 receives transmission requests (download requests) for distribution data packets from the OTA manager 30 (receiving unit). Furthermore, if the communication unit 17 receives a download request for a distribution data packet, it sends a distribution data packet generated by the control unit 18 (described later), including update data for the software of the electronic control units 50a to 50d and information related to the update sequence, to the OTA manager 30. Furthermore, in this embodiment, an example is described in which the software update data and information related to the update sequence are contained in one distribution data packet. However, the information related to the update sequence can also be sent by a distribution data packet that is separate from the software update data distribution data packet. This separate distribution data packet can be sent at other times during the software update process (e.g., together with information indicating the presence or absence of update data).

[0037] If the communication unit 17 receives an update confirmation request from the OTA manager 30, the control unit 18 determines, based on the update management information stored in the storage unit 16, whether software update data exists for the electronic control units 50a-50d installed in the vehicle whose vehicle ID is included in the update confirmation request. The determination result of the control unit 18 regarding the existence of update data is sent by the communication unit 17 to the OTA manager 30. If it is determined that software update data for the electronic control units 50a-50d exists, and a download request for a distribution data packet is received from the OTA manager 30, the control unit 18 generates a distribution data packet that includes the update data stored in the storage unit 16 and information related to the update sequence.

[0038] (2) In-vehicle network

[0039] The vehicle network 90 includes an OTA manager 30, multiple electronic control units 50a-50d, a display device 70, and a communication module 80. The OTA manager 30 and the communication module 80 are connected via bus 60a. The OTA manager 30 is connected to electronic control units 50a and 50b via bus 60b. The OTA manager 30 is connected to electronic control units 50c and 50d via bus 60c. The OTA manager 30 is connected to the display device 70 via bus 60d.

[0040] The OTA manager 30 can wirelessly communicate with the center 10 via the network 100 using the bus 60a and the communication module 80. Additionally, the OTA manager 30 can wiredly communicate with the electronic control units 50a-50d and the display device 70 via the buses 60b-60d. This OTA manager 30 manages OTA status and is a device that controls the software update process, i.e., the update sequence, to implement software updates for the electronic control units (hereinafter referred to as "target electronic control units") that are to be updated. The OTA manager 30 controls the software updates of the target electronic control units among the electronic control units 50a-50d based on update data obtained from the center 10 and information related to the update sequence. The OTA manager 30 may also be referred to as a central gateway (CGW).

[0041] Figure 4 It means Figure 1 A simplified block diagram of the OTA Manager 30 in the system. (See diagram below.) Figure 4 As shown, the OTA manager 30 includes a CPU 31, RAM 32, ROM (Read-Only Memory) 33, storage device 34, and communication device 36. The CPU 31, RAM 32, ROM 33, and storage device 34 constitute a microcomputer 35. In the OTA manager 30, the CPU 31 executes programs read from the ROM 33 using the RAM 32 as its working area, thereby performing the processing required for software updates. The number of CPUs 31 is not limited to one. The communication device 36 is used for... Figure 1 The devices shown are for communicating with the communication module 80, the electronic control unit 50a-50d, and the display device 70, respectively.

[0042] Figure 5 yes Figure 4 The diagram shown is a functional block diagram of OTA Manager 30. Figure 5 The OTA manager 30 shown includes a storage unit 37, a communication unit 38, and a control unit 39. The functions of the storage unit 37 are as follows: Figure 4 The storage device 34 shown is used for implementation. The functions of the communication unit 38 and the control unit 39 are achieved through... Figure 4The CPU 31 shown uses RAM 32 to execute programs stored in ROM 33.

[0043] In addition to storing the program (control program for OTA manager 30) used to perform software updates for the multiple electronic control units 50a-50d, and various data used during software updates, the storage unit 37 also stores software update data downloaded from the center 10 and information related to the update sequence. Furthermore, the storage unit 37 stores information related to the type of non-volatile memory mounted on each of the multiple electronic control units 50a-50d (described later).

[0044] The communication unit 38 functions as a sending and receiving unit for transmitting and receiving data, information, and requests with the center 10. For example, the communication unit 38 sends a software update confirmation request to the center 10 (sending unit) when the vehicle's power is turned on. The update confirmation request includes, for example, the vehicle ID used to identify the vehicle and information related to the current version of the software of the electronic control units 50a-50d connected to the vehicle network 90. ​​The vehicle ID and the current version of the software of the electronic control units 50a-50d are used to determine whether update data for the software of the electronic control units 50a-50d exists by comparing it with the latest version of the software maintained by the center 10 for each vehicle ID. In addition, the communication unit 38 receives a notification from the center 10 indicating the presence or absence of update data as a response to the update confirmation request (receiving unit). When software update data for electronic control units 50a-50d is available, the communication unit 38 sends a download request for a distribution data packet, including the software update data and information related to the update sequence, to the center 10 (transmitting unit), and receives (downloads) the distribution data packet sent from the center 10 (receiving unit). Additionally, the communication unit 38 sends the software update status sent by the electronic control units 50a-50d to the center 10 (transmitting unit).

[0045] The control unit 39 determines whether software update data for electronic control units 50a-50d exists based on the response from the center 10 to the update confirmation request received by the communication unit 38. Furthermore, the control unit 39 verifies the authenticity of the distribution data packets received (downloaded) from the center 10 by the communication unit 38 and stored in the storage unit 37. Additionally, the control unit 39 uses the update data received (downloaded) from the center 10 and controls the software update process (various verifications, installations, activations, etc.) of the electronic control units 50a-50d based on information related to the update sequence. Specifically, the control unit 39 forwards one or more update data packets downloaded via distribution data packets to the target electronic control unit, causing the target electronic control unit to install the update software based on the update data. After installation, the control unit 39 instructs the target electronic control unit to activate the installed update software. During this software update process, the control unit 39 appropriately controls various verification, installation, and activation steps among the multiple electronic control units 50a-50d based on information related to the update sequence.

[0046] Multiple electronic control units (ECUs) 50a to 50d are devices used to control the actions of various parts of the vehicle. Figure 1 The example shown is an in-vehicle network 90 with four electronic control units 50a to 50d, but the number of electronic control units is not particularly limited. Furthermore, the number of buses connecting the electronic control units 50a to 50d to the OTA manager 30 is also not particularly limited. Figure 6A as well as Figure 6B An example of a simplified structure of the electronic control units 50a to 50d is shown.

[0047] Figure 6A The illustrated electronic control unit 50a includes a CPU 51, RAM 52, non-volatile memory 53a, and a communication device 54. The CPU 51 executes programs read from the non-volatile memory 53a using RAM 52 as its working area to implement the functions of the electronic control unit 50a. The non-volatile memory 53a is a memory having a single storage area (library) 55 for storing data such as software (hereinafter referred to as "single-library memory"). In this embodiment, the memory type of the non-volatile memory 53a, which is a single-library memory, is sometimes referred to as "Category 1" to distinguish it from others. In addition to storing software for implementing the functions of the electronic control unit 50a, the storage area 55 sometimes also stores version information, parameter data, boot programs for startup, software update programs, etc. The communication device 54 is a device for communicating with the OTA manager 30 and other electronic control units 50b to 50d connected to the vehicle network 90.

[0048] Figure 6BThe electronic control unit 50b shown is similar to the electronic control unit 50a, including a CPU 51, RAM 52, non-volatile memory 53b, and a communication device 54. The non-volatile memory 53b mounted in the electronic control unit 50b is a memory with two storage areas (libraries) 56a and 56b for storing software and other data (hereinafter referred to as "dual-library memory"). In this embodiment, the memory type of the non-volatile memory 53b, which is a dual-library memory, is sometimes referred to as "Category 2" to distinguish it from others. In addition to storing software for implementing the functions of the electronic control unit 50b, storage areas 56a and 56b sometimes also store version information, parameter data, boot programs, software update programs, etc. The CPU 51 of the electronic control unit 50b uses either of the two storage areas 56a and 56b of the non-volatile memory 53b as the storage area (application area) to be read, and executes the software stored in the storage area to be read. For storage areas other than the read object (non-application surface, write surface), the installation (writing) of update software (updated version of the program) based on the updated data can be performed in the background while the program for the read object's storage area (application surface) is being executed. During activation (validation of the update software) in the software update process, the update software is activated by switching the storage area of ​​the read object of the program by the CPU 51 of the electronic control unit 50b.

[0049] As a specific example, consider a scenario where current software is stored in storage area 56a of the non-volatile memory 53b, which is a dual-library memory, and update software is installed in storage area 56b. If the update software is activated by the OTA manager 30, for example, the electronic control unit 50b switches the storage area of ​​the CPU 51's read target (application plane) by switching the read start address of the CPU 51 from the start address of storage area 56a to the start address of storage area 56b, and executes the update software installed in storage area 56b. In this disclosure, a non-volatile memory structure called "single-sided suspended memory," which virtually divides one storage area into two planes and allows writing of a program stored on one plane to the other plane while executing a program stored on one plane, is also classified as a second type of memory.

[0050] Figure 7 An example of category information, related to the category of non-volatile memory respectively mounted in multiple electronic control units 50a-50d, is shown. Figure 7In the illustrated category information, the number used to identify the electronic control unit, i.e., ECU_ID, is associated with the category (Category 1 (single library) / Category 2 (dual library)) of the non-volatile memory mounted on the electronic control unit. This category information is managed by storing it in either the storage unit 37 of the OTA manager 30 or the storage unit 16 of the center 10. The category information can be pre-created based on the specifications of the electronic control units 50a to 50d constituting the vehicle network 90, stored in the storage unit 37 during vehicle manufacturing, or retrieved from the target electronic control unit via communication within the vehicle network 90 during software update processing. Furthermore, when the category information is managed by the center 10, the OTA manager 30 can retrieve the category information from the center 10 via the network 100.

[0051] The display device 70 is a human-machine interface (HMI) used for various displays, such as displaying the existence of update data during software update processing of the electronic control units 50a-50d, displaying a consent request screen for requesting consent for software updates from vehicle users and administrators, and displaying the results of software updates. Typically, a display device from a car navigation system can be used as the display device 70, but it is not particularly limited as long as it can display the information required for software update processing. Furthermore, in Figure 1 The bus 60d shown can connect to electronic control units, etc., in addition to the display device 70.

[0052] The communication module 80 is a unit that enables communication between the control center 10 and the vehicle. It is a communication device used to connect the vehicle network 90 to the control center 10. The communication module 80 wirelessly connects to the control center 100 to perform vehicle authentication, download update data, and other functions related to the OTA manager 30. This communication module 80 can be configured to be included within the OTA manager 30.

[0053] Summary of software update processing

[0054] The OTA manager 30 sends a software update confirmation request to the center 10, for example, when the vehicle is powered on. The update confirmation request includes a vehicle ID and vehicle configuration information to identify the vehicle. This configuration information is related to the status (system configuration) of the electronic control units 50a-50d connected to the vehicle network 90, such as the current version of their hardware and software. The vehicle configuration information can be created by obtaining the identification number (ECU_ID) and the software version identification number (ECU_Software_ID) of the electronic control units 50a-50d connected to the vehicle network 90. ​​The vehicle ID and the current version of the software for the electronic control units 50a-50d are used to determine whether software update data for the electronic control units 50a-50d exists by comparing it with the latest version of the software maintained by the center 10 for each vehicle ID. The center 10 sends a notification indicating the presence or absence of update data to the OTA manager 30 as a response to the update confirmation request received from the OTA manager 30. When update data for the software of electronic control units 50a to 50d is available, the OTA manager 30 sends a download request for a distribution data package to the center 10. The center 10, based on the download request received from the OTA manager 30, sends a distribution data package to the OTA manager 30, including the update data and information related to the update sequence (the order of various verifications, installations, activations, etc.). The distribution data package may include, in addition to the update data and information related to the update sequence, verification data for verifying the authenticity of the update data, the quantity and category of the update data, and various control information used during the software update.

[0055] The OTA manager 30 determines whether software update data for the electronic control units 50a-50d exists based on the response to the update confirmation request received from the center 10. Additionally, the OTA manager 30 verifies the authenticity of the distribution data packets received from the center 10 and stored in the storage device 13. Furthermore, based on the update sequence information included in the distribution data packets, the OTA manager 30 forwards one or more update data packets downloaded via the distribution data packets to the target electronic control units, causing the target electronic control units to install the update data (updated software). After installation, the OTA manager 30 instructs the target electronic control units to activate the installed updated software based on the update sequence information included in the distribution data packets.

[0056] Furthermore, during the consent request processing, the OTA manager 30 outputs a notification to the output device that consent is required for a software update, or a notification urging consent to the software update. The output device can be a display device 70 installed in the vehicle network 90, or a voice output device (not shown) that provides voice-based notifications. For example, when using the display device 70 as the output device during consent request processing, the OTA manager 30 can display a consent request screen on the display device 70 requesting consent from the user or administrator for the software update, or display a notification urging the user or administrator to press the consent button if they consent. Additionally, during consent request processing, the OTA manager 30 can display statements, icons, etc., on the display device 70 indicating the existence of software update data for the electronic control units 50a to 50d; and display limitations in the execution of the software update process. If the OTA manager 30 receives consent input from the user or administrator, it executes the aforementioned installation and activation control processing to update the software of the target electronic control unit.

[0057] Here, when the non-volatile memory of the target electronic control unit is a single-library memory, since installation and activation are performed sequentially in principle, a request for consent to software updates is processed before installation. Even for a target electronic control unit with a single-library memory, based on information related to the update sequence indicated by center 10, there may be a request to temporarily halt update processing, i.e., postpone (standby) activation, after installation is complete. Furthermore, when the non-volatile memory of the target electronic control unit is a dual-library memory, the request for consent to software updates is processed at least after installation and before activation. Additionally, when the non-volatile memory of the target electronic control unit is a dual-library memory, the request for consent to software updates before installation can be performed or omitted.

[0058] The software update process consists of the following stages: the OTA manager 30 downloads update data and information related to the update sequence from the center 10 (download stage); the OTA manager 30 transfers the downloaded update data to the target electronic control unit based on the information related to the update sequence and installs the update software based on the update data in the storage area of ​​the target electronic control unit (installation stage); and the target electronic control unit activates the update software installed based on the information related to the update sequence (activation stage).

[0059] The download process involves the OTA manager 30 receiving update data for updating the software of the electronic control unit (ECU) sent from the center 10 via a distribution data packet and storing it in the storage unit 37. Regarding the reception of update data related to the download, priority can be given to receiving update data for ECUs equipped with Type 2 non-volatile memory (dual-base memory), which has a lower probability of update failure. Alternatively, update data for ECUs equipped with Type 1 non-volatile memory (single-base memory) and update data for ECUs equipped with Type 2 non-volatile memory (dual-base memory) can be received indiscriminately. The download phase includes not only the execution of the download but also the control of a series of download-related processes, such as determining whether the download can be executed and verifying the update data.

[0060] The update data sent from center 10 to OTA manager 30 may include any of the following: update software for the electronic control unit (ECU) (complete data or differential data), compressed data obtained by compressing the update software, or split data obtained by splitting the update software or compressed data. Additionally, the update data may include the ECU_ID (or serial number) of the target ECU and the ECU_Software_ID of the target ECU before the update. The update data is downloaded as the aforementioned distribution data packet, but the distribution data packet may include update data for a single ECU or multiple ECUs.

[0061] The installation process involves the OTA manager 30 writing update software (updated program) into the non-volatile memories 53a and / or 53b of multiple target electronic control units in a predetermined order, based on the update data downloaded from the center 10 and information related to the update sequence. The installation phase includes not only the execution of the installation but also the control of a series of installation-related processes, such as determining whether the installation can be executed, transferring update data, and verifying the update software.

[0062] When the update data includes the update software itself (complete data), the OTA manager 30 transfers the update data (update software) to the target electronic control unit (ECU) during the installation phase. Alternatively, when the update data includes compressed, differential, or segmented data of the update software, the OTA manager 30 may transfer the update data to the target ECU, which then generates the update software based on the update data. Or, the OTA manager 30 may 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 achieved by decompressing compressed data or combining (integrating) differential or segmented data.

[0063] The installation of the updated software is performed by the target electronic control unit based on an installation request from the OTA manager 30, which is based on information related to the update sequence obtained from the center 10. Furthermore, a specific target electronic control unit that receives the update data can perform the installation autonomously without explicit instructions from the OTA manager 30.

[0064] Activation is the process by which the target electronic control unit validates (activates) the updated software installed in the non-volatile memory 53a and / or 53b. The activation phase includes not only the execution of activation but also a series of controls related to activation, such as determining whether activation is feasible, requesting consent from the vehicle user or administrator for activation, and verifying the execution result.

[0065] The activation of the updated software is performed by the target electronic control unit based on an activation request from the OTA manager 30, which is based on information related to the update sequence obtained from the center 10. Furthermore, a specific target electronic control unit that receives the update data can activate itself after installation without explicit instructions from the OTA manager 30.

[0066] Furthermore, software update processing can be performed sequentially or in parallel for multiple target electronic control units.

[0067] In addition, the "software update processing" in this manual includes not only the entire process of continuous downloading, installation and activation, but also the process of only performing a part of the downloading, installation and activation.

[0068] deal with

[0069] Next, refer to Figure 8 , Figure 9A , Figure 9B , Figure 10A as well as Figure 10B Here are some specific examples related to software update processing performed in the network system involved in this embodiment.

[0070] (1) Specific examples of downloading

[0071] Figure 8 This is a flowchart illustrating the processing steps involved in a specific example of downloading data from the center 10 and the OTA manager 30. The process begins when the center 10 receives a download request for a distribution data packet from the OTA manager 30. Figure 8 Example of download.

[0072] (Step S801) Center 10 obtains information related to the update sequence of the target electronic control unit (hereinafter referred to as "target ECU") that is the object of the software update. This acquisition can be performed by Center 10 receiving information related to the update sequence from the vehicle manufacturer (OEM), or by Center 10 generating the information related to the update sequence itself based on various information provided by the OEM and the vehicle. If the information related to the update sequence is obtained, the process proceeds to step S802.

[0073] (Step S802) Center 10 generates a distribution data packet including update data for the target ECU and information related to the update sequence. Update data for the target ECU is provided in advance from the OEM, etc. If a distribution data packet is generated, the process proceeds to step S802.

[0074] (Step S803) Center 10 sends the generated distribution data packet to OTA Manager 30. If the distribution data packet has been sent, the process proceeds to step S804.

[0075] (Step S804) The OTA manager 30 stores the update data and other information included in the distribution data packet received from the center 10 in the storage unit 37. Thus, the download process ends.

[0076] In a specific example of the above distribution process, the center 10 sends a distribution data packet, including update data for the target ECU and information related to the update sequence, to the OTA manager 30. Through this process, the OTA manager 30 can implement update processing for each target ECU according to the steps of the software update process defined by the update sequence-related information provided by the center 10. The update sequence-related information can, for example, independently indicate update steps suitable for each target ECU, and can also indicate update steps between ECUs for multiple target ECUs requiring coordinated actions. Therefore, since the OTA manager 30 can easily implement update processing suitable for the target ECU based on the update sequence-related information without having to control / manage the functions and dependencies of multiple target ECUs itself, the processing burden of the OTA manager 30 can be reduced.

[0077] Furthermore, as information related to the update sequence, it is not necessary to send all the software update processing steps of the target ECU to the OTA manager 30 every time. For example, for a target ECU whose software update processing is always the same and is not affected by other target ECUs, it can be defined that the information related to the update sequence is included only when the initial distribution data packet is generated. The OTA manager 30 only needs to store part or all of the update sequence-related information sent via the initial distribution data packet in the storage unit 37, and read and use the required information from the storage unit 37 during the next software update processing.

[0078] (2) Specific example of installation and activation 1

[0079] Figure 9A as well as Figure 9B This is a flowchart illustrating the installation and activation steps involved in Example 1 for the OTA manager 30 and the target ECU. Figure 9A processing and Figure 9B The processing is done through the connector X.

[0080] exist Figure 9A as well as Figure 9B In the specific example 1 shown, the installation of update software for a target ECU equipped with a type 2 non-volatile memory (dual-library memory) (hereinafter referred to as "type 2 target ECU") is prioritized over the installation of update software for a target ECU equipped with a type 1 non-volatile memory (single-library memory) (hereinafter referred to as "type 1 target ECU") as an example of information related to the update sequence received by the OTA manager 30 from the center 10.

[0081] As an example of the update sequence related information in this specific example 1, the steps for software update processing for target ECUs of category 1 can be illustrated as "update data verification → postpone → install → activate", and the steps for software update processing for target ECUs of category 2 can be "update data verification → install → postpone → activate". Furthermore, the update sequence related information can include, in addition to defining the individual software update processing steps for target ECUs of category 1 and category 2, indicating the relative processing priority among multiple target ECUs as "update data verification → installation of target ECUs of category 2 → installation of target ECUs of category 1 → activation of target ECUs of category 1 → activation of target ECUs of category 2".

[0082] After the OTA Manager 30 has completed downloading the distribution data packet containing the update data of the target ECU and information related to the update sequence, and after the specified conditions (installation executable, verification of update data, etc.) are met, the processing of this specific example 1 begins.

[0083] (Step S901) The OTA manager 30 obtains the information related to the update sequence included in the distribution data packet, as well as the category (Category 1 / Category 2) of the non-volatile memory mounted on the target ECU. For this memory category, when managed by the OTA manager 30, the category information stored in the storage unit 37 can be referenced. Figure 7The information can be obtained by referring to the memory category information contained in the distribution data packet when managed by the center 10. If the information related to the update sequence and the memory category of the target ECU are obtained, the process proceeds to step S902.

[0084] (Step S902) The OTA manager 30 and the target ECU of the second category begin the process of writing the update software into the storage area of ​​the non-volatile memory of the target ECU of the second category, i.e., installation, based on the update data and information related to the update sequence. In the information related to the update sequence in this specific example 1, a "update data verification → postponement" step is defined for the target ECU of the first category, and a "update data verification → installation" step is defined for the target ECU of the second category. According to this step, after the verification of each update data, the installation of the update software in the target ECU of the second category begins before the installation of the update software in the target ECU of the first category. The installation begins simultaneously or in a predetermined order for all target ECUs of the second category. If the installation for the target ECU of the second category begins, the process proceeds to step S903.

[0085] (Step S903) The OTA manager 30 determines whether the installation of the update software in the target ECU of category 2 is complete. The OTA manager 30 can determine completion for all target ECUs of category 2, or only for a predetermined subset of target ECUs of category 2. The OTA manager 30 can determine completion based on the presence of completion notifications from the target ECUs of category 2, or based on a predetermined time elapsed since the start of installation. The predetermined time can be, for example, set to a maximum time required for each installation. If the installation of the update software in the target ECU of category 2 is determined to be complete (Step S903, Yes), the process proceeds to step S904.

[0086] (Step S904) The OTA manager 30 and the target ECU of category 1 begin the process of writing update software into the storage area of ​​the non-volatile memory of the target ECU of category 1, i.e., installation, based on update data and information related to the update sequence. On the other hand, the OTA manager 30 and the target ECU of category 2 postpone the activation of the update software written to the storage area of ​​the non-volatile memory of the target ECU of category 2, based on information related to the update sequence. In the update sequence related information of this specific example 1, a "postponement → installation" step is defined for the target ECU of category 1, and a "installation → postponement" step is defined for the target ECU of category 2. According to this step, after the installation of the update software in the target ECU of category 2, the installation of the update software in the target ECU of category 1 begins before the activation of the update software in the target ECU of category 2. The installation for all target ECUs of category 1 begins simultaneously or in a predetermined order. If the installation for the target ECU of category 1 begins, the process proceeds to step S905.

[0087] (Step S905) The OTA manager 30 determines whether the installation of the update software in the target ECU of category 1 is complete. The installation is completed for all target ECUs of category 1. The OTA manager 30 can determine completion based on the presence of a completion notification from the target ECU of category 1, or based on the elapsed time since the start of installation. The specified time can be set, for example, to be greater than the maximum time required for each installation. If the installation of the update software in the target ECU of category 1 is determined to be complete (step S905, Yes), the process proceeds to step S906.

[0088] (Step S906) The OTA manager 30 and the target ECU of category 1 begin activating the update software written to the storage area of ​​the non-volatile memory of the target ECU of category 1. In the information related to the update sequence in this specific example 1, an "install → activate" step is defined for the target ECU of category 1, and a "delay → activate" step is defined for the target ECU of category 2. According to this step, after the update software in the target ECU of category 1 is installed, the activation of the update software in the target ECU of category 1 begins before the activation of the update software in the target ECU of category 2. The activation begins simultaneously or in a predetermined order for all target ECUs of category 1. If the activation of the update software in the target ECU of category 1 begins, the process proceeds to step S907.

[0089] (Step S907) The OTA manager 30 determines whether the activation of the update software in the target ECU of category 1 is complete. The activation completion is determined for all target ECUs of category 1. The OTA manager 30 can determine activation completion based on the presence of a completion notification from the target ECU of category 1, or based on the elapsed time since the start of activation. The specified time can be set, for example, to be greater than the maximum time required for each activation. If the activation of the update software in the target ECU of category 1 is determined to be complete (step S907, Yes), the process proceeds to step S908.

[0090] (Step S908) The OTA manager 30 and the target ECU of the second category begin activating the update software written to the storage area of ​​the non-volatile memory of the target ECU of the second category. In the information related to the update sequence in this specific example 1, a "delay → activation" step is defined for the target ECU of the second category. According to this step, after the activation of the update software in the target ECU of the first category, the activation of the update software in the target ECU of the second category begins. The activation begins simultaneously or in a predetermined order for all target ECUs of the second category. If the activation of the update software in the target ECU of the second category begins, the process proceeds to step S909.

[0091] (Step S909) The OTA manager 30 determines whether the activation of the update software in the target ECU of category 2 is complete. The activation completion is determined for all target ECUs of category 2. The OTA manager 30 can determine activation completion based on the presence of a completion notification from the target ECU of category 2, or based on the elapsed time since the start of activation. The specified time can be set, for example, to be greater than the maximum time required for each activation. If the activation of the update software in the target ECU of category 2 is determined to be complete (Step S909, Yes), then the installation and activation of all target electronic control units are complete, and this process ends.

[0092] In the specific example 1 above, the installation and activation processes for the first-category target ECU and the second-category target ECU are progressively advanced based on the software update status of the other target ECU. Through this process, for example, installation can begin first for the second-category target ECU, for which control does not need to be stopped during the update, and after determining that the installation of the second-category target ECU is complete, installation can begin for the first-category target ECU, for which control needs to be stopped during the update. Therefore, the OTA manager 30 can easily implement software update processes suitable for each target ECU, such as reducing the communication load within the vehicle network 90 and shortening the time required to stop vehicle control until all update software is written, based on information related to the update sequence indicated by the center 10.

[0093] (3) Specific example 2 of installation and activation

[0094] Figure 10A as well as Figure 10B This is a flowchart illustrating the installation and activation steps involved in Example 2 for the OTA Manager 30 and the target ECU. Figure 10A processing and Figure 10B The processing is done through the connector Y.

[0095] exist Figure 10A as well as Figure 10B In the specific example 2 shown, the steps for software update processing suitable for each target ECU are defined for multiple target ECUs (-A, -B, -C) regardless of the type of non-volatile memory, as an example of the information related to the update sequence received by the OTA manager 30 from the center 10.

[0096] As an example of the update sequence related information in this specific example 2, the steps for software update processing for target ECU-A can be illustrated as "update data verification → installation → activation", the steps for software update processing for target ECU-B as "update data verification → installation → postponement → activation", and the steps for software update processing for target ECU-C as "update data verification → postponement → installation → activation". Alternatively, the update sequence related information could also include, in addition to defining the individual software update processing steps for multiple target ECUs (-A, -B, -C), indicating the relative processing priority among the multiple target ECUs as "update data verification → installation of target ECUs-A & B → activation of target ECU-A & installation of target ECU-C → activation of target ECU-C → activation of target ECU-B".

[0097] After the OTA Manager 30 has finished downloading the distribution data package containing the update data of the target ECU and information related to the update sequence, and after the specified conditions (installation executable, verification of update data, etc.) are met, the processing of this specific example 2 begins.

[0098] (Step S1001) The OTA manager 30 obtains information related to the update sequence from the distribution data packet. If the information related to the update sequence is obtained, the process proceeds to step S1002.

[0099] (Step S1002) The OTA manager 30, target ECU-A, and target ECU-B begin the process of writing update software into the storage areas of their respective non-volatile memories based on update data and information related to the update sequence; that is, installation. In the update sequence-related information of this specific example 2, a "Update data verification → Installation" step is defined for target ECU-A, a "Update data verification → Installation" step is defined for target ECU-B, and a "Update data verification → Delay" step is defined for target ECU-C. According to this step, after verifying each update data, the installation of update software in target ECU-A and target ECU-B begins before the installation of update software in target ECU-C. The installation for target ECU-A and target ECU-B begins simultaneously or in a predetermined order. If the installation for target ECU-A and target ECU-B begins, the process proceeds to step S1003.

[0100] (Step S1003) The OTA manager 30 determines whether the installation of the update software in target ECU-A and target ECU-B is complete. The OTA manager 30 can determine the completion of the installation based on the presence of completion notifications from target ECU-A and target ECU-B respectively, or based on the elapsed time since the start of the installation. The specified time can be set to, for example, the maximum time required for each installation. If it is determined that the installation of the update software in target ECU-A and target ECU-B is complete (step S1003, yes), the process proceeds to step S1004.

[0101] (Step S1004) The OTA manager 30 and the target ECU-A begin activating the update software written to the storage area of ​​the non-volatile memory of the target ECU-A based on the update data and information related to the update sequence. Additionally, the OTA manager 30 and the target ECU-C begin the process of writing the update software to the storage area of ​​the non-volatile memory of the target ECU-C, i.e., installation, based on the update data and information related to the update sequence. On the other hand, the OTA manager 30 and the target ECU-B postpone the activation of the update software written to the storage area of ​​the non-volatile memory of the target ECU-B based on the update sequence information. In the update sequence information of this specific example 2, a "install → activate" step is defined for the target ECU-A, a "install → postpone" step is defined for the target ECU-B, and a "postpone → install" step is defined for the target ECU-C. According to this process, after the update software in the target ECU-A and target ECU-B is installed, the activation of the update software in the target ECU-A and the installation of the update software in the target ECU-C begin before the activation of the update software in the target ECU-B. If activation of target ECU-A and installation of target ECU-C begin, the process proceeds to step S1005.

[0102] (Step S1005) The OTA manager 30 determines whether the activation of the update software in the target ECU-A is complete. The OTA manager 30 can determine the completion of activation based on the presence of a completion notification from the target ECU-A, or based on the elapsed time since the start of activation. The specified time can be set to, for example, more than the time required for activation. If it is determined that the activation of the update software in the target ECU-A is complete (step S1005, yes), the process proceeds to step S1006.

[0103] (Step S1006) The OTA manager 30 determines whether the installation of the update software in the target ECU-C is complete. The OTA manager 30 can determine the completion of the installation based on the presence of a completion notification from the target ECU-C, or based on the elapsed time since the start of the installation. The specified time can be set to, for example, more than the time required for the installation. If it is determined that the installation of the update software in the target ECU-C is complete (Step S1006, Yes), the process proceeds to step S1007.

[0104] (Step S1007) The OTA manager 30 and the target ECU-C begin activating the update software written to the storage area of ​​the non-volatile memory of the target ECU-C. In the information related to the update sequence in this specific example 2, a "install → activate" step is defined for the target ECU-C, and a "delay → activate" step is defined for the target ECU-B. According to this step, after the update software in the target ECU-C is installed, the activation of the update software in the target ECU-C begins before the activation of the update software in the target ECU-B. If the activation of the update software in the target ECU-C begins, the process proceeds to step S1008.

[0105] (Step S1008) The OTA manager 30 determines whether the activation of the update software in the target ECU-C is complete. The OTA manager 30 can determine the completion of activation based on the presence of a completion notification from the target ECU-C, or based on the elapsed time since the start of activation. The specified time can be set to, for example, more than the time required for activation. If it is determined that the activation of the update software in the target ECU-C is complete (Step S1008, Yes), the process proceeds to step S1009.

[0106] (Step S1009) The OTA manager 30 and the target ECU-B begin activating the update software written to the storage area of ​​the non-volatile memory of the target ECU-B. In the update sequence related information of this specific example 2, a "delay → activation" step is defined for the target ECU-B. According to this step, after the activation of the update software in the target ECU-C, the activation of the update software in the target ECU-B begins. If the activation of the update software in the target ECU-B begins, the process proceeds to step S1010.

[0107] (Step S1010) The OTA manager 30 determines whether the activation of the update software in the target ECU-B is complete. The OTA manager 30 can determine the completion of activation based on the presence of a completion notification from the target ECU-B, or based on the elapsed time since the start of activation. The specified time can be set to more than the time required for activation. If the activation of the update software in the target ECU-B is determined to be complete (Step S1010, Yes), then the installation and activation of all target electronic control units are complete, and this process ends.

[0108] In the specific example 2 above, target ECU-A undergoes software update processing independently, while target ECU-B and target ECU-C gradually proceed with installation and activation processes based on the software update status of each other's target ECUs. Through this process, for example, the installation of target ECU-B's update software can be performed in parallel with the software update processing of target ECU-A, taking precedence over the installation of target ECU-C's update software. Therefore, the OTA manager 30 can easily implement software update processes suitable for each target ECU based on information related to the update sequence provided (instructed) from the center 10.

[0109] Furthermore, in the above-mentioned specific example 2, the determination of the completion of the installation of the update software of target ECU-A (step S1003) and the determination of the completion of activation (step S1005) can be performed after the determination of the completion of the installation of the update software of target ECU-C (step S1006), or can be performed together with the determination of the completion of the activation of the update software of target ECU-B (step S1010) or the determination of the completion of the activation of the update software of target ECU-C (step S1008).

[0110] Furthermore, in the specific example 2 above, an example was given of defining software update processing steps suitable for each target ECU regardless of the type of non-volatile memory, as information related to the update sequence. However, software update processing steps suitable for each target ECU can also be defined based on the type of non-volatile memory. That is, the center 10 can generate update sequence-related information suitable for the target ECU based not only on the function and performance of the target ECU, but also on the type information of the non-volatile memory installed in the target ECU. In this case, for example, the center 10 can generate two types of information for one target ECU: software update processing steps applicable when it is a single-library memory specification and software update processing steps applicable when it is a dual-library memory specification.

[0111] Functions and Effects

[0112] As described above, in a network system according to one embodiment of this disclosure, the central unit sends software update data and information related to an update sequence defining the steps of the software update process to the OTA manager. Furthermore, the OTA manager controls the software update of the electronic control unit based on the software update data and update sequence information received from the central unit.

[0113] Through this process, the center can distribute software update data to the vehicle and enable the OTA manager to actively control the software update process of the target electronic control unit in the vehicle. On the other hand, since the OTA manager only passively advances the software update process of the target electronic control unit based on instructions from the center, it does not need to know the specifications of all electronic control units installed in the vehicle during the software update process, thus reducing the burden associated with controlling the software update process. For example, if the non-volatile memory of the target electronic control unit is changed from single-library memory to dual-library memory due to replacement, the center switches the information related to the update sequence from single-library memory to dual-library memory and sends it to the OTA manager, thereby enabling the OTA manager to perform the software update process without any burden.

[0114] The above describes one embodiment of the technology disclosed herein. However, this disclosure can be understood not only as a center, but also as a distribution method, distribution program, computer-readable non-transitory storage medium storing the distribution program, OTA manager capable of communicating with the center, system having a center and an OTA manager, or vehicle having an OTA manager, etc.

[0115] The technology disclosed herein can be utilized in network systems used for updating the software of electronic control units.

Claims

1. A software update control center, characterized in that, The software update control center includes one or more processors configured to send update data of the software of multiple electronic control units installed in the vehicle, along with information related to the update sequence that defines the steps of the software update process, to the OTA manager. The update process includes verifying the update data, installing the update data, and activating the update data. The software update control center also comprises: A distribution data packet is generated, comprising update data of the software, information related to the update sequence, and category information mounted in the non-volatile memory of the plurality of electronic control units, wherein the category information is associated with a single-library memory or a dual-library memory. The generated distribution data packet is then sent to the OTA manager. When the category information is associated with a single library storage, the consent request processing for the software update is executed before the installation of the update data and the activation of the update data. When the category information is associated with the dual-library memory, the consent request processing is executed after the installation of the updated data and before the activation of the updated data.

2. The software update control center according to claim 1, characterized in that, The software update data includes first update data for the software of a first electronic control unit and second update data for the software of a second electronic control unit. The first electronic control unit is equipped with a first-class non-volatile memory with one storage area, and the second electronic control unit is equipped with a second-class non-volatile memory with two storage areas. The plurality of electronic control units includes the first electronic control unit and the second electronic control unit. Furthermore, the information related to the update sequence includes the steps of the software update process for the first electronic control unit and the steps of the software update process for the second electronic control unit.

3. The software update control center according to claim 2, characterized in that, In the information related to the update sequence, the steps of the software update process of the first electronic control unit are different from those of the software update process of the second electronic control unit.

4. The software update control center according to claim 1, characterized in that, Information associated with the update sequence includes the steps of the software update process for each of the plurality of electronic control units.

5. An OTA manager, characterized in that, The OTA manager includes one or more processors, wherein the one or more processors are configured as follows: The software update control center receives update data for the software of multiple electronic control units installed in the vehicle, along with information related to the update sequence that defines the steps for processing the software update. Furthermore, the update process includes verifying the update data, installing the update data, and activating the update data. Information related to the update sequence is generated by the software update control center based on the category information of the non-volatile memory installed in the plurality of electronic control units. The software update control center generates a distribution data packet that includes update data for the software, information related to the update sequence, and category information. The category information is associated with a single-library storage or a dual-library storage. When the category information is associated with a single-library storage, the consent request processing for the software update is executed before the installation of the update data and before the activation of the update data. When the category information is associated with a dual-library storage, the consent request processing is executed after the installation of the update data and before the activation of the update data. The software updates of the plurality of electronic control units are controlled by performing the verification of the update data requests, the installation of the update data, and the activation of the update data based on the software update data and information related to the update sequence.

6. A software update control system, characterized in that, include: The software update control center includes one or more primary processors; and OTA manager, with one or more second processors, in, The one or more first processors are configured to send update data of the software of multiple electronic control units installed in the vehicle and information related to the update sequence that defines the steps of the software update process to the OTA manager. The update process comprises steps including verifying the update data, installing the update data, and activating the update data. The software update control center is configured as follows: A distribution data packet is generated, comprising software update data, information related to the update sequence, and category information stored in the non-volatile memory of the plurality of electronic control units. The category information is associated with either a single-library memory or a dual-library memory. If the category information is associated with a single-library memory, a consent request for software update is processed before the installation and activation of the update data. If the category information is associated with a dual-library memory, the consent request is processed after the installation and activation of the update data. And it is configured to send the generated distribution data packet to the OTA manager. Furthermore, the one or more second processors are configured to receive software update data and information related to the update sequence from the software update control center, and control the software update of the multiple electronic control units by requesting verification of the update data, executing the installation of the update data, and activating the update data based on the software update data and the information related to the update sequence.

7. A distribution method, executed by a software update control center having one or more processors and memory, characterized in that, include: Generate update data for the software of multiple electronic control units installed in the vehicle; Information related to an update sequence is generated and defined for steps of updating the software of the plurality of electronic control units, wherein the steps of the update process include verification of the update data, execution of installation of the update data, and execution of activation of the update data; A distribution data packet is generated, comprising update data of the software, information related to the update sequence, and category information stored in the non-volatile memory of the plurality of electronic control units. The category information is associated with a single-library memory or a dual-library memory. If the category information is associated with a single-library memory, a consent request for software updates is processed before the installation of the update data and before the activation of the update data. If the category information is associated with a dual-library memory, the consent request is processed after the installation of the update data and before the activation of the update data. The generated distribution data packet is sent to the OTA manager. The OTA manager is configured to control software updates by verifying requests for update data from the plurality of electronic control units, executing the installation of the update data, and activating the update data.

8. A non-transitory storage medium, characterized in that, The system stores commands that can be executed by a computer with one or more processors and memory, enabling the computer to perform the method of claim 7.

9. A vehicle, characterized in that, Includes the OTA manager as described in claim 5.

Images