vehicle-mounted unit

Abstract

Reduce the frequency of user inquiries regarding software updates. [Solution] The OTA master 11 installed in the vehicle 10 is configured as an in-vehicle device that manages software updates for the vehicle 10. The OTA master 11 determines whether user permission is required based on the type of software. If the OTA master 11 determines that user permission is required, it asks the user whether or not to proceed with the software update process.

Description

Technical Field

[0001] The present invention relates to an in-vehicle device mounted on a vehicle.

Background Art

[0002] As such an in-vehicle device, Patent Document 1 describes an in-vehicle device that manages software updates of a vehicle. When updating software, the in-vehicle device makes inquiries to the user regarding the necessity of the update and the update start time.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] When software updates are performed frequently, the number of inquiries to the user also increases. As a result, the user may feel bothered by frequent inquiries.

Means for Solving the Problems

[0005] The in-vehicle device that solves the above problems is an in-vehicle device mounted on a vehicle and manages software updates of the vehicle, and includes a determination unit that determines whether user permission is required based on the type of the software, and a control unit that makes an inquiry to the user as to whether to perform a process for updating the software when it is determined by the determination unit that the user permission is required.

Effects of the Invention

[0006] The above in-vehicle device has an effect of reducing the frequency of inquiries to the user during software updates.

Brief Description of the Drawings

[0007] [Figure 1] This diagram schematically shows the configuration of one embodiment of an in-vehicle device. [Figure 2] This is a sequence diagram showing the flow of the software update process. [Figure 3] This table shows examples of settings for user approval requirements for each type of software. [Figure 4] This figure shows an example of a consent screen. [Figure 5] This is a diagram showing an example of a selection screen. [Modes for carrying out the invention]

[0008] Below, one embodiment of the in-vehicle device will be described in detail with reference to Figures 1 to 4. <Configuration of the in-vehicle unit> First, the configuration of the in-vehicle device of this embodiment will be described with reference to Figure 1.

[0009] Vehicle 10 is equipped with various ECUs (Electronic Control Units) 15 that control various parts of the vehicle 10. Examples of ECUs 15 include the engine ECU, transmission ECU, brake ECU, advanced driver assistance ECU, and multimedia ECU.

[0010] Furthermore, the vehicle 10 is equipped with an OTA master 11, which is an in-vehicle device that manages software updates in the vehicle 10. The OTA master 11 comprises a processing circuit 12 and a storage device 13. The storage device 13 has a program for managing software updates pre-stored in it. The OTA master 11 is configured to perform processing related to software update management by having the processing circuit 12 read and execute the program stored in the storage device 13. In this embodiment, the OTA master 11 corresponds to an in-vehicle device that manages software updates for the vehicle 10. A wireless communication module 17 for external communication via a mobile communication network 18 is connected to the OTA master 11.

[0011] Furthermore, the vehicle 10 is equipped with an HMI (Human-Machine Interface) 16. The HMI 16 includes an input device that accepts operations from the occupant and an output device that presents information to the occupant through images and sound. In this embodiment, the HMI 16 includes a navigation function that guides the driver along a driving route and an entertainment function that plays music and videos. The OTA master 11, each ECU 15, and the HMI 16 are configured to communicate with each other via an in-vehicle network line 14.

[0012] Software updates in vehicle 10 are performed based on update data distributed from OTA server 20 via a mobile communication network 18, etc. The OTA server 20 includes a processing circuit 21 and a storage device 22. The OTA server 20 is configured to communicate with the outside world via the mobile communication network 18.

[0013] Furthermore, the OTA master 11 and OTA server 20 are configured to communicate with the user's mobile terminal 30 of the vehicle 10 via a mobile communication network 18, etc. An example of the mobile terminal 30 is a smartphone. The mobile terminal 30 includes a processing circuit 31, a storage device 32, and an HMI 33. The processing circuit 31 reads and executes a program stored in the storage device 32. The program stored in the storage device 13 includes a program for vehicle management.

[0014] <Software update> Next, we will explain the software update for vehicle 10. Specifically, the software to be updated includes the software of in-vehicle electronic devices such as the OTA master 11, each ECU 15, and HMI 16. In the following explanation, in-vehicle electronic devices that are subject to software updates will be referred to as "target devices." The software update is performed through three phases: download, installation, and activation.

