Vehicle control device and sensor data processing method

Abstract

In this vehicle control device, a processing period including a reference time required for processing each task included in a processing sequence, and including a margin time, is allocated to the processing sequence, which includes at least processing of a preceding task in one semiconductor chip and processing of a subsequent task in another semiconductor chip that utilizes the processing result of the preceding task. A processor of the other semiconductor chip obtains a remaining time that can be used for processing of the subsequent task in the processing period on the basis of an execution time required for processing the preceding task in the one semiconductor chip and the margin time, and determines at least one of the start time and the processing content of the subsequent task on the basis of the remaining time.

Description

Vehicle control device and sensor data processing method

[0001] The present invention relates to a vehicle control device that uses detection results from sensors and a sensor data processing method.

[0002] An existing technology for absorbing delays by switching the processing order in a vehicle control device made up of multiple devices is described in Patent Document 1. Patent Document 1 describes a method for absorbing delays in one of multiple tasks that can be executed in parallel by making subsequent tasks that use the results of those tasks event-driven, calculating the remaining time from the event reception time to the deadline, and switching the processing order while meeting the deadline.

[0003] According to the method described in Patent Document 1, when there is a delay in the output from the first ECU, a process that uses only the processing results of the second ECU is executed first, and then a process that uses the processing results from the first ECU is executed, thereby absorbing the delay that occurs in the first ECU.

[0004] JP 2023-36264 A

[0005] However, in the technology described in Patent Document 1, a process using the processing result of the first ECU is executed when the execution of a process using the processing result of the second ECU is completed, which poses a problem of absorbing delays when there is slack time remaining in the entire system.

[0006] The present invention has been made in consideration of the above circumstances, and aims to propose a vehicle control device and a sensor data processing method that can absorb delays by taking into account the slack time of the entire system.

[0007] In order to solve the above problem, one embodiment of the present invention provides a vehicle control device that includes multiple semiconductor chips each having a processor that processes sensor data received from a sensor, a non-volatile memory, and a volatile memory, and a processing period that includes a reference time and a slack time required for processing each task included in a processing sequence that includes at least processing of a preceding task in one semiconductor chip and processing of a subsequent task in another semiconductor chip that uses the processing result of the preceding task is assigned, and the processor of the other semiconductor chip calculates the remaining time available for processing the subsequent task in the processing period based on the execution time and slack time required for processing the preceding task in the one semiconductor chip, and determines at least one of the start time or processing content of the subsequent task based on the remaining time.

[0008] According to at least one aspect of the present invention, it is possible to absorb delays by taking into account the slack time of the entire system. Problems, configurations, and effects other than those described above will become apparent from the following description of the preferred embodiment of the present invention.

[0009] 1 is a diagram showing an example of the configuration of a vehicle control device according to a first embodiment of the present invention. FIG. 2 is a block diagram showing an example of the hardware configuration of a computer included in a semiconductor chip according to the first embodiment of the present invention. FIG. 3 is a diagram showing an example of the configuration of functional blocks and an example of the overall operation flow of a vehicle control device according to the first embodiment of the present invention. FIG. 4 is a diagram showing an example of the operation of functions in each semiconductor chip of the vehicle control device according to the first embodiment of the present invention. FIG. 5 is a diagram showing examples of average execution time and worst-case execution time for each function. FIG. 6 is a diagram showing a general operation example using a shared margin when task execution is delayed. FIG. 7 is a diagram showing an example in which the result of a preceding task is not used to meet a deadline in the first embodiment of the present invention. FIG. 8 is a diagram showing an example of function selection taking into account the remaining time in a semiconductor chip that executes processing of a preceding task according to the second embodiment of the present invention. FIG. 9 is a diagram showing a first example of a time synchronization error between semiconductor chips according to a third embodiment of the present invention. (Addition) FIG. 10 is a diagram showing a second example of a time synchronization error between semiconductor chips according to the third embodiment of the present invention. FIG. 11 is a diagram showing an example of allocating a shared margin to subsequent processing in the fourth embodiment of the present invention. FIG. 12 is a diagram showing an example in which the preceding processing completes execution within the time limit in the fourth embodiment of the present invention.

[0010] Hereinafter, examples of modes for carrying out the present invention (hereinafter referred to as "embodiments") will be described with reference to the accompanying drawings. In this specification and the accompanying drawings, identical or similar components are given the same reference numerals, and redundant explanations may be omitted or only explanations focusing on the differences may be given. Furthermore, when there are multiple identical or similar components, they may be described using the same reference numerals with different subscripts. Note that when it is not necessary to distinguish between these multiple components, the subscripts may be omitted in the description. The number of each component may be singular or plural unless otherwise specified.

[0011] In the following embodiment, various information is described in a table format, but the information may be in a data format other than a table format. Also, various names such as "XX information," "XX table," "XX list," and "XX list" are interchangeable.

[0012] First Embodiment First, a vehicle control device according to a first embodiment of the present invention will be described. Fig. 1 is a diagram showing an example of the configuration of a vehicle system including a vehicle control device according to the first embodiment of the present invention. In Fig. 1, a vehicle system 10 includes sensors such as a sonar 2, a radar 3, a camera 4, a LiDAR (Light Detection And Ranging) 6, and an additional camera 5, a vehicle control device 1, and devices such as a steering wheel 7, an accelerator 8, and a brake 9. The vehicle system 10 is a so-called vehicle.

[0013] The sonar 2, radar 3, camera 4, LiDAR 6, and additional camera 5 are attached to the body of the vehicle system 10. The additional camera 5 is a camera that complements the camera 4. For example, if the camera 4 is a front camera attached to the front of the vehicle, the additional camera 5 is a camera attached to the rear or side of the vehicle. However, the additional camera 5 may also be attached to the front of the vehicle. The vehicle control device 1 is an on-board electronic control unit (ECU). The sensors and devices shown in FIG. 1 are merely a part of the vehicle system 10.

[0014] [Configuration of Vehicle Control Device] The vehicle control device 1 receives sensing data from the sonar 2, radar 3, camera 4, LiDAR 6, and additional camera 5, and outputs control commands to the steering 7, accelerator 8, and brake 9. The vehicle control device 1 includes a semiconductor chip 11 and a semiconductor chip 12. The semiconductor chip 11 and the semiconductor chip 12 are configured in the form of a SoC (System on Chip), for example.

