Vehicle, server, and software update method

Abstract

To provide a vehicle, a server, and a software update method which can perform a preferable software update by OTA technique for a single bank-type computer mounted in a vehicle.SOLUTION: A mobile terminal includes a reception section, an acquisition section, a generation section, and a transmission section. The reception section receives an update software of a single bank-type computer mounted in a vehicle from a server (S16). The acquisition section acquires rollback data (S17). The generation section generates a package including the update software and the rollback data (S18). The transmission section transmits the package to the vehicle (S19).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 Patent Application Laid-Open 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 roughly 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. And 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 in 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 the in-vehicle ECU.

[0009] Currently popular vehicles are equipped with a number of single-bank microcomputers, and software updates of 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] The present disclosure has been made to solve the above problems, and an object thereof is to enable suitable software updates by OTA technology also for a single-bank type computer mounted on a vehicle.

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. (Item 1) The mobile terminal includes a receiving unit, an acquiring unit, a generating unit, and a transmitting unit. The receiving unit is configured to receive software for updating a single-bank type computer mounted on a vehicle from a server. The acquiring unit is configured to acquire rollback data. The generating unit is configured to generate a package including the software for updating and the rollback data. The transmitting unit is configured to transmit the package to the vehicle.

[0012] The server can function as an OTA (Over The Air) center that distributes software. The mobile terminal can mediate communication between the vehicle and the OTA center. In a system including these server, vehicle, and mobile terminal, the mobile terminal can attach rollback data to the software for updating received from the server. As described above, by the mobile terminal sending a package including rollback data together with the software for updating to the vehicle, it becomes possible to perform rollback using the rollback data when the software update of the single-bank type computer mounted on the vehicle fails. Thereby, it also becomes possible to suitably update the software of the single-bank type computer mounted on the vehicle by OTA technology.

[0013] 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.

[0014] The mobile terminal according to Item 1 above may have the configuration according to any one of Items 2 to 7 below.

[0015] (Item 2) The mobile terminal according to Item 1 further has the following characteristics. The rollback data includes a difference file between the software for updating and the software before the update.

[0016] According to the above configuration, the vehicle can perform software update using the update software, and can also perform rollback using the difference file.

[0017] (Item 3) The mobile terminal according to Item 1 further has the following characteristics. The rollback data includes version information of the software before update of a single-bank type computer.

[0018] According to the above configuration, the vehicle can acquire the software before update using the version information of the software before update. Therefore, the rollback of a single-bank type computer can be appropriately performed.

[0019] (Item 4) The mobile terminal according to any one of Items 1 to 3 further has the following characteristics. The mobile terminal further includes a storage unit and an update unit. The update unit holds the software update of the single-bank type computer until free space for generating the aforementioned package is secured in the storage unit in the software update of the single-bank type computer, and permits the software update of the single-bank type computer after free space for generating the package is secured in the storage unit.

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

[0021] (Item 5) The mobile terminal according to any one of Items 1 to 4 further has the following characteristics. The mobile terminal further includes a notification unit. The notification unit is configured to perform a predetermined notification when the free space of the storage unit for generating the aforementioned package is insufficient in the software update of the single-bank type computer.

[0022] According to the above configuration, it becomes easier for the user to grasp the situation. (Item 6) The mobile terminal according to any one of Items 1 to 5 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 a package to a vehicle by wireless communication.

[0023] According to the above configuration, the convenience of the user is improved. (Item 7) The mobile terminal according to any one of Items 1 to 6 is a smartphone.

[0024] According to the above configuration, a system with high user convenience is realized. According to the form according to the second aspect of the present disclosure, the following software distribution system is provided.

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

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

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

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

Effect of the Invention

[0029] According to the present disclosure, even for a single-bank type computer mounted on a vehicle, suitable software updates can be performed by OTA technology.

Brief Description of the Drawings

[0030]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Embodiments for Carrying Out the Invention

