Vehicle control device and sensor data processing method

The vehicle control device with semiconductor chips and assigned processing periods addresses delays by managing slack times, ensuring timely processing and efficient resource utilization.

JP2025142615APending Publication Date: 2025-10-01ASTEMO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2024042067
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-03-18
Publication Date
2025-10-01

AI Technical Summary

Technical Problem

Existing vehicle control systems face delays due to slack time in the system when processes using the processing results of one ECU are executed only after those of another ECU, leading to inefficiencies.

Method used

A vehicle control device with multiple semiconductor chips that include processors, non-volatile and volatile memories, assigns processing periods considering reference and slack times, allowing processors to calculate remaining times for tasks and determine start times based on these values, thereby absorbing delays.

Benefits of technology

Delays are effectively managed by considering slack times across the entire system, ensuring timely processing and efficient resource utilization.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025142615000001_ABST
    Figure 2025142615000001_ABST
Patent Text Reader

Abstract

To absorb delay when margin time remains as an entire system.SOLUTION: A processing period including reference time and margin time required for processing each task included in a processing sequence is allocated to the processing sequence at least including processing of a preceding task in one semiconductor chip 12 and processing of a following task in another semiconductor chip 11 utilizing a processing result of the preceding task. A processor of another semiconductor chip 11 obtains remaining time usable for processing of a following task in the processing period on the basis of execution time and margin time required for processing of a preceding task in the one semiconductor chip 12, and determines at least one of start time and processing contents of the following task on the basis of remaining time.SELECTED DRAWING: Figure 7
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

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

