Server, software distribution system

Abstract

To provide a server and a software distribution system capable of suitably updating software by an OTA technique also for a vehicle not having an OTA (Over The Air) access function.SOLUTION: In a software distribution system, a server 500 has a processor functioning as a first classification unit for classifying multiple vehicles as distribution objects of software into a first vehicle 100 and a second vehicle 200, and a distribution control unit for more preferentially executing software distribution to a second vehicle than software distribution to a first vehicle. The first vehicle 100 performs radio communication with the server 500 and directly receives software distributed by the server 500 from the server 500. The second vehicle 200 is constituted so as to be capable of communicating with a mobile terminal 300 that performs radio communication with the server 500, and receives software distributed by the server 500 via the mobile terminal 300.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to a server and a software distribution system. [Background technology]

[0002] Japanese Patent Application 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] Japanese Patent Application Publication No. 2017-149323 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. The target ECU (the ECU whose software is to be updated) then installs and activates the software in that order, thereby updating the software.

[0005] However, not all vehicles are capable of wireless communication with the OTA center. Software is not distributed from the OTA center to vehicles that cannot communicate wirelessly with the OTA center. It is desirable to be able to distribute software using OTA technology even to vehicles that do not have the function to communicate directly wirelessly with the OTA center (hereinafter referred to as the "OTA access function").

[0006] 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 vehicles that do not have OTA access functionality. [Means for solving the problem]

[0007] According to an embodiment of a first aspect of the present disclosure, there is provided a server as described below. (Item 1) The server is configured to distribute software. The server includes a first classification unit and a distribution control unit. The first classification unit is configured to classify multiple vehicles to which software is to be distributed into first vehicles and second vehicles. The distribution control unit is configured to prioritize software distribution to the second vehicle over software distribution to the first vehicle. The first vehicle is configured to wirelessly communicate with the server and to directly receive the software distributed by the server from the server. The second vehicle is configured to be able to communicate with a mobile terminal that wirelessly communicates with the server and is configured to receive the software distributed by the server via the mobile terminal.

[0008] The server can function as an OTA (Over The Air) center that distributes software. The first vehicle has the ability to communicate directly with the server via wireless communication (i.e., OTA access function). The second vehicle communicates wirelessly with the server via a mobile terminal. In a system including the server, the first vehicle, and the second vehicle, OTA communication speeds (amount of data transmitted and received per unit time) tend to vary significantly between vehicles. Because the second vehicle communicates wirelessly with the server via a mobile terminal, the communication speed of the second vehicle tends to be slower than that of the first vehicle. Depending on the situation, the large variation in communication speeds between vehicles may pose a problem. For example, a vehicle with a slow communication speed may take a long time to receive the software after the server starts distributing it, which may prevent it from updating its software in a timely manner.

[0009] Therefore, the server prioritizes software distribution to the second vehicle over software distribution to the first vehicle. By setting software distribution priorities for each vehicle in this way, software distribution to multiple vehicles can be performed in the appropriate order. This reduces delays in software updates in the second vehicle due to variations in communication speeds between vehicles.

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

[0011] (Item 2) The server according to item 1 further has the following feature: The server further includes a second classification unit that classifies a plurality of vehicles according to the type of software to be distributed. The distribution control unit is configured to prioritize distribution to a second vehicle over distribution to a first vehicle when distributing software to each vehicle classified into the same category by the second classification unit.

[0012] According to the above configuration, when the server distributes the same software to a plurality of vehicles, it is possible to give priority to distribution to the second vehicle over distribution to the first vehicle.

[0013] (Item 3) The server described in item 2 further has the following features: The second classification unit is configured to classify a plurality of vehicles into a first category to which vehicles receiving software related to entertainment belong, and a second category to which vehicles receiving software related to driving control belong. The distribution control unit is configured to prioritize software distribution to vehicles belonging to the second category over software distribution to vehicles belonging to the first category.

[0014] The distribution of software related to driving control tends to be more urgent than the distribution of software related to entertainment. With the above configuration, the server can more easily execute the distribution of software with high urgency at an early stage.

[0015] (Item 4) The server according to item 3 further has the following features. The second classification unit is configured to further classify vehicles classified into the first category into a third category to which vehicles that will receive software that is not for rollback belong, and a fourth category to which vehicles that will receive software that is for rollback belong. The distribution control unit is configured to give priority to software distribution to vehicles that belong to the fourth category over software distribution to vehicles that belong to the third category. The second classification unit is configured to further classify vehicles classified into the second category into a fifth category to which vehicles that will receive software that is not for rollback belong, and a sixth category to which vehicles that will receive software that is for rollback belong. The distribution control unit is configured to give priority to software distribution to vehicles that belong to the sixth category over software distribution to vehicles that belong to the fifth category.

[0016] According to the above configuration, the server can more easily distribute urgent software at an early stage.

[0017] (Item 5) The server according to any one of items 2 to 4 further has the following features: The second classification unit is configured to classify a plurality of vehicles into a seventh category to which vehicles receiving non-recall software belong, and an eighth category to which vehicles receiving recall software belong. The distribution control unit is configured to prioritize software distribution to vehicles belonging to the eighth category over software distribution to vehicles belonging to the seventh category.

[0018] According to the above configuration, the server can more easily distribute urgent software at an early stage.

