Server, software update system, software update method, and program

Abstract

To prevent a process related to software update not desired by a user from being executed due to an operation error, while securing sufficient convenience for the user in the software update.SOLUTION: A server is configured to: request a first terminal and a second terminal to make a reply as to whether to approve a process related to update of software for a control device mounted on a vehicle, the first terminal being a terminal mounted on the vehicle, and the second terminal being a terminal to be carried by a user of the vehicle; and when receiving replies from both first and second terminals as a response to the request, invalidate the reply from the second terminal and validate the reply from the first terminal.SELECTED DRAWING: Figure 4

Description

[Technical field]

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

[0002] Japanese Patent Laying-Open No. 2017-149323 (Patent Document 1) discloses a technology for updating software of a control device mounted on a vehicle by OTA (Over The Air). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2017-149323 A Summary of the Invention [Problem to be solved by the invention]

[0004] The server described in Patent Document 1 requests the smartphone to reply whether or not to accept the software update, and when it receives a reply of acceptance from the smartphone, downloads the new software (updated version of the software). The smartphone corresponds to a terminal that can be carried by the user of the vehicle (hereinafter, also referred to as a "portable terminal").

[0005] However, a mobile terminal is not necessarily the best HMI (Human Machine Interface) for making the reply. For example, when a user in a vehicle performs an operation for making the reply while driving the vehicle, there is a tendency for there to be fewer operational errors when operating a terminal mounted in the vehicle (hereinafter also referred to as an "in-vehicle terminal") than when operating a mobile terminal. If a process (e.g., download) related to a software update that the user does not want is executed based on an operational error, this significantly reduces the user's convenience. On the other hand, if the HMI for making the reply is limited to the in-vehicle terminal, the reply cannot be made by OTA when the user is not in the vehicle. This also leads to a decrease in user convenience.

[0006] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to prevent software update-related processing that the user does not want to execute due to erroneous operation, while ensuring sufficient user convenience in software updates. [Means for solving the problem]

[0007] According to an embodiment of a first aspect of the present disclosure, there is provided a server as described below. (Article 1) The server includes a request unit and a reception unit. The request unit is configured to request a reply as to whether or not to accept a process related to an update of software of a control device mounted on the vehicle from a first terminal mounted on the vehicle and a second terminal portable by the user of the vehicle. When replies are received from both the first terminal and the second terminal in response to the request, the reception unit is configured to invalidate the reply from the second terminal and validate the reply from the first terminal.

[0008] The server requests the in-vehicle terminal (first terminal) and the mobile terminal (second terminal) to reply whether or not to accept the process related to the software update of the control device mounted on the vehicle. Therefore, the user can select whether to use the in-vehicle terminal or the mobile terminal for the reply. This makes it easier to ensure sufficient user convenience. Furthermore, when the server receives replies to the request from both the in-vehicle terminal and the mobile terminal, it disables the reply from the mobile terminal and enables the reply from the in-vehicle terminal. When both the in-vehicle terminal and the mobile terminal reply, the reply from the mobile terminal is likely to be a reply based on an erroneous operation. Therefore, by disabling the reply from the mobile terminal and enabling the reply from the in-vehicle terminal, it is possible to prevent the execution of a process related to a software update that the user does not want due to an erroneous operation.

[0009] The server described in the above paragraph 1 may have the configuration described in any one of paragraphs 2 to 5 below.

[0010] (Clause 2) The server according to clause 1 further has the following feature: The reception unit is configured to determine a reception period during which replies to the request are received. If the reception unit receives replies from both the first terminal and the second terminal within the reception period, the reception unit determines whether or not to download the software based on the reply from the first terminal.

[0011] According to the above configuration, it is possible to prevent a download that the user does not want to perform due to an erroneous operation while ensuring sufficient user convenience in software updates. For example, if the user erroneously operates the mobile terminal, the user can invalidate the reply based on the erroneous operation by making a correct reply using the in-vehicle terminal within the acceptance period.

[0012] (Clause 3) The server described in clause 2 further has the following features: If the reception unit receives a reply from the first terminal within the reception period, the reception unit decides whether or not to download the software based on the reply from the first terminal, without waiting for the reception period to expire. If the reception unit receives a reply from the second terminal within the reception period and the reception period has expired without the reception unit receiving a reply from the first terminal, the reception unit decides whether or not to download the software based on the reply from the second terminal.

[0013] According to the above configuration, the time lag (response delay) between the reply from the first terminal and the start of downloading is reduced. Also, when the server receives a reply from the second terminal without receiving a reply from the first terminal, the server can determine whether or not to download the software based on the reply from the second terminal. This improves user convenience.

[0014] (4) The server according to the second or third aspect of the present invention further has the following feature: If the reception unit receives a reply from the second terminal located outside the vehicle within the reception period, the reception unit determines whether or not to download the software based on the reply from the second terminal without waiting for the reception period to elapse.

