Mobile terminal, software distribution system

Abstract

To enable even a single bank type computer mounted on a vehicle to be appropriately updated by an OTA technique.SOLUTION: A mobile terminal includes a storage unit, a receiving unit, and a transmitting unit. The receiving unit is configured to receive, from a vehicle, software prior to updating a single-bank type computer mounted on the vehicle (S15). The transmitting unit is configured to transmit, to the vehicle, update software acquired from a server (S17) after storing the received pre-update software in the storage unit (S15).SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates to a mobile terminal and a software distribution system.

Background Art

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

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] A vehicle can download new software for an in-vehicle ECU from an OTA center by performing wireless communication with the OTA center. Then, in the vehicle, the target ECU (the ECU to be updated with software) can update the software by sequentially executing installation and activation.

[0005] A typical in-vehicle ECU includes one or more microcomputers (hereinafter, also referred to as "microcontrollers"). Typical microcontrollers in an in-vehicle ECU are broadly classified into dual-bank microcontrollers and single-bank microcontrollers.

[0006] In a dual - bank microcomputer, two banks are formed by two memories. In a dual - bank microcomputer, when activation fails, it is possible to roll back to the original version of the software. Specifically, while leaving the original version of the software on the active side, the new version of the software is written on the writing side. Then, when activation of the writing side fails, rollback is executed by the original version of the software left on the active side.

[0007] In a single - bank microcomputer, one bank is formed by one memory. And in a single - bank microcomputer, software overwriting is performed in one bank. For this reason, the original version of the software does not remain. In a single - bank microcomputer, there may arise a problem that it is impossible to roll back to the original version of the software when activation fails.

[0008] Therefore, it is conceivable to change a single - bank microcomputer to a dual - bank microcomputer, to provide a storage unit for rollback within the bank of a single - bank microcomputer, or to externally provide a non - volatile memory (for example, Flash memory) for rollback to a single - bank microcomputer. However, these design changes lead to a large cost increase in in - vehicle ECUs.

[0009] Currently popular vehicles are equipped with a large number of single - bank microcomputers, and software updates for single - bank microcomputers are often performed at dealerships. However, there is also a need to easily execute software updates at the discretion of vehicle users using OTA technology even for single - bank microcomputers.

[0010] This disclosure has been made to solve the above - mentioned problems, and its object is to enable suitable software updates by OTA technology for single - bank type computers mounted on vehicles.

Means for Solving the Problems

[0011] According to the form according to the first aspect of the present disclosure, the following mobile terminal is provided.

[0012] (Item 1) The mobile terminal includes a storage unit, a reception unit, and a transmission unit. The reception unit is configured to receive, from the vehicle, the software before update of a single-bank type computer mounted on the vehicle. The transmission unit is configured to transmit, to the vehicle, the software for update acquired from the server after storing the received software before update in the storage unit.

[0013] The above server can function as an OTA (Over The Air) center that distributes software. The above mobile terminal can mediate communication between the vehicle and the OTA center. In a system including these server, vehicle, and mobile terminal, by using the storage unit of the mobile terminal, a single-bank type computer in a target ECU (ECU to be software-updated) mounted on the vehicle can be virtually made to function as a dual-bank type computer. According to the mobile terminal having the above configuration, when the software update (for example, activation) of the single-bank type computer of the above vehicle fails, it becomes possible to perform a rollback using the software before update stored in the storage unit of the mobile terminal. Thereby, suitable software update by the OTA technology becomes possible also for the single-bank type computer mounted on the vehicle.

[0014] Note that the mobile terminal is a terminal that can be carried by a user. Examples of the mobile terminal include a tablet terminal, a smartphone, and a wearable device.

[0015] The mobile terminal described in the above Item 1 may have the configuration described in any one of Items 2 to 5 shown below.

[0016] (2) The mobile terminal according to claim 1 further has the following features. The mobile terminal further includes an acquisition unit that acquires the version information of the software before the update, and a determination unit that determines whether the storage unit has free space for storing the software before the update in the software update of a single-bank type computer. When the determination unit determines that the storage unit has free space for storing the software before the update, the reception unit receives the software before the update from the vehicle, and after the transmission unit stores the software before the update in the storage unit, the transmission unit transmits the update software acquired from the server to the vehicle. When the determination unit determines that the storage unit does not have free space for storing the software before the update, the acquisition unit acquires the version information of the software before the update, and after the transmission unit stores the version information in the storage unit, the transmission unit transmits the update software acquired from the server to the vehicle.

[0017] According to the mobile terminal having the above configuration, it is possible to appropriately store data for rollback (specifically, the software before the update or its version information) according to the free space of the storage unit (that is, the amount of data that the storage unit can store).

[0018] (3) The mobile terminal according to claim 1 further has the following features. The mobile terminal further includes an update unit. In the software update of a single-bank type computer, the update unit holds the software update until free space for storing the software before the update is secured in the storage unit, and after free space for storing the software before the update is secured in the storage unit, the update unit is configured to permit the software update of the single-bank type computer.

[0019] According to the above configuration, it becomes easier to appropriately perform the software update of a single-bank type computer.

[0020] (Item 4) The mobile terminal according to any one of Items 1 to 3 further has the following features. The mobile terminal further includes a notification unit. The notification unit is configured to perform a predetermined notification when there is insufficient free capacity in the storage unit for storing the software before the update in the software update of a single-bank type computer.

[0021] [[ID=]4]According to the above configuration, it becomes easier for the user to grasp the situation.

[0022] (Item 5) The mobile terminal according to any one of Items 1 to 4 further has the following features. The receiving unit is configured to acquire update software from a server by wireless communication. The transmitting unit is configured to transmit to a vehicle by wireless communication.

[0023] According to the above configuration, the convenience of the user is improved.

[0024] According to the form according to the second aspect of the present disclosure, the following mobile terminal is provided.

[0025] (Item 6) The mobile terminal includes a storage unit, an acquisition unit, and a transmission unit. The acquisition unit is configured to acquire the version information of the software before the update of a single-bank type computer mounted on a vehicle. The transmission unit is configured to transmit the update software acquired from the server to the vehicle after storing the version information of the software before the update in the storage unit.

[0026] According to the mobile terminal having the above configuration, when the software update of the single-bank type computer mounted on the vehicle fails, the mobile terminal can acquire the software before the update from, for example, a server based on the version information of the software before the update stored in the storage unit. Then, the vehicle can receive the software before the update from the mobile terminal and perform a rollback of the single-bank type computer using the software before the update.

[0027] According to the form according to the third aspect of the present disclosure, the following software distribution system is provided.

[0028] (Item 7) The software distribution system includes the mobile terminal according to any one of Items 1 to 6, a vehicle, and a server. The vehicle includes a control device that manages a software update sequence. The control device uses the update software received from the mobile terminal to execute a software update of a single-bank type computer, and when the software update fails, receives the software before the update from the mobile terminal and is configured to execute a rollback using the software before the update.

