Vehicle control system

Abstract

To enable software update even in the case that hardware resources are exhausted.SOLUTION: A vehicle control device includes a first computation unit and a second computation unit. Therein, a determination is made, from information retained by a resource information retention unit, on the basis of an execution state of the first computation unit and a configuration of new software to be newly implemented, as to whether existing software can be updated to the new software in the first computation unit, as well as, whether the entire configuration of the new software can be updated in the first calculation unit, or whether the configuration of the new software should be partially reallocated to the second computation unit. Then, in the case that the relocation to the second computation unit is determined, a portion of the configuration of the new software to be relocated to the second computation unit is determined considering latency between the first computation unit and the second computation unit due to execution of the new software.SELECTED DRAWING: Figure 1

Description

Technical Field

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

Background Art

[0002] There is a technique for updating software installed in a vehicle control device (ECU: Electronic Control Unit) after product release. The sophistication of vehicle electronic control has been advancing year by year, and updating software after product release has great value in always installing the latest control software in the vehicle. However, since the amount of hardware resources such as processor performance and memory capacity of the vehicle control device is often limited, a software update method that effectively utilizes limited hardware resources is considered effective.

[0003] For example, Patent Document 1 describes a technique for calculating the free capacity of a storage unit by arranging modules to be updated in the order of dependence on update information of software, and changing the update order of the modules so that the free capacity is not insufficient, and then updating the software. This enables software update even when the free capacity for storing modules is smaller than the capacity of the software to be updated.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] According to the technology described in Patent Document 1, by changing the update order of modules, software can be updated even when the free space in the memory unit that stores the modules is small. However, since it is not possible to update software beyond the memory capacity of a single system, in systems with a long product lifespan, such as those used for decades, the available free space reaches its limit, leading to a problem where software updates become impossible due to hardware resource depletion.

[0006] The present invention aims to provide a vehicle control device that enables software updates even when hardware resources are depleted. [Means for solving the problem]

[0007] To solve the above problems, for example, the configuration described in the claims may be adopted. This application includes several means for solving the above-mentioned problems, but one example is: This system, which includes a first arithmetic unit that executes existing software and a second arithmetic unit that executes software different from the existing software, is applied to a vehicle control device that controls a vehicle. And the vehicle control system is Based on the execution status of the first arithmetic unit and the configuration of the newly implemented software, the first arithmetic unit has an update determination unit that determines whether the existing software can be updated to the new software, An update execution unit performs an update to the existing software based on the judgment result of the update judgment unit, A resource monitoring unit that monitors resource information used during vehicle operation, A resource information storage unit that stores resource usage information based on resource usage status provided by the resource monitoring unit, The system includes a software configuration change request transmission / reception unit that requests the second arithmetic unit to change the configuration of a part of the existing or new software being executed by the first arithmetic unit. Furthermore, the update determination unit determines from the information held by the resource information holding unit whether the entire configuration of the new software can be updated in the first calculation unit, or whether a portion of the configuration of the new software should be rearranged and placed in the second calculation unit. When the update determination unit determines that the data should be moved to the second calculation unit, the software placement change request transmission / reception unit sends a request to the second calculation unit. The software deployment change request transmission / reception unit, when performing a deployment change on a portion of the new software configuration, determines which portion of the new software configuration to deploy to the second arithmetic unit, taking into account the latency between the first and second arithmetic units during the execution of the new software. [Effects of the Invention]

