CONTROL DEVICE, METHOD, PROGRAM, AND VEHICLE

Abstract

To provide a control device or the like capable of executing software update adapted to each of an in-vehicle device equipped with a single-bank memory and an in-vehicle device equipped with a dual-bank memory.SOLUTION: A control device includes: a receiving unit that receives first update data for a first in-vehicle device equipped with a first type nonvolatile memory having one storage area and second update data for a second in-vehicle device equipped with a second type nonvolatile memory having two storage areas; and a control unit. The control unit performs: first control for writing the second update data to the second in-vehicle device after the reception of the first update data and the second update data is completed and validating the second update data at a predetermined timing; and second control for writing the first update data to the first in-vehicle device and validating the first update data at a timing different from the predetermined timing after the reception of the first update data and the second update data is completed.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a control device that controls software updates for an electronic control unit. [Background technology]

[0002] A vehicle is equipped with multiple electronic control units (ECUs) for controlling the operation of the vehicle. Each electronic control unit includes a processor, a temporary storage unit such as a RAM, and a non-volatile memory that is a non-volatile storage unit such as a flash ROM, and the processor executes software stored in the non-volatile memory to realize the control functions of the electronic control unit. The software stored in each electronic control unit is rewritable, and by updating the software to a newer version, it is possible to improve the functions of each electronic control unit or add new vehicle control functions.

[0003] As a technology for updating software of an electronic control unit, there is known an OTA (Over The Air) technology in which an in-vehicle communication device connected to an in-vehicle network is wirelessly connected to a communication network such as the Internet, and a device in charge of updating software of the vehicle downloads software from a server via wireless communication and installs the downloaded software in the electronic control unit, thereby updating or adding software to the electronic control unit. For example, see Patent Document 1.

[0004] There are two types of non-volatile memory installed in electronic control units: memory with one storage area for storing software and other data (hereinafter referred to as "single bank memory"), and memory with two storage areas for storing software and other data (hereinafter referred to as "dual bank memory"), and they may be used depending on the specifications of the electronic control unit. Electronic control units equipped with dual bank memory can store two versions of data, one old and one new, in each of the two storage areas. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2004-326689 A Summary of the Invention [Problem to be solved by the invention]

[0006] Some control functions provided in a vehicle, such as autonomous driving, are realized by the cooperative operation of multiple electronic control units (or actuators). In addition, the multiple electronic control units that require this cooperative operation may include both an electronic control unit equipped with a single bank memory and an electronic control unit equipped with a dual bank memory. In this case, in order to execute the autonomous driving function, the control functions of the software of the multiple electronic control units that realize the autonomous driving must be consistent with each other. For this reason, for example, if the software update process is delayed in some of the multiple electronic control units that require cooperative operation, restrictions arise such that the autonomous driving function cannot be executed during that time.

[0007] For this reason, when a campaign, which is an event in which software updates are performed on vehicles, is applied to a vehicle in which electronic control units equipped with single bank memory and electronic control units equipped with dual bank memory are mixed as the electronic control units to be updated, if downloading, installation, activation, etc. are not performed appropriately according to the memory structure of the electronic control unit to be updated, there is a risk that functions that require coordinated operation by multiple electronic control units will be restricted for an extended period of time.

[0008] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a control device and the like that can perform software updates that are adapted to both an in-vehicle device equipped with a single bank memory and an in-vehicle device equipped with a dual bank memory. [Means for solving the problem]

[0009] In order to solve the above-mentioned problems, one aspect of the disclosed technology is a control device that includes a receiving unit that receives first update data intended for a first in-vehicle device equipped with a first type of non-volatile memory having one storage area and second update data intended for a second in-vehicle device equipped with a second type of non-volatile memory having two storage areas, and a control unit, in which the control unit performs a first control of writing the second update data to the second in-vehicle device after reception of the first update data and the second update data is completed, and enabling the second update data at a predetermined timing, and a second control of writing the first update data to the first in-vehicle device and enabling the first update data at a timing different from the predetermined timing after reception of the first update data and the second update data is completed. Effect of the Invention

[0010] According to the present disclosure, it is possible to provide a control device and the like that can execute software updates adapted to both an in-vehicle device equipped with a single bank memory and an in-vehicle device equipped with a dual bank memory. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram showing an overall configuration of a network system according to an embodiment; [Diagram 2] Block diagram showing the general configuration of the center [Diagram 3] Center functional block diagram [Figure 4] Block diagram showing the schematic configuration of the OTA master [Diagram 5] OTA Master Functional Block Diagram [Figure 6A]FIG. 1 is a block diagram showing an example of a schematic configuration of an electronic control unit; [Figure 6B] FIG. 1 is a block diagram showing an example of a schematic configuration of an electronic control unit; [Figure 7] FIG. 13 is a diagram showing an example of type information [Figure 8] Flowchart of download processing procedure performed by the center and OTA master [Figure 9] 1 is a flowchart of an installation process performed by an OTA master and a target electronic control unit according to a first embodiment of the present invention. [Figure 10] 13 is a flowchart of an installation process performed by an OTA master and a target electronic control unit according to a second embodiment of the present invention. [Figure 11] Flowchart of the activation process performed by the OTA master and the target electronic control unit DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] In the network system for updating software of electronic control units disclosed herein, an OTA master receives update data for an electronic control unit equipped with a single bank memory and update data for an electronic control unit equipped with a dual bank memory from a center. The OTA master installs the update data for the electronic control unit equipped with a dual bank memory after receiving the update data, and installs the update data for the target electronic control unit equipped with a single bank memory at a predetermined timing. This makes it possible to avoid a case where installation of the electronic control unit equipped with a dual bank memory fails and installation of the target electronic control unit equipped with a single bank memory succeeds, and makes it possible to perform software updates adapted to each of the electronic control units equipped with each memory. Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the drawings.

