Vehicle control device and vehicle control method

Abstract

A vehicle control device (10) comprising a processor (10a) which causes functions provided by an in-vehicle device of a vehicle (1) to operate, and memory (10d), wherein: the processor (10a) estimates, on the basis of navigation information and / or vehicle information, a non-operation time for each function, during which the function does not operate; and the processor updates the software, which is stored in the memory (10d), of each function in accordance with the non-operation time thereof.

Description

Vehicle control device and vehicle control method

[0001] The present invention relates to a vehicle control device and a vehicle control method.

[0002] A technology is known in which application programs stored on a first data storage surface, which is the operational surface, are operated, updated data is written to a second data storage surface, which is the non-operational surface, the second data storage surface is rewritten, and the operational surface is switched from the first data storage surface to the second data storage surface (Patent Document 1).

[0003] International Publication No. 2020 / 032122

[0004] However, the technology described in Patent Document 1 has the problem that two physical banks of memory may be required to correspond to the operational and non-operational sides, which increases the cost of updating software.

[0005] The problem to be solved by the present invention is to provide a vehicle control device and a vehicle control method that can perform software updates at low cost.

[0006] The present invention solves the above problem by estimating the inoperative time for each function provided by the vehicle's onboard equipment based on navigation information and / or vehicle information, and updating the software for each function stored in memory according to the inoperative time.

[0007] According to the present invention, software updates can be performed at low cost.

[0008] Fig. 1 is a block diagram showing an example of a software update system including a vehicle control device according to an embodiment of the present invention. Fig. 2 is a diagram for explaining an example of updating the dead time of each function according to a transition of a driving state according to this embodiment. Fig. 3 is a diagram for explaining a method for determining the order of software updates according to this embodiment. Fig. 4 is a diagram for explaining whether or not a function can be stubbed and called according to the dead time according to this embodiment. Fig. 5 is a flowchart showing an example of a control procedure of a dead time estimation method according to this embodiment.

[0009] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of a vehicle control device and a vehicle control method according to the present invention will be described with reference to the accompanying drawings.

[0010] 1 is a block diagram showing an example of a software update system including a vehicle control device according to an embodiment of the present invention. The software update system 1000 is a system that manages software updates for a vehicle 1. The software update system 1000 is a system that can update software for vehicle control, diagnosis, and the like executed by an electronic control device (hereinafter referred to as an ECU (Electronic Control Unit)) of the vehicle 1 over the air (OTA). Updating software over the air in this manner is also referred to as SOTA (Software Over the Air).

[0011] As shown in FIG. 1 , the software update system 1000 includes an ECU 10, an additional ECU 11, and an additional ECU 12. Each ECU is mounted on a vehicle 1 and connected via an in-vehicle network, such as a Controller Area Network (CAN) or a Local Interconnect Network (LIN). Each ECU controls the vehicle's in-vehicle devices to execute functions provided by the in-vehicle devices. In this embodiment, the ECU 10 is the ECU that is the target of a software update (also referred to as an update target ECU). The ECU 10 is an example of a "vehicle control device" described in the claims. The additional ECUs 11 and 12 are ECUs other than the update target ECU and transmit vehicle information necessary for the software update of the ECU 10. For simplicity, FIG. 1 illustrates two examples of the additional ECUs (the additional ECUs 11 and 12). However, the additional ECUs are not limited to this and may be one ECU or three or more ECUs. In this embodiment, a case where software update is performed in the ECU 10 will be described as an example. However, if software update is required for the other ECUs 11 and 12, the software update is performed in the same manner as for the ECU 10.

[0012] In this embodiment, a case where a program executed by an ECU processor is wirelessly rewritten will be described as an example of a wireless ECU software update, but the software update system 1000 can also be applied to cases where data used in various software, such as map data used in a navigation system of the vehicle 1 and control parameters used in the ECU, is wirelessly rewritten. Also, while Figure 1 illustrates one vehicle as the vehicle 1, the software update system 1000 is a system that can update software for multiple vehicles 1.