[0008] According to the present invention, by changing the software placement among multiple processing units while considering the processing latency of the software that controls the vehicle, it becomes possible to update the software even when hardware resources are depleted. Other issues, configurations, and effects not mentioned above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0009] [Figure 1] This is a block diagram showing the overall configuration of a vehicle control device according to one embodiment of the present invention. [Figure 2] This is a configuration diagram showing an example of the internal arrangement of a vehicle control device according to one embodiment of the present invention. [Figure 3] This figure shows an example of existing software that is processed using one embodiment of the present invention. [Figure 4] This is a flowchart showing the processing procedure of the first arithmetic unit in one embodiment of the present invention. [Figure 5] This figure shows an example of resource usage according to one embodiment of the present invention. [Figure 6] This figure shows an example of worst-case resource usage according to one embodiment of the present invention. [Figure 7]It is a flowchart showing the processing procedure of the resource monitoring unit in an exemplary embodiment of the present invention. [Figure 8] It is a diagram showing an example of the resource usage amount of new software according to an exemplary embodiment of the present invention. [Figure 9] It is a flowchart showing the processing procedure of the update determination unit in an exemplary embodiment of the present invention. [Figure 10] It is a diagram showing an example of the determination result according to an exemplary embodiment of the present invention. [Figure 11] It is a flowchart showing the processing procedure of the update execution unit in an exemplary embodiment of the present invention. [Figure 12] It is a diagram showing an example of the arrangement change request information 109 according to an exemplary embodiment of the present invention. [Figure 13] It is a flowchart showing the processing procedure of the software arrangement change request transmission / reception unit in an exemplary embodiment of the present invention. [Figure 14] It is a diagram showing an example of the software arrangement before software update according to an exemplary embodiment of the present invention. [Figure 15] It is a diagram showing an example of the software arrangement after software update according to an exemplary embodiment of the present invention.

Embodiments for Carrying Out the Invention

[0010] Hereinafter, an exemplary embodiment of the present invention (hereinafter referred to as "this example") will be described with reference to the accompanying drawings.

[0011] [Configuration of Vehicle Control Device] ​​​​As shown in Figure 1, the vehicle control device 1 stores the software for operation (existing software) in the existing software storage unit 101. This existing software can be updated by new software supplied from an external source. The new software here is used to update at least a part of the existing software. In the drawing, software is abbreviated as "SW".

[0012] When the vehicle control device 1 updates existing software to new software, resource usage information 2 for the new software is supplied to the vehicle control device 1. This new software resource usage information 2 is acquired externally along with the new software, but it may also be generated within the vehicle when the new software is received.

[0013] The configuration of the vehicle control device 1 shown in Figure 1 is the configuration necessary when the vehicle control device 1 updates existing software to new software. The configuration of each part shown in Figure 1 is made up of the software that operates the vehicle control device 1, and similarly, the information shown in Figure 1 is acquired by the same software. The details of the processing of each configuration shown in Figure 1 will be explained in Figure 3 and subsequent figures.

[0014] First, the overall configuration of the vehicle control device 1 shown in Figure 1 will be described. The vehicle control device 1 includes an existing software storage unit 101, a first calculation unit 102, resource usage information 103, a resource monitoring unit 104, a resource information storage unit 105, and worst-case resource usage information 106. The vehicle control device 1 also includes an update determination unit 107, update determination result information 108, configuration change request information 109, an update execution unit 110, and a software configuration change request transmission / reception unit 111. Resource usage information 103, update determination result information 108, and configuration change request information 109 are each held in corresponding storage units.

[0015] Furthermore, a second calculation unit 3 is provided outside the vehicle control device 1 shown in Figure 1. This second calculation unit 3 is provided in another vehicle control device, which is provided in multiple locations within the vehicle. The configuration in which multiple vehicle control devices are provided in a vehicle will be described later in Figure 2.

[0016] The existing software storage unit 101 stores the software that the vehicle control device 1 will execute. The existing software stored in the existing software storage unit 101 is executed by the first calculation unit 102. The resource usage being processed by the first calculation unit 102 is measured within the vehicle control device 1, and the measured resource usage information 103 is stored. The resource usage information 103 is sent to the resource monitoring unit 104, where it is monitored. The monitoring results from the resource monitoring unit 104 are stored in the resource information storage unit 105. The resource information storage unit 105 has worst-case resource usage information 106 as one of the pieces of information it stores.

[0017] The update determination unit 107 determines whether the software can be executed in the first calculation unit 102 based on the resource usage information 2 of the new software and the worst resource usage information 106 held in the resource information holding unit 105, and then determines whether or not to update to the new software. Based on the determination of whether or not to update to the new software, the update determination unit 107 generates update determination result information 108. Based on the update judgment result information 108, the update execution unit 110 updates the existing software held by the existing software retention unit 101 to the new software.