[0013] <Embodiment> [System Configuration] Fig. 1 is a block diagram showing an overall configuration of a network system according to an embodiment of the present disclosure. The network system shown in Fig. 1 is a system for updating software of a plurality of electronic control units (ECUs) 50a to 50d mounted on a vehicle, and includes a center 10 located outside the vehicle and an in-vehicle network 90 built inside the vehicle.

[0014] (1) Center The center 10 can communicate with an OTA master 30 (described later) provided in the in-vehicle network 90 via the network 100, and can transmit update data for the software of the electronic control units 50a to 50d and receive notifications indicating the progress of the software update process, thereby controlling and managing the software updates of the multiple electronic control units 50a to 50d connected to the OTA master 30. This center 10 has a function as a so-called server.

[0015] FIG. 2 is a block diagram showing a schematic configuration of the center 10 in FIG. 1. As shown in FIG. 2, the center 10 includes a central processing unit (CPU) 11, a random access memory (RAM) 12, a storage device 13, and a communication device 14. The storage device 13 is a device including a readable and writable storage medium such as a hard disk drive (HDD) or a solid state drive (SSD), and stores a program for performing software update management, information used for software update control and update management, and software update data for each electronic control unit. In the center 10, the CPU 11 executes a program read from the storage device 13 by using the RAM 12 as a working area, thereby performing a predetermined process related to software update. The communication device 14 is a device for communicating with the OTA master 30 via the network 100.

[0016] Fig. 3 is a functional block diagram of the center 10 shown in Fig. 2. The center 10 shown in Fig. 3 includes a storage unit 16, a communication unit 17, and a control unit 18. The storage unit 16 is realized by the storage device 13 shown in Fig. 2. The communication unit 17 and the control unit 18 are realized by the CPU 11 shown in Fig. 2 executing a program stored in the storage device 13 using the RAM 12.

[0017] The storage unit 16 stores information related to software update processing of one or more electronic control units mounted on the vehicle. As the information related to the software update processing, the storage unit 16 stores at least update management information in which information indicating software available in the electronic control units 50a to 50d is associated with each vehicle identification information (vehicle ID) that identifies the vehicle, and update data of the software of the electronic control units 50a to 50d. As the information indicating the software available in the electronic control units 50a to 50d, for example, a combination of the latest version information of each software of the multiple electronic control units 50a to 50d is defined. Furthermore, as the information related to the software update processing, the storage unit 16 can store an update status indicating the update status of the software being implemented in the vehicle.

[0018] The communication unit 17 functions as a transmitting unit and a receiving unit that transmits and receives data, information, requests, and the like to and from the OTA master 30. The communication unit 17 receives a software update confirmation request from the OTA master 30 (receiving unit). The update confirmation request is information transmitted from the OTA master 30 to the center 10 when, for example, the power supply or ignition is turned on in the vehicle (hereinafter referred to as "power ON"), and is information for requesting the center 10 to confirm whether or not there is update data for the electronic control units 50a to 50d based on vehicle configuration information described later. In addition, in response to the update confirmation request received from the OTA master 30, the communication unit 17 transmits information indicating the presence or absence of update data to the OTA master 30 (transmitting unit). In addition, the communication unit 17 receives a transmission request (download request) for a distribution package from the OTA master 30 (receiving unit). Furthermore, when the communication unit 17 receives a download request for a distribution package, it transmits to the OTA master 30 a distribution package including update data for the software of the electronic control units 50a to 50d, which is generated by the control unit 18 described later.

[0019] When the communication unit 17 receives an update check request from the OTA master 30, the control unit 18 determines whether or not there is software update data for the electronic control units 50a to 50d mounted on the vehicle identified by the vehicle ID included in the update check request, based on the update management information stored in the storage unit 16. The control unit 18 transmits the determination result of whether or not there is update data to the OTA master 30 by the communication unit 17. When the control unit 18 determines that there is software update data for the electronic control units 50a to 50d, and receives a download request for a distribution package from the OTA master 30, the control unit 18 generates a distribution package including the corresponding update data stored in the storage unit 16. The control unit 18 may individually generate a distribution package including only update data for an electronic control unit equipped with a single bank memory, which will be described later, and a distribution package including only update data for an electronic control unit equipped with a dual bank memory, which will be described later. The control unit 18 may also generate a distribution package including update data for an electronic control unit equipped with a single bank memory and update data for an electronic control unit equipped with a dual bank memory, which will be described later.

[0020] (2) In-vehicle network The in-vehicle network 90 includes an OTA master 30, a plurality of electronic control units 50a to 50d, a display device 70, and a communication module 80. The OTA master 30 and the communication module 80 are connected via a bus 60a. The OTA master 30 and the electronic control units 50a and 50b are connected via a bus 60b. The OTA master 30 and the electronic control units 50c and 50d are connected via a bus 60c. The OTA master 30 and the display device 70 are connected via a bus 60d.