[0015] According to the above configuration, the time lag (response delay) between the reply from the second terminal and the start of downloading is small. When the second terminal that has sent the reply is outside the vehicle, the user is likely to be outside the vehicle, and the terminal mounted on the vehicle is unlikely to be operated.

[0016] (Clause 5) The server according to any one of clauses 2 to 4 further has the following features: The reception unit is configured to determine a reception period based on the contents of the software update. The reception unit is configured not to download the software if the reception period has elapsed without receiving a reply from either the first terminal or the second terminal.

[0017] According to the above configuration, if the acceptance period has elapsed without a reply, the software is not downloaded. This eliminates the need for the user to reply with a refusal. Furthermore, the server determines the acceptance period according to the contents of the software update, which makes it easier to set the acceptance period to an appropriate length. For example, in the case of a software update for which early updating is recommended, the server may lengthen the acceptance period to make it easier for the user to accept.

[0018] According to an embodiment of the second aspect of the present disclosure, there is provided a software updating system as described below.

[0019] (Article 6) The software update system includes a vehicle, a first terminal mounted on the vehicle, a second terminal portable by a user of the vehicle, and a server. The server is configured to request the first terminal and the second terminal to reply as to whether or not to accept a process related to an update of software of a control device mounted on the vehicle. Each of the first terminal and the second terminal is configured to prompt the user to perform an operation indicating either acceptance or rejection in response to the request. Each of the first terminal and the second terminal is configured to, when the user performs the operation, send a reply to the server according to the operation. When replies are received from both the first terminal and the second terminal, the server is configured to invalidate the reply from the second terminal and validate the reply from the first terminal.

[0020] In the above software update system, like the server described above, it is possible to prevent software update-related processing that the user does not want to execute due to erroneous operation while ensuring sufficient user convenience in software updates.

[0021] According to an embodiment of a third aspect of the present disclosure, there is provided a software updating method as described below.

[0022] (Section 7) The software update method includes requesting replies from a first terminal mounted in the vehicle and a second terminal portable by the user of the vehicle regarding whether or not to consent to a process related to an update of software of a control device mounted in the vehicle, and when replies are received from both the first terminal and the second terminal in response to the request, invalidating the reply from the second terminal and validating the reply from the first terminal.

[0023] In the above software update method, as in the case of the server described above, it is possible to prevent processing related to a software update that the user does not want to perform due to erroneous operation while ensuring sufficient user convenience in the software update.

[0024] According to another aspect, there is provided a program for causing a computer to execute the software update method according to claim 7. In one aspect, there is provided a computer device including a storage device that stores the program, and a processor that executes the program stored in the storage device. In another aspect, there is provided a computer device that distributes the program. Effect of the Invention

[0025] According to the present disclosure, in software updates, it is possible to prevent processes related to software updates that are not desired by the user from being executed due to erroneous operations while ensuring sufficient convenience for the user. [Brief description of the drawings]

[0026] [Figure 1] 1 is a diagram illustrating a configuration of a software update system according to an embodiment of the present disclosure. [Diagram 2] FIG. 1 is a diagram for explaining an overview of a software update method according to an embodiment of the present disclosure. [Diagram 3] 11 is a diagram for explaining a consent request in the software update method according to the embodiment of the present disclosure. FIG. [Figure 4]4 is a flowchart showing a processing procedure of a software updating method according to an embodiment of the present disclosure. [Diagram 5] FIG. 5 is a diagram illustrating a modified example of the process shown in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present disclosure will now be described in detail with reference to the accompanying drawings, in which the same or corresponding parts are designated by the same reference characters and will not be described repeatedly.

[0028] 1 is a diagram showing a configuration of a software update system according to this embodiment. With reference to FIG. 1, the software update system includes a vehicle 100, a mobile terminal 200, and an OTA center 500.

[0029] The vehicle 100 is, for example, an electric vehicle (BEV) that does not have an internal combustion engine. The vehicle 100 includes an OTA master 10, a plurality of ECUs (only the ECU 20 is shown), a start switch 50, a driving device 61, an ADS (Autonomous Driving System) 62, and an HMI (Human Machine Interface) 70. Each of the OTA master 10, the plurality of ECUs, the driving device 61, the ADS 62, and the HMI 70 receives power from a power source (for example, an on-board battery) that is not shown. "ECU" means an electronic control unit. "OTA" is an abbreviation for "Over The Air."

[0030] The start switch 50 is a switch that allows the user to start the vehicle system (the control system of the vehicle 100), and is installed, for example, in the passenger compartment of the vehicle 100. The start switch is generally called a "power switch" or an "ignition switch." The user operates the start switch 50 to switch the vehicle system on (operating) / off (stopped). When the start switch 50 is turned on, the vehicle system (including the OTA master 10 and the ECU 20) in a stopped state starts up, and the vehicle system goes into an operating state (hereinafter also referred to as "IG on"). When the start switch 50 is turned off while the vehicle system is operating, the vehicle system goes into a stopped state (hereinafter also referred to as "IG off").

