Mobile terminals, software distribution systems

Abstract

To make it possible to suitably update software by an OTA technique even in a single bank type computer mounted on a vehicle.SOLUTION: A mobile terminal includes a reception unit, an acquisition unit, a generation unit, and a transmission unit. The reception unit is configured to receive, from a server, update software for a single-bank type computer mounted on a vehicle (S16). The acquisition unit is configured to obtain rollback data (S17). The generation unit is configured to generate a package including the update software and rollback data (S18). The transmission unit is configured to transmit 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 technology]

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

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

[0004] A vehicle can download new software for its onboard ECU from the OTA center by wirelessly communicating with the OTA center. Then, in the vehicle, the target ECU (the ECU that is the subject of the software update) installs and activates the software, thereby updating the software.

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

[0006] In a dual bank microcontroller, two memories form two banks. In a dual bank microcontroller, if activation fails, it is possible to revert (roll back) to the original version of the software. Specifically, the original version of the software is left on the active side, and a new version of the software is written to the write side. Then, if activation of the write side fails, a rollback is performed using the original version of the software left on the active side.

[0007] In a single-bank microcontroller, one bank is formed by one memory. In a single-bank microcontroller, software is overwritten in one bank. As a result, the original version of the software does not remain. With a single-bank microcontroller, there is a problem in that if activation fails, it is not possible to revert to the original version of the software (roll back).

[0008] To address this issue, it is possible to consider changing the single-bank microcontroller to a dual-bank microcontroller, providing a memory section for rollback within the bank of the single-bank microcontroller, or providing the single-bank microcontroller with external non-volatile memory for rollback (e.g., Flash memory). However, these design changes would result in a significant increase in the cost of the in-vehicle ECU.

[0009] Currently, most vehicles are equipped with multiple single-bank microcontrollers, and software updates for these microcontrollers are often performed at dealerships. However, there is a need to use OTA technology to easily perform software updates for single-bank microcontrollers at the vehicle user's discretion.

[0010] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to enable suitable software updates using OTA technology even for single-bank type computers installed in vehicles. [Means for solving the problem]