[0018] Furthermore, when the update determination unit 107 determines that the first calculation unit 102 cannot update to the new software, it generates a reconfiguration request information 109. The reconfiguration request information 109 generated by the update determination unit 107 is transmitted from the software reconfiguration request transmission / reception unit 111 to the second calculation unit 3, which is located in another vehicle control device.

[0019] Upon receiving the relocation request information 109, the second arithmetic unit 3 changes the software to be executed based on the relocation request information 109. This change in software includes not only executing new software, but also executing at least a portion of the existing software held by the existing software holding unit 101. The vehicle control device equipped with the second calculation unit 3 also has the same configuration as the vehicle control device 1 shown in Figure 1, and determines whether the software for which a relocation request has been issued is executable, and if it is executable, it performs the relocation change based on the relocation change request.

[0020] [Arrangement configuration of multiple vehicle control devices] Figure 2 shows an example where multiple vehicle control devices are arranged on a vehicle M. Here, an example is shown where four vehicle control devices are arranged: a first vehicle control device 1a, a second vehicle control device 1b, a third vehicle control device 1c, and a fourth vehicle control device 1d. Each vehicle control device 1a to 1d is connected by a network NW, enabling them to send and receive data from each other. In addition, each vehicle control device 1a to 1d connected to the network NW is equipped with a transmitting / receiving unit or communication port for exchanging data with the outside of the vehicle, and can acquire information such as new software from the outside. Each vehicle control device 1a to 1d is equipped with a calculation unit (corresponding to the calculation unit 102 in Figure 1), and has the configuration shown in Figure 1 for updating the software executed by the calculation unit.

[0021] To describe the hardware configuration of each vehicle control device 1a to 1d, for example, the first vehicle control device 1a includes a CPU (Central Processing Unit) 11, a work memory 12, a storage unit 13, and an interface (I / F) 14, which are connected to each other so that data can be transferred between them. The CPU 11 executes the program (software) stored in the memory unit 13 within the work memory 12. As a result, the processing units shown in Figure 1 are configured within the work memory 12. The memory unit 13 stores programs for controlling the vehicle, as well as images and control data. The programs stored in the memory unit 13 also include programs for performing software update processing.

[0022] Interface 14 processes input data from cameras and various sensors, and outputs vehicle control data. Vehicle control devices 1b to 1d, other than the first vehicle control device 1a, have the same configuration as the first vehicle control device 1a. In the following explanation, when the vehicle control device 1 is mentioned, it refers to one of these multiple vehicle control devices 1a to 1d.

[0023] [Example of software processed by the vehicle control system] Figure 3 shows an example of the processing of existing software 101 and data D11 related to periodic information, which are calculated by the vehicle control device 1. Here, as examples of processing performed by existing software 101 in the vehicle control device 1, sensor fusion, object tracking, local map creation, trajectory generation, and control value calculation are shown. Each software process has a task that indicates the period during which calculations are performed. For example, in the example of data D11 in Figure 3, sensor fusion, object tracking, and local map creation are calculated at a 40ms cycle. Orbit generation and control value calculation are calculated at a 10ms cycle.

[0024] [Calculation processing in the calculation unit] Figure 4 is a flowchart showing the processing procedure in the first arithmetic unit 102. First, the first arithmetic unit 102 acquires the existing software 101 (step S11). Then, the first arithmetic unit 102 processes the acquired software and executes control and other actions based on the software (step S12).

[0025] Here, the first arithmetic unit 102 outputs resource usage information 103 from the calculation process performed in step S12 (step S13). This process from steps S11 to S13 is repeated while the first arithmetic unit 102 is running.

[0026] [Examples of resource usage and worst-case resource usage] Figure 5 shows an example of resource usage information 103 in this example. Resource usage information 103 is information that the first arithmetic unit 102 is executing while the software is running, and it changes as it goes on during the arithmetic processing. The resource usage information 103 here includes CPU load information D12 when the first arithmetic unit 102 processes the existing software 101, and latency information D13 when the first arithmetic unit 102 processes the existing software 101.

