VEHICLE CONTROL DEVICE

Abstract

A first arithmetic operation unit and a second arithmetic operation unit are created. Here, it is determined whether the entire structure of a new software can be updated in the first arithmetic operation unit, or whether a part of the structure of the new software should be modified so that it resides in the second arithmetic operation unit. This determination is based on information held by a resource information holding unit, the execution state in the first arithmetic operation unit, and the structure of the new software to be implemented.If a part of the structure of the new software is to be changed in the arrangement so that it is located in the second arithmetic operation unit, the part of the structure of the new software that is to be arranged in the second arithmetic operation unit is determined taking into account latencies in both arithmetic operation units.

Description

Technical area

[0001] The present invention relates to vehicle control devices. State of the art

[0002] There are techniques for updating the software implemented in vehicle control units (ECUs: electronic control units) after product releases. Electronic control systems for vehicles are increasingly upgraded year after year. Therefore, it is valuable to continuously implement the latest control software in vehicles by updating the software after product releases. However, such vehicle control units often have limited hardware resources, such as processor power and memory capacity. Therefore, software update methods that are able to utilize these limited hardware resources effectively are considered efficient.

[0003] For example, PTL1 describes a technique for updating software by arranging modules to be updated in dependency order according to software update information, further calculating the free capacity of a storage unit, and changing the order of updating the modules in such a way as to prevent a shortage of free capacity. This enables software updating even if the free capacity for storing the modules is, for example, smaller than the capacity of the software to be updated. Citation listPatent literature

[0004] PTL1: JP 2007-213189 A Summary of the inventionTechnical problem

[0005] With the technique described in PTL1, it is possible to update software by changing the order of module updates, even when the free capacity of the memory unit for storing modules is small. However, it is impossible to update software beyond the memory capacity of a system. This has induced the following problem. That is, in a system with a long product life, such as a system to be used in units of 10 years, for example, the limit of available free capacity is reached, making it impossible to update software due to the exhaustion of the hardware resource.

[0006] It is an object of the present invention to provide a vehicle control device that enables software updates even when hardware resources may be exhausted. Solution to the problem

[0007] To solve the aforementioned problem, the structures described in the claims are adopted, for example.

[0008] The present application includes several means of solving the aforementioned problem, and one example is as follows.

[0009] A first arithmetic operation unit designed to execute existing software and a second arithmetic operation unit designed to execute software different from the existing software applied to a vehicle control device for controlling a vehicle are provided.

[0010] Furthermore, the vehicle control device comprises: an update determination unit configured to determine whether the existing software can be updated to new software in the first arithmetic operation unit based on a state of execution in the first arithmetic operation unit and a structure of the new software to be newly implemented; an update execution unit configured to execute the update of the existing software according to a result of the determination by the update determination unit; a resource monitoring unit designed to monitor information about a resource used during operation of the vehicle; a resource information holding unit configured to hold information of the level of resource usage based on a resource usage status provided by the resource monitoring unit; and a software arrangement change request transmission / reception unit configured to transmit a request to the second arithmetic operation unit for an arrangement change of a part of the structure of the new software or the existing software executed by the first arithmetic operation unit.

[0011] Furthermore, the update determination unit is designed to determine whether the entire structure of the new software can be updated in the first arithmetic operation unit, or whether part of the structure of the new software should be modified in the arrangement so that it is located in the second arithmetic operation unit, based on information held by the resource information holding unit, and If the update determination unit determines that part of the structure of the new software should be changed in the arrangement so that it is located in the second arithmetic operation unit, the software arrangement change request send / receive unit makes a request to the second arithmetic operation unit, and when the part of the structure of the new software in the arrangement is changed, the software arrangement change request transmission / reception unit determines the part of the structure of the new software or the existing software to be arranged in the second arithmetic operation unit, considering latencies in the first arithmetic operation unit and the second arithmetic operation unit that occur during the execution of the new software. Advantageous effects of the invention

[0012] According to the present invention, it is possible to update software by changing the arrangement of the software among several arithmetic operation units, taking into account the latency during processing of the software to achieve the control of the vehicle, even if the hardware resources may be exhausted.