[0021] The OTA master 30 can communicate wirelessly with the center 10 via the bus 60a and the communication module 80 and the network 100. The OTA master 30 can also communicate wired with the electronic control units 50a-50d and the display device 70 via the buses 60b-60d. The OTA master 30 is a device having a function of managing an OTA state, controlling an update sequence, which is a flow of a software update process, and performing software update of an electronic control unit to be updated (hereinafter referred to as a "target electronic control unit"). The OTA master 30 controls software update of the target electronic control unit among the electronic control units 50a-50d based on update data acquired from the center 10. The OTA master 30 is sometimes called a central gateway (CGW).

[0022] 4 is a block diagram showing a schematic configuration of the OTA master 30 in FIG. 1. As shown in FIG. 4, the OTA master 30 includes a CPU 31, a RAM 32, a ROM (Read-Only Memory) 33, a storage device 34, and a communication device 36. The CPU 31, the RAM 32, the ROM 33, and the storage device 34 constitute a microcomputer 35. In the OTA master 30, the CPU 31 executes a program read from the ROM 33 by using the RAM 32 as a working area, thereby executing a predetermined process related to software update. The communication device 36 is a device for communicating with the communication module 80, the electronic control units 50a to 50d, and the display device 70, respectively, via the buses 60a to 60d shown in FIG. 1.

[0023] Fig. 5 is a functional block diagram of the OTA master 30 shown in Fig. 4. The OTA master 30 shown in Fig. 5 includes a storage unit 37, a communication unit 38, and a control unit 39. The storage unit 37 is realized by the storage device 34 shown in Fig. 4. The communication unit 38 and the control unit 39 are realized by the CPU 31 shown in Fig. 4 executing a program stored in the ROM 33 using the RAM 32.

[0024] The storage unit 37 stores a program for executing software updates of the multiple electronic control units 50a to 50d (a control program for the OTA master 30), various data used when executing the software updates, and software update data downloaded from the center 10. The storage unit 37 also stores information (described later) related to the type of non-volatile memory mounted in each of the multiple electronic control units 50a to 50d.

[0025] The communication unit 38 functions as a transmitting unit and a receiving unit that transmits and receives data, information, requests, and the like to and from the center 10. The communication unit 38 transmits a software update check request to the center 10, for example, when the power of the vehicle is turned on (transmitting unit). The update check request includes, for example, a vehicle ID for identifying the vehicle and information on the current version of the software of the electronic control units 50a to 50d connected to the in-vehicle network 90. ​​The vehicle ID and the current version of the software of the electronic control units 50a to 50d are used to determine whether or not there is update data for the software of the electronic control units 50a to 50d by comparing them with the latest version of the software held by the center 10 for each vehicle ID. In addition, the communication unit 38 receives a notification indicating the presence or absence of update data from the center 10 as a response to the update check request (receiving unit). When there is update data for the software of the electronic control units 50a to 50d, the communication unit 38 transmits a download request for a distribution package including the software update data and the like to the center 10 (transmission unit), and receives (downloads) the distribution package transmitted from the center 10 (reception unit). In addition, the communication unit 38 transmits the update status of the software transmitted by the electronic control units 50a to 50d to the center 10 (transmission unit).

[0026] The control unit 39 determines whether or not there is update data for the software of the electronic control units 50a to 50d, based on a response from the center 10 to the update confirmation request received by the communication unit 38. The control unit 39 also verifies the authenticity of the distribution package that the communication unit 38 receives (downloads) from the center 10 and stores in the storage unit 37. The control unit 39 also uses the update data received (downloaded) from the center 10 to control the software update process (various verifications, installation, activation, etc.) of the electronic control units 50a to 50d. Specifically, the control unit 39 transfers one or more pieces of update data downloaded in the distribution package to the target electronic control unit, and causes the target electronic control unit to install update software based on the update data. After the installation is completed, the control unit 39 instructs the target electronic control unit to activate the installed update software.

[0027] The electronic control units 50a to 50d are devices (ECUs) for controlling the operation of each part of the vehicle. Although Fig. 1 shows an example in which the in-vehicle network 90 includes four electronic control units 50a to 50d, 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 master 30 is also not particularly limited. An example of a schematic configuration of the electronic control units 50a to 50d is shown in Figs. 6A and 6B.

[0028] The electronic control unit 50a shown in FIG. 6A includes a CPU 51, a RAM 52, a nonvolatile memory 53a, and a communication device 54. The CPU 51 executes a program read from the nonvolatile memory 53a using the RAM 52 as a working area, thereby realizing the function of the electronic control unit 50a. The nonvolatile memory 53a is a single bank memory having one storage area 55 for storing data such as software. In this embodiment, the memory type of the nonvolatile memory 53a, which is a single bank memory, may be described as a "first type" to distinguish it from other types. In addition to software for realizing the function of the electronic control unit 50a, the storage area 55 may store version information, parameter data, a boot program for startup, a program for software update, and the like. The communication device 54 is a device for communicating with the OTA master 30 and other electronic control units 50b to 50d connected to the in-vehicle network 90.