[0029] According to the above software distribution system, it becomes easier to manage software updates on the vehicle side.

[0030] (Item 8) The software distribution system according to Item 7 further has the following characteristics. The single-bank type computer is a computer that performs vehicle driving control.

[0031] According to the above configuration, when an update of software related to driving control fails, it is possible to return to (roll back to) the software before the update. With the software before the update, the vehicle can run as before. Therefore, the user can feel at ease.

Effect of the Invention

[0032] According to the present disclosure, it becomes possible to perform suitable software updates for a single-bank type computer mounted on a vehicle by OTA technology.

Brief Description of the Drawings

[0033]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Embodiments for Carrying Out the Invention

[0034] The embodiments of the present 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.

[0035] FIG. 1 is a diagram showing the configuration of the software distribution system according to this embodiment. Referring to FIG. 1, this software distribution system includes a vehicle 100, a mobile terminal 300, and an OTA center 500. Note that "OTA" is an abbreviation for "Over The Air".

[0036] Vehicle 100 is a battery electric vehicle (BEV) without an internal combustion engine. The vehicle 100 according to this embodiment does not have an OTA access function (a function of directly wirelessly communicating with the OTA center 500) and cannot communicate with the OTA center 500 without going through another communication device (that is, a communication device other than the communication device provided in the vehicle 100 itself). Specifically, the vehicle 100 wirelessly communicates with the OTA center 500 via the mobile terminal 300. However, the vehicle 100 is an example of a vehicle to which the software distribution system described below is applied, and the software distribution system may be applied to other vehicles.

[0037] The mobile terminal 300 is configured to be portable by the user. The mobile terminal 300 is carried and operated by the user (vehicle administrator) of the vehicle 100. In this embodiment, a smartphone having a touch panel display is adopted as the mobile terminal 300. The smartphone has a built-in computer and a speaker function. However, it 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 300. For example, a laptop, a tablet terminal, a portable game machine, a wearable device (such as a smartwatch, smart glasses, smart gloves, etc.) can also be adopted as the mobile terminal 300.

[0038] The mobile terminal 300 includes a processor 310, a memory 320, and a communication module 330. The processor 310 includes, for example, a CPU (Central Processing Unit). The memory 320 includes non-volatile memory such as, for example, flash memory. The communication module 330 includes a communication I / F (interface) for directly performing wireless communication with the OTA center 500. Also, the communication module 330 also includes a communication I / F for directly performing wireless communication with the vehicle 100. The mobile terminal 300 mediates communication between the vehicle 100 and the OTA center 500. For example, in response to a request from the vehicle 100, the mobile terminal 300 accesses the communication network NW by specifying the address of the OTA center 500, enabling the vehicle ECU 110 in the vehicle 100 to communicate with the OTA center 500 via the mobile terminal 300 (communication module 330). Thereby, wireless communication between the vehicle 100 and the OTA center 500 is established.

[0039] An application software (hereinafter referred to as "mobile app") for using the services provided by the OTA center 500 is installed in the mobile terminal 300. Through the mobile app, the identification information (terminal ID) of the mobile terminal 300 is associated with the identification information (vehicle ID) of the vehicle 100 and registered in the OTA center 500. Also, the mobile terminal 300 can exchange information with the OTA center 500 through the mobile app.

[0040] The OTA center 500 is a server that provides a vehicle software update service using OTA technology. The OTA center 500 is configured to remotely update in-vehicle ECU software via a communication section from the center. The OTA center 500 distributes the software of the in-vehicle ECU. Note that "ECU" means an Electronic Control Unit.

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

[0042] In the OTA center 500, identification information (vehicle ID) of each vehicle (including the vehicle 100) that receives the vehicle software update service from the OTA center 500 is registered in advance. The storage device (for example, the memory 520) of the OTA center 500 stores information about each vehicle (hereinafter, also referred to as "vehicle information") separately by vehicle ID. The vehicle information includes, for example, the specifications of each vehicle and the communication address of each vehicle (for the vehicle 100, the communication address of the mobile terminal 300).

[0043] The vehicle 100 includes a plurality of ECUs (including the ECUs 110, 121, and 122). The number of ECUs provided in the vehicle 100 is arbitrary. Each in-vehicle ECU incorporates a computer including at least one processor and at least one memory. Each in-vehicle ECU may include a plurality of microcomputers (microcontrollers) in the form of a main microcomputer and a sub-microcomputer, for example. In the vehicle 100, the ECUs are connected to each other via a communication bus and are configured to be capable of wired communication. Note that the communication method between the ECUs is not particularly limited, and may be, for example, CAN (Controller Area Network) or Ethernet (registered trademark).

[0044] The ECU 110 includes a processor 111 and a memory 112. The processor 111 includes, for example, a CPU. The memory 112 includes a non-volatile memory such as a flash memory, for example. The vehicle 100 further includes a communication device 190. The ECU 110 communicates with devices outside the vehicle through the communication device 190. The communication device 190 includes a communication I / F (interface) for directly performing wireless communication with the mobile terminal 300. The communication device 190 and the mobile terminal 300 may perform short-range communication such as a wireless LAN (Local Area Network), NFC (Near Field Communication), or Bluetooth (registered trademark). The communication device 190 may directly communicate with the mobile terminal 300 existing within the vehicle or in the vicinity of the vehicle. While the vehicle 100 is stopped, the mobile terminal 300 inside or outside the vehicle and the ECU 110 may exchange information with each other via the communication device 190. Also, while the vehicle 100 is running, the mobile terminal 300 inside the vehicle and the ECU 110 may exchange information with each other via the communication device 190. The ECU 110 can communicate with the OTA center 500 via the mobile terminal 300 by requesting the mobile terminal 300 to communicate with the OTA center 500 as described above.

[0045] As described above, the ECU 110 of the vehicle 100 is configured to be capable of wireless communication with the OTA center 500 via the mobile terminal 300. The vehicle 100 can communicate with the OTA center 500 both while stopped and while running. The ECU 110 manages in-vehicle information, receives campaigns, and manages software update sequences.

[0046] Note that the communication method between the vehicle 100 and the mobile terminal 300 is not limited to the above short - range communication. The vehicle 100 and the mobile terminal 300 may be configured to communicate even when they are separated from each other. Further, the communication device 190 may further include a communication I / F for performing wired communication with a scan tool (a dedicated tool for performing wired software updates) not shown in the figure. The ECU 110 may perform wired communication with a scan tool connected to a DLC (Data Link Connector) inside the vehicle (not shown) via the communication device 190.

[0047] The vehicle 100 is an autonomous vehicle configured to be capable of autonomous driving. More specifically, the vehicle 100 is configured to be capable of performing both manned driving and unmanned driving. The vehicle 100 is configured to be capable of autonomous driving without a driver, but can also be driven manually (manned driving) by a user. Further, the vehicle 100 can also perform autonomous driving (for example, auto - cruise control) during manned driving. The level of autonomous driving may be fully autonomous driving (level 5) or conditional autonomous driving (for example, level 4).