[0013] Problems, structures and effects other than those described above will be clarified by the following description of embodiments. Brief description of the drawings [ Fig. 1] Fig. 1 is a block diagram illustrating an overall structure of a vehicle control device according to an embodiment of the present invention. [ Fig. 2] Fig. 2 is a structural view illustrating an example of an arrangement of vehicle control devices within a vehicle according to an embodiment of the present invention. [ Fig. 3] Fig. 3 is a view illustrating an example of existing software to be subjected to arithmetic processing according to an embodiment of the present invention. [ Fig. 4] Fig. Figure 4 is a flowchart representing a processing procedure in a first arithmetic operation unit according to an embodiment of the present invention. [ Fig. 5] Fig. Figure 5 is a view that represents an example of a level of resource utilization according to an embodiment of the present invention. [ Fig. 6] Fig. Figure 6 is a view that represents an example of a worst level of resource utilization according to an embodiment of the present invention. [ Fig. 7] Fig. 7 is a flowchart illustrating a processing procedure in a resource monitoring unit according to an embodiment of the present invention. [ Fig. 8] Fig. 8 is a view illustrating an example of a level of resource utilization of new software according to an embodiment of the present invention. [ Fig. 9] Fig. 9 is a flowchart illustrating a processing procedure in an update determination unit according to an embodiment of the present invention. [ Fig. 10] Fig. 10 is a view illustrating an example of the result of determination according to an embodiment of the present invention. [ Fig. 11] Fig. 11 is a flowchart illustrating a processing procedure in an update execution unit according to an embodiment of the present invention. [ Fig. 12] Fig. Figure 12 is a view that presents an example of arrangement change request information 109 according to an embodiment of the present invention. [ Fig. 13] Fig. Figure 13 is a flowchart representing a processing procedure in a software configuration change request send / receive unit according to an embodiment of the present invention. [ Fig. 14] Fig. Figure 14 is a view that shows an example of a software arrangement before the software is updated according to an embodiment of the present invention. [ Fig. 15] Fig. Figure 15 is a view that shows an example of the software arrangement after updating the software according to an embodiment of the present invention. Description of embodiments

[0014] An embodiment (hereinafter referred to as the “present example”) of the present invention is described below with reference to the accompanying drawings. [The structure of the vehicle control device]

[0015] Fig. Figure 1 is a block diagram that represents an entire functional structure for updating software in a vehicle control device 1 in the present example.

[0016] The vehicle control device 1 in the present example is a device that is mounted on a vehicle and is designed to control its driving and the like. As with reference to Fig. As described in Figure 2, a plurality of vehicle control devices 1 are installed in a vehicle, and the plurality of vehicle control devices 1 are connected to each other through a network. Each vehicle control device 1 is structured as a computer configured to execute software implemented therein, including an arithmetic operation unit, thereby performing operations for controlling the vehicle.

[0017] As in Fig. As shown in Figure 1, in the vehicle control device 1, an existing software holding unit 101 holds software (existing software) for performing operations. The existing software can be updated with new software supplied from the outside. Here, the new software is used to update at least part of the existing software. In the drawings, the software is abbreviated as "SW."

[0018] When the vehicle control unit 1 updates its existing software to the new software, information 2 regarding the level of resource utilization via the new software is supplied to the vehicle control unit 1. This information 2 regarding the level of resource utilization via the new software is acquired externally along with the new software, but can also be generated within the vehicle at the time the new software is received.

[0019] The structure of the vehicle control device 1 shown in Fig. Figure 1 shows a structure required when the vehicle control unit 1 updates the existing software to the new software. The structures of the respective units shown in Fig. 1 are structured by the software for operating the vehicle control device 1. Likewise, respective pieces of information shown in Fig. The data shown in section 1 are captured by the same software. Furthermore, the processing takes place within the respective structures shown in Fig. 1 are shown, with reference to Fig. 3 and the subsequent drawings are described in more detail.

[0020] First, the overall structure of the vehicle control device 1, which is located in Fig. The vehicle control device 1 is described as shown in Figure 1. It comprises the holding unit 101 for existing software, a first arithmetic operation unit 102, information 103 on the level of resource utilization, a resource monitoring unit 104, a resource information holding unit 105, and information 106 on the worst level of resource utilization.

