WO2025197262A1 - 車両制御装置及びセンサデータ処理方法 - Google Patents

車両制御装置及びセンサデータ処理方法

Info

Publication number
WO2025197262A1
WO2025197262A1 PCT/JP2025/000541 JP2025000541W WO2025197262A1 WO 2025197262 A1 WO2025197262 A1 WO 2025197262A1 JP 2025000541 W JP2025000541 W JP 2025000541W WO 2025197262 A1 WO2025197262 A1 WO 2025197262A1
Authority
WO
WIPO (PCT)
Prior art keywords
processing
time
task
semiconductor chip
control device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2025/000541
Other languages
English (en)
French (fr)
Inventor
有真 加藤
将史 溝口
健太郎 吉村
英之 坂本
崇顕 野海道
康浩 池田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Astemo Ltd
Original Assignee
Astemo Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Astemo Ltd filed Critical Astemo Ltd
Publication of WO2025197262A1 publication Critical patent/WO2025197262A1/ja
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt

Definitions

  • the present invention relates to a vehicle control device and a sensor data processing method that uses sensor detection results.
  • Patent Document 1 describes a technology that absorbs delays by switching the processing order in a vehicle control device made up of multiple devices.
  • 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.
  • Patent Document 1 executes processing that uses the processing results of the first ECU once the execution of processing that uses the processing results of the second ECU has been completed. This poses a challenge in absorbing delays when there is slack time remaining in the system as a whole.
  • the present invention was made in consideration of the above situation, and aims to propose a vehicle control device and sensor data processing method that can absorb delays by taking into account the slack time of the entire system.
  • one aspect of the present invention is a vehicle control device that includes multiple semiconductor chips each having a processor that processes sensor data received from a sensor, non-volatile memory, and volatile memory.
  • a processing cycle that includes a reference time and slack time required to process each task included in a processing sequence that includes at least the processing of a preceding task on one semiconductor chip and the processing of a subsequent task on another semiconductor chip that uses the processing results of the preceding task is assigned.
  • the processor on the other semiconductor chip 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, and determines at least one of the start time and processing content of the subsequent task based on the remaining time.
  • delays can be absorbed by taking into account the slack time of the entire system.
  • FIG. 1 is a diagram illustrating 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 the semiconductor chip according to the first embodiment of the present invention.
  • 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.
  • 3 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. 10 is a diagram showing an example of the average execution time and the worst execution time of each function.
  • FIG. 10 is a diagram illustrating a typical example of operation using a shared margin when task execution is delayed.
  • 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.
  • 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 a second embodiment of the present invention.
  • 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. (Addition)
  • FIG. 13 is a diagram showing an example of allocating a shared margin to subsequent processing in the fourth embodiment of the present invention.
  • FIG. 13 is a diagram illustrating an example in which the preceding process is completed within the time limit in the fourth embodiment of the present invention.
  • 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.
  • 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 7, an accelerator 8, and a brake 9.
  • the vehicle system 10 is a so-called vehicle.
  • 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.
  • 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, radar 3, and camera 4, as well as the processed data output from the semiconductor chip, to generate control commands for the steering 7, accelerator 8, and brake 9.
  • the semiconductor chip 11 then outputs the generated control commands to the steering 7, accelerator 8, and brake 9.
  • the vehicle control device 1 controls the behavior of the vehicle by operating the steering 7, accelerator 8, and brake 9 in accordance with control commands output from the semiconductor chip 11.
  • vehicle system 10 shown in Figure 1 is one example, and configurations with different types and numbers of sensors and different numbers of semiconductor chips are also possible.
  • semiconductor chip 11 will also be referred to as “SoC1”
  • semiconductor chip 12 will also be referred to as “SoC2.”
  • [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.
  • the hardware configuration will be described using the semiconductor chip 11 (SoC1) as an example.
  • SoC1 comprises a CPU (Central Processing Unit) 21, non-volatile memory 22, volatile memory 23, an input/output interface 24, and a network interface 25.
  • CPU Central Processing Unit
  • non-volatile memory 22 volatile memory 23, an input/output interface 24, and a network interface 25.
  • Each piece of hardware (block) is interconnected via a system bus.
  • This hardware constitutes a computing system (an example of a computer).
  • the CPU 21 CPU core
  • CPU 21 has a well-known timer function that uses a clock signal, etc.
  • a CPU is used as the processor, which is the arithmetic unit, other processors such as an MPU (Micro Processing Unit) may also be used.
  • MPU Micro Processing Unit
  • Non-volatile memory 22 is an example of a recording medium, and is capable of storing programs executed by CPU 21, data used by those programs, data obtained by running those programs, etc.
  • Examples of non-volatile memory 22 include HDDs (Hard Disk Drives), SSDs (Solid State Drives), optical or magnetic disk media, and semiconductor memory cards.
  • Variables, parameters, etc. generated during the CPU 21's calculation processing are temporarily written to the volatile memory 23, and these variables, parameters, etc. are read out by the CPU 21 as appropriate.
  • the input/output interface 24 is an interface that communicates signals and data with each sensor and actuator. SoC1 is equipped with an A/D (Analog/Digital) converter (not shown) that processes the input/output signals of each sensor, a driver circuit, etc. The input/output interface 24 may also serve as the A/D converter and driver circuit.
  • A/D Analog/Digital
  • the network interface 25 is configured to be able to send 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.
  • SoC2 The hardware configuration of semiconductor chip 12 (SoC2) is also similar to that of semiconductor chip 11 (SoC1).
  • SoC2 the CPU 21 executes programs stored in non-volatile memory 22, thereby realizing the functions of SoC2.
  • FIG. 3 is a diagram showing an example of the functional block configuration and overall operation flow of the vehicle control device 1.
  • the 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, 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, 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 the SoC1.
  • 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 the sonar data D2 acquired by the sonar 2, executes a process for measuring the distance from the vehicle to an object, and outputs the distance measurement result to the fusion unit 115.
  • the distance is measured 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 a radar, processing of LiDAR data from a LiDAR, etc. may be used.
  • the object detection unit 112 receives the radar data D3 acquired by the 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 SoC2 to the fusion unit 115.
  • 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 a known technique.
  • 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.
  • SoC2 receives additional camera data D5 from additional camera 5 and LiDAR data D6 from LiDAR 6. SoC2 uses this data to perform object detection and transmits the object detection results to SoC1.
  • 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. The SoC1 then integrates the object detection results and distance measurement results to recognize the surrounding environment of the vehicle and calculates the vehicle trajectory, 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.
  • the volatile memory 23 (see Figure 2) of SoC1 and SoC2 can be thought of as storing the results of task processing in SoC1 and SoC2 themselves, as well as timestamps indicating the processing times of those tasks.
  • 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.
  • the horizontal axis indicates time, and time progresses from left to right.
  • Vehicle control device 1 runs at a fixed processing cycle and must output control command values to control the vehicle during that processing cycle. Also, SoC1 and SoC2 can process tasks in parallel, but for example, fusion processing running on SoC1 requires output from SoC2.
  • SoC1 performs distance measurement using Sonar 2 (sonar), object detection using Camera 4 (camera), and object detection using Radar 3 (radar), and then performs fusion, trajectory calculation, and control command value calculation.
  • SoC2 performs object detection using Additional Camera 5 (camera) and object detection using LiDAR 6 (LiDAR), and then performs communication to send these object detection results to SoC1.
  • 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 communication to receive these object detection results is performed on the SoC1 side, but the "communication" on the SoC1 side is omitted.
  • [Average execution time and worst case execution time for each function] 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 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.
  • 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 case execution time is 40.
  • 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 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".
  • the critical path is object detection (camera) ⁇ object detection (LiDAR) ⁇ communication ⁇ fusion ⁇ trajectory calculation ⁇ control command value calculation.
  • 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 object detection (LiDAR) on SoC2 is delayed and requires 50 ms to execute, using the shared margin will enable the output of the entire system to be output within the specified processing cycle (150 ms).
  • the execution time and probability have the following relationship: 20ms: 20% 30ms: 70% 40ms: 10%
  • the shared margin is set to 14.5 ms, for example, there is a roughly 99.5% chance that the deadline will be met in a processing cycle of 60 ms. Setting a larger shared margin will improve the chance of meeting the deadline, but will result in less efficient resource utilization. For this reason, the shared margin must be set taking into account the trade-off between meeting the deadline and efficient resource utilization.
  • a 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 requires a time close to its worst-case execution time, task B will also require a time close to its worst-case execution time. Therefore, in order to meet the system deadline even if task A requires the worst-case execution time, it is necessary to set a shared margin that takes into account the worst-case execution time of task B.
  • [General behavior with shared margins] 6 shows an example of a 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.
  • SoC1 adjusts the execution timing of tasks to take into account the delay in object detection (LiDAR) on SoC2, enabling processing using the object detection (LiDAR) results while meeting the deadline.
  • SoC1 completes processing up to the calculation of the control command value, it still has the shared margin Mr (M-Mc) remaining.
  • the processor of the other semiconductor chip 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.
  • 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.
  • the nonvolatile memory 22 of SoC1 (see FIG. 2 ) stores a first program that uses the processing results of a preceding task on SoC2, and a second program that does not use the processing results of a preceding task on SoC2. SoC2 does not use the processing 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 processing results of tasks performed by its own SoC, and does not use the processing results of tasks performed by other SoCs.
  • 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.
  • the example shown in Figure 7 assumes that the execution of object detection (camera) and object detection (LiDAR) is delayed, resulting in the shared margin being exceeded.
  • the execution of object detection (camera) and object detection (LiDAR) is delayed, consuming shared margin Mc1 for object detection (camera) and shared margin Mc2 for object detection (LiDAR), exceeding shared margin M by time Te.
  • SoC1 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 subsequent task that should be executed in that processing cycle (cycle N in the diagram) ("time required to process the subsequent task" in the diagram).
  • the timing for abandoning receiving task results from SoC2 can be determined based on the sum of the worst-case 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 an object around the vehicle is not moving or when the object's movement is less than a predetermined value.
  • the timing for abandoning receiving task results from SoC2 may be dynamically switched between setting an abandonment timing based on the worst-case execution time (e.g., 60 ms) and an abandonment timing based on the average execution time (e.g., 40 ms).
  • the vehicle control device 1 needs to calculate the execution time of task processing in SoC2 for each processing cycle. For example, while processing a task in SoC2, it predicts the execution time until all task processing in SoC2 is completed and outputs the predicted value to SoC1.
  • 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 SoC2's execution time to calculate the time required to process the subsequent task and switch the abandonment timing.
  • SoC1 may set the timing for giving up on receiving the task results 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).
  • SoC1 determines that it can receive task results 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 can set the timing for abandoning receiving task results from SoC2 to an abandonment timing based on the average execution time (e.g., 40 ms).
  • the average execution time e.g. 40 ms.
  • SoC1 determines that it can receive task results from SoC2 after the sum of the average execution times of the subsequent tasks from the end time of cycle N, it can 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 execute the calculation process for control command values using the latest data (latest values) output by each sensor.
  • 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. This allows the system as a whole to flexibly absorb delays.
  • the vehicle control device e.g., vehicle control device 1
  • vehicle control device 1 includes a processor (CPU 21) that processes sensor data received from sensors (see the sensors in FIG. 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).
  • 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 a processing period that includes a reference time and a surplus time required to process each task included in the processing sequence.
  • 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.
  • the execution time e.g., average execution time/worst-case execution time
  • the slack time shared margin
  • the vehicle control device configured as described above, can absorb delays by taking into account the slack time of the entire vehicle control device (entire system). In other words, it is possible to absorb delays even when slack time remains in the entire system.
  • the processor of the other semiconductor chip (SoC1) determines that the processing time of a preceding task in one semiconductor chip (SoC2) exceeds the reference time plus a threshold time
  • the processor executes the subsequent task with processing content (simplified processing) having a shorter reference time.
  • 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 reference time plus a threshold time
  • the processor 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.
  • FIG. 8 is a diagram showing an example of selecting a function taking into account the remaining time in SoC2 according to the second embodiment of the present invention.
  • object detection camera, LiDAR
  • the average execution time and worst-case execution time for each method differ.
  • distance measurement sonar or non-sonar
  • SoC2 selects a function taking into account the remaining time at the start of each task process (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.
  • 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 simpler process.
  • the shared margin is set to 45 ms.
  • SoC1 completes the process up to the calculation of the control command value, the shared margin Mr'(M-Mc1-Mc2') remains.
  • Fusion should be selected.
  • Fusion-B should be selected. This ensures that the results of the fusion processing can be obtained. Note that Fusion may also be selected if it is acceptable to use the previous control command value.
  • the worst-case execution time for neither Fusion nor Fusion-B remains, but the average execution time for both remains ((1)-3, (3)-3), it is recommended to select Fusion-B in (1)-3 and Fusion in (3)-3.
  • the worst-case execution time cannot be secured, and it cannot be guaranteed that the task processing will be completed within the deadline. Therefore, by executing the function with the shorter average execution time from Fusion or Fusion-B, the possibility of completing the task processing within the deadline increases.
  • the variance of execution time may be taken into consideration in selecting a function that is likely to complete processing within the deadline. 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 function with the higher probability may be selected.
  • the vehicle control device has the same basic configuration as the vehicle control device 1 according to the first embodiment, but differs in the following respects.
  • the processor of another semiconductor chip SoC1 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 (SoC2) and the slack time (shared margin), and determines the processing content of the subsequent task based on the remaining time.
  • the execution time e.g., average execution time/worst-case execution time
  • the slack time shared margin
  • the processor of one semiconductor chip may calculate 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 slack time (shared margin) required to process one of the multiple tasks on the one semiconductor chip (SoC2), and determine the processing content of another task to be executed after the one task on the one semiconductor chip (SoC2) based on the remaining time.
  • the execution time e.g., average execution time/worst-case execution time
  • slack time shared margin
  • the processor of another semiconductor chip (SoC1) may calculate the remaining time available for processing on the other semiconductor chip (SoC1) 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 of the multiple tasks on the other semiconductor chip (SoC1), and determine the processing content of another task to be executed after the one task on the other semiconductor chip (SoC1) based on the remaining time.
  • the execution time e.g., average execution time/worst-case execution time
  • slack time shared margin
  • the vehicle control device may combine the configuration of the second embodiment with 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 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.
  • 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 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.
  • (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.
  • the volatile memory 23 (see FIG. 2) of the other semiconductor chip (SoC1) stores the processing result of the 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 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.
  • the vehicle control device 1 Since the vehicle control device 1 is configured with multiple SoCs, time synchronization between the SoCs is required. 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 SoC time is ahead of the absolute time and cases where the SoC time is behind the absolute time.
  • the original cycle N is from absolute time t2 to absolute time t5.
  • cycle N is from absolute time t1, which is ahead of absolute time t2 by an error ⁇ , to absolute time t4, which is ahead of absolute time t5 by an error ⁇ .
  • cycle N is from absolute time t3, which is behind absolute time t2 by an error ⁇ , to absolute time t6, which is behind absolute time t5 by an error ⁇ .
  • 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 process task B according to the update status of the timestamp.
  • SoC1 can process tasks appropriately without getting the cycle order wrong.
  • (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.
  • 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.
  • SoC2 selects and executes a function (for example, simple processing task C') that can be completed in time even after subtracting error 2 ⁇ from the shared margin.
  • Task C' has a shorter average execution time and 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.
  • object detection LiDAR
  • LiDAR object detection
  • SoC1 can then receive the output of task C' at an earlier time than in the case of task C and execute task D. This allows more time to remain on SoC1, thereby protecting dead time throughout the system.
  • SoC2 may also add a timestamp to the output data to identify which period the data belongs to.
  • FIG. 11 is a diagram showing an example of allocating the shared margin to the processing of a subsequent 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) for a specified number of consecutive times, the processor on the other semiconductor chip (SoC1) allocates a portion of the threshold time to the subsequent task.
  • SoC2 semiconductor chip
  • SoC1 allocates a portion of the threshold time to the subsequent task.
  • the shared margin is allocated to SoC1.
  • the shared margin is allocated before the start of the subsequent task (Fusion in FIG. 11). For example, 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 the subsequent tasks, if SoC1 takes time to process the remaining subsequent tasks, the deadline will not be met and SoC1 will output the previous control command value.
  • the deadline can be met even if SoC1 takes time to process the remaining subsequent tasks. This allows the vehicle control device 1 to perform processing using the most recent control command value, rather than the previous control command value.
  • FIG. 12 is a diagram showing an example in which the preceding task processing is completed within the allotted time in the fourth embodiment of the present invention.
  • 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).
  • SoC1 eliminates the shared margin in the next cycle (here, cycle N-1) (a state similar to that shown in FIG. 8).
  • cycle N-1 a state similar to that shown in FIG. 8.
  • the processing of a 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, the allocation of part of the threshold time to the subsequent task on the other semiconductor chip (SoC1) is stopped, and the threshold time of the preceding task is restored to its original state.
  • 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 the process that uses the results of the preceding task of SoC2.
  • Some or all of the above-mentioned configurations, functions, processing units, etc. may be realized in hardware, for example by designing them as integrated circuits.
  • Broad processor devices such as FPGAs (Field Programmable Gate Arrays) and ASICs (Application Specific Integrated Circuits) may also be used as hardware.
  • control lines and information lines shown are those considered necessary for explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be assumed that almost all components are interconnected.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)

