User terminal, software update system, control method and program

The user terminal reduces communication load and power consumption by displaying software update progress using locally stored data, addressing the issue of increased load during OTA updates for vehicle ECUs.

JP7722313B2Active Publication Date: 2025-08-13TOYOTA JIDOSHA KK
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2022160792
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-10-05
Publication Date
2025-08-13
Estimated Expiration
2042-10-05

AI Technical Summary

Technical Problem

Displaying software update progress on both in-vehicle HMI and user terminal increases communication load and power consumption during OTA updates for vehicle ECUs.

Method used

A user terminal receives and transmits software to the vehicle, displaying the update process progress using information already received, thereby reducing communication load by avoiding the need for additional data transfer.

Benefits of technology

Reduces communication load and power consumption by utilizing data already received by the user terminal to display software update progress, ensuring smooth software update processes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007722313000001
    Figure 0007722313000001
  • Figure 0007722313000002
    Figure 0007722313000002
  • Figure 0007722313000003
    Figure 0007722313000003
Patent Text Reader

Abstract

To enable suppression of a communication load in displaying a progress of update processing of a software of an on-vehicle ECU.SOLUTION: A software that is distributed from a server is downloaded to a vehicle through an on-vehicle communication module. And the software is downloaded to the vehicle via a user terminal. Update processing of an on-vehicle ECU is performed using the downloaded software. When the update processing is performed using the software downloaded via the user terminal (positive determination in S10), the user terminal displays a download status and a transfer status (S11). When the software is downloaded through the on-vehicle module (negative determination in S10), displaying is not performed.SELECTED DRAWING: Figure 9
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure relates to a user terminal, a software update system, a control method, and a program. [Background technology]

[0002] Japanese Patent Application Laid-Open Publication No. 2017-149323 (Patent Document 1) discloses a technology for updating software of an ECU (Electronic Control Unit) mounted on a vehicle by OTA (Over The Air). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2017-149323 Summary of the Invention [Problem to be solved by the invention]

[0004] A vehicle can download new software (data) for its onboard ECU by wirelessly communicating with an external server (for example, an OTA center). Then, the target ECU (the ECU whose software is to be updated) in the vehicle installs and activates the software, thereby updating the software.

[0005] When updating software (control programs) using such OTA technology, the software is downloaded from an OTA center via onboard communication equipment (for example, a communication module such as a DCM (Data Communication Module)) or a terminal owned by the user (user terminal: for example, a mobile terminal such as a smartphone).

[0006] When updating software for an in-vehicle ECU, notifications of the update progress and consent may be displayed on the vehicle's HMI (Human Machine Interface) or user terminal. When the update is performed using software downloaded via in-vehicle communication equipment or via a user terminal, displaying the progress status on both the HMI and the user terminal can increase communication load and power consumption.

[0007] An object of the present disclosure is to enable suppression of communication load when displaying the progress of software update processing for an in-vehicle ECU. [Means for solving the problem]

[0008] (1) A user terminal according to the present disclosure includes a receiving unit that receives software for an in-vehicle ECU and a transmitting unit that transmits the received software to a vehicle. The user terminal includes a control unit that displays a progress status of a first update process when the first update process is executed to update the software for the in-vehicle ECU using the software received by the receiving unit.

[0009] According to this configuration, the user terminal transmits the software received by the receiving unit to the vehicle from the transmitting unit. As a result, the software for the in-vehicle ECU is distributed to the vehicle via the user terminal. When the control unit of the user terminal executes a first update process for updating the software for the in-vehicle ECU using the software received by the receiving unit of the user terminal, the control unit of the user terminal displays the progress of the first update process. Since information (data) required for the first update process is distributed (transmitted) to the vehicle via the user terminal, data already received by the user terminal can be used when displaying the progress of the first update process, thereby reducing the communication load.

[0010] (2) Preferably, in (1), the progress of the first update process may include a progress of the reception of the software by the receiving unit and a progress of the transmission of the software by the transmitting unit.

[0011] According to this configuration, by using the software information (data) received by the user terminal, the progress status can be displayed and the communication load can be reduced.

[0012] (3) Preferably, in (2), the control unit may display information about the next operation of the first update process in addition to the progress of the first update process.

[0013] According to this configuration, in the software update process for the vehicle-mounted ECU, information about the next operation of the first update process is also displayed, which makes it possible to smoothly proceed with the software update process.

[0014] (4) Preferably, in (1) to (3), when the vehicle receives software without going through a user terminal and a second update process is being executed to update the software of the on-board ECU, the control unit does not display the progress of the second update process even if there is a request to display the progress of the second update process.

[0015] According to this configuration, when software for the in-vehicle ECU is distributed to the vehicle without going through the user terminal and a second update process is being executed to update the software of the in-vehicle ECU using this software, the control unit of the user terminal does not display the progress status of the second update process even if there is a request to display the progress status of the second update process. Therefore, the user terminal does not need to acquire information (data) necessary to display the progress status of the second update process via communication or the like, thereby reducing the communication load.