[0019] (Item 6) The server according to any one of Items 1 to 5 further has the following feature: The server further includes a storage device that stores information indicating whether each of a plurality of vehicles has subscribed to a premium service that allows the vehicle to receive software distribution preferentially from the server. When distributing predetermined software to a plurality of first vehicles, the distribution control unit is configured to prioritize distribution to first vehicles that have subscribed to the premium service over distribution to first vehicles that have not subscribed to the premium service.

[0020] According to the above configuration, early software distribution is more likely to be performed for vehicles of users who desire early software distribution (vehicles that have subscribed to premium services).

[0021] (Item 7) The server according to item 6 further has the following feature: The predetermined software is entertainment-related software.

[0022] If the software distribution order is determined according to user preferences, there is a possibility that the distribution of urgent software may be delayed. Therefore, in the above configuration, the premium service is targeted at the distribution of entertainment-related software, which is less urgent. This makes it easier to distribute software according to user preferences without hindering the distribution of urgent software.

[0023] According to an embodiment of the second aspect of the present disclosure, there is provided a software distribution system as follows.

[0024] (Item 8) The software distribution system includes the server according to any one of Items 1 to 7, a plurality of vehicles, and a mobile terminal. The mobile terminal is configured to transmit software acquired from the server to a second vehicle via wireless communication.

[0025] According to the above configuration, convenience for the user is improved. (Item 9) The software distribution system according to item 8 further has the following features: The mobile terminal is a smartphone.

[0026] According to the above configuration, a system that is highly convenient for users is realized. [Effects of the Invention]

[0027] According to the present disclosure, suitable software updates using OTA technology are possible even for vehicles that do not have OTA access functionality. [Brief explanation of the drawings]

[0028] [Figure 1] 1 is a diagram illustrating a configuration of a software distribution system according to an embodiment of the present disclosure. [Figure 2] 1 is a diagram for explaining an overview of a software update method according to an embodiment of the present disclosure; [Figure 3] 1 is a flowchart illustrating a processing procedure of a software distribution method according to an embodiment of the present disclosure. [Figure 4] 4 is a flowchart showing a processing procedure relating to software distribution in the software distribution method shown in FIG. 3. [Figure 5] 1 is a diagram illustrating a distribution order priority determined by a software distribution method according to an embodiment of the present disclosure. [Figure 6] FIG. 4 is a diagram illustrating a modified example of the process shown in FIG. 3. DETAILED DESCRIPTION OF THE INVENTION

[0029] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present disclosure will be described in detail with reference to the accompanying drawings. In the drawings, the same or corresponding parts are designated by the same reference numerals and their description will not be repeated.

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

[0031] Each of the vehicles 100 and 200 is, for example, an electric vehicle (BEV) that does not have an internal combustion engine. However, while the vehicle 100 has an OTA access function (a function for directly communicating wirelessly with the OTA center 500), the vehicle 200 does not have the OTA access function. In other words, the vehicle 100 can communicate wirelessly directly with the OTA center 500, but the vehicle 200 cannot communicate with the OTA center 500 without going through another communication device (i.e., a communication device other than the communication device provided in the vehicle 200 itself). Specifically, the vehicle 200 communicates wirelessly with the OTA center 500 via the mobile terminal 300.

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

[0033] 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 directly communicating wirelessly with the OTA center 500. The communication module 330 also includes a communication I / F for directly communicating wirelessly with the vehicle 200. The mobile terminal 300 mediates communication between the vehicle 200 and the OTA center 500. For example, in response to a request from the vehicle 200, the mobile terminal 300 specifies the address of the OTA center 500 and accesses the communication network NW, thereby enabling the vehicle 200 (ECU 210) to communicate with the OTA center 500 via the mobile terminal 300 (communication module 330). This establishes wireless communication between the vehicle 200 and the OTA center 500.

[0034] Application software (hereinafter referred to as a "mobile app") for using the services provided by the OTA center 500 is installed in the mobile terminal 300. The mobile app associates the identification information (terminal ID) of the mobile terminal 300 with the identification information (vehicle ID) of the vehicle 200 and registers the information in the OTA center 500. The mobile terminal 300 can also exchange information with the OTA center 500 via the mobile app.

[0035] 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 remote updates of vehicle ECU software from the center via a communication section. The OTA center 500 distributes software for the vehicle ECU. "ECU" stands for Electronic Control Unit.

[0036] 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 each of a plurality of vehicles (including the vehicle 100) and 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 wireless base stations. The communication network NW may also include a mobile phone network.

[0037] Vehicle 100 includes OTA master 110 and multiple ECUs (including ECUs 121 and 122). Vehicle 200 includes multiple ECUs (including ECUs 210, 221, and 222). OTA master 110 includes a built-in computer and functions as an on-board diagnostic device. Each vehicle may include any number of ECUs. Each on-board ECU includes a built-in computer that includes at least one processor and at least one memory. Each on-board ECU may include multiple microcomputers (microcomputers) in the form of a main microcomputer and a sub-microcomputer.

[0038] In vehicle 100, OTA master 110 and each ECU are connected via a communication bus, and are configured to be able to communicate with each other via wired communication. In vehicle 200, ECUs are connected via a communication bus, and are configured to be able to communicate with each other via wired communication. The communication method between the control devices in each vehicle is not particularly limited, and may be, for example, CAN (Controller Area Network) or Ethernet (registered trademark).

