vehicle

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] This 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 microcontroller, two banks are formed by two memory locations. A dual-bank microcontroller allows for a rollback to the original software version if activation fails. Specifically, the original software version remains on the active side, while the new version is written to the write side. If activation of the write side fails, the rollback is performed using the original software version remaining on the active side.

[0007] In a single-bank microcontroller, one memory unit forms one bank. Software overwriting occurs within this single bank. Therefore, the original version of the software is not retained. A potential problem with single-bank microcontrollers is that it's impossible to revert to the original software version (rollback) if activation fails.

[0008] Therefore, it is conceivable to change from a single-bank microcontroller to a dual-bank microcontroller, to add a memory unit for rollback within the bank of the single-bank microcontroller, or to add an external non-volatile memory (e.g., Flash memory) for rollback to the single-bank microcontroller. However, these design changes would lead to a significant increase in the cost of the automotive ECU.

[0009] Currently, most vehicles are equipped with numerous single-bank microcontrollers, and software updates for these microcontrollers are often performed by dealerships. However, there is a need to enable vehicle users to easily perform software updates for single-bank microcontrollers at their own discretion using OTA (Over-the-Air) technology.

[0010] This disclosure was made to solve the above-mentioned problems, and its purpose is to enable suitable software updates via OTA technology even for single-bank type computers mounted in vehicles. [Means for solving the problem]

[0011] In accordance with the form relating to the first aspect of this disclosure, the following mobile devices are provided: (Article 1) The mobile terminal comprises a receiving unit, an acquisition 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 the vehicle from a server. The acquisition unit is configured to acquire rollback data. The generating unit is configured to generate a package containing the update software and the rollback data. The transmitting unit is configured to transmit the package to the vehicle.

[0012] The server described above can function as an OTA (Over The Air) center for distributing software. The mobile terminal can mediate communication between the vehicle and the OTA center. In a system including this server, vehicle, and mobile terminal, the mobile terminal can add rollback data to the update software received from the server. As described above, by the mobile terminal sending a package containing the update software and rollback data to the vehicle, the vehicle can perform a rollback using the rollback data if the software update of the single-bank type computer fails. This enables suitable software updates using OTA technology even for single-bank type computers installed in vehicles.

[0013] Mobile devices are devices that users can carry with them. Examples of mobile devices include tablets, smartphones, and wearable devices.

[0014] The mobile terminal described in paragraph 1 above may have the configuration described in any one of paragraphs 2 to 7 below.

[0015] (Article 2) The mobile terminal described in Article 1 further has the following characteristics: The rollback data includes a difference file between the update software and the software before the update.

[0016] With the above configuration, the vehicle can perform software updates using update software, and can also perform rollbacks using differential files.

[0017] (Article 3) The mobile terminal described in Article 1 further has the following characteristics: The rollback data includes the version information of the software of a single-bank type computer prior to the update.

[0018] With the above configuration, the vehicle can retrieve the previous software using the version information of the software before the update. Therefore, a rollback of a single-bank type computer can be properly performed.

[0019] (Article 4) The mobile terminal described in any one of paragraphs 1 to 3 further has the following features: The mobile terminal further comprises a storage unit and an update unit. The update unit is configured to suspend the software update of a single-bank type computer until sufficient free space is secured in the storage unit to generate the aforementioned package, and to permit the software update of the single-bank type computer after sufficient free space is secured in the storage unit to generate the package.

[0020] The above configuration makes it easier to properly update the software of a single-bank type computer.

[0021] (Article 5) The mobile terminal described in any one of paragraphs 1 to 4 further has the following features: The mobile terminal further comprises a notification unit. The notification unit is configured to give a predetermined notification when there is insufficient free space in the storage unit for generating the aforementioned package during a software update of a single-bank type computer.

[0022] The above configuration makes it easier for users to 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 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 for 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 aspect 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 to execute rollback using rollback data when the software update fails.

[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 vehicle driving control.

[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 (rollback). With the software before the update, the vehicle can run as before. Therefore, the user can feel at ease.

Effects of the Invention

[0029] According to this disclosure, single-bank type computers installed in vehicles will also be able to receive suitable software updates via OTA technology. [Brief explanation of the drawing]

[0030] [Figure 1] This figure shows the schematic configuration of the software distribution system according to the embodiment of the present disclosure. [Figure 2] This figure illustrates an overview of the software update method according to the embodiments of this disclosure. [Figure 3] This is a first flowchart showing the processing procedure for the software update method according to the embodiment of the present disclosure. [Figure 4] This is a second flowchart showing the processing procedure for the software update method according to the embodiment of the present disclosure. [Figure 5] Figure 4 is a diagram that explains the process shown, particularly the activation (rollback) process of the dual-bank microcontroller equipped in the target ECU. [Figure 6] Figure 4 is a diagram that explains the process shown, particularly the activation (rollback) process of the single-bank microcontroller equipped in the target ECU. [Figure 7] Figure 3 shows a flowchart illustrating a modified version of the process shown. [Figure 8] Figure 4 is a flowchart showing a modified example of the vehicle processing shown. [Figure 9] Figure 8 is a diagram that explains the process shown, particularly the rollback process of a single-bank microcontroller. [Modes for carrying out the invention]

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

[0032] Figure 1 shows the configuration of the software distribution system according to this embodiment. Referring to Figure 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] Vehicle 100 is an electric vehicle (BEV) without an internal combustion engine. Vehicle 100 according to this embodiment does not have an OTA access function (a function to communicate wirelessly directly with the OTA center 500), and cannot communicate with the OTA center 500 without going through another communication device (i.e., a communication device other than the communication device built into the vehicle 100 itself). Specifically, vehicle 100 communicates wirelessly with the OTA center 500 via a mobile terminal 300. However, vehicle 100 is just one 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 as well.

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

[0035] The mobile terminal 300 comprises a processor 310, memory 320, and a communication module 330. The processor 310 includes, for example, a CPU (Central Processing Unit). The memory 320 includes, for example, non-volatile memory such as flash memory. The communication module 330 includes a communication interface (I / F) for directly communicating wirelessly with the OTA center 500. The communication module 330 also includes a communication interface for directly communicating wirelessly 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, 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] The mobile terminal 300 has application software (hereinafter referred to as "mobile app") installed for using the services provided by the OTA center 500. The mobile app links the identification information of the mobile terminal 300 (terminal ID) with the identification information of the vehicle 100 (vehicle ID) and registers it with 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 vehicle software update services using OTA technology. The OTA Center 500 is configured to perform remote in-vehicle ECU software updates via a communication channel from the center. The OTA Center 500 distributes the software for the in-vehicle ECU. "ECU" stands for Electronic Control Unit.