[0016] (5) A software update system disclosed herein includes a server that distributes software, a vehicle equipped with an ECU and capable of communicating with the server, and a user terminal that can communicate with the server and the vehicle, and is a software update system that updates the software of the ECU. In the software update system, the user terminal displays the progress of a first update process in which the software distributed from the server is distributed to the vehicle via the user terminal and updates the software of the ECU. On the other hand, the user terminal does not display the progress of a second update process in which the software distributed from the server is distributed to the vehicle without passing through the user terminal and updates the software of the ECU.

[0017] According to this configuration, the server functions as an OTA center that distributes software. The software is distributed to the vehicle from the server through communication with the server without going through the user terminal. The software distributed from the server is also distributed to the vehicle via the user terminal. The user terminal displays the progress of a first update process in which the software distributed from the server is distributed to the vehicle via the user terminal and updates the ECU software, but does not display the progress of a second update process in which the software distributed from the server is distributed to the vehicle without going through the user terminal and updates the ECU software.

[0018] The user terminal does not need to acquire information (data) necessary to display the progress of the second update process via communication, etc., which reduces the communication load. Furthermore, since the information (data) necessary for the first update process is delivered to the vehicle via the user terminal, data already received by the user terminal can be used when displaying the progress of the first update process, which reduces the communication load.

[0019] (6) Preferably, in (5), the progress of the first update process includes a progress of receiving the software at the user terminal and a progress of transmitting the software from the user terminal to the vehicle in front.

[0020] According to this configuration, by using information (data) of the software distributed to the user terminal, it is possible to display the progress status and reduce the communication load.

[0021] (7) Preferably, in (6), the user terminal displays information about the next operation of the first update process in addition to the progress of the first update process.

[0022] According to this configuration, in the software update process for the vehicle-mounted ECU, information regarding the next operation of the first update process is displayed, which makes it possible to smoothly proceed with the software update process.

[0023] (8) The control method disclosed herein is a control method that receives software distributed from a server, transmits the received software to a vehicle, and displays the progress of a software update process on a user terminal that updates the software of an on-board ECU. The control method includes the steps of: determining whether or not the update process will be executed using the software transmitted to the vehicle via the user terminal; and, when it is determined that the update process will be executed using the software transmitted to the vehicle via the user terminal, displaying the progress of the update process.

[0024] According to this method, the user terminal receives software distributed from the server and transmits the received software to the vehicle, thereby updating the software of the vehicle's ECU. When it is determined that the software update process is to be performed using the software transmitted to the vehicle via the user terminal, the user terminal displays the progress of the update process. By utilizing information (data) about the software distributed to the user terminal, the progress can be displayed, thereby reducing the communication load.

[0025] (9) The program disclosed herein is a program that causes a computer to execute the control method of (8).

[0026] By using this program, the progress status can be displayed by utilizing the software information (data) distributed to the user terminal, thereby reducing the communication load. [Effects of the Invention]

[0027] According to the present disclosure, it is possible to reduce the communication load when notifying the progress of the software update process of an in-vehicle ECU. [Brief explanation of the drawings]

[0028] [Figure 1] 1 is a diagram illustrating a configuration of a software update system according to an embodiment of the present disclosure. [Figure 2] 1 is a diagram for explaining an overview of a software update method according to an embodiment of the present invention; [Figure 3] FIG. 2 is a diagram illustrating an example of functional blocks configured in a user terminal. [Figure 4] FIG. 10 is a diagram showing an example of a software reception status displayed on the touch panel display. [Figure 5] FIG. 10 is a diagram illustrating an example of a software transfer status displayed on the touch panel display. [Figure 6] 10A and 10B are diagrams illustrating an example of a software reception status and a software transfer status displayed on a touch panel display. [Figure 7] FIG. 10 is a diagram showing an example of a guidance display displayed on a touch panel display. [Figure 8] FIG. 10 is a diagram illustrating an example of a confirmation display displayed on a touch panel display. [Figure 9] 10 is a flowchart illustrating an example of a display process according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0029] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present disclosure will be described in detail with reference to the accompanying drawings. In the drawings, the same or corresponding parts are designated by the same reference numerals and their description will not be repeated.

[0030] Fig. 1 is a diagram showing the configuration of a software update system according to this embodiment. Referring to Fig. 1, this software update system includes a vehicle 100, a vehicle 200, user terminals 300 and 300a, and an OTA center 500. Note that "OTA" is an abbreviation for "Over The Air."

[0031] Each of the vehicles 100 and 200 is, for example, an electric vehicle (BEV: Battery Electric Vehicle) that does not have an internal combustion engine. The vehicle 100 has an OTA access function (a function for directly communicating wirelessly with the OTA center 500), but the vehicle 200 does not have the OTA access function. The vehicle 100 can communicate wirelessly directly with the OTA center 500, but the vehicle 200 cannot communicate with the OTA center 500 unless it goes through another communication device (i.e., a communication device other than the communication device provided in the vehicle 200 itself). The vehicle 200 communicates wirelessly with the OTA center 500 via the user terminal 300 (via the user terminal 300). In addition to directly communicating wirelessly with the OTA center 500, the vehicle 100 is also capable of communicating wirelessly with the OTA center 500 via the user terminal 300a.