[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 in which, for multiple tasks that can be executed in parallel, subsequent tasks that use the results of those tasks are event-driven, and the remaining time from the event reception time to the deadline is calculated, thereby switching the processing order while meeting the deadline, thereby absorbing delays in one of the tasks.

[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. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2023-36264 Summary of the Invention [Problem to be solved by the invention]

[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. [Means for solving the problem]

[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. [Effects of the Invention]

[0008] According to at least one aspect of the present invention, delays can be absorbed 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 embodiments of the invention. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram showing an example of the configuration of a vehicle control device according to a first embodiment of the present invention. [Figure 2] 1 is a block diagram showing an example of the hardware configuration of a computer included in a semiconductor chip according to a first embodiment of the present invention. [Figure 3] 1 is a diagram illustrating an example of a functional block configuration and an overall operation flow of a vehicle control device according to a first embodiment of the present invention. [Figure 4] 2 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. [Figure 5] FIG. 10 is a diagram showing an example of the average execution time and the worst execution time of each function. [Figure 6] FIG. 10 is a diagram illustrating a typical example of operation using a shared margin when task execution is delayed. [Figure 7] FIG. 10 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. [Figure 8] FIG. 10 is a diagram showing an example of function selection taking into consideration the remaining time in a semiconductor chip that executes processing of a preceding task according to the second embodiment of the present invention. [Figure 9] FIG. 10 is a diagram showing a first example of a time synchronization error between semiconductor chips according to the third embodiment of the present invention. [Figure 10] (Additional) A diagram showing a second example of time synchronization errors between semiconductor chips according to the third embodiment of the present invention. [Figure 11] FIG. 13 is a diagram showing an example of allocating a shared margin to subsequent processing in the fourth embodiment of the present invention. [Figure 12] FIG. 13 is a diagram showing an example in which the preceding process is completed within the time limit in the fourth embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 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 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 a first embodiment of the present invention. In Fig. 1, the 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 only a part of the vehicle system 10.

[0014] [Vehicle control device configuration] 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 an 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, to generate control commands for the steering 7, the accelerator 8, and the brakes 9. The semiconductor chip 11 then outputs the generated control commands to the steering 7, the accelerator 8, and the brakes 9. The vehicle control device 1 operates the steering 7, accelerator 8, and brake 9 in response to control commands output from the semiconductor chip 11 to control 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, semiconductor chip 11 will also be referred to as "SoC1" and semiconductor chip 12 will also be referred to as "SoC2."

[0017] [Hardware configuration of vehicle control device] 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. that are 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 SoC1 includes an A / D (Analog / Digital) converter (not shown) that processes input / output signals of each sensor, a driver circuit, etc. The input / output interface 24 may also function as the A / D converter and the 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 terminal is 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 recorded in the nonvolatile memory 22, thereby realizing the functions of the SoC2.

[0025] [Function block configuration and overall operation flow] Next, the functions and operations of the vehicle control device 1 will be described with reference to FIG. FIG. 3 is a diagram showing an example of the functional block configuration and overall operation flow of the vehicle control device 1.

[0026] The SoC 2 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, executes object detection processing, and outputs the object detection result to the communication unit 123. The object detection unit 122 receives the LiDAR data D6 acquired by the LiDAR 6, executes 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 the SoC1.

[0027] The SoC 1 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 in this embodiment, distance measurement is performed using sonar, but other methods may also be used. For example, image processing (parallax information) of image data captured by a camera, processing of radar data from radar, processing of lidar data from lidar, etc. may be used.

[0028] The object detection unit 112 receives the Radar data D3 acquired by Radar 3, executes 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 the camera 4, executes 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 the SoC2 to the fusion unit 115.

[0029] Fusion unit 115 executes a fusion process to integrate the data of the distance measurement result from distance measurement unit 111, the object detection result from object detection unit 112, the object detection result from object detection unit 113, the object detection result from object detection unit 121, and the object detection result from object detection unit 122, and outputs the integrated data to trajectory calculation unit 116. The integration process can be executed by applying well-known techniques. The trajectory calculation unit 116 calculates the trajectory of the vehicle after recognizing the surrounding environment of the vehicle based on the data after the integration process, and outputs 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, the SoC2 receives the additional camera data D5 from the additional camera 5 and the LiDAR data D6 from the LiDAR 6. The SoC2 performs object detection using these data and transmits the object detection results to the SoC1.

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

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

[0033] [Vehicle control device operation] Next, the operation of the functions in the semiconductor chips 11 and 12 (SoC1 and SoC2) of the vehicle control device 1 will be described with reference to FIG. Fig. 4 is a diagram showing an example of the operation of the functions in the semiconductor chips 11 and 12 (SoC1 and SoC2) of the vehicle control device 1. In Fig. 4, the horizontal axis indicates time, and time progresses from left to right.

[0034] The vehicle control device 1 runs at a fixed processing cycle and needs to 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 (sonar) using sonar 2, object detection (camera) using camera 4, and object detection (radar) using radar 3, and then performs fusion, trajectory calculation, and control command value calculation. SoC2 performs object detection (camera) using additional camera 5 and object detection (LiDAR) using LiDAR 6, and then performs communication to send these object detection results to SoC1. In this example, a shared margin M is set from the end of control command value calculation in SoC1 until the start of the next cycle N+1. Note that communication to receive these object detection results is performed on the SoC1 side, but the description of "communication" on the SoC1 side is omitted.

[0036] [Average execution time and worst case execution time for each function] Figure 5 shows examples of the average execution time and worst-case execution time for each function. The average execution time refers to the average time it takes to execute the target function (task processing) on ​​each SoC. The worst-case execution time refers to the longest time it takes to execute the target function (task processing) on ​​each SoC.

[0037] In the example of FIG. 5, the average execution time (ms) and the worst-case execution time (ms) are as follows: The average execution time for distance measurement (sonar) is "5", and the worst execution time is "10". The average execution time for object detection (Radar) is “10”, and the worst execution time is “20”. The average execution time for object detection (camera) is "25", and the worst execution time is "40". Here, it is assumed that the time required to process camera data D4 from camera 4 in SoC1 is the same as the time required to process additional camera data D5 from additional camera 5 in SoC2, but they may be different. The average execution time for object detection (LiDAR) is “35”, and the worst execution time is “55”. The average execution time of the communication is "5", and the worst execution time is "20". The average execution time of the fusion is “25”, and the worst execution time is “35”. The average execution time of the trajectory calculation is "10", and the worst 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, and if the leeway 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 will enable the output of the entire system to be output within the specified processing cycle (150 ms).

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

[0040] Similarly, for task B, the execution time and probability have the following relationship: 20ms:20% 30ms:70% 40ms: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 of meeting the deadline with 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, if the number of objects detected by object detection increases, it is conceivable that fusion will also need to process many detected objects. For this reason, it is necessary to consider the case where there are dependencies between the execution times of multiple tasks. The correlation coefficient can be calculated by measuring the execution time of each task in response to input from each sensor. 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 behavior with shared margins] Figure 6 shows an example of a typical 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 Figure 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) processing 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 taking into account 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] Thus, in this embodiment, when the processing time of a preceding task in one semiconductor chip (SoC2) exceeds the reference time, the processor of another semiconductor chip (SoC1) suspends the start of the subsequent task until the processing of the preceding task is completed within the threshold time set for the slack time. This allows the other semiconductor chips to wait for the processing results of the preceding task on the one semiconductor chip within the threshold time set for the slack time, thereby enabling the other semiconductor chips to use the processing results of the preceding task on the one semiconductor chip for processing the subsequent task while meeting the deadline.

[0047] [Example of not using the results of predecessor tasks] Next, 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 will be described with reference to FIG.

[0048] FIG. 7 is a diagram showing an example of operation in the first embodiment when the result of the preceding task is not used to meet the deadline. In this embodiment, the nonvolatile memory 22 of SoC1 (see FIG. 2) stores a first program that uses the processing results of a preceding task in SoC2, and a second program that does not use the processing results of a preceding task in SoC2. SoC2 does not use the processing results of a preceding task in another SoC. Therefore, the nonvolatile memory 22 of SoC2 stores a program that is similar in this respect to the second program stored in SoC1. The second program uses only the processing results of tasks performed by its own SoC, and does not use the processing results of tasks performed 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 invalidates 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 the processing of the preceding task is completed within a threshold time set for the slack time (shared margin), and selects the second program if the 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 another semiconductor chip (SoC1) to execute a first fusion process as a subsequent task, which integrates the object detection result, which is the processing result of a preceding task in one semiconductor chip (SoC2), and the object detection result, which is the processing result of tasks (distance measurement (sonar), object detection (camera), object detection (radar)) in the other semiconductor chip, to generate first integrated object information. The second program causes the processor of another semiconductor chip (SoC1) to execute a second fusion process as a subsequent task, which generates second integrated object information using object detection results that are the processing results of tasks (distance measurement (sonar), object detection (camera), object detection (radar)) in the other semiconductor chip.

[0052] 7, it is assumed 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), exceeding the shared margin M by the time Te.