[0048] The vehicle 100 further includes a driving device 130 and an ADS (Autonomous Driving System) 140. In the vehicle 100, the ECU 121 is configured to control the driving device 130.

[0049] The driving device 130 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 driving wheels of the vehicle, a PCU (Power Control Unit) that drives the MG, and a battery that supplies power for driving the MG to the PCU. The MG functions as a driving motor of the vehicle. The brake device includes, for example, a braking device provided on each wheel of the vehicle 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.

[0050] The ADS140 includes a recognition sensor (e.g., at least one of a camera, a millimeter-wave radar, and a lidar) for recognizing the external environment of the vehicle, and executes processing related to autonomous driving based on information sequentially acquired by the recognition sensor. Specifically, the ADS140 generates a driving plan (information indicating the future behavior of the vehicle) according to the external environment of the vehicle while cooperating with the ECU121. Then, the ADS140 requests the ECU121 to control various actuators included in the driving device 130 so that the vehicle 100 travels according to the driving plan.

[0051] In this embodiment, the ADS is built into the vehicle. However, it is not limited to this, and the ADS may be an autonomous driving kit detachable from the vehicle. The sensor unit (including the recognition sensor) of the autonomous driving kit may be attached to the roof of the vehicle.

[0052] The vehicle 100 further includes a start switch 150 and an HMI (Human Machine Interface) 170.

[0053] The start switch 150 is a switch for the user to start the vehicle system (the control system of the vehicle 100), and is installed, for example, inside the vehicle cabin. Generally, the start switch is referred to as a "power switch" or an "ignition switch", etc. When the user operates the start switch 150, the on (operation) / off (stop) of the vehicle system (including each ECU mounted on the vehicle) is switched. When the start switch 150 is turned on, the stopped vehicle system starts, and the vehicle system enters an operating state (hereinafter, also referred to as "IG on"). Also, when the vehicle system is operating and the start switch 150 is turned off, the vehicle system enters a stopped state (hereinafter, also referred to as "IG off").

[0054] The ON operation of the start switch 150 is an operation for switching the vehicle state from IG OFF to IG ON. When the user performs an ON operation on the start switch 150, a start request is input to each in-vehicle ECU. That is, each in-vehicle ECU receives the start request from the user. On the other hand, the OFF operation of the start switch 150 is an operation for switching the vehicle state from IG ON to IG OFF. When the user performs an OFF operation on the start switch 150, a shutdown request is input to each in-vehicle ECU, and the vehicle 100 enters the shutdown standby state. In this way, each in-vehicle ECU receives the shutdown request from the user. However, in a running vehicle, the OFF operation of the start switch 150 is prohibited.

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

[0056] FIG. 2 is a diagram for explaining an overview of the software update method according to this embodiment. Referring to FIGS. 1 and 2 together, the processing related to software update (more specifically, the update of vehicle software using OTA) is performed in procedures such as configuration synchronization, campaign notification and application commitment, download, installation, activation, and software update completion notification. The processing described below is executed by the OTA center 500 and each vehicle (including the vehicle 100) that receives software distribution from the OTA center 500. The number of vehicles receiving distribution from the OTA center 500 may be about 50, or may be more than 100 and less than 1000, or may be more than 1000. ]>

[0057] When the vehicle 100 is in the IG-on state, it repeatedly executes configuration synchronization every time a preset time elapses. Also, when the vehicle 100 in the IG-on state receives a configuration synchronization request from the OTA center 500, it executes configuration synchronization. The configuration synchronization process by the vehicle 100 (ECU 110) includes transmitting vehicle configuration information to the OTA center 500. The vehicle configuration information includes, for example, hardware information (information indicating the part number of the hardware, the identifier of the ECU, etc.) and software information (information indicating the part number of the software, etc.) for each ECU included in the vehicle 100. In this embodiment, the vehicle configuration information further includes RXSWIN for each authorization target. RXSWIN is an identification number that can identify the software constituting the function type authorization.

[0058] When the OTA center 500 receives the above vehicle configuration information from the vehicle 100, it checks the campaigns (software updates) occurring at the current time. Then, if there is a campaign applicable to the vehicle 100, the OTA center 500 transmits a commitment request signal to request the user of the vehicle 100 to commit to the download of the new software (updated version of the software) related to that campaign. The commitment request signal includes information (campaign information) related to that campaign. The campaign information may include, for example, at least one of campaign attribute information (information indicating the purpose of the software update and the functions of the vehicle 100 that may be affected by the update), a list of campaign target vehicles, information related to the campaign target ECU (e.g., software information before and after the update), and information related to the notification to the user before and after the update. Note that the campaign to be notified may be a newly occurred campaign or a campaign that was not applied previously. Hereinafter, the transmission of the above commitment request signal is also referred to as "campaign notification".

[0059] When the vehicle 100 receives a campaign notification (commitment request signal), it asks the user for an input on whether to commit to the application of the campaign. Specifically, the vehicle 100 causes the in-vehicle HMI (for example, HMI 170) to display a message such as "New software has been found. Do you want to apply it to this vehicle?" and requests the user to make an input indicating either "Commit" or "Reject". Then, when the user makes an input indicating "Commit" to the in-vehicle HMI, the vehicle 100 executes the processes related to the download described below. On the other hand, when the user makes an input indicating "Reject" to the in-vehicle HMI, the vehicle 100 does not execute the processes related to the download. In this case, the OTA center 500 ends the processes related to the software update without proceeding to the download phase.

[0060] In this embodiment, the OTA center 500 and the vehicle 100 (ECU 110) execute the processes related to the download in the procedure described below.

[0061] The ECU 110 of the vehicle 100 requests the mobile terminal 300 for a delivery package including new software. Then, while performing wireless communication with the OTA center 500 via the mobile terminal 300, the ECU 110 executes the download (reception and storage) of the delivery package. The delivery package may include, in addition to new software (for example, a set of update data for each ECU targeted by the campaign), package attribute information (information indicating the update classification, the number of update data in the delivery package, the installation order of each ECU, etc.), and update data attribute information (the identifier of the target ECU, verification data for verifying the validity of the update data, etc.). The target ECU is the ECU to be updated with software. For example, the target ECU may be ECU 121, and the software to be updated may be an automatic driving control program.

[0062] Through the above-described process related to the download, the distribution package is stored in the storage device (e.g., the memory 112) provided in the ECU 110. During the download, the in-vehicle HMI notifies the user of the download progress. After the download is completed, the ECU 110 verifies the authenticity of the downloaded distribution package. If the verification result is "normal", the ECU 110 notifies the OTA center 500 via the mobile terminal 300 of the software update status (download completed). This notification means that the download has been successful.

