Vehicle software update system and HMI device

The vehicle software update system addresses user inconvenience by allowing permission periods for updates, reducing the need for repeated consent and ensuring updates occur only when desired.

JP2026092074APending Publication Date: 2026-06-04TOYOTA JIDOSHA KK

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
TOYOTA JIDOSHA KK
Filing Date
2026-03-30
Publication Date
2026-06-04

AI Technical Summary

Technical Problem

Users feel inconvenienced by the need to repeatedly grant permission for software updates in vehicles, and may also face disruptions during updates without their consent.

Method used

A vehicle software update system that allows setting a permission period for updates based on user input, enabling automatic execution within that period without further consent, or executing updates only when consent is given outside the set period.

Benefits of technology

Reduces user burden for consent processes and prevents unnecessary updates by allowing scheduled software updates.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026092074000001_ABST
    Figure 2026092074000001_ABST
Patent Text Reader

Abstract

When updating software, the aim is to reduce the burden on users regarding the approval process for updates and to prevent updates from being performed unnecessarily. [Solution] The OTA master 10 is capable of performing update processing for the update software of the specific control device 90 and setting an permission period for the update processing based on external input. If no permission period is set, the update processing is executed on the condition that an permission signal indicating permission for the update processing is obtained. If an permission period is set, the update processing is executed within the permission period without the condition that an permission signal is obtained.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to an information processing device for a vehicle, a software update system for a vehicle, and a program for a vehicle.

Background Art

[0002] The vehicle disclosed in Patent Document 1 includes an electronic control device and an information processing device that manages software updates in the electronic control device. The information processing device performs an update process for updating the software of the electronic control device to update software. This update process includes the information processing device downloading the update software from a server, installing the update software in the electronic control device, and activating the installed update software. Prior to performing such an update process, the information processing device obtains prior permission from the user of the vehicle.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] As in Patent Document 1, when obtaining the permission of each user for updating to update software, the user may feel troublesome because they are forced to handle it each time. On the other hand, if the update to the update software is performed without obtaining the permission of the user, the user cannot use the functions using the update software during the update process, so there is a risk of imposing inconvenience on the user. Therefore, depending on the situation, the user may also want to control the timing of performing the update themselves.

Means for Solving the Problems

[0005] The vehicle information processing device for solving the above problems is capable of performing an update process to update software on an electronic control unit installed in the vehicle, and setting an permission period for the update process based on an external input. If no permission period is set, the update process is executed on the condition that a permission signal indicating permission for the update process is obtained. If a permission period is set, the update process is executed within the permission period, regardless of whether the permission signal is obtained.

[0006] A vehicle software update system for solving the above problems comprises an electronic control unit mounted in the vehicle, an information processing unit for managing software updates of the electronic control unit, and an input device for receiving input from a user. The information processing unit is capable of performing an update process for the electronic control unit's update software and setting an authorization period for the update process based on input through the input device. If no authorization period is set, the system executes the update process on the condition that it has received an authorization signal from the input device indicating authorization for the update process. If an authorization period is set, the system executes the update process within the authorization period, regardless of whether it has received the authorization signal.

[0007] A vehicle program for solving the above problems is applied to a vehicle equipped with an electronic control unit and an information processing unit for managing the software of the electronic control unit, and causes the information processing unit to perform the following actions based on external input: set an authorization period for updating the software of the electronic control unit; execute the update process if the authorization period is not set, on the condition that an authorization signal indicating authorization for the update process is obtained; and execute the update process within the authorization period if the authorization period is set, without the condition that an authorization signal is obtained. [Effects of the Invention]

[0008] Each of the above technical concepts reduces the burden on users regarding the consent process for software updates and prevents unnecessary updates. [Brief explanation of the drawing]

[0009] [Figure 1] This is a schematic diagram of the vehicle's configuration. [Figure 2] This is a flowchart illustrating the processing steps for the configuration process. [Figure 3] This is a diagram illustrating an example of a setting image. [Figure 4] This is a flowchart illustrating the processing steps for the first process. [Figure 5] This is a flowchart illustrating the processing steps for the second process. [Figure 6] This flowchart shows an example of a change in the first process. [Figure 7] This flowchart illustrates an example of a change in the second process. [Figure 8] This flowchart shows an example of a change in the first process. [Figure 9] This flowchart illustrates an example of a change in the second process. [Modes for carrying out the invention]

[0010] Hereinafter, an embodiment of a vehicle software update system, including a vehicle information processing device, will be described with reference to the drawings. In this embodiment, the vehicle software update system is applied to an electric vehicle as an example.

[0011] <Overall vehicle configuration> As shown in Figure 1, the vehicle 100 is equipped with an OTA master 10. The OTA master 10 is equipped with a processing circuit 12. The processing circuit 12 is equipped with a CPU 20, a first memory 21, a second memory 22, and a third memory 23. The first memory 21 is a non-volatile storage medium. The first memory 21 is electrically rewritable. The first memory 21 functions as storage for data received from an external source, for example. The second memory 22 is a non-volatile storage medium. The second memory 22 is electrically rewritable. The second memory 22 stores software. The software consists of various programs W that describe the processing that the CPU 20 should execute, and a group of various data necessary for the CPU 20 to execute programs W. The third memory 23 is a volatile storage medium. The OTA master 10 is equipped with a communication module 14. The communication module 14 is a communication circuit for wireless communication with the outside via an external communication network. The OTA master 10 is equipped with a real-time clock 16. The real-time clock 16 is a circuit that generates date and time information. The OTA master 10 is an information processing device installed in the vehicle 100. The OTA master 10 is also an electronic control device installed in the vehicle 100.

[0012] Vehicle 100 includes a plurality of specific control devices 90 and a plurality of in-vehicle devices. In FIG. 1, four of the plurality of specific control devices 90 are shown as representatives. One of the plurality of in-vehicle devices is a motor device 51 that serves as a drive source of the vehicle 100. The motor device 51 includes a motor generator and an inverter that performs DC-AC power conversion. One of the plurality of in-vehicle devices is a hydraulic brake device 52. One of the plurality of in-vehicle devices is an electric parking brake device 53. In addition, examples of in-vehicle devices include an air conditioner device, a wiper device, and a plurality of HMI devices 70. The HMI device 70 is a device for exchanging information with the user using, for example, light or sound. Each specific control device 90 is an electronic control device that controls a specific one of the plurality of in-vehicle devices. Therefore, an example of the above specific control device 90 is a motor ECU. An individual identification value is assigned in advance to each specific control device 90. Each specific control device 90 can communicate with the OTA master 10 via a bus 95. Hereinafter, the specific control device 90 that controls the motor device 51, the specific control device 90 that controls the hydraulic brake device 52, and the specific control device 90 that controls the parking brake device 53 are collectively referred to as the specific control devices 90 of the running system.

[0013] Each specific control device 90 includes a processing circuit similar to that of the OTA master 10. That is, the specific control device 90 includes a CPU, a non-volatile first memory, a non-volatile second memory, and a volatile third memory. The second memory stores software F for controlling the target in-vehicle device. Note that the non-volatile memory employed in this embodiment, including the OTA master 10, has a double-bank structure. In this type of double-bank structured memory, there are two storage areas. And when reading data from one storage area, writing can be performed to the other storage area.

[0014] <HMI device> One of the plurality of HMI devices 70 is a display 71. One of the plurality of HMI devices 70 is a voice recognition device 72. One of the plurality of HMI devices 70 is a speaker 73. One of the plurality of HMI devices 70 is a push switch 74. The push switch 74 is for performing operations such as playing, stopping music and videos, and adjusting the volume. Note that the above HMI devices 70 are just examples, and there are other HMI devices 70. The display 71, the voice recognition device 72, the speaker 73, and the push switch 74 are located in the passenger compartment of the vehicle 100. In this embodiment, the display 71, the voice recognition device 72, the speaker 73, and the push switch 74 are controlled by an HMI control device, which is the same specific control device 90.