[0027] The CPU load information D12 is shown as the CPU load during computation. For example, the CPU load for sensor fusion is 20%, for object tracking it's 25%, for local map creation it's 15%, for trajectory generation it's 12%, and for control value calculation it's 10%. Furthermore, the CPU load information D12 also includes the total CPU load information (82% in this case).

[0028] Latency information D13 shows the processing time during the calculation as latency. For example, the latency for sensor fusion is 40ms, the latency for object tracking is 40ms, the latency for local map creation is 40ms, the latency for trajectory generation is 10ms, and the latency for control value calculation is 10ms. Additionally, latency information D13 also includes information on the total latency (140ms in this case).

[0029] Figure 6 shows an example of worst-case resource usage information 106 obtained by monitoring by the resource monitoring unit 104. The worst-case resource usage information 106 includes information D14 on the worst-case CPU load when the first arithmetic unit 102 processes the existing software 101, and information D15 on the worst-case latency when the first arithmetic unit 102 processes the existing software 101.

[0030] These worst-case CPU load information D14 and worst-case latency information D15 are adjusted by the resource monitoring process shown in Figure 7 to be the worst-case (maximum) values ​​of the CPU load information D12 and latency information D13 shown in Figure 5. For example, the worst-case CPU load for object tracking in Figure 6 is 23%, and the worst-case CPU load for local map creation is 18%, resulting in a total worst-case CPU load of 83%, which differs from the CPU load shown in Figure 5.

[0031] [Resource monitoring process] Figure 7 is a flowchart showing the processing procedure performed by the resource monitoring unit 104 to obtain the information shown in Figures 5 and 6. First, the resource monitoring unit 104 obtains resource usage information 103 from the first calculation unit 102 (step S21). The resource monitoring unit 104 also obtains worst-case resource usage information 106 held by the resource information holding unit 105 (step S22).

[0032] Next, the resource monitoring unit 104 determines whether the resource values ​​for each software, as shown in the resource usage information 103 obtained in step S21, are greater than the values ​​of the worst-case resource usage information 106 obtained in step S22 (step S23). If the result of the determination in step S23 is greater than the value of the worst resource usage information 106 (YES in step S23), the resource monitoring unit 104 updates the value of the worst resource usage information 106 based on the value of the resource usage information 103 (step S24). Then, the resource monitoring unit 104 outputs the updated value of the worst resource usage information 106 and has the resource information holding unit 105 hold it (step S25).

[0033] Furthermore, if the determination result in step S23 is the same as or less than the value of the worst resource usage information 106 (NO in step S23), the resource monitoring unit 104 terminates the resource monitoring process without updating the value of the worst resource usage information. The resource monitoring unit 104 repeatedly executes the process shown in the flowchart in Figure 7.

[0034] Furthermore, if the worst-case resource usage information D14 and D15 shown in Figure 6 are set and the resource usage information D12 and D13 shown in Figure 5 are obtained, the CPU load rate of 25% for object tracking will be greater than the worst-case CPU load rate of 23%. Therefore, the resource monitoring unit 104 updates the worst-case CPU load rate to 25% in step S24.

[0035] [Resource usage of the new software] Figure 8 shows an example of the new software resource usage information 2 in this example. This scenario assumes that a software update will update the fusion processing within the existing software 101. Figure 8 shows the new software resource usage D16, which indicates that the newly updated Fusion feature will have a CPU load of 40% and a latency of 40ms.

[0036] [Update decision process] Figure 9 is a flowchart showing the processing procedure of the update determination unit 107. First, the update determination unit 107 obtains new software resource usage information 2 (step S31). This new software resource usage information 2 is obtained at any time when the update is to be initiated. This arbitrary timing for initiating the update can be, for example, when the vehicle is stopped, parked, charging (in the case of electric vehicles or rechargeable hybrid vehicles), or when a notification is received via the vehicle's user interface, thereby enabling appropriate updates that avoid performing updates while the vehicle is in motion.