[0013] In this embodiment, "ECU software update" refers to the change of the ECU software version to a new version, i.e., the change of the program to be executed by the processor to a new version. Wireless software updates not only involve wirelessly obtaining and rewriting the new version of the program itself from outside the vehicle 1, but also wirelessly obtaining and rewriting various data used when the new version of the program is executed, and differential data between the new version of the program and the old version of the program, from outside the vehicle 1. In the following description, data required for software updates, such as the new version of the program and differential data, are referred to as "update data." Furthermore, the "new version of the program" is referred to as the "new program," and the "old version of the program" is referred to as the "old program."

[0014] In a software update, the ECU 10 performs an installation process to write the acquired update data to a flash memory, and then performs an activation process to read the update data, thereby switching the software version to a new version. The ECU 10 updates the software for each function executed by the ECU 10. In this embodiment, the ECU 10 sets an update schedule for executing the software update process and executes the software update according to the update schedule. The update schedule is set based on the order in which the software for each function of the ECU 10 is updated and the required time for each function update. The required time includes at least the time required to execute the installation process and the activation process. While the ECU 10 is executing the software update process for executing a function, the ECU 10 cannot execute that function.

[0015] The ECU 10 is a microcomputer composed of, for example, a central processing unit (CPU) 10a, a read-only memory (ROM) 10b, a random access memory (RAM) 10c, and a flash memory 10d. Each ECU also includes a power supply circuit, a data transfer circuit, and other components in addition to the microcomputer. The flash memory 10d stores programs for implementing the software for each function of the ECU. The flash memory 10d is a non-volatile storage medium physically composed of a single recording medium. The flash memory 10d is a single-bank memory. In single-bank memory, there is no distinction between a program storage area and an area where the CPU 10a executes the program, and the program cannot be rewritten while the CPU 10a is executing the program. The CPU 10a is a processor that operates functions provided by on-board equipment. In other words, the software for each function of the ECU 10 is implemented by the CPU 10a executing programs stored in the flash memory 10d and performing various processes. In this embodiment, the CPU 10a updates the software by rewriting the programs stored in the flash memory 10d. The CPU 10a is an example of a "processor" as claimed. The flash memory 10d is an example of a "memory" as claimed.

[0016] In this embodiment, the ECU 10 will be described as an example of a driving assistance ECU for executing driving assistance functions that assist the driving of the vehicle 1. The ECU 10 includes software for executing the driving assistance functions. The driving assistance functions executed by the ECU 10 include, for example, emergency braking (FEB), rear emergency braking (EAP), lane departure prevention (LDP), rear side collision prevention (BSI), autonomous driving (AD), parking assistance (APA), leading vehicle departure notification (LCDN), and exit safety assistance (OSE). In this embodiment, each function is independent of the application. That is, each application includes a program for executing the respective function. This enables software updates for each function. In FIG. 1 , for simplicity of explanation, the ECU 10 is illustrated as including three function execution units (e.g., a first function execution unit 101, a second function execution unit 102, and a third function execution unit 103) for executing the driving assistance functions. Each function execution unit executes a function such as FEB or EAP. The number of function execution units for driving assistance is not limited to three, but may be two or less, or may be four or more.

[0017] In this embodiment, the ECU to be updated may be another ECU for controlling the onboard equipment of the vehicle 1. For example, the ECU to be updated may be a body system ECU, a driving system ECU, a multimedia system ECU, or a power supply system ECU. The number of ECUs to be updated is not particularly limited, and software can be updated for multiple ECUs to be updated. For example, the multimedia system ECU is a general term for ECUs that control the multimedia system of the vehicle 1. Examples of multimedia system ECUs include a navigation control ECU that controls the navigation system of the vehicle 1 and an audio control ECU that controls the audio equipment of the vehicle 1. The power supply system ECU is a general term for ECUs that control the power supply system of the vehicle 1. Examples of power supply system ECUs include a power supply control ECU that controls the ACC (accessory) power supply and IG (ignition) power supply installed in the vehicle 1. The types of ECUs installed in the vehicle 1 and the way in which the ECUs are distinguished are not limited to these. The vehicle may also be equipped with ECUs other than these ECUs. Each ECU 10 controls the in-vehicle devices of the vehicle 1 to execute each function.