[0032] Since the user terminal 300 and the user terminal 300a have the same configuration, the following description will focus on the user terminal 300. The user terminal 300 is configured to be portable by the user. The user terminal 300 is a mobile terminal carried and operated by the user (vehicle manager) of the vehicle 200. In this embodiment, a smartphone equipped with a touch panel display is used as the user terminal 300. A smartphone has a built-in computer and a speaker function. However, the user terminal 300 is not limited to this, and any terminal portable by the user of the vehicle 200 can be used as the user terminal 300. For example, a laptop, a tablet terminal, a portable game console, a wearable device (smartwatch, smart glasses, smart gloves, etc.), etc. can also be used as the user terminal 300.

[0033] The user terminal 300 includes a processor 310, a memory 320, and a communication module 330. The processor 310 includes, for example, a CPU (Central Processing Unit). The memory 320 includes, for example, a non-volatile memory such as a flash memory. The communication module 330 includes a communication I / F (interface) for directly communicating wirelessly with the OTA center 500. The communication module 330 also includes a communication I / F for directly communicating wirelessly with the vehicle 200. This enables data exchange between the vehicle 200 and the OTA center 500 via the user terminal 300. For example, in response to a request from the vehicle 200, the user terminal 300 specifies the address of the OTA center 500 and accesses the communication network NW, thereby enabling data exchange (communication) between the vehicle 200 (ECU 210) and the OTA center 500 via the user terminal 300.

[0034] Application software (hereinafter referred to as a "mobile app") for using services provided by the OTA center 500 is installed in the user terminal 300. The mobile app associates the identification information (terminal ID) of the user terminal 300 with the identification information (vehicle ID) of the vehicle 200 and registers it in the OTA center 500. Furthermore, the user terminal 300 can exchange information with the OTA center 500 via the mobile app.

[0035] The user terminal 300a is a mobile terminal carried and operated by the user of the vehicle 100. Identification information (terminal ID) of the user terminal 300a is linked to identification information (vehicle ID) of the vehicle 100 and registered in the OTA center 500, and the user terminal 300a can exchange information with the OTA center 500 through a mobile app. Each of the user terminals 300, 300a includes a touch panel display that functions as an input device and a display device.

[0036] The OTA center 500 is a server that provides a vehicle software update service using OTA technology. The OTA center 500 is configured to perform remote updates of vehicle ECU software from the center via a communication section. The OTA center 500 distributes software for the vehicle ECU. "ECU" stands for Electronic Control Unit.

[0037] The OTA center 500 includes a processor 510, a memory 520, and a communication module 530. The processor 510 includes, for example, a CPU. The memory 520 includes, for example, a non-volatile memory such as a flash memory. The communication module 530 is connected to a communication network NW by wire and communicates with each of a plurality of vehicles (including the vehicle 100) and a plurality of mobile terminals (including the user terminal 300) via the communication network NW. The communication network NW is, for example, a wide area network constructed by the Internet and wireless base stations. The communication network NW may also include a mobile phone network.

[0038] Vehicle 100 includes OTA master 110 and multiple ECUs (including ECUs 121 and 122). Vehicle 200 includes multiple ECUs (including ECUs 210, 221, and 222). OTA master 110 includes a built-in computer and functions as an on-board diagnostic device. Each vehicle may include any number of ECUs. Each on-board ECU includes a built-in computer that includes at least one processor and at least one memory. Each on-board ECU may include multiple microcomputers (microcomputers) in the form of a main microcomputer and a sub-microcomputer.

[0039] In vehicle 100, OTA master 110 and each ECU are connected via a communication bus, and are configured to be able to communicate with each other via wired communication. In vehicle 200, ECUs are connected via a communication bus, and are configured to be able to communicate with each other via wired communication. The communication method between the control devices in each vehicle is not particularly limited, and may be, for example, CAN (Controller Area Network) or Ethernet (registered trademark).

[0040] The OTA master 110 includes a processor 111, a memory 112, and a communication module 113. The processor 111 includes, for example, a CPU. The memory 112 includes, for example, a non-volatile memory such as a flash memory. The communication module 113 includes a communication I / F (interface) for directly performing wireless communication with the OTA center 500. For example, the communication module 113 specifies the address of the OTA center 500 and accesses the communication network NW, thereby establishing wireless communication between the vehicle 100 (communication module 113) and the OTA center 500. The communication module 113 may include a TCU (Telematics Control Unit) and / or DCM (Data Communication Module) that perform wireless communication.