Abstract

車両制御装置において、一の半導体チップにおける先行タスクの処理と、当該先行タスクの処理結果を利用する他の半導体チップにおける後続タスクの処理と、を少なくとも含む処理シーケンスに対し、当該処理シーケンスに含まれる各タスクの処理に要する基準時間及び余裕時間を含む処理周期が割り当てられている。他の半導体チップのプロセッサは、一の半導体チップにおける先行タスクの処理に要した実行時間及び余裕時間に基づいて、処理周期における後続タスクの処理に使用可能な残時間を求め、残時間に基づいて、後続タスクの開始時間又は処理内容の少なくとも一方を決定する。

Description

車両制御装置及びセンサデータ処理方法
　本発明は、センサの検知結果を用いる車両制御装置及びセンサデータ処理方法に関する。
　複数の機器で構成される車両制御装置において、処理順序を切り替えることにより遅延を吸収する既存技術として、特許文献１に記載の技術がある。特許文献１には、並列に実行可能な複数のタスクにおいて、それらのタスクの結果をそれぞれ使用する後続タスクをイベント駆動とし、イベント受信時刻からデッドラインまでの残り時間を計算することで、デッドラインを満たしながら処理順序を入れ替えることで、片方のタスクの遅延を吸収する方法が記載されている。
　特許文献１に記載の方法によれば、第一のＥＣＵからの出力の遅延時に、第二のＥＣＵの処理結果のみを使用する処理を先行して実行し、次に第一のＥＣＵからの処理結果を使用する処理を実行することで第一のＥＣＵに発生した遅延を吸収できる。
特開２０２３－３６２６４号公報
　しかしながら、特許文献１に記載の技術は、第二のＥＣＵの処理結果を利用する処理の実行が完了した時点で、第一のＥＣＵの処理結果を利用する処理を実行する。このため、システム全体として余裕時間が残されている場合においての遅延の吸収が課題となる。
　本発明は、上記の状況に鑑みてなされたものであり、システム全体としての余裕時間を考慮して遅延を吸収することができる車両制御装置及びセンサデータ処理方法を提案することを目的とする。
　上記課題を解決するために、本発明の一態様の車両制御装置は、センサから受信したセンサデータを処理するプロセッサと、不揮発性メモリと、揮発性メモリと、を有する半導体チップを複数備えた車両制御装置であって、一の半導体チップにおける先行タスクの処理と、当該先行タスクの処理結果を利用する他の半導体チップにおける後続タスクの処理と、を少なくとも含む処理シーケンスに対し、当該処理シーケンスに含まれる各タスクの処理に要する基準時間及び余裕時間を含む処理周期が割り当てられており、他の半導体チップのプロセッサは、一の半導体チップにおける先行タスクの処理に要した実行時間及び余裕時間に基づいて、処理周期における後続タスクの処理に使用可能な残時間を求め、残時間に基づいて、後続タスクの開始時間又は処理内容の少なくとも一方を決定する。
　本発明の少なくとも一態様によれば、システム全体としての余裕時間を考慮して遅延を吸収することができる。
　上記した以外の課題、構成及び効果は、以下の発明を実施するための形態の説明により明らかにされる。
本発明の第１の実施形態に係る車両制御装置の構成例を示した図である。 本発明の第１の実施形態に係る半導体チップが備えるコンピューターのハードウェア構成例を示すブロック図である。 本発明の第１の実施形態に係る車両制御装置の機能ブロックの構成及び全体動作の流れの例を示した図である。 本発明の第１の実施形態に係る車両制御装置の各半導体チップにおける機能の動作例を示した図である。 各機能の平均実行時間と最悪実行時間の例を示した図である。 タスクの実行が遅延した際の共有マージンを使用した一般的な動作例を示した図である。 本発明の第１の実施形態においてデッドラインを守るために先行タスクの結果を使用しない例を示した図である。 本発明の第２の実施形態に係る先行タスクの処理を実行する半導体チップにおいて残り時間を考慮した機能の選択の例を示した図である。 本発明の第３の実施形態に係る半導体チップ間の時刻同期誤差の第１の例を示した図である。 （追加）本発明の第３の実施形態に係る半導体チップ間の時刻同期誤差の第２の例を示した図である。 本発明の第４の実施形態において後続の処理に共有マージンを按分する例を示した図である。 本発明の第４の実施形態において先行する処理が時間内に実行を完了した場合の例を示した図である。
　以下、添付図面を参照して、本発明を実施するための形態（以下、「実施形態」と称する）の例について説明する。
　本明細書及び添付図面において、同一の構成要素又は類似の構成要素には同一の符号を付与し、重複する説明を省略する、又は差分を中心とした説明のみを行う場合がある。また、同一又は類似の構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。なお、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明することもある。各構成要素の数は、特に断りがない限り単数でも複数でもよい。
　以下の実施形態の例では、各種情報をテーブル形式で説明するが、各種情報はテーブル形式以外のデータ形式であってもよい。また、例えば、「ＸＸ情報」、「ＸＸテーブル」、「ＸＸリスト」、「ＸＸ一覧」等の各種呼称について、これらは互換可能である。
＜第１の実施形態＞
　まず、本発明の第１の実施形態に係る車両制御装置について説明する。
　図１は、本発明の第１の実施形態に係る車両制御装置を含む車両システムの構成例を示した図である。図１において、車両システム１０は、ソナー２、Ｒａｄａｒ３、カメラ４、ＬｉＤＡＲ（Light Detection And Ranging）６、及び追加カメラ５といったセンサと、車両制御装置１と、ステアリング７、アクセル８、及びブレーキ９といった装置とを備える。車両システム１０はいわゆる車両である。
　ソナー２、Ｒａｄａｒ３、カメラ４、ＬｉＤＡＲ６、及び追加カメラ５は、車両システム１０のボディ部に取り付けられる。追加カメラ５は、カメラ４を補完するカメラである。例えば、カメラ４が車両前方に取り付けられたフロントカメラである場合、追加カメラ５は車両の後方や側方に取り付けられたカメラである。ただし、追加カメラ５が車両前方に取り付けられていてもよい。車両制御装置１は、車載用の電子制御装置（ＥＣＵ）である。図１に示したセンサや装置は車両システム１０の一部を示したに過ぎない。
［車両制御装置の構成］
　車両制御装置１は、ソナー２、Ｒａｄａｒ３、カメラ４、ＬｉＤＡＲ６、及び追加カメラ５からセンシングデータを受信し、ステアリング７、アクセル８、及びブレーキ９へ制御指令を出力する。車両制御装置１は、半導体チップ１１及び半導体チップ１２を備える。半導体チップ１１及び半導体チップ１２は、一例としてＳｏＣ（System on Chip）の形態で構成されている。
　半導体チップ１２は、追加カメラ５及びＬｉＤＡＲ６から受け取ったセンシングデータを処理し、処理済みのデータを半導体チップ１１へ出力する。
　半導体チップ１１は、ソナー２、Ｒａｄａｒ３、及びカメラ４から受け取ったセンシングデータ、並びに半導体チップから出力される処理済みデータを処理して、ステアリング７、アクセル８、及びブレーキ９の各々に対する制御指令を生成する。そして、半導体チップ１１は、生成した制御指令を対象のステアリング７、アクセル８、及びブレーキ９へ出力する。
　車両制御装置１は、半導体チップ１１から出力する制御指令によりステアリング７、アクセル８、及びブレーキ９を動作させて車両の挙動を制御する。
　図１に記載した車両システム１０の構成は一例であり、例えばセンサの種類や数、半導体チップの数を増減した構成も考えられる。以降、本明細書では、半導体チップ１１を「ＳｏＣ１」、半導体チップ１２を「ＳｏＣ２」とも記す。
［車両制御装置のハードウェア構成］
　図２は、車両制御装置１の半導体チップ１１，１２が備えるコンピューターのハードウェア構成例を示すブロック図である。ここでは、半導体チップ１１（ＳｏＣ１）を例にハードウェア構成について説明する。
　図２に示すように、ＳｏＣ１は、ＣＰＵ（Central Processing Unit）２１、不揮発性メモリ２２、揮発性メモリ２３、入出力インターフェース２４、及びネットワークインターフェース２５を備える。各ハードウェア（ブロック）は、システムバスを介して相互に接続されている。これらのハードウェアは、計算機システム（コンピューターの一例）を構成する。ＣＰＵ２１（ＣＰＵコア）が、ソフトウェアのプログラムを不揮発性メモリ２２から読み出し、該プログラムを揮発性メモリ２３に展開して実行することにより、半導体チップ１１の機能が実現される。
　ＣＰＵ２１は、クロック信号等を利用した周知のタイマ機能を備える。なお、演算装置であるプロセッサにＣＰＵを用いたが、ＭＰＵ（Micro Processing Unit）等の他のプロセッサを用いてもよい。
　不揮発性メモリ２２は、記録媒体の一例であり、ＣＰＵ２１が実行するプログラム、そのプログラムが使用するデータやプログラムを実行して得られたデータなどを保存することが可能である。不揮発性メモリ２２としては、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、光や磁気を利用するディスク媒体、又は半導体メモリカード等が用いられる。
　揮発性メモリ２３には、ＣＰＵ２１の演算処理の途中で発生した変数やパラメーター等が一時的に書き込まれ、これらの変数やパラメーター等がＣＰＵ２１によって適宜読み出される。
　入出力インターフェース２４は、各センサや各アクチュエータと信号やデータの通信を行うインターフェースである。ＳｏＣ１は、各センサの入出力信号を処理する図示しないＡ／Ｄ（Analog/digital）変換器、ドライバ回路等を備えている。入出力インターフェース２４がＡ／Ｄ変換器やドライバ回路を兼ねてもよい。
　ネットワークインターフェース２５は、端子が接続された車載ネットワークを介して、車載ネットワークに接続された他の電子制御装置と各種のデータを送受信できるように構成されている。
　半導体チップ１２（ＳｏＣ２）のハードウェア構成についても、半導体チップ１１（ＳｏＣ１）と同様である。ＳｏＣ２において、ＣＰＵ２１が不揮発性メモリ２２に記録されたプログラムを実行することにより、ＳｏＣ２の機能が実現される。
［機能ブロックの構成及び全体動作の流れ］
　次に、車両制御装置１の機能及び動作について、図３を参照して説明する。
　図３は、車両制御装置１の機能ブロックの構成及び全体動作の流れの例を示した図である。
　ＳｏＣ２は、物体検知部１２１、物体検知部１２２、及び通信部１２３を備える。
　物体検知部１２１は、追加カメラ５で撮影された画像データである追加カメラデータＤ５を受け取って物体検知の処理を実行し、物体検知結果を通信部１２３へ出力する。
　物体検知部１２２は、ＬｉＤＡＲ６で取得されたＬｉＤＡＲデータＤ６を受け取って物体検知の処理を実行し、物体検知結果を通信部１２３へ出力する。
　通信部１２３は、物体検知部１２１から入力された物体検知結果と物体検知部１２２から入力された物体検知結果を、ＳｏＣ１の通信部１１４へ送信する。
　ＳｏＣ１は、距離測定部１１１、物体検知部１１２、物体検知部１１３、通信部１１４、フュージョン部１１５、軌道計算部１１６、及び制御指令値算出部１１７を備える。
　距離測定部１１１は、ソナー２で取得されたソナーデータＤ２を受け取って自車から物体までの距離を測定する処理を実行し、距離測定結果をフュージョン部１１５へ出力する。なお、本実施形態では、ソナーを用いて距離測定を実施するが他の方法もよい。例えば、カメラで撮影した画像データの画像処理（視差情報）、ＲａｄａｒのＲａｄａｒデータの処理、ＬｉＤＡＲのＬｉＤＡＲデータの処理などが挙げられる。
　物体検知部１１２は、Ｒａｄａｒ３で取得されたＲａｄａｒデータＤ３を受け取って物体検知の処理を実行し、物体検知結果をフュージョン部１１５へ出力する。
　物体検知部１１３は、カメラ４で撮影された画像データであるカメラデータＤ４を受け取って物体検知の処理を実行し、物体検知結果をフュージョン部１１５へ出力する。
　通信部１１４は、ＳｏＣ２の通信部１２３から受信した物体検知部１２１の物体検知結果と物体検知部１２２の物体検知結果を、フュージョン部１１５へ出力する。
　フュージョン部１１５は、距離測定部１１１の距離測定結果、物体検知部１１２の物体検知結果、物体検知部１１３の物体検知結果、物体検知部１２１の物体検知結果、及び物体検知部１２２の物体検知結果の各データを統合するフュージョン処理を実行し、統合処理されたデータを軌道計算部１１６へ出力する。統合処理については、周知の技術を適用して実行できる。
　軌道計算部１１６は、統合処理後のデータに基づいて、自車の周辺環境を認識した上で車両の軌道を計算し、軌道計算結果を制御指令値算出部１１７へ出力する。
　制御指令値算出部１１７は、軌道計算部１１６から軌道計算結果を受け取って、計算した車両の軌道を実現するための制御指令値を算出する。
　上述した機能構成により、ＳｏＣ２は、追加カメラ５からの追加カメラデータＤ５及びＬｉＤＡＲ６からのＬｉＤＡＲデータＤ６を受け取る。ＳｏＣ２は、これらのデータを用いて物体検知を行い、ＳｏＣ１へ物体検知結果を送信する。
　ＳｏＣ１は、ソナー２からのソナーデータＤ２、Ｒａｄａｒ３からのＲａｄａｒデータＤ３、及びカメラ４からのカメラデータＤ４を受け取り、これらのデータを用いて物体検知や距離測定を行う。また、ＳｏＣ１は、ＳｏＣ２から追加カメラデータＤ５やＬｉＤＡＲデータＤ６に基づく物体検知結果を受け取る。
　そして、ＳｏＣ１は、これらの物体検知結果や距離測定結果を統合して、自車の周辺環境を認識した上で車両の軌道を計算する。そして、ＳｏＣ１は、計算した車両の軌道を実現するための制御指令値を算出し、ステアリング７、アクセル８、及びブレーキ９へ制御指令値を出力する。
　ＳｏＣ１及びＳｏＣ２の揮発性メモリ２３（図２参照）は、ＳｏＣ１及びＳｏＣ２自身におけるタスクの処理結果及び当該タスクの処理時間を示すタイムスタンプを記憶していると考えてよい。
［車両制御装置の動作］
　次に、車両制御装置１の各半導体チップ１１，１２（ＳｏＣ１，２）における機能の動作について、図４を参照して説明する。
　図４は、車両制御装置１の各半導体チップ１１，１２（ＳｏＣ１，２）における機能の動作例を示した図である。図４において横軸は時刻を示し、時間は左から右の方向へ経過する。
　車両制御装置１は一定の処理周期で実行され、その処理周期の間に車両を制御するための制御指令値を出力する必要がある。また、ＳｏＣ１及びＳｏＣ２は並列でタスクを処理することが可能であるが、例えば、ＳｏＣ１で実行されているフュージョンの処理は、ＳｏＣ２からの出力を必要とする。
　図４の例では、サイクルＮにおいてＳｏＣ１は、ソナー２による距離測定（ソナー）、カメラ４による物体検知（カメラ）、及びＲａｄａｒ３による物体検知（Ｒａｄａｒ）を実行した後、フュージョン、軌道計算、及び制御指令値算出を実行する。ＳｏＣ２は、追加カメラ５による物体検知（カメラ）、及びＬｉＤＡＲ６による物体検知（ＬｉＤＡＲ）を実行した後、それらの物体検知結果をＳｏＣ１へ送信する通信を実行する。この例では、ＳｏＣ１における制御指令値算出の終了後、次のサイクルＮ＋１が開始されるまでの間に共有マージンＭが設定されている。なお、ＳｏＣ１側ではそれらの物体検知結果を受信する通信が実行されるが、ＳｏＣ１側における「通信」の記載を省略している。
［各機能の平均実行時間と最悪実行時間］
　ここで、図５に、各機能の平均実行時間と最悪実行時間の例を示す。平均実行時間は、各ＳｏＣで対象機能（タスク処理）を実行するのにかかる平均的な時間を指す。最悪実行時間は、各ＳｏＣで対象機能（タスク処理）を実行するのにかかる最長の時間を指す。
　図５の例では、平均実行時間（ｍｓ）及び最悪実行時間（ｍｓ）は以下のとおりである。
　距離測定（ソナー）の平均実行時間は“５”、最悪実行時間は“１０”である。
　物体検知（Ｒａｄａｒ）の平均実行時間は“１０”、最悪実行時間は“２０”である。
　物体検知（カメラ）の平均実行時間は“２５”、最悪実行時間は“４０”である。ここでは、ＳｏＣ１におけるカメラ４のカメラデータＤ４の処理と、ＳｏＣ２における追加カメラ５の追加カメラデータＤ５の処理に要する時間が同じ場合を想定しているが、異なっていてもよい。
　物体検知（ＬｉＤＡＲ）の平均実行時間は“３５”、最悪実行時間は“５５”である。
　通信の平均実行時間は“５”、最悪実行時間は“２０”である。
　フュージョンの平均実行時間は“２５”、最悪実行時間は“３５”である。
　軌道計算の平均実行時間は“１０”、最悪実行時間は“１５”である。
　制御指令値算出の平均実行時間は“５”、最悪実行時間は“１０”である。
　図４に示した機能の動作の場合、クリティカルパスは、物体検知（カメラ）→物体検知（ＬｉＤＡＲ）→通信→フュージョン→軌道計算→制御指令値算出となる。ここで、クリティカルパスの基準時間（平均実行時間）は１０５（２５＋３５＋５＋２５＋１０＋５）ｍｓであり、余裕時間（共有マージン）を４５ｍｓと設定すると、処理周期が１５０ｍｓとなる。共有マージンは、いずれかの機能の遅延（タスク処理の遅延）を吸収するために用いられる。例えば、ＳｏＣ２の物体検知（ＬｉＤＡＲ）が遅延して実行時間に５０ｍｓを要したとしても、共有マージンを用いることで、システム全体の出力は、定めた処理周期（１５０ｍｓ）以内の出力が可能となる。
［タスクの実行時間を考慮した共有マージンの設定について］
　次に、タスクの実行時間を考慮した共有マージンの設定の考え方について説明する。
　例えば、あるタスクＡに関して、実行時間とその時間で処理される確率が下記の関係であったとする。
　　１０ｍｓ：１５％
　　１５ｍｓ：５０％
　　２０ｍｓ：３０％
　　３０ｍｓ：５％
　同様に、タスクＢに関して、実行時間と確率が下記の関係であったとする。
　　２０ｍｓ：２０％
　　３０ｍｓ：７０％
　　４０ｍｓ：１０％
　これらの２つのタスクＡ，Ｂに依存関係がなかったとすると、実行時間は下記１２パターンである。また、２つのタスクの発生率は、単純に２つのタスクの確率を掛け合わせた値となる。
　　１０ｍｓ＋２０ｍｓ：１５％＊２０％＝３％
　　１０ｍｓ＋３０ｍｓ：１５％＊７０％＝１０．５％
　　１０ｍｓ＋４０ｍｓ：１５％＊１０％＝１．５％
　　１５ｍｓ＋２０ｍｓ：５０％＊２０％＝１０％
　　１５ｍｓ＋３０ｍｓ：５０％＊７０％＝３５％
　　１５ｍｓ＋４０ｍｓ：５０％＊１０％＝５％
　　２０ｍｓ＋２０ｍｓ：３０％＊２０％＝６％
　　２０ｍｓ＋３０ｍｓ：３０％＊７０％＝２１％
　　２０ｍｓ＋４０ｍｓ：３０％＊１０％＝３％
　　３０ｍｓ＋２０ｍｓ：５％＊２０％＝１％
　　３０ｍｓ＋３０ｍｓ：５％＊７０％＝３．５％
　　３０ｍｓ＋４０ｍｓ：５％＊１０％＝０．５％
　タスクＡの平均実行時間は１６．５ｍｓ、タスクＢの平均実行時間は２９ｍｓであるため、例えば共有マージンを１４．５ｍｓと設定すると、処理周期６０ｍｓにおいて約９９．５％の確率でデッドラインを遵守することができる。共有マージンを大きく設定すると、デッドラインを遵守できる確率は向上するが、リソースの利用効率が悪化する。このため、デッドラインの遵守とリソースの利用効率とのトレードオフを踏まえて、共有マージンを設定する必要がある。
　一方で、例えば物体検知で検知した物体の数が多くなると、フュージョンにおいても多くの検知した物体に対して処理を行うことが考えられる。このため、複数のタスクの実行時間に依存関係が存在する場合についても想定する必要がある。
　各センサからの入力に対して、各タスクの実行時間を計測することで、相関係数を求めることができる。例えば、タスクＡとタスクＢに正の相関があると判断された場合は、タスクＡが最悪実行時間に近い時間を要するとき、タスクＢも最悪実行時間に近い時間を要することになる。したがって、タスクＡが最悪実行時間であってもシステムのデッドラインを守るためには、タスクＢの最悪実行時間を考慮した共有マージンの設定が必要となる。
［共有マージンを用いた一般的な動作］
　図６は、タスクの実行が遅延した際の共有マージンを使用した一般的な動作例を示した図である。ＳｏＣ１及びＳｏＣ２のタスク処理を含む処理シーケンスは、図４に記載した例と同じである。
　図６に示す例では、ＳｏＣ２における物体検知（ＬｉＤＡＲ）の実行が遅延した場合を想定している。平均実行時間内に物体検知（ＬｉＤＡＲ）の処理が終わらなかった場合は、共有マージンＭから共有マージンＭｃを消費する。ＳｏＣ１は、ＳｏＣ２における物体検知（ＬｉＤＡＲ）の遅延を考慮してタスクの実行タイミングを調整することで、デッドラインを守りつつ、物体検知（ＬｉＤＡＲ）の結果を用いた処理を可能とする。ＳｏＣ１では、制御指令値算出まで処理が終了したときに、まだ共有マージンＭｒ（Ｍ－Ｍｃ）が残っている。
　このように、本実施形態では、他の半導体チップ（ＳｏＣ１）のプロセッサは、一の半導体チップ（ＳｏＣ２）における先行タスクの処理時間が基準時間を超過すると、余裕時間に対して設定した閾値の時間内で先行タスクの処理が完了するまで後続タスクの開始を保留する。
　これにより、他の半導体チップは、余裕時間に対して設定した閾値の時間内で一の半導体チップにおける先行タスクの処理結果を待つ。これにより、他の半導体チップは、デッドラインを守りながら、一の半導体チップにおける先行タスクの処理結果を後続タスクの処理に利用することができる。
［先行タスクの結果を使用しない例］
　次に、本発明の第１の実施形態においてデッドラインを守るために先行タスクの結果を使用しない例について、図７を参照して説明する。
　図７は、第１の実施形態においてデッドラインを守るために先行タスクの結果を使用しない場合の動作例を示した図である。
　本実施形態では、ＳｏＣ１の不揮発性メモリ２２（図２参照）は、ＳｏＣ２における先行タスクの処理結果を利用する第一のプログラムと、ＳｏＣ２における先行タスクの処理結果を利用しない第二のプログラムと、を記憶する。ＳｏＣ２は、他のＳｏＣにおける先行タスクの処理結果を利用しない。このため、ＳｏＣ２の不揮発性メモリ２２は、この点でＳｏＣ１に記憶された第二のプログラムと類似したプログラムを記憶する。第二のプログラムは、自身のＳｏＣによるタスクの処理結果のみを利用し、他のＳｏＣによるタスクの処理結果を利用しない。
　すなわち、車両制御装置１では、他の半導体チップ（ＳｏＣ１）のプロセッサは、後続タスクの開始を保留した場合に、余裕時間（共有マージン）に対して設定した閾値の時間内で先行タスクの処理が完了しないときには、先行タスクの処理結果を利用するプログラムの開始要求を無効化する。
　そして、車両制御装置１では、他の半導体チップ（ＳｏＣ１）のプロセッサは、余裕時間（共有マージン）に対して設定した閾値の時間内に先行タスクの処理が完了した場合には、第一のプログラムを選択し、上記閾値の時間内に先行タスクの処理が完了しない場合には、第二のプログラムを選択する。
　ここで、第一のプログラム及び第二のプログラムについて説明する。
　第一のプログラムは、他の半導体チップ（ＳｏＣ１）のプロセッサに、一の半導体チップ（ＳｏＣ２）における先行タスクの処理結果である物体検知結果と当該他の半導体チップにおけるタスク（距離測定（ソナー）、物体検知（カメラ）、物体検知（Ｒａｄａｒ））の処理結果である物体検知結果とを統合して、第一の統合物体情報を生成する第一のフュージョン処理を後続タスクとして実行させる。
　第二のプログラムは、他の半導体チップ（ＳｏＣ１）のプロセッサに、当該他の半導体チップにおけるタスク（距離測定（ソナー）、物体検知（カメラ）、物体検知（Ｒａｄａｒ））の処理結果である物体検知結果を用いて、第二の統合物体情報を生成する第二のフュージョン処理を後続タスクとして実行させる。
　図７に示す例では、物体検知（カメラ）と物体検知（ＬｉＤＡＲ）の実行が遅延し、共有マージンを超過する場合を想定している。ここでは、物体検知（カメラ）と物体検知（ＬｉＤＡＲ）の実行が遅延し、物体検知（カメラ）において共有マージンＭｃ１及び物体検知（ＬｉＤＡＲ）において共有マージンＭｃ２を消費し、時間Ｔｅ分だけ共有マージンＭを超過している。
　共有マージンを超過した場合、ＳｏＣ１はＳｏＣ２のタスク結果を待機していると、デッドラインを守ることができない。そのため、ＳｏＣ１ではその処理周期（図中のサイクルＮ）で実行すべき後続タスクの実行時間（図中「後続タスクの処理に必要な時間」）を考慮して、ＳｏＣ２からのタスク結果の受け取りを断念する必要がある。
（最悪実行時間の和を用いる場合）
　例えば、デッドラインの順守が必須の場合は、最悪実行時間の和から、ＳｏＣ２からのタスク結果の受け取りを断念するタイミングを決定することができる。図５よりフュージョンの最悪実行時間は３５ｍｓ、軌道計算の最悪実行時間は１５ｍｓ、制御指令値算出の最悪実行時間は１０ｍｓである。このため、ＳｏＣ１は、次のサイクルＮ＋１の開始タイミングまでの残りの時間が６０（＝３５＋１５＋１０）ｍｓとなったタイミングｔｇで、ＳｏＣ２からのタスク結果の受け取りを断念する。
　このように設定することで、ＳｏＣ１で実行する残りの機能が全て最悪実行時間を要したとしても、デッドラインを遵守することができる。ただし、デッドラインを遵守することができるが、フュージョンの処理において、ＳｏＣ２からの出力を用いることができない。
（平均実行時間の和を用いる場合）
　また、システム（本実施形態では車両システム１０）の構成として前回の制御指令値を用いることが許容される場合がある。例えば、車両周辺の物体が動いていない場合や物体の移動量が所定値よりも小さい場合である。その場合、例えば平均実行時間の和から、ＳｏＣ２からのタスク結果の受け取りを断念するタイミングを決定することができる。図５よりフュージョンの平均実行時間は２５ｍｓ、軌道計算の平均実行時間は１０ｍｓ、制御指令値算出の平均実行時間は５ｍｓである。このため、ＳｏＣ１は、次のサイクルＮ＋１の開始タイミングまでの残りの時間が４０（＝２５＋１０＋５）ｍｓとなったタイミングで、ＳｏＣ２からのタスク結果の受け取りを断念することとなる。
　このように設定することで、最悪実行時間をベースに算出する場合と比較し、ＳｏＣ２によるタスク処理の大きな遅延を吸収することができる。一方で、ＳｏＣ１で実行する残りの機能に要する時間によっては、デッドラインを遵守するために、前回の制御指令値を使う必要がある。
　さらに、ＳｏＣ２からのタスク結果の受け取りを断念するタイミングを、最悪実行時間に基づく断念タイミング（例えば６０ｍｓ）と平均実行時間に基づく断念タイミング（例えば４０ｍｓ）のいずれで設定するか動的に切り替える構成としてもよい。この場合、車両制御装置１は、ＳｏＣ２におけるタスク処理の実行時間を処理周期の都度計算する必要がある。例えば、ＳｏＣ２におけるタスク処理中に、ＳｏＣ２において全てのタスク処理が完了するまでの実行時間を予測し、予測値をＳｏＣ１に出力する。前述のとおり、複数のタスクの実行時間には依存関係が存在する場合がある。例えば、ＳｏＣ２における物体検知（カメラ）の実行時間に基づいて、ＳｏＣ２における物体検知（ＬｉＤＡＲ）の実行時間を予測することができる。ＳｏＣ１は、ＳｏＣ２の実行時間の予測値を用いて後続タスクの処理に必要な時間を計算し、断念タイミングを切り替える。
　ＳｏＣ１は、サイクルＮの終了時刻から後続タスクの最悪実行時間の和よりも前にＳｏＣ２からタスク結果を受け取ることができると判断した場合、ＳｏＣ２からのタスク結果の受け取りを断念するタイミングを、最悪実行時間に基づく断念タイミング（例えば６０ｍｓ）と平均実行時間に基づく断念タイミング（例えば４０ｍｓ）のいずれに設定してもよい。
　また、ＳｏＣ１は、サイクルＮの終了時刻から後続タスクの最悪実行時間の和よりも後であって、後続タスクの平均実行時間の和よりも前にＳｏＣ２からタスク結果を受け取ることができると判断した場合、ＳｏＣ２からのタスク結果の受け取りを断念するタイミングを、平均実行時間に基づく断念タイミング（例えば４０ｍｓ）に設定するとよい。このようにすることで、ＳｏＣ２からタスク結果を受け取ることが期待できるため、他の半導体チップ（ＳｏＣ１）は、デッドラインを守りながら、一の半導体チップ（ＳｏＣ２）における先行タスクの処理結果を後続タスクの処理に利用することができる。
　また、ＳｏＣ１は、サイクルＮの終了時刻から後続タスクの平均実行時間の和よりも後にＳｏＣ２からタスク結果を受け取ることができると判断した場合、ＳｏＣ２からのタスク結果の受け取りを断念するタイミングを、最悪実行時間に基づく断念タイミング（例えば６０ｍｓ）に設定するとよい。このようにすることで、ＳｏＣ１は、各センサが出力する最新データ（最新値）を用いた制御指令値の算出処理を確実に実行することができる。
　これにより、ＳｏＣ２の実行時間の予測値に応じて、ＳｏＣ１におけるＳｏＣ２からのタスク結果の受け取りの断念タイミングを変更することができ、デッドラインの遵守を柔軟に実現できる。それゆえ、システム全体として遅延を柔軟に吸収することができる。
　以上のとおり、本実施形態に係る車両制御装置（例えば、車両制御装置１）は、センサ（図１の各センサを参照）から受信したセンサデータを処理するプロセッサ（ＣＰＵ２１）と、不揮発性メモリ（不揮発性メモリ２２）と、揮発性メモリ（揮発性メモリ２３）と、を有する半導体チップ（ＳｏＣ１／ＳｏＣ２）を複数備える。
　この車両制御装置では、一の半導体チップ（ＳｏＣ２）における先行タスクの処理と、当該先行タスクの処理結果を利用する他の半導体チップ（ＳｏＣ１）における後続タスクの処理と、を少なくとも含む処理シーケンスに対し、当該処理シーケンスに含まれる各タスクの処理に要する基準時間及び余裕時間を含む処理周期が割り当てられている。
　他の半導体チップのプロセッサは、一の半導体チップにおける先行タスクの処理に要した実行時間（例えば、平均実行時間／最悪実行時間）及び余裕時間（共有マージン）に基づいて、処理周期における後続タスクの処理に使用可能な残時間を求め、残時間に基づいて、後続タスクの開始時間を決定する。
　上記構成の本実施形態に係る車両制御装置によれば、車両制御装置全体（システム全体）としての余裕時間を考慮して遅延を吸収することができる。すなわち、システム全体として余裕時間が残されている場合においても遅延の吸収が可能である。
＜第２の実施形態＞
［残り時間を考慮した機能の選択の例］
　次に、本発明の第２の実施形態として、先行タスクの処理を実行する半導体チップ又は後続タスクの処理を実行する半導体チップにおいて残り時間を考慮した機能を選択する構成について、図８を参照して説明する。
　本実施形態では、一の半導体チップ（ＳｏＣ２）のプロセッサは、一の半導体チップ（ＳｏＣ２）における複数のタスクのうちの一のタスクの処理時間が、基準時間に閾値の時間を加えた時間を超えると判断した場合、一の半導体チップ（ＳｏＣ２）において一のタスクの後に実行される他のタスクをより基準時間が短い処理内容（簡易処理）で実行する。
　また、本実施形態では、他の半導体チップ（ＳｏＣ１）のプロセッサは、一の半導体チップ（ＳｏＣ２）における先行タスクの処理時間が、基準時間に閾値の時間を加えた時間を超えると判断した場合、後続タスクをより基準時間が短い処理内容（簡易処理）で実行する。さらに、本実施形態では、他の半導体チップ（ＳｏＣ１）のプロセッサは、他の半導体チップ（ＳｏＣ１）における複数のタスクのうちの一のタスクの処理時間が、基準時間に閾値の時間を加えた時間を超えると判断した場合、他の半導体チップ（ＳｏＣ１）において一のタスクの後に実行される他のタスクをより基準時間が短い処理内容（簡易処理）で実行する構成としてもよい。
（一の半導体チップ（ＳｏＣ２）で簡易処理を実行する例）
　図８は、本発明の第２の実施形態に係るＳｏＣ２において残り時間を考慮した機能を選択する例を示した図である。
　例えば、ＳｏＣ２の物体検知（カメラ、ＬｉＤＡＲ）についてさまざまな手法が存在し、それぞれの平均実行時間と最悪実行時間は異なる。この点は距離測定（ソナー又はソナー以外）も同様である。また、例えばフュージョンについても、ＳｏＣ１とＳｏＣ２のタスク結果を用いる場合と、ＳｏＣ１だけのタスク結果を用いる場合とで、ＳｏＣ１の入力のデータ量が変わるため、平均実行時間及び最悪実行時間が異なることが考えられる。そのため、ＳｏＣ２では各タスク処理の開始時点で（厳密には開始するまでに）、残りの時間を考慮して機能を選択することで、各センサが出力する最新データ（最新値）を用いた処理を行いつつ、システム全体でのデッドラインを守る。
　例えば、ＬｉＤＡＲ６による物体検知を行う機能として物体検知（ＬｉＤＡＲ）－Ｂを用意しておく。ＳｏＣ２における物体検知（ＬｉＤＡＲ）－Ｂの平均実行時間は３０ｍｓ、最悪実行時間は４０ｍｓとする。物体検知（ＬｉＤＡＲ）－Ｂは、物体検知（ＬｉＤＡＲ）の実行時間３５ｍｓよりも実行時間が短く簡易処理である。また、処理周期は１５０ｍｓ、クリティカルパスの平均実行時間１０５ｍｓを考慮して、共有マージンは４５ｍｓとする。
　図８に示すように、ＳｏＣ２において物体検知（カメラ）が共有マージンを１５ｍｓ（図中の共有マージンＭｃ１）消費した場合を考える。もし、ＳｏＣ２で物体検知（ＬｉＤＡＲ）を実行すると、最大で共有マージンを２０（＝５５－３５）ｍｓ消費する可能性がある。そこで、ＳｏＣ２は、物体検知（ＬｉＤＡＲ）よりも実行時間が短い物体検知（ＬｉＤＡＲ）－Ｂを選択する。このようにすることで、平均実行時間が５ｍｓ短縮することに加え、図中に共有マージンＭｃ２´として示すように最大でも共有マージンを１０（＝４０－３０）ｍｓしか消費しない。
　それゆえ、共有マージンＭを超過することなく、ＳｏＣ１に対してＳｏＣ２の出力を行うことができる。ＳｏＣ１では、制御指令値算出まで処理が終了したときに、共有マージンＭｒ´（Ｍ－Ｍｃ１－Ｍｃ２´）が残っている。
（他の半導体チップ（ＳｏＣ１）で簡易処理を実行する例）
　次に、フュージョンよりも簡易な処理であるフュージョン－Ｂ（図示略）を想定し、他の半導体チップ（ＳｏＣ１）における機能の選択例を説明する。一般に、平均実行時間は最悪実行時間よりも短いため、フュージョンの最悪実行時間よりもフュージョンの平均実行時間が短く、フュージョン－Ｂの最悪実行時間よりもフュージョン－Ｂの平均実行時間が短い。ここで、フュージョンの最悪実行時間よりもフュージョン－Ｂの最悪実行時間が短いと仮定すると、それぞれの時間の関係性は以下の３パターンとなる。
　（１）フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョンの平均実行時間＞フュージョン－Ｂの平均実行時間
　（２）フュージョンの最悪実行時間＞フュージョンの平均実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間
　（３）フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間＞フュージョンの平均実行時間
　上記パターン（１）に対して、共有マージンの残時間との関係はさらに５つのパターンが想定される。
　（１）－１：共有マージンの残時間＞フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョンの平均実行時間＞フュージョン－Ｂの平均実行時間
　（１）－２：フュージョンの最悪実行時間＞共有マージンの残時間＞フュージョン－Ｂの最悪実行時間＞フュージョンの平均実行時間＞フュージョン－Ｂの平均実行時間
　（１）－３：フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞共有マージンの残時間＞フュージョンの平均実行時間＞フュージョン－Ｂの平均実行時間
　（１）－４：フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョンの平均実行時間＞共有マージンの残時間＞フュージョン－Ｂの平均実行時間
　（１）－５：フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョンの平均実行時間＞フュージョン－Ｂの平均実行時間＞共有マージンの残時間
　また、上記パターン（２）に対して、共有マージンの残時間との関係はさらに５つのパターンが想定される。
　（２）－１：共有マージンの残時間＞フュージョンの最悪実行時間＞フュージョンの平均実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間
　（２）－２：フュージョンの最悪実行時間＞共有マージンの残時間＞フュージョンの平均実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間
　（２）－３：フュージョンの最悪実行時間＞フュージョンの平均実行時間＞共有マージンの残時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間
　（２）－４：フュージョンの最悪実行時間＞フュージョンの平均実行時間＞フュージョン－Ｂの最悪実行時間＞共有マージンの残時間＞フュージョン－Ｂの平均実行時間
　（２）－５：フュージョンの最悪実行時間＞フュージョンの平均実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間＞共有マージンの残時間
　また、上記パターン（３）に対して、共有マージンの残時間との関係はさらに５つのパターンが想定される。
　（３）－１：共有マージンの残時間＞フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間＞フュージョンの平均実行時間
　（３）－２：フュージョンの最悪実行時間＞共有マージンの残時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間＞フュージョンの平均実行時間
　（３）－３：フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞共有マージンの残時間＞フュージョン－Ｂの平均実行時間＞フュージョンの平均実行時間
　（３）－４：フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間＞共有マージンの残時間＞フュージョンの平均実行時間
（３）－５：フュージョンの最悪実行時間＞フュージョン－Ｂの最悪実行時間＞フュージョン－Ｂの平均実行時間＞フュージョンの平均実行時間＞共有マージンの残時間
　タスク処理の開始時点で、フュージョンの最悪実行時間及びフュージョン－Ｂの最悪実行時間のいずれも残っている場合（（１）－１、（２）－１、（３）－１）、フュージョンを選択するとよい。
　タスク処理の開始時点で、フュージョン－Ｂの最悪実行時間が残っており、フュージョンの最悪実行時間が残っていない場合（（１）－２、（２）－２、（２）－３、（３）－２）、フュージョン－Ｂを選択するとよい。このようにすることで、フュージョン処理の結果を確実に得ることができる。なお、前回の制御指令値を用いることが許容される場合、フュージョンを選択してもよい。
　タスク処理の開始時点で、フュージョン及びフュージョン－Ｂのいずれの最悪実行時間も残っていないが、いずれの平均実行時間も残っている場合（（１）－３、（３）－３）、（１）－３ではフュージョン－Ｂを、（３）－３ではフュージョンを選択するとよい。
この場合、最悪実行時間が確保できておらず、デッドライン以内にタスク処理の実行が完了することを保証できないため、フュージョン及びフュージョン－Ｂのうち平均実行時間が短い機能を実行することで、デッドライン以内にタスク処理の実行が完了する可能性が高くなる。なお、デッドライン以内に処理が完了する可能性が高い機能を選択するために、実行時間の分散を考慮して選択してもよい。具体的には、フュージョンとフュージョン－Ｂのそれぞれについて共有マージンの残時間以内に実行が完了する確率を求め、その確率が高い方を選択してもよい。
　タスク処理の開始時点で、フュージョン及びフュージョン－Ｂのいずれの最悪実行時間も残っていないが、いずれか一方の平均実行時間が残っている場合（（１）－４、（２）－４、（３）－４）、平均実行時間が残っている機能を選択するとよい。例えば、（１）－４及び（２）－４の場合は、フュージョン－Ｂを選択し、（３）－４の場合は、フュージョンを選択するとよい。このようにすることで、デッドライン以内にタスク処理の実行が完了する可能性が高くなる。なお、上述のとおり、実行時間の分散を考慮して選択してもよい。
　タスク処理の開始時点で、フュージョン及びフュージョン－Ｂのいずれの平均実行時間も残っていない場合（（１）－５、（２）－５、（３）－５）、平均実行時間が短い方の機能を選択するとよい。このようにすることで、デッドライン以内にタスク処理の実行が完了する可能性が高くなる。なお、上述のとおり、実行時間の分散を考慮して選択してもよい。
　以上のとおり、第２の実施形態に係る車両制御装置は、第１の実施形態に係る車両制御装置１と基本的な構成は同じであり、以下の点が異なる。
　第２の実施形態では、他の半導体チップ（ＳｏＣ１）のプロセッサは、一の半導体チップ（ＳｏＣ２）における先行タスクの処理に要した実行時間（例えば、平均実行時間／最悪実行時間）及び余裕時間（共有マージン）に基づいて、処理周期における後続タスクの処理に使用可能な残時間を求め、残時間に基づいて、後続タスクの処理内容を決定する。
また、一の半導体チップ（ＳｏＣ２）のプロセッサは、一の半導体チップ（ＳｏＣ２）における複数のタスクのうち一のタスクの処理に要した実行時間（例えば、平均実行時間／最悪実行時間）及び余裕時間（共有マージン）に基づいて、処理周期における一の半導体チップ（ＳｏＣ２）での処理に使用可能な残時間を求め、残時間に基づいて、一の半導体チップ（ＳｏＣ２）における一のタスクの後に実行される他のタスクの処理内容を決定する。また、他の半導体チップ（ＳｏＣ１）のプロセッサが、他の半導体チップ（ＳｏＣ１）における複数のタスクのうち一のタスクの処理に要した実行時間（例えば、平均実行時間／最悪実行時間）及び余裕時間（共有マージン）に基づいて、処理周期における他の半導体チップ（ＳｏＣ１）での処理に使用可能な残時間を求め、残時間に基づいて、他の半導体チップ（ＳｏＣ１）における一のタスクの後に実行される他のタスクの処理内容を決定してもよい。
　なお、本発明に係る車両制御装置として、第２の実施形態の構成と第１の実施形態の構成を組み合わせてもよい。すなわち、他の半導体チップ（ＳｏＣ１）は、一の半導体チップ（ＳｏＣ２）における先行タスクの処理に要した実行時間及び余裕時間に基づいて、処理周期における後続タスクの処理に使用可能な残時間を求め、残時間に基づいて、後続タスクの開始時間又は処理内容の少なくとも一方を決定する構成とする。
＜第３の実施形態＞
［半導体チップ間の時刻同期誤差を考慮した共有マージンの設定について］
　次に、本発明の第３の実施形態として、半導体チップ間の時刻同期誤差を考慮した共有マージンの設定について、図９及び図１０を参照して説明する。
（第１の例）
　図９は、本発明の第３の実施形態に係る半導体チップ（ＳｏＣ）間の時刻同期誤差の第１の例を示した図である。図９において横軸は時刻を表す。
　本例では、他の半導体チップ（ＳｏＣ１）の揮発性メモリ２３（図２参照）は、一の半導体チップ（ＳｏＣ２）における先行タスクの処理結果及び当該先行タスクの処理時間を示すタイムスタンプすなわち時刻情報を記憶する。そして、ＳｏＣ１のプロセッサは、揮発性メモリ２３に記憶されたタイムスタンプの更新状況に応じて、後続タスクの開始時間又は処理内容の少なくとも一方を決定する。
　車両制御装置１は、複数のＳｏＣで構成されるためＳｏＣ間の時刻同期が必要となる。
しかしながら、時刻同期には誤差があり、ＳｏＣの絶対時刻に対する誤差をεで表すとする。図９に示すように、絶対時刻に対して、ＳｏＣの時間が進んでいる場合とＳｏＣの時間が遅れている場合が想定される。
　車両制御装置１において、本来のサイクルＮは絶対時刻ｔ２から絶対時刻ｔ５までである。しかし、ＳｏＣ２にとってのサイクルＮは、絶対時刻ｔ２から誤差εだけ進んだ絶対時刻ｔ１から、絶対時刻ｔ５から誤差εだけ進んだ絶対時刻ｔ４までである。また、ＳｏＣ１にとってのサイクルＮは、絶対時刻ｔ２から誤差εだけ遅れた絶対時刻ｔ３から、絶対時刻ｔ５から誤差εだけ遅れた絶対時刻ｔ６までである。
　例えば、ＳｏＣ２の時間は絶対時刻よりも誤差εだけ早く、ＳｏＣ１の時間は絶対時刻よりも誤差εだけ遅い場合を想定する。すなわち、ＳｏＣ２におけるタスク処理開始は指定した絶対時刻よりも誤差εだけ早く、ＳｏＣ１におけるタスク処理開始は指定した絶対時刻よりも誤差εだけ遅い。この場合、サイクルＮにおいて、ＳｏＣ２で実行されるタスクＡがＳｏＣ２の時間を基準として絶対時刻ｔ（＝ｔ７）に出力をした際、ＳｏＣ１ではＳｏＣ１の時間を基準として絶対時刻ｔ－２εにＳｏＣ２の出力を受け取ることになる。
ここで、マイナスの符号は本来の目標時刻に対して遅れていることを表す。
　例えば、誤差２εよりもタスクＡの実行時間が短かった場合、ＳｏＣ１からすると１周期前すなわちサイクルＮ－１のタイミングでデータを受け取ることになる。そのため、送信元であるＳｏＣ２は、どの周期（ここでは、サイクルＮ）のデータであるかを特定するためのタイムスタンプを、出力データに付加する。これにより、ＳｏＣ１において、タイムスタンプの更新状況に応じてタスクＢの処理を実行することができる。
　例えば、ＳｏＣ１においてサイクルＮ－１のタイミングでＳｏＣ２からデータを受け取ったとしても、ＳｏＣ１のサイクルＮにおけるタスクＢの実行では、ＳｏＣ２からの受信データによりタイムスタンプが更新されていることを確認できる。そのため、ＳｏＣ１では、サイクルの順序を間違えることなく、適切にタスク処理を行うことができる。
（第２の例）
　図１０は、本発明の第３の実施形態に係る半導体チップ（ＳｏＣ）間の時刻同期誤差の第２の例を示した図である。図１０において横軸は時刻を表す。
　本例では、他の半導体チップ（ＳｏＣ１）のプロセッサは、余裕時間に対して、絶対時刻に対する他の半導体チップ（ＳｏＣ１）及び一の半導体チップ（ＳｏＣ２）の時刻同期誤差に応じた時間を減算し、処理周期における後続タスクの処理に使用可能な残時間を求める。
　ここで、ＳｏＣ２の時間は絶対時刻よりも誤差εだけ遅く、ＳｏＣ１の時間は絶対時刻よりも誤差εだけ早い場合を想定する。この場合、図１０上段に示すように、サイクルＮにおいて、ＳｏＣ２で実行されるタスクＣがＳｏＣ２の時間を基準として絶対時刻ｔ（＝ｔ８）に出力をした際、ＳｏＣ１ではＳｏＣ１の時間を基準として絶対時刻ｔ＋２εにＳｏＣ２の出力を受け取ることになる。ここで、プラスの符号は本来の目標時刻に対して進んでいることを表す。
　ＳｏＣ２の時間を基準とするとサイクルＮの終了まで十分な時間が残されている。しかし、ＳｏＣ１からするとサイクルＮの終了まで十分な時間が残っていないため、ＳｏＣ１はタスクＤを実行することができない。そのため、共有マージンを使用する際に、時刻同期誤差を考慮した時間分を削減して検討する必要がある。具体的には、ＳｏＣ１で残りの共有マージンを考慮して機能の選択をする際に、共有マージンから誤差２εを減算して各機能を選択した場合の残り時間を比較する必要がある。
　図１０下段に示すように、ＳｏＣ２において、共有マージンから誤差２εを減算しても間に合うような機能（例えば、簡易処理のタスクＣ´）を選択して実行する。タスクＣ´は、タスクＣよりも平均実行時間及び最悪実行時間が短い。タスクＣ及びタスクＣ´は、図８に示した物体検知（ＬｉＤＡＲ）と物体検知（ＬｉＤＡＲ）のように、同じセンサのデータを利用する機能である。タスクＣ´を選択すると、ＳｏＣ２で実行されるタスクＣ´がＳｏＣ２の時間を基準として絶対時刻ｔ８よりも前の絶対時刻ｔ９に出力をする。そして、ＳｏＣ１において、タスクＣの場合よりも早い時刻にタスクＣ´の出力を受信してタスクＤの処理を実行できる。そのため、ＳｏＣ１において残り時間に余裕ができ、システム全体でのデッドタイムを守ることができる。
　なお、ＳｏＣ１は、ＳｏＣ２との相対的な時刻同期誤差を知らないので、第２の例においても、ＳｏＣ２は、どの周期のデータであるかを特定するためのタイムスタンプを出力データに付加してもよい。
＜第４の実施形態＞
［共有マージン超過回数が規定回数を超えたときの対応］
　次に、本発明の第４の実施形態として、共有マージン超過回数が規定回数を超えたときの対応について、図１１及び図１２を参照して説明する。
［後続タスクの処理に共有マージンを按分する場合］
　図１１は、本発明の第４の実施形態において後続タスクの処理に共有マージンを按分する例を示した図である
　ハードウェア的な故障等によって、先行タスクの処理時間が複数回連続して共有マージンを超過する場合が考えられる。そこで、すなわち、他の半導体チップ（ＳｏＣ１）のプロセッサは、一の半導体チップ（ＳｏＣ２）における先行タスクの処理時間が、基準時間に閾値の時間（共有マージ）を加えた時間を超えることが規定回数以上連続した場合、閾値の時間の一部を後続タスク側に割り当てる。
　ＳｏＣ２からの出力タイミングが予め設定した閾値回数連続して共有マージンの終了隊イングを超過する場合、ＳｏＣ１に共有マージンを按分する。この場合、後続タスク（図１１ではフュージョン）の開始前に共有マージンを割り当てる。
　例えば、ＳｏＣ１でＳｏＣ２からの出力の断念のタイミングを、平均実行時間で設定している場合を想定する。後続タスクの処理に共有マージンを按分していない場合、仮に、ＳｏＣ１で残りの後続タスクの処理に時間を要したとすると、デッドラインを守れず、ＳｏＣ１は前回の制御指令値を出力することになる。
　一方、後続タスクの処理に共有マージンを按分することで、仮にＳｏＣ１で残りの後続タスクの処理に時間を要したとしても、デッドラインを守ることができる。そのため、車両制御装置１は、前回の制御指令値ではなく、制御指令値の最新値を用いた処理が可能となる。
［先行するタスク処理が時間内に実行を完了した場合］
　図１２は、本発明の第４の実施形態において先行するタスク処理が時間内に実行を完了した場合の例を示した図である。
　図１２に示す例では、ＳｏＣ１に対して共有マージンを按分しているため、按分された共有マージンの開始タイミングｔ１１よりも先にＳｏＣ２からの出力を受け取った場合は、そのサイクル（例えばサイクルＮ）でＳｏＣ２の出力を用いた処理が可能になる。
　そこで、先行するタスク処理が時間内に実行を完了した場合、ＳｏＣ１は、次のサイクル（ここではサイクルＮ－１）で共有マージンの按分の解消を行う（図８に近い状態）。
すなわち、一の半導体チップ（ＳｏＣ２）における先行タスクの処理が、先行タスクの基準時間に閾値の時間（共有マージン）を加えた時間内に完了した場合は、閾値の時間の一部を他の半導体チップ（ＳｏＣ１）における後続タスク側に割り当てることを中止し、先行タスク側の閾値の時間を基に戻す。
　これにより、ＳｏＣ２側のエラー回復に合わせて、ＳｏＣ２のタスク処理に元々の閾値の時間（共有マージン）を割り当てることができる。それゆえ、ＳｏＣ１は、ＳｏＣ２による先行タスクの最新の処理結果を利用して後続タスクの処理を実行できる状態に復帰する。
　一方で、按分された共有マージンの開始タイミングｔ１１と後続タスクの処理に必要な時間の間にＳｏＣ１がＳｏＣ２からの出力を受け取った場合、ＳｏＣ１では既にフュージョンの処理を実行していることになる。
　この場合、ＳｏＣ１は、現在実行しているＳｏＣ２の先行タスクの結果を用いていない処理を中断し、ＳｏＣ２における先行タスクの結果を用いた処理を開始する。
＜変形例＞
　以上、本発明は上述した実施形態に限定されるものではなく、請求の範囲に記載された発明の要旨を逸脱しない限りにおいて、その他種々の変形例、応用例を取り得ることは勿論である。例えば、上述した実施形態は本発明を分かりやすく説明するためにその構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成要素を備えるものに限定されない。また、ある実施形態の構成の一部を他の実施形態の構成要素に置き換えることが可能である。また、ある実施形態の構成に他の実施形態の構成要素を加えることも可能である。また、各実施形態の構成の一部について、他の構成要素の追加又は置換、削除をすることも可能である。
　また、上記の各構成、機能、処理部等は、それらの一部又は全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。ハードウェアとして、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）などの広義のプロセッサデバイスを用いてもよい。
　また、上述した実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成要素が相互に接続されていると考えてもよい。
　１…車両制御装置、　１０…車両システム、　１１…半導体チップ、　１２…半導体チップ、　２１…ＣＰＵ、　２２…不揮発性メモリ、　２３…揮発性メモリ、　１１１…距離測定部、　１１２…物体検知部（Ｒａｄａｒ）、　１１３…物体検知部（カメラ）、　１１４…通信部、　１１５…フュージョン部、　１１６…軌道計算部、　１１７…制御指令値算出部、　１２１…物体検知部（カメラ）、　１２２…物体検知部（ＬｉＤＡＲ）、
　１２３…通信部、　Ｍ…共有マージン、　Ｍｃ１…共有マージン（消費）、　Ｍｃ２…共有マージン（消費）、　Ｍｐ…共有マージン（按分）、　Ｍｒ…共有マージン（残り）、　Ｔｅ…時間