[0063] When the download is successful, the vehicle 100 executes the installation. Specifically, the ECU 110 requests the target ECU (e.g., the ECU 121) for the status of the target ECU and the output of the DTC (Diagnostic Trouble Code). Based on the status of the target ECU and the DTC, the ECU 110 determines whether installation can be executed for each target ECU. Then, the ECU 110 transfers new software (update data) to the target ECUs for which installation is executable. The target ECU that has received the update data executes the installation of the update data (writing to the non-volatile memory). During the installation, the in-vehicle HMI notifies the user of the installation progress.

[0064] When the transfer of the above update data from the ECU 110 to the target ECU is completed, the target ECU sends a transfer completion notification to the ECU 110. Then, the ECU 110 that has received the transfer completion notification requests integrity verification from the target ECU. The target ECU that has received this request performs verification using integrity verification data (verification data) and sends the verification result to the ECU 110. The ECU 110 stores the verification result (completion / failure / abort of installation) for each target ECU. If the integrity verification of all target ECUs is completed and all verification results are "normal", the ECU 110 notifies the OTA center 500 via the mobile terminal 300 of the software update status (installation completed). This notification means that the installation has been successful.

[0065] If the download and installation are successful, the vehicle 100 enters a state waiting for activation. Thereafter, when the start switch 150 of the vehicle 100 is turned off, the ECU 110 displays an activation consent screen on the in-vehicle HMI and requests the user to input either "accept" or "reject." The activation consent screen may display restrictions on the vehicle 100 (e.g., that the vehicle cannot be used for a certain period of time or that the operation of overcurrent devices is restricted). The activation consent screen may request the user to keep the vehicle 100 in a non-driving state (e.g., a shutdown standby state, a fixed parking range, or an activated electric parking brake) until activation is complete. The activation consent screen may display a message prompting the user to confirm the state of the vehicle 100.

[0066] If the user inputs "accept" on the activation consent screen, ECU 110 requests each target ECU to activate (enable the installed software). On the other hand, if the user inputs "reject" on the activation consent screen, ECU 110 stops the process related to the software update without performing the activation, and the vehicle system is shut down.

[0067] The target ECU executes activation in response to a request from ECU 110. In a target ECU that includes multiple microcomputers (e.g., a main microcomputer and a sub-microcomputer), the sub-microcomputer in the target ECU may perform rewriting using the flash rewriting function of the main microcomputer in the target ECU. Alternatively, each microcomputer in the target ECU may perform rewriting by directly communicating with ECU 110.

[0068] Each target ECU notifies ECU110 of the result (success / failure) of activation. Although details will be described later, if activation fails in the target ECU, software rollback is executed. On the other hand, when activation is successful in the target ECU, for example, when rewriting of all microcontrollers (targets for update) in the target ECU is completed, those microcontrollers synchronously perform a reset startup (self-reset) and start the updated software. After the target ECU completes the self-reset, it enters a state of waiting for a shutdown request from ECU110. The target ECU in such a state can continue diagnostic communication with ECU110.

[0069] When ECU110 receives a notification of activation success from the target ECU, it requests the target ECU for the identification information (ECU Software ID) of the updated software. Then, ECU110 checks whether the identification information received from the target ECU matches the identification information of the updated software included in the campaign information (configuration check). If the configuration check is successful (i.e., if the software identification information matches), ECU110 updates RXSWIN. The update of RXSWIN means that activation has been successful.

[0070] When activation is successful for all target ECUs, the ECU 110 notifies the OTA center 500 via the mobile terminal 300 of the software update status (software update completed). This notification being made means that the OTA software update has been successful. Also, the ECU 110 may display the result of the software update on the in-vehicle HMI. The in-vehicle HMI displays, for example, a software update completed screen indicating the success of the update. When the above-mentioned software update completion notification is made, the ECU 110 issues a shutdown request to each target ECU, and the control system of the vehicle 100 is shut down. As a result, the vehicle 100 turns off the ignition. Thereafter, when the start switch 150 of the vehicle 100 is turned on, the vehicle system turns on the ignition. Thereby, the update program (new version of software) starts in the target ECU. Note that the software to be updated is not limited to the control program of the driving support system such as the above-mentioned automatic driving control program and is arbitrary. For example, the OTA center 500 may distribute software related to entertainment.

[0071] By the way, typical microcomputers (microcontrollers) in in-vehicle ECUs are roughly classified into dual-bank microcomputers (dual-bank type microcontrollers) and single-bank microcomputers (single-bank type microcontrollers). In a dual-bank microcomputer, new software (new version of software) is written on the writing side while leaving the old software (original version of software) on the active side. Therefore, if activation fails, the writing side can be reverted to the old software by the old software left on the active side (rollback). On the other hand, in a single-bank microcomputer, software is overwritten in one bank. For this reason, no old software remains. In a single-bank microcomputer, there may arise a problem that it is not possible to revert to the old software (rollback) when activation fails.

[0072] Therefore, the software distribution system according to this embodiment enables suitable software updates by OTA technology even for a single-bank type computer mounted on a vehicle by executing the processes shown in FIGS. 3 and 4 described below.

[0073] In the software distribution system according to this embodiment, the microcomputer to be the target of software update (hereinafter simply referred to as "update target") is at least one of a single-bank microcomputer and a dual-bank microcomputer included in the target ECU. Although details will be described later, in vehicle 100, ECU 121 incorporates a single-bank microcomputer, and ECU 122 incorporates a dual-bank microcomputer. When the activation of the update target fails in the target ECU, a rollback of the update target is executed. In particular, for a plurality of microcomputers that execute control in cooperation with each other, it is required to align the software versions. In these microcomputers, software version upgrade (software update) is executed simultaneously, and when activation fails in any of these microcomputers, a process of reverting to the old software (rollback process) is executed for all microcomputers.

[0074] FIG. 3 is a first flowchart showing the processing procedure of the software update method according to this embodiment. A series of processes shown in this flowchart are executed by the mobile terminal 300 and the vehicle 100 when it is the execution timing of the above-described configuration synchronization (for example, when the execution condition of the configuration synchronization is satisfied). In this embodiment, the processor 310 shown in FIG. 1 functions as an example of the "reception unit", "transmission unit", "acquisition unit", and "judgment unit" according to the present disclosure, and the memory 320 shown in FIG. 1 functions as an example of the "storage unit" according to the present disclosure. "S" in the flowchart means step. The following flowchart is realized by one or more processors reading and executing a program stored in one or more memories.

[0075] Referring to FIGS. 3 together with FIGS. 1 and 2, a series of processes S11 to S17 are executed by the mobile terminal 300. A series of processes S31 to S36 are executed by the vehicle 100. In S31, the ECU 110 executes configuration synchronization (FIG. 2) via the mobile terminal 300. The mobile terminal 300 mediates configuration synchronization between the vehicle 100 and the OTA center 500 in S11. When there is a campaign applicable to the vehicle 100, in S32, the ECU 110 receives a campaign notification (FIG. 2) from the OTA center 500 via the mobile terminal 300. The mobile terminal 300 mediates a campaign notification from the OTA center 500 to the vehicle 100 in S12. Then, when the user makes an input indicating "approval" to the in-vehicle HMI regarding the application of the campaign, the process proceeds to S13 and S33. Note that in each of the case where there is no campaign applicable to the vehicle 100 and the case where the user makes an input indicating "rejection" regarding the application of the campaign, the series of processes shown in FIG. 3 ends. Thereafter, when it is time to execute configuration synchronization, the series of processes shown in FIG. 3 starts again.