[0011] According to an embodiment of a first aspect of the present disclosure, there is provided a mobile terminal as described below. (Article 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 update software for a single bank type computer installed in 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 update software 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 the server, the vehicle, and the mobile terminal, the mobile terminal can add rollback data to the update software received from the server. As described above, the mobile terminal can send a package including the rollback data together with the update software to the vehicle, so that if the vehicle fails to update the software of the single bank type computer, the rollback can be performed using the rollback data. This enables suitable software updates using OTA technology for single bank type computers installed in vehicles.

[0013] A 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 described in the above paragraph 1 may have the configuration described in any one of paragraphs 2 to 7 below.

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

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

[0017] (3) The mobile terminal according to the first aspect further has the following features: The rollback data includes version information of the software before the update of the single-bank type computer.

[0018] According to the above configuration, the vehicle can acquire the pre-update software by using the version information of the pre-update software, and therefore can appropriately perform rollback of the single-bank type computer.

[0019] (4) The mobile terminal according to any one of the above items 1 to 3 further has the following features. The mobile terminal further includes a storage unit and an update unit. The update unit is configured to suspend a software update of a single-bank type computer until free space for generating the package is secured in the storage unit, and to permit 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 update software in a single-bank type computer.

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

[0022] According to the above configuration, the user can easily understand 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 obtain update software from the server by wireless communication. The transmitting unit is configured to transmit the package to the vehicle by wireless communication.

[0023] According to the above configuration, user convenience 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 that is highly convenient for the user is realized. According to an embodiment of the second aspect of the present disclosure, there is provided a software distribution system as described below.

[0025] (Article 8) The software distribution system includes the mobile terminal according to any one of paragraphs 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 a software update of a single-bank type computer using update software received from the mobile terminal, and to execute a rollback using rollback data if the software update fails.

[0026] According to the above software distribution system, software updates can be easily managed 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 controls the running of a vehicle.

[0028] According to the above configuration, if the update of the driving control related software fails, the software before the update can be restored (rolled back). The vehicle can be driven in the same way as before with the software before the update. This provides peace of mind to the user. Effect of the Invention

[0029] According to the present disclosure, suitable software updates using OTA technology are possible even for single-bank type computers installed in vehicles. [Brief description of the drawings]

[0030] [Figure 1] 1 is a diagram illustrating a schematic configuration of a software distribution system according to an embodiment of the present disclosure. [Diagram 2] FIG. 1 is a diagram for explaining an overview of a software update method according to an embodiment of the present disclosure. [Diagram 3] 1 is a first flowchart showing a processing procedure of a software updating method according to an embodiment of the present disclosure. [Figure 4] 11 is a second flowchart showing the processing procedure of the software updating method according to the embodiment of the present disclosure. [Diagram 5] 5 is a diagram for explaining the process shown in FIG. 4, in particular the activation (rollback) process of the dual bank microcomputer included in the target ECU. FIG. [Figure 6] 5 is a diagram for explaining the process shown in FIG. 4, particularly the activate (rollback) process of the single-bank microcomputer included in the target ECU. FIG. [Figure 7] 4 is a flowchart showing a modified example of the process shown in FIG. 3. [Figure 8] 5 is a flowchart showing a modified example of the process of the vehicle shown in FIG. [Figure 9] 9 is a diagram for explaining the process shown in FIG. 8, particularly the rollback process of the single-bank microcomputer. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0032] Fig. 1 is a diagram showing a configuration of a 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 an electric vehicle (BEV) that does not have an internal combustion engine. The vehicle 100 according to this embodiment does not have an OTA access function (a function for directly wirelessly communicating with the OTA center 500), and cannot communicate with the OTA center 500 unless it goes through another communication device (i.e., a communication device other than the communication device provided in the vehicle 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.

[0034] The mobile terminal 300 is configured to be portable by a user. The mobile terminal 300 is carried and operated by a user (vehicle manager) of the vehicle 100. In this embodiment, a smartphone equipped with a touch panel display is adopted as the mobile terminal 300. The smartphone has a built-in computer and a speaker function. However, the present invention is not limited to this, and any terminal that can be carried by the user of the vehicle 100 can be adopted as the mobile terminal 300. For example, a laptop, a tablet terminal, a portable game console, a wearable device (such as a smart watch, smart glasses, or smart gloves), etc. can also be adopted as the mobile terminal 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, for example, a non-volatile memory such as a flash memory. The communication module 330 includes a communication I / F (interface) for performing direct wireless communication with the OTA center 500. The communication module 330 also includes a communication I / F for performing direct wireless communication with the vehicle 100. The mobile terminal 300 mediates communication between the vehicle 100 and the OTA center 500. For example, the mobile terminal 300, in response to a request from the vehicle 100, specifies the address of the OTA center 500 and accesses the communication network NW, thereby enabling the vehicle 100 (ECU 110) to communicate with the OTA center 500 via the mobile terminal 300 (communication module 330). This establishes wireless communication between the vehicle 100 and the OTA center 500.

[0036] Application software (hereinafter, referred to as a "mobile app") for using services provided by the OTA center 500 is installed in the mobile terminal 300. The mobile app associates identification information (terminal ID) of the mobile terminal 300 with identification information (vehicle ID) of the vehicle 100 and registers the same in the OTA center 500. The mobile terminal 300 can also 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 perform a remote update of the vehicle-mounted ECU software from the center via a communication section. The OTA center 500 distributes the software of the vehicle-mounted ECU. Note that "ECU" means an electronic control unit (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, for example, a non-volatile memory such as a flash memory. The communication module 530 is connected to a communication network NW by wire and communicates with a plurality of mobile terminals (including the mobile terminal 300) via the communication network NW. The communication network NW is, for example, a wide area network constructed by the Internet and a wireless base station. The communication network NW may include a mobile phone network.

[0039] 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 in the OTA center 500. A storage device (for example, memory 520) of the OTA center 500 stores information about each vehicle (hereinafter also referred to as "vehicle information") classified by the 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] Vehicle 100 includes multiple ECUs (including ECUs 110, 121, and 122). The number of ECUs included in vehicle 100 is arbitrary. Each vehicle-mounted ECU includes a built-in computer including at least one processor and at least one memory. Each vehicle-mounted ECU may include multiple microcomputers (microcomputers) in the form of a main microcomputer and a sub-microcomputer. In vehicle 100, ECUs are connected to each other via a communication bus and are configured to be able to communicate with each other via a wired connection. The communication method between 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, for example, a non-volatile memory such as a flash memory. 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 performing direct wireless communication with the mobile terminal 300. The communication device 190 and the mobile terminal 300 may perform short-range communication such as 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 present inside the vehicle or within a range around 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 through the communication device 190. In addition, while the vehicle 100 is traveling, the mobile terminal 300 in 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 able to wirelessly communicate with the OTA center 500 via the mobile terminal 300. The vehicle 100 can communicate with the OTA center 500 both when the vehicle is stopped and when the vehicle is running. The ECU 110 manages in-vehicle information, receives campaigns, and manages software update sequences. The communication method between the vehicle 100 and the mobile terminal 300 is not limited to the short-distance communication. The vehicle 100 and the mobile terminal 300 may be configured to be able to communicate with each other even when they are apart from each other. 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) in the vehicle not shown via the communication device 190.

[0043] 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 both manned and unmanned driving. The vehicle 100 is configured to be capable of autonomous driving without a driver, but can also be driven manually by a user (manned driving). The vehicle 100 can also perform autonomous driving (e.g., auto cruise control) while being manned. The level of autonomous driving may be fully autonomous (level 5) or conditionally autonomous (e.g., level 4).

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