[0031] The on operation of the start switch 50 is an operation for switching the state of the vehicle 100 from IG off to IG on. When the user turns on the start switch 50, a start request is input to the OTA master 10 and each of the multiple ECUs. That is, the OTA master 10 and each of the multiple ECUs accept the start request from the user. On the other hand, the off operation of the start switch 50 is an operation for switching the state of the vehicle 100 from IG on to IG off. When the user turns off the start switch 50, a shutdown request is input to the OTA master 10 and each of the multiple ECUs. That is, the OTA master 10 and each of the multiple ECUs accept the shutdown request from the user. However, the off operation of the start switch 50 is prohibited when the vehicle 100 is running.

[0032] The HMI 70 includes an input device and a display device. The HMI 70 may include a touch panel display that functions as an input device and a display device. The HMI 70 may include an information display or a ten-tail as a display device. The HMI 70 may include a steering switch as an input device. In addition, at least one of an IVI (In-Vehicle Infotainment) system, a meter panel, and a head-up display may function as the HMI 70.

[0033] 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 a remote vehicle ECU software update from the center via a communication section. The OTA master 10 manages in-vehicle information, receives campaigns, and manages a software update sequence. The OTA master 10 has a built-in computer and functions as an in-vehicle diagnostic device. The OTA master 10 controls each ECU having an OTA function. In the vehicle 100, the OTA master 10 and the ECU 20 each have an OTA function. Although not shown in FIG. 1, the vehicle 100 includes an ECU having an OTA function in addition to the ECU 20. The vehicle 100 may further include an ECU (not shown) that does not have an OTA function. The OTA master 10 and each ECU are connected via a communication bus and are configured to be able to communicate with each other via wired communication. The communication method is not particularly limited, and may be, for example, CAN (Controller Area Network) or Ethernet (registered trademark). Each ECU (such as ECU 20) mounted on vehicle 100 incorporates a computer having at least one processor and at least one memory. Each ECU may include multiple microcomputers (microcomputers) in the form of a main microcomputer and a sub-microcomputer. The number of ECUs included in vehicle 100 is arbitrary.

[0034] The vehicle 100 is an autonomous vehicle configured to be capable of autonomous driving. The vehicle 100 according to this embodiment is configured to be capable of both manned and unmanned driving. The vehicle 100 is configured to be capable of autonomous driving without a driver, but can also be driven manually by a user (manned driving). The vehicle 100 can also perform autonomous driving (e.g., auto cruise control) while being manned. The level of autonomous driving may be fully autonomous (level 5) or conditionally autonomous (e.g., level 4).

[0035] The ECU 20 is configured to control a driving device 61. The driving device 61 includes an accelerator device, a brake device, and a steering device. The accelerator device includes, for example, a motor generator (hereinafter, referred to as "MG") that rotates the drive wheels of the vehicle 100, a PCU (Power Control Unit) that drives the MG, and a battery that supplies the PCU with power to drive the MG. The MG functions as a driving motor for the vehicle 100. The brake device includes, for example, a braking device provided on each wheel of the vehicle 100, and an actuator that drives the braking device. The steering device includes, for example, an EPS (Electric Power Steering) and an actuator that drives the EPS.

[0036] The ADS 62 includes a recognition sensor (e.g., at least one of a camera, a millimeter wave radar, and a lidar) that recognizes the external environment of the vehicle 100, and executes processing related to autonomous driving based on information sequentially acquired by the recognition sensor. Specifically, the ADS 62 generates a driving plan (information indicating the future behavior of the vehicle 100) according to the external environment of the vehicle 100 in cooperation with the ECU 20. Then, the ADS 62 requests the ECU 20 to control various actuators included in the driving device 61 so as to drive the vehicle 100 according to the driving plan.

[0037] In this embodiment, the ADS 62 is built into the vehicle 100. However, the present invention is not limited to this, and the ADS 62 may be an autonomous driving kit that is detachable from the vehicle 100. A sensor unit (including a recognition sensor) of the autonomous driving kit may be attached to the rooftop of the vehicle 100.

[0038] The mobile terminal 200 is configured to be portable by the user of the vehicle 100. In this embodiment, a smartphone equipped with a touch panel display is adopted as the mobile terminal 200. The smartphone has a built-in computer. However, the present invention is not limited to this, and any terminal that can be carried by the user of the vehicle 100 can be adopted as the mobile terminal 200. For example, a laptop, a tablet terminal, a portable game console, a wearable device (such as a smart watch, smart glasses, or smart gloves), etc. can also be adopted as the mobile terminal 200.