[0015] During the download phase, software update data is downloaded to the vehicle 10. In the download phase, the OTA master 11 obtains the update data from the OTA server 20 and stores it in the storage device 13. The download phase includes a series of processes related to the download, such as determining whether to proceed with the download and verifying the update data. The update data transmitted from the OTA server 20 to the OTA master 11 may include the update software, compressed data of the update software, or segmented data obtained by dividing the update software or compressed data. The update data may also include an identifier for the updated device and an identifier for the software before the update. The update data is downloaded as a distribution package. The distribution package contains update data for one or more in-vehicle electronic devices.

[0016] During the installation phase, the update software is written to the target device. In the installation phase, the OTA master 11 writes the update software to the target device's memory. The installation phase includes a series of processes related to installation, such as determining whether installation is possible, transferring update data, and verifying the update software. If the update data includes the update software itself, the OTA master 11 transfers the update data to the target device during the installation phase. If the update data includes compressed data, differential data, or segmented data of the update software, a process of generating the update software from the update data is performed. This generation process may be performed by the OTA master 11 or by the target device. The generation of the update software can be done by decompressing the compressed data or assembling the differential data or segmented data. Note that the update software is deactivated upon completion of the installation phase.

[0017] In the activation phase, the update program on the target device is activated. That is, in the activation phase, the software used for the operation of the target device is switched from the software before the update to the software after the update. The activation phase includes a series of processes related to activation, such as determining whether activation can be executed, checking the integrity of the update program, and verifying the execution result of activation.

[0018] Hereinafter, referring to FIGS. 2 to 4, the details of the process related to software update will be described. FIG. 2 shows the flow of the process related to software update. As shown in FIG. 2, when updating software, the OTA server 20 first distributes campaign information to the vehicle 10 to be updated. The campaign information includes information such as the vehicle model to be updated, the update content, the distribution start time of the update data, the size of the update data, and the estimated update time. Note that the update software is classified into multiple types according to the in-vehicle electronic devices, functions, importance, urgency, etc. to which it is applicable. The campaign information also includes information on the type of the update software. The OTA master 11 obtains the type of the software to be updated from such campaign information.

[0019] After that, when the download of the update data becomes executable, the OTA master 11 determines whether user permission is required for the execution of the download based on the type of the update software. As described above, the software update is performed through three phases: download, installation, and activation. In the in-vehicle device of this embodiment, whether user permission is required for the execution of each phase is preset for each type of software. In the storage device 13 of the OTA master 11, a data table regarding whether user permission is required for each phase for each type of software is stored in advance. The OTA master 11 determines whether user permission is required by referring to such a data table.

[0020] Figure 3 shows a configuration example of such a data table. In the case of Figure 3, for software of type A, user consent is required for all of download, installation, and activation. For software of type B, user consent is required for download, but it is stated that user consent is not required for installation and activation. For software of type C, it is stated that user consent is not required for any of download, installation, and activation.

[0021] When the OTA master 11 determines that user consent is not required for download, it automatically starts downloading the update data. When starting the download, the OTA master 11 requests the OTA server 20 to transmit the update data. In response to this request, the OTA server 20 transmits the update data to the OTA master 11. The OTA master 11 stores the received update data in the storage device 13.

[0022] On the other hand, when it is determined that user consent is required for download, the OTA master 11 makes an inquiry to the user for permission to execute the download. When making the inquiry, the OTA master 11 first instructs the HMI 16 to display a permission screen. The HMI 16 displays the permission screen in response to this instruction. The permission screen is configured so that the user can select whether to permit the execution of the download of the update data. In the following description, the operation of the user who selects to permit the execution of the download is described as a permission operation. Also, the operation of the user who selects not to permit the execution of the download is described as a rejection operation. When the user performs a permission operation on the HMI 16 that has displayed the permission screen, the HMI 16 notifies the OTA master 11 that the user has permitted the download. The OTA master 11 starts downloading the update data in response to this notification.

[0023] Figure 4 shows an example of the configuration of the license screen. In the example screen configurations in Figures 4 and 5, software updates and update data are referred to as "system updates." The license screen in Figure 4 displays a message indicating that a download is available, as well as the type and version of the software to be updated. The license screen also displays a button to select whether or not to authorize the start of the download. The license screen may also be configured to allow transitions to a screen that displays detailed information about the software to be updated.