[0045] The driving device 130 includes an accelerator, a brake, and a steering device. The accelerator includes, for example, a motor generator (hereinafter, referred to as "MG") that rotates the drive wheels of the vehicle, a PCU (Power Control Unit) that drives the MG, and a battery that supplies the PCU with power to drive the MG. The MG functions as a motor for driving the vehicle. The brake 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] The ADS 140 includes a recognition sensor (e.g., at least one of a camera, a millimeter wave radar, and a lidar) that recognizes the external environment of the vehicle, and executes processing related to autonomous driving based on information sequentially acquired by the recognition sensor. Specifically, the 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 the ECU 121. Then, the ADS 140 requests the ECU 121 to control various actuators included in the driving device 130 so as to drive the vehicle 100 according to the driving plan.

[0047] In this embodiment, the ADS is built into the vehicle. However, the present invention 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 rooftop 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 that allows the user to start the vehicle system (the control system of the vehicle 100), and is installed, for example, inside the vehicle cabin. The start switch is generally called a "power switch" or an "ignition switch." The user operates the start switch 150 to switch the vehicle system (including each ECU mounted on the vehicle) between on (operating) and off (stopped). When the start switch 150 is turned on, the vehicle system in a stopped state starts up, and the vehicle system goes into an operating state (hereinafter also referred to as "IG on"). When the start switch 150 is turned off while the vehicle system is operating, the vehicle system goes into 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 on-board ECU. That is, each on-board ECU accepts 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 on-board ECU, and the vehicle 100 enters a shutdown standby state. In this way, each on-board ECU accepts the shutdown request from the user. However, the off operation of the start switch 150 is prohibited when the vehicle is running.

[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 ten-tail as a display device. The HMI 170 may include a steering switch as an input device. In addition, at least one of an IVI (In-Vehicle Infotainment) system, a meter panel, and a head-up display may function as the HMI 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 a software update method according to this embodiment. With reference to Fig. 2 together with Fig. 1, the process related to the software update (more specifically, the update of vehicle software using OTA) is performed in the steps of configuration synchronization, campaign notification and application consent, download, installation, activation, and software update completion notification. The process 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 that receive distribution from the OTA center 500 may be about 50 vehicles, may be between 100 and 1000 vehicles, or may be 1000 or more.

[0053] The vehicle 100 in the IG on state repeatedly executes configuration synchronization every time a preset time elapses. The vehicle 100 in the IG on state also executes configuration synchronization when a configuration synchronization request is received 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 hardware model number, ECU identifier, etc.) and software information (information indicating the software model number, etc.) for each ECU included in the vehicle 100. In this embodiment, the vehicle configuration information further includes an RXSWIN for each approval target. RXSWIN is an identification number capable of identifying software that constitutes functional type approval.

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

[0055] When the vehicle 100 receives the campaign notification (acceptance request signal), it requests the user to input whether or not to accept the application of the campaign. Specifically, the vehicle 100 displays a message such as "New software has been found. Do you want to apply it to this vehicle?" on the in-vehicle HMI (e.g., HMI 170) and requests the user to input either "accept" or "reject." Then, when the user inputs "accept" to the in-vehicle HMI, the vehicle 100 executes the process related to downloading described below. On the other hand, when the user inputs "reject" to the in-vehicle HMI, the vehicle 100 does not execute the process related to downloading. In this case, the OTA center 500 ends the process 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 process related to downloading in the procedure described below.

[0057] The ECU 110 of the vehicle 100 requests the mobile terminal 300 for a distribution package including new software corresponding to each update target. One or more microcomputers (microcomputers) included in the target ECU (ECU subject to software update) 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 distribution package may further include package attribute information (information indicating the update category, the number of update data in the distribution package, the installation order of each ECU, etc.) and update data attribute information (identifier of the target ECU, verification data for verifying the validity of the update data, etc.).

[0058] The mobile terminal 300, which has received the request for the distribution package from the vehicle 100, transmits a distribution package including new software to the vehicle 100. The mobile terminal 300 may collect update software into one distribution package and transmit the one distribution package including new software for all update targets to the vehicle 100. Alternatively, the mobile terminal 300 may generate a distribution package including new software corresponding to each update target for each update target and transmit the distribution packages one by one to the vehicle 100. As will be described in detail later, when the update target includes a single bank type computer, the mobile terminal 300, which has received the request for the distribution package, generates a package including new software and rollback data for the single bank type computer (hereinafter, also referred to as an "RB package"). Then, the mobile terminal 300 transmits the distribution package including the generated RB package to the vehicle 100. The ECU 110 downloads (receives and stores) the distribution package while wirelessly communicating with the OTA center 500 via the mobile terminal 300.

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