[0029] The electronic control unit 50b shown in FIG. 6B includes a CPU 51, a RAM 52, a nonvolatile memory 53b, and a communication device 54, similar to the electronic control unit 50a. However, the nonvolatile memory 53b mounted on the electronic control unit 50b is a dual bank memory having two storage areas 56a and 56b for storing data such as software. In this embodiment, the memory type of the nonvolatile memory 53b, which is a dual bank memory, may be described as a "second type" to distinguish it from others. In addition to software for realizing the functions of the electronic control unit 50b, the storage areas 56a and 56b may store version information, parameter data, a boot program for starting, a program for updating software, and the like. The CPU 51 of the electronic control unit 50b sets one of the two storage areas 56a and 56b of the nonvolatile memory 53b as a storage area (operational aspect) to be read, and executes the software stored in the storage area to be read. In the other storage area (non-operational side) that is not the read target, update software (updated program) based on the update data can be installed (written) in the background while the program in the read target storage area (operational side) is being executed. When activating (enabling update software) in the software update process, the update software can be activated by switching the storage area that is the read target of the program by the CPU 51 of the electronic control unit 50b.

[0030] As a specific example, assume that current software is stored in the storage area 56a of the nonvolatile memory 53b, which is a dual bank memory, and update software is installed in the storage area 56b. When activation of the update software is instructed from the OTA master 30, for example, the electronic control unit 50b can switch the read start address of the CPU 51 from the top address of the storage area 56a to the top address of the storage area 56b, thereby switching the storage area to be read by the CPU 51 (operation side) and executing the update software installed in the storage area 56b. Note that in this disclosure, a nonvolatile memory configuration called a "one-side suspend memory" in which one storage area is partitioned into two sides in a pseudo manner and a program can be written to the other side while a program stored in one side is being executed is also classified as the second type of memory.

[0031] Among the electronic control units 50a to 50d, there are a plurality of electronic control units that require cooperative operation to realize one function, such as automatic driving. The plurality of electronic control units that require cooperative operation may include both an electronic control unit equipped with a single bank memory and an electronic control unit equipped with a dual bank memory. For example, in a plurality of electronic control units X and Y that require cooperative operation to realize function A, if the version of software x written in electronic control unit X and the version of software y written in electronic control unit Y are not a predetermined combination (such as both being the latest version) after software update processing, a malfunction such as function A not being normally exhibited or function A being unable to be executed may occur. If the version of software x written in electronic control unit X and the version of software y written in electronic control unit Y are not a predetermined combination, measures such as re-executing the software update processing or returning each software x and y to the version before the software update processing (so-called rollback) are taken, but function A is restricted while this measure is being taken. Therefore, in the software update process of this embodiment described below, the update sequence is appropriately controlled based on the type of non-volatile memory of the electronic control unit (first type (single bank) / second type (dual bank)), making it possible to reduce the time during which functions requiring coordinated operation are restricted.

[0032] FIG. 7 shows an example of type information, which is information related to the type of nonvolatile memory mounted in each of the electronic control units 50a to 50d. In the type information shown in FIG. 7, an ECU_ID, which is a number for identifying an electronic control unit, is associated with the type of nonvolatile memory mounted in the electronic control unit (first type (single bank) / second type (dual bank)). This type information is stored and managed in one or both of the storage unit 37 of the OTA master 30 and the storage unit 16 of the center 10. The type information may be created in advance based on the specifications of the electronic control units 50a to 50d constituting the in-vehicle network 90 and stored in the storage unit 37 when the vehicle is manufactured, or may be acquired from the target electronic control unit through communication within the in-vehicle network 90 during software update processing. In addition, when the type information is managed by the center 10, the OTA master 30 may acquire the type information from the center 10 via the network 100.

[0033] The display device 70 is a human machine interface (HMI) used to perform various displays, such as displaying the presence of update data during software update processing of the electronic control units 50a to 50d, displaying a consent request screen for requesting consent to the software update from the vehicle user or administrator, and displaying the results of the software update. The display device 70 can typically be a display device of a car navigation system, but is not particularly limited as long as it can display information required during software update processing. In addition to the display device 70, an electronic control unit or the like may be further connected to the bus 60d shown in FIG. 1.

[0034] The communication module 80 is a unit having a function of controlling communication between the center 10 and the vehicle, and is a communication device for connecting the in-vehicle network 90 to the center 10. The communication module 80 is wirelessly connected to the center 10 via the network 100, and performs vehicle authentication by the OTA master 30, downloading update data, and the like. This communication module 80 may be configured as being included in the OTA master 30.

[0035] [Software update process overview] For example, the OTA master 30 transmits a software update check request to the center 10 when the power supply of the vehicle is turned on. The update check request includes a vehicle ID for identifying the vehicle and vehicle configuration information, which is information on the state (system configuration) of the electronic control units 50a to 50d connected to the in-vehicle network 90, such as the current versions of the hardware and software of the electronic control units 50a to 50d. The vehicle configuration information can be created by acquiring the identification numbers (ECU_ID) of the electronic control units and the identification numbers (ECU_Software_ID) of the software versions of the electronic control units from the electronic control units 50a to 50d connected to the in-vehicle network 90. ​​The vehicle ID and the current versions of the software of the electronic control units 50a to 50d are used to determine whether or not there is update data for the software of the electronic control units 50a to 50d by comparing them with the latest version of the software held by the center 10 for each vehicle ID. In addition, the OTA master 30 receives a notification indicating the presence or absence of update data from the center 10 as a response to the update check request. When there is update data for the software of the electronic control units 50a to 50d, the OTA master 30 transmits a download request for the distribution package to the center 10 and receives the distribution package transmitted from the center 10. In addition to the update data, the distribution package may include verification data for verifying the authenticity of the update data, the number of update data, type information, installation order, activation order, various control information used during software update, and the like.