[0024] If the user declines the download on the permission screen, the download of the update data will be temporarily suspended. In this case, OTA Master 11 will prompt the user for permission again when the conditions for downloading are met again. If the user declines, the user may be allowed to manually set the date and time to start the download.

[0025] Once the download is complete and installation is ready, the OTA master 11 determines whether user permission is required for installation based on the type of update data. If the OTA master 11 determines that user permission is not required, it automatically starts installing the update software on the target device. On the other hand, if it determines that user permission is required, the OTA master 11 requests user permission in the same way as in the case of a download. The OTA master 11 then waits for user permission to be obtained before starting the installation. Specifically, the OTA master 11 instructs the target device to start the installation. The OTA master 11 then confirms that the installation is complete upon receiving a completion notification from the target device.

[0026] Subsequently, when the update software becomes ready for activation, the OTA master 11 determines whether user permission is required for activation based on the type of update data. If the OTA master 11 determines that user permission is not required, it automatically starts the activation. On the other hand, if it determines that user permission is required, the OTA master 11 requests user permission in the same way as for downloads and installations. The OTA master 11 then waits for user permission to be obtained before starting the activation. Specifically, the OTA master 11 instructs the target device to start the activation. The OTA master 11 then confirms that the activation is complete upon receiving a completion notification from the target device.

[0027] <Effects of the Embodiment> The operation and effects of this embodiment will now be described. The OTA master 11, one of the in-vehicle devices installed in the vehicle 10, manages software updates for the vehicle 10. When updating the software, the OTA master 11 determines whether user permission is required based on the type of software to be updated. If the OTA master 11 determines that user permission is required, it asks the user whether or not to proceed with the software update process. In this embodiment, the OTA master 11 corresponds to a determination unit and a control unit.

[0028] Furthermore, the OTA master 11 performs software updates on the vehicle 10 through three phases: downloading the update data, installing the update program on the target device, and activating the update program. The OTA master 11 individually determines whether user permission is required at each of these three phases.

[0029] Depending on the type of software, user permission may be required for all three phases described above, or it may not be required. In the above embodiment, if user permission is not required, the update process proceeds automatically without contacting the user. Therefore, the in-vehicle device in the above embodiment has the effect of reducing the frequency of contacting the user during software updates.

[0030] <Regarding the setting of whether user permission is required depending on the type of software> As described above, in this embodiment, the requirement for user permission in each phase of software updates was varied depending on the type of software. The type of software for which the requirement for user permission differs should be determined by considering factors such as the software's functionality, the urgency of the update, and the time required for the update work.

[0031] Some software updates have deadlines for completion. For example, software updates to comply with legal revisions must be completed before the regulations come into effect. In addition, urgent software updates may be required for security reasons. It is conceivable to set whether user permission is required, taking into account the urgency of such updates. In this case, software is classified into those with high urgency and those with low urgency. OTA Master 11 determines the urgency level from the type of software to be updated. When updating high-urgency software, OTA Master 11 automatically performs the update without prompting for user permission. When updating low-urgency software, OTA Master 11 prompts for user permission and performs the update at the time desired by the user.

[0032] Depending on the software, some or all of the vehicle 10's functions may be restricted during some or all phases of the software update. For example, in the case of software for controlling the vehicle 10's driving, driving the vehicle 10 may be prohibited during activation. On the other hand, depending on the type of software and phase, the update process may proceed without any restrictions on the vehicle 10's functions. It is conceivable to set whether or not user permission is required, taking into account whether or not there are such function restrictions during the update. In this case, the software is classified into those that cause function restrictions during the update and those that do not. Then, if a function restriction occurs, the update process is performed after obtaining user permission, while if no function restriction occurs, the update process is performed automatically. Furthermore, some of the vehicle 10's functions that are restricted during the software update may be easily accepted by the user. For example, even if the entertainment functions of the HMI 16 are temporarily restricted, if the vehicle 10 can still be driven, the user may accept this. Therefore, even when a function restriction occurs, it may be possible to switch whether or not user permission is required depending on the nature of the restriction.