[0041] In the vehicle 200, the ECU 210 includes a processor 211 and a memory 212. The processor 211 includes, for example, a CPU. The memory 212 includes, for example, a non-volatile memory such as a flash memory. The vehicle 200 further includes a communication device 290. The ECU 210 communicates with devices outside the vehicle through the communication device 290. The communication device 290 includes a communication I / F (interface) for direct wireless communication with the user terminal 300. The communication device 290 and the user terminal 300 may perform short-range communication such as a wireless local area network (LAN), near field communication (NFC), or Bluetooth (registered trademark). The communication device 290 may directly communicate with the user terminal 300 located inside or within the vicinity of the vehicle. While the vehicle 200 is stopped, the user terminal 300 inside or outside the vehicle and the ECU 210 may exchange information with each other via the communication device 290. Furthermore, while the vehicle 200 is traveling, the user terminal 300 inside the vehicle and the ECU 210 may exchange information with each other via the communication device 290. The ECU 210 can communicate with the OTA center 500 via the user terminal 300 by requesting the user terminal 300 to communicate with the OTA center 500 as described above.

[0042] In the vehicle 100, the OTA master 110 is capable of communicating with the user terminal 300a through the communication device 190 in addition to the communication module 113. The communication device 190 includes a communication I / F (interface) for direct wireless communication with the user terminal 300a. The communication device 190 and the user terminal 300a may perform short-range communication using a technique such as wireless LAN, NFC, or Bluetooth (registered trademark). The communication device 190 may also directly communicate with the user terminal 300a located inside the vehicle or within a range surrounding the vehicle. While the vehicle 100 is stopped, the user terminal 300a located inside or outside the vehicle and the OTA master 110 may exchange information with each other via the communication device 190. Furthermore, while the vehicle 100 is traveling, the user terminal 300a located inside the vehicle and the OTA master 110 may exchange information with each other via the communication device 190. The OTA master 110 can communicate with the OTA center 500 via the user terminal 300a by requesting the user terminal 300a to communicate with the OTA center 500 as described above.

[0043] As described above, the OTA master 110 of the vehicle 100 and the ECU 210 of the vehicle 200 are each configured to be able to wirelessly communicate with the OTA center 500. Each of the vehicles 100 and 200 can communicate with the OTA center 500 whether the vehicle is stopped or moving. The OTA master 110 and the ECU 210 each manage in-vehicle information, receive campaigns, and manage software update sequences. Hereinafter, when there is no need to distinguish between the OTA master 110 and the ECU 210, they will be referred to as "update masters." The OTA master 110 corresponds to the update master of the vehicle 100, and the ECU 210 corresponds to the update master of the vehicle 200.

[0044] Each of the vehicles 100, 200 is an autonomous vehicle configured to be capable of autonomous driving. Each of the vehicles 100, 200 is configured to be capable of both manned and unmanned driving. Each of the vehicles 100, 200 is configured to be capable of autonomous driving without a driver, but can also be driven manually by a user (manned driving). Each of the vehicles 100, 200 can also perform autonomous driving (e.g., auto cruise control) while manned. The level of autonomous driving may be fully autonomous (level 5) or conditional autonomous driving (e.g., level 4).

[0045] Vehicles 100 and 200 are respectively equipped with driving devices 130 and 230 and ADS (Autonomous Driving Systems) 140 and 240. In vehicle 100, ECU 121 is configured to control driving device 130. In vehicle 200, ECU 221 is configured to control driving device 230.

[0046] Each of the driving devices 130, 230 includes an accelerator, a brake, and a steering device. The accelerator includes, for example, a motor generator (hereinafter referred to as "MG") that rotates the drive wheels of the vehicle, a PCU (Power Control Unit) that drives the MG, and a battery that supplies the PCU with power to drive the MG.

[0047] Each of the ADSs 140, 240 includes a recognition sensor (e.g., at least one of a camera, millimeter-wave radar, and LIDAR) that recognizes the external environment of the vehicle, and executes processing related to autonomous driving based on information sequentially acquired by the recognition sensor. The ADSs 140, 240 cooperate with the ECUs 121, 221, respectively, to generate a driving plan (information indicating future vehicle behavior) according to the external environment of the vehicle. The ADSs 140, 240 then request the ECUs 121, 221, respectively, to control various actuators included in the driving devices 130, 230 so as to drive the vehicles 100, 200 according to the driving plan.

[0048] The vehicles 100 and 200 are equipped with start switches 150 and 250 and HMIs 170 and 270, respectively.

[0049] Each of the activation switches 150, 250 is a switch that allows a user to activate a vehicle system (a control system of the vehicle 100, 200), and is installed, for example, inside the vehicle cabin. The activation switch is generally called a "power switch" or an "ignition switch." The user operates the activation switch 150, 250 to switch the vehicle system (including each ECU mounted on the vehicle) on (operating) or off (stopped). Turning the activation switch 150, 250 on activates a vehicle system that is in a stopped state, and the vehicle system enters an operating state (hereinafter also referred to as "IG on"). Turning the activation switch 150, 250 off while the vehicle system is operating switches the vehicle system to a stopped state (hereinafter also referred to as "IG off").