[0015] The display 71 includes a display screen and a drive circuit. The display 71 displays an image corresponding to a command signal transmitted by the HMI control device on the display screen. The display 71 is a touch panel type. That is, when the user performs an input operation on the display screen of the display 71, the display 71 transmits a signal corresponding to the input operation to the HMI control device. Note that the HMI control device may transmit a command signal to the display 71 under the command transmitted from the OTA master 10. Also, the HMI control device transmits a signal from the display 71 to the OTA master 10 as necessary. The display 71 is an input device that receives input from the user. Note that the display 71 in this embodiment is a center display located between the driver's seat and the passenger seat.

[0016] The voice recognition device 72 includes a microphone and a conversion circuit. The microphone collects sounds in the passenger compartment. The conversion circuit converts the sounds collected by the microphone into language data. Then, the conversion circuit outputs the converted language data to the HMI control device. The HMI control device transmits the language data received from the voice recognition device 72 to the OTA master 10 as necessary. The voice recognition device 72 is an input device that receives input from the user.

[0017] The speaker 73 emits a sound according to a command signal transmitted by the HMI control device. Note that the HMI control device may transmit a command signal to the speaker 73 under the command transmitted from the OTA master 10.

[0018] Here, as described above, the HMI control device may send a command signal to the display 71 under the command from the OTA master 10. Regarding this point, hereinafter, the description of the point that the HMI control device is interposed between the OTA master 10 and the display 71 will be omitted. For example, it may be described that the OTA master 10 transmits a command signal to the display 71, or it may be described that the OTA master 10 causes the display 71 to display an image. Similarly, hereinafter, regarding the case where a signal from the display 71 is transmitted from the HMI control device to the OTA master 10, the description of the point that the HMI control device is interposed in the middle will be omitted. The same applies to the voice recognition device 72 and the speaker 73.

[0019] <Other configurations> The vehicle 100 includes a first battery 61. The first battery 61 is a high-voltage battery for the running of the vehicle 100. The first battery 61 is a secondary battery that exchanges power with the motor device 51.

[0020] The vehicle 100 includes a connector 68. The connector 68 is connected to the first battery 61 via a power line. An external power supply 300 of the vehicle 100 can be connected to the connector 68. The first battery 61 can also be charged by the supplied power from the external power supply 300 via the connector 68. Hereinafter, charging the first battery 61 using the external power supply 300 will simply be referred to as charging the first battery 61.

[0021] Vehicle 100 is equipped with a second battery 62. The second battery 62 is a low-voltage battery with a lower rated voltage than the first battery 61. The second battery 62 is a secondary battery. The second battery 62 is connected to the first battery 61 via a step-down converter (not shown). The second battery 62 supplies power to, for example, the OTA master 10, each specific control device 90, and various auxiliary equipment. The auxiliary equipment here includes the HMI device 70, switches, sensors, etc.

[0022] Vehicle 100 is equipped with a battery sensor 81, a charging sensor 82, and a vehicle speed sensor 83. The battery sensor 81 detects battery information such as the temperature, voltage, and current of the first battery 61. The charging sensor 82 detects the charging current. The charging current is the current flowing through the power line connecting the first battery 61 and the connector 68. The vehicle speed sensor 83 detects the driving speed of vehicle 100.

[0023] Vehicle 100 is equipped with a start switch 80. The start switch 80 is sometimes referred to as a system start switch. The start switch 80 is a switch used by the user to instruct the vehicle 100 to start. The system of vehicle 100 is turned on or off by the user turning the start switch 80 on or off. The state in which the system of vehicle 100 is on includes the state in which vehicle 100 is drivable and the so-called accessory-on state. The state in which vehicle 100 is drivable is when the first battery 61 is supplying power to the motor unit 51 and the second battery 62 is supplying power to each specific control device 90. Each specific control device 90 is in an activated state when power is supplied. The accessory-on state is when the first battery 61 is not supplying power to the motor unit 51, while the second battery 62 is supplying power to each specific control device 90. In other words, the accessory-on state is when vehicle 100 is not drivable, but some onboard equipment is usable. For example, when the brake pedal of vehicle 100 is depressed and the start switch 80 is turned ON, vehicle 100 becomes ready to drive. On the other hand, when the brake pedal of vehicle 100 is not depressed and the start switch 80 is turned ON, vehicle 100 enters an accessory ON state. When the system of vehicle 100 is OFF, the first battery 61 is not supplying power to the motor unit 51, and the second battery 62 is not supplying power to each specific control device 90. Here, the OTA master 10 continues to operate by receiving power from the second battery 62, regardless of whether the system of vehicle 100 is ON or OFF. The same applies to the battery sensor 81 and the charge sensor 82. In addition, each specific control device 90 can temporarily enter an ON state by receiving power from the second battery 62 as needed, even when the system of vehicle 100 is OFF. The same applies to the display 71. The OTA master 10 receives a signal indicating the state of vehicle 100 in response to the ON / OFF operation of the start switch 80.In this way, the OTA master 10 can grasp whether the system of the vehicle 100 is on or off, and further whether the vehicle 100 is in a drivable state or an accessory on state.

[0024] The plurality of in-vehicle products including the OTA master 10, each specific control device 90, each HMI device 70, each sensor, the start switch 80, and each battery described above constitute a software update system for the vehicle.

[0025] <OTA Server> The OTA server 500 is a management server provided outside the vehicle 100. The OTA server 500 manages software information for a plurality of pre-registered vehicles. The OTA server 500 stores the latest update software applicable to each vehicle according to classifications such as vehicle type and model, for example. When new update software is registered, the OTA server 500 conducts a campaign for the update software. That is, the OTA server 500 distributes new update software to the applicable vehicles upon request from the vehicles.

[0026] <Overview of the Functions of the OTA Master> The CPU 20 of the OTA master 10 performs the following by executing the program W stored in the second memory 22. That is, the CPU 20 realizes various processes for managing software updates in each specific control device 90. The following describes these various processes.

[0027] The CPU 20 can execute three types of update processes. An update process is a process for updating the software in a specific control unit 90 to update software. One of the three types of update processes is the download process. The download process is a process that receives the update software from the OTA server 500 using wireless communication and stores the received update software in the first memory 21. Another of the three types of update processes is the installation process. The installation process is a process that stores the update software obtained in the download process in the second memory of the target specific control unit 90. Another of the three types of update processes is the activation process. The activation process is a process that activates the update software stored in the specific control unit 90 by the installation process. Activation involves changing the settings of the specific control unit 90 so that it can perform processing by referring to the update software. For example, in the activation process, the CPU 20 changes the setting of the read flag in the specific control unit 90. The read flag is a flag that specifies the memory area to which the specific control unit 90 will target when reading software. By changing the read flag setting, the specific control device 90 switches the memory area from which to load the software to the memory area that stores the updated software. The technology of updating software using wireless communication is sometimes referred to as OTA (Over The Air).

[0028] In the following, when the download, installation, and activation processes are described collectively, they will be referred to as the update process, and when each of these processes is described individually, the name of the individual process will be listed.

[0029] The CPU 20 is capable of performing configuration processing. In the configuration processing, the CPU 20 sets the permission period for update processing based on input from the user through the display 71. User permission is required to perform the update to the update software. The above permission period is the period during which the user has previously permitted the following: to perform the update processing. Therefore, within this permission period, the CPU 20 is permitted to perform the update processing without obtaining the user's permission at that time. In the configuration processing, the CPU 20 stores the permission period instructed by the user in the first memory 21, or erases the previously stored permission period from the first memory 21, in response to input from the user. The CPU 20 turns on the permission flag when the user instructs it to set a permission period. On the other hand, the CPU 20 turns off the permission flag when the user instructs it not to set a permission period.

[0030] The CPU 20 is capable of executing two types of execution processes for performing update processing. One of these execution processes, the first process, is basically a process performed exclusively when the vehicle 100's system is off. However, a part of the first process extends to the period when the vehicle 100's system is on. The other execution process, the second process, is basically a process performed exclusively when the vehicle 100's system is on. However, a part of the second process extends to the period when the vehicle 100's system is off.