[0039] In the mobile terminal 200, application software (hereinafter, referred to as a "mobile app") for using a service provided by the OTA center 500 is installed. By the mobile app, the identification information (terminal ID) of the mobile terminal 200 is associated with the identification information (vehicle ID) of the vehicle 100 and registered in the OTA center 500. The mobile terminal 200 can exchange information with the OTA center 500 through the mobile app. The mobile terminal 200 may function as an electronic key that remotely locks and unlocks the doors of the vehicle 100. The mobile terminal 200 may also play a role similar to that of the start switch 50. The mobile terminal 200 may remotely switch the state of the vehicle system (IG on / IG off) in response to an operation (on operation / off operation) from the user. With such a mobile terminal 200, the user can switch the state of the vehicle system even when outside the vehicle.

[0040] The OTA master 10, the mobile terminal 200, and the OTA center 500 each include a processor 110, 210, or 510, a memory 120, 220, or 520, and a communication module 130, 230, or 530. Each of the processors 110, 210, or 510 includes, for example, a CPU (Central Processing Unit). Each of the memories 120, 220, or 520 includes, for example, a non-volatile memory such as a flash memory.

[0041] The communication module 130 is configured to communicate with devices outside the vehicle. The communication module 130 may include a TCU (Telematics Control Unit) and / or a DCM (Data Communication Module) for wireless communication. Furthermore, the communication module 130 may include a communication I / F (Interface) for wired communication with devices outside the vehicle. The OTA master 10 may communicate with a scan tool (a dedicated tool for performing wired software updates) via a DLC (Data Link Connector) (not shown).

[0042] Each of the communication modules 130, 230 accesses the communication network NW by wireless communication. The communication module 530 is connected to the 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 mobile terminal 200) 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 include a mobile phone network. Each of the OTA master 10 and the mobile terminal 200 communicates with the OTA center 500 by wireless communication. The OTA master 10, the mobile terminal 200, and the OTA center 500 communicate with each other via the communication network NW.

[0043] Fig. 2 is a diagram for explaining an outline of a software update method according to this embodiment. With reference to Fig. 2 together with Fig. 1, processing related to software update (more specifically, vehicle software update using OTA) is performed in the following steps: configuration synchronization, campaign notification and application consent, download, installation, activation, and software update completion notification.

[0044] Vehicle 100 starts configuration synchronization when the vehicle system is turned on (for example, when start switch 50 or mobile terminal 200 is turned on). The configuration synchronization process by vehicle 100 includes transmitting vehicle configuration information to OTA center 500. The vehicle configuration information includes, for example, hardware information (information indicating hardware model numbers, ECU identifiers, etc.) and software information (information indicating software model numbers, etc.) for each ECU included in vehicle 100. The vehicle configuration information may further include an RXSWIN for each approval target. RXSWIN is an identification number capable of identifying software that constitutes functional type approval.

[0045] When the OTA center 500 receives the vehicle configuration information from the vehicle 100, it checks the campaign (software update) currently occurring. If there is a campaign applicable to the vehicle 100, the OTA center 500 transmits, in response to receiving the vehicle configuration information, an approval request signal to each of the OTA master 10 and the mobile terminal 200, requesting a reply as to whether or not to approve the download of new software (updated version of software) related to the campaign. The approval 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 the functions of the vehicle that may be affected by the update), a list of campaign target vehicles, information about the campaign target ECU (for example, software information before and after the update), and information about notifications to the user before and after the update. 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 approval request signal is also referred to as a "campaign notification".

[0046] 3 is a diagram for explaining a campaign notification (acceptance request) in the software update method according to this embodiment. In this embodiment, the OTA master 10 and the HMI 70 mounted on the vehicle 100 cooperate with each other to function as an example of a "first terminal (vehicle-mounted terminal)" according to the present disclosure.

[0047] 3, the OTA center 500 sends a campaign notification to each of the OTA master 10 and the mobile terminal 200. Upon receiving the campaign notification, each of the OTA master 10 and the mobile terminal 200 prompts the user to perform an operation indicating either acceptance or rejection of the campaign notification (acceptance request signal). Then, when the user performs the above operation, each of the OTA master 10 and the mobile terminal 200 sends a reply to the OTA center 500 according to the operation.

[0048] Specifically, when the OTA master 10 receives the campaign notification, the HMI 70 displays screen Sc1. When the mobile terminal 200 receives the campaign notification, the mobile terminal 200 (touch panel display) displays screen Sc2. Each of the screens Sc1 and Sc2 displays a message such as "New software has been found. Do you want to apply it to this car?" and prompts the user to perform an operation to indicate whether or not to accept the download of the new software.