Claims (13)

  1. 　センサから受信したセンサデータを処理するプロセッサと、不揮発性メモリと、揮発性メモリと、を有する半導体チップを複数備えた車両制御装置であって、
    　一の半導体チップにおける先行タスクの処理と、当該先行タスクの処理結果を利用する他の半導体チップにおける後続タスクの処理と、を少なくとも含む処理シーケンスに対し、当該処理シーケンスに含まれる各タスクの処理に要する基準時間及び余裕時間を含む処理周期が割り当てられており、
    　前記他の半導体チップのプロセッサは、
    　前記一の半導体チップにおける前記先行タスクの処理に要した実行時間及び前記余裕時間に基づいて、前記処理周期における前記後続タスクの処理に使用可能な残時間を求め、前記残時間に基づいて、前記後続タスクの開始時間又は処理内容の少なくとも一方を決定する、
    　車両制御装置。
  2. 　前記他の半導体チップのプロセッサは、
    　前記一の半導体チップにおける前記先行タスクの処理時間が前記基準時間を超過すると、前記余裕時間に対して設定した閾値の時間内で前記先行タスクの処理が完了するまで前記後続タスクの開始を保留する、
    　請求項１に記載の車両制御装置。
  3. 　前記他の半導体チップのプロセッサは、
    　前記後続タスクの開始を保留した場合に、前記閾値の時間内で前記先行タスクの処理が完了しないときには、前記先行タスクの処理結果を利用するプログラムの開始要求を無効化する、
    　請求項２に記載の車両制御装置。
  4. 　前記他の半導体チップの不揮発性メモリは、
    　前記一の半導体チップにおける先行タスクの処理結果を利用する第一のプログラムと、
    　前記一の半導体チップにおける先行タスクの処理結果を利用しない第二のプログラムと、を記憶し、
    　前記他の半導体チップのプロセッサは、
    　前記閾値の時間内に前記先行タスクの処理が完了した場合には、第一のプログラムを選択し、前記閾値の時間内に前記先行タスクの処理が完了しない場合には、第二のプログラムを選択する、
    　請求項２に記載の車両制御装置。
  5. 　複数の前記半導体チップは、
    　前記センサから受信したセンサデータに基づいて、物体を検知する物体検知処理を実行し、
    　前記第一のプログラムは、
    　前記他の半導体チップのプロセッサに、前記先行タスクの処理結果である物体検知結果と当該他の半導体チップにおけるタスクの処理結果である物体検知結果とを統合して、第一の統合物体情報を生成する第一のフュージョン処理を前記後続タスクとして実行させ、
    　前記第二のプログラムは、
    　前記他の半導体チップのプロセッサに、当該他の半導体チップにおけるタスクの処理結果である物体検知結果を用いて、第二の統合物体情報を生成する第二のフュージョン処理を前記後続タスクとして実行させる、
    　請求項４に記載の車両制御装置。
  6. 　前記他の半導体チップのプロセッサは、
    　前記一の半導体チップにおける前記先行タスクの処理時間が、前記基準時間に前記閾値の時間を加えた時間を超えると判断した場合、前記後続タスクをより基準時間が短い処理内容で実行する
    　請求項２に記載の車両制御装置。
  7. 　前記一の半導体チップのプロセッサは、
    　前記一の半導体チップにおける複数のタスクのうち一のタスクの処理時間が、前記基準時間に前記閾値の時間を加えた時間を超えると判断した場合、前記一の半導体チップにおける前記一のタスクの後に実行されるタスクをより基準時間が短い処理内容で実行する
    　請求項２に記載の車両制御装置。
  8. 　前記他の半導体チップのプロセッサは、
    　前記他の半導体チップにおける複数のタスクのうち一のタスクの処理時間が、前記基準時間に前記閾値の時間を加えた時間を超えると判断した場合、前記他の半導体チップにおける前記一のタスクの後に実行されるタスクをより基準時間が短い処理内容で実行する
    　請求項２に記載の車両制御装置。
  9. 　前記他の半導体チップの揮発性メモリは、
    　前記一の半導体チップにおける前記先行タスクの処理結果及び当該先行タスクの処理時間を示すタイムスタンプを記憶し、
    　前記他の半導体チップのプロセッサは、
    　前記揮発性メモリに記憶された前記タイムスタンプの更新状況に応じて、前記後続タスクの開始時間又は処理内容の少なくとも一方を決定する、
    　請求項１に記載の車両制御装置。
  10. 　前記他の半導体チップのプロセッサは、
    　前記余裕時間に対して、絶対時刻に対する前記他の半導体チップ及び前記一の半導体チップの時刻同期誤差に応じた時間を減算し、前記処理周期における前記後続タスクの処理に使用可能な前記残時間を求める
    　請求項１に記載の車両制御装置。
  11. 　前記他の半導体チップのプロセッサは、
    　前記一の半導体チップにおける前記先行タスクの処理時間が、前記基準時間に前記閾値の時間を加えた時間を超えることが規定回数以上連続した場合、前記閾値の時間の一部を前記後続タスク側に割り当てる
    　請求項２に記載の車両制御装置。
  12. 　前記他の半導体チップのプロセッサは、
    　前記一の半導体チップにおける前記先行タスクの処理が、前記基準時間に前記閾値の時間を加えた時間内に完了した場合は、前記閾値の時間の一部を前記後続タスク側に割り当てることを中止する
    　請求項１１に記載の車両制御装置。
  13. 　センサから受信したセンサデータを処理するプロセッサと、不揮発性メモリと、揮発性メモリと、を有する半導体チップを複数備えた車両制御装置におけるセンサデータ処理方法であって、
    　一の半導体チップにおける先行タスクの処理と、前記先行タスクの処理結果を利用する他の半導体チップにおける後続タスクの処理と、を少なくとも含む処理シーケンスに対し、当該処理シーケンスに含まれる各タスクの処理に要する基準時間及び余裕時間を含む処理周期が割り当てられており、
    　前記他の半導体チップのプロセッサは、
    　前記一の半導体チップにおける前記先行タスクの処理に要した実行時間及び前記余裕時間に基づいて、前記処理周期における前記後続タスクの処理に使用可能な残時間を求め、前記残時間に基づいて、前記後続タスクの開始時間又は処理内容の少なくとも一方を決定する、
    　センサデータ処理方法。