[0031] The execution process has the following characteristics. In the execution process, if no permission period is set, the CPU 20 executes the update process on the condition that it has received a permission signal from the display 71 or the voice recognition device 72. The permission signal is a signal indicating permission to execute the update process. On the other hand, if a permission period is set, the CPU 20 executes the update process within the permission period, without requiring the acquisition of a permission signal. Based on these two points, the CPU 20 also executes the update process in the following cases. For example, if the vehicle 100's speed is greater than zero, that is, while the vehicle 100 is running, the CPU 20 executes the update process on the condition that it has received a permission signal, regardless of whether a permission period is set or not. Also, with respect to the specific control device 90 of the driving system, the CPU 20 executes the update process on the condition that it has received a permission signal, regardless of whether a permission period is set or not. On the other hand, if the first battery 61 is charging, the CPU 20 executes the update process without requiring the acquisition of a permission signal, regardless of whether a permission period is set or not. More precisely, whether or not an authorization signal needs to be obtained depends on the combination of the type of specific control device 90 and the charge status of the first battery 61. This will be explained in detail later using a flowchart. The type of specific control device 90 refers to the classification of the specific control device 90 according to the in-vehicle device that the specific control device 90 controls, such as the above-mentioned driving system. In the following description, the OTA master 10 receiving an authorization signal from the display 71 or the voice recognition device 72 is equivalent to the OTA master 10 obtaining an authorization signal from them.

[0032] The CPU 20 repeatedly calculates the charge rate of the first battery 61, assuming it will perform the first and second processes. The charge rate of the first battery 61 is the ratio of the remaining capacity to the full charge capacity of the first battery 61. The CPU 20 can calculate the charge rate of the first battery 61 based on the battery information detected by the battery sensor 81.

[0033] <Configuration Process> The specific details of the configuration process will now be explained. The CPU 20 starts the configuration process when the vehicle 100's system is turned on and the user operates the display 71 to call up the software update configuration function.

[0034] As shown in Figure 2, when the CPU 20 starts the setting process, it first executes the process in step S10. In step S10, the CPU 20 provides guidance for setting the permission period. Specifically, the CPU 20 sends a command signal to the display 71 to display the setting image U shown in Figure 3. In response to this command signal, the display 71 displays the setting image U. The setting image U contains the following multiple display contents. The first display content is a message U1 prompting the user to enter the permission period. The second display content is an input field U2 for the user to enter the start time of the permission period. Next to this input field U2, there is a notation indicating that the input field U2 is for the start time. A detailed explanation will be omitted below, but all input fields and buttons present in the setting image U can accept user operations. The user can specify the start time of the permission period by operating the input field U2. In this embodiment, it is possible to specify each time from "1 o'clock" to "24 o'clock", which divides the day into 24 hour units. The third display element is an end input field U3 for the user to enter the end time of the permitted period. Next to this input field U3 is a notation indicating that this input field U3 is for the end time. By interacting with this input field U3, the user can specify the end time of the permitted period. The user can specify the end time in hours, just like the start time. The fourth display element is a date input field U4 for the user to enter the date of the permitted period. Next to this input field U4 is a notation indicating that this input field U4 is for the date. By interacting with this input field U4, the user can specify the date of the permitted period. In this embodiment, one of the following three options can be selected: "Every day", "A specific day of the week", or "A specific date". The fifth display element is a confirmation button U5. The confirmation button U5 is a button for the user to confirm the settings related to the permitted period. The sixth display element is a non-setting button U6. The non-setting button U6 is a button for the user to indicate that they do not want to set a permitted period. The seventh displayed item is the Exit button U7. The Exit button U7 is a button used by the user to signal the end of the display of the setting image U.Although not shown in the diagram, the setting image U also includes the following display content. The display content is a message that states that even if a permission period is set, depending on the type of specific control device 90 to be updated and the state of the vehicle 100, the user's permission will be requested before the software update can be performed. As shown in Figure 2, in step S10, the CPU 20 displays the setting image U on the display 71 and then proceeds to step S20.

[0035] In step S20, the CPU 20 determines whether or not input regarding the permission period has been received for the setting image U. The CPU 20 determines that input regarding the permission period has been received if the OK button U5 or the non-setting button U6 is operated before a predetermined time has elapsed since the process proceeded to step S20 (step S20: YES). In this case, the CPU 20 proceeds to step S30. The CPU 20 proceeds to step S30 as soon as the OK button U5 or the non-setting button U6 is operated. The predetermined time is predetermined as a specific time, for example, within 1 minute. The predetermined time is, for example, 30 seconds.

[0036] In step S30, the CPU 20 stores the user-specified permission period settings in the first memory 21. Specifically, the CPU 20 performs the following processing: First, the CPU 20 resets the permission period information currently stored in the first memory 21. That is, if the permission flag is currently on, the CPU 20 switches the permission flag to off and erases the permission period stored in the first memory 21. On the other hand, if the permission flag is currently off, the CPU 20 does nothing. Next, the CPU 20 reflects the input content for the setting image U into the contents stored in the first memory 21. Specifically, if the OK button U5 is operated, the CPU 20 turns on the permission flag. At the same time, the CPU 20 stores information about the start time, end time, and date of the permission period entered in the setting image U in the first memory 21. On the other hand, if the non-setting button U6 is operated, the CPU 20 leaves the permission flag off. Once the CPU 20 has reflected the user's input into the first memory 21, it stops displaying the setting image U on the display 71. At the same time, the CPU 20 terminates the process of step S30. Then the CPU 20 terminates the setting process.

[0037] On the other hand, in step S20, the CPU 20 determines that there was no input regarding the permission period in either of the following cases: The first case is when neither the confirm button U5 nor the non-set button U6 is operated before the predetermined time elapses after the process proceeds to step S20. The second case is when the exit button U7 is operated before the predetermined time elapses after the process proceeds to step S20. In either of these cases (step S20: NO), the CPU 20 terminates the display of the setting image U on the display 71. The CPU 20 then terminates the setting process. In the first case, the CPU 20 terminates the setting process when the predetermined time has elapsed. In the second case, the CPU 20 terminates the setting process when the exit button U7 is operated. If the determination in step S20 is NO, the first memory 21 will continue to retain the existing information regarding the permission period that it has stored at that time.

[0038] <First Processing> The CPU 20 starts the first process at predetermined execution times, provided the vehicle 100's system is off. These execution times are the hours from "1 o'clock" to "24 o'clock," dividing the day into 24 hourly segments. In other words, assuming the vehicle 100's system is off, the CPU 20 starts the first process every hour, for example, at "1 o'clock" or "2 o'clock."

[0039] As shown in Figure 4, when the CPU 20 starts the first process, it first executes the process in step S110. In step S110, the CPU 20 determines whether or not there is new update software applicable to the vehicle 100. Specifically, the CPU 20 first uses wireless communication to send a request to the OTA server 500 to check for the existence of new update software. If the CPU 20 receives a notification from the OTA server 500 in response to this request that there is no new update software (step S110: NO), the CPU 20 terminates the first process. On the other hand, if the CPU 20 receives a notification from the OTA server 500 that there is new update software (step S110: YES), the process proceeds to step S120. When the CPU 20 receives a notification from the OTA server 500 that there is new update software, it also receives software information along with the notification. The software information includes the identification value of the specific control device 90 to be updated, and information on the data capacity of the update software. The CPU 20 stores this software information in the first memory 21. In this embodiment, the OTA server 500 distributes update software targeting one specific control device 90 in a particular campaign. In other words, only one specific control device 90 is targeted for update in one first process or one second process.

[0040] In step S120, the CPU 20 determines whether the specific control device 90 to be updated is a specific control device 90 other than the one used in the drive system. The CPU 20 makes this determination by referring to the control device list stored in the second memory 22 and the software information received from the OTA server 500 in step S110. The control device list is a list that associates the identification value of each specific control device 90 with the in-vehicle device that each specific control device 90 controls. If the specific control device 90 to be updated is a drive system device (step S120: NO), the CPU 20 proceeds to step S160.