[0049] The screens Sc1 and Sc2 each include an apply button M11 or M21 that accepts an operation of "accept", a confirmation button M12 or M22, and a non-apply button M13 or M23 that accepts an operation of "reject". When the apply button M11 is operated, the OTA master 10 sends a reply of "accept" to the OTA center 500. When the non-apply button M13 is operated, the OTA master 10 sends a reply of "reject" to the OTA center 500. Hereinafter, the operation of either the apply button M11 or the non-apply button M13 on the screen Sc1 is referred to as a "first operation". On the other hand, when the apply button M21 is operated on the screen Sc2, the mobile terminal 200 sends a reply of "accept" to the OTA center 500. When the non-apply button M23 is operated, the mobile terminal 200 sends a reply of "reject" to the OTA center 500. Hereinafter, operating either the Apply button M21 or the Non-Apply button M23 on the screen Sc2 is referred to as a “second operation.” Each of the first operation and the second operation indicates the user's intention (either accept or reject) regarding the campaign notification (acceptance request).

[0050] When the confirmation buttons M12 and M22 are operated before the above-mentioned first and second operations are performed, the HMI 70 and the mobile terminal 200 respectively display the contents of the campaign (at least a part of the campaign information). Therefore, the user can determine whether or not to accept the download of new software related to the campaign after understanding the contents of the campaign.

[0051] Although details will be described later, the OTA center 500 according to this embodiment transmits the above-mentioned consent request signal to each of the OTA master 10 and the mobile terminal 200, and then determines a period (hereinafter referred to as the "reception period") during which a reply to the consent request signal is received (see FIG. 4). Then, when the OTA center 500 receives a reply from only one of the OTA master 10 and the mobile terminal 200 within the reception period, the OTA center 500 validates the reply. When the OTA center 500 receives replies from both the OTA master 10 and the mobile terminal 200 within the reception period, the OTA center 500 invalidates the reply from the mobile terminal 200 (the reply based on the second operation) and validates the reply from the OTA master 10 (the reply based on the first operation). When the OTA center 500 receives a reply indicating "approval" (a valid reply) within the reception period, the process related to the software update transitions to the download phase. On the other hand, when the OTA center 500 does not receive a reply indicating "approval" (a valid reply) within the reception period, the process related to the software update ends without proceeding to the download phase.

[0052] 2 together with FIG. 1, the OTA center 500 and the vehicle 100 execute the process related to the download, for example, in the procedure described below. In the following, the terminal (the in-vehicle terminal or the mobile terminal 200) that has sent the valid reply indicating "approval" described above is referred to as the "approval terminal."

[0053] The OTA master 10 requests the OTA center 500 for a distribution package including new software. The OTA master 10 then downloads (receives and stores) the distribution package while wirelessly communicating with the OTA center 500. The distribution package may include package attribute information (information indicating the update category, the number of update data in the distribution package, the installation order of each ECU, etc.) and update data attribute information (identifier of the target ECU, verification data for verifying the validity of the update data, etc.) in addition to the new software (e.g., a set of update data for each ECU that is the target of the campaign). The target ECU is an ECU that is the target of a software update. For example, the target ECU may be the ECU 20, and the software to be updated may be an autonomous driving control program.

[0054] Through the above-mentioned download-related process, the distribution package is stored in a storage device (for example, memory 120) provided in the OTA master 10. During the download, the approval terminal notifies the user of the progress of the download. After the download is completed, the OTA master 10 verifies the authenticity of the downloaded distribution package. Then, if the result of the verification is "normal", the OTA master 10 notifies the OTA center 500 of the software update status (download completed). This notification means that the download was successful.

[0055] If the download is successful, the vehicle 100 executes the installation. Specifically, the OTA master 10 requests at least one target ECU (e.g., ECU 20) to output the state of the target ECU and a DTC (Diagnostic Trouble Code). The OTA master 10 judges whether or not installation can be executed for each target ECU based on the state of the target ECU and the DTC. Then, the OTA master 10 transfers the new software (update data) to the target ECUs that can execute the installation. The target ECU that receives the update data executes installation of the update data (writing it into non-volatile memory). During the installation, the approval terminal notifies the user of the progress of the installation.

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

[0057] If the download and installation are successful, the vehicle 100 enters a state of waiting for activation. Thereafter, when the start switch 50 or the mobile terminal 200 is turned off, the OTA master 10 displays a predetermined message on the approval terminal and requests the user to input either "approval" or "rejection." If the user inputs "approval" to the approval terminal, the OTA master 10 executes activation (enabling the installed software). On the other hand, if the user inputs "rejection" to the approval terminal, the OTA master 10 stops the process related to the software update without executing activation, and the vehicle system is shut down.

[0058] When the configuration check after the activation is completed is successful, the OTA master 10 causes the approval terminal to display the result of the software update. The approval terminal displays, for example, a software update completion screen indicating the success of the update. Thereafter, the OTA master 10 notifies the OTA center 500 of the software update status (software update completion). This notification means that the OTA software update is successful. When this notification is made, the control system of the vehicle 100 is shut down and the IG is turned off. Thereafter, when the start switch 50 or the mobile terminal 200 is turned on, the IG of the vehicle system is turned on. This causes the update program (a new version of software) to start up in the target ECU.