[0060] If the download is successful, the vehicle 100 executes the installation. Specifically, the ECU 110 requests the target ECU (e.g., the ECU 121) to output the state of the target ECU and a DTC (Diagnostic Trouble Code). The ECU 110 determines whether or not the installation can be executed for each target ECU based on the state of the target ECU and the DTC. The ECU 110 then transfers the new software (update data) to the target ECUs for which the installation can be executed. The target ECU that receives the update data executes the installation of the update data (writing it into a non-volatile memory). During the installation, the in-vehicle HMI notifies the user of the progress of the installation.

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

[0062] If the download and installation are successful, the vehicle 100 enters a state of 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 "consent" or "rejection." The activation consent screen may display restrictions on the vehicle 100 (e.g., the vehicle cannot be used for a certain period of time, or the operation of an overcurrent device is restricted). The activation consent screen may request the user to keep the vehicle 100 in a non-driving state (e.g., in a shutdown standby state, fixed in parking range, or with the electric parking brake activated) until activation is completed. The activation consent screen may display a message prompting the user to check the state of the vehicle 100.

[0063] When the user inputs "Agree" on the activation consent screen, ECU 110 requests each target ECU to activate (enable the installed software). On the other hand, when the user inputs "Reject" on the activation consent screen, ECU 110 stops the process related to the software update without executing the activation, and the vehicle system is shut down.

[0064] The target ECU executes activation in response to a request from the 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 a flash rewriting function of the main microcomputer in the target ECU. Alternatively, each microcomputer in the target ECU may directly communicate with the ECU 110 to perform rewriting.

[0065] Each target ECU notifies the ECU 110 of the result of the activation (success / failure). If the activation fails in the target ECU, the software is rolled back, as will be described in detail later. On the other hand, if the activation is successful in the target ECU, for example, when rewriting of all microcomputers (targets for update) in the target ECU is completed, those microcomputers synchronously reset and start up (self-reset) and start up the updated software. After completing the self-reset, the target ECU goes into a state of waiting for a shutdown request from the ECU 110. In this state, the target ECU can continue diagnosis communication with the ECU 110.

[0066] When ECU 110 receives a notification from the target ECU that activation has been successful, it requests the target ECU for identification information (ECU Software ID) of the updated software. Then, ECU 110 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), ECU 110 updates RXSWIN. The fact that RXSWIN has been updated means that activation has been successful.

[0067] When activation is successful for all the target ECUs, the ECU 110 notifies the OTA center 500 of the software update state (software update completion) via the mobile terminal 300. This notification means that the OTA software update is successful. The ECU 110 may also display the result of the software update on the in-vehicle HMI. The in-vehicle HMI displays, for example, a software update completion screen indicating the success of the update. When the above-mentioned software update completion notification is made, the ECU 110 makes a shutdown request to each target ECU, and the control system of the vehicle 100 is shut down. As a result, the IG of the vehicle 100 is turned off. After that, when the start switch 150 of the vehicle 100 is turned on, the vehicle system is turned on. As a result, the update program (a new version of software) is started in the target ECU. Note that the software to be updated is not limited to a driving assistance control program such as the above-mentioned automatic driving control program, and is arbitrary. For example, the OTA center 500 may distribute software related to entertainment.

[0068] Meanwhile, typical microcomputers in vehicle ECUs are broadly divided into dual bank microcomputers (dual bank type microcomputers) and single bank microcomputers (single bank type microcomputers). In dual bank microcomputers, new software (new version of software) is written to the write side while the old software (original version of software) remains on the active side. Therefore, if activation fails, the write side can be restored (rolled back) to the old software by using the old software left on the active side. In contrast, in single bank microcomputers, software is overwritten in one bank. As a result, the old software does not remain. With single bank microcomputers, a problem can arise in that if activation fails, it is not possible to restore (roll back) to the old software.

[0069] Therefore, the software distribution system of this embodiment enables suitable software updates using OTA technology even for single-bank type computers installed in vehicles by executing the processes shown in Figures 3 and 4 described below.

[0070] In the software distribution system according to this embodiment, the microcomputer to be updated (the target of the software update) is at least one of a single bank microcomputer and a dual bank microcomputer included in the target ECU. As will be described in detail later, in the vehicle 100, the ECU 121 has a built-in single bank microcomputer, and the ECU 122 has a built-in dual bank microcomputer. If activation of the update target in the target ECU fails, the update target is rolled back. In particular, it is required that the software versions of multiple microcomputers that cooperate with each other to execute control are the same. In these microcomputers, software upgrades (software updates) are executed simultaneously, and if activation fails in any of the microcomputers, a process of returning to the old software (rollback process) is executed for all the microcomputers.

