OTA Master

Abstract

To provide an OTA master that determines abnormality occurrence after switching is completed.SOLUTION: Provided is an OTA master capable of communicating via a network with a center that stores the software update states of vehicles. The OTA master comprises: a first control unit that executes, after an onboard equipment software update process is executed on the basis of update data received from the center and a setup for getting started by updated software next time is finished, an update completion process of causing the center to grasp update completion and presenting a user to the effect that updating is completed; a second control unit that acquires software version information at a time after vehicle startup in the state of having been switched to the updated software; a third control unit that acquires from the center the software version information of the host vehicle that is preserved in the center at the above point of time; and a fourth control unit that determines that the update completion process has not been normally completed, when the version information acquired by the second control unit and the version information acquired by the third control unit do not match.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to an OTA master capable of communicating via a network with a center that stores the update status of vehicle software. [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] A known technology for updating software in an electronic control unit is 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 (OTA master) responsible for updating the vehicle's software downloads software from a server such as a center 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] Once the software update for a specific in-vehicle device is complete, the device will switch to the updated software and start up. Once the update is complete, an update completion notice indicating this is displayed, for example, on the navigation screen. This allows the user to recognize that the software update has been (successfully) completed. This update completion notice is displayed in the following process flow:

[0005] First, each in-vehicle device individually notifies the center that its own update has been completed. Based on this notification, the center can grasp the update completion status. After the update of all in-vehicle devices has been completed, if the OTA master sends an inquiry to the center asking whether the update of all in-vehicle devices has been completed, the OTA master responds by notifying the OTA master that all updates have been completed. In response, the OTA master displays an update completion notification on the navigation screen. In other words, when the software update in the vehicle is completed, the center is notified so that the center can grasp the update completion status of each vehicle, and then the process of displaying the update completion notification on the vehicle side (update completion process) is executed. Note that displaying this update completion notification is also required by law. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Application Laid-Open No. 2004-326689 Summary of the Invention [Problem to be solved by the invention]

[0007] However, even if the switch (update) to the new software itself is completed normally, the update completion process, which is the process between the completion of the software switch and the display of the update completion, may end abnormally, for example, due to an abnormal termination of the process of sending a notification of the update completion from the vehicle to the center. Note that "normal completion (completion) of the switch" here refers to a state in which the vehicle is currently running with the software before the update, but as a result of the update process, the binary data of the updated software has been placed in the memory area where the software to be loaded after startup is stored, and the settings have been completed so that the updated software will be loaded and started up at the next startup. For example, in the case of a single-bank memory, this refers to a state in which the binary data of the updated software has been placed, and in the case of a dual-bank memory, the bank where the updated software is stored is specified as the bank to be used at startup.

[0008] If an abnormal termination such as the one described above occurs, even if the switch to the updated software itself has been completed successfully, the center may treat the update of all in-vehicle devices as incomplete because the notification of update completion has not been received, and the update completion notification may not be displayed on the navigation screen. Furthermore, not displaying such an update completion notification (not presenting it to the user) even when the update has been completed is problematic from a legal standpoint.

[0009] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide an OTA master that can determine whether an abnormality has occurred after switching is completed. [Means for solving the problem]

[0010] In order to solve the above problem, one aspect of the disclosed technology is an OTA master capable of communicating via a network with a center that stores the update status of vehicle software, the OTA master including: a first control unit that executes software update processing for a predetermined in-vehicle device based on update data received from the center; and, after completing settings for starting the vehicle with the updated software at the next startup, executes update completion processing to let the center know that the update has been completed and to notify the user that the update has been completed; a second control unit that, at a predetermined timing after the vehicle is started with the updated software switched to, acquires version information of the software of the in-vehicle device at that time; a third control unit that acquires from the center version information of the software of the in-vehicle device related to the vehicle that is stored in the center at the above time; and a fourth control unit that determines that the update completion processing did not end normally if the version information acquired by the second control unit and the version information acquired by the third control unit do not match. [Effects of the Invention]

[0011] According to the OTA master of the present disclosure, it is possible to determine whether or not an abnormality has occurred after the switching is completed, and to display an update completion notification. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram showing the overall configuration of a network system according to an embodiment of the present invention. [Figure 2] Block diagram showing the general configuration of the center [Figure 3] Center functional block diagram [Figure 4] Block diagram showing the schematic configuration of the OTA master [Figure 5] OTA Master Functional Block Diagram [Figure 6] Flowchart of the control process executed by the OTA master DETAILED DESCRIPTION OF THE INVENTION