[0038] The OTA center 500 comprises a processor 510, memory 520, and a communication module 530. The processor 510 includes, for example, a CPU. The memory 520 includes, for example, non-volatile memory such as flash memory. The communication module 530 is connected to a communication network NW by a wire and communicates with multiple mobile terminals (including mobile terminals 300) via the communication network NW. The communication network NW is, for example, a wide-area network constructed by the internet and wireless base stations. The communication network NW may also include a mobile phone network.

[0039] The OTA Center 500 has pre-registered identification information (vehicle ID) for each vehicle (including vehicle 100) that receives vehicle software update services from the OTA Center 500. The storage device of the OTA Center 500 (for example, memory 520) stores information about each vehicle (hereinafter also referred to as "vehicle information"), distinguished by the vehicle ID. The vehicle information includes, for example, the specifications of each vehicle and the communication address of each vehicle (for vehicle 100, the communication address of the mobile terminal 300).

[0040] Vehicle 100 is equipped with multiple ECUs (including ECUs 110, 121, and 122). The number of ECUs in vehicle 100 is arbitrary. Each on-board ECU has a built-in computer comprising at least one processor and at least one memory. Each on-board ECU may have multiple microcontrollers (microcomputers) in the form of a main microcontroller and sub-microcontrollers. In vehicle 100, the ECUs are connected to each other via a communication bus and are configured to enable wired communication. The communication method between ECUs is not particularly limited, but may be, for example, CAN (Controller Area Network) or Ethernet (registered trademark).

[0041] The ECU 110 includes a processor 111 and memory 112. The processor 111 includes, for example, a CPU. The memory 112 includes, for example, non-volatile memory such as 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 interface for direct wireless communication with a mobile terminal 300. The communication device 190 and the mobile terminal 300 may communicate using short-range communication such as Wi-Fi (Local Area Network), NFC (Near Field Communication), or Bluetooth®. The communication device 190 may communicate directly with a mobile terminal 300 that is inside or within range of the vehicle. While the vehicle 100 is stopped, the mobile terminal 300 inside or outside the vehicle and the ECU 110 may exchange information with each other via the communication device 190. Furthermore, while the vehicle 100 is in motion, the mobile terminal 300 and the ECU 110 may exchange information with each other via the communication device 190. As described above, 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.

[0042] As described above, the ECU 110 of vehicle 100 is configured to communicate wirelessly with the OTA center 500 via a mobile terminal 300. Vehicle 100 can communicate with the OTA center 500 whether it is stationary or in motion. The ECU 110 manages in-vehicle information, receives campaigns, and manages the software update sequence. Note that the communication method between vehicle 100 and mobile terminal 300 is not limited to the short-range communication described above. Vehicle 100 and mobile terminal 300 may be configured to communicate even when they are far apart from each other. Furthermore, the communication device 190 may further include a communication I / F for wired communication with a scan tool (a dedicated tool for wired software updates) not shown. The ECU 110 may communicate via the communication device 190 with a scan tool connected to an in-vehicle DLC (Data Link Connector) not shown.

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

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

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

[0046] The ADS140 includes a recognition sensor (e.g., at least one of a camera, millimeter-wave radar, or lidar) that recognizes the external environment of the vehicle, and performs processing related to autonomous driving based on information acquired sequentially by the recognition sensor. Specifically, the ADS140 works in cooperation with the ECU121 to generate a driving plan (information indicating the future behavior of the vehicle) according to the external environment of the vehicle. Then, the ADS140 requests the ECU121 to control various actuators included in the driving device 130 so that the vehicle 100 is driven according to that 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 can be attached to and removed from the vehicle. The sensor unit (including the recognition sensor) of the autonomous driving kit may be mounted on the rooftop of the vehicle.

[0048] Vehicle 100 is further equipped with a start switch 150 and an HMI (Human Machine Interface) 170.

