OTA master, center, system, method, program, and vehicle
The OTA master system addresses the challenge of increased communication load by managing separate updates for single and dual bank memory units, optimizing software updates through efficient retransmission and prioritization, thereby reducing overall update time and load.
Patent Information
- Application Number
- JP2021095070
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2021-06-07
- Publication Date
- 2024-12-10
- Estimated Expiration
- 2041-06-07
AI Technical Summary
Existing software update systems face increased communication requirements due to the need to retransmit data when abnormalities occur during transmission, particularly when updating electronic control units with single and dual bank memories.
An OTA master system that manages software updates by generating separate distribution packages for electronic control units with single and dual bank memories, allowing for efficient retransmission of data and reducing communication load by prioritizing updates for dual bank memory units.
The system effectively reduces communication load and minimizes the time required to complete software updates by prioritizing updates for dual bank memory units, ensuring seamless software updates even in the presence of communication abnormalities.
Smart Images

Figure 0007596943000001 
Figure 0007596943000002 
Figure 0007596943000003
Abstract
Description
[Technical field]
[0001] The present disclosure relates to an OTA master that controls software updates for electronic control units. [Background technology]
[0002] A vehicle is equipped with multiple electronic control units 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. The processor executes software stored in the non-volatile memory to realize the control function of the electronic control unit. The software stored in each electronic control unit is rewritable, and by updating the software to a newer version, the function of each electronic control unit can be improved or a new vehicle control function can be added.
[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 the 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 (single bank memory), and memory with two storage areas for storing software and other data (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] In a campaign, which is an event for updating software for vehicles, both an electronic control unit equipped with a single bank memory and an electronic control unit equipped with a dual bank memory may be electronic control units for which software is to be updated. In this case, if a server transmits update data for an electronic control unit equipped with a dual bank memory and update data for an electronic control unit equipped with a single bank memory together in a single package to a device that handles the vehicle software update process, there is a problem that a large amount of communication traffic is required to resend the data when an abnormality occurs in the transmission.
[0007] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide an OTA master and the like that can perform software updates suitable for single bank memories and dual bank memories. [Means for solving the problem]
[0008] In order to solve the above problems, one aspect of the disclosed technology is an OTA master that controls software updates of an electronic control unit installed in a vehicle, and includes a communication unit that receives an update data distribution package intended for an electronic control unit equipped with a second type of non-volatile memory having two storage areas from a center prior to receiving an update data distribution package intended for an electronic control unit equipped with a first type of non-volatile memory having one storage area. Effect of the Invention
[0009] According to the OTA master disclosed herein, if an abnormality occurs in the communication of a distribution package, only that distribution package needs to be resent, making it possible to perform software updates suitable for single bank memories and dual bank memories. [Brief description of the drawings]
[0010] [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] Example of a flow chart of the download process performed by the center and OTA master [Figure 9] Example of a flowchart for the installation process performed by the OTA master and the target electronic control unit [Figure 10] Example of a flowchart of the activation process performed by the OTA master and the target electronic control unit DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] In the network system disclosed herein, the OTA master receives a distribution package of update data for an electronic control unit equipped with a dual bank memory from the center before receiving a distribution package of update data for an electronic control unit equipped with a single bank memory. This makes it possible to suppress an increase in the amount of communication (communication load) between the center and the OTA master by resending only that distribution package when a communication error occurs in the distribution package. Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the drawings.
[0012] <Embodiment> [composition] 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 40a to 40d mounted on a vehicle, and includes a center 10 located outside the vehicle and an in-vehicle network 20 built inside the vehicle.
[0013] (1) Center The center 10 is capable of communicating with an OTA master 30 (described later) provided in the in-vehicle network 20 via the network 70. The center 10 can control and manage software updates of the multiple electronic control units 40a-40d connected to the OTA master 30 by transmitting update data for the software of the electronic control units 40a-40d and receiving notifications indicating the progress of the software update process between the center 10 and the OTA master 30. The center 10 functions as a so-called server.
[0014] 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 executing a predetermined process related to software update. The communication device 14 is a device for communicating with the OTA master 30 via a network 70.
[0015] 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.
[0016] The storage unit 16 stores information related to software update processing of one or more electronic control units mounted on the vehicle. As 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 40a to 40d is associated with each vehicle identification information (vehicle ID) that identifies the vehicle, and update data of the software of the electronic control units 40a to 40d. As information indicating software available in the electronic control units 40a to 40d, for example, a combination of the latest version information of each software of the multiple electronic control units 40a to 40d is defined. Furthermore, as information related to the software update processing, the storage unit 16 can store update status indicating the update state of the software being performed in the vehicle. Furthermore, the storage unit 16 can store information (described later) related to the type of non-volatile memory mounted in each of the multiple electronic control units 40a to 40d.
[0017] 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 40a to 40d 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 of update data for the software of the electronic control units 40a to 40d, which is generated by the control unit 18, which will be described later.
[0018] 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 40a-40d 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 determination result by the control unit 18 as to whether or not there is update data is transmitted 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 40a-40d, upon receiving a download request for a distribution package from the OTA master 30, it generates a distribution package for the corresponding update data stored in the storage unit 16.
[0019] The control unit 18 generates a distribution package of only update data for an electronic control unit equipped with a single bank memory, which will be described later, and a distribution package of only update data for an electronic control unit equipped with a dual bank memory, which will be described later. If type information, which will be described later, is stored in advance in the storage unit 16, the control unit 18 can intentionally generate distribution packages of different types of update data individually. By separately generating distribution packages of update data based on such types, it is possible to transmit the distribution package of update data for an electronic control unit equipped with a second type of nonvolatile memory from the center 10 (communication unit 17 thereof) to the OTA master 30 before the distribution package of update data for an electronic control unit equipped with a first type of nonvolatile memory.
[0020] (2) In-vehicle network The in-vehicle network 20 includes an OTA master 30, a plurality of electronic control units 40a to 40d, and a communication module 50. The OTA master 30 and the communication module 50 are connected via a bus 60a. The OTA master 30 and the electronic control units 40a and 40b are connected via a bus 60b. The OTA master 30 and the electronic control units 40c and 40d are connected via a bus 60c.
[0021] The OTA master 30 can wirelessly communicate with the center 10 via the bus 60a and the communication module 50 and the network 70. 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 a 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 updates of the target electronic control units among the electronic control units 40a to 40d based on update data acquired from the center 10, etc. The OTA master 30 is sometimes referred to as a central gateway (CGW).
[0022] Fig. 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 50 and each of the electronic control units 40a to 40d via the buses 60a to 60c 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 40a to 40d (a control program for the OTA master 30), various data used when executing software updates, and software update data downloaded from the center 10. The storage unit 37 can also store information (described later) related to the type of non-volatile memory mounted in each of the multiple electronic control units 40a to 40d.
[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 40a to 40d connected to the in-vehicle network 20. The vehicle ID and the current version of the software of the electronic control units 40a to 40d are used to determine whether or not there is update data for the software of the electronic control units 40a to 40d 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 40a to 40d, the communication unit 38 transmits a download request for a distribution package of the software update data 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 40a to 40d to the center 10 (transmission unit).
[0026] The control unit 39 judges whether or not there is update data for the software of the electronic control units 40a to 40d 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 40a to 40d. 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. During this software update process, the control unit 39 appropriately controls procedures such as various verifications, installation, and activation in the multiple electronic control units 40a to 40d.
[0027] The electronic control units 40a to 40d are devices (ECUs: Electronic Control Units) for controlling the operation of each part of the vehicle. In FIG. 1, an example is shown in which the in-vehicle network 20 includes four electronic control units 40a to 40d, but the number of electronic control units is not particularly limited. For example, a display device (HMI) for performing various displays, such as a display that there is update data during software update processing of the electronic control units 40a to 40d, a display of a consent request screen for requesting consent to the software update from the vehicle user or administrator, and a display of the result of the software update, may be connected to the OTA master 30. A car navigation system or the like can be used as the display device. In addition, the number of buses connecting the electronic control units to the OTA master 30 is not particularly limited. For example, the above-mentioned display device may be connected to the OTA master 30 by a bus other than the buses 60a to 60c.
[0028] An example of a schematic configuration of the electronic control units 40a to 40d is shown in FIGS. 6A and 6B.
[0029] The electronic control unit 40a shown in FIG. 6A includes a CPU 41, a RAM 42, a non-volatile memory 43a, and a communication device 44. The CPU 41 executes a program read from the non-volatile memory 43a by using the RAM 42 as a working area, thereby realizing the function of the electronic control unit 40a. The non-volatile memory 43a is a memory having one storage area 45 for storing data such as software (hereinafter referred to as a "single bank memory"). Hereinafter, the memory type of the non-volatile memory 43a having the one storage area 45 is referred to as a "first type". In addition to software for realizing the function of the electronic control unit 40a, the storage area 45 may store version information, parameter data, a boot program for starting, a program for updating software, and the like. The communication device 44 is a device for communicating with the OTA master 30 and other electronic control units 40b to 40d connected to the in-vehicle network 20.
[0030] The electronic control unit 40b shown in FIG. 6B includes a CPU 41, a RAM 42, a non-volatile memory 43b, and a communication device 44, similar to the electronic control unit 40a. However, the non-volatile memory 43b mounted on the electronic control unit 40b is a memory having two storage areas 46a and 46b for storing data such as software (hereinafter referred to as a "dual bank memory"). Hereinafter, the type of the non-volatile memory 43b having the two storage areas 46a and 46b is referred to as a "second type". In addition to software for realizing the functions of the electronic control unit 40b, the storage areas 46a and 46b may store version information, parameter data, a boot program for starting, a program for updating software, and the like. The CPU 41 of the electronic control unit 40b sets one of the two storage areas 46a and 46b of the non-volatile memory 43b 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 41 of the electronic control unit 40b.
[0031] As a specific example, assume that current software is stored in the storage area 46a of the non-volatile memory 43b, which is a dual bank memory, and update software is installed in the storage area 46b. When activation of the update software is instructed from the OTA master 30, for example, the electronic control unit 40b can switch the read start address of the CPU 41 from the top address of the storage area 46a to the top address of the storage area 46b, thereby switching the storage area to be read by the CPU 41 (operation side) and executing the update software installed in the storage area 46b. Note that in this disclosure, a 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.
[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 40a to 40d. 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 40a to 40d constituting the in-vehicle network 20 and stored in the storage unit 37 of the OTA master 30 when the vehicle is manufactured, or may be acquired by the OTA master 30 from the target electronic control unit through communication within the in-vehicle network 20 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 70.
[0033] The communication module 50 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 20 to the center 10. The communication module 50 is wirelessly connected to the center 10 via the network 70, and performs vehicle authentication by the OTA master 30, downloading update data, etc. This communication module 50 may be configured as being included in the OTA master 30.
[0034] [Software update process overview] The OTA master 30 transmits a software update check request to the center 10, for example, 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 40a to 40d connected to the in-vehicle network 20, such as the current versions of the hardware and software of the electronic control units 40a to 40d. 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 40a to 40d connected to the in-vehicle network 20. The vehicle ID and the current versions of the software of the electronic control units 40a to 40d are used to determine whether or not there is update data for the software of the electronic control units 40a to 40d by comparing them with the latest version of the software held by the center 10 for each vehicle ID. The center 10 transmits a notification indicating the presence or absence of update data to the OTA master 30 as a response to the update check request received from the OTA master 30. When there is update data for the software of the electronic control units 40a to 40d, the OTA master 30 transmits a download request for a distribution package to the center 10. In response to the download request received from the OTA master 30, the center 10 transmits a distribution package of the update data to the OTA master 30. In addition to the update data, the distribution package may include verification data for verifying the authenticity of the update data, the number and type information of the update data, various control information used when updating the software, and the like.
[0035] The OTA master 30 determines whether or not there is update data for the software of the electronic control units 40a to 40d, 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.
[0036] 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 (not shown) that provides a notification by display and an audio output device (not shown) that provides a notification by audio, which are provided in the in-vehicle network 20, can be used. For example, when a display device is used as the output device in the consent request process, the OTA master 30 can cause the display device to display a consent request screen for requesting consent to the software update from the user or administrator, or cause the display device to display a notification that prompts a specific input operation such as pressing an consent button if the user or administrator consents. In addition, in the consent request process, the OTA master 30 can cause the display device to display a statement or an icon notifying that there is update data for the software of the electronic control units 40a to 40d, or cause the display device 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.
[0037] 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. Note that even in the case of a target electronic control unit with a single bank memory, it may be requested to temporarily stop the update processing when installation is complete, that is, to wait (put on hold) activation. 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.
[0038] 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).
[0039] 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. In downloading, update data intended for an electronic control unit equipped with a dual bank memory, which has a relatively low probability of update failure, is received before update data intended for an electronic control unit equipped with a single bank memory. 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 performed and verifying the update data.
[0040] 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.
[0041] Installation is a process in which the OTA master 30 writes update software (updated programs) in a predetermined order to the non-volatile memories 43a and / or 43b of multiple target electronic control units based on update data downloaded from the center 10. Installation is performed with priority given to update data intended for electronic control units equipped with dual bank memory over update data intended for electronic control units equipped with single bank memory. 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 or not the installation can be executed, transferring the update data, and verifying the update software.
[0042] 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.
[0043] 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.
[0044] Activation is a process in which the target electronic control unit activates the update software installed in the non-volatile memory 43a and / or 43b. Activation may be performed with priority given to either the update data intended for the electronic control unit equipped with a dual bank memory or the update data intended for the electronic control unit equipped with a single bank memory, or may be performed without regard to priority to either. 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 performed, requesting consent to activation from the vehicle user or administrator, and verifying the execution results.
[0045] 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.
[0046] The software update process can be performed consecutively or in parallel for each of the multiple target electronic control units.
[0047] 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.
[0048] [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, and 10. FIG.
[0049] (1) Specific examples of downloads 8 is a flowchart illustrating a process procedure according to a specific example of downloading performed by the center 10 and the OTA master 30. The download process illustrated in FIG. 8 is started when the center 10 receives a download request for a distribution package from the OTA master 30.
[0050] (Step S801) The center 10 generates a distribution package of update data for a first type of target ECU among target electronic control units (hereinafter referred to as "target ECUs") that are the subject of software update. The center 10 also generates a distribution package of update data for a second type of target ECU among target ECUs that are the subject of software update. At this time, the center 10 can determine the memory type of the non-volatile memory mounted in the target ECU by referring to the type information stored in the storage unit 16. If the center 10 manages the types of non-volatile memories mounted in each of the multiple electronic control units 40a to 40d, information on the memory type may be included in the distribution package. Once the distribution packages of update data for the first and second types of target ECUs have been generated, the process proceeds to step S802.
[0051] (Step S802) The center 10 transmits a distribution package of update data intended for the second type target ECU to the OTA master 30. Once the distribution package has been transmitted, the process proceeds to step S803.
[0052] (Step S803) The OTA master 30 receives the distribution package of update data intended for the second type of target ECU transmitted from the center 10. When reception of this distribution package is completed, the process proceeds to step S804.
[0053] (Step S804) The center 10 transmits a distribution package of update data intended for the first type of target ECU to the OTA master 30. Once the distribution package has been transmitted, the process proceeds to step S805.
[0054] (Step S805) The OTA master 30 receives the distribution package of update data intended for the first type of target ECU transmitted from the center 10. When reception of this distribution package is completed, the process proceeds to step S806.
[0055] (Step S806) The OTA master 30 stores the update data (and information on the memory type, etc.) received in the distribution package from the center 10 in the storage unit 37. This completes the download process.
[0056] According to this specific example of downloading, the OTA master 30 can receive the distribution package of update data intended for the second type target ECU before the distribution package of update data intended for the first type target ECU.
[0057] (2) Installation example Fig. 9 is a flowchart for explaining the procedure of an installation process according to a specific example performed by the OTA master 30 and a target ECU. The installation process shown in Fig. 9 is started after downloading of update data for at least one second-type target ECU is completed and when predetermined conditions (installation can be executed, verification of update data is OK, etc.) are satisfied.
[0058] (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.
[0059] (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.
[0060] (Step S903) 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 of the first type target ECUs at the same time or in a predetermined order. Note that the installation for the first type target ECUs may be started after the installation for all of the second type target ECUs is completed, or after the installation for a predetermined part of the second type target ECUs is completed. When the installation for the first type target ECU is started, the process proceeds to step S904.
[0061] (Step S904) The OTA master 30 judges whether installation of the update software in all (first and second type) target ECUs is complete. The OTA master 30 may judge completion of installation when a completion notification is received from each target ECU, or when a predetermined time has elapsed since the start of installation. The predetermined time can be set to, for example, equal to or greater than the maximum time required for each installation. When it is judged that installation of the update software in all target ECUs is complete (step S904, Yes), installation in the target ECUs is complete, and this installation process ends.
[0062] According to the specific example of the installation, the installation for the second type target ECU that does not require stop control during the update can be started with priority over the installation for the first type target ECU that requires stop control during the update. This process can reduce the communication load within the vehicle (in-vehicle network 20) and shorten the time that the control of the vehicle must be stopped until writing of all the update software is completed.
[0063] (3) Specific examples of activation Fig. 10 is a flowchart for explaining a processing procedure according to a specific example of activation performed by the OTA master 30 and the target ECU. The activation processing illustrated in Fig. 10 is started after the installation of update software for each of the first type target ECU and the second type target ECU is completed and when predetermined conditions (activation can be executed, verification of update data is OK, etc.) are satisfied.
[0064] (Step S1001) 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 activation of the update software in the first type target ECU starts, the process proceeds to step S1002.
[0065] (Step S1002) The OTA master 30 and the second type target ECU start activation to validate the update software written in the storage area of the non-volatile memory of the second type target ECU. This activation is started for all the second type target ECUs at once or in a predetermined order. The activation of the second type target ECUs may be started after the activation of all the first type target ECUs is completed, or may be started after the activation of a predetermined part of the first type target ECUs is completed. When the activation of the update software in the second type target ECU is started, the process proceeds to step S1003.
[0066] (Step S1003) The OTA master 30 judges whether activation of the update software in all target ECUs (first and second types) is completed. The OTA master 30 may judge the completion of activation when a completion notification is received from each target ECU, or when a predetermined time has elapsed since the start of activation. The predetermined time can be set to, for example, equal to or greater than the maximum time required for each activation. When it is judged that activation of the update software in all target ECUs is completed (step S1003, Yes), activation for the target ECUs is completed, and this activation process ends.
[0067] According to the above specific example of activation, activation of update software for a first type target ECU is started first, and then activation of update software for a second type target ECU is started. This process makes it possible to perform software update for a second type target ECU after confirming success of software update for the first type target ECU, and therefore makes it possible to suitably execute software update processing for a system including both a target ECU equipped with a single bank memory and a target ECU equipped with a dual bank memory.
[0068] <Actions and Effects> As described above, according to the network system according to an embodiment of the present disclosure, the center generates update data for an electronic control unit equipped with a single bank memory (a first type of nonvolatile memory) and update data for an electronic control unit equipped with a dual bank memory (a second type of nonvolatile memory) as separate distribution packages. Then, the distribution package of the update data for the electronic control unit equipped with the dual bank memory is transmitted and received between the center and the OTA master before the distribution package of the update data for the electronic control unit equipped with the single bank memory.
[0069] This process makes it possible to suppress an increase in the amount of communication (communication load) between the center and the OTA master, since when communication of a distribution package is abnormal, only that distribution package needs to be resent. Also, since the center can check the consistency of the software before sending the update data in a distribution package, it is possible to avoid a situation where a resend request is generated because the OTA master finds that the software is inconsistent after downloading.
[0070] In addition, the OTA master can receive a distribution package of update data for an electronic control unit equipped with a dual bank memory before a distribution package of update data for an electronic control unit equipped with a single bank memory. Therefore, between the OTA master and the target electronic control unit, installation for a target electronic control unit equipped with a dual bank memory that does not require stop control during an update can be prioritized over installation for a target electronic control unit equipped with a single bank memory that requires stop control during an update.
[0071] This allows the OTA master to write update software to the storage area of the target electronic control unit equipped with dual bank memory first, and when the writing is about to be completed, start writing the update software to the storage area of the target electronic control unit equipped with single bank memory. This reduces the communication load within the vehicle (in-vehicle network) and shortens the time that vehicle control must be stopped until writing of all update software is completed.
[0072] 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 a method executed by an OTA master having a processor and a memory, a program, a computer-readable non-transitory storage medium storing a 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]
[0073] The disclosed technique can be used in a network system for updating software in an electronic control unit. [Explanation of symbols]
[0074] 10 Center 11, 31, 41 CPUs 12, 32, 42 RAM 13, 34 Storage device 14, 36, 44 Communication equipment 16, 37 Memory section 17, 38 Communications Department 18, 39 Control section 20 In-vehicle network 30 OTA Master 33 ROM 35 Microcomputer 40a~40d Electronic control unit (ECU) 43a, 43b Non-volatile memory 45, 46a, 46b Storage area 50 Communication Module 60a~60c Bus 70 Network
Claims
1. An OTA master that controls software updates of an electronic control unit mounted on a vehicle, a communication unit that receives a distribution package of update data for the electronic control unit from a center; an OTA master comprising: a control unit that, when the center contains, as the distribution packages receivable from the center, a first distribution package of update data intended for the electronic control unit equipped with a first type of non-volatile memory having one storage area, and a second distribution package of update data intended for the electronic control unit equipped with a second type of non-volatile memory having two storage areas, controls the communication unit to receive the second distribution package from the center before the first distribution package.
2. An OTA master as described in claim 1, wherein the control unit transfers the update data received by the communication unit to the electronic control unit to be updated based on type information indicating whether the non-volatile memory installed in the electronic control unit is the first type or the second type.
3. The OTA master according to claim 2 , wherein the communication unit acquires the type information from the center.
4. The OTA master according to claim 2 , further comprising a storage unit that stores the type information.
5. 5. The OTA master according to claim 2, wherein the control unit transfers update data for the electronic control unit equipped with the second type of non-volatile memory to the electronic control unit to be updated, based on the type information, giving priority to update data for the electronic control unit equipped with the first type of non-volatile memory.
6. A center capable of communicating with an OTA master that controls software updates of an electronic control unit mounted in a vehicle, a storage unit that stores type information indicating whether the nonvolatile memory mounted in the electronic control unit is a first type having one storage area or a second type having two storage areas; a communication unit that, when there exists a first distribution package of update data intended for an electronic control unit equipped with a first type of non-volatile memory having one storage area and capable of being transmitted to the OTA master, and a second distribution package of update data intended for an electronic control unit equipped with a second type of non-volatile memory having two storage areas, transmits the second distribution package to the OTA master so that the OTA master can receive it before the first distribution package.
7. The center according to claim 6 , wherein the communication unit transmits the type information stored in the storage unit to the OTA master.
8. A system including an OTA master that controls software updates of an electronic control unit mounted on a vehicle, and a center that can communicate with the OTA master, the center includes a first communication unit that transmits to the OTA master a first distribution package of update data intended for the electronic control unit equipped with a first type of non-volatile memory having one storage area, and a second distribution package of update data intended for the electronic control unit equipped with a second type of non-volatile memory having two storage areas; When the first distribution package and the second distribution package exist in the center, the OTA master: a second communication unit that receives the first distribution package and the second distribution package from the center; a control unit that controls the second communication unit to receive the second distribution package from the center before the first distribution package is received by the second communication unit.
9. 9. The system according to claim 8, wherein the control unit of the OTA master transfers update data for the electronic control unit equipped with the second type of nonvolatile memory to the electronic control unit to be updated, giving priority to update data for the electronic control unit equipped with the first type of nonvolatile memory, based on type information indicating whether the nonvolatile memory equipped in the electronic control unit is the first type or the second type.
10. The center further includes a storage unit that stores the type information, The system according to claim 9 , wherein the first communication unit of the center transmits the type information to the OTA master.
11. A method executed by an OTA master that includes a processor and a memory and controls software updates of an electronic control unit installed in a vehicle, the method comprising: receiving, when a first distribution package of update data intended for the electronic control unit equipped with a first type of non-volatile memory having one storage area and a second distribution package of update data intended for the electronic control unit equipped with a second type of non-volatile memory having two storage areas, the second distribution package from the center before the first distribution package; and transferring update data for the electronic control unit equipped with the second type of nonvolatile memory to the electronic control unit to be updated, based on type information indicating whether the nonvolatile memory equipped in the electronic control unit is of the first type or the second type, in priority to update data for the electronic control unit equipped with the first type of nonvolatile memory.
12. A program executed by a computer of an OTA master that includes a processor and a memory and controls software updates of an electronic control unit mounted on a vehicle, receiving, when a first distribution package of update data intended for the electronic control unit equipped with a first type of non-volatile memory having one storage area and a second distribution package of update data intended for the electronic control unit equipped with a second type of non-volatile memory having two storage areas, the second distribution package from the center before the first distribution package; and transferring update data for the electronic control unit equipped with the second type of nonvolatile memory to the electronic control unit to be updated, giving priority to update data for the electronic control unit equipped with the first type of nonvolatile memory, based on type information indicating whether the nonvolatile memory equipped in the electronic control unit is the first type or the second type.
13. A vehicle equipped with the OTA master according to any one of claims 1 to 5.
Citation Information
Patent Citations
Method for rewriting software of on-vehicle equipment, system of telematics system, and telematics device
JP2004326689A
Center device, delivery package generation method, and program for delivery package generation
JP2020027624A
Vehicle information communication system, vehicle information communication method, vehicle information communication program, and center device
JP2020027670A
Center device, distribution package generation method and distribution package generation program
US20210157568A1