[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. The center 10 can control and manage software updates for the multiple electronic control units 40a to 40d connected to the OTA master 30 by transmitting update data for the software of the electronic control units 40a to 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.

[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 software update control and 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 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] Fig. 3 is a functional block diagram of the center 10 shown in Fig. 2. The center 10 shown in Fig. 3 includes a storage unit 16, a communication unit 17, and a control unit 18. The storage unit 16 is realized by the storage device 13 shown in Fig. 2. The communication unit 17 and the control unit 18 are realized by the CPU 11 shown in Fig. 2 executing a program stored in the storage device 13 using the RAM 12.

[0017] The storage unit 16 stores information related to software update processing for 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 that associates information indicating software available in the electronic control units 40a to 40d with each vehicle identification information (vehicle ID) that identifies the vehicle, and update data for the software of the electronic control units 40a to 40d. The information indicating the software available in the electronic control units 40a to 40d may, for example, be defined as a combination of the latest version information for each of the multiple electronic control units 40a to 40d. Furthermore, as information related to the software update processing, the storage unit 16 can store update status information indicating the status of software updates being performed on the vehicle. Furthermore, the storage unit 16 can store information related to the type of non-volatile memory mounted in each of the multiple electronic control units 40a to 40d.

[0018] The communication unit 17 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. The update confirmation request is information transmitted from the OTA master 30 to the center 10, for example, when the power or ignition of the vehicle is turned on (hereinafter referred to as "power ON"), and is information for requesting the center 10 to confirm whether or not update data for the electronic control units 40a to 40d is available based on vehicle configuration information. Furthermore, upon receiving an update confirmation request from the OTA master 30, the communication unit 17 transmits information indicating the availability of update data to the OTA master 30. Furthermore, the communication unit 17 receives a distribution package transmission request (download request) from the OTA master 30. Furthermore, upon receiving a distribution package download request, the communication unit 17 transmits a distribution package including software update data for the electronic control units 40a to 40d to the OTA master 30.

[0019] When the communication unit 17 receives an update check request from the OTA master 30, the control unit 18 determines whether or not there is software update data for the electronic control units 40a to 40d mounted on the vehicle identified by the vehicle ID included in the update check request, based on the update management information (such as the version of the electronic control unit) stored in the storage unit 16. The control unit 18 transmits the determination result of whether or not there is update data to the OTA master 30 via the communication unit 17. When the determination unit 15 determines that there is software update data for the electronic control units 40a to 40d, the control unit 18 generates and transmits a distribution package including the update data to the OTA master 30 that has issued the update check request.

[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 is capable of wirelessly communicating with the center 10 via the bus 60a and the communication module 50 and the network 70. The OTA master 30 is a device that has the function of managing the OTA status, controlling the update sequence, which is the flow of the software update process, and performing a software update of the electronic control unit to be updated (hereinafter referred to as the "target electronic control unit"). The OTA master 30 controls the software update of the target electronic control unit 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] 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, 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 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 for the plurality of 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 about the type of nonvolatile memory installed in each of the plurality of electronic control units 40a to 40d.

[0025] The communication unit 38 transmits and receives data, information, requests, and the like to and from the center 10. For example, when the vehicle is powered on, the communication unit 38 transmits a software update check request to the center 10. The update check request includes, for example, a vehicle ID for identifying the vehicle and version information related to the current versions of the software in the electronic control units 40a to 40d connected to the in-vehicle network 20. The update check request may also include information related to the types of the electronic control units 40a to 40d connected to the in-vehicle network 20. The vehicle ID and the current versions of the software in the electronic control units 40a to 40d are used to determine whether or not update data is available for the software in the electronic control units 40a to 40d by comparing them with the latest versions of the software stored by the center 10 for each vehicle ID. The communication unit 38 also receives a notification indicating the availability of update data from the center 10 in response to the update check request. When there is software update data for 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, and receives (downloads) the distribution package transmitted from the center 10 under the control of the control unit 39. The communication unit 38 also transmits to the center 10 the update status of the software transmitted by the electronic control units 40a to 40d.

[0026] The control unit 39 determines whether or not there is software update data for 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 performs, under its own control, decryption and verification of the authenticity of a 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 software update processing (various verifications, installation, activation, etc.) for 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 complete, the control unit 39 instructs the target electronic control unit to activate the installed update software. During this software update process, the control unit 39 appropriately controls various procedures such as verification, installation, and activation in the electronic control units 40a to 40d.

[0027] The control unit 39 also has the following functions: a software update process for a specified in-vehicle device is executed based on the update data received from the center 10; after the settings for starting the vehicle with the updated software at the next startup are completed, the control unit 39 executes an update completion process to inform the center 10 that the update has been completed and to notify the user that the update has been completed (first control unit); a function to acquire software version information for the in-vehicle device at that time at a predetermined timing after the vehicle is started with the updated software switched to (second control unit); a function to acquire from the center 10 software version information for the in-vehicle device related to the vehicle that is stored in the center 10 at that time (third control unit); and a function to determine that the update completion process did not end normally if the version information acquired by the second control unit does not match the version information acquired by the third control unit (fourth control unit).

[0028] 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 an example in which the in-vehicle network 20 includes 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.

[0029] 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. Note that the communication module 50 may be configured as part of the OTA master 30.

[0030] [control] Next, the control executed in the network system according to this embodiment will be described with further reference to Fig. 6. Fig. 6 shows a processing sequence of the control executed between the center 10 and the OTA master 30. The control shown in Fig. 6 starts when the ignition of the vehicle is turned on (IG-ON).

[0031] (Step S611) The OTA master 30 determines whether or not this is the first time the software has been started since being switched to the new software. If this is the first time the software has been started since being switched to the new software (step S611, Yes), the process proceeds to step S612; otherwise, the control ends.

[0032] (Step S612) The OTA master 30 acquires version information relating to the version of each software of the multiple electronic control units 40a to 40d installed in the vehicle (host vehicle). Note that the version information to be acquired need only be for the newly switched software. Once the software version information is acquired, the process proceeds to step S613.

[0033] (Step S613) The OTA master 30 requests the center 10 to transmit version information about the software related to the multiple electronic control units 40a to 40d installed in the vehicle, which information is held by the center 10 (stored in the storage unit 16). Once the request is transmitted, the process proceeds to step S614.

[0034] (Step S621) When the center 10 receives a request to transmit the software version information from the OTA master 30, it transmits the software version information to the OTA master 30. Once the software version information has been transmitted, the process proceeds to step S622.

[0035] (Step S614) When the OTA master 30 receives the software version information from the center 10, the process proceeds to step S615.

[0036] (Step S615) The OTA master 30 determines whether the software version information received from the center 10 matches the software version information acquired from the multiple electronic control units 40a-40d. If both sets of version information match (step S615, Yes), it is determined that there is no problem, and the process proceeds to step S616. On the other hand, if both sets of version information do not match (step S615, No), it is determined that there is a problem, such as an abnormal termination occurring in the process after switching, and the process proceeds to step S617.

[0037] (Step S616) The OTA master 30 transmits a notification (match notification) indicating that the two pieces of version information match to the center 10. When the match notification is transmitted to the center 10, this control by the OTA master 30 ends.

[0038] (Step S617) The OTA master 30 transmits a notice (mismatch notice) indicating that the version information of both devices does not match to the center 10. This mismatch notice also serves as a request to correct the version information. When the mismatch notice is transmitted to the center 10, the process proceeds to step S618.

[0039] (Step S618) The OTA master 30 executes a process to display the update completion notification. In this process, the OTA master 30 modifies its own update completion status information as necessary, and displays the update completion notification on the screen of the navigation device, etc. When the process to display the update completion notification is executed, this control by the OTA master 30 ends.

[0040] (Step S622) The center 10 determines whether the two pieces of version information match based on the match notification or mismatch notification received from the OTA master 30. If the two pieces of version information match (step S622, Yes), it is determined that there is no problem, and this control by the center 10 ends. On the other hand, if the two pieces of version information do not match (step S622, No), it is determined that there is a problem, and the process proceeds to step S623.

[0041] (Step S623) The center 10 executes a process to correct predetermined information. In this process, the center 10 appropriately corrects information related to updates, such as update status information stored in the storage unit 16. When the information correction process is executed, this control by the OTA master 30 ends.

[0042] <Effects> As described above, the OTA master according to an embodiment of the present disclosure can determine whether an abnormality has occurred after the switchover is completed by checking the update status while communicating with the center. Also, the OTA master according to the present embodiment can display an update completion notification. [Industrial Applicability]

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

[0044] 10 Center 11, 31 CPUs 12, 32 RAM 13, 34 Storage device 14, 36 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) 50 Communication Module 60a~60c Bus 70 Network

Claims

[Claim 1] An OTA master capable of communicating with a center that stores the update status of vehicle software via a network, a first control unit that executes a software update process for a predetermined in-vehicle device based on the update data received from the center, and after completing settings for starting the device with the updated software at the next startup, executes an update completion process to inform the center that the update has been completed and to notify a user that the update has been completed; a second control unit that acquires, at a predetermined timing after the vehicle is started with the updated software installed, version information of the software of the in-vehicle device at that time; a third control unit that acquires from the center version information of the software of the in-vehicle device related to the vehicle, the version information being stored in the center at the time; an OTA master comprising: a fourth control unit that, if the version information acquired by the second control unit and the version information acquired by the third control unit do not match, determines that the update completion process did not end normally and requests the center to correct information related to the software update process stored in the center.

Images