[0018] The ECU 10 also includes a function for updating software that executes each function of the ECU 10. Specifically, as shown in FIG. 1 , the ECU 10 includes a dead time management unit 100, an update execution unit 110, and a task scheduler 120 as functional blocks for software updates. The dead time management unit 100 and function execution units such as the first function execution unit 101, the second function execution unit 102, and the third function execution unit 103 are functional units included in the OEM domain, while the update execution unit 110 and the task scheduler 120 are functional units included in the supplier domain. In this embodiment, the ECU 10 updates the software for each function while the vehicle ignition is on. For example, the ECU 10 updates the software from when the vehicle 1 starts traveling from a departure point, such as a home, toward a destination, until it arrives at the destination and parks and stops.

[0019] The inactivity time management unit 100 estimates the inactivity time for each driving assistance function and manages the estimated inactivity time. The inactivity time is the time during which the function is expected to be inactive, and is an estimate of how long the function will not be active from the estimated time point. The inactivity time may also be a period during which the function is not active and can be temporarily disabled.

[0020] Here, an example of a procedure for estimating the dead time will be described. First, when the ignition of the vehicle 1 is turned on and the ECU 10 is started, the dead time management unit 100 periodically acquires navigation information and / or vehicle information of the vehicle 1. The navigation information and / or vehicle information is information acquired from the other ECUs 11 and 12.

[0021] The navigation information is information necessary for the vehicle 1 to travel a route from a departure point to a destination, and includes the vehicle 1's position information, map information, traffic congestion information, and required travel time. The map information includes, for example, the road type (general road, expressway, etc.) of the roads included in the travel route. The required travel time includes the required time to the destination, and if the travel route includes an expressway, the required time to the expressway entrance. The traffic congestion information includes the presence or absence of traffic congestion on the travel route and its location. The vehicle information is information related to the vehicle status of the vehicle 1, and includes, for example, information related to the vehicle speed, accelerator opening, brake pressure, gear lock status, and execution status of driving assistance functions of the vehicle 1. The gear status is the shift position setting, and includes, for example, parking range, drive range, and reverse range. The lock status includes whether the doors are locked or unlocked.

[0022] Next, the idle time management unit 100 determines whether the state of the navigation or vehicle 1 has changed based on the navigation information and / or vehicle information. For example, the idle time management unit 100 periodically references a stored table based on the navigation information and / or vehicle information to determine the current state of the navigation or vehicle 1, and determines that the state of the navigation or vehicle 1 has changed if the current state of the navigation or vehicle 1 differs from the previous determination result. The stored table, for example, stores predetermined states of the navigation or vehicle 1 and their determination conditions, each associated with each state of the navigation or vehicle 1. The determination conditions are conditions determined based on the navigation information and vehicle information. The idle time management unit 100 determines whether the determination conditions are met based on the navigation information and / or vehicle information, and if the determination conditions are met, determines that the current state of the navigation or vehicle is the state of the navigation or vehicle corresponding to the determination condition. If the current state of the navigation or vehicle 1 is the same as the previous determination result, the idle time management unit 100 determines that the state of the navigation or vehicle 1 has not changed.

[0023] Then, when it is determined that the state of the navigation or the vehicle has changed, the idle time management unit 100 estimates the idle time for each function. Specifically, the idle time management unit 100 estimates the idle time based on the navigation information and / or the vehicle information. At this time, the idle time management unit 100 may estimate the idle time for all functions, or may estimate the idle time for some functions. For example, the idle time management unit 100 may estimate the idle time limited to functions that are subject to software updates. Note that, in this embodiment, the idle time estimation is performed when it is determined that the state of the navigation or the vehicle has changed, but this is not limited thereto, and the idle time estimation may be performed at regular intervals.