[0021] Furthermore, the vehicle control device 1 comprises an update determination unit 107, update determination result information 108, order change request information 109, an update execution unit 110, and a software order change request send / receive unit 111. Moreover, the resource utilization level information 103, the update determination result information 108, and the order change request information 109 are held in their respective corresponding holding units.

[0022] Furthermore, a second arithmetic operation unit 3 is provided outside the vehicle control device 1, which is located in Fig. 1. The second arithmetic operation unit 3 is provided in a plurality of other vehicle control devices provided in the vehicle. The structures of the plurality of vehicle control devices provided in the vehicle will be described later with reference to Fig. 2 described.

[0023] The existing software holding unit 101 holds software to be executed by the vehicle control unit 1. The existing software held by the existing software holding unit 101 is executed by the first arithmetic operation unit 102.

[0024] The level of resource utilization during the execution of the software by the first arithmetic operation unit 102 is measured in the vehicle control device 1 and the information 103 of the measured level of resource utilization is stored.

[0025] The information 103 regarding the level of resource utilization is transmitted to the resource monitoring unit 104 and monitored by the resource monitoring unit 104.

[0026] The result of the monitoring by the resource monitoring unit 104 is stored in the resource information holding unit 105.

[0027] The resource information holding unit 105 has the information 106 of the worst level of resource utilization as a part of the information held therein.

[0028] The update determination unit 107 determines whether it is possible to execute software in the first arithmetic operation unit 102, based on information 2 regarding the level of resource utilization for the new software and information 106 regarding the lowest level of resource utilization held in the resource information holding unit 105. This determines whether an update to the new software is possible. The update determination unit 107 then generates the update determination result information 108 based on this determination of whether an update to the new software is possible.

[0029] The update execution unit 110 updates the existing software held in the holding unit 101 for existing software to the new software based on the update determination result information 108.

[0030] If the update determination unit 107 determines that it is impossible to perform the update to the new software in the first arithmetic operation unit 102, the update determination unit 107 further generates order change request information 109. The order change request information 109 generated by the update determination unit 107 is transmitted by the software order change request send / receive unit 111 to the second arithmetic operation unit 3, which is contained in another vehicle control device.

[0031] The second arithmetic operation unit 3, which has received the order change request information 109, modifies the software to be executed therein based on the order change request information 109. At this time, the modification of the software includes not only the execution of the new software, but also the execution of at least part of the existing software, which is held in the holding unit 101 for existing software.

[0032] Furthermore, the vehicle control device with the second arithmetic operation unit 3 also has a similar structure to that of the vehicle control device 1, which is in Fig. As shown in Figure 1, this vehicle control unit determines whether it is possible to execute the software specified as being to be modified in the configuration. If it is possible to execute the software, this vehicle control unit performs the configuration modification based on the configuration modification request. [The structure of the arrangement of multiple vehicle control devices]

[0033] Fig. Figure 2 presents an example in which several vehicle control units are arranged in a vehicle M. Here, an example is shown in which four vehicle control units are arranged: a first vehicle control unit 1a, a second vehicle control unit 1b, a third vehicle control unit 1c, and a fourth vehicle control unit 1d. The respective vehicle control units 1a to 1d are interconnected by a network NW and are capable of sending and receiving data to and from each other. Furthermore, each of the vehicle control units 1a to 1d connected to the network NW includes a transmit / receive unit or a communication interface for exchanging data with the outside of the vehicle and the like, and is capable of acquiring information such as new software from the outside.

[0034] Each of the vehicle control devices 1a to 1d comprises an arithmetic operation unit (that of the arithmetic operation unit 102 in Fig. 1 corresponds) and furthermore shows the in Fig. The structure shown in section 1 is used to update the software to be executed by the arithmetic operation unit.

[0035] Here, the hardware structure of each of the vehicle control devices 1a to 1d is described. The first vehicle control device 1a, for example, comprises a central processing unit (CPU) 11, a working memory 12, a storage unit 13, and an interface (I / F) 14, which are interconnected to transfer data to and from each other.

[0036] The CPU 11 executes 12 programs (software) in the main memory, which are stored in the memory unit 13. Consequently, the respective processing units that are in Fig. The 1 are represented, structured in 12 working memory.

[0037] Memory unit 13 stores programs for controlling the vehicle and also stores images, control data, and the like. The programs stored in memory unit 13 also include a program for performing a software update process.