[0049] The start switch 150 is a switch used by the user to start the vehicle system (the control system of the vehicle 100), and is installed, for example, inside the passenger compartment. Generally, start switches are called "power switches" or "ignition switches." By operating the start switch 150, the user switches the vehicle system (including each ECU installed in the vehicle) on (operating) / off (stopped). When the start switch 150 is turned on, the vehicle system, which is in a stopped state, starts up, and the vehicle system becomes operational (hereinafter also referred to as "IG on"). Also, when the vehicle system is operational, if the start switch 150 is turned off, the vehicle system becomes stopped (hereinafter also referred to as "IG off").

[0050] Turning the start switch 150 ON switches the vehicle's state from ignition off to ignition on. When the user turns the start switch 150 ON, a start request is input to each onboard ECU. In other words, each onboard ECU accepts the start request from the user. On the other hand, turning the start switch 150 OFF switches the vehicle's state from ignition on to ignition off. When the user turns the start switch 150 OFF, a shutdown request is input to each onboard ECU, and the vehicle 100 enters a shutdown standby state. In this way, each onboard ECU accepts the shutdown request from the user. However, turning the start switch 150 OFF is prohibited in a moving vehicle.

[0051] HMI170 includes input and display devices. HMI170 may include a touch panel display that functions as both an input and display device. HMI170 may include an information display or a tenttail as a display device. HMI170 may include steering wheel switches as an input device. At least one of an IVI (In-Vehicle Infotainment) system, an instrument panel, and a head-up display may also function as HMI170. HMI170 may also include input and display devices for a car navigation system.

[0052] Figure 2 is a diagram illustrating the overview of the software update method according to this embodiment. Referring to Figure 2 together with Figure 1, the process related to software updates (more specifically, vehicle software updates using OTA) is carried out in steps such as configuration synchronization, campaign notification and acceptance of application, download, installation, activation, and software update completion notification. The processes described below are performed by the OTA Center 500 and each vehicle (including 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 around 50, or 100 to less than 1000, or 1000 or more.

[0053] Vehicle 100 with the ignition on repeatedly performs configuration synchronization at predetermined intervals. Vehicle 100 with the ignition on also performs configuration synchronization when it receives a request for it from the OTA center 500. The configuration synchronization process by 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 hardware part numbers, ECU identifiers, etc.) and software information (information indicating software part numbers, etc.) for each ECU included in vehicle 100. In this embodiment, the vehicle configuration information further includes RXSWIN for each approved item. RXSWIN is an identification number that can identify the software constituting the functional type approval.

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

[0055] When vehicle 100 receives a campaign notification (acceptance request signal), it prompts the user to input whether or not to accept the application of the campaign. Specifically, vehicle 100 displays a message on the in-vehicle HMI (e.g., HMI 170) such as "New software has been found. Do you want to apply it to this vehicle?" and requests the user to input either "Accept" or "Reject". If the user inputs "Accept" to the in-vehicle HMI, vehicle 100 executes the download process described below. On the other hand, if the user inputs "Reject" to the in-vehicle HMI, vehicle 100 does not execute the download process. In this case, the OTA center 500 terminates the software update process without proceeding to the download phase.

[0056] In this embodiment, the OTA center 500 and the vehicle 100 (ECU 110) perform the download process according to the procedure described below.

[0057] The ECU 110 of the vehicle 100 requests a distribution package containing new software corresponding to each update target from the mobile terminal 300. One or more microcontrollers (MCUs) included in the target ECU (the ECU to be updated) are the targets for the update. For example, the target ECU may be ECU 121, and the software to be updated may be an automated 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 to verify the validity of the update data, etc.).

[0058] Upon receiving a request for the above-mentioned distribution package from vehicle 100, mobile terminal 300 sends the distribution package containing the new software to vehicle 100. Mobile terminal 300 may combine the update software into a single distribution package and send a single distribution package containing the new software for all update targets to vehicle 100. Alternatively, mobile terminal 300 may generate a distribution package containing the new software corresponding to each update target and send each of these distribution packages to vehicle 100. As will be described in detail later, if the update targets include a single-bank type computer, mobile terminal 300, upon receiving a request for the above-mentioned distribution package, generates a package (hereinafter also referred to as the "RB package") containing the new software and rollback data for that single-bank type computer. Then, mobile terminal 300 sends the distribution package containing the generated RB package to vehicle 100. ECU 110 performs the download (receive and save) of the above-mentioned distribution package while wirelessly communicating with OTA center 500 via mobile terminal 300.

[0059] The above-described download process saves the distribution package to the storage device (e.g., memory 112) of the ECU 110. During the download, the in-vehicle HMI notifies the user of the download progress. After the download is complete, the ECU 110 verifies the authenticity of the downloaded distribution package. If the verification result is "normal", the ECU 110 notifies the OTA center 500 of the software update status (download complete) via the mobile terminal 300. This notification indicates that the download was successful.

[0060] If the download is successful, vehicle 100 will perform the installation. Specifically, ECU 110 requests the target ECU (e.g., ECU 121) to provide the status of the target ECU and the output of a DTC (Diagnostic Trouble Code). Based on the status of the target ECU and the DTC, ECU 110 determines whether installation is possible for each target ECU. ECU 110 then transfers the new software (update data) to the target ECUs that are eligible for installation. The target ECU that receives the update data performs the installation (writing to non-volatile memory). During installation, the in-vehicle HMI notifies the user of the installation progress.

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