[0053] If the shared margin is exceeded, SoC1 will not be able to meet the deadline if it is waiting 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) ("time required to process the succeeding task" in the figure).

[0054] (Using the sum of worst-case execution times) For example, if meeting the deadline is essential, the timing for abandoning receiving task results from SoC2 can be determined based on the sum of the worst-case execution times. Figure 5 shows that 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 time remaining 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) Furthermore, the configuration of the system (vehicle system 10 in this embodiment) may allow the use of the previous control command value. For example, this may occur when an object around the vehicle is not moving or when the amount of movement of the object is less than a predetermined value. In this case, the timing to abandon receiving the task result from SoC2 can be determined, for example, from the sum of the 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 the task result from SoC2 when the remaining time until the start of the next cycle N+1 is 40 (=25+10+5) ms.

[0057] By setting it this way, it is possible to 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 in SoC2 at each processing cycle. For example, while SoC2 is processing a task, it predicts the execution time until all task processing is completed in SoC2 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) in SoC2 can be predicted based on the execution time of object detection (camera) in SoC2. SoC1 uses the predicted value of the 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 abandoning receiving the task result from SoC2 to either an abandonment timing based on the worst-case execution time (e.g., 60 ms) or an abandonment 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 (for example, 40 ms). By doing so, 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 in one semiconductor chip (SoC2) for processing the subsequent task while meeting the deadline.