[0036] The OTA master 30 determines whether or not there is update data for the software of the electronic control units 50a to 50d, based on the response to the update confirmation request received from the center 10. The OTA master 30 also verifies the authenticity of the distribution package received from the center 10 and stored in the storage device 13. The OTA master 30 also transfers one or more pieces of update data downloaded in the distribution package to the target electronic control unit, and causes the target electronic control unit to install the update data. After the installation is completed, the OTA master 30 instructs the target electronic control unit to activate the installed updated software to make it valid.

[0037] In addition, in the consent request process, the OTA master 30 causes the output device to output a notification that consent is required for the software update or a notification that prompts input that the software update has been consented to. As the output device, a display device 70 provided in the in-vehicle network 90, an audio output device (not shown) that gives a voice notification, or the like can be used. For example, in the consent request process, when the display device 70 is used as the output device, the OTA master 30 can cause the display device 70 to display a consent request screen for requesting consent to the software update from the user or administrator, or cause the display device 70 to display a notification that prompts a specific input operation such as pressing an consent button when the user or administrator consents. In addition, in the consent request process, the OTA master 30 can cause the display device 70 to display a message or an icon notifying that there is update data for the software of the electronic control units 50a to 50d, or cause the display device 70 to display restrictions during the execution of the software update process. When the OTA master 30 receives input indicating consent from the user or administrator, it executes the above-mentioned installation and activation control process and updates the software of the target electronic control unit.

[0038] Here, if the non-volatile memory of the target electronic control unit is a single bank memory, in principle, installation and activation are performed consecutively, so consent request processing for the software update is performed before installation is performed. Also, if the non-volatile memory of the target electronic control unit is a dual bank memory, consent request processing for the software update is performed at least after installation is performed and before activation is performed. Note that, if the non-volatile memory of the target electronic control unit is a dual bank memory, consent request processing for the software update before installation may be performed or may be omitted.

[0039] The software update process consists of a phase in which the OTA master 30 downloads update data from the center 10 (download phase), a phase in which the OTA master 30 transfers the downloaded update data to the target electronic control unit and installs update software based on the update data in the storage area of ​​the target electronic control unit (installation phase), and a phase in which the target electronic control unit activates the installed update software (activation phase).

[0040] Downloading is a process in which the OTA master 30 receives update data for updating the software of the electronic control unit, which is transmitted from the center 10 in a distribution package, and stores the data in the storage unit 37. Regarding reception of update data by downloading, it is possible to preferentially receive update data intended for an electronic control unit equipped with a second type of nonvolatile memory (dual bank memory) which has a relatively low probability of update failure, or to receive update data intended for an electronic control unit equipped with a first type of nonvolatile memory (single bank memory) and update data intended for an electronic control unit equipped with a second type of nonvolatile memory (dual bank memory) equally. The download phase includes not only execution of the download, but also control of a series of processes related to the download, such as determining whether the download can be executed and verifying the update data.

[0041] The update data transmitted from the center 10 to the OTA master 30 may include update software for the electronic control unit (all data or difference data), compressed data obtained by compressing the update software, or divided data obtained by dividing the update software or the compressed data. The update data may also include the ECU_ID (or serial number) of the target electronic control unit and the ECU_Software_ID of the target electronic control unit before the update. The update data is downloaded as the above-mentioned distribution package, and the distribution package includes update data for a single electronic control unit or multiple electronic control units.

[0042] The installation is a process in which the OTA master 30 writes update software (updated programs) in a predetermined order to the non-volatile memories 53a and / or 53b of multiple target electronic control units based on the update data downloaded from the center 10. The installation phase not only executes the installation, but also includes control of a series of processes related to the installation, such as judging whether the installation can be executed, transferring the update data, and verifying the update software.

[0043] If the update data includes the update software itself (all data), the OTA master 30 transfers the update data (update software) to the target electronic control unit in the installation phase. If the update data includes compressed data, difference data, or divided data of the update software, the OTA master 30 may transfer the update data to the target electronic control unit and the target electronic control unit may generate the update software from the update data, or the OTA master 30 may generate the update software from the update data and then transfer the update software to the target electronic control unit. Here, the update software can be generated by decompressing the compressed data or assembling (integrating) the difference data or divided data.

[0044] The target electronic control unit can install the update software based on an installation request from the OTA master 30. Note that for a specific target electronic control unit that has received the update data, the installation may be performed autonomously without receiving an explicit instruction from the OTA master 30.

[0045] Activation is a process in which the target electronic control unit activates the update 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 or not activation can be executed, requesting the vehicle user or administrator to consent to the activation, and verifying the execution result.

[0046] The activation of the update software can be performed by the target electronic control unit based on an activation request from the OTA master 30. Note that, for a specific target electronic control unit that has received the update data, the activation may be performed autonomously after the installation is completed, without receiving an explicit instruction from the OTA master 30.