[0041] In step S160, the CPU 20 provides confirmation notification via display. Specifically, the CPU 20 first waits until the vehicle 100 system switches from off to on. Once the vehicle 100 system switches on, the CPU 20 sends a command signal to the display 71 to display the permission image. The display 71 then displays the permission image. The permission image includes a message asking the user whether to allow the update process to be executed, an accept button, and a reject button. The accept button is for the user to authorize the execution of the update process. The reject button is for the user to reject the execution of the update process. The accept and reject buttons can accept input from the user. The display 71 is configured to function as follows in response to the user's operation on the permission image. That is, if the user operates the accept button, the display 71 sends a first permission signal to the OTA master 10 indicating permission to execute the update process. If the user presses the reject button, the display 71 sends a first rejection signal to the OTA master 10 indicating that the update process is to be refused. The first approval signal and the first rejection signal are predetermined to be different signals from each other. When the CPU 20 displays the approval image on the display 71, it proceeds to step S170.

[0042] In step S170, the CPU 20 determines whether the user has authorized the update process. Specifically, in step S170, if the CPU 20 receives a first authorization signal before a predetermined first waiting time has elapsed from the time the process proceeds to step S170, it determines that the user has authorized the update process (step S170: YES). In this case, the CPU 20 proceeds to step S140 when it receives the first authorization signal. The details of the process in step S140 will be described later. The first waiting time is, for example, the same as the predetermined time mentioned above, for example, 30 seconds.

[0043] On the other hand, in step S170, if the CPU 20 does not receive the first permission signal before the first waiting time elapses after the process has proceeded to step S170, it determines that the user has not permitted the execution of the update process (step S170: NO). In this case, the CPU 20 terminates the first process. The determination in step S170 is NO in one of the following cases: The first case is when neither the first permission signal nor the first rejection signal is received before the first waiting time elapses after the process has proceeded to step S170. The second case is when the first rejection signal is received before the first waiting time elapses after the process has proceeded to step S170. In the first case, the CPU 20 terminates the first process when the first waiting time elapses. In the second case, the CPU 20 terminates the first process when the first rejection signal is received. Note that if the first process is terminated via step S170, the system of the vehicle 100 is turned on. Therefore, in this case, the CPU 20 will not execute the first process until the vehicle 100's system is turned off again.

[0044] Now, in step S120, if the specific control device 90 to be updated is not part of the drive system (step S120: YES), the CPU 20 proceeds to step S130.

[0045] In step S130, the CPU 20 determines whether the charging conditions are met. The charging conditions are that both of the following two requirements are met. The first requirement is that the first battery 61 is being charged. The second requirement is that the current charge rate of the first battery 61 is less than or equal to the first charge rate. The first charge rate is predetermined as a value that requires a relatively long time, such as one hour, to charge the first battery 61 from that first charge rate to the maximum charge rate. Therefore, if the second requirement is met, it is expected that charging of the first battery 61 will continue for a relatively long time thereafter. The CPU 20 determines whether the first requirement is met as follows: The CPU 20 refers to the latest charging current detected by the charging sensor 82. The CPU 20 then determines that the first requirement is met if the charging current is greater than zero. On the other hand, the CPU 20 determines that the first requirement is not met if the charging current is zero. The CPU 20 determines whether the second requirement is met in the following way: The CPU 20 refers to the latest charge rate of the first battery 61 calculated from the battery information. The CPU 20 determines that the second requirement is met if the latest charge rate is less than or equal to the first charge rate. On the other hand, the CPU 20 determines that the second requirement is not met if the latest charge rate is greater than the first charge rate. If, as a result of these determinations, the charging condition is met (step S130: YES), the CPU 20 skips step S150, which will be explained later, and proceeds to step S140. On the other hand, if the charging condition is not met (step S130: NO), the CPU 20 proceeds to step S150.

[0046] In step S150, the CPU 20 determines whether or not an authorization period is set. At this time, the CPU 20 refers to the authorization flag stored in the first memory 21. If no authorization period is set (step S150: NO), the CPU 20 proceeds to step S160, which has already been described. On the other hand, if an authorization period is set (step S150: YES), the CPU 20 proceeds to step S155.

[0047] In step S155, the CPU 20 determines whether the current date and time are within the permitted period by referring to the information on the permitted period stored in the first memory 21. If the current date and time are outside the permitted period (step S155: NO), the CPU 20 repeats the process in step S155. That is, the CPU 20 waits for the current date and time to fall within the permitted period by repeating the determination in step S155. On the other hand, if the current date and time are within the permitted period (step S155: YES), the CPU 20 proceeds to step S140. If the system of the vehicle 100 switches from off to on while the determination in step S155 is being repeated, the CPU 20 terminates the first process at that point.

[0048] In step S140, the CPU 20 executes the update process for the update software of the specific control device 90 to be updated. First, the CPU 20 performs a download process. Specifically, the CPU 20 requests the OTA server 500 to send the update software. Upon receiving the update software from the OTA server 500 in response to this request, the CPU 20 stores the received update software in the first memory 21. After this, the CPU 20 performs an installation process. Specifically, the CPU 20 sends the target update software and a command signal to store the update software to the specific control device 90 to be updated. In response to this command signal, the specific control device 90 to be updated stores the update software in its second memory. After completing the installation process, the CPU 20 performs an activation process. Specifically, in the activation process, the CPU 20 sends a command signal to the specific control device 90 to be updated to activate the update software stored during the installation process. In response to this command signal, the specific control device 90 to be updated performs the process of activating the update software. The details of the activation are as already explained. After completing the activation process, the CPU 20 erases the software information stored in the first memory 21. Then, the CPU 20 terminates the process of step S140. At the same time, the CPU 20 terminates the first process. Note that the same process of erasing software information after completing the activation process also applies to the second process, which will be described later.

[0049] Here, regarding the processing in step S140, if the process proceeds from step S170 to step S140, the system of vehicle 100 is ON at that point. In this case, the CPU 20 performs the download process and the installation process while the system of vehicle 100 is ON. After that, the CPU 20 waits until the system of vehicle 100 switches from ON to OFF. Then, when the system of vehicle 100 switches to OFF, the CPU 20 performs the activation process. The series of processes until the activation process is completed is the processing in step S140. On the other hand, regarding the processing in step S140, if the process proceeds from step S130 to step S140, or from step S155 to step S140, the system of vehicle 100 is OFF at that point. In this case, the CPU 20 completes the download process, the installation process, and the activation process while the system of vehicle 100 is OFF. If, during the execution of step S140, the user turns on the start switch 80 to switch the vehicle 100's system from off to on, the CPU 20 displays the following message on the display 71. The message indicates that a software update is in progress and the vehicle 100's system cannot be turned on. When the CPU 20 displays this message on the display 71, the switching of the vehicle 100's system from off to on is put on hold.

[0050] Regarding the first process described above, in relation to processes such as step S140 or step S160, a new execution time for the first process may be reached during the execution of the first process. In this case, the CPU 20 cancels the execution of the first process at that time. Similarly, if the CPU 20 reaches the execution time for the second process described below during the execution of the first process, it cancels the execution of the second process at that time.

[0051] <Second Processing> If the vehicle 100's system is turned on, CPU 20 will start the second process at a predetermined execution time. The execution time is the same as that described for the first process. As mentioned above, CPU 20 may cancel the execution of the second process depending on its interaction with the first process.

[0052] As shown in Figure 5, when the CPU 20 starts the second process, it first executes the process in step S210. In step S210, the CPU 20 determines whether or not new update software exists. The content of the process in step S210 is the same as the content of the process in step S110. Therefore, the details of the process in step S210 are omitted. If the CPU 20 determines that no new update software exists (step S210: NO), it terminates the second process. On the other hand, if the CPU 20 determines that new update software exists (step S210: YES), it proceeds to step S220.

[0053] In step S220, the CPU 20 determines whether the specific control device 90 to be updated is not a specific control device 90 of the drive system. The processing content of step S220 is the same as that of step S120. Therefore, the details of the processing content of step S220 are omitted. If the specific control device 90 to be updated is of the drive system (step S220: NO), the CPU 20 proceeds to step S270.

[0054] In step S270, the CPU 20 provides an audio confirmation notification. Specifically, the CPU 20 sends a command signal to the speaker 73 to output an audio message inquiring about whether an update is possible. The speaker 73 then provides an audio message regarding the inquiry about whether an update is possible. The audio message includes the fact that there is software to be updated and asks whether the user approves or rejects the update process. After providing the audio message, the CPU 20 proceeds to step S280.