[0061] Furthermore, if SoC1 determines that it can receive the task result from SoC2 after the sum of the average execution times of the succeeding tasks from the end time of cycle N, it may set the timing for abandoning receiving the task result from SoC2 to a timing based on the worst-case execution time (e.g., 60 ms). This allows SoC1 to reliably execute the calculation process of the control command value 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 across the entire system.

[0063] As described above, the vehicle control device (e.g., vehicle control device 1) according to this embodiment includes a processor (CPU 21) that processes sensor data received from sensors (see each sensor in Figure 1), and multiple semiconductor chips (SoC1 / SoC2) that each include a non-volatile memory (non-volatile memory 22) and a volatile memory (volatile memory 23). In this vehicle control device, a processing period including a reference time and a surplus 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 (SoC2) and the processing of a subsequent task in another semiconductor chip (SoC1) that uses the processing results of the preceding task is assigned. The processor of the other semiconductor chip calculates the remaining time available for processing the subsequent task in the processing cycle based on the execution time (e.g., average execution time / worst-case execution time) required to process the preceding task on one semiconductor chip and the slack time (shared margin), 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 feature selection considering remaining time] Next, as a second embodiment of the present invention, a configuration for selecting a function taking into consideration the remaining time in a semiconductor chip that executes processing of a preceding task or a semiconductor chip that executes processing of a succeeding task will be described with reference to FIG. In this embodiment, when the processor of a semiconductor chip (SoC2) determines that the processing time of one of multiple tasks in the semiconductor chip (SoC2) exceeds the reference time plus a threshold time, it executes another task to be executed after the one task in the semiconductor chip (SoC2) using processing content (simplified processing) with a shorter reference time. In addition, in this embodiment, if the processor of the other semiconductor chip (SoC1) determines that the processing time of a preceding task in one semiconductor chip (SoC2) exceeds the time obtained by adding a threshold time to the reference time, it executes the subsequent task with processing content (simplified processing) having a shorter reference time. Furthermore, in this embodiment, if the processor of the other semiconductor chip (SoC1) determines that the processing time of one task among multiple tasks in the other semiconductor chip (SoC1) exceeds the time obtained by adding a threshold time to the reference time, it may be configured to execute another task to be executed after the first task in the other semiconductor chip (SoC1) with processing content (simplified processing) having a shorter reference time.

[0066] (Example of simple processing performed on a single semiconductor chip (SoC2)) FIG. 8 is a diagram showing an example of selecting a function taking into consideration the remaining time in the SoC2 according to the 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. The same is true for distance measurement (sonar or non-sonar). Furthermore, for example, with regard to fusion, the amount of input data to SoC1 will differ when using task results from SoC1 and SoC2 compared to when using task results from SoC1 alone, so the average execution time and worst-case execution time are likely to differ. Therefore, SoC2 selects functions taking into account the remaining time at the start of each task process (strictly speaking, before the start), allowing it to process using the latest data (latest values) output by each sensor while meeting the deadline for the entire system.

[0067] For example, let's say we have Object Detection (LiDAR)-B 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 simpler process. Also, considering 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 a sharing margin of 15 ms (sharing margin Mc1 in the figure). If object detection (LiDAR) is executed on SoC2, it could consume a sharing margin of up to 20 (= 55 - 35) ms. Therefore, SoC2 selects object detection (LiDAR)-B, which has a shorter execution time than object detection (LiDAR). By doing so, the average execution time is reduced by 5 ms, and the sharing margin is consumed at most by only 10 (= 40 - 30) ms, as shown as sharing margin Mc2' in the figure. Therefore, SoC2 can be output to SoC1 without exceeding the shared margin M. When the process for calculating the control command value is completed in SoC1, the shared margin Mr' (M-Mc1-Mc2') remains.