[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 is executed by the mobile terminal 300 and the vehicle 100 when the execution timing of the above-mentioned configuration synchronization is reached (for example, when the execution condition of the configuration synchronization is met). In this embodiment, the processor 310 shown in FIG. 1 functions as an example of a "receiving unit", "acquiring unit", "generating unit", "updating unit", "notifying unit", and "transmitting unit" according to the present disclosure, and the memory 320 shown in FIG. 1 functions as an example of a "storage unit" according to the present disclosure. "S" in the flowchart means a step. The following flowchart is realized by one or more processors reading and executing a program stored in one or more memories.

[0072] 1 and 2, and FIG. 3, a series of processes from S11 to S20 are executed by the mobile terminal 300. A series of processes from 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. If a campaign applicable to the vehicle 100 exists, the ECU 110 receives a campaign notification (FIG. 2) from the OTA center 500 via the mobile terminal 300 in S32. The mobile terminal 300 mediates the campaign notification from the OTA center 500 to the vehicle 100 in S12. Then, when the user inputs an "approval" to the in-vehicle HMI regarding the application of the campaign, the process proceeds to S13 and S33. In the case where there is no campaign applicable to the vehicle 100, or in the case where the user inputs "reject" for the application of the campaign, the series of processes shown in Fig. 3 ends. After that, when it is time to execute configuration synchronization, the series of processes shown in Fig. 3 starts again.

[0073] In S13, the mobile terminal 300 determines whether the update target (the computer that is the target of the software update) is a single-bank microcomputer. The update target is a 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 campaign information (S12). If the update target is a single-bank microcomputer (YES in S13), the mobile terminal 300 checks the free space of the memory 320 in S14 and determines whether the memory 320 has free space for generating an RB package (see S18 described later). The mobile terminal 300 may acquire the data size of the new software to be updated from the OTA center 500. Alternatively, the mobile terminal 300 may extract information on the new software from the campaign information (S12).

[0074] When the memory 320 has free space for generating the RB package (YES in S14), the process proceeds to S16. On the other hand, when the memory 320 does not have free space for generating the RB package (NO in S14), the mobile terminal 300 performs a predetermined notification in S15. Specifically, the mobile terminal 300 displays a message urging 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 of the memory 320 until the free space of the memory 320 is sufficient in response to the above message (request to increase free space) (YES in S14), the process proceeds to S16.

[0075] In S16, the mobile terminal 300 acquires the new software to be updated (the new version of the software itself) from the OTA center 500 via wireless communication. Then, in S17, the mobile terminal 300 acquires 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 via 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] Next, in S18, the mobile terminal 300 generates an RB package including the new software to be updated (update software) and version information (rollback data) of the old software to be updated. The mobile terminal 300 may combine the version information of the old software into one package by adding it to the new software. Next, in S19, the mobile terminal 300 transmits a distribution package including the RB package (S18) to the vehicle 100 by wireless communication.

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

[0078] After receiving the input indicating the above-mentioned "approval" from the user, the vehicle 100 (ECU 110) waits for the distribution package from the mobile terminal 300 in S33. If the determination in S33 is NO, the process does not proceed, and the determination in S33 is repeated while the determination in S33 is NO. Then, when the vehicle 100 receives the distribution package from the mobile terminal 300 (YES in S33), the ECU 110 downloads and installs new software for the update target in S34 (FIG. 2).

[0079] If the update target includes multiple microcomputers (computers), the processes of S13 to S20 and S33 and S34 are executed for each update target. If the update target is a single-bank microcomputer (YES in S13), the mobile terminal 300 generates an RB package for the update target by the processes of S16 to S18 as described above, and then transmits a distribution package including the RB package to the vehicle 100 in S19. On the other hand, if the update target is a dual-bank microcomputer (NO in S13), the processes of S16 to S18 are not executed, and the mobile terminal 300 transmits a distribution package not including rollback data to the vehicle 100 in S20.

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

[0081] 1 and 2 as well as Fig. 4, in S41, the target ECU of the vehicle 100 activates the update target (Fig. 2) in response to a request from the ECU 110. For example, the ECU 110 determines whether the vehicle 100 is in a state in which activation is possible, and when it determines that the vehicle 100 is in a state in which activation is possible (for example, a shutdown standby state), it requests the target ECU to activate the update target.

[0082] In the next step S42, the target ECU determines whether activation of the update target has been successful. If activation of the update target has failed (NO in S42), the target ECU notifies ECU 110 of the activation failure. Upon receiving the notification, ECU 110 requests the target ECU to roll back the update target. Furthermore, ECU 110 requests an ECU that includes a microcomputer that cooperates with the update target (i.e., a microcomputer that runs on the same version of software as the update target) to roll back that microcomputer. Then, the process proceeds to S44.

[0083] If activation of the update target is successful (YES in S42), the target ECU further determines in S43 whether activation of a microcomputer linked to the update target has failed. The target ECU may determine whether activation of a microcomputer linked to the update target has failed based on the presence or absence of the rollback request from ECU 110. If activation of any microcomputer linked to the update target has failed (YES in S43), the process proceeds to S44.

[0084] 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), in S45, the vehicle 100 (target ECU) transmits a signal (hereinafter referred to as a "SW request signal") requesting the old software (main body) to be updated to the mobile terminal 300. The SW request signal includes version information (rollback data) of the old software to be updated that is included in the RB package.