[0055] In step S280, the CPU 20 determines whether the user has authorized the update process. Here, the voice recognition device 72 is configured as follows: If the voice recognition device 72 hears the user's voice indicating that they have authorized the update process, it sends a second authorization signal to the OTA master 10 indicating authorization for the update process. On the other hand, if the voice recognition device 72 hears the user's voice indicating that they have refused the update process, it sends a second refusal signal to the OTA master 10 indicating refusal for the update process. The second authorization signal and the second refusal signal are predetermined to be different signals. In step S280, if the CPU 20 receives the second authorization signal before a predetermined second waiting time has elapsed from the time the process proceeds to step S280, it determines that the user has authorized the update process (step S280: YES). In this case, the CPU 20 proceeds to step S240 when it receives the second authorization signal. The processing details of step S240 will be described later. The second waiting time is, for example, the same as the first waiting time.

[0056] On the other hand, in step S280, if the CPU 20 does not receive the second grant signal before the second waiting time has elapsed, it determines that the user has not granted permission to execute the update process (step S280: NO). In this case, the CPU 20 terminates the second process. The determination in step S280 is NO in one of the following cases: The first case is when neither the second grant signal nor the second reject signal is received before the second waiting time has elapsed after the process has proceeded to step S280. The second case is when the second reject signal is received before the second waiting time has elapsed after the process has proceeded to step S280. In the first case, the CPU 20 terminates the second process when the second waiting time has elapsed. In the second case, the CPU 20 terminates the second process when the second reject signal is received.

[0057] Now, in step S220, if the specific control device 90 to be updated is not part of the drive system (step S220: YES), the CPU 20 proceeds to step S230. In step S230, the CPU 20 determines whether the charging conditions are met. The processing content of step S230 is basically the same as that of step S130. However, the second requirement of the charging conditions is different from that of step S130. The second requirement in step S230 is that the current charge rate of the first battery 61 is less than or equal to the second charge rate. The second charge rate is predetermined to be slightly higher than the first charge rate. The reason for setting the second charge rate higher than the first charge rate is to take into account that the activation process will not be performed in step S240, which will be described later, as part of the update process. With respect to all other requirements, the processing content of step S230 is the same as that of step S130. Therefore, further explanation of step S230 is omitted.

[0058] In step S230, if the charging condition is not met (step S230: NO), the CPU 20 proceeds to step S270. The situations in which the determination in step S230 is NO are one of the following: The first situation is when the vehicle 100's speed is greater than zero, that is, when the vehicle 100 is in motion. The second situation is when the vehicle 100's speed is zero, that is, when the vehicle 100 is stopped. Considering that the vehicle 100's system is ON at the time step S230 is executed, the second situation is as follows: That is, although the vehicle 100 is currently stopped, there is a high probability that the vehicle 100 will start moving at a relatively early stage. In either of these first or second situations, the CPU 20 proceeds to step S270, as already explained, and issues a confirmation notification. On the other hand, in step S230, if the charging condition is met (step S230: YES), the CPU 20 proceeds to step S240.

[0059] In step S240, the CPU 20 performs a download process and an installation process for the specific control device 90 to be updated. The details of these processes are the same as those described in the first process. Therefore, the explanation is omitted here. After performing the download process and the installation process, the CPU 20 proceeds to step S250.

[0060] In step S250, the CPU 20 determines whether the system of the vehicle 100 has switched from on to off. If the system of the vehicle 100 is on (step S250: YES), the CPU 20 executes the process in step S250 again. That is, the CPU 20 waits until the system of the vehicle 100 switches from on to off. When the system of the vehicle 100 switches from off to on (step S250: YES), the CPU 20 proceeds to step S260. If the CPU 20 is repeating the process in step S250 when the execution time for the next second process arrives, it cancels the execution of the next second process.

[0061] In step S260, the CPU 20 executes the activation process. The content of the activation process is the same as that described in the first process. Therefore, the explanation is omitted here. After the activation process is completed, the CPU 20 terminates the second process. Note that the execution time for the first process may be reached while step S260 is in progress. In this case, the CPU 20 cancels the execution of the first process at that time.

[0062] <Operation of the Embodiment> (A) Regarding the first process CPU20 performs update processing in each of the following cases during the first processing stage.

[0063] (A1) Assume that the update software received from the OTA server 500 is for a device other than the specific control device 90 of the running system (Step S120: YES). Assume that the first battery 61 is not charging at this time (Step S130: NO). Assume that the permission period has already been set (Step S150: YES). In this case, the CPU 20 starts the update process when the date and time falls within the permission period (Step S155: YES) (Step S140). That is, assuming that the update software is for a device other than the specific control device 90 of the running system, and if a permission period has been set, the CPU 20 executes the update process without requiring the acquisition of the first permission signal.

[0064] (A2) As in (A1) above, assume that the update software is intended for a vehicle other than the specific control device 90 of the drive system (step S120: YES), and that the first battery 61 was not being charged (step S130: NO). Assume that no permission period was set (step S150: NO). In this case, the CPU 20 performs the update process if the user authorizes the update process in response to the confirmation notice in step S160 (step S140). That is, if no permission period is set, the CPU 20 executes the update process on the condition that it has received the first permission signal.

[0065] (A3) Assume the update software is intended for a device other than the specific control device 90 of the drive system (Step S120: YES). Assume that the first battery 61 is being charged at this time (Step S130: YES). In this case, the CPU 20 starts the update process (Step S140). That is, assuming that the update software is for a device other than the specific control device 90 of the drive system, the CPU 20 executes the update process while the first battery 61 is being charged, regardless of whether a permission period is set or not, and without requiring the acquisition of the first permission signal.

[0066] (A4) Assume the update software targets a specific control device 90 of the drive system (Step S120: NO). In this case, the CPU 20 performs the update process if the user authorizes the update process in response to the confirmation notice in Step S160, regardless of whether a permission period has been set (Step S140). That is, if the specific control device 90 to be updated is of the drive system, the CPU 20 performs the update process on the condition that it has received the first authorization signal, regardless of whether a permission period has been set.

[0067] (B) Regarding the second process CPU20 performs update processing in each of the following cases through the second processing step. (B1) Assume that the update software received from the OTA server 500 is intended for a vehicle other than the specific control device 90 of the driving system (Step S220: YES). Assume that the first battery 61 was not charging at this time (Step S230: NO). As described above, the situation in which the determination in Step S230 is NO is when the vehicle 100 is in motion or when there is a high probability that the vehicle 100 will start moving. Under these circumstances, if the user authorizes the update process in response to the confirmation notice in Step S270, the CPU 20 performs the update process (Steps S240, Steps S260). Thus, when the vehicle 100 is in motion or when there is a high probability that the vehicle 100 will start moving, the CPU 20 performs the update process on the condition that it has received the second authorization signal, regardless of whether an authorization period has been set or not.

[0068] (B2) Assume that the update software is intended for a device other than the specific control device 90 of the running system (Step S220: YES). Assume that the first battery 61 is being charged at this time (Step S230: YES). In this case, the CPU 20 starts the update process in Step S240. That is, assuming that the update software is for a device other than the specific control device 90 of the running system, the CPU 20 executes the update process while the first battery 61 is being charged, regardless of whether a permission period is set or not, and without requiring the acquisition of the second permission signal.

[0069] (B3) Assume the update software targets a specific control device 90 of the drive system (step S220: NO). In this case, the CPU 20 performs the update process if the user authorizes the update process in response to the confirmation notice in step S270, regardless of whether a permission period has been set (steps S240, S260). That is, if the specific control device 90 to be updated is of the drive system, the CPU 20 performs the update process on the condition that it has received the second permission signal, regardless of whether a permission period has been set.