[0069] (Example of simple processing performed on another semiconductor chip (SoC1)) Next, we will explain an example of function selection in another semiconductor chip (SoC1) assuming Fusion-B (not shown), which is a process simpler than Fusion. Generally, the average execution time is shorter than the worst-case execution time, so the average execution time of Fusion is shorter than the worst-case execution time of Fusion, and the average execution time of Fusion-B is shorter than the worst-case execution time of Fusion-B. Here, if we assume that the worst-case execution time of Fusion-B is shorter than the worst-case execution time of Fusion, the relationship between the respective times will be as follows: (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-B > 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 other patterns are assumed regarding the relationship with the remaining time of the shared margin. (1)-1: Remaining time of 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 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 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 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 shared margin

[0071] In addition, in relation to the above pattern (2), five further patterns are assumed in relation to the remaining time of the shared margin. (2)-1: Remaining time of 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 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 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 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 > Remaining time of shared margin

[0072] In addition, in relation to the above pattern (3), five further patterns are assumed in relation to the remaining time of the shared margin. (3)-1: Remaining time of 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 shared margin > Worst execution time of Fusion-B > Average execution time of Fusion-B > Average execution time of Fusion (3)-3: Worst execution time of Fusion > Worst execution time of Fusion-B > Remaining time of shared margin > Average execution time of Fusion-B > 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 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-B > Average execution time of Fusion > Remaining time of 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), it is advisable to select Fusion-B in (1)-3 and Fusion in (3)-3. In this case, the worst-case execution time cannot be secured, and it is not possible to guarantee 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 task processing is more likely to be completed within the deadline. Note that in order to select a function that is likely to complete processing within the deadline, it is also possible to take into account the variance of execution times. Specifically, it is possible to calculate the probability that execution will be completed within the remaining time of the shared margin for each of Fusion and Fusion-B, and select the one with the higher probability.

[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 of either one 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. By doing this, it is more likely 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.

[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 take 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 a 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 slack time (shared margin) required to process a preceding task in the one semiconductor chip (SoC2), and determines the processing content of the subsequent task based on the remaining time. Also, the processor of the one semiconductor chip (SoC2) calculates the remaining time available for processing in the one semiconductor chip (SoC2) in a processing cycle based on the execution time (e.g., average execution time / worst case execution time) and slack time (shared margin) required to process one task among multiple tasks in the one semiconductor chip (SoC2), and determines the processing content of the other task to be executed after the one task in the one semiconductor chip (SoC2) based on the remaining time. In addition, the processor of the other semiconductor chip (SoC1) may calculate the remaining time available for processing in the other semiconductor chip (SoC1) in the 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 slack 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 in 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> [Setting a shared margin to account for time synchronization errors between semiconductor chips] Next, as a third embodiment of the present invention, setting of a shared margin taking into consideration time synchronization errors between semiconductor chips will be described with reference to FIGS.

[0081] (First example) 9 is a diagram showing a first example of time synchronization errors between semiconductor chips (SoCs) according to the third embodiment of the present invention, in which the horizontal axis represents time. In this example, the volatile memory 23 (see FIG. 2) of the other 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 according to the update status of the timestamp stored in the volatile memory 23.

[0082] The vehicle control device 1 is composed of multiple SoCs, and therefore requires time synchronization between the SoCs. However, there is an error in time synchronization, 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 time of the SoC is ahead of the absolute time and cases where the time of the SoC 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 ε. Also, cycle N for SoC1 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 of SoC2 is earlier than the absolute time by an error ε, and the time of SoC1 is later than the absolute time by an error ε. In other words, the start of task processing in SoC2 is earlier than the specified absolute time by an error ε, and the start of task processing in SoC1 is 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 of SoC2, SoC1 will receive the output of SoC2 at absolute time t-2ε based on the time of SoC1. Here, the minus sign indicates a delay from 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 the timing of cycle N-1. Therefore, SoC2, which is 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 the processing of task B 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 process tasks appropriately without making a mistake in the order of the cycles.

[0087] (Second example) 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 which 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 error 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] Here, we assume that the time of SoC2 is slower than the absolute time by an error ε, and the time of 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 of SoC2, SoC1 receives the output of SoC2 at absolute time t+2ε based on the time of 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 enough time remaining until the end of cycle N. However, from SoC1's perspective, 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 in 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 (for example, 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' at an earlier time than in the case of task C and execute task D. 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 as well, SoC2 may add a timestamp to the output data to identify the period of the data.

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

[0093] [When the shared margin is apportioned to the processing of successor tasks] FIG. 11 is a diagram showing an example of allocating a shared margin to the processing of subsequent tasks in the fourth embodiment of the present invention. There may be cases where the processing time of a preceding task exceeds the shared margin multiple times in succession due to a hardware failure, etc. In other words, if the processing time of a preceding task on one semiconductor chip (SoC2) exceeds the reference time plus the threshold time (shared merge) for a specified number of consecutive times, the processor on the other semiconductor chip (SoC1) allocates part 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 Figure 11). For example, let's assume that SoC1 sets the timing for abandoning output from SoC2 based on the average execution time. If the shared margin is not allocated proportionally to the processing of subsequent tasks, if SoC1 takes too long to process the remaining subsequent tasks, 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, it is possible to meet the deadline even if it takes time to process the remaining subsequent tasks on SoC 1. Therefore, the vehicle control device 1 can perform processing using the latest value of the control command value instead of the previous control command value.