[0039] The OTA master 110 includes a processor 111, a memory 112, and a communication module 113. The processor 111 includes, for example, a CPU. The memory 112 includes, for example, a non-volatile memory such as a flash memory. The communication module 113 includes a communication I / F (interface) for directly performing wireless communication with the OTA center 500. For example, the communication module 113 specifies the address of the OTA center 500 and accesses the communication network NW, thereby establishing wireless communication between the vehicle 100 (communication module 113) and the OTA center 500. The communication module 113 may include a TCU (Telematics Control Unit) and / or DCM (Data Communication Module) for performing wireless communication.

[0040] The ECU 210 includes a processor 211 and a memory 212. The processor 211 includes, for example, a CPU. The memory 212 includes, for example, a non-volatile memory such as a flash memory. The vehicle 200 further includes a communication device 290. The ECU 210 communicates with devices outside the vehicle through the communication device 290. The communication device 290 includes a communication I / F (interface) for directly communicating wirelessly with the mobile terminal 300. The communication device 290 and the mobile terminal 300 may perform short-range communication such as wireless local area network (LAN), near field communication (NFC), or Bluetooth (registered trademark). The communication device 290 may directly communicate with the mobile terminal 300 located inside or within the vicinity of the vehicle. While the vehicle 200 is stopped, the mobile terminal 300 inside or outside the vehicle and the ECU 210 may exchange information with each other via the communication device 290. Furthermore, while the vehicle 200 is traveling, the mobile terminal 300 inside the vehicle and the ECU 210 may exchange information with each other via the communication device 290. The ECU 210 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.

[0041] The communication device 290 may further include a communication I / F for performing wired communication with a scan tool (not shown) (a dedicated tool for performing wired software updates). The ECU 210 may perform wired communication with the scan tool connected to a DLC (Data Link Connector) (not shown) in the vehicle via the communication device 290.

[0042] As described above, the OTA master 110 of the vehicle 100 and the ECU 210 of the vehicle 200 are each configured to be able to wirelessly communicate with the OTA center 500. Each of the vehicles 100 and 200 can communicate with the OTA center 500 whether the vehicle is stopped or running. The OTA master 110 and the ECU 210 each manage in-vehicle information, receive campaigns, and manage software update sequences. Hereinafter, when there is no need to distinguish between the OTA master 110 and the ECU 210, they will be referred to as "update masters." In other words, the OTA master 110 corresponds to the update master of the vehicle 100, and the ECU 210 corresponds to the update master of the vehicle 200.

[0043] Each of the vehicles 100, 200 is an autonomous vehicle configured to be capable of autonomous driving. More specifically, each of the vehicles 100, 200 is configured to be capable of both manned and unmanned driving. Each of the vehicles 100, 200 is configured to be capable of autonomous driving without a driver, but can also be driven manually by a user (manned driving). Furthermore, each of the vehicles 100, 200 can also perform autonomous driving (e.g., auto cruise control) while manned. The level of autonomous driving may be fully autonomous (level 5) or conditionally autonomous (e.g., level 4).

[0044] Vehicles 100 and 200 are respectively equipped with driving devices 130 and 230 and ADS (Autonomous Driving Systems) 140 and 240. In vehicle 100, ECU 121 is configured to control driving device 130. In vehicle 200, ECU 221 is configured to control driving device 230.

[0045] Each of the driving devices 130, 230 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 brake device provided on each wheel of the vehicle and an actuator that drives the brake device. The steering device includes, for example, an EPS (Electric Power Steering) and an actuator that drives the EPS.

[0046] Each of the ADSs 140 and 240 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 ADSs 140 and 240 cooperate with the ECUs 121 and 221, respectively, to generate a driving plan (information indicating future vehicle behavior) according to the external environment of the vehicle. The ADSs 140 and 240 then request the ECUs 121 and 221 to control various actuators included in the driving devices 130 and 230, respectively, so as to drive the vehicles 100 and 200 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 can be attached to and detached 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 vehicles 100 and 200 are equipped with start switches 150 and 250 and HMIs (Human Machine Interfaces) 170 and 270, respectively.

[0049] Each of the activation switches 150, 250 is a switch that allows a user to activate a vehicle system (a control system of the vehicle 100, 200), and is installed, for example, inside the vehicle cabin. The activation switch is generally called a "power switch" or "ignition switch." The user operates the activation switch 150, 250 to switch the vehicle system (including each ECU mounted on the vehicle) on (operated) or off (stopped). Turning the activation switch 150, 250 on activates the vehicle system from a stopped state, and the vehicle system enters an operating state (hereinafter also referred to as "IG on"). Turning the activation switch 150, 250 off while the vehicle system is operating switches the vehicle system to a stopped state (hereinafter also referred to as "IG off").

[0050] The ON operation of the start switches 150, 250 is an operation for switching the vehicle state from IG OFF to IG ON. When the user turns on the start switches 150, 250, a startup request is input to each on-board ECU. That is, each on-board ECU accepts the startup request from the user. On the other hand, the OFF operation of the start switches 150, 250 is an operation for switching the vehicle state from IG ON to IG OFF. When the user turns off the start switches 150, 250, a shutdown request is input to each on-board ECU. That is, each on-board ECU accepts the shutdown request from the user. However, the OFF operation of the start switches 150, 250 is prohibited when the vehicle is running.