[0024] For example, in the case of a function used on an expressway, such as automated driving (AD), the dead time management unit 100 acquires a driving route from navigation information, and if the driving route includes an expressway, estimates the time from the current position of the vehicle 1 to the entrance of the expressway as the dead time of the function related to automated driving (AD).If the driving route does not include an expressway, the dead time management unit 100 estimates a sufficiently large value, for example, a predetermined maximum value, as the dead time of the function related to automated driving (AD).

[0025] In addition, for example, in the case of a function used at the destination, such as parking assistance (APA), the downtime management unit 100 estimates the time from the current position of vehicle 1 to the destination or intermediate point of vehicle 1 based on navigation information as the downtime of the function related to parking assistance (APA).

[0026] Furthermore, for example, in the case of a function used when the vehicle is stopped, such as a preceding vehicle departure notification (LCDN), when the vehicle 1 is traveling on a highway, the dead time management unit 100 estimates, based on navigation information, the time it will take for the vehicle 1 to travel from the current position of the vehicle 1 to the highway exit or a congestion point as the dead time of the function related to the preceding vehicle departure notification (LCDN).When the vehicle 1 is traveling on an ordinary road, the dead time management unit 100 estimates, based on navigation information, the time it will take for the vehicle 1 to travel from the current position of the vehicle 1 to the next traffic light as the dead time of the function related to the preceding vehicle departure notification (LCDN).

[0027] Furthermore, for example, in the case of a function used while driving, such as an ITS-based safety function, when vehicle 1 is stopped at a traffic light, the inoperative time management unit 100 estimates the expected waiting time until vehicle 1 departs as the inoperative time of the ITS-based safety function.

[0028] When the idle time management unit 100 estimates the idle time, it manages the estimated idle time for each function. Specifically, the idle time management unit 100 stores the idle time that is estimated first after the ECU 10 is started. Then, every time the idle time management unit 100 estimates the idle time, it updates the stored idle time to the newly estimated idle time.

[0029] An example of a method for managing inactive time will now be described with reference to Fig. 2. Fig. 2 is a diagram for explaining an example of updating the inactive time of each function in accordance with a transition in the driving state in this embodiment. In Fig. 2, the navigation information, vehicle information, and inactive time for each function are updated each time the state of the navigation or vehicle 1 changes. Fig. 2 shows an example of a method for managing inactive time from when the vehicle 1 departs from home until it arrives at its destination.

[0030] 2, the state of the navigation or vehicle transitions from a state in which vehicle 1 is at home to a state in which vehicle 1 is at a destination via the states of an ordinary road (driving), an ordinary road (waiting at a traffic light), an expressway, and an ordinary road (traffic jam). For example, the idle time management unit 100 determines that the state of the navigation or vehicle is "ordinary road (driving)" because, based on the navigation information, the determination condition that vehicle 1 is located on an ordinary road is satisfied, and based on the vehicle information, the determination condition that vehicle 1 is traveling is satisfied. Furthermore, even when vehicle 1 is located on an ordinary road, if, based on the navigation information, the determination condition that vehicle 1 is located at a traffic light is satisfied, the idle time management unit 100 determines that the state of the navigation or vehicle is "ordinary road (waiting at a traffic light)."

[0031] The dead time management unit 100 estimates the dead time each time the state of the navigation or the vehicle 1 changes. In the example of Fig. 2, for example, when the vehicle 1 is at home, the dead time management unit 100 estimates the dead time of the FEB, LDP, and BSI functions to be 60 seconds, the dead time of the AD and LCDN functions to be 999 seconds, and the dead time of the EAP, APA, and OSE functions to be 0 seconds, and stores the estimated dead time for each. Then, when the vehicle 1 starts traveling and is traveling on an open road, the dead time management unit 100 re-estimates the dead time and updates the stored dead time. Specifically, the downtime management unit 100 estimates the downtime of the FEB, EAP, LDP, and BSI functions to be 0 seconds, the downtime of the AD function to be 900 seconds, the downtime of the LCDN and OSE functions to be 999 seconds, and the downtime of the APA function to be 1800 seconds, and updates each estimated downtime.