[0015] The semiconductor chip 12 processes the sensing data received from the additional camera 5 and the LiDAR 6 and outputs the processed data to the semiconductor chip 11. The semiconductor chip 11 processes the sensing data received from the sonar 2, the radar 3, and the camera 4, as well as the processed data output from the semiconductor chip, and generates control commands for each of the steering 7, the accelerator 8, and the brakes 9. The semiconductor chip 11 then outputs the generated control commands to the target steering 7, the accelerator 8, and the brakes 9. The vehicle control device 1 operates the steering 7, the accelerator 8, and the brakes 9 according to the control commands output from the semiconductor chip 11, thereby controlling the behavior of the vehicle.

[0016] 1 is an example, and configurations in which the types and numbers of sensors and the number of semiconductor chips are increased or decreased are also possible. Hereinafter, in this specification, the semiconductor chip 11 will also be referred to as "SoC1" and the semiconductor chip 12 will also be referred to as "SoC2."

[0017] 2 is a block diagram showing an example of the hardware configuration of the computer provided in the semiconductor chips 11 and 12 of the vehicle control device 1. Here, the hardware configuration will be described using the semiconductor chip 11 (SoC1) as an example.

[0018] As shown in FIG. 2 , the SoC 1 includes a CPU (Central Processing Unit) 21, a nonvolatile memory 22, a volatile memory 23, an input / output interface 24, and a network interface 25. Each piece of hardware (block) is connected to one another via a system bus. These pieces of hardware constitute a computer system (an example of a computer). The CPU 21 (CPU core) reads a software program from the nonvolatile memory 22, loads the program into the volatile memory 23, and executes it, thereby realizing the functions of the semiconductor chip 11.

[0019] The CPU 21 has a known timer function that uses a clock signal, etc. Although a CPU is used as a processor that is an arithmetic unit, other processors such as an MPU (Micro Processing Unit) may also be used.

[0020] The nonvolatile memory 22 is an example of a recording medium, and is capable of storing programs executed by the CPU 21, data used by the programs, data obtained by executing the programs, etc. The nonvolatile memory 22 may be a hard disk drive (HDD), a solid state drive (SSD), an optical or magnetic disk medium, a semiconductor memory card, or the like.

[0021] Variables, parameters, etc. generated during the calculation process of the CPU 21 are temporarily written to the volatile memory 23, and these variables, parameters, etc. are read out by the CPU 21 as appropriate.

[0022] The input / output interface 24 is an interface for communicating signals and data with each sensor and each actuator. The SoC 1 is equipped with an A / D (Analog / Digital) converter (not shown) that processes input / output signals from each sensor, a driver circuit, etc. The input / output interface 24 may also function as the A / D converter and driver circuit.

[0023] The network interface 25 is configured to be able to transmit and receive various data to and from other electronic control units connected to the in-vehicle network via the in-vehicle network to which the terminals are connected.

[0024] The hardware configuration of the semiconductor chip 12 (SoC2) is also similar to that of the semiconductor chip 11 (SoC1). In the SoC2, the CPU 21 executes a program stored in the nonvolatile memory 22, thereby realizing the functions of the SoC2.

[0025] [Configuration of Functional Blocks and Overall Operation Flow] Next, the functions and operations of the vehicle control device 1 will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of the configuration of functional blocks of the vehicle control device 1 and an example of the overall operation flow.

[0026] SoC2 includes an object detection unit 121, an object detection unit 122, and a communication unit 123. The object detection unit 121 receives additional camera data D5, which is image data captured by the additional camera 5, performs object detection processing, and outputs the object detection result to the communication unit 123. The object detection unit 122 receives LiDAR data D6 acquired by the LiDAR 6, performs object detection processing, and outputs the object detection result to the communication unit 123. The communication unit 123 transmits the object detection results input from the object detection unit 121 and the object detection results input from the object detection unit 122 to the communication unit 114 of SoC1.

[0027] The SoC1 includes a distance measurement unit 111, an object detection unit 112, an object detection unit 113, a communication unit 114, a fusion unit 115, a trajectory calculation unit 116, and a control command value calculation unit 117. The distance measurement unit 111 receives sonar data D2 acquired by the sonar 2, executes processing to measure the distance from the vehicle to an object, and outputs the distance measurement result to the fusion unit 115. Note that while the present embodiment uses sonar to perform distance measurement, other methods may also be used. For example, image processing (parallax information) of image data captured by a camera, processing of radar data from a radar, processing of LiDAR data from a LiDAR, etc. may be used.

[0028] The object detection unit 112 receives radar data D3 acquired by Radar 3, performs object detection processing, and outputs the object detection result to the fusion unit 115. The object detection unit 113 receives camera data D4, which is image data captured by camera 4, performs object detection processing, and outputs the object detection result to the fusion unit 115. The communication unit 114 outputs the object detection results of the object detection units 121 and 122, received from the communication unit 123 of SoC 2, to the fusion unit 115.

[0029] The fusion unit 115 executes a fusion process to integrate the data of the distance measurement result from the distance measurement unit 111, the object detection result from the object detection unit 112, the object detection result from the object detection unit 113, the object detection result from the object detection unit 121, and the object detection result from the object detection unit 122, and outputs the integrated data to the trajectory calculation unit 116. The integration process can be performed by applying well-known techniques. The trajectory calculation unit 116 recognizes the surrounding environment of the vehicle based on the data after the integration process, and calculates the trajectory calculation result to the control command value calculation unit 117. The control command value calculation unit 117 receives the trajectory calculation result from the trajectory calculation unit 116 and calculates a control command value for realizing the calculated trajectory of the vehicle.

[0030] With the above-described functional configuration, SoC2 receives additional camera data D5 from additional camera 5 and LiDAR data D6 from LiDAR 6. SoC2 performs object detection using this data and transmits the object detection results to SoC1.

[0031] SoC1 receives sonar data D2 from Sonar 2, radar data D3 from Radar 3, and camera data D4 from Camera 4, and uses these data to perform object detection and distance measurement. SoC1 also receives object detection results based on additional camera data D5 and LiDAR data D6 from SoC2. SoC1 then integrates these object detection results and distance measurement results to recognize the vehicle's surrounding environment and calculate the vehicle's trajectory. SoC1 then calculates control command values ​​to realize the calculated vehicle trajectory and outputs the control command values ​​to the steering wheel 7, accelerator 8, and brake 9.

[0032] The volatile memory 23 (see FIG. 2) of SoC1 and SoC2 can be considered to store the results of task processing in SoC1 and SoC2 themselves and timestamps indicating the processing times of the tasks.