[0038] Interface 14 performs processing to input detection data from a camera and various sensors, and processing to output data for controlling the vehicle.

[0039] The other vehicle control devices 1b to 1d, as well as the first vehicle control device, also have the same structure as that of the first vehicle control device 1a.

[0040] In the following description, vehicle control device 1 refers to any one of the several vehicle control devices 1a to 1d. [Example of software that undergoes arithmetic processing by the vehicle control unit]

[0041] Fig. Figure 3 is a view that presents an example of data D11 with respect to processes of the existing software 101, which is to be subjected to arithmetic processing in the vehicle control device 1, and furthermore with respect to cycle information about it.

[0042] Here, sensor fusion, object tracking, local map generation, path generation and control value calculation are presented as examples of processes of the existing software 101, which is to be subjected to arithmetic processing in the vehicle control device 1.

[0043] Each process of the tax software has a task that specifies a cycle of arithmetic processing. In the example of data D11 in Fig. For example, in step 3, arithmetic processing for sensor fusion, object tracking, and local map generation is performed in a 40 ms cycle. Furthermore, arithmetic processing for path generation and control value calculation is performed in a 10 ms cycle. [Arithmetic processing in the arithmetic operation unit]

[0044] Fig. 4 is a flowchart that represents a processing procedure in the first arithmetic operation unit 102.

[0045] First, the first arithmetic operation unit 102 captures the existing software 101 (step S11). Then, the first arithmetic operation unit 102 performs arithmetic processing on the captured software, thereby executing the control and the like based on the software (step S12).

[0046] Here, the first arithmetic operation unit 102 outputs information 103 about the level of resource utilization during arithmetic processing in step S12 (step S13). This processing in steps S11 to S13 is repeated during operations of the first arithmetic operation unit 102. [Examples of the level of resource utilization and the worst level of resource utilization]

[0047] Fig. Figure 5 shows an example of the resource utilization level information (103) in the present example. The resource utilization level information (103) is information captured by the first arithmetic operation unit (102) during software execution and changes at all times during arithmetic processing.

[0048] In this case, the resource usage level information 103 includes information D12 about the CPU load factor when the first arithmetic operation unit 102 performs arithmetic processing on the existing software 101, and information D13 about the latency when the first arithmetic operation unit 102 performs arithmetic processing on the existing software 101.

[0049] The information D12 about the CPU load factor is given as CPU load factors during arithmetic operations.

[0050] For example, here the CPU load factor of sensor fusion is 20%, the CPU load factor of object tracking is 25%, the CPU load factor of local map generation is 15%, the CPU load factor of trajectory generation is 12%, and the CPU load factor of control value calculation is 10%.

[0051] The information D12 concerning the CPU load factor also includes information about the total CPU load factor (82% in this case), which is the sum of the CPU load factors mentioned above.

[0052] In the information D13 about latency, the processing times during arithmetic operations are specified as latencies.

[0053] For example, the latency of sensor fusion is 40 ms, the latency of object tracking is 40 ms, the latency of generating a local map is 40 ms, the latency of path generation is 10 ms, and the latency of control value calculation is 10 ms.

[0054] The information D13 regarding latency also includes information about the total latency (140 ms in this case), which is the sum of the latencies mentioned above.

[0055] Fig. 6 is views that represent an example of the information 106 of the worst level of resource utilization that resulted from monitoring by the resource monitoring unit 104.

[0056] The information 106 about the worst level of resource utilization includes information D14 about the worst CPU load factor when the first arithmetic operation unit 102 performs arithmetic processing on the existing software 101, and information D15 about the worst latency when the first arithmetic operation unit 102 performs arithmetic processing on the existing software 101.

[0057] The information D14 about the worst CPU load factor and the information D15 about the worst latency are derived as the worst values ​​(maximum values) from the values ​​that are recorded as CPU load factor information D12 and latency information D13, which are recorded in Fig. 5 are shown, obtained through resource monitoring processing, which is described in the subsequent Fig. The figure shown in 7 is fixed.

[0058] In Fig. For example, the worst CPU load factor for object tracking is 23%, the worst CPU load factor for generating a local map is 18%, and the overall worst CPU load factor is 83%, which is derived from the CPU load factors that are in Fig. The 5 shown are different. [Resource monitoring processing]