[0051] Each of the HMIs 170, 270 includes an input device and a display device. Each of the HMIs 170, 270 may include a touch panel display that functions as an input device and a display device. Each of the HMIs 170, 270 may include an information display or a ten-tail as a display device. Each of the HMIs 170, 270 may include steering wheel switches as an input device. Furthermore, at least one of an IVI (In-Vehicle Infotainment) system, an instrument panel, and a head-up display may function as each of the HMIs 170, 270. Each of the HMIs 170, 270 may include an input device and a display device of a car navigation system.

[0052] FIG. 2 is a diagram for explaining an overview of a software update method according to this embodiment. Referring to FIG. 2 together with FIG. 1, the process related to a software update (more specifically, a vehicle software update using OTA) is performed in the following order: configuration synchronization, campaign notification and application acceptance, download, installation, activation, and software update completion notification. The process described below is performed by the OTA center 500 and each vehicle (including vehicles 100 and 200) that receives software distribution from the OTA center 500. The number of vehicles that receive software distribution from the OTA center 500 may be around 50, or may be between 100 and 1000, or may be 1000 or more.

[0053] A vehicle in the IG-on state repeatedly performs configuration synchronization every time a preset time has elapsed. A vehicle in the IG-on state also performs configuration synchronization when a configuration synchronization request is received from the OTA center 500. The configuration synchronization process by the vehicle 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.

[0054] When the OTA center 500 receives the vehicle configuration information from the vehicle, it checks for currently occurring campaigns (software updates). If a campaign applicable to the vehicle exists, the OTA center 500 transmits an consent request signal to the vehicle user requesting consent to the download of new software (software updates) 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 vehicle functions 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. Note that 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 receives the campaign notification (acceptance request signal), it prompts the user to input whether or not to accept the application of the campaign. Specifically, the vehicle displays a message such as "New software has been found. Would you like to apply it to this vehicle?" on the in-vehicle HMI (e.g., HMI 170, 270) and requests the user to input either "accept" or "reject." If the user inputs "accept" to the in-vehicle HMI, the vehicle executes the download-related process described below. On the other hand, if the user inputs "reject" to the in-vehicle HMI, the vehicle does not execute the download-related process. In this case, the OTA center 500 terminates the software update-related process without proceeding to the download phase.

[0056] In this embodiment, the OTA center 500 and the vehicle update master (for example, the OTA master 110 or the ECU 210) execute the process related to downloading in the procedure described below.

[0057] The vehicle's update master requests a distribution package including new software from the OTA center 500. The update master then downloads (receives and stores) the distribution package while wirelessly communicating with the OTA center 500. In addition to the new software (e.g., a set of update data for each ECU that is the target of the campaign), the distribution package may also include package attribute information (information indicating the update category, the number of update data in the distribution package, the installation order for each ECU, etc.) and update data attribute information (e.g., an identifier for the target ECU, verification data for verifying the validity of the update data, etc.). The target ECU is the ECU that is the target of a software update. For example, the target ECU may be ECU 121 or 221, and the software to be updated may be an autonomous driving control program.

[0058] Through the above-described download process, the distribution package is stored in a storage device (e.g., memory 112 or 212) provided in the update master. During the download, the in-vehicle HMI notifies the user of the progress of the download. After the download is complete, the update master verifies the authenticity of the downloaded distribution package. If the verification result is "normal," the update master notifies the OTA center 500 of the software update status (download completed). This notification means that the download was successful.

[0059] If the download is successful, the vehicle performs the installation. Specifically, the update master requests at least one target ECU (e.g., ECU 121 or 221) to output the target ECU's status and DTC (Diagnostic Trouble Code). The update master determines whether installation can be performed for each target ECU based on the target ECU's status and DTC. The update master then transfers the new software (update data) to target ECUs that can be installed. Upon receiving the update data, the target ECU installs the update data (writes it to non-volatile memory). During the installation, the in-vehicle HMI notifies the user of the progress of the installation.

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

[0061] If the download and installation are successful, the vehicle enters a state waiting for activation. When the vehicle's activation switch (e.g., activation switch 150 or 250) is then turned off, the update master displays a predetermined message on the in-vehicle HMI, requesting the user to input either "accept" or "reject." If the user inputs "accept" into the in-vehicle HMI, the update master activates the installed software (activates the installed software). If the update master fails to activate the software, the update master requests the OTA center 500 to roll back the software. Upon receiving a rollback request from the vehicle, the OTA center 500 distributes rollback software to the vehicle. The update master can then use the rollback software to revert (roll back) the software that failed to be activated to its original version. If the user inputs "reject" into the in-vehicle HMI, the update master cancels the software update process without activating the software, and the vehicle system is shut down.

[0062] If the update master is successfully activated, the update master displays the results 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. The update master then notifies the OTA center 500 of the software update status (software update complete). This notification means that the OTA software update was successful. When this notification is made, the vehicle's control system is shut down and the IG is turned off. Then, when the vehicle's start switch is turned on, the vehicle system is turned on. This causes the update program (new version of software) to start in the target ECU.