[0033] [Operation of Vehicle Control Device] Next, the operation of the functions in each semiconductor chip 11, 12 (SoC1, 2) of the vehicle control device 1 will be described with reference to Fig. 4. Fig. 4 is a diagram showing an example of the operation of the functions in each semiconductor chip 11, 12 (SoC1, 2) of the vehicle control device 1. In Fig. 4, the horizontal axis represents time, and time elapses from left to right.

[0034] The vehicle control device 1 runs at a fixed processing cycle and must output control command values ​​for controlling the vehicle during that processing cycle. Although SoC1 and SoC2 can process tasks in parallel, for example, fusion processing running on SoC1 requires output from SoC2.

[0035] In the example of FIG. 4 , in cycle N, SoC1 performs distance measurement using Sonar 2 (sonar), object detection using Camera 4 (camera), and object detection using Radar 3 (radar), followed by fusion, trajectory calculation, and control command value calculation. SoC2 performs object detection using Additional Camera 5 (camera) and object detection using LiDAR 6 (LiDAR), followed by communication to transmit the object detection results to SoC1. In this example, a shared margin M is set between the end of control command value calculation in SoC1 and the start of the next cycle N+1. Note that SoC1 also performs communication to receive the object detection results, but the "communication" on the SoC1 side is omitted.

[0036] [Average Execution Time and Worst Case Execution Time of Each Function] Here, Fig. 5 shows examples of the average execution time and worst case execution time of each function. The average execution time refers to the average time required to execute the target function (task processing) on ​​each SoC. The worst case execution time refers to the longest time required to execute the target function (task processing) on ​​each SoC.

[0037] In the example of Figure 5, the average execution time (ms) and worst-case execution time (ms) are as follows: The average execution time for distance measurement (sonar) is "5" and the worst-case execution time is "10". The average execution time for object detection (radar) is "10" and the worst-case execution time is "20". The average execution time for object detection (camera) is "25" and the worst-case execution time is "40". Here, it is assumed that the time required to process camera data D4 from camera 4 on SoC1 is the same as the time required to process additional camera data D5 from additional camera 5 on SoC2, but this may be different. The average execution time for object detection (LiDAR) is "35" and the worst-case execution time is "55". The average execution time for communication is "5" and the worst-case execution time is "20". The average execution time for fusion is "25" and the worst-case execution time is "35". The average execution time for trajectory calculation is "10" and the worst-case execution time is "15". The average execution time for calculating the control command value is "5", and the worst execution time is "10".

[0038] In the case of the function operation shown in Figure 4, the critical path is object detection (camera) → object detection (LiDAR) → communication → fusion → trajectory calculation → control command value calculation. Here, the reference time (average execution time) of the critical path is 105 (25 + 35 + 5 + 25 + 10 + 5) ms. If the slack time (shared margin) is set to 45 ms, the processing cycle will be 150 ms. The shared margin is used to absorb delays in any of the functions (task processing delays). For example, even if the object detection (LiDAR) of SoC2 is delayed and requires an execution time of 50 ms, using the shared margin allows the output of the entire system to be output within the specified processing cycle (150 ms).

[0039] [Setting the shared margin taking into account the execution time of a task] Next, the concept of setting the shared margin taking into account the execution time of a task will be explained. For example, for a certain task A, the execution time and the probability of it being completed within that time have the following relationship: 10 ms: 15% 15 ms: 50% 20 ms: 30% 30 ms: 5%

[0040] Similarly, for task B, the execution time and probability have the following relationship: 20 ms: 20% 30 ms: 70% 40 ms: 10%

[0041] If there is no dependency between these two tasks A and B, there are 12 possible execution time patterns: The occurrence rate of the two tasks is simply the product of the probabilities of the two tasks. 10ms+20ms: 15%*20%=3% 10ms+30ms: 15%*70%=10.5% 10ms+40ms: 15%*10%=1.5% 15ms+20ms: 50%*20%=10% 15ms+30ms: 50%*70%=35% 15ms + 40ms: 50% * 10% = 5% 20ms + 20ms: 30% * 20% = 6% 20ms + 30ms: 30% * 70% = 21% 20ms + 40ms: 30% * 10% = 3% 30ms + 20ms: 5% * 20% = 1% 30ms+30ms: 5%*70%=3.5% 30ms+40ms: 5%*10%=0.5%

[0042] Since the average execution time of task A is 16.5 ms and the average execution time of task B is 29 ms, if the share margin is set to 14.5 ms, for example, there is an approximately 99.5% chance that the deadline will be met in a processing cycle of 60 ms. Setting a larger share margin will improve the chance of meeting the deadline, but will result in a decrease in resource utilization efficiency. For this reason, the share margin must be set taking into account the trade-off between meeting the deadline and resource utilization efficiency.

[0043] On the other hand, for example, if the number of objects detected by object detection increases, it is possible that fusion will also need to process many detected objects. For this reason, it is necessary to consider cases where there is a dependency between the execution times of multiple tasks. By measuring the execution time of each task in relation to input from each sensor, a correlation coefficient can be calculated. For example, if it is determined that there is a positive correlation between task A and task B, when task A takes a time close to its worst-case execution time, task B will also take a time close to its worst-case execution time. Therefore, in order to meet the system deadline even if task A takes its worst-case execution time, it is necessary to set a shared margin that takes into account the worst-case execution time of task B.

[0044] [General Operation Using Shared Margin] Fig. 6 shows an example of general operation using a shared margin when task execution is delayed. The processing sequence including task processing on SoC1 and SoC2 is the same as the example shown in Fig. 4.

[0045] The example shown in Figure 6 assumes that the execution of object detection (LiDAR) on SoC2 is delayed. If the object detection (LiDAR) process is not completed within the average execution time, the shared margin Mc is consumed from the shared margin M. SoC1 adjusts the execution timing of tasks to account for the delay in object detection (LiDAR) on SoC2, enabling processing using the object detection (LiDAR) results while meeting the deadline. When SoC1 completes processing up to the calculation of the control command value, the shared margin Mr(M-Mc) still remains.

[0046] In this embodiment, when the processing time of a preceding task on one semiconductor chip (SoC2) exceeds the reference time, the processor on the other semiconductor chip (SoC1) suspends the start of the subsequent task until the preceding task is completed within the threshold time set for the slack time. This allows the other semiconductor chip to wait for the processing result of the preceding task on the one semiconductor chip within the threshold time set for the slack time. This allows the other semiconductor chip to use the processing result of the preceding task on the one semiconductor chip for processing the subsequent task while meeting the deadline.