PCT/JP2025/000541 2024-03-18 2025-01-09 車両制御装置及びセンサデータ処理方法 Pending WO2025197262A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2024042067A JP2025142615A (ja) 2024-03-18 2024-03-18 車両制御装置及びセンサデータ処理方法
JP2024-042067 2024-03-18

Publications (1)

Publication Number Publication Date
WO2025197262A1 true WO2025197262A1 (ja) 2025-09-25

Family

ID=97138699

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2025/000541 Pending WO2025197262A1 (ja) 2024-03-18 2025-01-09 車両制御装置及びセンサデータ処理方法

Country Status (2)

Country Link
JP (1) JP2025142615A (ja)
WO (1) WO2025197262A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016113968A (ja) * 2014-12-16 2016-06-23 アイシン精機株式会社 車両用制御装置および制御方法
JP2020204844A (ja) * 2019-06-14 2020-12-24 富士電機株式会社 制御装置およびその保守支援装置
JP2023036264A (ja) * 2021-09-02 2023-03-14 日立Astemo株式会社 電子システム及び電子制御装置
WO2023195121A1 (ja) * 2022-04-07 2023-10-12 日本電信電話株式会社 トランザクション制御システム、トランザクション制御方法およびトランザクション制御プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016113968A (ja) * 2014-12-16 2016-06-23 アイシン精機株式会社 車両用制御装置および制御方法
JP2020204844A (ja) * 2019-06-14 2020-12-24 富士電機株式会社 制御装置およびその保守支援装置
JP2023036264A (ja) * 2021-09-02 2023-03-14 日立Astemo株式会社 電子システム及び電子制御装置
WO2023195121A1 (ja) * 2022-04-07 2023-10-12 日本電信電話株式会社 トランザクション制御システム、トランザクション制御方法およびトランザクション制御プログラム