[0063] The software to be updated is not limited to a driving assistance control program such as the above-described autonomous driving control program, and may be any program. In this embodiment, the OTA center 500 distributes software for responding to recalls (hereinafter also referred to as "recall response SW"). Furthermore, the OTA center 500 distributes software related to driving control (hereinafter also referred to as "driving control SW") and software related to entertainment (hereinafter also referred to as "entertainment SW") as software that is not related to recalls (hereinafter also referred to as "non-recall response SW"). Examples of driving control SW include the above-described driving assistance control programs as well as control programs for manual driving (e.g., software for accelerator control, brake control, or steering control). The driving control SW may be a control program for the driving device 130, 230 or the ADS 140, 240. Examples of entertainment SW include display control programs such as AR (augmented reality) control as well as programs for updating information used in display control (e.g., map information). The entertainment SW may be a control program for the HMI 170, 270.

[0064] The OTA center 500 pre-registers identification information (vehicle ID) of each vehicle (including vehicles 100 and 200) that receives the vehicle software update service from 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"), distinguishing them by vehicle ID. As shown in FIG. 2, the vehicle information includes information indicating whether each vehicle corresponds to a first vehicle or a second vehicle. The first vehicle is a vehicle that wirelessly communicates with the OTA center 500 and directly receives software distributed by the OTA center 500 from the OTA center 500. The second vehicle is configured to be able to communicate with a mobile terminal that wirelessly communicates with the OTA center 500 and receives the software distributed by the OTA center 500 via the mobile terminal. For example, vehicle 100 corresponds to the first vehicle, and vehicle 200 corresponds to the second vehicle. The vehicle information further includes the communication address of each vehicle (for the second vehicle, the communication address of the mobile terminal). As shown in FIG. 2, the vehicle information includes information indicating whether each vehicle has subscribed to a premium service. The premium service is a service that allows the vehicle user to receive software distribution preferentially from the OTA center 500. A vehicle user can subscribe to the premium service by, for example, signing a subscription contract with a service provider.

[0065] FIG. 3 is a flowchart showing the processing steps of the software distribution method according to this embodiment. The series of processes shown in this flowchart are executed by the OTA center 500 at a predetermined interval. The execution interval may be a fixed value or may be variable depending on the situation (e.g., the occurrence of a campaign, the number of vehicles waiting for distribution, the processing load, the communication capacity, etc.). In this embodiment, the OTA center 500 corresponds to an example of a "server" according to the present disclosure, and the processor 510 shown in FIG. 1 functions as an example of a "first classification unit," a "distribution control unit," and a "second classification unit" according to the present disclosure. "S" in the flowchart denotes a step. Furthermore, "SW" denotes software. The following flowchart is realized by one or more processors reading and executing programs stored in one or more memories.

[0066] 1 and 2, in S11, the OTA center 500 requests configuration synchronization from each vehicle registered in the OTA center 500. As a result, the OTA center 500 receives vehicle configuration information from each vehicle that has performed configuration synchronization. Subsequently, in S12, the OTA center 500 executes a campaign notification to each vehicle to which the campaign is applicable. Subsequently, in S13, the OTA center 500 checks the response of each vehicle to the campaign notification. Specifically, the OTA center 500 determines, as distribution targets, vehicles that have responded with "accept" to the campaign notification (i.e., vehicles that have requested a distribution package from the OTA center 500). Furthermore, if the OTA center 500 receives a rollback request from any vehicle, it also adds that vehicle to the distribution targets. In S13, the OTA center 500 checks the identification information (vehicle ID) of each vehicle included in the distribution targets and the distribution package or rollback software requested by each vehicle.

[0067] In the following S14, OTA center 500 determines whether the above distribution targets (S13) include vehicles (hereinafter also referred to as "8C vehicles") that request the recall response SW (distribution package). If the 8C vehicles are included in the distribution targets (YES in S14), the process proceeds to S20. The 8C vehicles included in the distribution targets correspond to vehicles that receive the recall response SW distribution (i.e., vehicles belonging to the 8th category).

[0068] In S20, the OTA center 500 executes a series of processes described below and shown in Fig. 4. Fig. 4 is a flowchart showing the processes related to software distribution executed by the OTA center 500 in S20.

[0069] 1 and 2, in S21, the OTA center 500 acquires information about the target vehicle (for example, the vehicle information shown in FIG. 2). If the determination in S14 of FIG. 3 is YES, each 8C vehicle included in the distribution target (S13) corresponds to the target vehicle.

[0070] In S22, the OTA center 500 classifies each target vehicle into a first vehicle and a second vehicle based on the vehicle information shown in Fig. 2. For example, a target vehicle having a configuration similar to that of vehicle 100 shown in Fig. 1 is classified as a first vehicle. Also, a target vehicle having a configuration similar to that of vehicle 200 shown in Fig. 1 is classified as a second vehicle.

[0071] In S23, the OTA center 500 determines the priority of delivery for each target vehicle. The OTA center 500 according to this embodiment sets the priority of the target vehicle classified as the second vehicle higher than the priority of the target vehicle classified as the first vehicle.