[0076] In S13, the mobile terminal 300 determines whether the update target (the computer to be software-updated) is a single-bank microcomputer. The update target is the microcomputer included in the target ECU. The mobile terminal 300 may acquire information on the update target from the vehicle 100 (ECU 110). Alternatively, the mobile terminal 300 may extract information on the update target from the campaign information (S12). When the update target is a single-bank microcomputer (YES in S13), in S14, the mobile terminal 300 checks the free capacity of the memory 320 and determines whether there is free capacity in the memory 320 to store the old software of the update target (that is, the software before update stored on the active surface of the update target). The mobile terminal 300 may acquire the data size of the old software (main body) of the update target from the vehicle 100 (ECU 110). Alternatively, the mobile terminal 300 may extract information on the software before update from the campaign information (S12).

[0077] If the memory 320 has free space for storing the old software to be updated (YES in S14), the mobile terminal 300 requests the vehicle 100 for the old software (main body) to be updated in S15. Hereinafter, this request (S15) is also referred to as the "first request".

[0078] After the vehicle 100 (ECU). After the vehicle 100 (ECU110) receives an input indicating the above-mentioned "approval" from the user, in S33, it waits for the above first request from the mobile terminal 300. Specifically, in S33, the ECU110 determines whether it has received the first request from the mobile terminal 300 within a predetermined time after the user makes an input indicating "approval". If it is determined to be YES in S14, the mobile terminal 300 executes the first request to the vehicle 100 before the above predetermined time elapses, and it is determined to be YES in S33. In this case, the ECU110 transmits the old software (main body) to be updated to the mobile terminal 300 in the subsequent S34. Then, the mobile terminal 300 stores the old software (main body) received from the vehicle 100 in the memory 320. Thereafter, the process proceeds to S17 and S35. On the other hand, if it is determined to be NO in S14, the predetermined time elapses without the vehicle 100 receiving the first request, and it is determined to be NO in S33. In this case, the process proceeds to S35 without executing the process of S34.

[0079] If the memory 320 does not have free space for storing the old software to be updated (NO in S14), the mobile terminal 300 stores the version information of the old software to be updated in the memory 320 in S16. The data size of the version information of the old software is very small compared to the data size of the old software main body. The mobile terminal 300 may obtain the version information of the old software to be updated from the vehicle 100 (ECU110). Alternatively, the mobile terminal 300 may extract the version information of the old software to be updated from the campaign information (S12).

[0080] When the old software main body or the old software version information to be updated is stored in the memory 320 in S15 or S16, the process proceeds to S17. In S17, while the mobile terminal 300 receives the new software (the software main body of the new version) to be updated from the OTA center 500 by wireless communication, it transmits the received new software to the vehicle 100 by wireless communication.

[0081] In S35, the vehicle 100 (ECU110) determines whether it has received the new software (S17) from the mobile terminal 300. When the vehicle 100 receives the new software from the mobile terminal 300 (YES in S35), the ECU110 executes the download and installation (Figure 2) of the new software in S36. Specifically, the ECU110 executes the download (Figure 2) of the new software to be updated via the mobile terminal 300. The mobile terminal 300 mediates the download from the OTA center 500 to the vehicle 100 in S17. Then, when the download is successful, the new software is written (installed) to the update target.

[0082] When the update target includes a plurality of microcontrollers (computers), the processes of S13 to S17 and S33 to S36 are executed for each update target. When the update target is a single-bank microcontroller (YES in S13), after the mobile terminal 300 stores the old software or its version information of the update target in the memory 320 as described above in S15 or S16, in S17, it transmits the new software (update software) obtained from the OTA center 500 to the vehicle 100. On the other hand, when the update target is a dual-bank microcontroller (NO in S13), the process of S17 is executed without performing the processes of S14 to S16. And since the process of S15 is not performed, it is determined as NO in S33.

[0083] After the download and installation of the new software are completed for all the update targets and a predetermined activation start condition is satisfied, the process proceeds to S21 and S41 in FIG. 4. For example, when the activation start condition is satisfied, the ECU 110 requests activation from each target ECU. Then, a series of processes shown in FIG. 4 described below are started. FIG. 4 is a second flowchart showing the processing procedure of the software update method according to this embodiment.

[0084] Referring to FIG. 4 together with FIGS. 1 and 2, in S41, the target ECU of the vehicle 100 executes the activation of the update target (FIG. 2) in response to the request from the ECU 110. The ECU 110 determines, for example, whether the vehicle 100 is in an activatable state, and when it is determined that the vehicle 100 is in an activatable state (for example, a shutdown standby state), requests the activation of the update target from the target ECU.

[0085] In the subsequent S42, the target ECU determines whether the activation of the update target has been successful. If the activation of the update target fails (NO in S42), the target ECU notifies the ECU 110 of the activation failure. The notified ECU 110 requests the target ECU to roll back the update target. Further, the ECU 110 requests the ECU equipped with the microcomputer that cooperates with the update target (that is, the microcomputer operating with the same version of software as the update target) to roll back the microcomputer. Then, the process proceeds to S44.

[0086] If the activation of the update target is successful (YES in S42), in S43, the target ECU further determines whether the microcomputer that cooperates with the update target has failed to be activated. The target ECU may determine whether the microcomputer that cooperates with the update target has failed to be activated based on the presence or absence of the above rollback request from the ECU 110. If any of the microcomputers that cooperate with the update target has failed to be activated (YES in S43), the process proceeds to S44.

[0087] In S44, the target ECU determines whether the update target is a single-bank microcomputer. If the update target is a single-bank microcomputer (YES in S44), the vehicle 100 (target ECU) requests the old software (main body) of the update target from the mobile terminal 300 in S45. Hereinafter, this request (S45) is also referred to as the "second request".

[0088] After the above-mentioned download is completed, the mobile terminal 300 waits for the second request from the vehicle 100 in S21. Specifically, in S21, the mobile terminal 300 determines whether it has received the second request from the vehicle 100 within a predetermined time after the download is completed. If it is determined to be YES in S44, the vehicle 100 executes the second request to the mobile terminal 300 before the above-mentioned predetermined time elapses. As a result, it is determined to be YES in S21, and the process proceeds to S22. On the other hand, if it is determined to be NO in S44, the predetermined time elapses without the mobile terminal 300 receiving the second request, and it is determined to be NO in S21. In this case, the processes of S22 to S24 are not executed, and the process proceeds to S25.

[0089] In S22, the mobile terminal 300 determines whether it holds the old software (main body) of the update target. If the process of S15 in FIG. 3 is executed, it is determined to be YES in S22, and the process proceeds to S24. In this case, in subsequent S24, the mobile terminal 300 transmits the old software (main body) of the update target stored in the memory 320 to the vehicle 100 (target ECU). Then, the process proceeds to S25.