[0047] The software update process can be performed consecutively or in parallel for each of the multiple target electronic control units.

[0048] Furthermore, in this specification, the "software update process" includes not only a process in which download, installation, and activation are all performed consecutively, but also a process in which only some of the download, installation, and activation are performed.

[0049] [process] Next, some specific examples of the software update process executed in the network system according to this embodiment will be described with further reference to FIGS. 8, 9, 10, and 11. FIG.

[0050] (1) Specific examples of downloads 8 is a flowchart illustrating a process of a specific example of downloading performed by the center 10 and the OTA master 30. The downloading illustrated in FIG. 8 is started when the center 10 receives a download request for a distribution package from the OTA master 30.

[0051] (Step S801) The center 10 generates a distribution package including update data for a target electronic control unit (hereinafter referred to as "target ECU") that is the target of software update. The update data for the target ECU is provided in advance by an OEM or the like. As the distribution package, a package in which update data for a target ECU equipped with a single bank memory and update data for a target ECU equipped with a dual bank memory are mixed may be generated, or a package containing only update data for a target ECU equipped with a single bank memory and a package containing only update data for a target ECU equipped with a dual bank memory may be generated. If the center 10 manages the types of non-volatile memories installed in each of the multiple electronic control units 50a to 50d, information on the memory type may be included in the distribution package. When the distribution package is generated, the process proceeds to step S802.

[0052] (Step S802) The center 10 transmits the generated distribution package to the OTA master 30. Once the distribution package has been transmitted, the process proceeds to step S803.

[0053] (Step S803) The OTA master 30 stores the update data (and information on the memory type) and the like contained in the distribution package received from the center 10 in the storage unit 37. This completes the download process.

[0054] (2) Installation Example 1 9 is a flowchart for explaining the procedure of installation processing according to concrete example 1 performed by the OTA master 30 and the target ECU. This concrete example 1 of installation is an example in which installation of update software is started in a target ECU (hereinafter referred to as a "first type target ECU") equipped with a first type of nonvolatile memory (single bank memory) that requires stop control during update at the timing when installation of update software is completed in a target ECU (hereinafter referred to as a "second type target ECU") equipped with a second type of nonvolatile memory (dual bank memory) that does not require stop control during update.

[0055] The installation process of the concrete example 1 illustrated in FIG. 9 is started after the download of the update data for the target ECU is completed and when predetermined conditions (installation can be executed, verification of the update data is OK, etc.) are satisfied.

[0056] (Step S901) The OTA master 30 acquires the type (first type / second type) of the non-volatile memory mounted in the target ECU. If the memory type is managed by the OTA master 30, it can be acquired by referring to the type information (FIG. 7) stored in the storage unit 37, and if the memory type is managed by the center 10, it can be acquired by referring to the memory type information included in the distribution package and transmitted. When the memory type of the target ECU is acquired, the process proceeds to step S902.

[0057] (Step S902) The OTA master 30 and the second type target ECU start installation, which is a process of writing update software to the storage area of ​​the non-volatile memory of the second type target ECU based on the update data. This installation is started for all the second type target ECUs at once or in a predetermined order. When the installation for the second type target ECUs starts, the process proceeds to step S903.

[0058] (Step S903) The OTA master 30 judges whether the installation of the update software in the second type target ECUs is completed. The completion of the installation may be judged for all the second type target ECUs, or may be judged for only a predetermined part of the second type target ECUs. The OTA master 30 may judge the completion of the installation when a completion notification is received from the second type target ECUs, or when a predetermined time has elapsed since the start of the installation. The predetermined time can be set to, for example, a maximum time required for each installation or more. When it is judged that the installation of the update software in the second type target ECUs is completed (step S903, Yes), the process proceeds to step S904.

[0059] (Step S904) The OTA master 30 and the first type target ECU start installation, which is a process of writing update software to a storage area of ​​a non-volatile memory of the first type target ECU based on the update data. This installation is started for all the first type target ECUs at once or in a predetermined order. When installation for the first type target ECUs is started, the process proceeds to step S905.

[0060] (Step S905) The OTA master 30 judges whether the installation of the update software in the first type target ECUs is completed. The completion of the installation is judged for all the first type target ECUs. The OTA master 30 may judge the completion of the installation when a completion notification is received from the first type target ECU, or when a predetermined time has elapsed since the start of the installation. The predetermined time can be set to, for example, a maximum time required for each installation. When it is judged that the installation of the update software in the first type target ECUs is completed (step S905, Yes), the installation for all the target ECUs is completed, and this installation process ends.

[0061] In the above specific example 1 of installation, installation for the second type target ECU is started first, and installation for the first type target ECU is started when it is determined that installation for the second type target ECU is completed. This process allows installation for the second type target ECU that does not require stop control during update to be performed before installation for the first type target ECU that requires stop control during update. This reduces the communication load within the vehicle (in-vehicle network 90) and shortens the time that vehicle control must be stopped until writing of all update software is completed.

[0062] (3) Installation Example 2 10 is a flowchart explaining the procedure of installation processing according to concrete example 2 performed by the OTA master 30 and the target ECU. This concrete example 2 of installation is an example in which installation of update software in a first type target ECU that requires stop control during update is started at the timing when installation of update software in a second type target ECU that does not require stop control during update has progressed to a predetermined point.