[0070] <Effects of the Embodiment> (1) As described in (A1) above, in the first process, if a permission period has been set in advance, the CPU 20 performs the update process within that permission period without obtaining the user's permission. This reduces the number of times the user has to give permission. Therefore, the burden on the user regarding permission for the update process can be reduced. Also, since the update process is executed within the permission period set by the user, the user can control the timing of the update process themselves. On the other hand, as described in (A2) above, in the first process, if a permission period has not been set in advance, the CPU 20 performs the update process after obtaining the user's permission. For example, in the case of (A2), if the user refuses to grant permission for the update process in response to the confirmation notice in step S160 (step S170: NO), the CPU 20 refrains from executing the update process. With this configuration, it is possible to prevent the update process from being performed unnecessarily even when the user does not wish to update the software. Overall, the configuration of this embodiment can improve the user's convenience when updating the software.

[0071] (2) Suppose the specific control device 90 of the running system is updated without the user's knowledge. In this case, the user may feel uneasy because the vehicle 100 will be controlled differently from before while it is running after the update. In this regard, as described in (A4) and (B3) above, in the first and second processes, when updating the specific control device 90 of the running system, the update process is carried out only after obtaining the user's permission. This reduces the possibility that the user will feel uneasy while driving after the update.

[0072] (3) For example, suppose that download and installation processes are performed while vehicle 100 is in motion. In this case, other controls may be affected, or processing may be performed in a mode different from normal. Therefore, when update processing is performed while vehicle 100 is in motion, the user needs to be aware that processing is being performed in a mode different from normal. Accordingly, as described in (B1) above, in the second process, CPU 20 performs update processing with the user's permission when vehicle 100 is in motion or when there is a high probability that vehicle 100 will start moving. This reduces the likelihood that the user will feel any discomfort even when update processing is performed in these situations.

[0073] (4) As described in (3) above, in the second process, permission to perform the update process may be obtained from the user while the vehicle 100 is in motion. At this time, it is necessary to ensure that the user's driving operations are not affected in relation to handling this permission. Therefore, in the second process, the CPU 20 uses voice recognition to obtain permission for the update process. With voice recognition, unlike, for example, when the user performs an input operation on the display 71, the user does not need to take their hands off the steering wheel to handle the permission. Therefore, even while the vehicle 100 is in motion, there is little risk of it interfering with the user's driving. Therefore, with the above configuration, the burden on the user when granting permission while the vehicle 100 is in motion can be minimized.

[0074] (5) While the first battery 61 is being charged using the external power supply 300, the vehicle 100 is not in operation. Therefore, it is permissible to perform the update process during this period. Accordingly, as described in (A3) and (B2) above, in the first and second processes, while the first battery 61 is being charged, the CPU 20 performs the update process without requiring the acquisition of a permission signal, provided that the specific control device 90 to be updated is not part of the driving system. This reduces the frequency with which the user has to grant permission.

[0075] <Example of changes> The above embodiment can be modified as follows. The above embodiment and the following modifications can be combined and implemented to the extent that they do not contradict each other technically.

[0076] The timing of executing the setting process is not limited to the examples of the above embodiment. For example, the CPU 20 may execute the setting process when the system of the vehicle 100 switches from off to on, or when the system of the vehicle 100 switches from on to off.

[0077] The content of the configuration process is not limited to the examples of the above embodiment. The configuration process only needs to be configured to set the permission period based on input from the user via an input device. The content of the setting image U is not limited to the examples of the above embodiment. The setting image U only needs to contain content that is appropriate for guiding or accepting the setting of the permission period.

[0078] The means of guiding and accepting the setting of the permission period are not limited to using the display 71. For example, the speaker 73 may be used to guide the setting of the permission period. The voice recognition device 72 may be used to accept the setting of the permission period.

[0079] • The permission period is not limited to hours. For example, it may be possible to set the permission period in minutes. The timing of executing the first process is not limited to the examples of the above embodiment. For example, the first process may be executed every 3 hours or every 6 hours. The timing of executing the first process may be determined as appropriate to ensure that software updates are not delayed. The same applies to the second process.

[0080] The contents of the first and second processes are not limited to the examples of the embodiments described above. The first and second processes only need to be configured to achieve the following two things together: First, if no permission period is set, the update process is executed on the condition that a permission signal has been obtained. Second, if a permission period is set, the update process is executed within the permission period without being conditional on obtaining a permission signal. If either the first or second process can achieve the above two things, the other may be omitted.

[0081] • If a permission period is set, performing the update process within that period is sufficient if the following conditions are met: that at least one of the following processes—download, install, or activate—can be performed within the permission period. More specifically, it is sufficient if at least a part of each process, such as a portion of the download process, is performed within the permission period.

[0082] In step S155 of the first process in the above embodiment, if the current date and time is outside the permitted period, step S155 does not need to be repeated. Also, in the confirmation notification in step S160, the notification may be given without waiting for the vehicle 100 system to be turned on. In this case, for example, the content of the first process can be changed as shown in Figure 6. In the first process shown in Figure 6, steps S155A and S160A are used instead of steps S155 and S160 shown in Figure 4. That is, if the permitted period is not set in step S150 (step S150: NO), the CPU 20 proceeds to step S160A. On the other hand, if the permitted period is set (step S150: YES), the CPU 20 proceeds to step S155A. Then, in step S155A, the CPU 20 determines whether the current date and time is within the permitted period. In step S155A, if the current date and time are outside the permitted period (step S155A: NO), the CPU 20 proceeds to step S160A. In step S160A, the CPU 20 sends a command signal to display the permitted image to an external device via the communication module 14. The external device to which the signal is sent is, for example, a smartphone owned by the user. After this, the CPU 20 performs the processing in step S170. The processing in step S170 is the same as in the above embodiment, but the difference is that the source of the first permission signal is an external device. That is, the external device is configured to send the first permission signal to the OTA master 10 in response to input from the user. The external device also constitutes an input device that receives input from the user. In this way, an external input device not installed in the vehicle 100 may constitute part of the software update system. In this example of modification, even if no permitted period is set, or if a permitted period is set but the current date and time are outside the permitted period, the CPU 20 performs the software update on the condition that it has obtained the permission signal. Even if no permission period is set or the current date falls outside the permission period, there may be software that needs to be updated urgently. In such cases, this example of modification is useful for updating the software.The ability to update the software even when no permission period is set or when the current date and time are outside the permission period expands the user's flexibility regarding software updates. In Figure 6, the same steps as in Figure 4 are used to indicate the same processing steps.

[0083] Regarding the modification example shown in Figure 6, the in-vehicle display 71 may be used to provide the confirmation notification for step S160A. In the second process, the presence or absence of a permission period may be considered when performing the update process. Furthermore, the update process may be performed without requiring the acquisition of a permission signal while the vehicle 100 is in motion or under circumstances where there is a high probability that the vehicle 100 will start moving. As a configuration that takes these points into consideration, for example, the second process shown in Figure 7 may be adopted. In the second process shown in Figure 7, steps S290, S291, and S292 are added to the second process shown in Figure 5 as processing when the determination in step S230 is NO. Furthermore, in the second process shown in Figure 7, the processing content of steps S240 and S260 is partially changed from that in Figure 5. That is, if the charging condition is not met in step S230 (step S230: NO), the CPU 20 proceeds to step S290. In step S290, the CPU 20 determines whether or not a predetermined precondition is met. The precondition is, for example, that the capacity of the update software is less than or equal to a predetermined capacity. The predetermined capacity is set to be appropriately small enough to allow download processing to be completed quickly. In step S290, the CPU 20 determines whether the prerequisites are met based on the software information obtained in step S210. If the prerequisites are not met (step S290: NO), the CPU 20 proceeds to step S270. In this case, the CPU 20 performs the update process in steps S270 and S280 after obtaining the user's consent at that point, similar to the embodiment described above. On the other hand, if the prerequisites are met (step S290: YES), the CPU 20 proceeds to step S291. In step S291, the CPU 20 determines whether a permission period has been set. If no permission period has been set, the CPU 20 proceeds to step S270. In this case as well, the CPU 20 performs the update process after obtaining the user's consent at that point. On the other hand, if the CPU 20 determines in step S291 that an permission period has been set (step S291: YES), it proceeds to step S292. Then, in step S292, the CPU 20 determines whether the date and time at that point is within the permission period.If the time at that moment is outside the permitted period (step S292: NO), CPU20 performs the process in step S292 again. On the other hand, if the time at that moment is within the permitted period (step S292: YES), CPU20 proceeds to step S240. Then, in step S240, CPU20 performs the download process. After this, CPU20 performs the process in step S250, and in step S260, performs the installation process and the activation process. If the system of vehicle 100 switches from on to off while the process in step S292 is being repeated, CPU20 may terminate the second process at that point. In this example of modification, if the permitted period arrives while vehicle 100 is in motion or before vehicle 100 starts moving (step S292: YES), CPU20 can perform the update process at that point without obtaining the user's permission. For example, if the update software is small and the download process can be completed quickly, then any control changes due to the download process will only be for a very short period. In this case, the user is unlikely to notice anything unusual. Therefore, it is permissible to perform the update process without the user's permission while the vehicle 100 is in motion. As explained in the above example, obtaining a permission signal is not essential when updating the software while the vehicle 100 is in motion. Note that in Figure 7, the same step numbers as in Figure 5 are used for the parts where the same process is performed as in Figure 5.