[0090] If the process of S15 in FIG. 3 is not executed (that is, if the process of S16 in FIG. 3 is executed), it is determined as NO in S22, and the process proceeds to S23. In S23, the mobile terminal 300 acquires the old software (main body) to be updated from the OTA center 500 based on the version information of the old software to be updated stored in the memory 320 (S16 in FIG. 3). In this case, in subsequent S24, the mobile terminal 300 transmits the old software (main body) to be updated acquired from the OTA center 500 to the vehicle 100 (target ECU). Then, the process proceeds to S25.

[0091] When the update target is a single-bank microcomputer (YES in S44), the vehicle 100 receives the old software to be updated (S24). As a result, in S46, the target ECU of the vehicle 100 executes a rollback process (a process of reverting to the old software) for the update target using the old software (main body) received from the mobile terminal 300. The target ECU updates the bank (single bank) of the update target to the state before the update while receiving the old software (main body) to be updated from the mobile terminal 300.

[0092] When the update target is a dual-bank microcomputer (NO in S44), without the vehicle 100 receiving the old software to be updated (S24) from the mobile terminal 300, the target ECU of the vehicle 100 executes a rollback process for the update target in S46.

[0093] FIG. 5 is a diagram for explaining the activation (rollback) process of the dual-bank microcomputer provided in the ECU 122. Hereinafter, an example will be described in which the ECU 122 is the target ECU and the dual-bank microcomputer MC2 is the update target.

[0094] Referring to FIG. 5, the ECU 122 includes a dual-bank microcomputer MC2 having two banks (a first bank and a second bank). Specifically, the dual-bank microcomputer MC2 includes two memories (e.g., Flash memories), and each memory forms a bank within the microcomputer. For example, when the first bank is the active side, the second bank becomes the writing side. The old software is stored on the active side (the first bank). The new software is written to the writing side (the second bank) by the above-described download process and installation process (S36 in FIG. 3). Thereafter, the ECU 122 (the target ECU) switches (activates) the writing side of the dual-bank microcomputer MC2 to the active side in S41 of FIG. 4. If the ECU 122 successfully activates the dual-bank microcomputer MC2 and the ECU 122 does not receive a rollback request from the ECU 110, the ECU 122 performs a self-reset and then waits for a shutdown request from the ECU 110. In this case, the first bank that stores the old software becomes the writing side, and the second bank to which the new software is written becomes the active side. That is, the dual-bank microcomputer MC2 is started with the new software (the updated program). On the other hand, if the ECU 122 receives a rollback request from the ECU 110, the ECU 122 executes a rollback process for the dual-bank microcomputer MC2 (S46 in FIG. 4). In this case, the first bank that stores the old software returns to the active side, and the second bank becomes the writing side. Also, the old software is written to the writing side. Thereafter, the dual-bank microcomputer MC2 is started with the old software (the program before update).

[0095] FIG. 6 is a diagram for explaining a first example of the activation (rollback) process of the single-bank microcomputer included in the ECU 121. Hereinafter, an example will be described in which the ECU 121 is the target ECU and the single-bank microcomputer MC1 is the update target. Moreover, in this example, the memory 320 has a free capacity for storing the software (main body) before the update of the single-bank microcomputer MC1 during download.

[0096] Referring to FIG. 6, the ECU 121 includes a single-bank microcomputer MC1 having one bank (single bank). Specifically, the single-bank microcomputer MC1 includes one memory (e.g., Flash memory), and the memory forms a bank within the microcomputer. The single-bank microcomputer MC1 corresponds to a computer that controls the running of the vehicle 100. For example, during normal operation, the bank is on the active side. Before software update, the old software is stored in the bank. When software is updated, the bank becomes the write side. Then, new software is written into the bank by the above-described download process and installation process (S36 in FIG. 3). However, before writing, the old software (the software before update) is stored in the memory 320 of the mobile terminal 300 (S15 in FIG. 3).

[0097] Thereafter, the ECU 121 (target ECU) switches (activates) the write side of the single-bank microcomputer MC1 to the active side in S41 of FIG. 4. When the ECU 121 succeeds in activating the single-bank microcomputer MC1 and the ECU 121 does not receive a rollback request from the ECU 110, the ECU 121 performs a self-reset and then waits for a shutdown request from the ECU 110. In this case, the bank into which the new software is written becomes the active side. That is, the single-bank microcomputer MC1 starts with the new software (the program after update). On the other hand, when the ECU 121 receives a rollback request from the ECU 110, the ECU 121 executes a rollback process for the single-bank microcomputer MC1 (S44 to S46 in FIG. 4). Specifically, the ECU 121 receives the old software (main body) from the mobile terminal 300 (memory 320) and writes the old software into the bank of the single-bank microcomputer MC1. Thereafter, the bank into which the old software is written becomes the active side. In this case, the single-bank microcomputer MC1 starts with the old software (the program before update).

[0098] FIG. 7 is a diagram for explaining a second example of the activation (rollback) process of the single-bank microcomputer included in the ECU 121. In the following, an example will be described in which the ECU 121 is the target ECU and the single-bank microcomputer MC1 is the one to be updated. However, in this example, the memory 320 does not have free capacity for storing the software (main body) before the update of the single-bank microcomputer MC1 at the time of download.

[0099] Referring to FIG. 7, also in this example, at the time of software update, the bank of the single-bank microcomputer MC1 becomes the write surface, and new software is written to that bank by the above-described download process and installation process (S36 in FIG. 3). However, in this example, before the writing, the version information of the old software, rather than the old software main body, is stored in the memory 320 of the mobile terminal 300 (S16 in FIG. 3).

[0100] After that, the ECU 121 (target ECU) switches (activates) the writing surface of the single-bank microcomputer MC1 to the active surface in S41 of FIG. 4. If the ECU 121 successfully activates the single-bank microcomputer MC1 and the ECU 121 does not receive a rollback request from the ECU 110, the ECU 121 enters a state of waiting for a shutdown request from the ECU 110 after performing a self-reset. In this case, the bank in which the new software is written becomes the active surface. That is, the single-bank microcomputer MC1 is started with the new software (updated program). On the other hand, if the ECU 121 receives a rollback request from the ECU 110, the ECU 121 executes a rollback process for the single-bank microcomputer MC1 (S44 to S46 in FIG. 4). Specifically, the ECU 121 requests the old software from the mobile terminal 300 (S45 in FIG. 4). Then, in response to the request from the ECU 121, the mobile terminal 300 acquires the software (main body) of the version indicated by the version information stored in the memory 320 from the OTA center 500 and transmits the acquired software (main body) to the vehicle 100 (ECU 121). The ECU 121 receives the old software (main body) from the mobile terminal 300 and writes the old software to the bank of the single-bank microcomputer MC1. After that, the bank in which the old software is written becomes the active surface. In this case, the single-bank microcomputer MC1 is started with the old software (program before update).