[0063] The installation process of the specific example 2 illustrated in FIG. 10 is started after the download of the update data for the target ECU is completed and when predetermined conditions (installation can be executed, verification of the update data is OK, etc.) are satisfied.

[0064] (Step S1001) The OTA master 30 acquires the type (first type / second type) of the non-volatile memory mounted in the target ECU. If the memory type is managed by the OTA master 30, it can be acquired by referring to the type information (FIG. 7) stored in the storage unit 37, and if the memory type is managed by the center 10, it can be acquired by referring to the memory type information included in the distribution package and transmitted. When the memory type of the target ECU is acquired, the process proceeds to step S1002.

[0065] (Step S1002) The OTA master 30 and the second type target ECU start installation, which is a process of writing update software to the storage area of ​​the non-volatile memory of the second type target ECU based on the update data. This installation is started for all the second type target ECUs at once or in a predetermined order. When installation for the second type target ECUs starts, the process proceeds to step S1003.

[0066] (Step S1003) The OTA master 30 judges whether the installation of the update software in the second type target ECU has progressed to a predetermined point (or beyond the predetermined point). This predetermined point can be set to any position (processing stage) between the start of the installation and the completion of the installation, and can be set in various ways, such as the timing when the writing process has progressed to a point where the probability of the installation being successful is high, or the timing when the writing process has progressed to a point where the installation can be recovered without the need for reinstallation even if the installation fails. Whether the installation has progressed to the predetermined point may be judged for all the second type target ECUs, or may be judged only for a predetermined part of the second type target ECUs. When it is judged that the installation of the update software in the second type target ECU has progressed to the predetermined point (step S1003, Yes), the process proceeds to step S1004.

[0067] (Step S1004) The OTA master 30 and the first type target ECU start installation, which is a process of writing update software to a storage area of ​​a non-volatile memory of the first type target ECU based on the update data. This installation is started for all the first type target ECUs at once or in a predetermined order. When installation for the first type target ECUs starts, the process proceeds to step S1005.

[0068] (Step S1005) The OTA master 30 judges whether or not the installation of the update software in the first type target ECU and the installation of the update software in the second type target ECU are both completed. The completion of the installation is judged for all the first type target ECUs and all the second type target ECUs. The OTA master 30 may judge the completion of the installation when a completion notification is received from each of the first type target ECUs and the second type target ECUs, or when a predetermined time has elapsed since the start of the installation. The predetermined time can be set to, for example, a maximum time required for each installation. When it is judged that the installation of the update software in both the first type target ECUs and the second type target ECUs is completed (step S1005, Yes), the installation for all the target ECUs is completed, and the installation process ends.

[0069] In the above-mentioned specific example 2 of installation, installation for the second type target ECU is started first, and installation for the first type target ECU is started at the timing when it is determined that the installation for the second type target ECU has progressed to a predetermined point. This process allows installation for the second type target ECU that does not require stop control during update to be performed before installation for the first type target ECU that requires stop control during update. This reduces the communication load within the vehicle (in-vehicle network 90), and the time during which control of the vehicle must be stopped until writing of all update software is completed can be further shortened compared to the specific example 1 of installation.

[0070] In the above-described specific example 1 and specific example 2, the OTA master 30 has been described as controlling the order of installation and activation of the update software in the first type target ECU and the second type target ECU by its own judgment based on the control program stored in the storage unit 37. However, the OTA master 30 may control the order of installation and activation of the update software in the first type target ECU and the second type target ECU by receiving a predetermined instruction from the center 10 (obtaining information related to the update sequence, etc.).

[0071] (4) Specific examples of activation 11 is a flowchart illustrating a process procedure according to a specific example of activation performed by the OTA master 30 and the target ECU. This specific example of activation is an example in which update software is activated in a first type target ECU that requires stop control during update, and then update software is activated in a second type target ECU that does not require stop control during update.

[0072] The activation process illustrated in FIG. 11 is initiated after the installation of update software for each of the first type target ECU and the second type target ECU is completed and certain conditions (activation can be performed, update data verification is OK, etc.) are satisfied.

[0073] (Step S1101) The OTA master 30 and the first type target ECU start activation to validate the update software written in the storage area of ​​the non-volatile memory of the first type target ECU. This activation is started for all the first type target ECUs at once or in a predetermined order. When the activation of the update software in the first type target ECU starts, the process proceeds to step S1102.

[0074] (Step S1102) The OTA master 30 judges whether activation of the update software in the first type target ECUs is completed. Completion of activation is judged for all first type target ECUs. The OTA master 30 may judge completion of activation when a completion notification is received from the first type target ECU, or when a predetermined time has elapsed since the start of activation. The predetermined time can be set to, for example, a time equal to or longer than the maximum time required for each activation. When it is judged that activation of the update software in the first type target ECUs is completed (Yes in step S1102), the process proceeds to step S1103.

[0075] (Step S1103) The OTA master 30 and the second type target ECUs start activation to validate the update software written in the storage area of ​​the non-volatile memory of the second type target ECUs. This activation is started for all the second type target ECUs at once or in a predetermined order. When activation of the update software in the second type target ECUs starts, the process proceeds to step S1104.