[0085] After the download is completed, the mobile terminal 300 waits for the SW request signal from the vehicle 100 in S21. Specifically, the mobile terminal 300 determines in S21 whether or not the SW request signal is received from the vehicle 100 within a predetermined time after the download is completed. If YES is determined in S44, the vehicle 100 transmits the SW request signal to the mobile terminal 300 before the predetermined time has elapsed. As a result, YES is determined in S21, and the process proceeds to S22. On the other hand, if NO is determined in S44, the predetermined time elapses without the vehicle 100 transmitting the SW request signal, and NO is determined in S21. In this case, the process proceeds to S24 without executing the processes of S22 and S23.

[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. Then, 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] If the update target is a single-bank microcomputer (YES in S44), the vehicle 100 receives the old software of the update target (S23). As a result, in S46, the target ECU of the vehicle 100 executes a rollback process (processing to restore to the old software) of the update target using the old software (main body) of the update target received from the mobile terminal 300. While receiving the old software (main body) of the update target from the mobile terminal 300, the target ECU uses the received old software (main body) to restore the bank (single bank) of the update target to the state before the update.

[0088] If the update target is a dual bank microcontroller (NO at S44), the target ECU of the vehicle 100 executes rollback processing of the update target in S46 without the vehicle 100 receiving the old software of the update target (S23) from the mobile terminal 300.

[0089] 5 is a diagram for explaining the activation (rollback) process of the dual bank microcomputer included in the ECU 122. In the following, an example will be explained in which the ECU 122 is the target ECU and the dual bank microcomputer MC2 is the update target.

[0090] 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 in the microcomputer. For example, when the first bank is the active side, the second bank becomes the write side. The active side (first bank) stores old software. The write side (second bank) is written with new software by the download process and the installation process (S34 in FIG. 3). Thereafter, the ECU 122 (target ECU) switches the write side of the dual bank microcomputer MC2 to the active side (activates) in S41 in FIG. 4. If the ECU 122 has successfully activated the dual bank microcomputer MC2 and has not received a rollback request from the ECU 110, the ECU 122 resets itself and then waits for a shutdown request from the ECU 110. In this case, the first bank storing the old software becomes the write surface, and the second bank to which the new software has been written becomes the active surface. 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 rollback processing of the dual bank microcomputer MC2 (S46 in FIG. 4). In this case, the first bank storing the old software returns to the active surface, and the second bank becomes the write surface. Also, the old software is written to the write surface. Thereafter, the dual bank microcomputer MC2 starts up with the old software (the program before the update).

[0091] 6 is a diagram for explaining the activation (rollback) process of the single-bank microcomputer included in the ECU 121. In the following, an example will be explained in which the ECU 121 is the target ECU and the single-bank microcomputer MC1 is the update target.

[0092] With reference to FIG. 6, ECU 121 includes a single-bank microcomputer MC1 having one bank (single bank). Specifically, single-bank microcomputer MC1 includes one memory (e.g., Flash memory), and the memory forms a bank within the microcomputer. Single-bank microcomputer MC1 corresponds to a computer that controls the running of vehicle 100. For example, during normal operation, the bank is the active side. Before software update, 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-mentioned download process and installation process (S34 in FIG. 3). However, in this embodiment, mobile terminal 300 generates an RB package before writing the new software, and transmits a distribution package including the RB package to vehicle 100 (S16 to S19 in FIG. 3). Furthermore, if the free space in the memory 320 is insufficient, the mobile terminal 300 prompts the user to increase the free space in the memory 320, for example, by displaying a screen Sc1, before generating the RB package (S15 in FIG. 3).

[0093] Old version information (old software version information) is written consecutively to the new software on the write surface of the bank of the single-bank microcomputer MC1. After that, ECU121 (target ECU) switches (activates) the write surface of the single-bank microcomputer MC1 to the active surface in S41 of FIG. 4. If ECU121 succeeds in activating the single-bank microcomputer MC1 and does not receive a rollback request from ECU110, ECU121 resets itself and then waits for a shutdown request from ECU110. In this case, the bank to which the new software has been written becomes the active surface. That is, the single-bank microcomputer MC1 starts up with the new software (the updated program).

[0094] On the other hand, when the ECU 121 receives a rollback request from the ECU 110, the ECU 121 executes the rollback process of the single-bank microcomputer MC1 (S44 to S46 in FIG. 4). Specifically, the ECU 121 requests the mobile terminal 300 to provide the old software by specifying the version (S45 in FIG. 4). The version of the software requested by the ECU 121 is specified by the old version information. Then, in response to the request from the ECU 121, the mobile terminal 300 acquires the software (main body) of the specified version from the OTA center 500 (S22 in FIG. 4) and transmits the acquired software (main body) to the vehicle 100 (ECU 121) (S23 in FIG. 4). 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 to which the old software is written becomes the active side. In this case, the single-bank microcomputer MC1 starts up with the old software (the program before the update).