[0059] FIG. 4 is a flowchart showing the processing procedure of the software update method according to this embodiment. The processing shown in this flowchart is executed by the OTA center 500 when the configuration synchronization processing by the target vehicle is completed. The target vehicle is, for example, the vehicle 100 shown in FIG. 1. When the configuration synchronization processing by the target vehicle is completed, the OTA center 500 receives the above-mentioned vehicle configuration information from the target vehicle and starts a series of processing for the target vehicle shown in FIG. 4, which will be described below. In this embodiment, the OTA center 500 corresponds to an example of a "server" according to the present disclosure. In this embodiment, the processor 510 shown in FIG. 1 functions as an example of a "request unit" and a "reception unit" according to the present disclosure. The following flowchart is realized by one or more processors reading and executing a program stored in one or more memories. "S" in the flowchart means a step.

[0060] 1 to 3 and FIG 4, in S11, the OTA center 500 determines whether or not there is a campaign (new or unapplied software update) applicable to the target vehicle. If there is no campaign applicable to the target vehicle (NO in S11), the series of processes shown in FIG 4 ends.

[0061] If there is a campaign applicable to the target vehicle (YES in S11), the OTA center 500 transmits the above-mentioned consent request signal to each of the OTA master 10 and the mobile terminal 200 in the following S12. Then, the OTA center 500 determines the above-mentioned acceptance period (period for accepting a reply to the consent request signal) in S13. The OTA center 500 determines the acceptance period based on, for example, the contents of the campaign (contents of software update). More specifically, when the consent request signal requests consent to an update process of software for which early update is recommended (for example, software related to safety), the OTA center 500 makes the acceptance period longer than when the consent request signal requests consent to an update process of normal software (software with low urgency). This makes it easier for the user to consent. Alternatively, the OTA center 500 may determine the acceptance period based on the status of the target vehicle. For example, when the user is driving the target vehicle for parking (driving for parking), the OTA center 500 may extend the reception period so that the user can reply after completing the parking operation. However, the present invention is not limited to this, and the reception period may be a predetermined fixed period.

[0062] In the next step S14, the OTA center 500 judges whether the acceptance period determined in step S13 has elapsed. While the acceptance period has not elapsed (NO in step S14), the OTA center 500 accepts replies from the OTA master 10 and the mobile terminal 200. When the acceptance period has elapsed (YES in step S14), the OTA center 500 judges whether a reply to the consent request signal has been received within the acceptance period (S15). When the acceptance period has elapsed without the OTA center 500 receiving a reply from either the OTA master 10 or the mobile terminal 200 (NO in step S15), the OTA center 500 notifies each of the OTA master 10 and the mobile terminal 200 in step S22 that the software will not be downloaded, and then ends the series of processes shown in FIG. 4. In this case, the OTA center 500 does not download new software related to the campaign.

[0063] If the OTA center 500 receives a reply from at least one of the OTA master 10 and the mobile terminal 200 within the reception period (YES in S15), the OTA center 500 determines in S16 whether or not a reply (reply based on the first operation) has been received from the OTA master 10 within the reception period. If the OTA center 500 has not received a reply from the OTA master 10 within the reception period, NO is determined in S16, and the process proceeds to S19. A NO determination in S16 means that the OTA center 500 has received a reply only from the mobile terminal 200. In this case, the reply from the mobile terminal 200 becomes valid.

[0064] On the other hand, if the determination in S16 is YES, the OTA center 500 determines in S17 whether or not a reply (a reply based on the second operation) has been received from the mobile terminal 200 within the reception period. If the OTA center 500 has not received a reply from the mobile terminal 200 within the reception period, the determination in S17 is NO, and the process proceeds to S19. A determination of NO in S17 means that the OTA center 500 has received a reply only from the OTA master 10. In this case, the reply from the OTA master 10 becomes valid.

[0065] Furthermore, if both S16 and S17 are judged as YES, the OTA center 500 invalidates the reply from the mobile terminal 200 in S18 and validates the reply from the OTA master 10. Then, the process proceeds to S19. If both S16 and S17 are judged as YES, it means that the OTA center 500 has received replies from both the OTA master 10 and the mobile terminal 200.

[0066] In S19, the OTA center 500 determines whether or not to download new software related to the campaign based on the valid reply. If the valid reply indicates "rejection" (NO in S19), the process proceeds to the above-mentioned S22. In this case, the download is not performed. On the other hand, if the valid reply indicates "acceptance" (YES in S19), the OTA center 500 advances the process related to the software update to the download phase in S21. This starts the download of the new software related to the campaign. When the process of S21 is executed, the series of processes shown in FIG. 4 ends. The process after the start of the download has already been described (see FIG. 2).

