server

Abstract

To suppress hindering of driving of a vehicle by notification related to software update, while securing sufficient user's convenience, in the software update.SOLUTION: A server determines whether or not a vehicle is traveling on the basis of a position and / or vehicle speed of the vehicle. The server performs notification to request a user of a vehicle to accept processing related to update of software of a control device mounted on the vehicle. When it is determined that the vehicle is traveling, the server performs the notification on an on-vehicle terminal mounted on the vehicle. When it is determined that the vehicle is not traveling, the server performs the notification on a portable terminal portable by the user of the vehicle.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 Art

[0002] Japanese Unexamined Patent Application Publication No. 2017-149323 (Patent Document 1) discloses a technique for updating software of a control device mounted on a vehicle via OTA (Over The Air).

Prior Art Literature

Patent Literature

[0003]

Patent Document 1

Summary of the Invention

Problem to be Solved by the Invention

[0004] The server described in Patent Document 1 sends a notification requesting consent for software update to a smartphone, and when receiving a reply of consent from the smartphone, downloads new software (an updated version of software). The smartphone corresponds to a terminal portable by a user of a vehicle (hereinafter, also referred to as "portable terminal").

[0005] However, a mobile device is not always the best Human Machine Interface (HMI) to receive the above notifications. For example, if a smartphone receives the above notification while a user is driving a vehicle, the user may misunderstand the notification (request for consent) regarding the software update as a notification regarding another requirement (e.g., an urgent message). Such a misunderstanding may interfere with the user's driving. On the other hand, if the HMI that receives the above notifications is limited to a terminal installed in the vehicle (hereinafter also referred to as "in-vehicle terminal"), the user will not be able to receive the above notification (request for consent) regarding the software update when they are not in the vehicle, which will lead to a decrease in user convenience.

[0006] This disclosure was made to solve the above-mentioned problems, and its purpose is to ensure sufficient user convenience during software updates while suppressing the disruption of vehicle operation due to notifications regarding software updates. [Means for solving the problem]

[0007] In accordance with the form relating to the first aspect of this disclosure, the following servers are provided: (Paragraph 1) The server comprises a determination unit and a notification unit. The determination unit is configured to determine whether or not the vehicle is in operation. The notification unit is configured to notify the vehicle user requesting their consent to a process related to updating the software of the control device installed in the vehicle. If the determination unit determines that the vehicle is in operation, the notification unit makes the above notification to the in-vehicle terminal installed in the vehicle. If the determination unit determines that the vehicle is not in operation, the notification unit makes the above notification to a portable terminal that can be carried by the vehicle user.

[0008] The server described above sends the notification (notification requesting consent) to the in-vehicle terminal when the vehicle is in operation. Therefore, the user can understand that the notification is about a software update by checking the in-vehicle terminal that received the notification, without having to check their mobile device. This reduces the likelihood of the user being interrupted while driving. Examples of in-vehicle terminals include the instrument panel, navigation system, and head-up display. Furthermore, the server also sends the notification (notification requesting consent) to the mobile terminal when the vehicle is not in operation. This makes it easier to ensure sufficient user convenience.

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

[0010] (Paragraph 2) The server described in Paragraph 1 further has the following characteristics: If the determination unit determines that the vehicle is in operation, the notification unit will not send the above notification to the mobile terminal.

[0011] With the above configuration, the mobile device will not receive the above notification (notification of consent request) while the vehicle is in operation. Therefore, it is less likely that a user driving the vehicle will mistake a notification about a software update (consent request) for a notification about another requirement (for example, an urgent notification).

[0012] (Article 3) The server described in Article 1 or Article 2 further has the following characteristics: When the determination unit determines that the vehicle is not in operation, the notification unit sends the above notification not only to the mobile terminal but also to the in-vehicle terminal.

[0013] With the above configuration, when the vehicle is not in operation, the user can receive the above notification on both the in-vehicle terminal and the mobile terminal. This improves user convenience.

[0014] (Article 4) The server described in any one of paragraphs 1 to 3 further has the following characteristics: The determination unit determines that the vehicle is not in operation when the mobile terminal is located outside the vehicle.

[0015] The above configuration makes it easier and more accurate to determine whether or not the vehicle is in operation. Furthermore, when the vehicle is not in use, the mobile device can receive the above notification (request for consent).

[0016] In accordance with the form relating to the second aspect of this disclosure, the following software update system is provided:

[0017] (Clause 5) The software update system comprises an in-vehicle terminal installed in the vehicle, a portable terminal that can be carried by the vehicle user, and a server that notifies the vehicle user to request their consent to the process of updating the software of the control device installed in the vehicle. The server makes the above notification to the in-vehicle terminal when the vehicle is in operation. The server makes the above notification to the portable terminal when the vehicle is not in operation.

[0018] Similar to the server mentioned earlier, the above software update system also makes it possible to ensure sufficient user convenience during software updates while minimizing the disruption to vehicle operation caused by notifications regarding software updates.

[0019] (Article 6) The software update system described in Article 5 further has the following features: The server provides the above notification not only to the in-vehicle terminal but also to the mobile terminal when the vehicle is in operation. When the mobile terminal receives the above notification from the server while the vehicle is in operation, it notifies the vehicle user of the software update by voice.

[0020] According to the above configuration, when a mobile device receives the above notification (a notification requesting consent) while driving a vehicle, it will notify the user of the software update via voice. This makes it less likely for a driver to mistake a notification about a software update (a request for consent) for a notification about another matter (for example, an urgent notification).

[0021] (Item 7) The software update system according to Item 5 or Item 6 further has the following features. Each of the in-vehicle terminal and the mobile terminal, upon receiving the above notification from the server, performs display that prompts the vehicle user to perform an operation indicating either consent or rejection to the notification. Each of the in-vehicle terminal and the mobile terminal transmits a reply indicating consent to the server when an operation indicating consent is performed by the vehicle user.

[0022] According to the above configuration, the user can easily and appropriately transmit a reply indicating consent to the server.

[0023] According to an aspect of the third viewpoint of the present disclosure, the software update method described below is provided.

[0024] (Item 8) The software update method comprises: determining whether a vehicle is in operation; when it is determined that the vehicle is in operation, transmitting a notification requesting consent for processing related to updating software of a control device mounted on the vehicle to the in-vehicle terminal mounted on the vehicle; and when it is determined that the vehicle is not in operation, transmitting the above notification to a mobile terminal that is portable by the user of the vehicle.

[0025] With the above software update method, similarly to the server described above, it becomes possible to suppress interference with vehicle driving caused by notifications related to software update while ensuring sufficient user convenience in software update.

[0026] According to an aspect of another viewpoint, there is provided a program that causes a computer to execute the software update method according to Item 8. In one aspect, there is provided a computer device comprising a storage device that stores the above 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 above program. [[Advantageous Effects of Invention]]

[0027] According to this disclosure, it becomes possible to ensure sufficient user convenience during software updates while minimizing the disruption to vehicle operation caused by notifications regarding software updates. [Brief explanation of the drawing]

[0028] [Figure 1] This figure shows the configuration of the software update system according to the embodiment of this disclosure. [Figure 2] This is a diagram illustrating an overview of the software update method according to the embodiments of this disclosure. [Figure 3] This figure illustrates the consent request in the software update method according to the embodiment of this disclosure. [Figure 4] This flowchart shows the processing procedure for the software update method according to an embodiment of the present disclosure. [Figure 5] This figure shows a modified example of the process shown in Figure 4. [Modes for carrying out the invention]

[0029] Embodiments of this disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and their descriptions will not be repeated.

[0030] Figure 1 shows the configuration of the software update system according to this embodiment. Referring to Figure 1, this software update system includes a vehicle 100, a mobile terminal 200, and an OTA center 500.