[0062] If the download and installation are successful, vehicle 100 enters an activation waiting state. Subsequently, when the vehicle 100's start switch 150 is turned off, the ECU 110 displays an activation consent screen on the in-vehicle HMI and requests the user to input either "Accept" or "Deny". The activation consent screen may also display limitations of vehicle 100 (for example, the vehicle may be unusable for a certain period of time, or the operation of overcurrent devices may be restricted). The activation consent screen may also require the user to keep vehicle 100 in a non-driving state (for example, in shutdown standby state, parking range locked, or electric parking brake engaged) until activation is complete. The activation consent screen may also display a message prompting the user to confirm the status of vehicle 100.

[0063] Then, if the user indicates "Accept" on the activation consent screen, ECU110 requests each target ECU to activate (enable the installed software). On the other hand, if the user indicates "Reject" on the activation consent screen, ECU110 will stop the software update process without performing the activation, and the vehicle system will shut down.

[0064] The target ECU performs activation in response to a request from ECU110. In a target ECU equipped with multiple microcontrollers (for example, a main microcontroller and sub-microcontrollers), the sub-microcontrollers within the target ECU may perform the rewriting using the Flash rewriting function of the main microcontroller within the target ECU. Alternatively, each microcontroller within the target ECU may communicate directly with ECU110 to perform the rewriting.

[0065] Each target ECU notifies ECU110 of the activation result (success / failure). As will be explained in detail later, if activation fails in a target ECU, a software rollback is performed. On the other hand, if activation is successful in a target ECU, for example, once the rewriting of all microcontrollers (targets for update) within the target ECU is complete, those microcontrollers will synchronously reset and start up (self-reset), and the updated software will be launched. After the self-reset is complete, the target ECU will be in a state of waiting for a shutdown request from ECU110. In this state, the target ECU can continue diagnostic communication with ECU110.

[0066] When ECU110 receives notification of successful activation from the target ECU, it requests the updated software identification information (ECU Software ID) from the target ECU. ECU110 then verifies whether the identification information received from the target ECU matches the updated software identification information included in the campaign information (configuration verification). If the configuration verification is successful (i.e., the software identification information matches), ECU110 updates RXSWIN. The updating of RXSWIN indicates that the activation was successful.

[0067] Once all target ECUs have been successfully activated, ECU 110 notifies the OTA center 500 via the mobile terminal 300 of the software update status (software update complete). This notification indicates that the OTA software update was successful. ECU 110 may also display the software update result on the in-vehicle HMI. The in-vehicle HMI may, for example, display a software update complete screen indicating the success of the update. Once the above software update completion notification is sent, ECU 110 requests each target ECU to shut down, and the control system of the vehicle 100 shuts down. As a result, the vehicle 100 turns off its ignition. Subsequently, when the vehicle 100's start switch 150 is turned on, the vehicle system turns on its ignition. This starts the update program (new version of software) on the target ECUs. The software to be updated is not limited to driver assistance control programs such as the automated driving control program described above, but is arbitrary. For example, the OTA center 500 may distribute entertainment-related software.

[0068] Incidentally, typical microcontrollers (microcomputers) in automotive ECUs are broadly classified into dual-bank microcontrollers and single-bank microcontrollers. In dual-bank microcontrollers, the old software (original version of the software) remains on the active side, while the new software (newer version of the software) is written to the programmable side. Therefore, if activation fails, the old software remaining on the active side can be used to revert the programmable side back to the old software (rollback). In contrast, in single-bank microcontrollers, software is overwritten in a single bank. As a result, the old software does not remain. A potential problem with single-bank microcontrollers is that it is not possible to revert to the old software (rollback) if activation fails.

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

[0070] In the software distribution system according to this embodiment, the microcontroller to be updated (the target of the software update) is at least one of the single-bank microcontroller and dual-bank microcontroller equipped in the target ECU. As will be described in detail later, in vehicle 100, ECU 121 incorporates a single-bank microcontroller, and ECU 122 incorporates a dual-bank microcontroller. If the activation of the update target fails in the target ECU, a rollback of the update target is performed. In particular, for multiple microcontrollers that work together to perform control, it is required that the software versions be the same. Software upgrades (software updates) are performed simultaneously on these microcontrollers, and if activation fails on any of these microcontrollers, a process to revert to the old software (rollback process) is performed on all microcontrollers.

[0071] Figure 3 is a first flowchart showing the processing procedure of the software update method according to this embodiment. The series of processes shown in this flowchart are executed by the mobile terminal 300 and the vehicle 100 when the execution timing of the aforementioned configuration synchronization occurs (for example, when the execution conditions for configuration synchronization are met). In this embodiment, the processor 310 shown in Figure 1 functions as an example of the "receiving unit," "acquisition unit," "generation unit," "update unit," "notification unit," and "transmission unit" according to this disclosure, and the memory 320 shown in Figure 1 functions as an example of the "storage unit" according to this disclosure. "S" in the flowchart means step. The following flowchart is realized by one or more processors reading and executing programs stored in one or more memories.