[0095] Referring again to FIG. 4 together with FIG. 1 and FIG. 2, in S46, the target ECU executes the rollback process of the update target as described above. When some kind of failure occurs during activation and activation of the update target fails, the target ECU may return the update target to a normal state by using a journal file (a file to which log information is written) before the update. When the requested rollback is completed, the target ECU notifies the ECU 110 of the rollback completion. When the ECU 110 receives the notification of the rollback completion, it requests the target ECU for the identification information (ECU Software ID) of the software before the update. Then, the ECU 110 checks whether the identification information received from the target ECU and the identification information of the software before the update included in the campaign information match each other (configuration check). Success in the configuration check here (i.e., the software identification information matches) means that the rollback was successful. When the software identification information does not match, the ECU 110 may request the target ECU to perform the rollback again.

[0096] If the rollback is successful, the process proceeds to S47. The process also proceeds to S47 if activation of the update target is successful (YES in S42) and activation of none of the microcomputers linked to the update target has failed (NO in S43). If the update target includes multiple microcomputers (computers), the processes of S41 to S46 and S21 to S23 are executed for each update target. Then, when activation or rollback is successful for all update targets, the vehicle 100 (ECU 110) notifies the mobile terminal 300 of completion in S47. Then, when the process of S47 is executed, the series of processes of S31 to S47 by the vehicle 100 ends.