[0031] Vehicle 100 is, for example, an electric vehicle (BEV) without an internal combustion engine. Vehicle 100 comprises an OTA master 10, multiple ECUs (only 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, multiple ECUs, driving device 61, ADS 62, and HMI 70 receives power from a power source (not shown) (for example, an on-board battery). "ECU" stands for Electronic Control Unit. "OTA" is an abbreviation for "Over The Air".

[0032] The start switch 50 is a switch used by 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. Generally, the start switch is called a "power switch" or "ignition switch". By operating the start switch 50, the user switches the vehicle system on (operating) / off (stopped). When the start switch 50 is turned on, the vehicle system (including the OTA master 10 and ECU 20) which is in a stopped state is started, and the vehicle system becomes operational (hereinafter also referred to as "IG on"). Also, when the vehicle system is operating, if the start switch 50 is turned off, the vehicle system becomes stopped (hereinafter also referred to as "IG off").

[0033] Turning the start switch 50 ON is an operation to switch the state of the vehicle 100 from IG OFF to IG ON. When the user turns the start switch 50 ON, 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, turning the start switch 50 OFF is an operation to switch the state of the vehicle 100 from IG ON to IG OFF. When the user turns the start switch 50 OFF, 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, turning the start switch 50 OFF is prohibited while the vehicle 100 is in motion.

[0034] The HMI70 includes input and display devices. The HMI70 may include a touch panel display that functions as both an input and display device. The HMI70 may include an information display or a tenttail as a display device. The HMI70 may include steering wheel switches as an input device. In addition, at least one of the IVI (In-Vehicle Infotainment) system, the instrument panel, and the head-up display may function as the HMI70.

[0035] The OTA Center 500 is a server that provides vehicle software update services using OTA technology. The OTA Center 500 is configured to perform remote in-vehicle ECU software updates via a communication section from the center. The OTA Master 10 manages in-vehicle information, receives campaigns, and manages the 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 that has OTA functionality. In vehicle 100, both the OTA Master 10 and the ECU 20 each have OTA functionality. Although not shown in Figure 1, vehicle 100 also has other ECUs with OTA functionality besides the ECU 20. Furthermore, vehicle 100 may also have ECUs (not shown) that do not have OTA functionality. The OTA Master 10 and each ECU are connected via a communication bus and are configured to communicate with each other via wired connections. The communication method is not particularly limited, but may be, for example, CAN (Controller Area Network) or Ethernet®. Each ECU (such as ECU20) mounted on vehicle 100 incorporates a computer comprising at least one processor and at least one memory. Each ECU may also contain multiple microcontrollers (microcomputers) in the form of a main microcontroller and sub-microcontrollers. The number of ECUs in vehicle 100 is arbitrary.

[0036] Vehicle 100 is an autonomous vehicle configured to be capable of autonomous driving. Vehicle 100 according to this embodiment is configured to be capable of both manned and unmanned driving. Although vehicle 100 is configured to be capable of autonomous driving without a driver, it can also be driven manually by a user (manned driving). In addition, vehicle 100 can perform autonomous driving (e.g., automatic cruise control) while being driven by a driver. The level of autonomous driving may be fully autonomous driving (level 5) or conditional autonomous driving (e.g., level 4).

[0037] The ECU 20 is configured to control the driving system 61. The driving system 61 includes an accelerator, a brake, and a steering system. The accelerator 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 power to the PCU to drive the MG. The MG functions as the driving motor of the vehicle 100. The brake system includes, for example, braking devices provided on each wheel of the vehicle 100 and actuators that drive the braking devices. The steering system includes, for example, an EPS (Electric Power Steering) and actuators that drive the EPS.

[0038] The ADS62 includes a recognition sensor (for example, at least one of a camera, millimeter-wave radar, and lidar) that recognizes the external environment of the vehicle 100, and performs processing related to autonomous driving based on information acquired sequentially by the recognition sensor. Specifically, the ADS62 works in cooperation with the ECU20 to generate a driving plan (information indicating the future behavior of the vehicle 100) according to the external environment of the vehicle 100. Then, the ADS62 requests the ECU20 to control various actuators included in the driving device 61 so that the vehicle 100 is driven according to that driving plan.

[0039] In this embodiment, the ADS62 is built into the vehicle 100. However, it is not limited to this, and the ADS62 may be an autonomous driving kit that can be attached to and removed from the vehicle 100. The sensor unit (including the recognition sensor) of the autonomous driving kit may be mounted on the rooftop of the vehicle 100.

[0040] 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 used as the mobile terminal 200. The smartphone has a built-in computer and a speaker function. However, it is not limited to this, and any device that can be carried by the user of the vehicle 100 can be used as the mobile terminal 200. For example, laptops, tablet devices, portable game consoles, and wearable devices (smartwatches, smart glasses, smart gloves, etc.) can also be used as the mobile terminal 200.

[0041] The mobile terminal 200 has application software (hereinafter referred to as "mobile app") installed for using services provided by the OTA center 500. The mobile app links the identification information of the mobile terminal 200 (terminal ID) with the identification information of the vehicle 100 (vehicle ID) and registers it with 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 also function as an electronic key for remotely locking and unlocking the doors of the vehicle 100. The mobile terminal 200 may also perform a similar role to the activation switch 50. The mobile terminal 200 may remotely switch the state of the vehicle system (IG on / IG off) in response to user operation (on operation / off operation). With such a mobile terminal 200, the user can switch the state of the vehicle system even when outside the vehicle.

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

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

[0044] Each of the communication modules 130 and 230 accesses the communication network NW wirelessly. The communication module 530 is connected to the communication network NW by wire and communicates with each of the multiple vehicles (including vehicle 100) and multiple mobile terminals (including mobile terminal 200) via the communication network NW. The communication network NW is a wide-area network constructed by, for example, the internet and wireless base stations. The communication network NW may also include a mobile phone network. Each of the OTA master 10 and mobile terminal 200 communicates with the OTA center 500 wirelessly. The OTA master 10, mobile terminal 200, and OTA center 500 communicate with each other via the communication network NW.

[0045] Figure 2 is a diagram illustrating the overview of the software update method according to this embodiment. Referring to Figure 2 together with Figure 1, the process related to software updates (more specifically, vehicle software updates using OTA) is carried out in steps such as configuration synchronization, campaign notification and acceptance of application, download, installation, activation, and software update completion notification.

[0046] A vehicle 100 with the ignition on repeatedly performs configuration synchronization at predetermined intervals (e.g., every hour). The configuration synchronization process by vehicle 100 includes transmitting vehicle configuration information to the OTA center 500. The vehicle configuration information includes, for example, hardware information (information indicating hardware part numbers, ECU identifiers, etc.) and software information (information indicating software part numbers, etc.) for each ECU included in vehicle 100. The vehicle configuration information may further include RXSWIN for each approved item. RXSWIN is an identification number that can identify the software constituting the functional type approval.

[0047] When the OTA center 500 receives the above vehicle configuration information from the vehicle 100, it checks for any currently active campaigns (software updates). If there is a campaign applicable to the vehicle 100, the OTA center 500 sends a consent request signal to the user of the vehicle 100, requesting their consent to download the new software (software update) related to that campaign. The consent request signal includes information about the campaign (campaign information). The campaign information may include, for example, campaign attribute information (information indicating the purpose of the software update and the vehicle functions that may be affected by the update), a list of campaign-targeted vehicles, information about campaign-targeted ECUs (e.g., software information before and after the update), and information about notifications to the user before and after the update. The campaign that is notified may be a newly occurring campaign or a campaign that was not previously applied. Hereafter, the transmission of the above consent request signal will also be referred to as a "campaign notification."

[0048] Figure 3 is a diagram illustrating a campaign notification (request for consent) in the software update method according to this embodiment. In this embodiment, the OTA master 10 and HMI 70 installed in the vehicle 100 work together to function as an example of an "in-vehicle terminal" according to this disclosure.

[0049] Referring to Figure 3, the OTA Center 500 determines whether the vehicle 100 is in operation before sending a campaign notification. Details of the determination method will be described later (see S22 in Figure 4). If it is determined that the vehicle 100 is in operation, the OTA Center 500 sends a campaign notification to the OTA Master 10. On the other hand, if it is determined that the vehicle 100 is not in operation, the OTA Center 500 sends a campaign notification to both the OTA Master 10 and the mobile terminal 200. Upon receiving the campaign notification, the OTA Master 10 and the mobile terminal 200 each prompt the user to either accept or reject the campaign notification (acceptance request signal). If the user has performed an operation indicating acceptance, the OTA Master 10 and the mobile terminal 200 each send a reply indicating acceptance to the OTA Center 500.

[0050] Specifically, when the OTA master 10 receives a campaign notification, the HMI 70 displays screen Sc1. When the mobile terminal 200 receives the campaign notification, it notifies the user of the incoming notification with sound or vibration, and the mobile terminal 200's touch panel display displays screen Sc2. Screens Sc1 and Sc2 each display a message such as, for example, "New software has been found. Do you want to apply it to this vehicle?" and prompt the user to indicate whether or not to accept the download of the new software.

[0051] Screens Sc1 and Sc2 each include apply buttons M11 and M21, which accept the "accept" operation, and confirmation buttons M12 and M22, and non-apply buttons M13 and M23, which accept the "reject" operation. When the apply button M11 is operated, the OTA master 10 sends an "accept" reply to the OTA center 500. When the non-apply button M13 is operated, the OTA master 10 dismisses the display on screen Sc1 without sending the "accept" reply. Hereinafter, the operation of either the apply button M11 or the non-apply button M13 on screen Sc1 will be referred to as the "first operation". On the other hand, when the apply button M21 is operated on screen Sc2, the mobile terminal 200 sends an "accept" reply to the OTA center 500. When the non-apply button M23 is operated, the mobile terminal 200 dismisses the display on screen Sc2 without sending the "accept" reply. Hereafter, the operation of either the Apply button M21 or the Disapply button M23 on screen Sc2 will be referred to as the "second operation." Both the first and second operations indicate the user's intention (either accept or reject) regarding the campaign notification (request for acceptance).

[0052] If the confirmation buttons M12 and M22 are pressed before the first and second operations described above are performed, the HMI70 and mobile terminal 200 will display the campaign details (at least a portion of the campaign information), respectively. This allows the user to understand the campaign details and then decide whether or not to agree to download the new software related to that campaign.

[0053] As will be described in detail later, in this embodiment, if the OTA center 500 receives the "acceptance" reply from the OTA master 10 or the mobile terminal 200, it proceeds to the download phase of the software update process. On the other hand, if the OTA center 500 does not receive the "acceptance" reply from the OTA master 10 or the mobile terminal 200, the OTA center 500 terminates the software update process without proceeding to the download phase.

[0054] Referring again to Figure 2 along with Figure 1, the OTA center 500 and the vehicle 100 perform the download process, for example, using the procedure described below. Hereinafter, the terminal (in-vehicle terminal or mobile terminal 200) that sent the "acceptance" reply will be referred to as the "accepting terminal".

[0055] The OTA master 10 requests a distribution package containing the new software from the OTA center 500. The OTA master 10 then downloads (receives and saves) the distribution package while communicating wirelessly with the OTA center 500. In addition to the new software (e.g., a set of update data for each ECU targeted by 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 (identifier of the target ECU, verification data to verify the legitimacy of the update data, etc.). The target ECU is the ECU to be updated. For example, the target ECU may be ECU20, and the software to be updated may be an automated driving control program.

[0056] The above-described download process saves the distribution package to the storage device (e.g., memory 120) of the OTA master 10. During the download, the accepting terminal notifies the user of the download progress. After the download is complete, the OTA master 10 verifies the authenticity of the downloaded distribution package. If the verification result is "normal", the OTA master 10 notifies the OTA center 500 of the software update status (download complete). This notification indicates that the download was successful.

[0057] If the download is successful, vehicle 100 will perform the installation. Specifically, OTA master 10 requests the status of at least one target ECU (e.g., ECU 20) and the output of a DTC (Diagnostic Trouble Code). Based on the status of the target ECU and the DTC, OTA master 10 determines whether installation can be performed for each target ECU. Then, OTA master 10 transfers the new software (update data) to the target ECUs that are able to perform the installation. The target ECU that receives the update data performs the installation of the update data (writing to non-volatile memory). During the installation, the acceptance terminal notifies the user of the installation progress.

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

[0059] If the download and installation are successful, the vehicle 100 enters an activation waiting state. Subsequently, if the power switch 50 or the mobile terminal 200 is turned off, the OTA master 10 displays a predetermined message on the acceptance terminal and requests the user to input either "accept" or "reject". If the user inputs "accept" to the acceptance terminal, the OTA master 10 performs activation (activation of the installed software). On the other hand, if the user inputs "reject" to the acceptance terminal, the OTA master 10 stops the software update process without performing activation, and the vehicle system shuts down.

[0060] Once the OTA master 10 has successfully verified the configuration after activation, it displays the software update result on the acceptance terminal. The acceptance terminal displays, for example, a software update completion screen indicating the success of the update. Subsequently, the OTA master 10 notifies the OTA center 500 of the software update status (software update complete). This notification means that the OTA software update was successful. Upon receiving this notification, the vehicle's control system shuts down and the ignition is turned off. Subsequently, when the power switch 50 or the mobile terminal 200 is turned on, the vehicle system's ignition is turned on. This starts the update program (new version of software) on the target ECU.

[0061] Figure 4 is a flowchart showing the processing procedure of the software update method according to this embodiment. In the flowchart, "S" represents a step. The series of processes from S11 to S15 are executed by the OTA master 10 (in-vehicle terminal), the series of processes from S21 to S26 are executed by the OTA center 500 (server), and the series of processes from S31 to S33 are executed by the mobile terminal 200. The following flowchart is realized by one or more processors reading and executing programs stored in one or more memories. In this embodiment, the processor 510 shown in Figure 1 functions as an example of the "determination unit" and "notification unit" according to this disclosure.

[0062] Referring to Figures 1-3 and Figure 4, in S11, the OTA master 10 performs configuration synchronization. Specifically, the OTA master 10 transmits the aforementioned vehicle configuration information to the OTA center 500. Subsequently, in S12, the OTA master 10 determines whether or not it has received a campaign notification.

[0063] When the OTA center 500 receives the above vehicle configuration information, it starts a series of processes from S21 to S26. In S21, the OTA center 500 determines whether there is a campaign (new or unapplied software update) applicable to the target vehicle that sent the above vehicle configuration information. The target vehicle here is vehicle 100 shown in Figure 1. If there is no campaign applicable to vehicle 100 (NO in S21), the series of processes from S21 to S26 ends.

[0064] If there is a campaign applicable to vehicle 100 (YES in S21), then in the following S22, the OTA center 500 determines whether vehicle 100 is in operation. For example, the OTA center 500 determines that vehicle 100 is in operation if the mobile terminal 200 is located inside vehicle 100, and that vehicle 100 is not in operation if the mobile terminal 200 is located outside vehicle 100. The OTA center 500 may, for example, receive location information from both vehicle 100 and mobile terminal 200 and determine whether mobile terminal 200 is outside vehicle 100 based on that location information. Alternatively, the OTA center 500 may receive a signal from mobile terminal 200 indicating whether it is inside vehicle 100, and determine whether mobile terminal 200 is outside vehicle 100 based on that signal.

[0065] The method for determining whether or not vehicle 100 is in operation is not limited to the above. For example, the OTA center 500 may receive a signal from vehicle 100 indicating whether or not vehicle 100 is in operation and determine whether or not vehicle 100 is in operation based on that signal. The OTA master 10 may determine that vehicle 100 is in operation when the start switch 50 is turned ON, and determine that vehicle 100 is no longer in operation when the ignition is switched from ON to OFF. A sensor for detecting a driver (for example, a seat belt sensor or a seat occupancy sensor) may be provided in the driver's seat of vehicle 100. The OTA master 10 may then determine that the vehicle is in operation if there is a driver in the driver's seat, and not in operation if there is no driver in the driver's seat. Alternatively, the OTA center 500 may determine that vehicle 100 is in operation if vehicle 100 is moving. The OTA center 500 may receive a signal from the vehicle 100 indicating the vehicle's position and / or status (e.g., vehicle speed), and determine whether the vehicle 100 is in motion based on that signal.

[0066] If it is determined that vehicle 100 is not in operation (NO in S22), the OTA center 500 sends a campaign notification to both the OTA master 10 and the mobile terminal 200 in S23, requesting the user of vehicle 100 to agree to download the new software related to the campaign. On the other hand, if it is determined that vehicle 100 is in operation (YES in S22), the OTA center 500 sends the campaign notification only to the OTA master 10 in S24. After executing the process in S23 or S24, the OTA center 500 determines in S25 whether it has received an "acceptance" reply from the in-vehicle terminal (OTA master 10) or the mobile terminal 200.

[0067] If the OTA master 10 receives the campaign notification (S23, S24) from the OTA center 500 within a predetermined period (for example, the period until a predetermined time has elapsed since the configuration synchronization), it determines YES in S12. In this case, the process proceeds to S13. On the other hand, if the OTA master 10 does not receive the campaign notification within the predetermined period after the configuration synchronization, it determines NO in S12, and the series of processes S11 to S15 ends. Determining NO in S12 means that there are no campaigns applicable to the vehicle 100. After the series of processes S11 to S15 is completed, once a predetermined time has elapsed since the previous configuration synchronization, the series of processes S11 to S15 starts again, and the configuration synchronization (S11) is executed.

[0068] In S13, the OTA master 10 causes the HMI 70 to display a message prompting the user of vehicle 100 to either accept or reject the campaign notification. Specifically, the OTA master 10 controls the HMI 70 so that it displays screen Sc1 shown in Figure 3.

[0069] In S14, the OTA master 10 determines whether or not the user has operated the apply button M11 (Figure 3). If a predetermined time has elapsed since the HMI 70 displayed screen Sc1 (Figure 3) without the user operating the apply button M11, the OTA master 10 determines NO in S14 and dismisses the display of screen Sc1 by the HMI 70. In this case, the series of processes from S11 to S15 ends without a "confirmation" reply being sent. On the other hand, if the user operates the apply button M11 before the predetermined time has elapsed since the HMI 70 displayed screen Sc1 (Figure 3), the OTA master 10 determines YES in S14 and proceeds to S15. In S15, the OTA master 10 sends a "confirmation" reply to the OTA center 500. Once the process in S15 is executed, the series of processes from S11 to S15 ends.

[0070] When the mobile terminal 200 receives the campaign notification (S23) from the OTA center 500, it starts a series of processes from S31 to S33. In S31, the mobile terminal 200 displays a prompt to the user of the vehicle 100 to either accept or reject the campaign notification. Specifically, the mobile terminal 200 (touch panel display) displays screen Sc2 shown in Figure 3.

[0071] In S32, the mobile terminal 200 determines whether or not the user has operated the apply button M21 (Figure 3). If a predetermined time has elapsed since the mobile terminal 200 displayed screen Sc2 (Figure 3) without the user operating the apply button M21, the mobile terminal 200 determines NO in S32 and dismisses the display of screen Sc2. In this case, the series of processes from S31 to S33 ends without a "confirmation" reply being sent. On the other hand, if the user operates the apply button M21 before the predetermined time has elapsed since the mobile terminal 200 displayed screen Sc2 (Figure 3), the mobile terminal 200 determines YES in S32 and proceeds to S33. In S33, the mobile terminal 200 sends a "confirmation" reply to the OTA center 500. Once the process in S33 is executed, the series of processes from S31 to S33 ends.

[0072] When the OTA center 500 receives an "acceptance" reply (S15, S33) from the in-vehicle terminal (OTA master 10) or the mobile terminal 200, it determines YES in S25. Specifically, the OTA center 500 accepts the above "acceptance" replies during a predetermined acceptance period (for example, the period from the time the campaign notification is sent until a predetermined amount of time has elapsed). If the above acceptance period has elapsed without receiving an "acceptance" reply from either the in-vehicle terminal or the mobile terminal 200, the OTA center 500 determines NO in S25. In this case, the OTA center 500 terminates the series of processes from S21 to S26 without proceeding with the software update process to the download phase. On the other hand, if the OTA Center 500 receives an "acceptance" reply (S15, S33) from the in-vehicle terminal or mobile terminal 200 within the above acceptance period (YES in S25), the OTA Center 500 proceeds to the download phase of the software update process in S26. This initiates the download of the new software related to the above campaign. Once the process in S26 is executed, the series of processes from S21 to S26 is completed. The process after the download starts has already been described (see Figure 2).

[0073] As described above, the software update method according to this embodiment includes the process shown in Figure 4. Specifically, it includes the OTA center 500 determining whether or not the vehicle 100 is in operation (S22), the OTA center 500 sending a campaign notification to the in-vehicle terminal (OTA master 10) installed in the vehicle 100 if it is determined that the vehicle 100 is in operation (YES in S22) (S24), and the OTA center 500 sending a campaign notification to the portable terminal 200 that can be carried by the user of the vehicle 100 if it is determined that the vehicle 100 is not in operation (NO in S22) (S23). The campaign notification requests the user of the vehicle 100 to consent to the process related to updating the software of the ECU (control unit) installed in the vehicle 100.

[0074] According to the method described above, when the user is driving vehicle 100, the campaign notification is sent to the in-vehicle terminal (OTA master 10). Therefore, the user, while driving, can find out that the campaign notification is about a software update by checking the in-vehicle terminal (HMI 70) that received the notification, without having to check the mobile terminal 200. This makes it less likely for the user to be interrupted while driving vehicle 100. Furthermore, when the user is not driving vehicle 100, the campaign notification is sent to the mobile terminal 200. Therefore, the user who is not driving can find out the content of the campaign notification by checking the mobile terminal 200 that received the notification, without having to check the in-vehicle terminal. This makes it easier to ensure sufficient user convenience.

[0075] The process shown in Figure 4 can be modified as appropriate. For example, in the process shown in Figure 4, if it is determined that vehicle 100 is not in operation (NO in S22), the OTA center 500 notifies not only the mobile terminal 200 but also the in-vehicle terminal (OTA master 10) (S23). Therefore, when the vehicle 100 is not being driven, the user can check the campaign notification on both the in-vehicle terminal (HMI 70) and the mobile terminal 200. However, this is not the only option, and the process in S23 may be modified so that the OTA center 500 sends the campaign notification only to the mobile terminal 200.

[0076] Furthermore, in the process shown in Figure 4, if it is determined that the vehicle 100 is in operation (YES in S22), the OTA center 500 does not send a campaign notification to the mobile terminal 200. This prevents the user who is driving from mistaking a notification about a software update (a request for consent) for a notification about another requirement (for example, an urgent notification). However, this is not limited to this, and a campaign notification may be sent to the mobile terminal 200 if it is determined that the vehicle 100 is in operation. For example, instead of S21-S26 and S31-S33 shown in Figure 4, the process shown in Figure 5, which will be explained below, may be adopted.

[0077] Figure 5 shows a modified version of the process shown in Figure 4. Although not shown in Figure 5, in this modified version as well, the series of processes S11 to S15 shown in Figure 4 are executed by the OTA master 10 (in-vehicle terminal).

[0078] Referring to Figures 1-3 and Figure 5, in this modified example, S23A and S24A are used instead of S23 and S24 in Figure 4. If it is determined that vehicle 100 is in operation (YES in S22), the process in S23A is performed, and then the process proceeds to S24A. If it is determined that vehicle 100 is not in operation (NO in S22), the process in S23A is not performed, and the process proceeds to S24A. In S23A, the OTA center 500 transmits a signal to the mobile terminal 200 indicating that vehicle 100 is in operation (hereinafter referred to as the "in operation signal"). This in operation signal notifies the mobile terminal 200 that vehicle 100 is in operation. In S24A, the OTA center 500 sends a campaign notification to the OTA master 10 and the mobile terminal 200, respectively, similar to S23 in Figure 4. After that, the process proceeds to S25. The subsequent processing is the same as the example shown in Figure 4.

[0079] When the mobile terminal 200 receives the campaign notification (S24A) from the OTA center 500, it starts the series of processes (S31A, S31B, S31~S33) shown in Figure 5. In this modified example, S31A and S31B are added before S31~S33 shown in Figure 4. In S31A, the mobile terminal 200 determines whether or not the vehicle 100 is in operation. The mobile terminal 200 determines whether or not the vehicle 100 is in operation based on whether or not it has received the in-operation signal (S23A) from the OTA center 500. If it is determined that the vehicle 100 is in operation (YES in S31A), the process in S31B is performed and then the process proceeds to S31. If it is determined that the vehicle 100 is not in operation (NO in S31A), the process proceeds to S31 without performing the process in S31B. In S31B, the mobile terminal 200 notifies the user of the software update via its speaker. The mobile terminal 200 may also announce a message such as, "New software has been found." The processing from S31 onward is the same as the example shown in Figure 4.

[0080] In the modified software update system described above, when the vehicle 100 is in operation (YES in S22), the OTA center 500 sends a campaign notification not only to the in-vehicle terminal but also to the mobile terminal 200 (S24A). When the mobile terminal 200 receives a campaign notification from the OTA center 500 while the vehicle 100 is in operation (YES in S31A), it notifies the user of the vehicle 100 of the software update by voice (S31B). This makes it less likely for the user who is driving to mistake the notification (request for consent) regarding the software update for a notification regarding another requirement (for example, an urgent notification).

[0081] In the above embodiment, an on-premise server is used as the OTA Center 500 (see Figure 1). However, it is not limited to this, and the functions of the OTA Center 500 (for example, functions related to software updates) may be implemented on the cloud using cloud computing. In other words, the OTA Center 500 may be a cloud server. The software to be updated is not limited to control programs for driver assistance systems such as the autonomous driving control program mentioned above, but is arbitrary. It is not necessary for the vehicle to be configured to be capable of autonomous driving.

[0082] 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, biofuel engine, or 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 onboard battery may be configured to be contact-chargeable, contactless-chargeable (wireless-chargeable) while parked or driving, or replaceable. The vehicle may be equipped with solar panels. The vehicle may be equipped with flight capabilities. The vehicle may be a MaaS (Mobility as a Service) vehicle. A MaaS vehicle is a vehicle managed by a MaaS operator. The vehicle may be a multi-purpose vehicle customized according to the user's intended 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 last-mile BEV or electric wheelchair).

[0083] The above variations may be combined in any way as desired. The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims rather than by the description of the embodiments above, and all modifications within the meaning and scope equivalent to the claims are intended to be included. [Explanation of symbols]

[0084] 10 OTA masters, 20 ECUs, 50 start switches, 70 HMIs, 100 vehicles, 110, 210, 510 processors, 120, 220, 520 memory modules, 130, 230, 530 communication modules, 200 mobile terminals, 500 OTA centers.

Claims

1. A determination unit that determines whether the vehicle is in motion based on the vehicle's position and / or speed, A notification unit that notifies the user of the vehicle requesting their consent to the process of updating the software of the control device installed in the vehicle, Equipped with, If the determination unit determines that the vehicle is in motion, the notification unit will send the notification to the in-vehicle terminal installed in the vehicle. If the determination unit determines that the vehicle is not in motion, the notification unit sends the notification to the user's portable terminal.

2. The server according to claim 1, wherein if the determination unit determines that the vehicle is in motion, the notification unit does not send the notification to the mobile terminal.

3. The server according to claim 2, wherein, if the determination unit determines that the vehicle is not in motion, the notification unit provides the notification not only to the mobile terminal but also to the in-vehicle terminal.

Images