[0059] Fig. 7 is a flowchart that describes a processing procedure in resource monitoring unit 104 to obtain the in Fig. 5 and Fig. The information shown is presented in section 6.

[0060] First, the resource monitoring unit 104 records the information 103 about the level of resource utilization from the first arithmetic operation unit 102 (step S21). Furthermore, the resource monitoring unit 104 records the information 106 about the lowest level of resource utilization held by the resource information holding unit 105 (step S22).

[0061] Next, the resource monitoring unit 104 determines whether the value of the resource for each software, as indicated by the resource utilization level information 103 captured in step S21, is greater than the value in the worst resource utilization level information 106 captured in step S22 (step S23).

[0062] If the determination in step S23 shows that the value of the resource for each software is greater than the value in information 106 of the worst level of resource utilization (YES in step S23), the resource monitoring unit 104 updates the value in information 106 of the worst level of resource utilization based on the value in information 103 of the level of resource utilization (step S24). Then, the resource monitoring unit 104 outputs the updated value in information 106 of the worst level of resource utilization and causes the resource information holding unit 105 to hold it (step S25).

[0063] If the determination in step S23 shows that the value of the resource for each software is equal to or less than the value in the information 106 of the worst level of resource utilization (NO in step S23), the resource monitoring unit 104 terminates the resource monitoring processing without updating the value in the information of the worst level of resource utilization.

[0064] Resource monitoring unit 104 processes the schedule of Fig. 7 repeatedly.

[0065] Furthermore, in a case where information D14 and D15 indicate the worst level of resource utilization, which is in Fig. 6 are shown, will be determined when the information from D12 and D13 indicates the level of resource utilization, which is shown in Fig. 5, the object tracking CPU load factor is 25% and has a value greater than the worst CPU load factor, which is 23%. Consequently, the resource monitoring unit 104 updates the worst CPU load factor to 25% in step S24. [The level of resource usage of the new software]

[0066] Fig. Figure 8 is a view that provides an example of the information 2 regarding the level of resource usage via the new software in the present example.

[0067] It is assumed here that the fusion process in the existing software 101 will be updated by updating the software.

[0068] Regarding the merger function that needs to be updated, the level D16 indicates the resource usage of the new software, which is in Fig. Figure 8 shows that the updated Fusion has a CPU load factor of 40% and a latency of 40 ms. [Update determination processing]

[0069] Fig. 9 is a flowchart that represents a processing procedure in the update determination unit 107.

[0070] First, the update determination unit 107 collects the resource usage information (step S31) for the new software. This resource usage information is then collected at any time to initiate the update. This "any time" could be, for example, when the vehicle is stopped, parked, charging (in the case of an electric or plug-in hybrid vehicle), or when the vehicle's user interface sends a notification, thus allowing for updates to be performed at times other than while the vehicle is in motion.

[0071] Then the update determination unit 107 records the information 106 of the worst level of resource utilization held in the resource information holding unit 105 (step S32).

[0072] Next, the update determination unit 107 determines whether the hardware resource will be exhausted when an update is performed with the new software by adding the values ​​in information 2 of the level of resource utilization via the new software to the values ​​for the other software as the software to be updated in information 106 of the worst level of resource utilization (step S33).

[0073] In the case of the level D16, resource usage of the new software, which is in Fig. As shown in Figure 8 (the CPU load factor of the fusion is 40% and the fusion latency is 40 ms), the update determination unit 107, for example, updates the values ​​for the fusion in information D14 and D15 of the worst level of resource utilization, which is shown in Fig. Figure 6 shows the resource usage of the new software, with level D16. The update determination unit 107 further determines the total value of these values. If the total value exceeds a certain CPU load factor (for example, 100% or 95% with a tolerance), or if the total sum of the latencies exceeds the processing cycle, the update determination unit 107 determines that the hardware resource is exhausted. The CPU load factor for determining that the hardware resource is exhausted can be a value lower than 100%, such as 95% or 90% with a tolerance. Similarly, the latency for this determination can be a time period shorter than the processing cycle.

[0074] If the determination in step S33 determines that the hardware resource is exhausted (YES in step S33), the update determination unit 107 further outputs “NG”, indicating that the update is not possible, as update determination result information 108 (step S34).