[0072] Note that when there are multiple target vehicles classified as first vehicles, the method for determining the priority of these first vehicles is arbitrary. For example, the priority of each first vehicle may be determined so that the longer the first vehicle has been using the pre-update software, i.e., the earlier the start date and time of use of the pre-update software (e.g., activation date and time), the higher the priority. Alternatively, the priority of each first vehicle may be determined so that the earlier the first vehicle responds with "acceptance," the higher the priority. When there are multiple target vehicles classified as second vehicles, the method for determining the priority of each second vehicle can be the same as for the first vehicle.

[0073] In S24, the OTA center 500 distributes software to each target vehicle according to the priority determined in S23. In the following S25, the OTA center 500 determines whether software distribution to all target vehicles has been completed. While the determination in S25 is NO, the software distribution (S24) continues. In S24, the OTA center 500 distributes software to target vehicles in order of priority, starting with the target vehicle with the highest priority. In other words, the higher the priority, the sooner the target vehicle receives the software distribution. In this embodiment, the OTA center 500 prioritizes software distribution to the second vehicle over software distribution to the first vehicle. If the determination in S14 of FIG. 3 is YES, the recall response SW is distributed in S24.

[0074] When the software distribution to all target vehicles is completed (YES in S25), S20 in FIG. 3 ends along with the series of processes shown in FIG. 4. The target vehicles that received the distribution through the process of S20 download (receive and save) the distributed software and update their software according to the procedure shown in FIG. 2. When the process of S20 is executed, the series of processes shown in FIG. 3 ends once, but the series of processes shown in FIG. 3 is restarted according to the execution cycle. As a result, the determination in S14 is executed again via the above-mentioned S11 to S13. Then, if the distribution of the recall-compatible SW is completed, a NO determination is made in S14, and the process proceeds to S15. In this embodiment, the OTA center 500 does not distribute non-recall-compatible SW (see S15 to S18) until the distribution of the recall-compatible SW is completed. Therefore, software distribution to the above-mentioned 8C vehicles (vehicles that will receive the recall-compatible SW) is executed with priority over software distribution to vehicles that will receive the non-recall-compatible SW (vehicles belonging to the seventh category).

[0075] 1 and 2, and again referring to FIG. 3, in S15, the OTA center 500 determines whether the distribution targets (S13) include vehicles requesting a rollback of the driving control SW (hereinafter also referred to as "6C vehicles"). If the 6C vehicles are included in the distribution targets (YES in S15), the process proceeds to S20. The 6C vehicles included in the distribution targets correspond to vehicles that receive distribution of software for rollback of driving control (i.e., vehicles belonging to the sixth category).

[0076] Even if the determination in S15 is YES, the process of S20 described above (i.e., the series of processes shown in FIG. 4) is executed. However, if the determination in S15 is YES, each 6C vehicle included in the distribution targets (S13) becomes a target vehicle, and in S24, software for rollback related to driving control is distributed to each 6C vehicle according to the priority determined in S23. Then, after software distribution to all target vehicles (6C vehicles) is completed (YES in S25), the series of processes shown in FIG. 3 is started again according to the execution period. As a result, the determination in S15 is executed again via the above-described S11 to S14. Then, if distribution of the software for rollback related to driving control has been completed, a determination in S15 is NO, and the process proceeds to S16. In this embodiment, the OTA center 500 does not distribute software (S16) that is not for rollback related to driving control until distribution of the software for rollback related to driving control is completed. For this reason, software distribution to the aforementioned 6C vehicles (vehicles receiving software for rollback of driving control) will be given priority over software distribution to the later-described 5C vehicles (vehicles receiving software that is not for rollback of driving control).

[0077] In S16, the OTA center 500 determines whether the distribution targets (S13) include vehicles (hereinafter also referred to as "5C vehicles") that request the driving control SW (distribution package). If the 5C vehicles are included in the distribution targets (YES in S16), the process proceeds to S20. The 5C vehicles included in the distribution targets correspond to vehicles that receive software (distribution package) that is not for rollback related to driving control (i.e., vehicles belonging to the fifth category).

[0078] Even if the determination in S16 is YES, the processing of S20 described above (i.e., the series of processing shown in FIG. 4) is executed. However, if the determination in S16 is YES, each of the 5C vehicles included in the distribution targets (S13) becomes a target vehicle, and in S24, software that is not for rollback related to driving control is distributed to each of the 5C vehicles according to the priority determined in S23. Then, after software distribution to all target vehicles (5C vehicles) is completed (YES in S25), the series of processing shown in FIG. 3 is started again according to the execution period. As a result, the determination in S16 is executed again via the above-mentioned S11 to S15. Then, if distribution of software that is not for rollback related to driving control has been completed, a NO determination is made in S16, and the processing proceeds to S17.

[0079] In S17, the OTA center 500 determines whether the distribution targets (S13) include vehicles requesting rollback of entertainment SW (hereinafter also referred to as "4C vehicles"). If the distribution targets include 4C vehicles (YES in S17), the process proceeds to S20. The 4C vehicles included in the distribution targets correspond to vehicles that receive distribution of entertainment-related rollback software (i.e., vehicles belonging to the fourth category).