[0072] Referring to Figure 3 along with Figures 1 and 2, the series of processes from S11 to S20 are executed by the mobile terminal 300. The series of processes from S31 to S34 are executed by the vehicle 100. In S31, the ECU 110 performs configuration synchronization (Figure 2) via the mobile terminal 300. In S11, the mobile terminal 300 mediates the configuration synchronization between the vehicle 100 and the OTA center 500. If there is a campaign applicable to the vehicle 100, in S32, the ECU 110 receives a campaign notification (Figure 2) from the OTA center 500 via the mobile terminal 300. In S12, the mobile terminal 300 mediates the campaign notification from the OTA center 500 to the vehicle 100. Then, when the user gives input indicating "acceptance" to the in-vehicle HMI regarding the application of the campaign, the process proceeds to S13 and S33. Furthermore, if there are no campaigns applicable to vehicle 100, or if the user indicates "rejection" regarding the application of a campaign, the series of processes shown in Figure 3 will terminate. Subsequently, when it is time for configuration synchronization to be performed, the series of processes shown in Figure 3 will start again.

[0073] In S13, the mobile terminal 300 determines whether the target of the update (the computer to be updated) is a single-bank microcontroller. The target of the update is the microcontroller included in the target ECU. The mobile terminal 300 may obtain information about the target of the update from the vehicle 100 (ECU 110). Alternatively, the mobile terminal 300 may extract information about the target of the update from the campaign information (S12). If the target of the update is a single-bank microcontroller (YES in S13), the mobile terminal 300 checks the free space in memory 320 in S14 and determines whether there is free space in memory 320 to generate the RB package (see S18 described later). The mobile terminal 300 may obtain the data size of the new software to be updated from the OTA center 500. Alternatively, the mobile terminal 300 may extract information about the new software from the campaign information (S12).

[0074] If memory 320 has enough free space to generate the RB package (YES in S14), the process proceeds to S16. On the other hand, if memory 320 does not have enough free space to generate the RB package (NO in S14), the mobile terminal 300 makes a predetermined notification in S15. Specifically, the mobile terminal 300 displays a message prompting the user to increase the free space in memory 320. The user can increase the free space in memory 320 by operating the mobile terminal 300 to stop unnecessary applications running on the mobile terminal 300 or by deleting unnecessary data stored in memory 320. As long as there is insufficient free space in memory 320 to generate the RB package (NO in S14), S14 and S15 are repeated, and the mobile terminal 300 continues to make the above notification. Then, when the user increases the free space in memory 320 to a sufficient level in response to the above message (request for increased free space) (YES in S14), the process proceeds to S16.

[0075] In S16, the mobile terminal 300 obtains the new software to be updated (the new version of the software itself) from the OTA center 500 via wireless communication. Subsequently, in S17, the mobile terminal 300 obtains 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 also obtain 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 containing the new software to be updated (update software) and version information of the old software to be updated (rollback data). The mobile terminal 300 may also combine the new software and the old software version information into a single package. Next, in S19, the mobile terminal 300 transmits the distribution package containing the RB package (S18) to the vehicle 100 via wireless communication.

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

[0078] After receiving the aforementioned "acceptance" input from the user, vehicle 100 (ECU 110) waits for the distribution package from the mobile terminal 300 in S33. If NO is determined in S33, processing does not proceed, and as long as NO is determined in S33, the determination in S33 is repeated. When vehicle 100 receives the distribution package from the mobile terminal 300 (YES in S33), ECU 110 performs the download and installation of the new software for the update target in S34 (Figure 2).

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

[0080] After the download and installation of the new software is complete for all update targets, and the predetermined activation start conditions are met, the process proceeds to S21 and S41 in Figure 4. For example, when the activation start conditions are met, the ECU 110 requests activation from each target ECU. Then, the series of processes shown in Figure 4, which will be described below, begins. Figure 4 is a second flowchart showing the processing procedure of the software update method according to this embodiment.

[0081] Referring to Figures 1 and 2, as well as Figure 4, in S41, the target ECU of vehicle 100 performs the activation of the update target (Figure 2) in response to a request from ECU 110. ECU 110 determines, for example, whether vehicle 100 is in an activatable state, and if it determines that vehicle 100 is in an activatable state (for example, in a shutdown standby state), it requests the target ECU to perform the activation of the update target.

[0082] In the following S42, the target ECU determines whether the activation of the update target was successful. If the activation of the update target fails (NO in S42), the target ECU notifies ECU110 of the activation failure. Upon receiving the notification, ECU110 requests the target ECU to roll back the update target. Furthermore, ECU110 requests the ECU equipped with the microcontroller that interacts with the update target (i.e., a microcontroller running the same version of software as the update target) to roll back that microcontroller. The process then proceeds to S44.

[0083] If the activation of the update target is successful (YES in S42), the target ECU further determines in S43 whether the microcontroller that interacts with the update target failed to activate. The target ECU may also determine whether the microcontroller that interacts with the update target failed to activate based on whether or not there is a rollback request from ECU110. If any of the microcontrollers that interact with the update target fail to activate (YES in S43), the process proceeds to S44.

[0084] In S44, the target ECU determines whether the target to be updated is a single-bank microcontroller. If the target to be updated is a single-bank microcontroller (YES in S44), the vehicle 100 (target ECU) sends a signal to the mobile terminal 300 in S45 requesting the old software (main unit) to be updated (hereinafter referred to as the "SW request signal"). The SW request signal includes version information (rollback data) of the old software to be updated, which is included in the RB package.

[0085] After the aforementioned download is complete, 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 complete. If it is determined to be YES in S44, the vehicle 100 sends the SW request signal to the mobile terminal 300 before the predetermined time has elapsed. 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 has elapsed without the vehicle 100 sending the SW request signal, and it is determined to be NO in S21. In this case, the processes in S22 and S23 are not executed, and the process proceeds to S24.