[0075] Further, the update determination unit 107 outputs arrangement change request information 109 (step S34) and ends the update determination processing.

[0076] If the determination in step S33 determines that the hardware resource is not exhausted (NO in step S33), the update determination unit 107 further outputs “OK”, indicating that the update is possible, as update determination result information 108 (step S36) and terminates the update determination processing.

[0077] Fig. Figure 10 presents an example of the update determination result information 108. Here, information D17 about the result of the update determination of "NG" is shown. In the case of the update determination result information 108, which is in Fig. When item 10 is shown, an order change request is executed. However, although not shown, in a case where the result of the update determination is "OK", the update execution unit 110 performs the update. [Update execution processing]

[0078] Fig. 11 is a flowchart showing a processing procedure when the update execution unit 110 executes the update.

[0079] The update execution unit 110 acquires the update determination result information 108 (step S41). Then, the update execution unit 110 determines whether the acquired result of the determination is "OK" or not (step S42). If step S42 determines that the result of the determination is "OK" (YES in step S42), the update execution unit 110 executes the update with the prepared new software (step S43) and terminates the update execution processing. If, on the other hand, step S42 determines that the result of the determination is "NG" (NO in step S42), the update execution unit 110 terminates the update execution processing without executing the update. [Example of a change order request]

[0080] Fig. 12 is a view showing an example of the arrangement change request information 109 in the present example.

[0081] The order change request information D19 in the example of Fig. 12 designate the tax value calculation as software to be modified in the arrangement, including CPU load factor information (10%) and latency information (10 ms) about the software and the tax value calculation.

[0082] Furthermore, the software to be changed in the arrangement is selected by the update determination unit 107 or the like to prevent hardware resource exhaustion with regard to CPU load and latency when the update to the new software is performed. Specifically, it is determined which software should be requested to be changed in the arrangement so that it is executed by a different arithmetic operation unit, taking into account the latencies in the first arithmetic operation unit 102 and another arithmetic operation unit (the second arithmetic operation unit 3) that may occur during the execution of the new software. [Processing to transmit an order change request]

[0083] Fig. 13 is a flowchart that represents a processing procedure in the software order change request send / receive unit 111 in the present example.

[0084] First, the software arrangement change request transmission / reception unit 111 acquires the arrangement change request information 109 (step S51). Then, the software arrangement change request transmission / reception unit 111 outputs the acquired arrangement change request information 109 to the second arithmetic operation unit 3 in another vehicle control device (step S52) and terminates the processing for transmitting the arrangement change request.

[0085] Furthermore, the second arithmetic operation unit 3, which received the order change request, has a similar structure to the structure in Fig. 1 and consequently determines whether the hardware resource will be exhausted or not when it executes the software that is being requested to change the arrangement. As a result, if the second arithmetic operation unit 3 accepts the arrangement change request, then the second arithmetic operation unit 3 sends a response "the change request is OK" to the software arrangement change request send / receive unit 111.

[0086] Furthermore, information (program data) about the corresponding software to be modified in the arrangement is also transferred from the vehicle control unit 1 with the first arithmetic operation unit 102 to the vehicle control unit with the second arithmetic operation unit 3. Alternatively, the program data of the software can be stored in a memory unit in the vehicle control unit 1 with the first arithmetic operation unit 102, and the vehicle control unit with the second arithmetic operation unit 3 can read and execute the corresponding program data via the network NW. [Example of software layout change]

[0087] Fig. 14 and Fig. 15 are views showing the difference of software arrangement between before and after the software update.

[0088] As in Fig. 14, for example, it is assumed that the first arithmetic operation unit 102 is structured to execute the respective pieces of software for fusion SW1, object tracking SW2, local map generation SW3, trajectory generation SW4, and control value calculation SW5, while the second arithmetic operation unit 3 is structured to execute the other software.

[0089] For example, it is assumed that Fusion SW1 was upgraded to Fusion SW1' as new software in this state. In this case, if it is determined that the hardware resource of the first arithmetic operation unit 102 is exhausted in this state, the arrangement is changed as shown in Fig. 15 shown.

[0090] As in Fig. As shown in Figure 15, the first arithmetic operation unit 102 performs the fusion SW1', the object tracking SW2, the generation of a local map SW3, and the path generation SW4. Furthermore, the control value calculation SW5 is performed by the second arithmetic operation unit 3.