[0101] Referring again to FIGS. 1, 2, and 4, in S46, the target ECU executes the rollback process for the update target as described above. When some failure occurs during activation and the activation of the update target fails, the target ECU may use the pre-update journal file (the file for writing log information) to return the update target to a normal state. When the requested rollback is completed, the target ECU notifies the ECU110 of the completion of the rollback. Upon receiving the notification of the completion of the rollback, the ECU110 requests the target ECU for the identification information (ECU Software ID) of the software before the update. Then, the ECU110 checks whether the identification information received from the target ECU matches the identification information of the software before the update included in the campaign information (configuration check). The success of the configuration check here (i.e., the matching of the software identification information) means that the rollback was successful. If the software identification information does not match, the ECU110 may request the target ECU to perform the rollback again.

[0102] If the rollback is successful, the process proceeds to S47. Also, when the activation of the update target is successful (YES in S42) and none of the microcontrollers that cooperate with the update target have failed in activation (NO in S43), the process proceeds to S47. When the update target includes a plurality of microcontrollers (computers), the processes of S41 to S46 and S21 to S24 are executed for each update target. And when the activation or rollback is successful for all update targets, the vehicle 100 (ECU110) issues an end notification to the mobile terminal 300 in S47. Then, when the process of S47 is executed, the series of processes of S31 to S47 by the vehicle 100 ends.

[0103] In S25, the mobile terminal 300 determines whether it has received the above-mentioned termination notification (S47) from the vehicle 100. If the mobile terminal 300 has not received the above-mentioned termination notification (NO in S25), the process returns to S21. When the mobile terminal 300 receives the above-mentioned termination notification (YES in S25), the series of processes from S11 to S25 by the mobile terminal 300 ends.

[0104] As described above, the software distribution system according to this embodiment includes a mobile terminal 300, a vehicle 100, and an OTA center 500 (server). The mobile terminal 300 includes a processor 310 and a memory 320 (storage unit). The processor 310 is configured to be capable of receiving the software before update of a single-bank type computer mounted on the vehicle 100 from the vehicle 100 (S15 in FIG. 3), storing the received software before update in the memory 320 (S15 in FIG. 3), and then transmitting the software for update acquired from the OTA center 500 to the vehicle 100 (S17 in FIG. 3).

[0105] According to the mobile terminal 300 having the above configuration, when the vehicle 100 fails to update (for example, activate) the software of a single-bank type computer (for example, the single-bank microcomputer MC1 shown in FIG. 6), it is possible to perform a rollback using the software before update stored in the memory 320 of the mobile terminal 300. Thereby, not only the dual-bank type computer mounted on the vehicle 100 but also the single-bank type computer can be suitably updated by OTA technology.

[0106] Further, the processor 310 of the mobile terminal 300 is configured to be capable of obtaining the version information of the software before the update (S16 in FIG. 3) and determining whether the memory 320 (storage unit) has free space for storing the software before the update in the software update of the single-bank type computer (S14 in FIG. 3). When the processor 310 determines that the memory 320 has free space for storing the software before the update (YES in S14 in FIG. 3), it receives the software before the update from the vehicle 100 (S15 in FIG. 3), stores the software before the update in the memory 320 (S15 in FIG. 3), and then transmits the update software obtained from the OTA center 500 to the vehicle 100 (S17 in FIG. 3). When the processor 310 determines that the memory 320 does not have free space for storing the software before the update (NO in S14 in FIG. 3), it obtains the version information of the software before the update (S16 in FIG. 3), stores the version information in the memory 320 (S16 in FIG. 3), and then transmits the update software obtained from the OTA center 500 to the vehicle 100 (S17 in FIG. 3).

[0107] According to the mobile terminal 300 having the above configuration, data for rollback (specifically, the software before the update or its version information) can be appropriately stored according to the free space of the memory 320. When the free space of the memory 320 is sufficiently large, the software before the update itself is stored in the memory 320 in advance, enabling the rollback to be executed early.

[0108] The vehicle 100 according to this embodiment includes an ECU 110 (control device) that manages a software update sequence. The ECU 110 uses the update software received from the mobile terminal 300 to execute a software update for a single-bank type computer (S36 in FIG. 3 and S41 in FIG. 4). If the software update fails, the ECU 110 is configured to receive the software before the update from the mobile terminal 300 and execute a rollback using the software before the update (S44 to S46 in FIG. 4). According to the vehicle 100 having such a configuration, it becomes easier to manage software updates on the vehicle side.

[0109] The processes shown in FIGS. 3 and 4 above can be changed as appropriate. For example, in the above embodiment, in S13 (FIG. 3) and S44 (FIG. 4), it is determined whether the update target is a single-bank microcomputer. However, depending on the vehicle, an ECU equipped with a single-bank microcomputer having a storage unit for rollback may be installed. In a system that distributes software to such a vehicle, in S13 (FIG. 3) and S44 (FIG. 4), it may be determined whether the update target is a single-bank microcomputer that does not have a storage unit for rollback. That is, even if the update target is a single-bank microcomputer, if the update target has a storage unit for rollback, it may be determined as NO in each of S13 (FIG. 3) and S44 (FIG. 4). Examples of single-bank microcomputers having a storage unit for rollback include single-bank microcomputers provided with a storage unit for rollback within the bank and single-bank microcomputers provided with an external storage unit (non-volatile memory) for rollback. Such single-bank microcomputers can perform rollback in a manner similar to that of dual-bank microcomputers.

[0110] FIG. 8 is a flowchart showing a first modification of the process shown in FIG. 3. In this modification, the processor 310 shown in FIG. 1 functions as an example of the "reception unit", "transmission unit", "update unit", and "notification unit" according to the present disclosure, and the memory 320 shown in FIG. 1 functions as an example of the "storage unit" according to the present disclosure.

[0111] Referring to FIGS. 8 together with FIGS. 1 and 2, in this modification, when it is determined as NO in S33, the process does not proceed, and while it is determined as NO in S33, the determination in S33 is repeated. Also, S16A is adopted instead of S16 (FIG. 3). When the memory 320 does not have free capacity for storing the old software (main body) to be updated (NO in S14), the mobile terminal 300 performs a predetermined notification in S16A. Specifically, the mobile terminal 300 displays, for example, the screen Sc1. The screen Sc1 displays a message prompting the user to increase the free capacity of the memory 320. The user can increase the free capacity of the memory 320 by operating the mobile terminal 300 to stop unnecessary applications running on the mobile terminal 300 or deleting unnecessary data stored in the memory 320. While the free capacity of the memory 320 for storing the old software (main body) is insufficient (NO in S14), S14 and S16A are repeated, and the mobile terminal 300 continues to display the screen Sc1 (S16A). Then, when the user increases the free capacity until the free capacity of the memory 320 becomes sufficient in response to the request by the screen Sc1 (YES in S14), the mobile terminal 300 requests the vehicle 100 for the old software (main body) to be updated in S15 (the first request). As a result, it is determined as YES in S33, and the vehicle 100 (ECU 110) transmits the old software (main body) to be updated to the mobile terminal 300 in S34.