[0086] In S22, the mobile terminal 300 obtains the old software to be updated (main unit) 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 to be updated (main unit) obtained from the OTA center 500 to the vehicle 100 (target ECU). After that, the process proceeds to S24.

[0087] If the target of the update is a single-bank microcontroller (YES in S44), the vehicle 100 receives the old software of the target of the update (S23). As a result, in S46, the target ECU of the vehicle 100 uses the old software (main body) of the target of the update received from the mobile terminal 300 to perform a rollback process (process to revert to the old software). The target ECU receives the old software (main body) of the target of the update from the mobile terminal 300 and uses the received old software (main body) to revert the bank (single bank) of the target of the update to its state before the update.

[0088] If the target of the update is a dual-bank microcontroller (NO in S44), the vehicle 100 does not receive the old software of the target of the update from the mobile terminal 300 (S23), and the target ECU of the vehicle 100 performs the rollback process of the target of the update in S46.

[0089] Figure 5 illustrates the activation (rollback) process of the dual-bank microcontroller in ECU122. The following describes an example where ECU122 is the target ECU and the dual-bank microcontroller MC2 is the target of the update.

[0090] Referring to Figure 5, ECU122 is equipped with a dual-bank microcontroller MC2 having two banks (first bank and second bank). Specifically, the dual-bank microcontroller MC2 has two memories (e.g., Flash memory), and each memory forms a bank within the microcontroller. For example, when the first bank is the active side, the second bank becomes the write side. The active side (first bank) stores the old software. The write side (second bank) is written to by the aforementioned download and installation process (S34 in Figure 3). Subsequently, ECU122 (target ECU) switches the write side of the dual-bank microcontroller MC2 to the active side (activates) at S41 in Figure 4. If ECU122 successfully activates the dual-bank microcontroller MC2 and does not receive a rollback request from ECU110, ECU122 performs a self-reset and then waits for a shutdown request from ECU110. In this case, the first bank, which stores the old software, becomes the write surface, and the second bank, on which the new software is written, becomes the active surface. That is, the dual-bank microcontroller MC2 starts up with the new software (updated program). On the other hand, if ECU122 receives a rollback request from ECU110, ECU122 executes the rollback process for the dual-bank microcontroller MC2 (S46 in Figure 4). In this case, the first bank, which stores the old software, returns to the active surface, and the second bank becomes the write surface. The old software is also written to the write surface. After that, the dual-bank microcontroller MC2 starts up with the old software (the program before the update).

[0091] Figure 6 illustrates the activation (rollback) process of the single-bank microcontroller equipped in ECU121. Below, we will describe an example where ECU121 is the target ECU and the single-bank microcontroller MC1 is the target of the update.

[0092] Referring to Figure 6, the ECU121 includes a single-bank microcontroller MC1 having one bank (single bank). Specifically, the single-bank microcontroller MC1 has one memory (e.g., Flash memory), and this memory forms a bank within the microcontroller. The single-bank microcontroller MC1 corresponds to the computer that controls the driving of the vehicle 100. For example, during normal operation, the bank is the active side. Before a software update, the old software is stored in the bank. During a software update, the bank becomes the write side. Then, the new software is written to the bank by the aforementioned download and installation process (S34 in Figure 3). However, in this embodiment, the mobile terminal 300 generates an RB package before the new software is written and sends a distribution package including the RB package to the vehicle 100 (S16-S19 in Figure 3). Furthermore, if there is insufficient free space in memory 320, the mobile terminal 300 prompts the user to increase the free space in memory 320 by, for example, displaying screen Sc1 before generating the RB package (S15 in Figure 3).

[0093] On the programmable side of the single-bank microcontroller MC1, the old version information (version information of the old software) is written immediately after the new software. Subsequently, at S41 in Figure 4, the ECU121 (target ECU) switches the programmable side of the single-bank microcontroller MC1 to the active side (activates it). If the ECU121 successfully activates the single-bank microcontroller MC1 and does not receive a rollback request from the ECU110, the ECU121 performs a self-reset and then waits for a shutdown request from the ECU110. In this case, the bank on which the new software was written becomes the active side. That is, the single-bank microcontroller MC1 starts up with the new software (updated program).

[0094] On the other hand, if ECU121 receives a rollback request from ECU110, ECU121 executes the rollback process for the single-bank microcontroller MC1 (S44-S46 in Figure 4). Specifically, ECU121 requests the old software from the mobile terminal 300, specifying the version (S45 in Figure 4). The software version requested by ECU121 is specified by the old version information mentioned above. Then, in response to the request from ECU121, the mobile terminal 300 obtains the specified version of the software (main program) from the OTA center 500 (S22 in Figure 4) and sends the obtained software (main program) to the vehicle 100 (ECU121) (S23 in Figure 4). ECU121 receives the old software (main program) from the mobile terminal 300 and writes the old software to the bank of the single-bank microcontroller MC1. After that, the bank on which the old software was written becomes the active plane. In this case, the single-bank microcontroller MC1 starts up with the old software (the program before the update).