[0096] [If the preceding task process completes its execution within the time limit] FIG. 12 is a diagram showing an example in which the preceding task processing is completed within the time limit in the fourth embodiment of the present invention. In the example shown in Figure 12, the shared margin is allocated to SoC1, so 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 will eliminate the apportionment of the shared margin in the next cycle (here, cycle N-1) (a state similar to that shown in Figure 8). In other words, if the processing of the preceding task 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, SoC1 will stop allocating part of the threshold time to the succeeding task on the other semiconductor chip (SoC1) and will return the threshold time of the preceding task to its original state. This allows the original threshold time (shared margin) to be allocated to task processing on SoC2 in accordance with the error recovery on the SoC2 side. Therefore, SoC1 returns to a state where it can execute the processing of the succeeding task by using the latest processing result of the preceding task by SoC2.

[0098] On the other hand, if SoC1 receives output from SoC2 between the start timing t11 of the apportioned shared margin and the time required to process the subsequent task, SoC1 will already be performing fusion processing. In this case, SoC1 suspends the currently running process that does not use the results of the preceding task of SoC2, and starts a process that uses the results of the preceding task of SoC2.

[0099] <Modification> As described above, 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 the present invention is 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, the above-described configurations, functions, processing units, etc. may be partially or entirely realized 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 connected to each other. [Explanation of symbols]

[0102] 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 (pro rata), Mr...shared margin (remaining), Te...time

Claims

1. A vehicle control device including a plurality of semiconductor chips each having a processor for processing sensor data received from a sensor, a nonvolatile memory, and a volatile memory, a processing period including a reference time and a slack time required for processing each task included in the processing sequence is assigned to a processing sequence including at least processing of a preceding task in one semiconductor chip and processing of a subsequent task in another semiconductor chip that uses a processing result of the preceding task; The processor of the other semiconductor chip calculating a remaining time available for processing the succeeding task in the processing cycle based on the execution time required for processing the preceding task in the one semiconductor chip and the slack time, and determining at least one of a start time or a processing content of the succeeding task based on the remaining time; Vehicle control device.

2. The processor of the other semiconductor chip When the processing time of the preceding task in the one semiconductor chip exceeds the reference time, the start of the succeeding task is suspended until the processing of the preceding task is completed within a threshold time set for the slack time. The vehicle control device according to claim 1 .