[0032] As an example, the updating of the APA's inoperative time will be described. The APA's inoperative time is estimated to be 0 seconds when vehicle 1 is at home, but is updated to 1800 seconds when vehicle 1 starts traveling on an ordinary road. This is because the next time the APA's function will be needed is when vehicle 1 arrives at its destination, and it is thought that the function will not operate until then. Also, for example, the AD's inoperative time gradually decreases as vehicle 1 approaches a highway, and is updated to 0 seconds when vehicle 1 is on the highway. Thereafter, after vehicle 1 leaves the highway, there is no situation in which the AD is used, so the AD's inoperative time is updated to 999 seconds.

[0033] The update execution unit 110 executes a software update of the driving assistance function according to the downtime. Specifically, the update execution unit 110 first acquires, for each function, the required time required for the software update of that function. For example, the required time is determined by referring to information included in update data acquired from outside the vehicle 1. The update execution unit 110 compares the downtime with the required time for each function and determines whether a software update of that function is executable. If the required time is shorter than the downtime, the update execution unit 110 determines that a software update of that function is executable. If the required time is longer than the downtime, the update execution unit 110 determines that a software update of that function is not executable. If the update execution unit 110 determines that a software update is executable, the update execution unit 110 executes a software update process for that function within the downtime based on the update data.

[0034] In the update process, the update execution unit 110 executes an installation process to write a new program after deleting the old program stored in the flash memory 10d, and then executes an activation process to read the new program written in the flash memory 10d into the microcomputer of the ECU.

[0035] The update execution unit 110 may also acquire update data and store it in advance in a memory separate from the flash memory 10d. The update data may be acquired, for example, from an external software update server. The external software update server is a server that manages software updates for each vehicle.

[0036] Furthermore, in this embodiment, the task scheduler 120 may set an update schedule based on inactivity time. The update execution unit 110 executes software updates for each function in order according to the update schedule set by the task scheduler 120. For example, when there are multiple functions for which software updates can be executed, the task scheduler 120 determines the order in which software updates are to be executed based on the inactivity time and required time for each function, using a predetermined criterion so that software updates for as many functions as possible are executed. The predetermined criterion is, for example, the length of inactivity time. The task scheduler 120 compares the length of inactivity time for each function, determines the order in which software updates are to be executed in order from the function with the shortest inactivity time, and sets the update schedule.

[0037] FIG. 3 illustrates an example of a method for setting an update schedule in which software updates are performed in order of shortest downtime. FIG. 3 is a diagram for explaining a method for determining the order of software updates according to this embodiment. Here, as shown in the table on the left side of FIG. 3 , the downtimes for the first function, the second function, and the third function are 40 seconds, 70 seconds, and 50 seconds, respectively, and the required times for software updates for the first function, the second function, and the third function are 30 seconds, 20 seconds, and 10 seconds, respectively. Since the required times for all functions are shorter than the downtimes, it is determined that software updates can be performed for all functions. Since the downtimes are shortest for the first function, the third function, and the second function, the task scheduler 120 sets the update schedule so that software updates are performed in the order of the first function, the third function, and the second function. In the example of FIG. 3 , as shown in the diagram on the right side, the software update for the first function is first performed for a required time RT1 within the downtime N1, and then the software update for the third function is performed. The software update for the third function is executed for the required time RT3 within the dead time NT3, and then the software update for the second function is executed for the required time RT2 within the dead time NT2.