[0084] • In addition to the requirements of the above modified example, the requirement that the vehicle 100's speed is zero may be added to the prerequisites. In this case, if the determination in step S292 is NO, the CPU 20 shall terminate the second process at that point. When this configuration is adopted, assuming that the size of the update software is small, the CPU 20 will perform the download process without obtaining the user's permission at that point, only when the vehicle 100 is stopped (step S290: YES) and within the permission period. On the other hand, if the vehicle 100's speed is greater than zero, the CPU 20 will perform the download process, as in the above embodiment, regardless of whether a permission period is set or not, on the condition that the second permission signal was obtained in step S280. To determine whether the vehicle 100's speed is zero, the detection result of the vehicle speed sensor 83 may be referred to.

[0085] Regarding the second process shown in Figure 7, if the determination in step S292 is NO, the process may proceed to step S270. In other words, even if a permission period is set, the update process may be executed on the condition that the second permission signal has been received through steps S270 and S280, even if it is outside the permission period.

[0086] As explained in Figure 7, the content of the update process performed in steps S240 and S260 of the second process may be changed from that shown in Figure 5. Furthermore, the content of the processes performed in steps S240 and S260 may be changed depending on the situation. For example, if the charging conditions are met (step S230: YES), the CPU 20 performs the download process and the installation process in step S240, and the activation process in step S260. On the other hand, if the CPU 20 obtains permission from the user at that point (step S280: YES), it performs the download process in step S240, and the installation process and the activation process in step S260. Such an embodiment may be adopted.

[0087] Regarding the update process performed in step S260, the following configuration may be adopted. That is, instead of performing the update process when the system of vehicle 100 switches from on to off, the update process may be performed after a predetermined third waiting time has elapsed following the system of vehicle 100 switching from on to off. In this case, the execution of the first process can be canceled until the third waiting time has elapsed following the system of vehicle 100 switching from on to off and the update process is completed. This modified example, which includes a third waiting time, can also be applied to the activate process in the first process shown in Figure 4 when the process proceeds from step S170 to step S140.

[0088] In a particular campaign, multiple specific control devices 90 may be subject to updates. Consequently, multiple update software may be distributed simultaneously from the OTA server 500 to a particular vehicle 100. In this case, for example, in step S110 of the first process in Figure 4, the CPU 20 will receive software information for each specific control device 90 subject to update from the OTA server 500. In this case, the CPU 20 may perform the processes from S120 onward in parallel for each target specific control device 90. In this case, regarding the update process, depending on the communication status with the OTA server 500, the download process may be delayed, but this does not pose any problem in performing the series of update processes. Here, the first process is used as an example, but the same applies to the second process.

[0089] Regarding the necessity of permission depending on the type of specific control device 90, for example, if the specific control device 90 controls an in-vehicle device for exchanging information with the user inside the vehicle, such as an HMI device 70, the following approach may be adopted. That is, the update process may be performed without requiring the acquisition of a permission signal, regardless of whether a permission period is set or whether the first battery 61 is being charged. Also, even for specific control devices 90 of the driving system, depending on the content of the update, the update may be performed without requiring the acquisition of a permission signal, for example, if it is within the permission period or the first battery 61 is being charged. Furthermore, with respect to specific control devices 90 of the driving system, for example, in cases where an update is urgently needed, the update may be performed without requiring the acquisition of a permission signal, regardless of the permission period or charging status. If the specific control device 90 of the driving system is updated without the user's permission, the user can be notified afterward that an update has been performed on the specific control device 90 of the driving system. This would reduce the likelihood of the user feeling uncomfortable after the update. In other words, it is not essential to require the acquisition of a permission signal when updating the specific control device 90 of the driving system. This configuration is possible if the software information sent from the OTA server 500 to the OTA master 10 includes details of the update, such as whether it is urgent.

[0090] Depending on the type of specific control device 90 to be updated, it may be possible to perform all of the download, installation, and activation processes while the vehicle 100's system is turned on. In such cases, all of these may be performed while the vehicle 100's system is turned on.

[0091] The manner of confirmation notification in the first and second processes is not limited to the examples of the above embodiments. For example, in step S160 of the first process, confirmation notification may be given by voice guidance from speaker 73 instead of, or in addition to, confirmation notification by display 71. Similarly, in step S270 of the second process, confirmation notification may be given using display 71 instead of, or in addition to, confirmation notification by voice guidance from speaker 73.

[0092] Regarding step S270 of the second process, a confirmation notification for step S270 may be issued on the condition that the vehicle 100 is stationary. The manner in which user permission is received in response to the confirmation notice is not limited to the examples of the above embodiments. For example, if a confirmation notice is made using the display 71 in step S270 of the second process, as in the modified example above, then in step S280, a first permission signal from the display 71 may be received. In step S280, both the first permission signal from the display 71 and the second permission signal from the voice recognition device 72 may be received. Furthermore, permission signals may be received using something other than the display 71 and the voice recognition device 72. For example, a push switch 74 may be used as an input device to receive input from the user. In this case, it is sufficient to enable the push switch 74 to send a permission signal indicating permission to execute the update process to the OTA master 10. When using a push switch 74 as an input device, it is preferable to install the push switch 74 on the steering wheel from the viewpoint of not interfering with the user's driving operations. When the push switch 74 is installed on the steering wheel, the same effects as in (4) above can be enjoyed. In step S170 of the first process, the device that transmits the permission signal may be changed as appropriate.

[0093] • The HMI device 70 installed in the vehicle 100 may be replaced with or in addition to the one in the above embodiment. For example, instead of or in addition to the center display in the above embodiment, a display provided on the meter panel may be used. This display will be called the front display. Confirmation notifications may be made using this front display. Also, for example, when obtaining user permission in step S170 or step S280, the user's response obtained via the voice recognition device 72 or the push switch 74 on the steering wheel may be displayed on the front display.

[0094] The charging conditions in the first and second processes are not limited to the examples of the embodiments described above. For example, the second requirement may be omitted. The charging conditions only need to include the requirement that the first battery 61 is being charged.

[0095] The method for determining whether or not the first battery 61 is being charged is not limited to the example of the above embodiment. The method is not limited to one using a charging sensor 82 as in the above embodiment, as long as it can appropriately determine whether or not the first battery 61 is being charged.

[0096] In the first and second processes, it is not mandatory to consider whether permission is required depending on whether the first battery 61 is being charged or not. If the determination regarding the charging of the first battery 61 is to be abolished in the first process, the first process shown in Figure 8 may be adopted, for example. That is, if the CPU 20 determines in step S120 that the specific control device 90 to be updated is not part of the drive system, the process may proceed to step S150. Note that in Figure 8, the same step numbers as in Figure 4 are used where the same processing as in Figure 4 is performed.

[0097] If the determination regarding the charging of the first battery 61 is to be abolished in the second process, for example, the second process shown in Figure 9 may be adopted. In the second process shown in Figure 9, instead of determining in step S230 whether or not the first battery 61 is being charged, the process in step S300 is adopted. In step S300, the CPU 20 determines whether or not the vehicle 100 is in the accessory-on state. If the vehicle 100 is in the accessory-on state (step 300: YES), the CPU 20 proceeds to step S240. On the other hand, if the vehicle 100 is not in the accessory-on state (step S300: NO), the CPU 20 proceeds to step S270. Note that in Figure 9, the same step numbers as in Figure 5 are used where the same processing as in Figure 5 is performed.