[0037] Then, the update determination unit 107 obtains the worst resource usage information 106 stored in the resource information holding unit 105 (step S32). Next, the update determination unit 107 determines whether hardware resources will be exhausted if an update is performed with the new software by adding the value of the new software resource usage information 2 and the value of the worst-case resource usage information 106 for software other than the software to be updated (step S33).

[0038] For example, when the new software resource usage D16 shown in Figure 8 (Fusion CPU load rate 40%, latency 40ms), the Fusion values ​​in the worst-case resource usage information D14 and D15 shown in Figure 6 are updated with the new software resource usage D16 to calculate the total value. If this total value exceeds a certain CPU load rate (for example, 100% or a conservative 95%), or if the total latency exceeds the processing cycle, the update determination unit 107 determines that the hardware resources are exhausted. Note that the CPU load rate at which exhaustion is determined may be a value lower than 100%, such as a conservative 95% or 90%. Similarly, the latency may also be shorter than the processing cycle.

[0039] Then, if the decision in step S33 determines that hardware resources are depleted (YES in step S33), the update decision unit 107 outputs "NG" as update decision result information 108, indicating that the update cannot be performed (step S34). Furthermore, the update determination unit 107 outputs the layout change request information 109 (step S34) and terminates the update determination process.

[0040] Furthermore, if the decision in step S33 determines that hardware resources will not be exhausted (NO in step S33), the update decision unit 107 outputs "OK" as update decision result information 108, indicating that the update is possible (step S36), and terminates the update decision process.

[0041] Figure 10 shows an example of update judgment result information 108. Here, information D17 indicates an update judgment result of "NG". In the case of update judgment result information 108 shown in Figure 10, a request for a layout change is made. On the other hand, although not shown in the figure, if the update judgment result is "OK", the update is performed by the update execution unit 110.

[0042] [Update execution process] Figure 11 is a flowchart showing the processing procedure when the update execution unit 110 performs an update. The update execution unit 110 obtains update judgment result information 108 (step S41). The update execution unit 110 then determines whether the obtained judgment result is "OK" or not (step S42). If the judgment result in step S42 is "OK" (YES in step S42), the update execution unit 110 performs the update using the prepared new software (step S43) and terminates the update execution process. On the other hand, if the judgment result in step S42 is "NG" (NO in step S42), the update execution process terminates without performing the update.

[0043] [Example of a request for a change in layout] Figure 12 shows an example of the layout change request information 109 in this example. In the example in Figure 12, information D19 of the request for a change in placement lists the control value calculation software as the software whose placement will be changed, including CPU load percentage information (10%) and latency information (10ms) for the control value calculation software. The software whose placement is changed here is selected by the update determination unit 107, etc., to ensure that the CPU load and latency do not deplete hardware resources when the software is updated to the new software. In other words, the decision of which software to request to be moved to run on a different arithmetic unit is made by considering the latency between the first arithmetic unit 102 and the other arithmetic unit (second arithmetic unit 3) when the new software is executed.

[0044] [Processing to send a request for a change in layout] Figure 13 is a flowchart showing the processing procedure of the software deployment change request transmission / reception unit 111 in this example. First, the software relocation request transmission / reception unit 111 obtains the relocation request information 109 (step S51). Then, the software relocation request transmission / reception unit 111 outputs the obtained relocation request information 109 to the second calculation unit 3 of another vehicle control device (step S52), and ends the relocation request transmission process.

[0045] The second arithmetic unit 3, which receives the relocation request, has the same configuration as shown in Figure 1, and determines whether or not hardware resources will be exhausted when the software for which the relocation request was made is executed. If the second arithmetic unit 3 accepts the relocation request based on the result, it sends a reply to the software relocation request transmission / reception unit 111 indicating that the relocation request is OK. Furthermore, information (program data) of the software that performs the corresponding configuration change is also transferred from the vehicle control device 1 having the first arithmetic unit 102 to the vehicle control device having the second arithmetic unit 3. Alternatively, the software program data may be held in the storage unit of the vehicle control device 1 having the first arithmetic unit 102, and the vehicle control device having the second arithmetic unit 3 may read and execute the program data via the network NW.