[0038] In this embodiment, the idle time management unit 100 may determine whether to stub (temporarily disable) or call a function based on the idle time. Whether to stub a function determines whether to delete the function logic itself from memory to free up memory. Whether to call a function determines whether to call the function logic. By performing SOTA in the stubbed area, resources can be saved, and the processing load can be reduced by skipping the function call. For example, if the idle time for each function is longer than a predetermined multiple (e.g., 10 times) of the time required for the software update, the idle time management unit 100 determines that the function can be stubbed and stubs the function. Furthermore, if the idle time is shorter than 10 times the required time but longer than the predetermined time, the idle time management unit 100 skips the call of the function. Furthermore, if the idle time is shorter than the predetermined time, the idle time management unit 100 calls the function as usual.

[0039] An example of a method for determining whether a function can be stubbed and called depending on the inoperation time will be described with reference to FIG. 4 . FIG. 4 is a diagram for explaining whether a function can be stubbed and called depending on the inoperation time according to this embodiment. FIG. 4 shows a table indicating the inoperation time of each function, a usage image map indicating whether each function can be stubbed, and a call necessity map indicating whether each function can be call skipped. In FIG. 4 , "1" indicates that stubbed function is not possible, and "0" indicates that stubbed function is possible. In FIG. 4 , "1" indicates that call skipped function is not possible, and "0" indicates that call skipped function is possible.

[0040] For example, assume that vehicle 1 is traveling on a public road and stopped at a traffic light. In this case, the inoperation times of each function are 60 seconds for FEB, EAP, LDP, and BSI, 999 seconds for AD and APA, and 0 seconds for LCDN and OSE. In this case, FEB, EAP, LDP, BSI, LCDN, and OSE cannot be stubbed, while AD and APA can be stubbed. Also, in this case, call skip is possible for FEB, EAP, LDP, BSI, AD, and APA, but call skip is not possible for LCDN and OSE.

[0041] Next, a procedure for estimating dead time in the ECU according to this embodiment will be described with reference to the flowchart of Fig. 5. Fig. 5 is a flowchart showing an example of a control procedure for the dead time estimation method according to this embodiment. In Fig. 5, when the ignition of the vehicle 1 is turned on, the ECU 10 starts the control flow from step S1 at regular intervals.

[0042] In step S1, the ECU 10 acquires navigation information and vehicle information. For example, the ECU 10 acquires the navigation information and vehicle information from the other ECUs 11 and 12. In step S2, the ECU 10 determines whether the state of the navigation or vehicle has changed based on the navigation information and vehicle information. For example, the ECU 10 determines the current state of the navigation or vehicle, and if the current state of the navigation or vehicle is different from the state determined in the previous control flow, determines that the state of the navigation or vehicle has changed.

[0043] If it is determined that the state of the navigation or the vehicle has changed, the ECU 10 proceeds to step S3. If it is determined that the state of the navigation or the vehicle has not changed, the ECU 10 proceeds to step S9. In step S3, the ECU 10 acquires navigation information. In step S4, the ECU 10 acquires vehicle information. In step S5, the ECU 10 selects a function to be determined.

[0044] In step S6, the ECU 10 calculates the inoperation time for each function to be determined based on the navigation information and vehicle information. In step S7, the ECU 10 updates the inoperation time. Specifically, the ECU 10 updates the stored inoperation time from the inoperation time calculated in the previous control flow to the inoperation time newly calculated this time. In step S8, the ECU 10 determines whether the inoperation times of all functions have been calculated.

[0045] If the inoperative time of all functions has been calculated, the ECU 10 ends the control flow. If the inoperative time of all functions has not been calculated, the ECU 10 returns to step S5, selects another function whose inoperative time has not yet been calculated as a function to be determined, and repeats the control flow. In step S9, the ECU 10 decrements the inoperative time. The inoperative time is the inoperative time estimated in the previous control flow.