[0091] In the example of Fig. In section 15, the fusion SW1' is implemented as new software by the first arithmetic operation unit 102. However, the fusion SW1' can also be executed as new software by the second arithmetic operation unit 3. Alternatively, the entire software update can be executed by the second arithmetic operation unit 3. Part of the fusion SW1' as new software can also be implemented by the first arithmetic operation unit 102, while the remaining part of the fusion SW1' can be executed by the second arithmetic operation unit 3.

[0092] It is determined which software should be executed by the second arithmetic operation unit 3, taking into account the latencies in the first arithmetic operation unit 102 and the second arithmetic operation unit 3 that may occur during the execution of the new software.

[0093] By performing the processing described above, the vehicle control unit in this example is caused to execute the software configuration change process across multiple arithmetic operation units, while taking into account the latency during software processing. Therefore, even if the hardware resource in one arithmetic operation unit becomes exhausted due to the software update, the update is performed in conjunction with another arithmetic operation unit, thus enabling the software to be updated appropriately.

[0094] Furthermore, the update determination unit 107 determines whether an update is possible based on the CPU load factor and latency. This makes it relatively easy to determine the resource utilization state, which advantageously allows for the simple determination of whether an update is possible with a small number of arithmetic operations. Incidentally, determining whether an update is possible based on the CPU load factor and latency is just one example. It is also possible to perform the determination based on the amount of memory usage in addition to the CPU load factor and latency. By determining the resource utilization state based on the CPU load factor, latency, and the amount of memory usage, it is possible to determine the resource utilization state more accurately.

[0095] Alternatively, the Update Determination Unit 107 can determine the resource utilization state based on any one of the CPU load factor, latency, and the amount of memory usage. This allows for the evaluation of only one numerical value when determining the resource utilization state, thus simplifying its assessment.

[0096] As in Fig. Further, as shown in Figure 15, the structure is changed so that the first arithmetic operation unit 102 implements the new software, while the second arithmetic operation unit 3 implements part of the existing software. This enables updating by effectively utilizing the hardware resources of the respective arithmetic operation units. In this case, the determination of the layout change can also be made based on the resource usage status, such as the CPU load factor, latency, and the amount of memory usage, enabling optimal layout change. [Examples of modifications]

[0097] Furthermore, the embodiment mentioned above has been described in detail for the purpose of explaining the present invention in such a way as to facilitate understanding of the present invention, and the present invention is not necessarily limited to structures with all the described structures.

[0098] Regarding the timing at which the vehicle control device 1 performs the update, for example, the update may be performed at any time of the vehicle. Namely, it is possible to determine whether the entire structure of the new software can be updated with the first arithmetic operation unit 102 or whether part of the structure of the new software should be changed in the arrangement to be located in the second arithmetic operation unit 3, based on the information 106 of the worst level of resource usage (at least any of the load factor of the central processing unit, the level of memory usage, and the latency) that is part of the information held by the resource information holding unit 105 at any time of the vehicle. This enables appropriate updating.

[0099] Here, the "any point in time" of the vehicle can be, for example, any time during a stop, while parked, while charging (in the case of an electric vehicle or a plug-in hybrid vehicle), or at the time of a notification from the vehicle's user interface. This allows for suitable updates during periods other than while the vehicle is in motion.

[0100] Furthermore, in the above-mentioned embodiment, an example was described in which the software in the arrangement is changed to be located in the arithmetic operation unit in another vehicle control device outside the vehicle control device. However, the location where the arithmetic operation unit is arranged is not limited to that in the above-mentioned embodiment, and the present invention can be widely applied to systems including multiple arithmetic operation units.

[0101] Furthermore, the structural views in Fig. 1 and Fig. Two control and information lines are shown that are considered necessary for the description; not all control and information lines required for products are shown. It can be assumed that almost all structures are actually interconnected.

[0102] Furthermore, the processing procedures of the in Fig. The process flowcharts shown in section 4 and the subsequent drawings are merely examples. The processing sequence can be partially changed, or multiple processes can be performed simultaneously, as long as the same result can be obtained.