[0047] [Example of not using the result of the preceding task] Next, an example of not using the result of the preceding task in order to meet the deadline in the first embodiment of the present invention will be described with reference to FIG.

[0048] FIG. 7 illustrates an example of operation in the first embodiment when the results of a preceding task are not used to meet a deadline. In this embodiment, the nonvolatile memory 22 of SoC1 (see FIG. 2) stores a first program that uses the results of a preceding task on SoC2, and a second program that does not use the results of a preceding task on SoC2. SoC2 does not use the results of a preceding task on another SoC. Therefore, the nonvolatile memory 22 of SoC2 stores a program similar to the second program stored on SoC1 in this respect. The second program uses only the results of tasks processed by its own SoC, and does not use the results of tasks processed by other SoCs.

[0049] That is, in the vehicle control device 1, when the processor of another semiconductor chip (SoC1) suspends the start of a subsequent task, if the processing of the preceding task is not completed within the threshold time set for the slack time (shared margin), the processor disables the request to start a program that uses the processing results of the preceding task.

[0050] In the vehicle control device 1, the processor of the other semiconductor chip (SoC1) selects the first program if processing of the preceding task is completed within a threshold time set for the slack time (shared margin), and selects the second program if processing of the preceding task is not completed within the threshold time.

[0051] Here, the first program and the second program will be described. The first program causes the processor of the other semiconductor chip (SoC1) to execute, as a subsequent task, a first fusion process that integrates object detection results resulting from processing of a preceding task on one semiconductor chip (SoC2) with object detection results resulting from processing of tasks (distance measurement (sonar), object detection (camera), object detection (radar)) on the other semiconductor chip to generate first integrated object information. The second program causes the processor of the other semiconductor chip (SoC1) to execute, as a subsequent task, a second fusion process that uses object detection results resulting from processing of tasks (distance measurement (sonar), object detection (camera), object detection (radar)) on the other semiconductor chip to generate second integrated object information.

[0052] 7 assumes that the execution of object detection (camera) and object detection (LiDAR) is delayed and exceeds the shared margin. Here, the execution of object detection (camera) and object detection (LiDAR) is delayed, consuming the shared margin Mc1 in the object detection (camera) and the shared margin Mc2 in the object detection (LiDAR), resulting in the shared margin M being exceeded by time Te.

[0053] If the shared margin is exceeded, SoC1 will not be able to meet the deadline if it waits for the task result from SoC2. Therefore, SoC1 must give up on receiving the task result from SoC2, taking into account the execution time of the succeeding task that should be executed in that processing cycle (cycle N in the figure).

[0054] (Using the Sum of Worst-Case Execution Times) For example, if meeting the deadline is essential, the sum of the worst-case execution times can be used to determine the timing for abandoning receiving task results from SoC2. As shown in Figure 5, the worst-case execution time for fusion is 35 ms, the worst-case execution time for trajectory calculation is 15 ms, and the worst-case execution time for control command value calculation is 10 ms. Therefore, SoC1 abandons receiving task results from SoC2 at time tg, when the remaining time until the start of the next cycle N+1 is 60 (= 35 + 15 + 10) ms.

[0055] By setting it this way, the deadline can be met even if the remaining functions executed by SoC1 all take the worst-case execution time. However, although the deadline can be met, the output from SoC2 cannot be used in the fusion processing.

[0056] (Using the Sum of Average Execution Times) The system (vehicle system 10 in this embodiment) may be configured to allow the use of the previous control command value. For example, this may occur when objects around the vehicle are not moving or when the amount of movement of the objects is less than a predetermined value. In this case, the timing to abandon receiving task results from SoC2 can be determined, for example, from the sum of average execution times. As shown in FIG. 5, the average execution time for fusion is 25 ms, the average execution time for trajectory calculation is 10 ms, and the average execution time for control command value calculation is 5 ms. Therefore, SoC1 abandons receiving task results from SoC2 when the remaining time until the start of the next cycle N+1 is 40 (= 25 + 10 + 5) ms.

[0057] This setting can absorb large delays in task processing by SoC2 compared to calculations based on the worst-case execution time. On the other hand, depending on the time required for the remaining functions to be executed by SoC1, it may be necessary to use the previous control command value in order to meet the deadline.

[0058] Furthermore, the timing for abandoning receiving task results from SoC2 may be dynamically switched between a timing based on the worst-case execution time (e.g., 60 ms) and a timing based on the average execution time (e.g., 40 ms). In this case, the vehicle control device 1 needs to calculate the execution time of task processing on SoC2 at each processing cycle. For example, while processing a task on SoC2, the vehicle control device 1 predicts the execution time until all task processing on SoC2 is completed and outputs the predicted value to SoC1. As described above, there may be dependencies between the execution times of multiple tasks. For example, the execution time of object detection (LiDAR) on SoC2 can be predicted based on the execution time of object detection (camera) on SoC2. SoC1 uses the predicted execution time of SoC2 to calculate the time required to process the subsequent task and switch the abandonment timing.

[0059] If SoC1 determines that it can receive the task result from SoC2 before the sum of the worst-case execution times of the subsequent tasks from the end time of cycle N, it may set the timing for giving up on receiving the task result from SoC2 to either a timing based on the worst-case execution time (e.g., 60 ms) or a timing based on the average execution time (e.g., 40 ms).

[0060] Furthermore, if SoC1 determines that it can receive the task result from SoC2 after the end time of cycle N and the sum of the worst-case execution times of the subsequent tasks, but before the sum of the average execution times of the subsequent tasks, it may set the timing for abandoning receiving the task result from SoC2 to a timing based on the average execution time (e.g., 40 ms).By doing this, it is possible to expect to receive the task result from SoC2, and the other semiconductor chip (SoC1) can use the processing result of the preceding task on one semiconductor chip (SoC2) for processing the subsequent task while meeting the deadline.

[0061] Furthermore, if SoC1 determines that it can receive task results from SoC2 after the sum of the average execution times of the succeeding tasks from the end of cycle N, it may set the timing for abandoning receiving task results from SoC2 to a timing based on the worst-case execution time (e.g., 60 ms). This allows SoC1 to reliably calculate control command values ​​using the latest data (latest values) output by each sensor.

[0062] This allows SoC1 to change the timing at which it abandons receiving task results from SoC2 depending on the predicted execution time of SoC2, enabling flexible adherence to deadlines and flexibly absorbing delays throughout the system as a whole.