[0050] The ON operation of the start switches 150, 250 is an operation for switching the vehicle state from IG OFF to IG ON. When the user turns on the start switches 150, 250, a startup request is input to each on-board ECU. That is, each on-board ECU accepts the startup request from the user. On the other hand, the OFF operation of the start switches 150, 250 is an operation for switching the vehicle state from IG ON to IG OFF. When the user turns off the start switches 150, 250, a shutdown request is input to each on-board ECU. That is, each on-board ECU accepts the shutdown request from the user. However, the OFF operation of the start switches 150, 250 is prohibited when the vehicle is running.

[0051] Each of the HMIs 170 and 270 includes an input device and a display device. Each of the HMIs 170 and 270 may include a touch panel display that functions as the input device and the display device. Each of the HMIs 170 and 270 may include the input device and the display device of a car navigation system.

[0052] FIG. 2 is a diagram for explaining an overview of a software update method according to this embodiment. Referring to FIG. 2 together with FIG. 1, the processing related to a software update (more specifically, updating vehicle software using OTA) is performed in the following order: configuration synchronization, campaign notification and application acceptance, download, installation, activation, and software update completion notification. The processing described below is performed by the OTA center 500 and each vehicle (including vehicles 100 and 200) that receives software distribution from the OTA center 500. The number of vehicles that receive distribution from the OTA center 500 may be around 50, or may be between 100 and 1000, or may be 1000 or more.

[0053] A vehicle in the IG-on state repeatedly performs configuration synchronization every time a preset time has elapsed. A vehicle in the IG-on state also performs configuration synchronization when a configuration synchronization request is received from the OTA center 500. The configuration synchronization process by the vehicle includes transmitting vehicle configuration information to the OTA center 500. The vehicle configuration information includes, for example, hardware information (information indicating the hardware model number, ECU identifier, etc.) and software information (information indicating the software model number, etc.) for each ECU included in the vehicle.

[0054] When the OTA center 500 receives the vehicle configuration information from the vehicle, it checks for currently occurring campaigns (software updates). If a campaign applicable to the vehicle exists, the OTA center 500 transmits an consent request signal to the vehicle user requesting consent to the download of new software (software updates) related to the campaign. The consent request signal includes information about the campaign (campaign information). The campaign information may include at least one of campaign attribute information (information indicating the purpose of the software update and vehicle functions that may be affected by the update), a list of campaign-target vehicles, information about campaign-target ECUs (e.g., software information before and after the update), and information about notifications to the user before and after the update. Note that the campaign to be notified may be a newly occurring campaign or a campaign that has not been applied before. Hereinafter, the transmission of the consent request signal is also referred to as a "campaign notification."

[0055] When the vehicle receives the campaign notification (acceptance request signal), it prompts the user to input whether or not to accept the application of the campaign. For example, the vehicle may display a message such as "New software has been found. Do you want to apply it to this vehicle?" on the in-vehicle HMI (HMI 170, 270) or the user terminal 300, 300a, and request the user to input either "accept" or "reject." If the user inputs "accept," the vehicle executes the download process described below. On the other hand, if the user inputs "reject," the vehicle does not execute the download process. In this case, the OTA center 500 terminates the software update process without proceeding to the download phase.

[0056] In this embodiment, the OTA center 500 and the vehicle update master (for example, the OTA master 110 or the ECU 210) execute the process related to downloading in the procedure described below.

[0057] The vehicle's update master requests a distribution package including new software from the OTA center 500. The update master then downloads (receives and stores) the distribution package from the OTA center 500. In addition to the new software (for example, a set of update data for each ECU that is the target of the campaign), the distribution package may also include package attribute information (information indicating the update category, the number of update data in the distribution package, the installation order for each ECU, etc.) and update data attribute information (such as an identifier for the target ECU and verification data for verifying the validity of the update data). The target ECU is the ECU that is the target of a software update. For example, the target ECU may be ECU 121 or 221, and the software to be updated may be an autonomous driving control program.

[0058] Through the above-described download process, the distribution package is stored in a storage device (for example, memory 112 or 212) provided in the update master. After the download is complete, the update master verifies the authenticity of the downloaded distribution package. If the verification result is "normal," the update master notifies the OTA center 500 of the software update status (download complete). This notification means that the download was successful.

[0059] If the download is successful, the vehicle performs the installation. The update master requests at least one target ECU (for example, ECU 121 or 221) to output the target ECU's status and DTC (Diagnostic Trouble Code). The update master determines whether installation can be performed for each target ECU based on the target ECU's status and DTC. The update master then transfers the new software (update data) to target ECUs that can be installed. Upon receiving the update data, the target ECU installs the update data (writes it to non-volatile memory).

[0060] When the transfer of the update data from the update master to the target ECU is complete, the target ECU sends a transfer completion notification to the update master. Then, upon receiving the transfer completion notification, the update master requests the target ECU to perform integrity verification. Upon receiving this request, the target ECU performs verification using integrity verification data (verification data) and sends the verification results to the update master. The update master stores the verification results (installation completed / failed / cancelled) for each target ECU. When integrity verification for all target ECUs is complete and all verification results are "normal," the update master notifies the OTA center 500 of the software update status (installation completed). This notification means that the installation was successful.