[0095] Referring again to Figure 4 along with Figures 1 and 2, in S46, the target ECU executes the rollback process for the update target as described above. If any failure occurs during activation and the activation of the update target fails, the target ECU may use the journal file (file to which log information is written) from before the update to restore the update target to a normal state. Once the requested rollback is complete, the target ECU notifies ECU110 of the rollback completion. Upon receiving notification of rollback completion, ECU110 requests the pre-update software identification information (ECU Software ID) from the target ECU. ECU110 then checks whether the identification information received from the target ECU matches the pre-update software identification information contained in the campaign information (configuration check). Success in this configuration check (i.e., the software identification information matches) means that the rollback was 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, if the activation of the update target is successful (YES in S42) and none of the microcontrollers that interact with the update target have failed to activate (NO in S43), the process proceeds to S47. If the update target includes multiple microcontrollers (computers), processes S41-S46 and S21-S23 are executed for each update target. Once the activation or rollback is successful for all update targets, the vehicle 100 (ECU 110) sends a completion notification to the mobile terminal 300 in S47. After the process in S47 is executed, the series of processes from S31 to S47 by the vehicle 100 are completed.

[0097] In S24, the mobile terminal 300 determines whether or not it has received the termination notification (S47) from the vehicle 100. If the mobile terminal 300 has not received the termination notification (NO in S24), the process returns to S21. If the mobile terminal 300 has received the termination notification (YES in S24), the series of processes from S11 to S24 by the mobile terminal 300 are completed.