[0063] As described above, a vehicle control device (e.g., vehicle control device 1) according to this embodiment includes multiple semiconductor chips (SoC1 / SoC2) each having a processor (CPU 21) for processing sensor data received from a sensor (see each sensor in FIG. 1 ), a nonvolatile memory (nonvolatile memory 22), and a volatile memory (volatile memory 23). In this vehicle control device, a processing period including a reference time and a slack time required for processing each task included in a processing sequence is assigned to the processing sequence, the processing period including at least processing a preceding task in one semiconductor chip (SoC2) and processing a subsequent task in another semiconductor chip (SoC1) that uses the processing result of the preceding task. The processor of the other semiconductor chip calculates the remaining time available for processing the subsequent task in the processing period based on the execution time (e.g., average execution time / worst-case execution time) and the slack time (shared margin) required for processing the preceding task in the one semiconductor chip, and determines the start time of the subsequent task based on the remaining time.

[0064] According to the vehicle control device of this embodiment having the above configuration, delays can be absorbed by taking into account the slack time of the entire vehicle control device (entire system). In other words, delays can be absorbed even when slack time remains in the entire system.

[0065] Second Embodiment [Example of Function Selection Considering Remaining Time] Next, as a second embodiment of the present invention, a configuration for selecting a function considering remaining time in a semiconductor chip executing processing of a preceding task or a semiconductor chip executing processing of a subsequent task will be described with reference to FIG. 8 . In this embodiment, if a processor of one semiconductor chip (SoC2) determines that the processing time of one of multiple tasks in the one semiconductor chip (SoC2) exceeds a reference time plus a threshold time, the processor executes another task to be executed after the one task in the one semiconductor chip (SoC2) with processing content (simplified processing) that has a shorter reference time. Also, in this embodiment, if a processor of another semiconductor chip (SoC1) determines that the processing time of the preceding task in the one semiconductor chip (SoC2) exceeds the reference time plus a threshold time, the processor executes the subsequent task with processing content (simplified processing) that has a shorter reference time. Furthermore, in this embodiment, if the processor of the other semiconductor chip (SoC1) determines that the processing time of one of the multiple tasks in the other semiconductor chip (SoC1) exceeds the reference time plus a threshold time, it may be configured to execute another task that is to be executed after the one task in the other semiconductor chip (SoC1) with processing content (simplified processing) that has a shorter reference time.

[0066] (Example of Executing Simple Processing on a Single Semiconductor Chip (SoC2)) FIG. 8 is a diagram showing an example of selecting a function taking into account the remaining time in SoC2 according to a second embodiment of the present invention. For example, there are various methods for object detection (camera, LiDAR) on SoC2, and the average execution time and worst-case execution time for each method differ. This also applies to distance measurement (sonar or non-sonar). Furthermore, for example, with regard to fusion, the amount of input data to SoC1 differs when using task results from SoC1 and SoC2 and when using task results from SoC1 alone, so the average execution time and worst-case execution time may differ. Therefore, SoC2 selects a function taking into account the remaining time at the start of each task processing (strictly speaking, before the start), thereby performing processing using the latest data (latest values) output by each sensor while meeting the deadline for the entire system.

[0067] For example, Object Detection (LiDAR)-B is prepared as a function that performs object detection using LiDAR6. The average execution time of Object Detection (LiDAR)-B on SoC2 is 30 ms, and the worst-case execution time is 40 ms. Object Detection (LiDAR)-B has a shorter execution time than Object Detection (LiDAR), which takes 35 ms, and is a simple process. Furthermore, taking into account the processing cycle of 150 ms and the average execution time of the critical path of 105 ms, the shared margin is set to 45 ms.