[0031] 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 description will not be repeated.

[0032] 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".

[0033] The vehicle 100 is a battery electric vehicle (BEV) that does not include 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 passing through another communication device (that is, a communication device other than the communication device provided in the vehicle 100 itself). Specifically, the vehicle 100 performs wireless communication 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.

[0034] 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 incorporates a computer and has 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.

[0035] 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 flash memory, for example. The communication module 330 includes a communication I / F (interface) for directly performing wireless communication with the OTA center 500. Further, 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 100 (ECU 110) 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.

[0036] 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. The mobile app associates the identification information (terminal ID) of the mobile terminal 300 with the identification information (vehicle ID) of the vehicle 100 and registers it with the OTA center 500. Also, the mobile terminal 300 can exchange information with the OTA center 500 through the mobile app.

[0037] 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.

[0038] 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.

[0039] In the OTA center 500, identification information (vehicle ID) of each vehicle (including the vehicle 100) that receives a 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 regarding 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).

[0040] The vehicle 100 includes a plurality of ECUs (including the ECUs 110, 121, and 122). The number of ECUs included 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. The communication method between the ECUs is not particularly limited, and may be, for example, CAN (Controller Area Network) or Ethernet (registered trademark).

[0041] 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 parked, 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 in motion, 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.

[0042] 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 parked and while in motion. The ECU 110 manages vehicle internal information, receives campaigns, and manages software update sequences. 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 be able to communicate even when they are separated from each other. Also, 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 update) (not shown). 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.

[0043] Vehicle 100 is an autonomous vehicle configured to be capable of autonomous driving. More specifically, vehicle 100 is configured to be capable of performing both manned driving and unmanned driving. 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, vehicle 100 is also capable of performing autonomous driving (e.g., auto cruise control) during manned driving. The level of autonomous driving may be fully autonomous driving (level 5) or conditional autonomous driving (e.g., level 4).

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

[0045] 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 for 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.

[0046] ADS 140 includes a recognition sensor (e.g., at least one of a camera, a millimeter wave radar, a lidar) that recognizes the external environment of the vehicle, and executes processing related to autonomous driving based on information sequentially acquired by the recognition sensor. Specifically, ADS 140 generates a driving plan (information indicating the future behavior of the vehicle) according to the external environment of the vehicle while cooperating with ECU 121. Then, ADS 140 requests ECU 121 to control various actuators included in driving device 130 so that vehicle 100 is driven according to the driving plan.

[0047] 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 that is 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.

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

[0049] 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 in the vehicle interior, for example. Generally, the start switch is referred to as a "power switch" or an "ignition switch". 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 is started, 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").

[0050] The on operation of the start switch 150 is an operation for switching the state of the vehicle from IG off to IG on. When the user turns 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 state of the vehicle from IG on to IG off. When the user turns off the start switch 150, a shutdown request is input to each in-vehicle ECU, and the vehicle 100 enters a shutdown standby state. In this way, each in-vehicle ECU receives the shutdown request from the user. However, in a vehicle that is in motion, the off operation of the start switch 150 is prohibited.

[0051] 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. Further, 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.

