OTA master, method, and program

The OTA Master system addresses the challenge of mixed memory ECUs by prioritizing dual-bank memory updates, ensuring efficient and consistent software updates across vehicles with varying memory structures.

JP7750343B2Active Publication Date: 2025-10-07TOYOTA JIDOSHA KK
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
JP2024116719
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2024-07-22
Publication Date
2025-10-07
Estimated Expiration
2041-02-18

AI Technical Summary

Technical Problem

Existing software update methods for vehicles with mixed electronic control units (ECUs) having single-bank and dual-bank memory structures face challenges in ensuring consistent and efficient updates due to differing recovery methods, leading to potential startup delays.

Method used

A vehicle-mounted OTA Master that receives update data and notifies users, prioritizing updates for dual-bank memory ECUs, ensuring compatibility and efficient software updates by managing memory type-specific update processes.

Benefits of technology

Enables seamless software updates for both single-bank and dual-bank memory ECUs, reducing startup delays and communication load, and ensuring consistent update management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007750343000001
    Figure 0007750343000001
  • Figure 0007750343000002
    Figure 0007750343000002
  • Figure 0007750343000003
    Figure 0007750343000003
Patent Text Reader

Abstract

To provide a control device and the like capable of performing software updates adapted to single bank memory and dual bank memory.SOLUTION: There is provided a control device to be mounted on a vehicle. The device comprises: a reception unit for receiving, from a center, update data for updating software of an on-vehicle device mounted on the vehicle; and a communication unit configured to notify the center of an error when a type of the on-vehicle device indicated by the update data is different from an actual type of the on-vehicle device.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure relates to a method for controlling software updates in an electronic control unit. OTA master ( Control device ) etc. [Background technology]

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

[0003] One known technology for updating software in an electronic control unit is OTA (Over The Air) technology, which wirelessly connects an in-vehicle communication device connected to an in-vehicle network to a communication network such as the Internet, and a device responsible for updating the vehicle's software 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. See, for example, 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 the type used may vary 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] Japanese Patent Application Laid-Open No. 2004-326689 Summary of the Invention [Problem to be solved by the invention]

[0006] In a campaign, which is an event to update software for vehicles, both electronic control units with single bank memory and electronic control units with dual bank memory may be targeted for software updates. Due to the memory structure, the recovery methods for the electronic control units with single bank memory and those with dual bank memory when an update fails are different.

[0007] Therefore, when a campaign 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 electronic control units to be updated, if the download and installation are not performed according to the memory structure of the electronic control unit to be updated, it may take some time for the electronic control unit to start up normally after the software update.