Also Published As

Publication number Publication date
JP2025142615A (ja) 2025-10-01

Similar Documents

Publication Publication Date Title
KR102269504B1 (ko) 자동차용 제어 장치
CN103098032B (zh) 仿真方法和系统
Hildebrandt et al. Scheduling coprocessor for enhanced least-laxity-first scheduling in hard real-time systems
EP2579164B1 (en) Multiprocessor system, execution control method, execution control program
CN101506783B (zh) 用于阻隔操作的条件式广播的方法和设备
US8281051B2 (en) Method and device for determining time in a bus system and corresponding bus system
JP7658861B2 (ja) 電子システム及び電子制御装置
WO2017188109A1 (ja) 車両制御装置、及び車両システム
JPH0612503B2 (ja) チャンネル間の通信機能を有する専用サービス・プロセッサ
WO2025256541A1 (zh) 资源调度的方法、装置和系统
Chetto Real-time systems scheduling 1: fundamentals
JP2025142615A (ja) 車両制御装置及びセンサデータ処理方法
Zeng et al. Design space exploration of automotive platforms in metropolis
EP2596412B1 (en) Electronic circuit, safety critical system, and method for providing a reset signal
CN101647002A (zh) 多处理系统及方法
US11604739B2 (en) Conditional direct memory access channel activation
EP4296856A1 (en) Computer system and method for executing an automotive customer function
CN112486142B (zh) 将虚拟化io架构和汽车应用集成在ecu的方法及系统
Sundar et al. Design and analyses of functional mode changes for mixed-criticality systems
US9524266B2 (en) Latency management system and method for multiprocessor system
Borrmann et al. Safe and efficient runtime resource management in heterogeneous systems for automated driving
Di Natale et al. Architecture exploration for time-critical and cost-sensitive distributed systems
Xie et al. Distributed computing for functional safety of automotive embedded systems
Sundar Design and analysis of task models for mixed-criticality systems with practical considerations
JP7236939B2 (ja) 制御装置および制御方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25773966

Country of ref document: EP

Kind code of ref document: A1