[0061] If the download and installation are successful, the vehicle enters a state waiting for activation. When the vehicle's activation switch (e.g., activation switch 150 or 250) is then turned off, the update master displays a predetermined message on the in-vehicle HMI or user terminal 300, 300a, requesting the user to input either "accept" or "reject." If the user inputs "accept," the update master activates the installed software. If the update master fails to activate the software, the update master requests the OTA center 500 to roll back the software. Upon receiving a rollback request from the vehicle, the OTA center 500 distributes rollback software to the vehicle. The update master can then use the rollback software to revert (roll back) the software that failed to be activated to its original version. If the user inputs "reject," the update master cancels the software update process without executing the activation, and the vehicle system is shut down.

[0062] If the update master is successfully activated, the update master displays the results of the software update on the in-vehicle HMI or the user terminal 300, 300a. The update master then notifies the OTA center 500 of the software update status (software update complete). This notification means that the OTA software update was successful. When this notification is made, the vehicle's control system is shut down and the IG is turned off. After that, when the vehicle's start switch is turned on, the vehicle system is turned on. This causes the update program (new version of software) to start in the target ECU. Note that the software to be updated is not limited to a driving assistance control program such as the above-mentioned autonomous driving control program, and can be any program.

[0063] In this way, when a distribution package (software) is downloaded and the software of the target ECU is updated, it is preferable to display the progress of the software update process to the user. When software (distribution package) distributed from the OTA center 500 is downloaded via an in-vehicle communication device (OTA master 110 (communication module 113)), or when software distributed from the OTA center 500 is downloaded via the user terminal 300, 300a, there is a concern that displaying the progress on both the in-vehicle HMI and the user terminal 300, 300a may increase communication load and power consumption. In this embodiment, when software is downloaded via the user terminal 300, 300a, the progress of the update process is displayed on the user terminal 300, 300a, thereby suppressing increases in communication load and power consumption.

[0064] 3 is a diagram showing an example of functional blocks configured in the user terminals 300 and 300a. These functional blocks are functions configured by a processor, a memory, a communication module, and the like.

[0065] When the receiving unit 31 receives a campaign notification from the OTA center 500, the control unit 35 displays "Accept" or "Reject" on the touch panel display 340. When the user selects (operates) "Accept," the transmitting unit 34 requests the OTA center 500 to distribute software (distribution package) in accordance with instructions from the vehicle's update master.

[0066] The receiving unit 31 receives the software transmitted from the OTA center 500 and stores the received software in the storage unit 32, whereupon the software is downloaded. When the software download begins, the control unit 35 displays the software reception status (download status) on the touch panel display 340 of the user terminal 300, 300a. FIG. 4 is a diagram showing an example of the software reception status displayed on the touch panel display 340. As shown in FIG. 4, the software reception status may display, for example, "Software downloading in progress," along with a "Percentage (%) of software downloaded to the storage unit 32" 341 and a "Time (minutes) remaining until download completion" 342. The software (distribution package) distributed from the OTA center 500 includes information on the number of bytes (number of packets) of the software. The control unit 35 uses this information and the communication speed (bps) between the OTA center 500 and the user terminal 300, 300a to calculate and display the "Percentage (%) of software downloaded" 341 and the "Time (minutes) remaining until download completion" 342.

[0067] When the download (storage) of the software to the storage unit 32 is completed, the control unit 35 transmits (transfers) the downloaded software from the transmission unit 34 to the vehicle's update master (OTA master 110 or ECU 210). When the software transfer (transmission) starts, the control unit 35 displays the software transmission status (transfer status) on the touch panel display 340 of the user terminal 300, 300a. FIG. 5 is a diagram showing an example of the software transfer status displayed on the touch panel display 340. As shown in FIG. 5, the software transfer status may display, for example, "Software transfer in progress," along with a "Percentage (%) of software transferred (sent) to the update master" 343 and a "Time (minutes) remaining until transfer completion" 344. The control unit 35 calculates and displays the "Percentage (%) of software transferred" 343 and the "Time (minutes) remaining until transfer completion" 344 using the number of bytes (number of packets) of the software to be transferred and the communication speeds (bps) of the communication devices 190, 290 and the user terminal 300, 300a.

[0068] If the user terminal 300, 300a is configured to be able to transmit (transfer) software in parallel with receiving the software, the software reception status (download status) and transfer status are displayed on the touch panel display 340. Fig. 6 is a diagram showing an example of the software reception status and transfer status displayed on the touch panel display 340. The software reception status and transfer status are displayed simultaneously on the touch panel display 340, as shown in Fig. 6.

[0069] When the transfer (transmission) of the software from the user terminal 300, 300a is completed, the download of the software (distribution package) to the storage device included in the update master is completed. Then, as described above, the software (update data) is installed in the target ECU. When the installation in the target ECU is completed, an installation completion notification is transmitted from the update master or the OTA center 500. When the receiving unit 31 receives the installation completion notification, the control unit 35 displays a guidance display on the touch panel display 340. FIG. 7 is a diagram showing an example of a guidance display displayed on the touch panel display 340. As shown in FIG. 7, the "guidance display" 345 provides information such as "the installation has been completed," "the IG must be turned off (the start switch must be turned off) to activate the software (to update the software)," and "the time required to activate the software." By displaying such a "guidance display" 345, the user can be prompted to turn off the IG without leaving the vehicle with the IG on, thereby facilitating the update process.