[0080] Even if the determination in S17 is YES, the process of S20 described above (i.e., the series of processes shown in FIG. 4) is executed. However, if the determination in S17 is YES, each 4C vehicle included in the distribution target (S13) becomes a target vehicle. In S23, the OTA center 500 prioritizes target vehicles classified as second vehicles higher than the priority of target vehicles classified as first vehicles. If there are multiple target vehicles classified as first vehicles, the OTA center 500 prioritizes first vehicles that subscribe to the premium service higher than the priority of first vehicles that do not subscribe to the premium service. Furthermore, if there are multiple target vehicles classified as second vehicles, the OTA center 500 prioritizes second vehicles that subscribe to the premium service higher than the priority of second vehicles that do not subscribe to the premium service. For vehicles that still have the same priority after prioritizing based on whether or not they subscribe to the premium service as described above, the OTA center 500 may determine the priority of the distribution order based on the start date and time of use of the software before the update, the time of the reply of "acceptance," etc. Furthermore, in S24, entertainment-related rollback software is distributed to each 4C vehicle according to the priority determined in S23. Then, after software distribution to all target vehicles (4C vehicles) is completed (YES in S25), the series of processes shown in FIG. 3 is started again according to the execution cycle. As a result, the determination in S17 is executed again after going through the above-described S11 to S16. Then, if distribution of entertainment-related rollback software is completed, a NO determination is made in S17, and the process proceeds to S18. In this embodiment, the OTA center 500 does not distribute entertainment-related software that is not for rollback (S18) until distribution of entertainment-related rollback software is completed. Therefore, software distribution to the above-described 4C vehicles (vehicles that receive entertainment-related rollback software) is executed with priority over software distribution to the below-described 3C vehicles (vehicles that receive entertainment-related rollback software).

[0081] In S18, the OTA center 500 determines whether the distribution targets (S13) include vehicles (hereinafter also referred to as "3C vehicles") that request entertainment SW (distribution package). If 3C vehicles are included in the distribution targets (YES in S18), the process proceeds to S20. The 3C vehicles included in the distribution targets correspond to vehicles that receive entertainment-related software (distribution package) that is not for rollback (i.e., vehicles belonging to the third category).

[0082] Even if the determination in S18 is YES, the process of S20 described above (i.e., the series of processes shown in FIG. 4) is executed. However, if the determination in S18 is YES, each 3C vehicle included in the distribution target (S13) becomes a target vehicle. In S23, the OTA center 500 prioritizes target vehicles classified as second vehicles higher than the priority of target vehicles classified as first vehicles. If there are multiple target vehicles classified as first vehicles, the OTA center 500 prioritizes first vehicles that subscribe to the premium service higher than the priority of first vehicles that do not subscribe to the premium service. Furthermore, if there are multiple target vehicles classified as second vehicles, the OTA center 500 prioritizes second vehicles that subscribe to the premium service higher than the priority of second vehicles that do not subscribe to the premium service. For vehicles that still have the same priority after prioritizing based on whether or not they subscribe to the premium service as described above, the OTA center 500 may determine the priority of the distribution order based on the start date and time of use of the software before the update, the time of the reply of "acceptance," etc. Furthermore, in S24, entertainment-related software that is not for rollback is distributed to each 3C vehicle according to the priority determined in S23. Then, when software distribution to all target vehicles (3C vehicles) is completed (YES in S25), the series of processes shown in Fig. 3 ends. However, the series of processes shown in Fig. 3 are started according to the execution cycle.

[0083] According to the processes shown in Figures 3 and 4, software is distributed according to the priority order shown in Figure 5. Figure 5 is a diagram showing the priority order of distribution determined by the software distribution method according to this embodiment.

[0084] 5, the OTA center 500 prioritizes software distribution to vehicles (vehicles belonging to the second category) that receive distribution of driving control SW over software distribution to vehicles (vehicles belonging to the first category) that receive distribution of entertainment SW. The OTA center 500 prioritizes software distribution to vehicles (vehicles belonging to the fourth and sixth categories) that receive distribution of rollback software over software distribution to vehicles (vehicles belonging to the third and fifth categories) that receive distribution of software that is not for rollback. The OTA center 500 prioritizes software distribution to vehicles (vehicles belonging to the eighth category) that receive distribution of recall-compatible software over software distribution to vehicles (vehicles belonging to the seventh category) that receive distribution of non-recall-compatible software. When distributing entertainment SW to multiple first vehicles, the OTA center 500 prioritizes distribution to first vehicles that have subscribed to the premium service over distribution to first vehicles that have not subscribed to the premium service. When distributing entertainment SW to a plurality of second vehicles, the OTA center 500 gives priority to distribution to second vehicles that have subscribed to the premium service over distribution to second vehicles that have not subscribed to the premium service.

[0085] As described above, the software distribution system according to this embodiment includes an OTA center 500 (server), multiple vehicles (including vehicles 100 and 200), and a mobile terminal 300. The mobile terminal 300 is configured to transmit software acquired from the OTA center 500 to the vehicle 200 via wireless communication. The OTA center 500 includes a first classification unit (S22 in FIG. 4) that classifies multiple vehicles to which software is to be distributed into first vehicles and second vehicles, a distribution control unit (S23 and S24 in FIG. 4) that prioritizes software distribution to the second vehicles over software distribution to the first vehicles, and a second classification unit (S14 to S18 in FIG. 3) that classifies the multiple vehicles according to the type of software to be distributed. In this embodiment, the distribution control unit prioritizes software distribution to the second vehicles over software distribution to the first vehicles when distributing software to vehicles classified into the same category by the second classification unit (see FIG. 5).