[0112] In the first modification described above, in the software update of the single-bank type computer by the processor 310 of the mobile terminal 300, until free space for storing the software before the update is secured in the memory 320 (storage unit) (NO in S14), the mobile terminal 300 repeats the processes of S14 and S16A. As a result, on the vehicle 100 side, S33 is repeated. For this reason, the software update is put on hold. After free space for storing the software before the update is secured in the memory 320 (YES in S14), the mobile terminal 300 permits the software update of the single-bank type computer by the first request (S15). As a result, the process on the vehicle 100 side proceeds to S34, and the software update of the single-bank type computer is executed. By the above-described process, it is possible to suppress the software update from proceeding in a situation where rollback is not possible. Further, in the software update of the single-bank type computer, when the free space in the memory 320 (storage unit) for storing the software before the update is insufficient (NO in S14), the processor 310 is configured to perform a predetermined notification (S16A). By such notification processing, it becomes easier for the user to grasp the situation.

[0113] In the first modification described above, since it is always determined as YES in S22 of FIG. 4, S22 and S23 in FIG. 4 may be omitted, and when it is determined as YES in S21, the process may proceed to S24.

[0114] FIG. 9 is a flowchart showing a second modification of the process shown in FIG. 3. In this modification, the processor 310 shown in FIG. 1 functions as an example of the "transmission unit" and the "acquisition unit" according to the present disclosure, and the memory 320 shown in FIG. 1 functions as an example of the "storage unit" according to the present disclosure.

[0115] Referring to FIG. 9 together with FIGS. 1 and 2, in this modification, S14, S15, S33, and S34 (FIG. 3) are absent. When it is determined as YES in S13, the mobile terminal 300 stores only the version information of the old software to be updated in the memory 320 in S16. The mobile terminal 300 may obtain the version information of the old software to be updated from the vehicle 100. Alternatively, the mobile terminal 300 may extract the version information of the old software to be updated from the campaign information (S12). When the version information of the old software to be updated is stored in the memory 320 by the process of S16, the process proceeds to S17.

[0116] In the software distribution system according to the second modification described above, the mobile terminal 300 includes a processor 310 and a memory 320 (storage unit). Then, the processor 310 is configured to be able to obtain the version information of the software before update of the single-bank type computer mounted on the vehicle 100 (S16), store the version information in the memory 320 (S16), and then transmit the update software obtained from the OTA center 500 (server) to the vehicle 100 (S17).

[0117] According to the mobile terminal 300 having the above configuration, when the software update of the single-bank type computer in the vehicle 100 fails, the mobile terminal 300 can obtain the software before update from the OTA center 500 based on the version information of the software before update stored in the memory 320 in advance. Then, the vehicle 100 can receive the software before update from the mobile terminal 300 and perform a rollback of the single-bank type computer using the software before update. In the second modification described above, since it is always determined as NO in S22 of FIG. 4, S22 of FIG. 4 may be omitted, and when it is determined as YES in S21, the process may proceed to S23.

[0118] The receiving unit, transmitting unit, acquisition unit, determination unit, update unit, and notification unit of the mobile terminal 300 may be implemented by dedicated hardware (electronic circuits) rather than software. In the above-described embodiment, an on-premises server is employed 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 (for example, functions related to software distribution) may be implemented on the cloud by cloud computing. That is, the OTA center 500 may be a cloud server.

[0119] The vehicle may include an OTA master having an OTA access function. The vehicle may include a TCU (Telematics Control Unit) and / or a DCM (Data Communication Module) that perform wireless communication with the OTA center. It is not essential that the vehicle be configured to be capable of autonomous driving. The vehicle may be an xEV (electric vehicle) other than a BEV. The vehicle may include an internal combustion engine (for example, a gasoline engine, a biofuel engine, or a hydrogen engine). The vehicle is not limited to a four-wheel passenger car, and may be a bus or a truck, or a three-wheel xEV. The vehicle may include a flight function. The vehicle may be a vehicle used for MaaS (Mobility as a Service). The vehicle may be a multi-purpose vehicle customized according to the user's purpose of use. The vehicle may be a mobile store vehicle, a robot taxi, an automated guided vehicle (AGV), or an agricultural machine. The vehicle may be a driverless or single-passenger small BEV (for example, a BEV for last-mile use, an electric wheelchair, or an electric scooter).

[0120] The above various modifications may be implemented in any combination.

[0121] The embodiments disclosed this time should be considered as illustrative in all respects and not restrictive. The scope of the present invention is shown not by the description of the above-described embodiments but by the claims, and it is intended that all modifications within the meaning and scope equivalent to the claims are included.

Description of Symbols

[0122] 100 Vehicle, 110, 121, 122 ECU, 111, 310, 510 Processor, 112, 320, 520 Memory, 130 Driving Device, 140 ADS, 150 Start Switch, 170 HMI, 190 Communication Device, 300 Mobile Terminal, 330 Communication Module, 500 OTA Center, 530 Communication Module, MC1 Single-Bank Microcomputer, MC2 Dual-Bank Microcomputer.

Claims

1. A memory unit, a receiving unit that receives, from the vehicle, the software before update of a single-bank type computer mounted on the vehicle, a transmitting unit that, after storing the received software before update in the memory unit, transmits the software for update acquired from a server to the vehicle, A mobile terminal comprising: The mobile terminal has an acquisition unit that acquires version information of the software before update, and a determination unit that determines whether the memory unit has free capacity for storing the software before update in the software update of the single-bank type computer, further comprising: When the determination unit determines that the memory unit has free capacity for storing the software before update, the receiving unit receives the software before update from the vehicle, and the transmitting unit, after storing the software before update in the memory unit, transmits the software for update acquired from the server to the vehicle. When the determination unit determines that the memory unit does not have free capacity for storing the software before update, the acquisition unit acquires the version information of the software before update, and the transmitting unit, after storing the version information in the memory unit, transmits the software for update acquired from the server to the vehicle. A mobile terminal.

2. The mobile terminal according to claim 1, further comprising a notification unit that performs a predetermined notification when the free capacity of the memory unit for storing the software before update is insufficient in the software update of the single-bank type computer.

3. The receiving unit is configured to acquire the software for update from the server by wireless communication, The transmitting unit is configured to transmit to the vehicle by wireless communication. The mobile terminal according to claim 1.

4. A mobile terminal according to any one of claims 1 to 3, the vehicle, the server, comprising: The vehicle includes a control device that manages a software update sequence. The software distribution system, wherein the control device executes software update of the single-bank type computer by using the update software received from the mobile terminal, and when the software update fails, receives the software before the update from the mobile terminal and executes rollback by using the software before the update.

5. The software distribution system according to claim 4, wherein the single-bank type computer is a computer that controls the running of the vehicle.

Images