[0070] In this embodiment, the user terminal 300, 300a and the communication device 190, 290 communicate via short-range communication such as Bluetooth (registered trademark). Therefore, communication between the user terminal 300, 300a and the communication device 190, 290 may be interrupted, for example, when the user terminal 300, 300a is taken out of the vehicle. In such a case, the control unit 35 displays a confirmation message on the touch panel display 340. FIG. 8 is a diagram showing an example of a confirmation message displayed on the touch panel display 340. As shown in FIG. 8, the "confirmation message" 346 provides guidance or confirmation regarding the following: "Since communication with the vehicle has been interrupted, return the user terminal to the vehicle" or "If communication is not restored, check the pairing between the vehicle and the user terminal." Displaying such a "confirmation message" 346 can guide the user to the next operation in the update process, thereby facilitating the update process.

[0071] 9 is a flowchart showing an example of display processing according to this embodiment. In this embodiment, this flowchart is processed by user terminal 300 or user terminal 300a, but part of the processing may be processed by OTA center 500, OTA master 110, or ECU 210. This processing is realized by one or more processors reading and executing a program stored in one or more memories.

[0072] This flowchart begins processing when: A) the icon of a mobile app displayed on the touch panel display 340 of the user terminal 300, 300a is tapped (for example, when the mobile app transitions from background processing to foreground processing); B) the user terminal 300 receives a campaign notification from the OTA center 500; or C) the user terminal 300a receives a notification (instruction) from the vehicle 100 (OTA master 110) to receive a campaign notification.

[0073] When processing is started by the operation of A) above, in step (hereinafter, step will be abbreviated as "S") 10, it is determined whether software distributed from the OTA center 500 is being downloaded via the user terminal 300, 300a when processing is started. If the software has not been received by the receiving unit 31, a negative determination is made and the current routine is terminated. If the software has been received by the receiving unit 31, a positive determination is made and the process proceeds to S11.

[0074] Furthermore, when the process is started by B) or C) above, in step 10, it is determined whether or not software distributed from the OTA center 500 is to be downloaded via the user terminal 300, 300a. When the process is started by B) above, the vehicle 200 downloads software via the user terminal 300, so a positive determination is made and the process proceeds to S11.

[0075] In the vehicle 100, it is possible to download software distributed from the OTA center 500 using the communication module 113 of the OTA master 110 (without going through the user terminal 300a), or to download software via the user terminal 300a. When the processing is started by C) above, this is because an instruction to download software via the user terminal 300a has been received from the vehicle 100, so a positive determination is made in S10 and the process proceeds to S11. Note that whether to download software using the communication module 113 in the vehicle 100 or via the user terminal 300a may be selected by the user, or the OTA master 110 may make the selection depending on the communication environment, etc.

[0076] In S11, when the receiving unit 31 starts receiving the software, the receiving status (downloading status) is displayed on the touch panel display 340. Also, when the transmitting unit 34 starts transferring (transmitting) the software, the transmitting status (transfer status) of the software is displayed on the touch panel display 340.

[0077] In the next step S12, it is determined whether communication between the user terminal 300a and the vehicle 100 (communication device 190) has been disconnected (or whether communication between the user terminal 300a and the vehicle 200 (communication device 290) has been disconnected). If communication between the user terminal and the vehicle has been disconnected, a positive determination is made and the process proceeds to S13. If communication between the user terminal and the vehicle has not been disconnected, a negative determination is made and the process proceeds to S14.

[0078] In S13, a "confirmation display" 346 is displayed on the touch panel display 340. In S14, it is determined whether the installation is complete. Until the receiving unit 31 receives an installation completion notification, a negative determination is made and the process returns to S11. Then, when the receiving unit 31 receives an installation completion notification, a positive determination is made in S14 and the process proceeds to S15.

[0079] In S15, a "Guide Display" 345 is displayed on the touch panel display 340, and then the current routine is terminated.

[0080] In the present embodiment, the process of downloading software via user terminal 300, 300a and updating the software of the target ECU (the process performed when a positive determination is made in S10) corresponds to an example of a "first update process" in the present disclosure. In the present embodiment, the process of downloading software and updating the software of the target ECU without going through user terminal 300, 300a (the process performed when a negative determination is made in S10 and the software of the target ECU is updated) corresponds to an example of a "second update process" in the present disclosure. In the present embodiment, "guidance display" 345 and "confirmation display" 346 correspond to examples of "information regarding the next operation of the first update process" in the present disclosure. Also, in the present embodiment, the process of S10 in FIG. 9 corresponds to an example of "a step of determining whether or not the update process is to be executed using software transmitted to the vehicle via the user terminal" in the present disclosure.