[0033] Software updates can take a long time or a short time. If the functionality of vehicle 10 is restricted during the update, the longer the update takes, the longer the restriction will last. It is conceivable to set whether user permission is required, taking these update times into consideration. In this case, the software is classified into those with long update times and those with short update times. Then, if the update time is long, user permission is required before the update is performed, while if it is short, the update is performed automatically.

[0034] (Other embodiments) <User settings for permission requirements> In the above embodiment, the OTA master 11 determined whether user permission was required based on a data table pre-stored in the storage device 13. Alternatively, the user may manually set whether user permission is required for each phase of each type of software.

[0035] Figure 5 shows an example of the configuration of the settings screen displayed on the HMI16 for these manual settings. This example of the settings screen is configured so that the user can manually switch whether or not user permission is required for each phase for each type of software.

[0036] Furthermore, the types of software that require user permission and those that do not may be learned based on the user's selection results, for example, as follows. Immediately after the start of learning, when the OTA master 11 receives campaign information, it displays the following selection screen on the HMI 16. The selection screen displays the update details and buttons for the user to select whether user permission is required for each phase. The OTA master 11 determines whether user permission is required for each phase of the current software update according to the user's selection results on the selection screen. The OTA master 11 also stores the user's selection results on the selection screen along with the corresponding software type. In this way, the OTA master 11 learns the selection results regarding the requirement of user permission for each type of software. Once the learning is complete after several software updates, the OTA master 11 omits the display of the selection screen and determines whether user permission is required based on the learning results.

[0037] Furthermore, the above embodiment can be implemented with the following modifications. This embodiment and the following modifications can be combined with each other to the extent that they do not contradict each other technically. In the above embodiment, the OTA master 11 individually determined whether user permission was required in each phase of download, installation, and activation. The determination of whether permission is required for each phase may be performed collectively. That is, after receiving campaign information, the OTA master 11 determines whether user permission is required for each phase and records the determination result. Then, in each phase, the OTA master 11 determines whether user permission is required based on the recorded determination result.

[0038] The OTA master 11 in the above embodiment determined whether user permission was required for each of the following: download, install, and activate. The timing and number of times user permission is required during the software update process may be changed.

[0039] The in-vehicle device of the above embodiment may be configured to display a permission screen, as illustrated in Figure 4, on the HMI 33 of the user's mobile terminal 30, and for the user to perform a permission operation on the HMI 33.

[0040] The user permission determination and / or user permission inquiry performed by the OTA master 11 in the above embodiment may be performed by another in-vehicle device. For example, the device targeted for software updates may perform at least one of the above determination and inquiry. In that case, the in-vehicle device that performs the determination corresponds to the determination unit, and the in-vehicle device that performs the inquiry corresponds to the control unit. The in-vehicle device in the above embodiment may be composed of multiple in-vehicle devices, such that the determination unit and the control unit each correspond to different in-vehicle devices. [Explanation of symbols]

[0041] 10 vehicles 11 OTA Master 12 Processing Circuit 13 Storage device 14. In-vehicle network connection 15 ECU 16 HMI 17 Wireless communication module 18 Mobile communications network 20 OTA servers 21 Processing Circuit 22 Storage device 30 Mobile devices 31 Processing Circuit 32 Storage device 33 HMI

Claims

1. An in-vehicle device installed in a vehicle that manages software updates for that vehicle, A determination unit that determines whether user permission is required based on the type of software, If the determination unit determines that user permission is required, the control unit will ask the user whether or not to perform the process for updating the software, An in-vehicle device equipped with the following features.

2. The aforementioned software update is performed through three phases: downloading the update data, installing the update program on the in-vehicle equipment to be updated, and activating the update program. The in-vehicle device according to claim 1, wherein the determination unit individually determines whether user permission is required for the implementation of each of the three phases.

3. The in-vehicle device according to claim 1, configured so that the user can select the type of software that the determination unit determines requires user permission, and the type of software that the determination unit determines does not require user permission.

4. The in-vehicle device according to claim 1, wherein the control unit performs the query through a human-machine interface mounted on the vehicle.

5. The in-vehicle device according to claim 1, wherein the control unit performs the inquiry via the user's mobile terminal.

Images