[0067] As described above, the software update method according to this embodiment includes the process shown in Fig. 4. That is, the OTA center 500 (server) requests the OTA master 10 (first terminal) mounted on the vehicle 100 and the mobile terminal 200 (second terminal) portable by the user of the vehicle 100 to reply whether or not to accept the process (e.g., download) related to the software update of the ECU (controller) mounted on the vehicle 100 (S12). Furthermore, when the OTA center 500 receives replies from both the OTA master 10 and the mobile terminal 200 in response to the request (YES in both S16 and S17), it invalidates the reply from the mobile terminal 200 and validates the reply from the OTA master 10 (S18).

[0068] According to the above method, the user can select whether to use the in-vehicle terminal (HMI 70) of the vehicle 100 or the mobile terminal 200 for the reply. This makes it easier to ensure sufficient user convenience. Furthermore, when the OTA center 500 receives replies to the request from both the in-vehicle terminal (OTA master 10) of the vehicle 100 and the mobile terminal 200, it invalidates the reply from the mobile terminal 200 and validates the reply from the in-vehicle terminal. When both the in-vehicle terminal and the mobile terminal 200 reply, it is highly likely that the reply from the mobile terminal 200 is a reply based on an erroneous operation. Therefore, by invalidating the reply from the mobile terminal 200 and validating the reply from the in-vehicle terminal, it is possible to prevent a process related to a software update that the user does not want to perform due to an erroneous operation.

[0069] The process shown in Fig. 4 can be modified as appropriate. For example, the OTA center 500 may execute the process shown in Fig. 5 instead of the process shown in Fig. 4. Fig. 5 is a diagram showing a modified example of the process shown in Fig. 4.

[0070] 1 to 3, and FIG. 5, the OTA center 500 executes processes in S31 to S33 corresponding to S11 to S13 in FIG. 4, respectively. Thereafter, the OTA center 500 judges in S34 whether or not a reply (a reply based on the first operation) has been received from the OTA master 10 within the reception period, similar to S16 in FIG. 4. If NO is determined in S34, the OTA center 500 judges in S35 whether or not a reply (a reply based on the second operation) has been received from the mobile terminal 200 within the reception period, similar to S17 in FIG. 4. If NO is also determined in S35, the OTA center 500 judges in S371 whether or not the reception period determined in S33 has elapsed. If NO is also determined in S371, the process returns to S34. While NO is determined in all of S34, S35, and S371, S34, S35, and S371 are repeated.

[0071] If the acceptance period has elapsed without the OTA center 500 receiving a reply from either the OTA master 10 or the mobile terminal 200 (YES in S371), the OTA center 500 notifies each of the OTA master 10 and the mobile terminal 200 in S42 that the software will not be downloaded, and then terminates the series of processes shown in FIG. 5.

[0072] When the OTA center 500 receives a reply from the mobile terminal 200 within the reception period without receiving a reply from the OTA master 10 (YES in S35), the OTA center 500 judges in S36 whether or not the mobile terminal 200 is outside the vehicle 100. For example, the OTA center 500 may receive position information from each of the vehicle 100 and the mobile terminal 200, and judge whether or not the mobile terminal 200 is outside the vehicle 100 based on the position information. Alternatively, the OTA center 500 may receive a signal indicating whether or not the mobile terminal 200 is inside the vehicle 100 from the mobile terminal 200, and judge whether or not the mobile terminal 200 is outside the vehicle 100 based on the signal. When the mobile terminal 200 is outside the vehicle 100 (YES in S36), the process proceeds to S39. In this case, the reply from the mobile terminal 200 becomes valid.

[0073] If the mobile terminal 200 is not outside the vehicle 100 (NO in S36), the OTA center 500 determines in S372 whether the acceptance period determined in S33 has elapsed. If NO is determined in S372, the process returns to S34. On the other hand, if YES is determined in S372, the process proceeds to S39. In this case, the reply from the mobile terminal 200 becomes valid.

[0074] If the OTA center 500 receives a reply from the OTA master 10 within the reception period (YES in S34), the process proceeds to S38. In this case, the reply from the OTA master 10 becomes valid. If the OTA center 500 also receives a reply from the mobile terminal 200 within the reception period, the OTA center 500 invalidates the reply from the mobile terminal 200 in S38. After that, the process proceeds to S39.

[0075] In S39, the OTA center 500 determines whether or not to download new software related to the campaign based on the valid reply, similar to S19 in FIG. 4. If the valid reply indicates "rejection" (NO in S39), the process proceeds to S42 described above. In this case, the download is not performed. On the other hand, if the valid reply indicates "acceptance" (YES in S39), the OTA center 500 advances the process related to the software update to the download phase in S41. This starts the download of the new software related to the campaign. When the process of S41 is performed, the series of processes shown in FIG. 5 ends.