[0076] (Step S1104) The OTA master 30 judges whether activation of the update software in the second type target ECU is completed. Completion of activation is judged for all second type target ECUs. The OTA master 30 may judge completion of activation when a completion notification is received from the second type target ECU, or when a predetermined time has elapsed since the start of activation. The predetermined time can be set to, for example, a maximum time required for each activation. When it is judged that activation of the update software in the second type target ECU is completed (step S1104, Yes), activation for all target electronic control units is completed, and this activation process ends.

[0077] In the above specific example of activation, activation of the update software of the first type target ECU is started first, and after it is determined that activation of the update software in the first type target ECU is completed, activation of the update software of the second type target ECU is started. This process makes it possible to preferably execute software update processing of a system including both the first type target ECU equipped with a single bank memory and the second type target ECU equipped with a dual bank memory.

[0078] <Actions and Effects> As described above, according to the network system according to one embodiment of the present disclosure, the OTA master starts writing update data for an electronic control unit equipped with a dual bank memory at a predetermined timing after starting writing update data for an electronic control unit equipped with a dual bank memory (first type target ECU) out of update data received from the center for an electronic control unit equipped with a single bank memory and update data for an electronic control unit equipped with a dual bank memory (second type target ECU).

[0079] This process allows the electronic control unit equipped with a single bank memory to start installing the new version of the software after confirming that the electronic control unit equipped with a dual bank memory has completed installation of the new version of the software (100% complete). Alternatively, the electronic control unit equipped with a single bank memory can start installing the new version of the software after confirming that the electronic control unit equipped with a dual bank memory has progressed to a point where the probability of successful installation is high (e.g., 50% complete) or that the electronic control unit equipped with a dual bank memory has progressed to a point where recovery is possible without the need for reinstallation even if the installation fails (e.g., 70% complete).

[0080] Therefore, even if the installation of the software on the electronic control unit equipped with the dual bank memory fails, the software installation has not yet started on the electronic control unit equipped with the single bank memory, so that the combination of the old versions that are consistent between the software on the electronic control unit equipped with the dual bank memory and the software on the electronic control unit equipped with the single bank memory can be maintained. Therefore, in a case where cooperative operation between the electronic control unit equipped with the single bank memory and the electronic control unit equipped with the dual bank memory is required to realize a function, such as an autonomous driving function, even if the installation of the software on the electronic control unit equipped with the dual bank memory fails, the time during which the autonomous driving function is restricted can be shortened compared to a conventional update process that does not consider the software update procedure (sequence order) between the electronic control unit equipped with the dual bank memory and the electronic control unit equipped with the single bank memory.

[0081] Although one embodiment of the disclosed technology has been described above, the present disclosure can be understood as not only an OTA master, but also an update method executed by an OTA master having a processor and a memory, an update program, a computer-readable non-transitory storage medium storing the update program, a center capable of communicating with the OTA master, a system including a center and an OTA master, or a vehicle including an OTA master. [Industrial Applicability]

[0082] The disclosed technique can be used in a network system for updating software in an electronic control unit. [Explanation of symbols]

[0083] 10 Center 11, 31, 51 CPUs 12, 32, 52 RAM 13, 34 Storage device 14, 36, 54 Communication equipment 16, 37 Memory section 17, 38 Communications Department 18, 39 Control section 30 OTA Master 33 ROM 35 Microcomputer 50a~50d Electronic Control Unit (ECU) 53a, 53b Non-volatile memory 55, 56a, 56b Storage area 60a~60d Bus 70 Display device 80 Communication Module 90 In-vehicle network 100 Network

Claims

1. a receiving unit that receives first update data intended for a first in-vehicle device equipped with a first type of non-volatile memory having one storage area, and second update data intended for a second in-vehicle device equipped with a second type of non-volatile memory having two storage areas; A control unit, The control unit is a first control for writing the second update data to the second in-vehicle device after the first update data and the second update data have been received, and for enabling the second update data at a predetermined timing; and a second control of writing the first update data to the first in-vehicle device and validating the first update data at a timing different from the specified timing after completion of reception of the first update data and the second update data.

2. 2. The control device according to claim 1, wherein the control unit writes the second update data to the second in-vehicle device, then writes the first update data to the first in-vehicle device and activates the first update data, and then activates the second update data written to the second in-vehicle device.

3. The control device according to claim 1 , wherein the receiving unit receives the first update data and the second update data from a center.

4. 4. The control device according to claim 3, wherein the predetermined timing is instructed by the center.

5. The control device according to claim 3 , wherein the receiving unit receives information about the memories of the first in-vehicle device and the second in-vehicle device from the center.

6. The control device according to claim 5 , further comprising a storage unit that stores information regarding the memory.

7. A vehicle comprising the control device according to claim 1 , the first in-vehicle device, and the second in-vehicle device.

8. A method for updating software of an in-vehicle device, comprising: receiving first update data intended for a first in-vehicle device equipped with a first type of non-volatile memory having one storage area, and receiving second update data intended for a second in-vehicle device equipped with a second type of non-volatile memory having two storage areas; writing the second update data to the second in-vehicle device after completion of reception of the first update data and the second update data, and enabling the second update data at a predetermined timing; and after completion of reception of the first update data and the second update data, writing the first update data to the first in-vehicle device and enabling the first update data at a timing different from the specified timing.

9. A program for causing a computer to execute the method according to claim 8.

Images