[0046] As described above, in the vehicle control device and vehicle control method according to this embodiment, the vehicle control device includes a processor and memory that operate functions provided by the vehicle's onboard devices, and the processor estimates the downtime for each function based on navigation information and / or vehicle information, and updates the software for each function stored in the memory according to the downtime. This allows software updates to be performed at low cost.

[0047] In the vehicle control device and vehicle control method according to this embodiment, the processor compares, for each function, the inactivity time with the time required to update the software of the function, and if the required time is shorter than the inactivity time, determines that the software of the function can be updated, and if it determines that the software update can be performed, updates the software of the function stored in the memory. This allows the software of each function to be updated when the function is not operating.

[0048] Furthermore, in the vehicle control device and vehicle control method according to this embodiment, when there are multiple functions for which software updates can be performed, the processor determines the order in which the software updates will be performed based on the inoperation time and required time for each function so that software updates can be performed for as many functions as possible, and updates the software for the functions in the determined order. This allows software updates to be performed for as many functions as possible.

[0049] In the vehicle control device and vehicle control method according to the present embodiment, the processor updates the software of the function while the ignition of the vehicle is on. This allows the software update to be performed while the ignition of the vehicle is on.

[0050] Furthermore, in the vehicle control device and vehicle control method according to the present embodiment, the functions are independent for each application, which allows software updates to be performed on a function-by-function basis.

[0051] Furthermore, in the vehicle control device and vehicle control method according to this embodiment, the processor stores or updates the estimated inoperative time, thereby making it possible to manage the inoperative time of the function.

[0052] Furthermore, in the vehicle control device and vehicle control method according to this embodiment, the processor periodically determines whether the state of the navigation or the vehicle has changed based on the navigation information and / or vehicle information, and if it determines that the state of the navigation or the vehicle has changed, estimates the inoperation time for each function and updates the stored inoperation time. This allows the inoperation time to be updated each time the state of the navigation or the vehicle changes.

[0053] It should be noted that the above-described embodiments have been described to facilitate understanding of the present invention, and are not intended to limit the present invention. Therefore, each element disclosed in the above-described embodiments is intended to include all design modifications and equivalents that fall within the technical scope of the present invention.

[0054] 1000... Software update system ECU 10 CPU 10a 100... Dead time management unit 110... Update execution unit 120... Task scheduler Flash memory 10d

Claims

1. A vehicle control device comprising a processor and memory that operate functions provided by on-board equipment of a vehicle, wherein the processor estimates, for each function, an inoperative time during which the function will not be operating based on navigation information and / or vehicle information, and updates the software for each function stored in the memory in accordance with the inoperative time.

2. A vehicle control device as described in claim 1, wherein the processor compares, for each function, the inoperation time with the time required to update the software of the function, and if the required time is shorter than the inoperation time, determines that the software update of the function can be performed, and if it determines that the software update can be performed, updates the software of the function stored in the memory.

3. A vehicle control device as described in claim 2, wherein the processor, when there are multiple functions for which software updates can be performed, determines the order in which software updates will be performed based on the inoperation time and required time for each function so that software updates for as many functions as possible are performed, and updates the software of the functions in the determined order.

4. A vehicle control device according to any one of claims 1 to 3, wherein the processor updates the software of the function when the ignition of the vehicle is on.

5. A vehicle control device according to any one of claims 1 to 4, wherein the function is an independent function for each application.

6. A vehicle control device according to any one of claims 1 to 5, wherein the processor stores or updates the estimated dead time.

7. A vehicle control device according to claim 6, wherein the processor determines whether the state of the navigation or the vehicle has changed at regular intervals based on the navigation information and / or the vehicle information, and when it determines that the state of the navigation or the vehicle has changed, estimates the inoperation time for each function and updates the stored inoperation time.

8. A vehicle control method executed by a vehicle control device having a processor and memory that operate functions provided by on-board equipment of a vehicle, wherein the processor estimates, for each function, an inoperative time during which the function will not be operating based on navigation information and / or vehicle information, and updates the software for each function stored in the memory in accordance with the inoperative time.

Images