[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 single-bank memories and dual-bank memories. [Means for solving the problem]

[0009] In order to solve the above problems, one aspect of the disclosed technology is a vehicle-mounted OTA Master and is mounted on a vehicle. memory a receiving unit that receives update data for updating the software from a center; memory The type of memory If the type is different from the mismatch and a notification unit that notifies the user of the OTA Master is. [Effects of the Invention]

[0010] According to the present disclosure, it is possible to provide a control device and the like that can perform software updates that are compatible with single-bank memories and dual-bank memories. [Brief explanation of the drawings]

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

[0012] In the network system for updating programs in electronic control units disclosed herein, a distribution package containing a mixture of update data for electronic control units with single-bank memory and update data for electronic control units with dual-bank memory is transmitted and received between a center and an OTA master (control device). This allows, for example, the center to check the consistency between the memory type of the target electronic control unit and the update data when generating the distribution package, and to prioritize installation for target electronic control units with dual-bank memory over installation for target electronic control units with single-bank memory. Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the drawings.

[0013] <Embodiment> [composition] Fig. 1 is a block diagram showing the 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 multiple 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 established within the vehicle.

[0014] (1) Center The center 10 can communicate with an OTA master 30 (described later) provided in the in-vehicle network 20 via the network 70, and can manage software updates for multiple electronic control units 40a to 40d connected to the OTA master 30. The center 10 functions 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 equipped with a readable and writable storage medium such as a hard disk drive (HDD) or a solid state drive (SSD), and stores a program for managing software updates, information used for the software update management, update data for each electronic control unit, and the like. In the center 10, the CPU 11 executes a program read from the storage device 13 using the RAM 12 as a work area, thereby performing predetermined processing related to software updates. The communication device 14 is a device for communicating with the OTA master 30 via a network 70.

[0016] (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.

[0017] The OTA master 30 is capable of wireless communication with the center 10 via the communication module 50. The OTA master 30 is a device that has the function of managing the OTA status, controlling the software update sequence, and performing software updates of electronic control units to be updated (hereinafter referred to as "target electronic control units"), and controls the 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. The OTA master 30 is sometimes referred to as a central gateway (CGW).

[0018] The multiple electronic control units 40a to 40d are devices (ECUs: Electronic Control Units) for controlling the operation of various parts of the vehicle. While FIG. 1 illustrates four electronic control units 40a to 40d, the number of electronic control units is not particularly limited. For example, a display device (HMI) may be connected to the OTA master 30 to display various information, such as a display indicating that update data is available during software update processing for the electronic control units 40a to 40d, a consent request screen for requesting consent for the software update from the vehicle user or administrator, and a display of the software update results. A car navigation system or the like may be used as the display device. Furthermore, 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 via a bus other than the buses 60a to 60c.

[0019] 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 may be configured as part of the OTA master 30.

[0020] 3 is a block diagram showing a schematic configuration of the OTA master 30 in FIG. 1. As shown in FIG. 3, 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, RAM 32, ROM 33, and storage device 34 constitute a microcomputer 35. In the OTA master 30, the CPU 31 executes a program read from the ROM 33, using the RAM 32 as a work area, thereby performing predetermined processing related to software updates. The communication device 36 is a device for communicating with the communication module 50 and electronic control units 40a to 40d via the buses 60a to 60c shown in FIG. 1.

[0021] 4A and 4B are block diagrams each showing an example of a schematic configuration of an electronic control unit.

[0022] The electronic control unit 40a shown in FIG. 4A includes a CPU 41, a RAM 42, a nonvolatile memory 43a, and a communication device 44. The CPU 41 executes programs read from the nonvolatile memory 43a using the RAM 42 as a work area, thereby realizing the functions of the electronic control unit 40a. The nonvolatile memory 43a is a memory (single-bank memory) having one storage area 45 for storing software. Hereinafter, the memory type of the nonvolatile memory 43a having this single storage area 45 will be referred to as the "first type." In addition to software for realizing the functions of the electronic control unit 40a, the storage area 45 may also store version information, parameter data, a boot program for startup, a program for software update, 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.

[0023] The electronic control unit 40b shown in FIG. 4B includes a CPU 41, a RAM 42, a nonvolatile memory 43b, and a communication device 44, similar to the electronic control unit 40a. However, the nonvolatile memory 43b installed in the electronic control unit 40b is a memory (dual bank memory) having two storage areas 46a and 46b for storing programs. Hereinafter, the type of nonvolatile memory 43b configured with these two storage areas 46a and 46b will be referred to as the "second type." In addition to software for implementing the functions of the electronic control unit 40b, the storage areas 46a and 46b may also store version information, parameter data, a boot program for startup, a program for software updates, and the like. The CPU 41 of the electronic control unit 40b selects one of the two storage areas 46a and 46b of the nonvolatile memory 43b as the storage area to be read (operational side) 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 (an updated program) based on the update data can be installed (written) in the background while the program in the storage area (operational side) that is the read target 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.

[0024] As a specific example, assume that current software is stored in storage area 46a and update software is installed in storage area 46b. When an instruction to activate the update software is received from OTA master 30, for example, the read start address of CPU 41 in electronic control unit 40b is switched from the first address of storage area 46a to the first address of storage area 46b, thereby switching the storage area to be read by CPU 41 (operational side) and executing the update software installed in storage area 46b. Note that in this disclosure, a configuration known as "single-side suspend memory," in which one storage area is partitioned into two pseudo-sides and a program can be written to one side while the other side is running, is also classified as the second type of memory.

[0025] Fig. 5 is a functional block diagram of the center 10 shown in Fig. 2. The center 10 shown in Fig. 5 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.

[0026] The storage unit 16 stores information related to software update processing for one or more electronic control units mounted on a vehicle. As information related to the software update processing, the storage unit 16 stores, for each vehicle identification information (vehicle ID) that identifies the vehicle, update management information that associates information indicating software available in the electronic control unit with update data for the software of the electronic control unit. For example, the information indicating the software available in the electronic control unit defines a combination of the latest version information for each software of multiple electronic control units.

[0027] The communication unit 17 is capable of receiving a software update confirmation request from the OTA master 30. The update confirmation request is information transmitted from the OTA master 30 to the center 10, for example, when the power or ignition (IGN) of the vehicle is turned on, and is information for requesting the center 10 to confirm whether or not there is update data for the electronic control unit. The communication unit 17 is also capable of receiving a distribution package transmission request (download request) from the OTA master 30. Upon receiving the distribution package download request, the communication unit 17 transmits to the OTA master 30 a distribution package including update data for the software of the electronic control unit, which is generated by the control unit 18 (described later).

[0028] When communication unit 17 receives an update confirmation request from OTA master 30, control unit 18 determines whether or not there is software update data for the electronic control unit mounted on the vehicle identified by the vehicle ID included in the update confirmation request, based on the update management information stored in storage unit 16. If control unit 18 determines that there is software update data for the electronic control unit, upon receiving a distribution package download request from OTA master 30, control unit 18 generates a distribution package including the corresponding update data stored in storage unit 16.

[0029] The control unit 18 may separately generate a distribution package containing only update data for an electronic control unit equipped with a first type of nonvolatile memory (single bank memory) and a distribution package containing only update data for an electronic control unit equipped with a second type of nonvolatile memory (dual bank memory). Alternatively, the control unit 18 may generate a distribution package containing update data for an electronic control unit equipped with a first type of nonvolatile memory (single bank memory) and update data for an electronic control unit equipped with a second type of nonvolatile memory (dual bank memory). If type information (described later) is stored in advance in the storage unit 16, the control unit 18 can intentionally generate a distribution package containing a mixture of multiple update data of different types. By generating such a distribution package containing a mixture of multiple update data of different types, a distribution package containing update data for an electronic control unit equipped with a first type of nonvolatile memory and update data for an electronic control unit equipped with a second type of nonvolatile memory can be transmitted from the center 10 (communication unit 17) to the OTA master 30.

[0030] Fig. 6 is a functional block diagram of the OTA master 30 shown in Fig. 2. The OTA master 30 shown in Fig. 6 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. 3. The communication unit 38 and the control unit 39 are realized by the CPU 31 shown in Fig. 3 executing a program stored in the ROM 33 using the RAM 32.

[0031] The storage unit 37 stores information (hereinafter referred to as "type information") relating to the type of nonvolatile memory installed in each of the plurality of electronic control units 40a to 40d. An example of the type information is shown in Fig. 7. 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 (first type or second type) of nonvolatile memory installed in that electronic control unit.

[0032] This type information may be created in advance based on the specifications of the electronic control units that make up the in-vehicle network 20 and stored in the storage unit 37 when the vehicle is manufactured. Alternatively, the type information may be acquired by the communication unit 38 (described later) via communication within the in-vehicle network 20 from the target electronic control unit to obtain the type of nonvolatile memory during a software update process. If the type of nonvolatile memory is acquired from the target electronic control unit each time a software update process is performed, the OTA master 30 can centrally manage the types of nonvolatile memory installed in multiple electronic control units installed in the vehicle, and can appropriately respond even if the type of nonvolatile memory is changed due to, for example, replacing the electronic control unit. Alternatively, the type information may be acquired from the center 10 via communication via the network 70. In this case, the type of nonvolatile memory of the electronic control unit installed in the vehicle is managed in advance by the center 10.

[0033] The communication unit 38 transmits a software update check request to the center 10, for example, when the vehicle power or ignition (IGN) is turned on. The update check request includes a vehicle ID for identifying the vehicle and the software versions of the electronic control units 40a to 40d connected to the in-vehicle network 20. The vehicle ID and the software versions of the electronic control units 40a to 40d are used to determine whether update data for the software of the electronic control units is available by comparing them with the latest software versions stored by the center 10 for each vehicle ID. The communication unit 38 also receives a notification from the center 10 in response to the update check request indicating the availability of update data. If update data for the software of the electronic control units is available, the communication unit 38 transmits a download request for a 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, installation order, type information, various control information used during the software update, and the like. Furthermore, when type information is obtained from the target electronic control unit during software update processing, the communication section 38 obtains the type information through communication with the target electronic control unit.

[0034] The control unit 39 determines whether or not there is update data for the software of the electronic control unit 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 received from the center 10 and stored in the memory unit 37. The control unit 39 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 update software based on the update data. After the installation is complete, the control unit 39 instructs the target electronic control unit to activate the installed update software.

[0035] Here, if the nonvolatile memory of the electronic control unit is of the first type (single bank memory), installation and activation are performed consecutively, and therefore consent request processing is performed before installation to request consent from the vehicle user or administrator for the software update. If the nonvolatile memory of the electronic control unit is of the second type (dual bank memory), consent request processing for the software update is performed at least after installation and before activation. Note that if the nonvolatile memory of the electronic control unit is of the second type memory, consent request processing for the software update before installation may be performed or may be omitted.

[0036] In the consent request process, the control unit 39 causes the output device to output a notification that consent is required for the software update and a notification prompting the user to input consent to the software update. Examples of the output device that can be used include a display device that provides visual notification and an audio output device that provides audio notification. For example, when a display device is used as the output device in the consent request process, the control unit 39 can cause the display device to display an consent request screen for requesting consent to the software update, and a notification prompting the user or administrator to perform a specific input operation, such as pressing an "accept" button, if the user or administrator consents. Furthermore, in the consent request process, the control unit 39 can cause the display device to display, on the display device, text or an icon notifying the user that update data for the electronic control unit software is available, and can also display, on the display device, restrictions on the execution of the software update process.

[0037] The control unit 39 performs the consent request process at a timing that corresponds to the memory type of the target electronic control unit based on the type information. Then, when the control unit 39 receives input from the user or administrator indicating consent, it executes the above-mentioned installation and activation control process to update the software of the target electronic control unit.

[0038] The software update process consists of a phase (download phase) in which the OTA master 30 downloads update data from the center 10, a phase (installation 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, and a phase (activation phase) in which the target electronic control unit activates the installed update software.

[0039] Downloading is a process in which the OTA master 30 receives update data for updating the software of the electronic control unit, which has been transmitted from the center 10 in a distribution package, and stores the received data in the storage unit 37. When receiving update data via download, priority may be given to update data intended for electronic control units equipped with a second type of nonvolatile memory (dual bank memory), which has a relatively low probability of update failure, or update data intended for electronic control units equipped with a first type of nonvolatile memory (single bank memory) and update data intended for electronic control units equipped with a second type of nonvolatile memory (dual bank memory) may be received equally. The download phase not only executes the download, but also includes control of a series of processes related to the download, such as determining whether the download can be executed 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, compressed data obtained by compressing the update software, or divided data obtained by dividing the update software or compressed data. The update data may also include the number (ECU_ID) of the target electronic control unit and a number (ECU_Software_ID) for identifying the software of the electronic control unit before the update. The update data is downloaded as the distribution package described above, and the distribution package includes update data for a single or multiple electronic control units.

[0041] Installation is a process in which the OTA master 30 writes update software (an updated program) to the target electronic control unit 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 determining 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, 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, differential 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. Alternatively, 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 and assembling (integrating) the differential 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. Alternatively, the target electronic control unit that receives the update data can install the software autonomously without receiving an explicit instruction from the OTA master 30.

[0044] Activation is the process by which the target electronic control unit activates the installed update software. The activation phase not only executes the activation, but also includes a series of controls related to the activation, such as determining whether the activation can be executed and verifying the execution results.

[0045] The target electronic control unit can activate the update software based on an activation request from the OTA master 30. Alternatively, the target electronic control unit that has received the update data can autonomously activate the software after installation is complete, 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 electronic control units.

[0047] Furthermore, in this specification, the term "software update processing" includes not only processing in which downloading, installing, and activating are all performed consecutively, but also processing in which only some of the downloading, installing, and activating are performed.

[0048] [process] Next, with further reference to FIGS. 8, 9, 10, 11A, 11B, and 12, several specific examples of software update processing executed in the network system according to this embodiment will be described.

[0049] (1) Example 1 8 is a flowchart illustrating the download processing procedure according to specific example 1 performed by the center 10 and the OTA master 30. This specific example 1 is an example in which the center 10 manages the memory types of the nonvolatile memories installed in each of the multiple electronic control units 40a to 40d, that is, the storage unit 16 stores type information. Note that the same type information may also be stored in the storage unit 37 of the OTA master 30. The processing shown 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 including update data for the target electronic control unit that is the target of the software update. At this time, the center 10 references the type information stored in the storage unit 16 and generates a distribution package in which the memory type of the nonvolatile memory installed in the target electronic control unit is attached as an attribute to the update data. Once the distribution package is generated, processing proceeds to step S802.

[0051] (Step S802) The OTA master 30 receives the distribution package transmitted from the center 10. When the distribution package is received, the process proceeds to step S803.

[0052] (Step S803) The OTA master 30 stores the update data included in the distribution package received from the center 10 and the memory type attached as an attribute to the update data in the storage unit 37. This completes the download process.

[0053] As in Example 1, when the center 10 manages type information, it is possible to check the consistency between the target electronic control unit and the update data regarding memory type when generating a distribution package. This makes it possible to avoid a situation where the OTA master 30 finds inconsistency after downloading. This prevents the need to resend the distribution package and suppresses an increase in the amount of communication (communication load) between the center 10 and the OTA master 30.

[0054] (2) Example 2 9 is a flowchart illustrating the download processing procedure according to specific example 2 performed by the center 10 and the OTA master 30. This specific example 2 is an example in which the OTA master 30 manages the memory types of the nonvolatile memories installed in each of the multiple electronic control units 40a to 40d, that is, the storage unit 16 of the center 10 does not store type information. The processing shown in FIG. 9 is started when the center 10 receives a download request for a distribution package from the OTA master 30.

[0055] (Step S901) The center 10 generates a distribution package including update data for the target electronic control unit that is the target of the software update. At this time, the center 10 does not need to know whether the distribution package includes update data for the electronic control unit equipped with a first type of nonvolatile memory (single bank memory) and update data for the electronic control unit equipped with a second type of nonvolatile memory (dual bank memory). Once the distribution package is generated, the process proceeds to step S902.

[0056] (Step S902) The OTA master 30 receives the distribution package transmitted from the center 10. When the distribution package is received, the process proceeds to step S903.

[0057] (Step S903) The OTA master 30 stores the update data included in the distribution package received from the center 10 in the storage unit 37. This completes the download process.

[0058] In specific example 2, the OTA master 30 manages the type information, so if the memory type of the non-volatile memory is changed due to replacement of the electronic control unit, etc., it is possible to quickly update the type information managed by the OTA master 30 within the vehicle (in-vehicle network 20).

[0059] (3) Example 3 10 is a flowchart illustrating the installation process according to a third specific example, which is performed by the OTA master 30 and the target electronic control unit. This third specific example is an example in which the OTA master 30 controls the installation order of update data according to the memory type of the nonvolatile memory installed in the target electronic control unit. In this case, the memory type of the nonvolatile memory installed in each of the multiple electronic control units 40a to 40d may be managed by either the center 10 or the OTA master 30. The process shown in FIG. 10 starts after the download of the update data is completed and certain conditions (such as whether installation is possible or whether the update software is verified) are satisfied.

[0060] (Step S1001) The OTA master 30 acquires the memory type (first type / second type) of the nonvolatile memory installed in the target electronic control unit (target ECU). This memory type can be acquired by referring to type information stored in the storage unit 37 if managed by the OTA master 30, or by referring to memory type information included in and transmitted from the distribution package if managed by the center 10. Once the memory type of the target electronic control unit is acquired, the process proceeds to step S1002.

[0061] (Step S1002) The OTA master 30 and the target electronic control units (target ECUs) equipped with the second type of nonvolatile memory (dual bank memory) execute installation, which is a process of writing update software to a storage area based on the update data. This installation is executed consecutively or in parallel for all target electronic control units equipped with the second type of nonvolatile memory (first process). When the execution of installation for all target electronic control units equipped with the second type of nonvolatile memory is completed, the process proceeds to step S1003.

[0062] (Step S1003) The OTA master 30 and the target electronic control units (target ECUs) equipped with a first type of nonvolatile memory (single bank memory) execute an installation process, which is a process of writing update software to a storage area based on the update data. This installation process is executed consecutively or in parallel for all target electronic control units equipped with the first type of nonvolatile memory (second process). When the execution of the installation process for all target electronic control units equipped with the first type of nonvolatile memory is completed, the installation process for all target electronic control units is completed, and the installation process ends.

[0063] In Example 3, installation of the update software into a target electronic control unit equipped with a dual-bank memory, which does not require stop control during the update, is prioritized over installation of the update software into a target electronic control unit equipped with a single-bank memory, which requires stop control during the update. This process allows the OTA master 30, which can monitor the update software writing status in real time, to write the update software into the storage area of ​​the target electronic control unit equipped with a dual-bank memory first, and then start writing the update software into the storage area of ​​the target electronic control unit equipped with a single-bank memory when the writing is about to be completed. This reduces the communication load within the vehicle (in-vehicle network 20) ​​and shortens the time required to stop vehicle control until all update software has been written.

[0064] (4) Example 4 11A and 11B are flowcharts illustrating the installation process according to Example 4, which is performed by the OTA master 30 and the target electronic control unit. The process in FIG. 11A and the process in FIG. 11B are connected by a connector X. Example 4 is an example in which the OTA master 30 controls the installation order of update data according to the memory type of the nonvolatile memory installed in the target electronic control unit, while ensuring consistency between the memory type of the nonvolatile memory installed in the target electronic control unit and the memory type managed by the type information. In this case, the memory type of the nonvolatile memory installed in each of the multiple electronic control units 40a to 40d may be managed by either the center 10 or the OTA master 30. The process shown in FIGS. 11A and 11B starts after the download of the update data is completed and certain conditions (such as whether installation is possible or the update software is verified) are satisfied.

[0065] (Step S1101) The OTA master 30 acquires the memory type (first type / second type) of the nonvolatile memory installed in the target electronic control unit (target ECU). This memory type can be acquired by referring to type information stored in the storage unit 37 if managed by the OTA master 30, or by referring to memory type information included in and transmitted from the distribution package if managed by the center 10. Once the memory type of the target electronic control unit is acquired, the process proceeds to step S1102.

[0066] (Step S1102) The OTA master 30 and a target electronic control unit (target ECU) equipped with a second type of nonvolatile memory (dual bank memory) execute installation, which is a process of writing update software to a storage area based on the update data. At this time, the OTA master 30 notifies the target electronic control unit that executed the installation of the memory type acquired in step S1101. After the installation has been executed for the target electronic control unit equipped with the second type of nonvolatile memory and the notification of the memory type has been made, the process proceeds to step S1103.

[0067] (Step S1103) The target electronic control unit that performed the installation determines whether the memory type of its own mounted nonvolatile memory matches the memory type notified by the OTA master 30. That is, the target electronic control unit that performed the installation determines whether the memory type notified by the OTA master 30 is the second type. If the two memory types match (step S1103, Yes), the process proceeds to step S1102, and if the two memory types do not match (step S1103, No), the process proceeds to step S1104.

[0068] (Step S1104) The target electronic control unit equipped with the second type of nonvolatile memory notifies the OTA master 30 that the memory type notified by the OTA master 30 does not match the memory type of the nonvolatile memory equipped in the target electronic control unit itself. If the center 10 manages the memory types of the nonvolatile memories equipped in each of the multiple electronic control units 40a to 40d, this notification is sent from the OTA master 30 to the center 10. When the mismatch in memory types is notified, the process proceeds to step S1102.

[0069] The first process in steps S1102 to S1104 described above is executed consecutively or in parallel for all of the target electronic control units equipped with the second type nonvolatile memory (dual bank memory).

[0070] (Step S1105) The OTA master 30 and a target electronic control unit (target ECU) equipped with a first type of nonvolatile memory (single bank memory) execute installation, which is a process of writing update software to a storage area based on the update data. At this time, the OTA master 30 notifies the target electronic control unit that executed the installation of the memory type acquired in step S1101. Once the installation has been executed for the target electronic control unit equipped with the first type of nonvolatile memory and the notification of the memory type has been made, the process proceeds to step S1106.

[0071] (Step S1106) The target electronic control unit that performed the installation determines whether the memory type of its own nonvolatile memory matches the memory type notified by the OTA master 30. That is, the target electronic control unit that performed the installation determines whether the memory type notified by the OTA master 30 is the first type. If the two memory types match (step S1106, Yes), the process proceeds to step S1105, and if the two memory types do not match (step S1106, No), the process proceeds to step S1107.

[0072] (Step S1107) The target electronic control unit equipped with a first type of nonvolatile memory notifies the OTA master 30 that the memory type notified by the OTA master 30 does not match the memory type of the nonvolatile memory equipped in the target electronic control unit itself. If the center 10 manages the memory types of the nonvolatile memories equipped in each of the multiple electronic control units 40a to 40d, this notification is sent from the OTA master 30 to the center 10. When the mismatch in memory types is notified, the process proceeds to step S1105.

[0073] The second process in steps S1105 to S1107 described above is executed consecutively or in parallel for all of the target electronic control units equipped with the first type of nonvolatile memory (single bank memory).

[0074] When the execution of installation (first process) for all target electronic control units equipped with non-volatile memory of the second type is completed, and the execution of installation (second process) for all target electronic control units equipped with non-volatile memory of the first type is completed, the installation process ends.

[0075] In Example 4, installation of software for a target electronic control unit equipped with dual-bank memory that does not require stop control during the update is performed with priority over installation of software for a target electronic control unit equipped with single-bank memory that requires stop control during the update (Example 3). In addition, the system checks whether the memory type of the non-volatile memory installed in the target electronic control unit matches the memory type managed by the type information. This process makes it possible to install new update software that matches the actual state if the memory type in the type information managed by the center 10 or the OTA master 30 differs from the actual state of the target electronic control unit. Furthermore, the memory type in the type information managed by the center 10 or the OTA master 30 can be rewritten and updated as necessary.

[0076] (5) Example 5 12 is a flowchart illustrating the download and installation processing procedure according to specific example 5, which is performed by the center 10, the OTA master 30, and the target electronic control unit. This specific example 5 is an example in which a distribution package including update data for a target electronic control unit equipped with a first type of nonvolatile memory (single bank memory) and update data for a target electronic control unit equipped with a second type of nonvolatile memory (dual bank memory) is transmitted from the center 10. The memory types of the nonvolatile memories equipped in each of the multiple electronic control units 40a to 40d are managed by the center 10. The processing shown in FIG. 12 is started when the center 10 receives a download request for the distribution package from the OTA master 30.

[0077] (Step S1201) The center 10 generates a distribution package including update data for an electronic control unit equipped with a first type of nonvolatile memory (single bank memory) and update data for an electronic control unit equipped with a second type of nonvolatile memory (dual bank memory). At this time, the center 10 references the type information stored in the storage unit 16 to generate a distribution package that mixes update data for the first type and update data for the second type. The memory type may be attached to the update data as an attribute. Once the distribution package is generated, processing proceeds to step S1202.

[0078] (Step S1202) The OTA master 30 receives the distribution package transmitted from the center 10. When the distribution package is received, the process proceeds to step S1203.

[0079] (Step S1203) The OTA master 30 stores the update data and the memory type of the update data included in the distribution package received from the center 10 in the storage unit 37. Once the update data and the memory type of the update data are stored, the process proceeds to step S1204.

[0080] (Step S1204) The OTA master 30 and the target electronic control unit (target ECU) execute an installation process, which is a process of writing update software to a storage area based on the update data. At this time, the installation process for the target electronic control unit equipped with the first type of nonvolatile memory and the installation process for the target electronic control unit equipped with the second type of nonvolatile memory are executed in parallel. When the installation process for all target electronic control units is completed, this process ends.

[0081] As in Example 5, when the center 10 manages type information, it is possible to check the consistency between the target electronic control unit and the update data regarding memory type when generating a distribution package. This makes it possible to avoid a situation in which the OTA master 30 finds inconsistency after downloading. This prevents the distribution package from having to be resent, and suppresses an increase in the amount of communication (communication load) between the center 10 and the OTA master 30. Furthermore, since installation for a target electronic control unit equipped with a single bank memory and installation for a target electronic control unit equipped with a dual bank memory can be performed in parallel, it is possible to quickly complete the software update process for a system that includes both a target electronic control unit equipped with a single bank memory and a target electronic control unit equipped with a dual bank memory.

[0082] <Actions and Effects> As described above, according to the network system of one embodiment of the present disclosure, a distribution package containing update data intended for an electronic control unit equipped with a single bank memory (a first type of non-volatile memory) and update data intended for an electronic control unit equipped with a dual bank memory (a second type of non-volatile memory), i.e., a distribution package containing a mixture of multiple update data of different types, can be transmitted and received between the center and the OTA master.

[0083] As a result, for example, if the center manages type information regarding the memory type of the nonvolatile memory installed in each of multiple electronic control units installed in a vehicle, it is possible to check the consistency between the target electronic control unit and the update data regarding memory type when generating a distribution package. This makes it possible to avoid a situation where an inconsistency is discovered in the OTA master after download. This prevents the need to retransmit the distribution package and suppresses an increase in the amount of communication (communication load) between the center and the OTA master. Furthermore, if the OTA master manages type information, if the memory type of the nonvolatile memory changes due to an electronic control unit replacement or other reason, it is possible to quickly update the type information managed by the OTA master within the vehicle (in-vehicle network).

[0084] In addition, since the OTA master can receive 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, between the OTA master and the target electronic control unit, installation for a target electronic control unit equipped with a dual bank memory, which does not require stop control during the update, can be performed with priority over installation for a target electronic control unit equipped with a single bank memory, which requires stop control during the update.

[0085] 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 then start writing the update software to the storage area of ​​the target electronic control unit equipped with single bank memory when the writing is about to complete. This reduces the communication load within the vehicle (in-vehicle network) and shortens the time that vehicle control must be stopped until all update software has been written.

[0086] Alternatively, the OTA master can perform installation on a target electronic control unit with a single bank memory and installation on a target electronic control unit with a dual bank memory in parallel, in which case it is expected that the software update process for a system that includes both a target electronic control unit with a single bank memory and a target electronic control unit with a dual bank memory can be completed quickly.

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

[0088] The disclosed technique can be used in a network system for updating programs in electronic control units. [Explanation of symbols]

[0089] 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 areas 50 Communication Module 60a~60c Bus 70 Network

Claims

1. An OTA master mounted on a vehicle, a receiving unit that receives update data for updating software stored in a memory installed in the vehicle from a center; an informing unit that, when the type of the memory indicated by the update data differs from the type of the memory, notifies the center of a mismatch.

2. 2. The OTA master of claim 1, wherein the update data includes first update data for a first memory equipped with a first type of non-volatile memory having one storage area, and second update data for a second memory equipped with a second type of non-volatile memory having two storage areas.

3. 2. The OTA master according to claim 1, further comprising a control unit that controls the startup of a first electronic control unit equipped with a first type of nonvolatile memory having one storage area and the startup of a second electronic control unit equipped with a second type of nonvolatile memory having two storage areas so that they occur at different times.

4. 2. The OTA master of claim 1, wherein the type of memory indicated by the update data indicates whether the memory is a first memory equipped with a first type of non-volatile memory having one storage area, or a second memory equipped with a second type of non-volatile memory having two storage areas.

5. A method performed by an OTA master on board a vehicle, comprising: receiving update data from a center for updating software in a memory installed in the vehicle; If the type of memory indicated by the update data differs from the type of the memory, notifying the center of the discrepancy.

6. A program to be executed by an OTA master computer installed in a vehicle, receiving update data from a center for updating software in a memory installed in the vehicle; and if the type of memory indicated by the update data differs from the type of the memory, notifying the center of the discrepancy.

Citation Information

Patent Citations

  • Method for rewriting software of on-vehicle equipment, system of telematics system, and telematics device

    JP2004326689A

  • Program update system, control system, moving body, program update method and program

    JP2020144682A

  • OTA master, center, system, method, program, and vehicle

    JP2022126194A