[0046] [Example of software relocation] Figures 14 and 15 show the differences in software deployment before and after a software update. For example, as shown in Figure 14, the first calculation unit 102 is configured to execute the fusion SW1, object tracking SW2, local map creation SW3, trajectory generation SW4, and control value calculation SW5 software, while the second calculation unit 3 is configured to execute the other software.

[0047] In this state, suppose that Fusion SW1 is updated to Fusion SW1' with new software. If it is determined that the hardware resources of the first arithmetic unit 102 will be exhausted, the configuration is changed as shown in Figure 15. Specifically, as shown in Figure 15, the fusion SW1', object tracking SW2, local map creation SW3, and trajectory generation SW4 are executed in the first calculation unit 102. Then, the control value calculation SW5 is executed in the second calculation unit 3.

[0048] In the example shown in Figure 15, the new software, Fusion SW1', is executed by the first arithmetic unit 102. However, conversely, the new software, Fusion SW1', may be executed by the second arithmetic unit 3. Alternatively, all software related to the update may be executed by the second arithmetic unit 3. Furthermore, a portion of the new software, Fusion SW1', may be executed by the first arithmetic unit 102, and the remaining portion of Fusion SW1' may be executed by the second arithmetic unit 3. The decision of which software to execute in the second arithmetic unit 3 is made considering the latency between the first arithmetic unit 102 and the second arithmetic unit 3 when executing new software.

[0049] As described above, the vehicle control system in this example performs a process to change the software placement among multiple processing units while taking into account the latency during software processing. Therefore, even if a software update depletes the hardware resources of one processing unit, the update can be performed in cooperation with another processing unit, ensuring that the software update is performed appropriately.

[0050] Furthermore, since the update determination unit 107 determines whether or not to perform an update based on the CPU load rate and latency, resource usage can be determined relatively easily, and the determination of whether or not to perform an update can be performed easily with fewer calculations. Note that determining whether or not to perform an update based on the CPU load rate and latency is just one example; memory usage may also be added in addition to the CPU load rate and latency. By determining resource usage based on the CPU load rate, latency, and memory usage, it becomes possible to determine resource usage more accurately. Alternatively, the update determination unit 107 may determine resource usage based on one of the following: CPU load rate, latency, or memory usage. This allows only one numerical value to be used when determining resource usage, making it easier to determine resource usage.

[0051] Furthermore, as shown in Figure 15, by reconfiguring the system so that new software is processed by the first arithmetic unit 102 and some of the existing software is processed by the second arithmetic unit 3, it becomes possible to update the system while making effective use of the hardware resources of each arithmetic unit. In this case, the decision to change the placement can be made based on resource usage such as CPU load, latency, and memory usage, enabling the optimal placement change.

[0052] [Differentiation] The embodiments described so far are explained in detail for the purpose of clearly illustrating the present invention, and are not necessarily limited to those comprising all the configurations described. For example, the timing of the vehicle control device 1 performing an update can be determined at any time the vehicle desires. In other words, by determining at any time the vehicle desires whether the entire configuration of the new software can be updated in the first arithmetic unit 102, or whether a portion of the new software configuration should be moved to the second arithmetic unit 3, based on the worst-case resource usage information 106 (at least one of the central processing unit load rate, memory usage, and latency), which is part of the information held by the resource information holding unit 105, an appropriate update can be performed. The term "any timing" in this context refers to any of the following: when the vehicle is stopped, parked, charging (for electric vehicles or rechargeable hybrid vehicles), or when a notification is received via the vehicle's user interface. This allows for appropriate updates that avoid performing updates while the vehicle is in motion.

[0053] Furthermore, although the above-described embodiment example described a change in software placement between the processing unit of another vehicle control device located outside the vehicle control device, the placement of the processing unit is not limited to the above-described embodiment example, and the present invention is broadly applicable to systems equipped with multiple processing units. Furthermore, the configuration diagrams shown in Figures 1 and 2 only show control lines and information lines that are deemed necessary for explanation, and do not necessarily show all control lines and information lines in the actual product. In reality, it is reasonable to assume that almost all components are interconnected. Furthermore, the flowcharts shown in Figure 4 and subsequent figures represent just one example of the processing flow. If the processing result is the same, you may change the order of some processes or execute multiple processes simultaneously.