3. The processor of the other semiconductor chip When the start of the succeeding task is suspended, if the processing of the preceding task is not completed within the threshold time, invalidating a start request of a program that uses the processing result of the preceding task. The vehicle control device according to claim 2.

4. The nonvolatile memory of the other semiconductor chip is a first program that utilizes a processing result of a preceding task in the one semiconductor chip; a second program that does not use the processing result of the preceding task in the one semiconductor chip; The processor of the other semiconductor chip If the processing of the preceding task is completed within the threshold time, a first program is selected, and if the processing of the preceding task is not completed within the threshold time, a second program is selected. The vehicle control device according to claim 2.

5. The plurality of semiconductor chips include executes an object detection process to detect an object based on the sensor data received from the sensor; The first program causing the processor of the other semiconductor chip to execute, as the subsequent task, a first fusion process that integrates an object detection result that is a processing result of the preceding task and an object detection result that is a processing result of a task in the other semiconductor chip, and generates first integrated object information; The second program causing the processor of the other semiconductor chip to execute, as the subsequent task, a second fusion process that generates second integrated object information using an object detection result that is a processing result of a task in the other semiconductor chip; The vehicle control device according to claim 4.

6. The processor of the other semiconductor chip When it is determined that the processing time of the preceding task in the one semiconductor chip exceeds the time that is the sum of the reference time and the threshold time, the succeeding task is executed with processing content that has a shorter reference time. The vehicle control device according to claim 2.

7. The processor of the one semiconductor chip When it is determined that the processing time of one of the tasks in the one semiconductor chip exceeds the time obtained by adding the threshold time to the reference time, the task to be executed after the one task in the one semiconductor chip is executed with processing content that has a shorter reference time. The vehicle control device according to claim 2.

8. The processor of the other semiconductor chip When it is determined that the processing time of one of the tasks in the other semiconductor chip exceeds the time obtained by adding the threshold time to the reference time, the task to be executed after the one task in the other semiconductor chip is executed with processing content that has a shorter reference time. The vehicle control device according to claim 2.

9. The volatile memory of the other semiconductor chip is storing a processing result of the preceding task in the one semiconductor chip and a timestamp indicating the processing time of the preceding task; The processor of the other semiconductor chip determining at least one of the start time and the processing content of the subsequent task according to an update status of the timestamp stored in the volatile memory; The vehicle control device according to claim 1 .

10. The processor of the other semiconductor chip A time corresponding to a time synchronization error between the one semiconductor chip and the other semiconductor chip with respect to absolute time is subtracted from the slack time to obtain the remaining time available for processing the subsequent task in the processing cycle. The vehicle control device according to claim 1 .

11. The processor of the other semiconductor chip When the processing time of the preceding task in the one semiconductor chip exceeds the time that the reference time is added to the threshold time for a specified number of consecutive times, a part of the threshold time is allocated to the succeeding task. The vehicle control device according to claim 2.

12. The processor of the other semiconductor chip If the processing of the preceding task in the one semiconductor chip is completed within the time period that is the reference time plus the threshold time period, the allocation of part of the threshold time period to the succeeding task is stopped. The vehicle control device according to claim 11.

13. A sensor data processing method in a vehicle control device including a plurality of semiconductor chips each including a processor for processing sensor data received from a sensor, a nonvolatile memory, and a volatile memory, comprising: a processing period including a reference time and a slack time required for processing each task included in a processing sequence including at least processing of a preceding task in one semiconductor chip and processing of a subsequent task in another semiconductor chip that uses a processing result of the preceding task is assigned; The processor of the other semiconductor chip calculating a remaining time available for processing the succeeding task in the processing cycle based on the execution time required for processing the preceding task in the one semiconductor chip and the slack time, and determining at least one of a start time or a processing content of the succeeding task based on the remaining time; Sensor data processing method.

Citation Information

Patent Citations

  • Electronic system and electronic control apparatus

    JP2023036264A