[0052] FIG. 2 is a diagram for explaining an outline of the software update method according to this embodiment. Referring to FIG. 1 and FIG. 2 together, the process 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 approval, download, installation, activation, and software update completion notification. The processes described below are executed by the OTA center 500 and each vehicle (including 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.

[0053] The vehicle 100 in the IG-on state repeatedly executes configuration synchronization every time a preset time elapses. Also, the vehicle 100 in the IG-on state executes configuration synchronization even when it receives a configuration synchronization request from the OTA center 500. 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 an RXSWIN for each approval target. The RXSWIN is an identification number that can identify software constituting the function type approval.

[0054] When the OTA center 500 receives the vehicle configuration information from the vehicle 100, it checks the campaigns (software updates) that are currently occurring. If there is a campaign applicable to the vehicle 100, the OTA center 500 sends a commitment request signal to the user of the vehicle 100, requesting commitment for the download of the new software (updated version of the software) related to that campaign. The commitment request signal includes information about that campaign (campaign information). 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 about the campaign target ECU (e.g., software information before and after the update), and information about the notifications 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".

[0055] When the vehicle 100 receives a campaign notification (commitment request signal), it requests the user to input whether to commit to the application of that campaign. Specifically, the vehicle 100 causes, for example, a message such as "New software has been found. Do you want to apply it to this vehicle?" to be displayed on the in-vehicle HMI (e.g., HMI 170), and requests the user to input an indication of either "Commit" or "Reject". When the user inputs an indication of "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 inputs an indication of "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.

[0056] 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.

[0057] The ECU 110 of the vehicle 100 requests the mobile terminal 300 for a delivery package including new software corresponding to each update target. One or more microcomputers (microcontrollers) included in the target ECU (the ECU to be software-updated) are the update targets. For example, the target ECU may be the ECU 121, and the software to be updated may be an automatic driving control program. The delivery package may further include package attribute information (information indicating an update category, the number of update data in the delivery package, the installation order of each ECU, etc.), and update data attribute information (an identifier of the target ECU, verification data for verifying the validity of the update data, etc.).

[0058] The mobile terminal 300 that has received the request for the delivery package from the vehicle 100 transmits the delivery package including the new software to the vehicle 100. The mobile terminal 300 may group the update software into one delivery package and transmit one delivery package including the new software for all update targets to the vehicle 100. Alternatively, the mobile terminal 300 may generate a delivery package including the new software corresponding to each update target for each update target and transmit those delivery packages to the vehicle 100 one by one. Although details will be described later, when the update target includes a single-bank type computer, the mobile terminal 300 that has received the request for the delivery package generates a package (hereinafter, also referred to as an "RB package") including new software and rollback data for that single-bank type computer. Then, the mobile terminal 300 transmits the delivery package including the generated RB package to the vehicle 100. The ECU 110 executes the download (reception and storage) of the above delivery package while performing wireless communication with the OTA center 500 via the mobile terminal 300.

[0059] Through the above-described download process, the distribution package is saved in the storage device (e.g., memory 112) provided in ECU 110. During the download, the in-vehicle HMI notifies the user of the download progress. After the download is completed, ECU 110 verifies the authenticity of the downloaded distribution package. If the verification result is "normal", 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 was successful.

[0060] When the download is successful, vehicle 100 executes the installation. Specifically, ECU 110 requests the target ECU (e.g., 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, ECU 110 determines whether installation can be executed for each target ECU. Then, 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 (writing to the non-volatile memory) of the update data. During the installation, the in-vehicle HMI notifies the user of the installation progress.

[0061] When the transfer of the above update data from ECU 110 to the target ECU is completed, the target ECU sends a transfer completion notification to ECU 110. Then, 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 ECU 110. ECU 110 saves 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", 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 was successful.

[0062] If the installation is successfully completed following the download, the vehicle 100 enters a wait - for - activation state. After that, when the start switch 150 of the vehicle 100 is turned off, the ECU 110 causes the in - vehicle HMI to display an activation approval screen and requests the user to input either "approve" or "reject". The activation approval screen may display the limitations of the vehicle 100 (for example, the vehicle cannot be used for a certain period of time, or the operation of high - current devices is restricted). The activation approval screen may request the user to keep the vehicle 100 in a non - running state (for example, shutdown standby state, parking range fixed, or electric parking brake actuated) until the activation is completed. The activation approval screen may display a message prompting the user to check the state of the vehicle 100.

[0063] When the user inputs "approve" with respect to the activation approval screen, the ECU 110 requests each target ECU to activate (enable the installed software). On the other hand, when the user inputs "reject" with respect to the activation approval screen, the ECU 110 aborts the process related to the software update without performing the activation, and the vehicle system is shut down.

[0064] The target ECU executes the activation in response to the request from the ECU 110. In a target ECU having a plurality of microcontrollers (for example, a main microcontroller and a sub - microcontroller), the sub - microcontroller in the target ECU may perform the rewriting by means of the Flash rewriting function of the main microcontroller in the target ECU. Alternatively, each microcontroller in the target ECU may directly communicate with the ECU 110 to perform the rewriting.

[0065] 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 the rewriting of all microcontrollers (targets for update) in the target ECU is completed, those microcontrollers are reset and started up (self-reset) synchronously, and the updated software is started. After the self-reset is completed, the target ECU waits for a shutdown request from ECU110. The target ECU in such a state can continue diagnostic communication with ECU110.

[0066] 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 (that is, if the software identification information matches), ECU110 updates RXSWIN. The update of RXSWIN means that activation has been successful.

[0067] 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 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 notification of software update completion 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. After that, when an on operation is performed on the start switch 150 of the vehicle 100, the vehicle system turns on the ignition. Thereby, the update program (new version of software) is started 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-described automatic driving control program and is arbitrary. For example, the OTA center 500 may distribute software related to entertainment.

[0068] Incidentally, 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 overwriting is performed in one bank. For this reason, no old software remains. In a single-bank microcomputer, there may arise a problem that it is impossible to revert to the old software (rollback) when activation fails.

[0069] 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.

[0070] In the software distribution system according to this embodiment, the microcontroller to be updated (the target of software update) is at least one of a single-bank microcontroller and a dual-bank microcontroller included in the target ECU. Although details will be described later, in vehicle 100, ECU 121 incorporates a single-bank microcontroller and ECU 122 incorporates a dual-bank microcontroller. 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 microcontrollers that execute control in cooperation with each other, it is required to align the software versions. In these microcontrollers, software version updates (software updates) are executed simultaneously, and when activation fails in any of these microcontrollers, a process of reverting to the old software (rollback process) is executed for all microcontrollers.

[0071] 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", "acquisition unit", "generation unit", "update unit", "notification unit", and "transmission 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.

[0072] Referring to FIGS. 3 together with FIGS. 1 and 2, a series of processes S11 to S20 are executed by the mobile terminal 300. A series of processes S31 to S34 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. After that, when it is the execution timing of configuration synchronization, the series of processes shown in FIG. 3 is started again.

[0073] 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 for generating an RB package (see S18 described later). The mobile terminal 300 may acquire the data size of the new software for the update target from the OTA center 500. Alternatively, the mobile terminal 300 may extract information on the new software from the campaign information (S12).

[0074] If the memory 320 has free space for generating the RB package (YES in S14), the process proceeds to S16. On the other hand, if the memory 320 does not have free space for generating the RB package (NO in S14), the mobile terminal 300 gives a predetermined notification in S15. Specifically, the mobile terminal 300 displays a message prompting the user to increase the free space of the memory 320. The user can increase the free space of the memory 320 by operating the mobile terminal 300 to stop unnecessary applications running on the mobile terminal 300 or delete unnecessary data stored in the memory 320. While the free space of the memory 320 for generating the RB package is insufficient (NO in S14), S14 and S15 are repeated, and the mobile terminal 300 continues the above notification. Then, when the user increases the free space until the free space of the memory 320 becomes sufficient in response to the above message (request for increasing free space) (YES in S14), the process proceeds to S16.

[0075] In S16, the mobile terminal 300 acquires new software to be updated (the software body of the new version) from the OTA center 500 by wireless communication. Subsequently, in S17, the mobile terminal 300 acquires the version information of the old software to be updated (information indicating the version of the software before the update). The mobile terminal 300 may acquire the version information of the old software to be updated from the vehicle 100 by wireless communication. Alternatively, the mobile terminal 300 may extract the version information of the old software to be updated from the campaign information (S12).

[0076] Subsequently, in S18, the mobile terminal 300 generates an RB package including new software to be updated (update software) and version information of the old software to be updated (rollback data). The mobile terminal 300 may create a single package by adding the version information of the old software to the new software. Subsequently, in S19, the mobile terminal 300 transmits the distribution package including the RB package (S18) to the vehicle 100 via wireless communication.

[0077] When the update target is not a single-bank microcontroller (NO in S13), in S20, the mobile terminal 300 receives a distribution package including new software to be updated (the software body of the new version) from the OTA center 500 via wireless communication, and transmits the received new software to the vehicle 100 via wireless communication.

[0078] After the vehicle 100 (ECU110) receives an input indicating the above-mentioned "approval" from the user, in S33, it waits for the above distribution package from the mobile terminal 300. If 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. When the vehicle 100 receives the above distribution package from the mobile terminal 300 (YES in S33), the ECU110 executes download and installation of new software for the update target (Figure 2) in S34.

[0079] When the update target includes a plurality of microcontrollers (computers), the processes of S13 to S20 and S33, S34 are executed for each update target. When the update target is a single-bank microcontroller (YES at S13), after the mobile terminal 300 generates the RB package of the update target by the processes of S16 to S18 as described above, in S19, it transmits the distribution package including the RB package to the vehicle 100. On the other hand, when the update target is a dual-bank microcontroller (NO at S13), without performing the processes of S16 to S18, the mobile terminal 300 transmits a distribution package not including rollback data to the vehicle 100 in S20.

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

[0081] Referring to FIG. 4 together with FIGS. 1 and 2, in S41, the target ECU of the vehicle 100 executes the activation (FIG. 2) of the update target 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 determines that the vehicle 100 is in an activatable state (for example, a shutdown standby state), it requests the activation of the update target to the target ECU.

[0082] In the subsequent S42, the target ECU determines whether or not 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 ECU110 of the activation failure. The notified ECU110 requests the target ECU to roll back the update target. Further, the ECU110 requests the ECU equipped with the microcomputer that cooperates with the update target (i.e., the microcomputer operating with the same version of software as the update target) to roll back the microcomputer. Thereafter, the process proceeds to S44.

[0083] If the activation of the update target is successful (YES in S42), in S43, the target ECU further determines whether or not the microcomputer that cooperates with the update target has failed to be activated. The target ECU may determine whether or not 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 ECU110. If any of the microcomputers that cooperate with the update target has failed to be activated (YES in S43), the process proceeds to S44.

[0084] In S44, the target ECU determines whether or not 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) transmits, in S45, a signal (hereinafter referred to as "SW request signal") for requesting the old software (main body) of the update target to the mobile terminal 300. The SW request signal includes the version information (rollback data) of the old software of the update target included in the RB package.

[0085] After the aforementioned download is completed, the mobile terminal 300 waits for the SW request signal from the vehicle 100 in S21. Specifically, in S21, the mobile terminal 300 determines whether it has received the SW request signal 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 transmits the SW request signal to the mobile terminal 300 before the 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 vehicle 100 transmitting the SW request signal, and it is determined to be NO in S21. In this case, the processes of S22 and S23 are not executed, and the process proceeds to S24.

[0086] In S22, the mobile terminal 300 acquires the old software (main body) to be updated from the OTA center 500 based on the version information (rollback data) of the old software to be updated indicated by the SW request signal. Subsequently, in S23, 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 S24.

[0087] When the update target is a single-bank microcontroller (YES in S44), the vehicle 100 receives the old software to be updated (S23). As a result, 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 in S46. While receiving the old software (main body) to be updated from the mobile terminal 300, the target ECU reverts the bank (single bank) of the update target to the state before the update using the received old software (main body).

[0088] When the update target is a dual - bank microcomputer (NO at S44), without the vehicle 100 receiving the old software (S23) of the update target from the mobile terminal 300, the target ECU of the vehicle 100 executes the roll - back process of the update target at S46.

[0089] FIG. 5 is a diagram for explaining the activation (roll - back) process of the dual - bank microcomputer included in the ECU122. Hereinafter, an example will be described in which the ECU122 is the target ECU and the dual - bank microcomputer MC2 is the update target.

[0090] 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 write side. The old software is stored on the active side (the first bank). The new software is written to the write side (the second bank) by the aforementioned download process and installation process (S34 in FIG. 3). Thereafter, the ECU 122 (the target ECU) switches (activates) the write side of the dual-bank microcomputer MC2 to the active side in S41 of FIG. 4. When 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 enters a state of waiting for a shutdown request from the ECU 110 after performing a self-reset. In this case, the first bank that stores the old software becomes the write side, and the second bank to which the new software is written becomes the active side. That is, the dual-bank microcomputer MC2 starts up with the new software (the updated program). On the other hand, when 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 write side. Also, the old software is written to the write side. Thereafter, the dual-bank microcomputer MC2 starts up with the old software (the program before the update).

[0091] FIG. 6 is a diagram for explaining 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.

[0092] 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. During software update, the bank becomes the write side. Then, new software is written into the bank by the above-described download process and installation process (S34 in FIG. 3). However, in this embodiment, the mobile terminal 300 generates an RB package and transmits a distribution package including the RB package to the vehicle 100 before writing the new software (S16 to S19 in FIG. 3). Also, when the free capacity of the memory 320 is insufficient, the mobile terminal 300 prompts the user to increase the free capacity of the memory 320, for example, by displaying the screen Sc1, before generating the above-described RB package (S15 in FIG. 3).

[0093] On the write side of the bank of the single-bank microcomputer MC1, old version information (version information of the old software) is written continuously to the new software. 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. If 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 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 (updated program).

[0094] When the other party, ECU121, receives a rollback request from ECU110, ECU121 executes the rollback process of the single-bank microcomputer MC1 (S44 to S46 in FIG. 4). Specifically, ECU121 specifies a version and requests the old software from the mobile terminal 300 (S45 in FIG. 4). The version of the software requested by ECU121 is specified by the above old version information. Then, the mobile terminal 300 obtains the software (main body) of the specified version from the OTA center 500 in response to the request from ECU121 (S22 in FIG. 4), and transmits the obtained software (main body) to the vehicle 100 (ECU121) (S23 in FIG. 4). ECU121 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 written with the old software becomes the active side. In this case, the single-bank microcomputer MC1 is started with the old software (the program before the update).

[0095] Referring again to FIG. 4 together with FIGS. 1 and 2, in S46, the target ECU executes the rollback process of 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 journal file (the file for writing log information) before the update to return the update target to a normal state. When the requested rollback is completed, the target ECU notifies ECU110 of the completion of the rollback. When receiving the notification of the completion of the rollback, ECU110 requests the target ECU for the identification information (ECU Software ID) of the software before the update. Then, 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 (that is, the matching of the software identification information) means that the rollback has been successful. If the software identification information does not match, ECU110 may request the target ECU to redo the rollback.

[0096] If the rollback is successful, the process proceeds to S47. Also, when the activation of the update target is successful (YES at S42) and none of the microcontrollers that cooperate with the update target have failed in activation (NO at 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 S23 are executed for each update target. Then, when the activation or rollback is successful for all update targets, the vehicle 100 (ECU 110) sends an end notification to the mobile terminal 300 at S47. When the process of S47 is executed, the series of processes of S31 to S47 by the vehicle 100 ends.

[0097] At S24, the mobile terminal 300 determines whether it has received the above end notification (S47) from the vehicle 100. If the mobile terminal 300 has not received the above end notification (NO at S24), the process returns to S21. When the mobile terminal 300 receives the above end notification (YES at S24), the series of processes of S11 to S24 by the mobile terminal 300 ends.

[0098] As described above, the software distribution system according to this embodiment includes the mobile terminal 300, the vehicle 100, and the 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 able to receive the update software for the single-bank type computer mounted on the vehicle 100 from the OTA center 500 (S16 in FIG. 3), acquire rollback data (for example, the version information of the software before the update of the single-bank type computer) (S17 in FIG. 3), generate an RB package including the update software and the rollback data (S18 in FIG. 3), and transmit a distribution package including the generated RB package to the vehicle 100 (S19 in FIG. 3).

[0099] The mobile terminal 300 having the above configuration can attach rollback data to the software for update received from the OTA center 500. As described above, when the mobile terminal 300 sends a package including the rollback data together with the update software to the vehicle 100, the vehicle 100 can perform a rollback using the rollback data when the software update (for example, activation) of a single-bank type computer (for example, the single-bank microcomputer MC1 shown in FIG. 6) fails. Thereby, not only the dual-bank type computer mounted on the vehicle 100 but also the single-bank type computer can be suitably updated with software by the OTA technology.

[0100] Also, in the software update of the single-bank type computer, the processor 310 of the mobile terminal 300 repeats the processes of S14 and S15 until free capacity for generating the RB package is secured in the memory 320 (storage unit) (NO in S14). As a result, on the vehicle 100 side, S33 is repeated. Therefore, the software update is put on hold. After free capacity for generating the RB package is secured in the memory 320 (YES in S14), the mobile terminal 300 permits the software update of the single-bank type computer by transmitting the distribution package (S19). Thereby, 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 suppressed that the software update proceeds in a situation where a rollback cannot be performed. Further, in the software update of the single-bank type computer, when the free capacity of the memory 320 (storage unit) for generating the RB package is insufficient (NO in S14), the processor 310 is configured to perform a predetermined notification (S15). By such notification processing, it becomes easier for the user to grasp the situation.

[0101] The vehicle 100 according to this embodiment includes an ECU 110 (control device) that manages the software update sequence. The ECU 110 uses the update software received from the mobile terminal 300 to execute the software update of the single-bank type computer (S34 in FIG. 3 and S41 in FIG. 4). If the software update fails, it is configured to execute a rollback using rollback data (for example, the version information of the software before the update of the single-bank type computer) (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.

[0102] 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, it may be determined in S13 (FIG. 3) and S44 (FIG. 4) 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 in 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 dual-bank microcomputers.

[0103] The rollback data is not limited to the old version information described above. Any data used for rollback can be adopted as rollback data. Hereinafter, with reference to FIGS. 7 to 9, a modified example in which a difference file between new software (software for update) and old software (software before update) is adopted as rollback data will be described.

[0104] FIG. 7 is a flowchart showing a modified example of the process shown in FIG. 3. Referring to FIG. 7 together with FIGS. 1 and 2, in this modified example, S16A to S18A are adopted instead of S16 to S18 (FIG. 3). In S16A, the mobile terminal 300 acquires the new software (software body of the new version) to be updated from the OTA center 500 by wireless communication, and acquires the old software (software body of the version before update) to be updated from the vehicle 100 by wireless communication. Subsequently, in S17A, the mobile terminal 300 generates a difference file between the new software to be updated and the old software to be updated based on the above new software and old software. The difference file indicates the difference between the new software and the old software. Therefore, the old software is derived from the new software and the difference file. Also, the new software is derived from the old software and the difference file. Subsequently, in S18A, the mobile terminal 300 generates an RB package including the new software (software for update) to be updated and the difference file (rollback data). Subsequently, in S19, the mobile terminal 300 transmits a distribution package including the RB package (S18A) to the vehicle 100 by wireless communication. In this modified example, when the processes of S19 or S20 are executed for all update targets, the process related to software update by the mobile terminal 300 ends.

[0105] When the vehicle 100 receives the above distribution package (S19 or S20) from the mobile terminal 300 (YES in S33), the ECU 110 executes the download and installation of new software in S34. After that, the ECU 110 starts a series of processes shown in FIG. 8 described below. FIG. 8 is a flowchart showing a modified example of the process of the vehicle 100 shown in FIG. 4.

[0106] Referring to FIG. 8 together with FIGS. 1 and 2, in this modified example, S461 and S462 are adopted instead of S45 to S47 (FIG. 4). The target ECU executes the activation of the update target in S41. Then, when the target ECU receives a rollback request from the ECU 110 in S42 or S43 similar to the process shown in FIG. 4, the process proceeds to S44. The target ECU determines whether the update target is a single-bank microcomputer in S44. And when the update target is a single-bank microcomputer (YES in S44), the target ECU of the vehicle 100 executes a rollback process (a process of returning to the old software) of the update target using the above-mentioned difference file (rollback data) in S461. On the other hand, when the update target is not a single-bank microcomputer (NO in S44), the target ECU of the vehicle 100 executes a rollback process of the update target using the data of another bank of the update target (for example, the original version of the software left on the active side) in S462 (see FIG. 5).

[0107] FIG. 9 is a diagram for explaining the process of S461 (rollback process of the single-bank microcomputer). Referring to FIG. 9, on the writing surface of the bank of the single-bank microcomputer MC1, rollback data (difference file between the new software to be updated and the old software to be updated) is continuously written to the new software. Then, the ECU121 (target ECU) switches (activates) the writing surface of the single-bank microcomputer MC1 to the active surface in S41 of FIG. 8. When the ECU121 successfully activates the single-bank microcomputer MC1 and the ECU121 does not receive a rollback request from the ECU110, the ECU121 enters a state of waiting for a shutdown request from the ECU110 after performing a self-reset. In this case, the bank on which the new software is written becomes the active surface. That is, the single-bank microcomputer MC1 starts with the new software (updated program).

[0108] On the other hand, when the ECU121 receives a rollback request from the ECU110, the ECU121 executes the rollback process of the single-bank microcomputer MC1 (S461 in FIG. 8). Specifically, the ECU121 uses the above difference file to revert the new software to the old software. Then, the bank rewritten with the old software becomes the active surface. In this case, the single-bank microcomputer MC1 starts with the old software (program before update).

[0109] Also, with the software distribution system according to the above modification example, it is possible to perform suitable software update by OTA technology for the single-bank type computer mounted on the vehicle 100. Further, according to the above software distribution system, even when the mobile terminal 300 and the vehicle 100 cannot communicate due to a communication failure or the like after the mobile terminal 300 sends a package to the vehicle 100, the vehicle 100 can perform a rollback.

[0110] The receiving unit, acquisition unit, generation unit, update unit, notification unit, and transmission unit of the mobile terminal 300 may be implemented not by software but by dedicated hardware (electronic circuits). Also, in the above embodiment, an on-premises server is adopted as the OTA center 500 (see FIG. 1). However, the present invention is not limited to this, and the functions of the OTA center 500 (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.

[0111] 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 performs wireless communication with the OTA center. It is not essential for the vehicle to be configured to be capable of autonomous driving. The vehicle may be an xEV (electric vehicle) other than a BEV. The vehicle may 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 have 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 an unmanned or single-passenger small BEV (for example, a BEV for last-mile, an electric wheelchair, or an electric scooter).

[0112] The above various modifications may be implemented in any combination. 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 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 Reference Numerals

[0113] 100 vehicles, 110, 121, 122 ECUs, 111, 310, 510 processors, 112, 320, 520 memories, 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

[Claim 1] a receiving unit that receives update software for a single bank type computer mounted on the vehicle from a server; An acquisition unit for acquiring rollback data; a generating unit that generates a package including the update software and the rollback data; a transmitting unit that transmits the package to the vehicle; A mobile terminal comprising:

Images