[0054] Furthermore, the processing performed by the vehicle control device of the present invention is carried out by the execution of a program (software). For example, an existing information processing device (computer) may be made to function as the vehicle control device of the present invention by implementing a program that performs the processing described in the embodiment example. In this case, the program information can be stored in memory or various recording media such as hard disks, SSDs (Solid State Drives), IC cards, SD card optical discs, etc. Furthermore, while the vehicle control system shown in Figure 2 is an example of a system composed of an information processing unit (computer) controlled by a CPU, some or all of the functions performed by the vehicle control system may be implemented by dedicated hardware such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit). [Explanation of Symbols]

[0055] 1, 1a, 1b, 1c, 1d… Vehicle control device, 2… Software resource usage information, 3… Second calculation unit, 11… CPU, 12… Work memory, 13… Storage unit, 14… Interface, 101… Existing software retention unit, 102… First calculation unit, 103… Resource usage information, 104… Resource monitoring unit, 105… Resource information retention unit, 106… Worst-case resource usage information, 107… Update judgment unit, 108… Update judgment result information, 109… Deployment change request information, 110… Update execution unit, 111… Software deployment change request transmission / reception unit

Claims

1. A vehicle control device that controls a vehicle, comprising a first arithmetic unit that executes existing software and a second arithmetic unit that executes software different from the existing software, Based on the execution status of the first arithmetic unit and the configuration of the newly implemented software, the update determination unit determines whether the existing software can be updated to the new software in the first arithmetic unit, An update execution unit that performs an update of the existing software according to the determination result of the update determination unit, A resource monitoring unit that monitors resource information used during the operation of the vehicle, A resource information holding unit that holds resource usage information based on the resource usage status provided by the resource monitoring unit, The system includes a software configuration change request transmission / reception unit that requests the second arithmetic unit to change the configuration of a part of the existing software or new software being executed by the first arithmetic unit, The update determination unit determines from the information held by the resource information holding unit whether the entire configuration of the new software can be updated in the first calculation unit, or whether a part of the configuration of the new software should be rearranged and placed in the second calculation unit. When the update determination unit determines that the arrangement change should be made to the second calculation unit, the software arrangement change request transmission / reception unit requests the second calculation unit, When the software deployment change request transmission / reception unit performs a deployment change on a portion of the configuration of the new software, it takes into account the latency between the first and second arithmetic units during the execution of the new software and determines which portion of the configuration of the new software or the existing software to be deployed to the second arithmetic unit. Vehicle control system.

2. The update determination unit determines whether the entire configuration of the new software can be updated in the first arithmetic unit, or whether a portion of the configuration of the new software should be rearranged in the second arithmetic unit, based on at least one of the load rate, memory usage, and latency of the central processing unit, which are part of the information held by the resource information holding unit. The vehicle control device according to claim 1.

3. The update determination unit determines, at any time the vehicle has the ability to update the entire configuration of the new software in the first arithmetic unit, or to rearrange a portion of the configuration of the new software in the second arithmetic unit, based on at least one of the load rate of the central processing unit, memory usage, and latency, which are part of the information held by the resource information holding unit. The vehicle control device according to claim 1.

4. The aforementioned arbitrary timing is any of the following timings: when the vehicle is stopped, when the vehicle is parked, when the vehicle is charging, or when a notification is sent via the vehicle's user interface. The vehicle control device according to claim 3.

5. When the update determination unit determines that it is necessary to relocate the software to the second arithmetic unit, it selects the software to be relocated to the second arithmetic unit from the existing software in a manner that optimizes the use of hardware resources. The vehicle control device according to claim 1.

6. The aforementioned hardware resources are at least one of the following: the load rate of the central processing unit, memory usage, and latency. The vehicle control device according to claim 5.

Images