[0098] As described above, the software distribution system according to this embodiment comprises a mobile terminal 300, a vehicle 100, and an OTA center 500 (server). The mobile terminal 300 comprises a processor 310 and a memory 320 (storage unit). The processor 310 is configured to receive update software for a single-bank type computer installed in the vehicle 100 from the OTA center 500 (S16 in Figure 3), acquire rollback data (for example, version information of the software of the single-bank type computer before the update) (S17 in Figure 3), generate an RB package containing the update software and the rollback data (S18 in Figure 3), and transmit a distribution package containing the generated RB package to the vehicle 100 (S19 in Figure 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, by the mobile terminal 300 sending a package containing the update software and rollback data to the vehicle 100, the vehicle 100 can perform a rollback using the rollback data if the software update (e.g., activation) of the single-bank type computer (e.g., the single-bank microcontroller MC1 shown in Figure 6) fails. This makes it possible to perform suitable software updates using OTA technology not only for the dual-bank type computer installed in the vehicle 100, but also for the single-bank type computer.

[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 sufficient free space is secured in the memory 320 (storage unit) for generating the RB package (NO in S14). As a result, S33 is repeated on the vehicle 100 side. Therefore, the software update is put on hold. After sufficient free space is secured in the memory 320 for generating the RB package (YES in S14), the mobile terminal 300 permits the software update of the single-bank type computer by sending the distribution package (S19). As a result, the processing on the vehicle 100 side proceeds to S34, and the software update of the single-bank type computer is executed. The above process prevents the software update from proceeding in a situation where it cannot be rolled back. In addition, the processor 310 is configured to give a predetermined notification (S15) if there is insufficient free space in the memory 320 (storage unit) for generating the RB package in the software update of the single-bank type computer (NO in S14). This notification process makes it easier for users to understand the situation.

[0101] The vehicle 100 according to this embodiment is equipped with an ECU 110 (control unit) that manages the software update sequence. The ECU 110 is configured to perform a software update of a single-bank type computer using update software received from a mobile terminal 300 (S34 in Figure 3 and S41 in Figure 4), and if the software update fails, it is configured to perform a rollback using rollback data (for example, version information of the single-bank type computer's software before the update) (S44 to S46 in Figure 4). With a vehicle 100 having such a configuration, it becomes easier to manage software updates on the vehicle side.

[0102] The processes shown in Figures 3 and 4 above can be modified as appropriate. For example, in the above embodiment, steps S13 (Figure 3) and S44 (Figure 4) determine whether the update target is a single-bank microcontroller. However, some vehicles may be equipped with an ECU that incorporates a single-bank microcontroller with a memory unit for rollback. In a system that distributes software to such vehicles, steps S13 (Figure 3) and S44 (Figure 4) may be modified to determine whether the update target is a single-bank microcontroller without a memory unit for rollback. That is, even if the update target is a single-bank microcontroller, if the update target has a memory unit for rollback, the system may be modified to determine NO in steps S13 (Figure 3) and S44 (Figure 4). Examples of single-bank microcontrollers with a memory unit for rollback include single-bank microcontrollers with a memory unit for rollback provided within the bank, and single-bank microcontrollers with an externally provided memory unit (non-volatile memory) for rollback. Such single-bank microcontrollers can perform rollback in a manner similar to that of a dual-bank microcontroller.

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

[0104] Figure 7 is a flowchart showing a modified version of the process shown in Figure 3. Referring to Figure 7 along with Figures 1 and 2, in this modified version, S16A to S18A are used instead of S16 to S18 (Figure 3). In S16A, the mobile terminal 300 obtains the new software to be updated (the main software file of the new version) from the OTA center 500 via wireless communication, and also obtains the old software to be updated (the main software file of the version before the update) from the vehicle 100 via 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 new software and the old software. The difference file shows the difference between the new software and the old software. Therefore, the old software can be derived from the new software and the difference file. Also, the new software can be derived from the old software and the difference file. Subsequently, in S18A, the mobile terminal 300 generates an RB package containing the new software to be updated (update software) and the difference file (rollback data). Next, in S19, the mobile terminal 300 transmits the distribution package, including the RB package (S18A), to the vehicle 100 via wireless communication. In this modified example, once the processing in S19 or S20 has been executed for all update targets, the software update process by the mobile terminal 300 is completed.

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

[0106] Referring to Figure 8 along with Figures 1 and 2, in this modified example, S461 and S462 are used instead of S45-S47 (Figure 4). In S41, the target ECU activates the target to be updated. Then, in S42 or S43, similar to the process shown in Figure 4, if the target ECU receives a rollback request from ECU 110, the process proceeds to S44. In S44, the target ECU determines whether the target to be updated is a single-bank microcontroller. If the target to be updated is a single-bank microcontroller (YES in S44), the target ECU of vehicle 100 executes the rollback process (process to revert to the old software) of the target to be updated using the aforementioned differential file (rollback data) in S461. On the other hand, if the target to be updated is not a single-bank microcontroller (NO in S44), the target ECU of vehicle 100 executes the rollback process of the target to be updated using data from another bank of the target to be updated (for example, the original version of the software left on the active side) in S462 (see Figure 5).

[0107] Figure 9 is a diagram illustrating the process of S461 (rollback process of the single-bank microcontroller). Referring to Figure 9, the rollback data (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 microcontroller MC1, following the new software. Subsequently, ECU121 (target ECU) switches the write surface of the single-bank microcontroller MC1 to the active surface (activates it) in S41 of Figure 8. If ECU121 successfully activates the single-bank microcontroller MC1 and does not receive a rollback request from ECU110, ECU121 performs a self-reset and then waits for a shutdown request from ECU110. In this case, the bank on which the new software was written becomes the active surface. That is, the single-bank microcontroller MC1 starts up with the new software (updated program).

[0108] On the other hand, if ECU121 receives a rollback request from ECU110, ECU121 executes the rollback process for the single-bank microcontroller MC1 (S461 in Figure 8). Specifically, ECU121 uses the difference file mentioned above to revert the new software back to the old software. After that, the bank that has been rewritten with the old software becomes the active plane. In this case, the single-bank microcontroller MC1 starts up with the old software (the program before the update).

[0109] The software distribution system according to the above modified example also enables suitable software updates via OTA technology for the single-bank type computer installed in the vehicle 100. Furthermore, with the above software distribution system, even if communication between the mobile terminal 300 and the vehicle 100 becomes impossible due to a communication failure or other reason after the mobile terminal 300 has sent a package to the vehicle 100, the vehicle 100 can perform a rollback.

[0110] The receiving, acquiring, generating, updating, notification, and transmitting units of the mobile terminal 300 may be implemented not by software, but by dedicated hardware (electronic circuits). In the above embodiment, an on-premise server is used as the OTA center 500 (see Figure 1). However, it is not limited to this, and the functions of the OTA center 500 (for example, functions related to software distribution) may be implemented on the cloud using cloud computing. In other words, the OTA center 500 may be a cloud server.

[0111] The vehicle may be equipped with an OTA master with OTA access capabilities. The vehicle may include a TCU (Telematics Control Unit) and / or a DCM (Data Communication Module) for wireless communication with an OTA center. It is not required that the vehicle be configured for autonomous driving. The vehicle may be an xEV (electric vehicle) other than a BEV. The vehicle may be equipped with an internal combustion engine (e.g., a gasoline engine, a biofuel engine, or a hydrogen engine). The vehicle is not limited to a four-wheeled passenger car, but may be a bus or a truck, or a three-wheeled xEV. The vehicle may be equipped with flight capabilities. 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 intended use. The vehicle may be a mobile store vehicle, a robotaxi, an automated guided vehicle (AGV), or agricultural machinery. The vehicle may be an unmanned or single-seater small BEV (e.g., a last-mile BEV, an electric wheelchair, or an electric scooter).

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

[0113] 100 vehicles, 110, 121, 122 ECUs, 111, 310, 510 processors, 112, 320, 520 memory, 130 driving devices, 140 ADS, 150 start switches, 170 HMIs, 190 communication devices, 300 mobile terminals, 330 communication modules, 500 OTA centers, 530 communication modules, MC1 single-bank microcontrollers, MC2 dual-bank microcontrollers.

Claims

1. A vehicle equipped with multiple computers, In the case where the target computer for software update among the aforementioned multiple computers is a single-bank type computer, the system includes an acquisition unit that acquires a package containing update software and rollback data. The acquisition unit is configured to receive the package from a mobile terminal when the update target is a single-bank type computer. A vehicle further comprising a rollback unit that, if the target of the update is a single-bank type computer, and if the activation of the target of the update fails, uses the rollback data contained in the package to request the software body of the previous version from the mobile terminal, and uses the software body of the previous version received from the mobile terminal to perform a rollback process on the target of the update.

2. The vehicle according to claim 1, wherein the rollback data includes version information of the software of the single-bank type computer prior to the update.

3. The vehicle according to claim 1, wherein the rollback unit is configured to execute a rollback process for the update target without receiving the software body of the previous version from the mobile terminal if the update target is a dual-bank type computer and activation of the update target fails.

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

5. The vehicle according to any one of claims 1 to 4, further comprising an update unit that, when the package is acquired by the acquisition unit, performs the download and installation of the update software for the update target.