[0068] As shown in Figure 8, consider the case where object detection (camera) on SoC2 consumes 15 ms of shared margin (shared margin Mc1 in the figure). If object detection (LiDAR) is performed on SoC2, it could consume up to 20 (= 55 - 35) ms of shared margin. Therefore, SoC2 selects object detection (LiDAR)-B, which has a shorter execution time than object detection (LiDAR). This not only reduces the average execution time by 5 ms, but also consumes a maximum of 10 (= 40 - 30) ms of shared margin, as shown by shared margin Mc2' in the figure. Therefore, SoC2 can output to SoC1 without exceeding shared margin M. When SoC1 completes processing up to the calculation of the control command value, a shared margin Mr' (M - Mc1 - Mc2') remains.

[0069] (Example of Executing Simple Processing on Another Semiconductor Chip (SoC1)) Next, assuming Fusion-B (not shown), which is a processing simpler than Fusion, an example of selecting a function on another semiconductor chip (SoC1) will be explained. Generally, the average execution time is shorter than the worst execution time, so the average execution time of Fusion is shorter than the worst execution time of Fusion, and the average execution time of Fusion-B is shorter than the worst execution time of Fusion-B. Here, assuming that the worst execution time of Fusion-B is shorter than the worst execution time of Fusion, the relationship between the respective times will be in the following three patterns: (1) Worst execution time of Fusion > Worst execution time of Fusion-B > Average execution time of Fusion > Average execution time of Fusion-B (2) Worst execution time of Fusion > Average execution time of Fusion > Worst execution time of Fusion > Average execution time of Fusion-B (3) Worst execution time of Fusion > Worst execution time of Fusion-B > Average execution time of Fusion-B > Average execution time of Fusion

[0070] In addition to the above pattern (1), five further patterns are assumed for the relationship with the remaining time of the shared margin. (1)-1: Remaining time of the shared margin > Worst execution time of Fusion > Worst execution time of Fusion-B > Average execution time of Fusion > Average execution time of Fusion-B (1)-2: Worst execution time of Fusion > Remaining time of the shared margin > Worst execution time of Fusion-B > Average execution time of Fusion > Average execution time of Fusion-B (1)-3: Worst execution time of Fusion > Worst execution time of Fusion-B > Remaining time of the shared margin > Average execution time of Fusion > Average execution time of Fusion-B (1)-4: Worst execution time of Fusion > Worst execution time of Fusion-B > Average execution time of Fusion > Remaining time of the shared margin > Average execution time of Fusion-B (1)-5: Worst execution time of Fusion > Worst execution time of Fusion-B > Average execution time of Fusion > Average execution time of Fusion-B > Remaining time of the shared margin

[0071] Furthermore, for the above pattern (2), five further patterns are assumed for the relationship with the remaining time of the shared margin. (2)-1: Remaining time of the shared margin > Worst execution time of fusion > Average execution time of fusion > Worst execution time of fusion-B > Average execution time of fusion-B (2)-2: Worst execution time of fusion > Remaining time of the shared margin > Average execution time of fusion > Worst execution time of fusion-B > Average execution time of fusion-B (2)-3: Worst execution time of fusion > Average execution time of fusion > Remaining time of the shared margin > Worst execution time of fusion-B > Average execution time of fusion-B (2)-4: Worst execution time of fusion > Average execution time of fusion > Worst execution time of fusion-B > Remaining time of the shared margin > Average execution time of fusion-B (2)-5: Worst execution time of fusion > Average execution time of fusion > Worst execution time of fusion-B > Average execution time of fusion-B > Average execution time of fusion-B > Remaining time of the shared margin

[0072] Furthermore, for the above pattern (3), five further patterns are assumed for the relationship with the remaining time of the shared margin. (3)-1: Remaining time of the shared margin > Worst execution time of Fusion > Worst execution time of Fusion-B > Average execution time of Fusion-B > Average execution time of Fusion (3)-2: Worst execution time of Fusion > Remaining time of the shared margin > Worst execution time of Fusion-B > Average execution time of Fusion > Average execution time of Fusion (3)-3: Worst execution time of Fusion > Worst execution time of Fusion-B > Remaining time of the shared margin > Average execution time of Fusion > Average execution time of Fusion (3)-4: Worst execution time of Fusion > Worst execution time of Fusion-B > Average execution time of Fusion-B > Remaining time of the shared margin > Average execution time of Fusion (3)-5: Worst execution time of Fusion > Worst execution time of Fusion-B > Average execution time of Fusion > Average execution time of Fusion > Remaining time of the shared margin

[0073] At the start of task processing, if both the worst-case execution times of Fusion and Fusion-B remain ((1)-1, (2)-1, (3)-1), Fusion should be selected.

[0074] At the start of task processing, if the worst-case execution time of Fusion-B remains and the worst-case execution time of Fusion does not remain ((1)-2, (2)-2, (2)-3, (3)-2), Fusion-B should be selected. By doing so, the results of the fusion processing can be obtained reliably. Note that Fusion may be selected if it is permissible to use the previous control command value.

[0075] At the start of task processing, if neither Fusion nor Fusion-B's worst-case execution time remains, but both their average execution times remain ((1)-3, (3)-3), Fusion-B should be selected in (1)-3, and Fusion should be selected in (3)-3. In this case, the worst-case execution time cannot be secured, and it cannot be guaranteed that task processing will be completed within the deadline. Therefore, by executing the function with the shorter average execution time between Fusion and Fusion-B, the possibility of completing task processing within the deadline increases. Note that in order to select a function that is likely to complete processing within the deadline, the variance of execution times may be taken into consideration. Specifically, the probability that execution will be completed within the remaining time of the shared margin for each of Fusion and Fusion-B may be calculated, and the one with the higher probability may be selected.

[0076] At the start of task processing, if there is no worst-case execution time remaining for either Fusion or Fusion-B, but the average execution time for one of them remains ((1)-4, (2)-4, (3)-4), it is advisable to select the function with the remaining average execution time. For example, in the cases of (1)-4 and (2)-4, Fusion-B should be selected, and in the case of (3)-4, Fusion should be selected. In this way, the possibility of completing task processing within the deadline increases. As mentioned above, the selection may also be made taking into account the variance of execution times.

[0077] If there is no remaining average execution time for either Fusion or Fusion-B at the start of task processing ((1)-5, (2)-5, (3)-5), it is advisable to select the function with the shorter average execution time. This increases the likelihood that task processing will be completed within the deadline. As mentioned above, the selection may also be made taking into account the variance of execution times.

[0078] As described above, the vehicle control device according to the second embodiment has the same basic configuration as the vehicle control device 1 according to the first embodiment, but differs in the following respects. In the second embodiment, the processor of the other semiconductor chip (SoC1) calculates the remaining time available for processing a subsequent task in a processing cycle based on the execution time (e.g., average execution time / worst-case execution time) and the slack time (shared margin) required to process a preceding task on the one semiconductor chip (SoC2), and determines the processing content of the subsequent task based on the remaining time. Furthermore, the processor of the one semiconductor chip (SoC2) calculates the remaining time available for processing on the one semiconductor chip (SoC2) in a processing cycle based on the execution time (e.g., average execution time / worst-case execution time) and the slack time (shared margin) required to process one of the multiple tasks on the one semiconductor chip (SoC2), and determines the processing content of the other task to be executed after the one task on the one semiconductor chip (SoC2) based on the remaining time. Furthermore, the processor of the other semiconductor chip (SoC1) may calculate the remaining time available for processing in the other semiconductor chip (SoC1) in a processing cycle based on the execution time (e.g., average execution time / worst-case execution time) required to process one of multiple tasks in the other semiconductor chip (SoC1) and the leeway time (shared margin), and may determine the processing content of another task to be executed after the one task in the other semiconductor chip (SoC1) based on the remaining time.

[0079] The vehicle control device according to the present invention may be a combination of the configuration of the second embodiment and the configuration of the first embodiment. That is, the other semiconductor chip (SoC1) calculates the remaining time available for processing the subsequent task in the processing cycle based on the execution time and slack time required to process the preceding task on the one semiconductor chip (SoC2), and determines at least one of the start time and processing content of the subsequent task based on the remaining time.

[0080] <Third embodiment> [Regarding setting of a shared margin taking into account time synchronization errors between semiconductor chips] Next, as a third embodiment of the present invention, setting of a shared margin taking into account time synchronization errors between semiconductor chips will be described with reference to Figures 9 and 10.

[0081] (First Example) FIG. 9 is a diagram showing a first example of time synchronization error between semiconductor chips (SoCs) according to a third embodiment of the present invention. In FIG. 9, the horizontal axis represents time. In this example, the volatile memory 23 (see FIG. 2) of another semiconductor chip (SoC1) stores the processing result of a preceding task in one semiconductor chip (SoC2) and a timestamp, i.e., time information, indicating the processing time of the preceding task. The processor of SoC1 then determines at least one of the start time and processing content of the subsequent task based on the update status of the timestamp stored in the volatile memory 23.

[0082] Since the vehicle control device 1 is composed of multiple SoCs, time synchronization between the SoCs is necessary. However, time synchronization involves errors, and the error with respect to the absolute time of the SoC is represented by ε. As shown in Figure 9, there are cases where the SoC time is ahead of the absolute time and cases where the SoC time is behind the absolute time.

[0083] In the vehicle control device 1, the original cycle N is from absolute time t2 to absolute time t5. However, for SoC2, cycle N is from absolute time t1, which is earlier than absolute time t2 by an error ε, to absolute time t4, which is earlier than absolute time t5 by an error ε. Similarly, for SoC1, cycle N is from absolute time t3, which is delayed from absolute time t2 by an error ε, to absolute time t6, which is delayed from absolute time t5 by an error ε.

[0084] For example, assume that the time on SoC2 is earlier than the absolute time by an error ε, and the time on SoC1 is later than the absolute time by an error ε. That is, task processing on SoC2 starts earlier than the specified absolute time by an error ε, and task processing on SoC1 starts later than the specified absolute time by an error ε. In this case, in cycle N, when task A executed on SoC2 outputs at absolute time t (=t7) based on the time on SoC2, SoC1 receives the output from SoC2 at absolute time t-2ε based on the time on SoC1. Here, the minus sign indicates a delay relative to the original target time.

[0085] For example, if the execution time of task A is shorter than the error 2ε, SoC1 will receive the data one cycle before, i.e., at cycle N-1. Therefore, SoC2, the sender, adds a timestamp to the output data to identify which cycle (here, cycle N) the data belongs to. This allows SoC1 to execute task B processing according to the update status of the timestamp.

[0086] For example, even if SoC1 receives data from SoC2 at the timing of cycle N-1, when SoC1 executes task B in cycle N, it can confirm that the timestamp has been updated based on the data received from SoC2. Therefore, SoC1 can perform task processing appropriately without making a mistake in the order of the cycles.

[0087] (Second Example) Figure 10 is a diagram showing a second example of time synchronization errors between semiconductor chips (SoCs) according to the third embodiment of the present invention. In Figure 10, the horizontal axis represents time. In this example, the processor of the other semiconductor chip (SoC1) subtracts from the slack time a time corresponding to the time synchronization errors between the other semiconductor chip (SoC1) and one semiconductor chip (SoC2) relative to absolute time, and calculates the remaining time available for processing subsequent tasks in the processing cycle.

[0088] Assume that the time on SoC2 is slower than the absolute time by an error ε, and the time on SoC1 is faster than the absolute time by an error ε. In this case, as shown in the upper part of Figure 10, in cycle N, when task C executed on SoC2 outputs at absolute time t (=t8) based on the time on SoC2, SoC1 receives the output from SoC2 at absolute time t + 2ε based on the time on SoC1. Here, the plus sign indicates that the time is ahead of the original target time.

[0089] Based on the time of SoC2, there is sufficient time remaining until the end of cycle N. However, from the perspective of SoC1, there is not enough time remaining until the end of cycle N, so SoC1 cannot execute task D. Therefore, when using the sharing margin, it is necessary to consider reducing the time by an amount that takes into account the time synchronization error. Specifically, when selecting functions on SoC1 while taking the remaining sharing margin into consideration, it is necessary to subtract the error 2ε from the sharing margin and compare the remaining time when each function is selected.

[0090] As shown in the lower part of Figure 10, SoC2 selects and executes a function (e.g., simple processing task C') that can be completed in time even after subtracting the error 2ε from the shared margin. Task C' has a shorter average execution time and a shorter worst-case execution time than task C. Task C and task C' are functions that use data from the same sensor, such as object detection (LiDAR) and object detection (LiDAR) shown in Figure 8. When task C' is selected, task C' executed on SoC2 outputs at absolute time t9, which is earlier than absolute time t8 based on the time of SoC2. Then, SoC1 can receive the output of task C' and execute task D earlier than in the case of task C. This allows SoC1 to have more time remaining, thereby protecting the dead time of the entire system.

[0091] Since SoC1 does not know the relative time synchronization error with SoC2, in the second example, SoC2 may also add a timestamp to the output data to identify which period the data belongs to.

[0092] <Fourth embodiment> [Response when the number of times the shared margin is exceeded exceeds a specified number of times] Next, as a fourth embodiment of the present invention, a response when the number of times the shared margin is exceeded exceeds a specified number of times will be described with reference to FIGS. 11 and 12 .

[0093] 11 is a diagram showing an example of allocating the shared margin to the processing of a succeeding task in the fourth embodiment of the present invention. It is conceivable that the processing time of a preceding task may exceed the shared margin multiple times in succession due to a hardware failure or the like. Therefore, if the processing time of a preceding task on one semiconductor chip (SoC2) exceeds the reference time plus a threshold time (shared merge) a predetermined number of times in succession, the processor on the other semiconductor chip (SoC1) allocates a portion of the threshold time to the succeeding task.

[0094] If the output timing from SoC2 exceeds the end time of the shared margin for a preset threshold number of consecutive times, the shared margin is allocated to SoC1. In this case, the shared margin is allocated before the start of the subsequent task (fusion in FIG. 11). For example, assume that the timing for abandoning output from SoC2 in SoC1 is set based on the average execution time. If the shared margin is not allocated to the processing of the subsequent task, if SoC1 takes time to process the remaining subsequent task, the deadline will not be met and SoC1 will output the previous control command value.

[0095] On the other hand, by allocating the shared margin to the processing of the subsequent tasks, the deadline can be met even if the processing of the remaining subsequent tasks takes time on SoC 1. Therefore, the vehicle control device 1 can perform processing using the latest control command value instead of the previous control command value.

[0096] 12 shows an example of a case where the preceding task processing completes execution within the allotted time in the fourth embodiment of the present invention. In the example shown in Fig. 12, the shared margin is allocated to SoC1. Therefore, if the output from SoC2 is received before the start timing t11 of the allocated shared margin, processing using the output of SoC2 becomes possible in that cycle (e.g., cycle N).

[0097] Therefore, if the preceding task processing is completed within the allotted time, SoC1 eliminates the apportionment of the shared margin in the next cycle (here, cycle N-1) (resulting in a state similar to that shown in Figure 8). That is, if the preceding task processing on one semiconductor chip (SoC2) is completed within the time calculated by adding the threshold time (shared margin) to the reference time of the preceding task, the allocation of part of the threshold time to the succeeding task on the other semiconductor chip (SoC1) is stopped, and the threshold time of the preceding task is restored to its original state. This allows the original threshold time (shared margin) to be allocated to the task processing on SoC2 in line with the error recovery on SoC2's side. Therefore, SoC1 returns to a state where it can execute the succeeding task processing using the latest processing results of the preceding task by SoC2.

[0098] On the other hand, if SoC1 receives an output from SoC2 between the start time t11 of the allocated shared margin and the time required for the subsequent task, SoC1 is already executing fusion processing. In this case, SoC1 suspends the processing that does not use the results of the preceding task of SoC2 and starts processing that uses the results of the preceding task of SoC2.

[0099] <Modifications> The present invention is not limited to the above-described embodiments, and various other modifications and applications are possible without departing from the spirit of the invention as defined in the claims. For example, the above-described embodiments have been described in detail and specifically to clearly explain the present invention, and are not necessarily limited to those including all of the components described. Furthermore, it is possible to replace part of the configuration of one embodiment with a component of another embodiment. It is also possible to add a component of another embodiment to the configuration of one embodiment. It is also possible to add, replace, or delete other components from part of the configuration of each embodiment.

[0100] Furthermore, some or all of the above-described configurations, functions, processing units, etc. may be implemented in hardware, for example, by designing them as integrated circuits, etc. As the hardware, a broad processor device such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) may be used.

[0101] In the above-described embodiment, the control lines and information lines are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are interconnected.

[0102] REFERENCE SIGNS LIST 1...vehicle control device, 10...vehicle system, 11...semiconductor chip, 12...semiconductor chip, 21...CPU, 22...non-volatile memory, 23...volatile memory, 111...distance measurement unit, 112...object detection unit (Radar), 113...object detection unit (camera), 114...communication unit, 115...fusion unit, 116...trajectory calculation unit, 117...control command value calculation unit, 121...object detection unit (camera), 122...object detection unit (LiDAR), 123...communication unit, M...shared margin, Mc1...shared margin (consumption), Mc2...shared margin (consumption), Mp...shared margin (proration), Mr...shared margin (remaining), Te...time

Claims

1. A vehicle control device having multiple semiconductor chips each having a processor for processing sensor data received from a sensor, a non-volatile memory, and a volatile memory, wherein a processing period including a reference time and a slack time required for processing each task included in a processing sequence that includes at least the processing of a preceding task in one semiconductor chip and the processing of a subsequent task in another semiconductor chip that uses the processing result of the preceding task is assigned, and the processor of the other semiconductor chip calculates the remaining time available for processing the subsequent task in the processing period based on the execution time and the slack time required for the processing of the preceding task in the one semiconductor chip, and determines at least one of the start time and processing content of the subsequent task based on the remaining time.

2. The vehicle control device described in claim 1, wherein, when the processing time of the preceding task in the one semiconductor chip exceeds the reference time, the processor of the other semiconductor chip suspends the start of the subsequent task until processing of the preceding task is completed within a threshold time set for the slack time.

3. The vehicle control device according to claim 2, wherein the processor of the other semiconductor chip disables a request to start a program that uses the processing results of the preceding task when the start of the subsequent task is suspended and the processing of the preceding task is not completed within the threshold time.

4. A vehicle control device as described in claim 2, wherein the non-volatile memory of the other semiconductor chip stores a first program that uses the processing results of the preceding task in the one semiconductor chip, and a second program that does not use the processing results of the preceding task in the one semiconductor chip, and the processor of the other semiconductor chip selects the first program if the processing of the preceding task is completed within the threshold time, and selects the second program if the processing of the preceding task is not completed within the threshold time.

5. The vehicle control device described in claim 4, wherein the multiple semiconductor chips execute an object detection process to detect an object based on sensor data received from the sensor, the first program causes the processor of the other semiconductor chip to execute, as the subsequent task, a first fusion process that integrates the object detection result that is the processing result of the preceding task with the object detection result that is the processing result of a task in the other semiconductor chip to generate first integrated object information, and the second program causes the processor of the other semiconductor chip to execute, as the subsequent task, a second fusion process that uses the object detection result that is the processing result of a task in the other semiconductor chip to generate second integrated object information.

6. A vehicle control device as described in claim 2, wherein the processor of the other semiconductor chip executes the subsequent task with processing content that has a shorter reference time when it determines that the processing time of the preceding task in the one semiconductor chip exceeds the reference time plus the threshold time.

7. A vehicle control device as described in claim 2, wherein, when the processor of the one semiconductor chip determines that the processing time of one of the multiple tasks in the one semiconductor chip exceeds the reference time plus the threshold time, it executes a task to be executed after the one task in the one semiconductor chip with processing content that has a shorter reference time.

8. A vehicle control device as described in claim 2, wherein, when the processor of the other semiconductor chip determines that the processing time of one of the multiple tasks in the other semiconductor chip exceeds the reference time plus the threshold time, it executes a task to be executed after the one task in the other semiconductor chip with processing content that has a shorter reference time.

9. A vehicle control device as described in claim 1, wherein the volatile memory of the other semiconductor chip stores the processing result of the preceding task in the one semiconductor chip and a timestamp indicating the processing time of the preceding task, and the processor of the other semiconductor chip determines at least one of the start time or processing content of the subsequent task depending on the update status of the timestamp stored in the volatile memory.

10. The vehicle control device according to claim 1, wherein the processor of the other semiconductor chip subtracts a time corresponding to a time synchronization error between the other semiconductor chip and the one semiconductor chip relative to absolute time from the slack time, and calculates the remaining time available for processing the subsequent task in the processing cycle.

11. A vehicle control device as described in claim 2, wherein the processor of the other semiconductor chip allocates a portion of the threshold time to the subsequent task when the processing time of the preceding task in the one semiconductor chip exceeds the reference time plus the threshold time for a specified number of consecutive times.

12. A vehicle control device as described in claim 11, wherein the processor of the other semiconductor chip stops allocating part of the threshold time to the subsequent task if processing of the preceding task in the one semiconductor chip is completed within the time obtained by adding the threshold time to the reference time.

13. A sensor data processing method in a vehicle control device having multiple semiconductor chips each having a processor that processes sensor data received from a sensor, a non-volatile memory, and a volatile memory, wherein a processing period including a reference time and a slack time required for processing each task included in a processing sequence is assigned to a processing sequence that includes at least processing of a preceding task in one semiconductor chip and processing of a subsequent task in another semiconductor chip that uses the processing result of the preceding task, and the processor of the other semiconductor chip calculates the remaining time available for processing the subsequent task in the processing period based on the execution time required for processing the preceding task in the one semiconductor chip and the slack time, and determines at least one of the start time and processing content of the subsequent task based on the remaining time.

Images