[0098] The length of the waiting time used in various processes, such as the predetermined time used in the setup process and the first waiting time used in the first process, may be set appropriately according to their respective purposes. The non-volatile memory provided by the specific control device 90 may be a single-bank structure. Unlike a double-bank structure, this type of memory has only one storage area. Furthermore, it is not possible to write data while reading data from this memory. Therefore, if a single-bank structure non-volatile memory is used, it is generally considered that not only the activation process but also the installation process should be performed when the vehicle 100's system is turned off.

[0099] Some specific control units 90 may employ a double-bank structure for their non-volatile memory, while the remaining specific control units 90 may employ a single-bank structure for their non-volatile memory. Depending on the structure of the non-volatile memory provided by the specific control unit 90 to be updated, the installation and activation processes may be performed at an appropriate time.

[0100] • In the same specific control device 90, non-volatile memories with different structures may be used for the first memory and the second memory. In the same specific control device 90, the first memory and the second memory may be combined into a single non-volatile memory.

[0101] The above examples of modifications regarding non-volatile memory can also be applied to the OTA master 10. That is, a single-bank structure may be used as the non-volatile memory for the OTA master 10. Non-volatile memories with different structures may be used for the first memory 21 and the second memory 22. The first memory 21 and the second memory 22 may be combined into a single non-volatile memory.

[0102] The OTA master 10 may update its own software. In other words, the electronic control unit that the OTA master 10 updates its software for may be the OTA master 10 itself.

[0103] The overall configuration of vehicle 100 is not limited to the examples of the embodiments described above. For example, vehicle 100 may have an engine in addition to the motor device 51 as a power source for vehicle 100. That is, vehicle 100 may be a plug-in hybrid vehicle. Also, for example, the connector 68 may be eliminated from vehicle 100. That is, vehicle 100 may be a hybrid vehicle that cannot be charged by an external power source 300. Also, for example, vehicle 100 may be an engine-powered vehicle that does not have a motor device 51 as a power source for vehicle 100 and only has an engine.

[0104] When using a vehicle 100 that is not an electric vehicle or a plug-in hybrid vehicle, the first process shown in Figure 8 and the second process shown in Figure 9 may be applied to the vehicle. In this case, the configurations of each of the above modification examples may be applied as appropriate. For example, a configuration that determines whether permission is required depending on the type of specific control device 90 to be updated may be applied. Alternatively, a configuration that considers whether there is a permission period when the vehicle 100's system is on may be applied, for example, as explained in Figure 7. Alternatively, a configuration that executes the update process by obtaining permission outside of the permission period when a permission period is set may be applied, for example, as explained in Figure 6.

[0105] The OTA master 10 may include a processing circuit that includes one or more processors that perform various processes according to a computer program (software). The OTA master 10 may also include a processing circuit that includes one or more dedicated hardware circuits, such as application-specific integrated circuits (ASICs), that perform at least some of the various processes, or a processing circuit that includes a combination of the above processors and dedicated hardware circuits. The processor includes a CPU and memory such as RAM and ROM. The memory stores program code or instructions configured to cause the CPU to perform the processes. Memory, i.e., computer-readable media, includes any available media that can be accessed by a general-purpose or dedicated computer. This modification example can also be applied to the specific control device 90.

[0106] <Note> The above embodiments and their modifications include the configurations described in the following appendix. [Note 1] A software update system for a vehicle comprising an electronic control unit mounted on a vehicle, an information processing unit for managing software updates of the electronic control unit, and an input device for receiving input from a user, wherein the information processing unit is capable of performing update processing for the electronic control unit to update software and setting an authorization period for the update processing based on input through the input device, and if no authorization period is set, the system executes the update processing on the condition that it has received an authorization signal from the input device indicating authorization for the update processing, and if an authorization period is set, the system executes the update processing within the authorization period without being conditional on receiving the authorization signal.

[0107] [Note 2] The information processing device, when the permission period is set, will perform the update process even outside the permission period, provided that the permission signal has been obtained. This is the vehicle software update system described in [Note 1].

[0108] [Note 3] If the electronic control device that is the target of the software update controls the vehicle's drive source or the vehicle's brake system, the information processing device executes the update process on the condition that it has obtained the permission signal, regardless of whether the permission period has been set or not, as described in [Note 1] or [Note 2].

[0109] [Note 4] A vehicle software update system according to any one of [Note 1] to [Note 3], comprising a vehicle speed sensor for detecting the vehicle's driving speed, wherein the information processing device executes the update process on the condition that it has obtained the permission signal, regardless of whether the permission period is set or not, when the vehicle's driving speed is greater than zero.

[0110] [Note 5] The input device is a voice recognition device provided in the passenger compartment of the vehicle, or a push switch provided on the steering wheel of the vehicle. [Note 4] The software update system for a vehicle.

[0111] [Note 6] A software update system for a vehicle according to any one of [Note 1] to [Note 5], comprising a battery that can be charged by an external power source of the vehicle, wherein the information processing device, when the battery is being charged, executes the update process regardless of whether the permission period is set or not, and without requiring the acquisition of the permission signal. [Explanation of symbols]

[0112] 10…OTA Master 20…CPU 51…Motor device 52…Brake system 53…Parking brake device 61…Battery No. 1 71…Display 72…Speech recognition device 74…Push switch 83... Vehicle speed sensor 90...Specific control device 100...vehicles 300…External power supply

Claims

1. This involves performing an update process for the electronic control unit installed in the vehicle, and Based on external input, the permission period for the update process is set, It is possible to do this, If the aforementioned permission period is not set, the update process is executed on the condition that a permission signal indicating permission for the update process has been obtained. If the aforementioned permission period is set, the update process will be executed within the aforementioned permission period, regardless of whether the permission signal has been obtained. Information processing device for vehicles.

2. The electronic control unit installed in the vehicle, An information processing device for managing software updates of the aforementioned electronic control device, It includes an input device that accepts input from the user, The aforementioned information processing device is The process of updating the software for the electronic control device is performed, Based on the input through the aforementioned input device, the permission period for the update process is set, It is possible to do this, If the aforementioned permission period is not set, the update process is executed on the condition that a permission signal indicating permission for the update process is obtained from the input device. If the aforementioned permission period is set, the update process will be executed within the permission period, regardless of whether the permission signal has been obtained. A software update system for vehicles.

3. The information processing device, when the permission period is set, will execute the update process even outside the permission period, provided that it has received the permission signal. A software update system for a vehicle according to claim 2.

4. If the electronic control unit that is the target of the software update controls the vehicle's drive source or the vehicle's brake system, The information processing device executes the update process on the condition that it has received the permission signal, regardless of whether the permission period has been set or not. A software update system for a vehicle according to claim 2.

5. The vehicle is equipped with a vehicle speed sensor that detects the vehicle's travel speed, The information processing device, when the vehicle's speed is greater than zero, executes the update process, regardless of whether the permission period is set, provided that it has received the permission signal. A software update system for a vehicle according to claim 2.

6. The input device is either a voice recognition device located inside the vehicle's cabin or a push switch located on the vehicle's steering wheel. A software update system for a vehicle according to claim 5.

7. The vehicle is equipped with a battery that can be charged by an external power source, If the battery is being charged, the information processing device will execute the update process regardless of whether the permission period is set or not, and without requiring the acquisition of the permission signal. A software update system for a vehicle according to claim 2.

8. This system is applied to vehicles equipped with an electronic control unit and an information processing unit that manages the software of the electronic control unit. The aforementioned information processing device, Based on external input, a permission period is set for updating the software of the electronic control unit. If the aforementioned permission period is not set, the update process is executed on the condition that a permission signal indicating permission for the update process is obtained. If the aforementioned permission period is set, the update process will be executed within the aforementioned permission period, without being conditional on obtaining the aforementioned permission signal. Make them do it A program for vehicles.