[0097] In S24, the mobile terminal 300 determines whether or not the end notification (S47) has been received from the vehicle 100. If the mobile terminal 300 has not received the end notification (NO in S24), the process returns to S21. Then, when the mobile terminal 300 receives the end notification (YES in S24), the series of processes from 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 also includes the processor 310 and the memory 320 (storage unit). The processor 310 is configured to be able to receive update software for a single bank type computer mounted on the vehicle 100 from the OTA center 500 (S16 in FIG. 3), obtain rollback data (e.g., version information of 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 add rollback data to the update software received from the OTA center 500. As described above, the mobile terminal 300 sends a package including the rollback data together with the update software to the vehicle 100, so that the vehicle 100 can perform rollback using the rollback data when a software update (e.g., activation) of a single-bank type computer (e.g., the single-bank microcomputer MC1 shown in FIG. 6) fails. This enables suitable software updates using OTA technology not only for dual-bank type computers mounted on the vehicle 100 but also for single-bank type computers.

[0100] Furthermore, 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 space for generating an RB package is secured in the memory 320 (storage unit) (NO in S14). As a result, S33 is repeated on the vehicle 100 side. Therefore, the software update is put on hold. Then, after free space for generating an 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 a distribution package (S19). 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. The above-mentioned process prevents the software update from proceeding in a situation where rollback is not possible. In addition, the processor 310 is configured to perform a predetermined notification (S15) when free space for generating an RB package is insufficient in the memory 320 (storage unit) in the software update of the single bank type computer (NO in S14). This notification process makes it easier for the user to understand the situation.

[0101] Vehicle 100 according to this embodiment includes ECU 110 (control device) that manages a software update sequence. ECU 110 executes software update of the single bank type computer using update software received from mobile terminal 300 (S34 in FIG. 3 and S41 in FIG. 4), and is configured to execute rollback using rollback data (e.g., version information of the software before the update of the single bank type computer) if the software update fails (S44 to S46 in FIG. 4). Vehicle 100 having such a configuration makes it easier to manage software updates on the vehicle side.

[0102] The processes shown in FIG. 3 and FIG. 4 can be modified 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, some vehicles may be equipped with an ECU that incorporates a single-bank microcomputer having a storage unit for rollback. In a system that distributes software to such vehicles, 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 that have a storage unit for rollback include a single-bank microcomputer in which a storage unit for rollback is provided within a bank, and a single-bank microcomputer in which a storage unit (non-volatile memory) for rollback is provided externally. Such single-bank microcomputers can perform rollback in a manner similar to that of a dual-bank microcomputer.

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

[0104] FIG. 7 is a flowchart showing a modified example of the process shown in FIG. 3. Referring to FIG. 7 together with FIG. 1 and FIG. 2, in this modified example, S16A to S18A are adopted instead of S16 to S18 (FIG. 3). In S16A, the mobile terminal 300 acquires new software (the main body of the software of the new version) to be updated from the OTA center 500 by wireless communication, and acquires old software (the main body of the software of the version before the update) to be updated from the vehicle 100 by wireless communication. Then, 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 new software and the 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. Then, in S18A, the mobile terminal 300 generates an RB package including the new software to be updated (the software for update) and the difference file (rollback data). Next, in S19, the mobile terminal 300 transmits a distribution package including the RB package (S18A) to the vehicle 100 by wireless communication. In this modification, when the process of S19 or S20 is executed for all update targets, the process related to the software update by the mobile terminal 300 ends.

[0105] When vehicle 100 receives the distribution package (S19 or S20) from mobile terminal 300 (YES in S33), ECU 110 downloads and installs the new software in S34. Then, ECU 110 starts a series of processes shown in Fig. 8, which will be described below. Fig. 8 is a flowchart showing a modified example of the process of vehicle 100 shown in Fig. 4.

[0106] 1 and 2, and FIG. 8, in this modified example, S461 and S462 are adopted instead of S45 to S47 (FIG. 4). The target ECU activates the update target in S41. Then, when the target ECU receives a rollback request from 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. If the update target is a single-bank microcomputer (YES in S44), the target ECU of vehicle 100 executes rollback processing (processing to restore the old software) of the update target using the difference file (rollback data) described above in S461. On the other hand, if the update target is not a single-bank microcomputer (NO in S44), the target ECU of vehicle 100 executes rollback processing of the update target using 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, rollback data (a difference file between the new software to be updated and the old software to be updated) is written to the write surface of the bank of the single-bank microcomputer MC1 consecutively to the new software. Thereafter, the ECU 121 (target ECU) switches the write surface of the single-bank microcomputer MC1 to the active surface (activates) in S41 of FIG. 8. If the ECU 121 succeeds in activating the single-bank microcomputer MC1 and does not receive a rollback request from the ECU 110, the ECU 121 resets itself and then waits for a shutdown request from the ECU 110. In this case, the bank to which the new software is written becomes the active surface. That is, the single-bank microcomputer MC1 starts up with the new software (the program after updating).

[0108] On the other hand, when the ECU 121 receives a rollback request from the ECU 110, the ECU 121 executes the rollback process of the single-bank microcomputer MC1 (S461 in FIG. 8). Specifically, the ECU 121 uses the difference file to restore the new software to the old software. After that, the bank rewritten with the old software becomes the active side. In this case, the single-bank microcomputer MC1 starts up with the old software (the program before the update).

[0109] The software distribution system according to the above modification also enables suitable software updates by OTA technology for a single-bank type computer mounted on the vehicle 100. Furthermore, according to the above software distribution system, even if the mobile terminal 300 and the vehicle 100 are unable to communicate with each other due to a communication failure or the like after the mobile terminal 300 has sent a package to the vehicle 100, the vehicle 100 can perform a rollback.

[0110] The receiving unit, acquiring unit, generating unit, updating unit, notifying unit, and transmitting unit of the mobile terminal 300 may be embodied by dedicated hardware (electronic circuits) instead of software. In the above embodiment, an on-premise server is adopted as the OTA center 500 (see FIG. 1). However, the present invention is not limited to this, and the functions of the OTA center 500 (for example, functions related to software distribution) may be implemented on a 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 that the vehicle is 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 (e.g., a gasoline engine, a biofuel engine, or a hydrogen engine). The vehicle is not limited to a four-wheeled passenger car, but may be a bus or a truck, or may be a three-wheeled xEV. The vehicle may include a flying function. The vehicle may be a vehicle used in MaaS (Mobility as a Service). The vehicle may be a multi-purpose vehicle customized according to the user's purpose of use. The vehicle may be a mobile store vehicle, a robotaxi, an automated guided vehicle (AGV), or an agricultural machine. The vehicle may be an unmanned or one-seater small BEV (e.g., a BEV for the last mile, an electric wheelchair, or an electric skater).

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

[0113] 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 microcontroller, MC2 dual bank microcontroller.

Claims

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:

2. The mobile terminal according to claim 1 , wherein the rollback data includes a difference file between the update software and software before the update.

3. The mobile terminal according to claim 1 , wherein the rollback data includes version information of software before the update of the single-bank type computer.

4. A storage unit; an update unit that suspends a software update for the single bank type computer until free space for generating the package is secured in the storage unit, and permits the software update for the single bank type computer after free space for generating the package is secured in the storage unit; The mobile terminal of claim 1 further comprising:

5. 5. The mobile terminal according to claim 4, further comprising a notification unit that issues a predetermined notification when the free space in the storage unit for generating the package is insufficient during software update of the single-bank type computer.

6. the receiving unit is configured to obtain the update software from the server through wireless communication; The mobile terminal of claim 1 , wherein the transmitter is configured to transmit the package to the vehicle by wireless communication.

7. The mobile terminal of claim 6, wherein the mobile terminal is a smartphone.

8. A mobile terminal according to any one of claims 1 to 7; The vehicle; The server; Equipped with The vehicle includes a control device that manages a sequence of software updates; A software distribution system in which the control device performs a software update of the single bank type computer using the update software received from the mobile terminal, and if the software update fails, performs a rollback using the rollback data.

9. 9. The software distribution system according to claim 8, wherein the single-bank type computer is a computer that performs driving control of the vehicle.

Images