[0076] In the software update system according to the above modification, if the OTA center 500 receives a reply from the in-vehicle terminal (OTA master 10) of the vehicle 100 within the reception period (YES in S34), the OTA center 500 determines whether or not to download the software based on the reply from the in-vehicle terminal without waiting for the reception period to elapse (S39). This reduces the time lag (response delay) from the reply from the in-vehicle terminal of the vehicle 100 to the start of downloading. If the OTA center 500 receives a reply from the mobile terminal 200 within the reception period and the reception period has elapsed without the OTA center 500 receiving a reply from the in-vehicle terminal of the vehicle 100 (YES in S372), the OTA center 500 determines whether or not to download the software based on the reply from the mobile terminal 200 (S39). If the OTA center 500 receives a reply from the mobile terminal 200 located outside the vehicle 100 within the reception period (YES in S36), the OTA center 500 determines whether or not to download the software based on the reply from the mobile terminal 200 without waiting for the reception period to elapse (S39). This reduces the time lag (response delay) from the reply from the mobile terminal 200 to the start of downloading. If the mobile terminal 200 that sent the reply is outside the vehicle, it is highly likely that the user is outside the vehicle, and it is unlikely that the terminal (e.g., HMI 70) mounted on the vehicle 100 will be operated.

[0077] In the above embodiment, an on-premise server is adopted as the OTA center 500 (see FIG. 1). However, the present invention is not limited to this, and the functions of the OTA center 500 (e.g., functions related to software update) may be implemented on a cloud by cloud computing. That is, the OTA center 500 may be a cloud server. The software to be updated is not limited to a driving assistance control program such as the above-mentioned automatic driving control program, and is arbitrary. It is not essential that the vehicle is configured to be capable of automatic driving.

[0078] 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 may be a three-wheeled xEV. The on-board battery may be configured to be contact-chargeable, or may be configured to be contactlessly charged (wirelessly charged) while parked or running, or may be configured to be battery-replaceable. The vehicle may be equipped with a solar panel. The vehicle may be equipped with a flying function. The vehicle may be a MaaS (Mobility as a Service) vehicle. The MaaS vehicle is a vehicle managed by a MaaS operator. 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 an agricultural machine. The vehicle may be an unmanned or one-seater small BEV (e.g., a BEV for the last mile or an electric wheelchair).

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

[0080] 10 OTA master, 20 ECU, 50 start switch, 70 HMI, 100 vehicle, 110, 210, 510 processor, 120, 220, 520 memory, 130, 230, 530 communication module, 200 mobile terminal, 500 OTA center.

Claims

1. a request unit that requests a first terminal mounted on the vehicle and a second terminal that is portable by a user of the vehicle to reply as to whether or not a process related to a software update of a control device mounted on the vehicle is approved; a reception unit that, when receiving the replies from both the first terminal and the second terminal in response to the request, invalidates the reply from the second terminal and validates the reply from the first terminal; A server comprising:

2. The reception unit determines a reception period during which the reply to the request is received, 2. The server according to claim 1, wherein if the reception unit receives the replies from both the first terminal and the second terminal within the reception period, the reception unit decides whether or not to download the software based on the reply from the first terminal.

3. When the reception unit receives the reply from the first terminal within the reception period, the reception unit determines whether or not to download the software based on the reply from the first terminal without waiting for the reception period to elapse; 3. The server of claim 2, wherein if the reception unit receives the reply from the second terminal within the reception period and the reception period has elapsed without the reception unit receiving the reply from the first terminal, the reception unit decides whether or not to download the software based on the reply from the second terminal.

4. 4. The server according to claim 3, wherein, when the reception unit receives the reply from the second terminal located outside the vehicle within the reception period, the reception unit decides whether or not to download the software based on the reply from the second terminal without waiting for the reception period to elapse.

5. The acceptance unit determines the acceptance period based on the content of the software update, The server according to any one of claims 2 to 4, wherein the reception unit does not download the software if the reception period has elapsed without receiving the reply from either the first terminal or the second terminal.

6. Vehicles and A first terminal mounted on the vehicle; a second terminal portable by a user of the vehicle; A server; A software update system comprising: The server requests the first terminal and the second terminal to reply as to whether or not to accept a process related to a software update of a control device mounted in the vehicle; Each of the first terminal and the second terminal prompts a user to perform an operation indicating either acceptance or rejection of the request; When the operation is performed by the user, each of the first terminal and the second terminal transmits a reply corresponding to the operation to the server; A software updating system, wherein when the server receives the replies from both the first terminal and the second terminal, the server invalidates the reply from the second terminal and validates the reply from the first terminal.

7. Requesting a response as to whether or not to approve a process related to software update of a control device mounted in a vehicle from a first terminal mounted in the vehicle and a second terminal portable by a user of the vehicle; When the reply is received from both the first terminal and the second terminal in response to the request, invalidating the reply from the second terminal and validating the reply from the first terminal; A software update method comprising:

8. A program causing a computer to execute the software updating method according to claim 7.

Images