[0086] The communication speed of the second vehicle tends to be slower than the communication speed of the first vehicle. In this regard, the OTA center 500 having the above configuration prioritizes software distribution to the second vehicle over software distribution to the first vehicle. In this way, by setting the priority of software distribution for each vehicle, it becomes possible to distribute software to multiple vehicles in an appropriate order. This reduces delays in software updates in the second vehicle due to variations in communication speeds between vehicles. Note that the above-mentioned first classification unit, second classification unit, and distribution control unit may be embodied by dedicated hardware (electronic circuits) rather than software.

[0087] In a configuration in which the OTA center 500 distributes to 100 or more vehicles, the distribution timing may change significantly by the OTA center 500 changing the distribution priority as described above. For example, the OTA center 500 may cause a difference of one week or more (for example, several weeks) in the distribution timing between the vehicle with the highest priority and the vehicle with the lowest priority.

[0088] The processes shown in Figures 3 and 4 above can be modified as appropriate. For example, steps S14 to S18 in Figure 3 that are not suitable for the intended purpose may be removed. Figure 6 is a diagram showing a modified example of the process shown in Figure 3. For example, in a configuration in which a rollback is performed using the original version of software backed up on the vehicle side without the vehicle requesting a rollback from the OTA center 500, a process flow that does not include S15 and S17 as shown in Figure 6 may be adopted.

[0089] In the above embodiment, an on-premise server is used as the OTA center 500 (see FIG. 1). However, the present invention is not limited to this, and functions of the OTA center 500 (for example, functions related to software updates) may be implemented on a cloud using cloud computing. In other words, the OTA center 500 may be a cloud server.

[0090] It is not necessary for a vehicle to be configured to be capable of autonomous driving. The vehicle may be an xEV (electric vehicle) other than a BEV. The vehicle may 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 truck, or a three-wheeled xEV. The vehicle may be equipped with a flight 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 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 skater).

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

[0092] 100,200 Vehicle, 110 OTA Master, 111,211,310,510 Processor, 112,212,320,520 Memory, 113,330,530 Communication Module, 121,122,210,221,222 ECU, 130,230 Driving Device, 140,240 ADS, 150,250 Start Switch, 170,270 HMI, 290 Communication Device, 300 Mobile Terminal, 500 OTA Center.

Claims

1. A server for distributing software, The server in question is a first classification unit that classifies a plurality of vehicles to which software is to be distributed into first vehicles and second vehicles; a distribution control unit that performs software distribution to the second vehicle with priority over software distribution to the first vehicle; Equipped with the first vehicle is configured to wirelessly communicate with the server and directly receive the software distributed by the server from the server; The second vehicle is configured to be able to communicate with a mobile terminal that wirelessly communicates with the server, and is configured to receive software distributed by the server via the mobile terminal.

2. The server in question is a second classification unit that classifies the plurality of vehicles according to the type of software distributed to the vehicles; Further equipped with The server according to claim 1 , wherein the distribution control unit is configured to, in distributing software to each vehicle classified into the same category by the second classification unit, give priority to distribution to the second vehicle over distribution to the first vehicle.

3. the second classification unit is configured to classify the plurality of vehicles into a first category to which vehicles receiving software related to entertainment belong, and a second category to which vehicles receiving software related to driving control belong, The server according to claim 2 , wherein the distribution control unit is configured to preferentially execute software distribution to vehicles belonging to the second category over software distribution to vehicles belonging to the first category.

4. The second classification unit is configured to further classify the vehicles classified into the first category into a third category to which vehicles receiving software that is not for rollback belong, and a fourth category to which vehicles receiving software for rollback belong, the distribution control unit is configured to preferentially execute software distribution to vehicles belonging to the fourth category over software distribution to vehicles belonging to the third category; The second classification unit is configured to further classify the vehicles classified into the second category into a fifth category to which vehicles receiving software that is not for rollback belong, and a sixth category to which vehicles receiving software for rollback belong, The server according to claim 3 , wherein the distribution control unit is configured to preferentially execute software distribution to vehicles belonging to the sixth category over software distribution to vehicles belonging to the fifth category.

5. the second classification unit is configured to classify the plurality of vehicles into a seventh category to which vehicles receiving distribution of non-recall-compliant software belong, and an eighth category to which vehicles receiving distribution of recall-compliant software belong; The server according to claim 2 , wherein the distribution control unit is configured to preferentially execute software distribution to vehicles belonging to the eighth category over software distribution to vehicles belonging to the seventh category.

6. The server in question is a storage device that stores information indicating whether or not each of the plurality of vehicles has subscribed to a premium service that allows the vehicle to preferentially receive software distribution from the server; Further equipped with The server of claim 1, wherein the distribution control unit is configured, when distributing specified software to a plurality of the first vehicles, to prioritize distribution to the first vehicles that have subscribed to the premium service over distribution to the first vehicles that have not subscribed to the premium service.

7. 7. The server according to claim 6, wherein the predetermined software is entertainment-related software.

8. A server according to any one of claims 1 to 7; The plurality of vehicles; The mobile terminal; Equipped with The mobile terminal is configured to transmit the software obtained from the server to the second vehicle via wireless communication.

9. The software distribution system according to claim 8 , wherein the mobile terminal is a smartphone.

Images