[0081] According to this embodiment, when an update process (first update process) is performed to update the software of a target ECU (on-board ECU) using software received by the receiving unit 31 of the user terminal 300, 300a, the progress of the update process (first update process) is displayed. Information (data) required for this update process (first update process) is delivered (transmitted) to the vehicle 100, 200 via the user terminal 300, 300a. Therefore, when displaying the progress of this update process (first update process), data already received by the user terminal 300, 300a can be used, thereby reducing the communication load. Furthermore, information regarding the next operation of this update process (first update process) ("guidance display" 345 or "confirmation display" 346) is displayed, which allows the software update process to proceed smoothly.

[0082] According to this embodiment, when software is transmitted to a vehicle without going through the user terminal 300, 300a and an update process (second update process) for updating the software of a target ECU (on-vehicle ECU) is being executed (negative determination in S10 of FIG. 9), even if there is a request to display the progress of this update process (second update process) (even if the process of the flowchart of FIG. 9 is started), the progress is not displayed. This eliminates the need for the user terminal 300, 300a to acquire information (data) necessary to display the progress of this process (second update process) via communication or the like, thereby reducing the communication load.

[0083] In the above, various information is displayed on the touch panel display 340, but the display is not limited to one having a touch panel function, and may be a device (such as a PC) that has an operation unit separate from the display.

[0084] It is not necessary for a vehicle to be configured to be capable of autonomous driving. The vehicle may be an xEV (electric vehicle) other than a BEV. The vehicle may be a PHEV (plug-in hybrid vehicle) or HEV (hybrid vehicle) equipped with an internal combustion engine (e.g., a gasoline engine, a biofuel engine, or a hydrogen engine). The vehicle is not limited to a four-wheeled passenger car, but may be a bus or truck, or a three-wheeled xEV. The vehicle may have a flight function. The vehicle may be a vehicle used in MaaS (Mobility as a Service). The vehicle may be a multi-purpose vehicle customized according to the user's purpose of use. The vehicle may be a mobile store vehicle, a robotaxi, an automated guided vehicle (AGV), or agricultural machinery. The vehicle may be an unmanned or single-seater small BEV (e.g., a BEV for last-mile travel, an electric wheelchair, or an electric skater).

[0085] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the description of the above embodiments, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0086] 31 receiving unit, 32 memory unit, 34 transmitting unit, 35 control unit, 110 OTA master, 121, 122, 210, 221, 222 ECU, 100, 200 vehicle, 111, 211, 310, 510 processor, 112, 212, 320, 520 memory, 113, 330, 530 communication module, 130, 230 driving device, 140, 240 ADS, 150, 250 start switch, 170, 270 HMI, 190, 290 communication device, 300, 300a user terminal, 340 touch panel display, 500 OTA center.

Claims

1. a receiving unit for receiving software of an in-vehicle ECU; a transmitting unit that transmits the received software to a vehicle, a control unit that, when a first update process is executed to update the software of the in-vehicle ECU using the software received by the receiving unit, displays a progress status of the first update process; The control unit determines whether the first update process will be executed using the software transmitted to the vehicle via the user terminal, and displays the progress of the first update process on the user terminal when it is determined that the first update process will be executed.

2. The user terminal according to claim 1 , wherein the progress status of the first update process includes a progress status of reception of the software by the receiving unit and a progress status of transmission of the software by the transmitting unit.

3. The user terminal according to claim 2 , wherein the control unit displays information regarding a next operation of the first update process in addition to the progress status of the first update process.

4. A user terminal as described in any one of claims 1 to 3, wherein when the vehicle receives the software without going through the user terminal and a second update process is being executed to update the software of the on-board ECU, the control unit does not display the progress of the second update process even if there is a request to display the progress of the second update process.

5. a server that distributes software; a vehicle equipped with an ECU and capable of communicating with the server; a user terminal capable of communicating with the server and the vehicle, the software update system updating software of the ECU, The user terminal the software distributed from the server is distributed to the vehicle via the user terminal, and a first update process for updating the software of the ECU is determined to be executed; and when it is determined that the first update process is to be executed, a progress status of the first update process is displayed; A software update system in which the software distributed from the server is distributed to the vehicle without passing through the user terminal, and the progress of a second update process that updates the software of the ECU is not displayed.

6. 6. The software update system of claim 5, wherein the progress of the first update process includes a progress of receiving the software at the user terminal and a progress of transmitting the software from the user terminal to the vehicle.

7. The software update system according to claim 6 , wherein the user terminal displays information regarding a next operation of the first update process in addition to the progress status of the first update process.

8. A control method for receiving software distributed from a server, transmitting the received software to a vehicle, and displaying a progress status of a software update process on a user terminal that updates software of an in-vehicle ECU, the method comprising: determining, in the user terminal, whether the update process is to be executed using the software transmitted to the vehicle via the user terminal; and when it is determined that the update process will be executed in the user terminal using the software transmitted to the vehicle via the user terminal, displaying the progress of the update process.

9. A program that causes a computer to execute the control method according to claim 8.

Citation Information

Patent Citations

  • Vehicle control system

    JP2017149323A