[0103] Furthermore, the processing carried out in the vehicle control unit according to the present invention is performed by executing a program (software). A program for performing the processing described in the embodiment can, for example, be implemented in an existing information processing device (computer), so that the existing information processing device can function as a vehicle control unit according to the present invention. In this case, information about the program can be stored in any of various types of recording media, such as a memory, a hard disk or solid-state drive (SSD), an IC card, an SD card, and an optical disc.

[0104] Furthermore, in the Fig.Figure 2 illustrates an example where the vehicle control unit is structured by an information processing device (computer) operating under the control of a CPU. However, some or all of the functions performed by the vehicle control unit can be implemented by dedicated hardware such as a user-programmable logic array (FPGA) or an application-specific integrated circuit (ASIC). List of reference symbols 1, 1a, 1b, 1c, 1d Vehicle control device 2 Information on the level of resource usage via the software 3 second arithmetic operation unit 11 CPU 12 RAM 13 Storage unit 14 Interface 101 Holding unit for existing software 102 first arithmetic operation unit 103 Information on the level of resource use 104 Resource Monitoring Unit 105 Resource Information Holding Unit 106 Information of the worst level of resource use 107 Update determination unit 108 Update determination result information 109 Order change request information 110 Update Execution Unit 111 Software arrangement change request sending / receiving unit QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] JP 2007-213189 A

[0004]

Claims

[1] A vehicle control device having a first arithmetic operation unit configured to execute existing software and a second arithmetic operation unit configured to execute software different from the existing software to control a vehicle, the vehicle control device comprising: an update determination unit configured to determine whether the existing software in the first arithmetic operation unit can be updated to new software based on a state of execution in the first arithmetic operation unit and a structure of the new software to be newly implemented; an update execution unit configured to execute the update of the existing software according to a result of the determination by the update determination unit; a resource monitoring unit configured to monitor information about a resource used during operation of the vehicle; a resource information holding unit configured to hold information of the level of resource usage based on a resource usage status provided by the resource monitoring unit; and a software arrangement change request transmission / reception unit configured to transmit a request to the second arithmetic operation unit for an arrangement change of a part of the structure of the new software or the existing software executed by the first arithmetic operation unit; wherein the update determination unit is configured to determine whether the entire structure of the new software in the first arithmetic operation unit can be updated or a part of the structure of the new software in the arrangement should be changed to be located in the second arithmetic operation unit, on the basis of information held by the resource information holding unit, and when the update determination unit determines that a part of the structure of the new software in the arrangement should be changed so that it is located in the second arithmetic operation unit, the software arrangement change request transmission / reception unit makes a request to the second arithmetic operation unit, and when the part of the structure of the new software in the arrangement is changed, the software arrangement change request transmission / reception unit determines the part of the structure of the new software or the existing software to be arranged in the second arithmetic operation unit in consideration of latencies in the first arithmetic operation unit and the second arithmetic operation unit that occur during the execution of the new software. [2] The vehicle control device according to claim 1, wherein the update determination unit is configured to determine whether the entire structure of the new software in the first arithmetic operation unit can be updated or a part of the structure of the new software in the arrangement should be changed to be located in the second arithmetic operation unit, based on a load factor of a central processing unit, a level of memory usage, and / or a latency, which are a part of the information held by the resource information holding unit. [3] The vehicle control device according to claim 1, wherein the update determination unit is configured to determine whether the entire structure of the new software in the first arithmetic operation unit can be updated or a part of the structure of the new software should be changed in the arrangement to be located in the second arithmetic operation unit, based on a load factor of a central processing unit, a level of memory usage, and / or a latency, which are a part of the information held by the resource information holding unit, at any time of the vehicle. [4] The vehicle control device according to claim 3, wherein the arbitrary time is any one of a time during the stop of the vehicle, a time during the parking of the vehicle, a time during the charging of the vehicle, or a time at the time of notification from a user interface of the vehicle. [5] The vehicle control device according to claim 1, wherein, when the update determination unit determines that a part of the structure of the new software in the arrangement should be changed to be located in the second arithmetic operation unit, the software to be changed in the arrangement to be located in the second operation unit is selected from the existing software in such a manner that an amount of utilization of the hardware resource is optimized. [6] The vehicle control device according to claim 5, wherein the hardware resource is a load factor of a central processing unit, an amount of memory usage, and / or a latency.

Images