Electronic Systems and Control Units

Abstract

To provide an electronic system and an electronic control apparatus which improve efficiency of use of a CPU and the like by dynamically changing task scheduling in response to a state of a processing load.SOLUTION: In a vehicle, an electronic system 110 is connected through a network to a plurality of task processing units for processing allocated tasks. First to third electronic control devices as first to third task processing units each have a task activation unit 72 or 83 for activating each task to execute it. Third task processing in the third task processing unit uses at least a first task processing result of the first task processing unit and a second task processing result of the second task processing unit preceding the third task processing. A series of processing from the preceding first task processing or the preceding second task processing to the third task processing are periodically carried out at a predetermined interval.SELECTED DRAWING: Figure 18

Description

[Technical field]

[0001] The present invention relates to an electronic system and an electronic control device thereof. [Background technology]

[0002] In order to improve the utilization efficiency of the CPU (Central Processing Unit) mounted on an in-vehicle electronic control unit (ECU), it is considered effective to dynamically change the scheduling of tasks computed by each CPU depending on the processing load, etc. Patent Document 1 discloses a technique for providing a distributed control method and device that can guarantee the response time and deadline conditions required by distributed control without imposing an excessive burden on the designer of the distributed control system. Patent Document 1 describes that for each transmittable message, the right to transmit the message is assigned preferentially to the message with the shortest slack time based on the slack time for the distributed control to which the message belongs. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2003-298599 A Summary of the Invention [Problem to be solved by the invention]

[0004] The technology of Patent Document 1 changes the transmission priority of messages with deadlines to a higher priority than messages with short deadlines. This dynamically changes the transmission timing of each message when the CPU processing load is large and delays occur in message transmission, and is expected to ensure that the transmission deadline of each message is met. However, the timing of each message transmission is determined by the CPU processing load, the number of messages to be transmitted, the amount of data, and the like. For this reason, there are an infinite number of verification patterns for message transmission, and it is difficult to verify in advance whether the deadline is actually met.

[0005] By the way, there is a well-known scheduling technique called LET (Logical Execution Time). In LET, the timing at which each task accesses global memory is fixed. The fixed interval between reads and writes when accessing global memory during task processing is called an "interval." At the beginning of the interval, each task reads the necessary variables from global memory and copies them to local memory (Read task (R task)), and at the end of the interval, it writes the calculation results from the local memory to global memory (Write task (W task)). The calculations of each task (Execute task (E task)) can be executed at any time during the interval. In other words, the execution timing of an E task can be changed arbitrarily within the interval.

[0006] This ensures that even if the timing of the E-task calculations in the local memory is shifted due to the effects of the CPU processing load, etc., there will be no change in the behavior of the microcontroller or ECU as long as the fixed timing of reads and writes to the global memory is maintained.

[0007] Conventional LET was only applicable within the same microcomputer, but it is believed that LET can be extended between ECUs as long as the time required for communication between ECUs is guaranteed. However, in LET, in order to adhere to the fixed timing of reads and writes to global memory, it is necessary to design intervals that are sufficiently longer than the execution time of E-tasks calculated in local memory. This can often result in a decrease in CPU utilization efficiency.

[0008] In consideration of the above circumstances, an object of the present invention is to improve the utilization efficiency of a processor such as a CPU by dynamically changing task scheduling in accordance with the processing load status. [Means for solving the problem]

[0009] In order to achieve the above object, an electronic system according to one aspect of the present invention is an electronic system in which a plurality of task processing units that process assigned tasks are connected via a network. The multiple task processing units each include a task starting unit that starts and executes each task, and a third task processing in a third task processing unit utilizes at least a processing result of a first task in a first task processing unit that precedes the third task processing or a processing result of a second task in a second task processing unit, and periodically executes a series of processes from the preceding first task processing or second task processing to the third task processing at a predetermined time interval. Effect of the Invention

[0010] According to at least one aspect of the present invention, the utilization efficiency of the task processing unit is improved by dynamically changing task scheduling (execution timing) in accordance with the processing load status. In addition, by keeping a series of processes after the task scheduling change within a predetermined time interval, it is possible to guarantee that the schedule change will not affect other processes. Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0011] [Figure 1] 1 is a diagram showing an example of the overall configuration of an electronic system according to a first embodiment of the present invention. [Diagram 2] 1 is a diagram showing an example of a hardware configuration of each electronic control device included in an electronic system according to a first embodiment of the present invention. [Diagram 3] 5 is a flowchart showing an outline of a processing procedure in a third electronic control device (autonomous driving ECU) according to the first embodiment of the present invention. [Figure 4] FIG. 2 is a diagram showing an example of a camera risk map according to the first embodiment of the present invention. [Diagram 5] FIG. 2 is a diagram showing an example of a LIDAR risk map according to the first embodiment of the present invention. [Figure 6] FIG. 2 is a diagram showing an example of a superimposed risk map according to the first embodiment of the present invention. [Figure 7] FIG. 2 is a diagram showing an example of a control period of the electronic system according to the first embodiment of the present invention. [Figure 8] FIG. 2 is a diagram showing an example of mapping processes from data acquisition to trajectory generation to tasks according to the first embodiment of the present invention. [Figure 9] FIG. 13 is a diagram showing an example of a task before it is made compatible with LET. [Figure 10] FIG. 2 is a diagram showing an example after a task according to the first embodiment of the present invention is made compatible with LET. [Figure 11] FIG. 13 is a diagram for explaining intervals in normal LET. [Figure 12] FIG. 2 is a diagram for explaining a reference time (budget) and a margin according to the first embodiment of the present invention. [Figure 13] 4 is an example of a timing chart showing interval extension and margin sharing according to the first embodiment of the present invention. [Figure 14] 11 is an example of an improved timing chart in consideration of the change in processing order according to the first embodiment of the present invention. [Figure 15] 5 is an example of a timing chart showing a maximum allowable processing delay when processing order rearrangement according to the first embodiment of the present invention is not performed. [Figure 16] 4 is an example of a timing chart showing a maximum allowable processing delay when processing order rearrangement is performed according to the first embodiment of the present invention. [Figure 17] 4 is a flowchart for determining whether or not a process order needs to be changed according to the first embodiment of the present invention. [Figure 18] FIG. 2 is a block diagram showing a scheduling function of each electronic control unit according to the first embodiment of the present invention. [Figure 19] FIG. 2 is a diagram showing an example of a method for calculating an expected processing time for a camera object detection task (E task) in the first electronic control unit (camera ECU) according to the first embodiment of the present invention. [Figure 20] FIG. 2 is a diagram showing an example of processing time exceeded task information transmitted from a first electronic control unit (camera ECU) to a third electronic control unit (autonomous driving ECU) according to the first embodiment of the present invention. [Figure 21] FIG. 11 is a diagram showing, in source code, a method for starting a task in a third electronic control device (autonomous driving ECU) according to the first embodiment of the present invention. [Figure 22] 10 is a flowchart for determining whether or not it is necessary to change the processing order according to the second embodiment of the present invention. [Figure 23] FIG. 11 is a diagram showing the timing at which processing is performed in each electronic control unit when processing is skipped according to the second embodiment of the present invention. [Figure 24] FIG. 11 is a diagram showing, in source code, a method for starting a task in a third electronic control device (autonomous driving ECU) according to a second embodiment of the present invention. [Diagram 25] 13 is a flowchart for determining whether or not a process order needs to be changed according to the third embodiment of the present invention. [Figure 26] FIG. 13 is a diagram showing the timing at which processing is performed in each electronic control device when processing is changed according to a third embodiment of the present invention. [Figure 27] FIG. 13 is a diagram showing, in source code, a method for starting a task in a third electronic control device (autonomous driving ECU) according to a third embodiment of the present invention. [Figure 28] 13 is a flowchart for determining whether or not to change the processing order according to a fourth embodiment of the present invention. [Figure 29] FIG. 13 is a diagram showing the timing at which processing is performed in each electronic control device when processing is changed according to a fourth embodiment of the present invention. [Diagram 30] FIG. 13 is a diagram showing, in source code, a method for starting a task in a third electronic control device (autonomous driving ECU) according to a fourth embodiment of the present invention. [Diagram 31] FIG. 13 is a diagram showing an example of the overall configuration of an electronic system according to a sixth embodiment of the present invention. [Diagram 32] FIG. 13 is a diagram showing an example of the overall configuration of an electronic system according to a seventh embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The present invention relates to an electronic system, and more particularly to a vehicle control system in which a plurality of electronic control units (ECUs) are connected via a network. Hereinafter, an example of an embodiment of the present invention will be described with reference to the accompanying drawings. In this specification and the accompanying drawings, components having substantially the same functions or configurations are designated by the same reference numerals, and duplicated descriptions will be omitted.

[0013] [First embodiment] First, an electronic system including a plurality of electronic control devices according to a first embodiment of the present invention will be described.

[0014] <Overall configuration of electronic system> An electronic system according to a first embodiment of the present invention will be described with reference to FIG. FIG. 1 is a diagram showing an example of the overall configuration of an electronic system according to a first embodiment of the present invention. The illustrated vehicle 100 includes sensors (sensing devices) including a camera 4 and a LIDAR 5, an electronic system 110, a steering wheel 6, an accelerator 7, and a brake 8. The sensors and mechanisms illustrated in FIG.

[0015] The electronic system 110 receives camera image data 9 and LIDAR point cloud data 11 from the camera 4 and LIDAR 5, respectively. The electronic system 110 has a role of outputting a steering control command 13, an accelerator control command 14, and a brake control command 15 to the actuators of the steering 6, the accelerator 7, and the brake 8, respectively, based on these data.

[0016] The electronic system 110 includes a camera ECU1 as a first electronic control device, a LIDAR ECU2 as a second electronic control device, and an autonomous driving ECU3 as a third electronic control device. These three electronic control devices are connected to each other so as to be able to communicate with each other via an in-vehicle network 16. The first to third electronic control devices are examples of first to third task processing units.

[0017] In this embodiment, the in-vehicle network 16 is configured using a communication method that can synchronize the times of all electronic control devices connected to the in-vehicle network 16 and guarantee data transmission within a certain period of time. One example of such a communication method is the well-known TSN (Time Sensitive Network), but the communication method applicable to the in-vehicle network 16 of the present invention is not limited to this.

[0018] The first electronic control unit (camera ECU1) receives camera image data 9 from the camera 4, generates camera object detection data 10, and transmits it to the third electronic control unit (autonomous driving ECU3) using the in-vehicle network 16. The camera object detection data 10 includes information such as the type, position (coordinates), and ID (label information) of the detected object. The internal logic of the first electronic control unit (camera ECU1) and the data format of the camera object detection data 10 are not directly related to the present invention, so examples will be omitted.

[0019] The second electronic control unit (LIDAR ECU2) receives the LIDAR point cloud data 11 from the LIDAR 5, generates LIDAR object detection data 12, and transmits it to the third electronic control unit (autonomous driving ECU3) using the in-vehicle network 16. The LIDAR object detection data 12 includes information such as the type, position (coordinates), and ID (label information) of the detected object. The internal logic of the second electronic control unit (LIDAR ECU2) and the data format of the LIDAR object detection data 12 are not directly related to the present invention, so examples are omitted.

[0020] The third electronic control unit (autonomous driving ECU3) receives camera object detection data 10 from the camera ECU 1, and receives LIDAR object detection data 12 from the LIDAR ECU 2. The third electronic control unit (autonomous driving ECU3) then analyzes the camera object detection data 10 and the LIDAR object detection data 12 to generate a driving trajectory, and generates a steering control command 13, an accelerator control command 14, and a brake control command 15 to realize the driving trajectory.

[0021] The functions provided to each of the above-mentioned electronic control units (ECUs) are merely examples and are not intended to be limiting. In other words, it should be noted that the present invention is applicable regardless of the type of sensor, the number of ECUs, and the applications installed in the ECUs.

[0022] <Hardware configuration of electronic control unit> 2 is a diagram showing an example of the hardware configuration of each electronic control device included in the electronic system 110. Here, the hardware configuration will be described using the camera ECU 1 as an example.

[0023] The camera ECU 1 shown in the figure includes a CPU (Central Processing Unit) 51, a ROM (Read Only Memory) 52, a RAM (Random Access Memory) 53, a global memory 54, a local memory 55, an input / output interface 56, and a network interface 57. Each hardware block is connected to each other via a system bus. These hardware blocks constitute a computer system (an example of a computer). The CPU 51 (CPU core) reads a software program from the ROM 52, expands the program into the RAM 53, and executes it, thereby realizing the functions of the camera ECU 1.

[0024] The CPU 51 has a known timer function. Although a CPU is used as the processor, other processors such as an MPU (micro processing unit) may also be used.

[0025] The global memory 54 and the local memory 55 are memories used in the LET and are composed of non-volatile semiconductor memories. For example, the control programs may be stored in the global memory 54 or the local memory 55, which are composed of semiconductor memories or the like. The global memory area and the local memory area may be realized by making the address areas different in one memory. Also, the addresses that can be referenced in the memory may be set for each of the global memory area and the local memory area by using a programming language such as C.

[0026] The input / output interface 56 is an interface for communicating signals and data with each sensor and each actuator. The ECU is equipped with an A / D (Analog / Digital) converter (not shown) for processing input / output signals of each sensor, a driver circuit, etc. The input / output interface 56 may also function as the A / D converter and the driver circuit.

[0027] The network interface 57 is configured to be able to transmit and receive various data to and from other ECUs connected to the in-vehicle network 16 via the in-vehicle network 16 to which a terminal is connected.

[0028] The same applies to the hardware configurations of the LIDAR ECU 2 and the autonomous driving ECU 3. In the LIDAR ECU 2, the CPU 51 executes a program stored in the ROM 52 to realize the functions of the LIDAR ECU 2. In the autonomous driving ECU 3, the CPU 51 executes a program stored in the ROM 52 to realize the functions of the autonomous driving ECU 3. These programs may be stored in the global memory 54 or the local memory 55.

[0029] <Third Electronic Control Unit (Autonomous Driving ECU)> Here, the function of the third electronic control unit (autonomous driving ECU 3) will be described in further detail. FIG. 3 is a flowchart showing an outline of a processing procedure in the third electronic control unit (autonomous driving ECU 3) in the first embodiment. In step S1, the autonomous driving ECU 3 generates a camera risk map 17 based on the camera object detection data 10.

[0030] FIG. 4 is a diagram showing an example of the camera risk map 17 in the first embodiment. The camera risk map 17 is a two-dimensional array that stores integer values, and divides the area ahead of the vehicle 100 (the area photographed in the direction of travel) into a grid, assigning a value of 1 to grids (array elements) in which an object is detected by the camera object detection data 10, and assigning a value of 0 to other grids (array elements) (the value 0 is omitted in FIG. 4). For example, since no object is detected in the lower left corner of the grid, 0 is assigned to Camera_risk[0][0]. Also, since an object is detected in a grid one grid away from the lower right corner of the grid in the direction of travel (one grid upward in the figure), 1 is assigned to Camera_risk[1][4].

[0031] Returning to the description of Fig. 3, in step S2, the autonomous driving ECU 3 generates a LIDAR risk map 18 based on the LIDAR object detection data 12.

[0032] FIG. 5 is a diagram showing an example of the LIDAR risk map 18 in the first embodiment. The LIDAR risk map 18 is a two-dimensional array that stores integer values, and divides the area ahead of the vehicle 100 (measurement area in the travel direction) into a grid, assigning 1 to grids (array elements) where an object is detected by the LIDAR object detection data 12, and assigning 0 to other grids (array elements) (0 is omitted in FIG. 5). For example, since no object is detected in the lower left corner of the grid, 0 is assigned to Lidar_risk[0][0]. Also, since an object is detected in a grid one grid away from the lower right corner of the grid in the travel direction (one grid upward in the figure), 1 is assigned to Lidar_risk[1][4].

[0033] Returning to the description of Fig. 3, in step S3, the autonomous driving ECU 3 superimposes the camera risk map 17 and the LIDAR risk map 18 to generate a risk map 19.

[0034] FIG. 6 is a diagram showing an example of a superimposed risk map 19 (synthetic risk map) in the first embodiment. In this embodiment, 1 is assigned to a grid (array element) in which an object is detected in at least one of the camera risk map 17 and the LIDAR risk map 18. For example, since an object is detected in the camera risk map 17, 1 is assigned to Risk[6][1] of the risk map 19. Furthermore, since an object is detected in the LIDAR risk map 18, 1 is assigned to Risk[0][4] of the risk map 19. Furthermore, since an object is not detected in either the camera risk map 17 or the LIDAR risk map 18, 0 is assigned to Risk[6][4] of the risk map 19.

[0035] Returning to the description of Fig. 3, in step S4, the autonomous driving ECU 3 generates a travel trajectory 20 of the vehicle 100 using information from the risk map 19. Any method may be used for the trajectory generation, and examples thereof are omitted since they are not related to the present invention. In addition, examples of the format of the data representing the travel trajectory 20 are also omitted since they are not related to the present invention.

[0036] In step S5, the autonomous driving ECU 3 generates control command values ​​(steering control command 13, accelerator control command 14, and brake control command 15) using information on the driving trajectory 20. Any method may be used to generate the command values, and examples are omitted since they are not related to the present invention. In addition, examples of the formats of the steering control command 13, accelerator control command 14, and brake control command 15 are also omitted since they are not related to the present invention.

[0037] From the above, it should be noted that the generation of the camera risk map 17 in step S1 and the generation of the LIDAR risk map 18 in step S2 are not related to each other. Furthermore, it should be noted that the risk map overlay in step S3 is related to the camera risk map 17 and the LIDAR risk map 18. That is, in order to start the risk map overlay process, both the camera risk map 17 and the LIDAR risk map 18 need to be generated.

[0038] <Control period> FIG. 7 is a diagram showing an example of a control period of the electronic system 110 in the first embodiment. The electronic system 110 acquires camera image data 9, and generates camera object detection data 10 from the camera image data 9 (S11). This process is executed as an internal process of the camera ECU 1. The electronic system 110 also acquires LIDAR point cloud data 11, and generates LIDAR object detection data 12 from the LIDAR point cloud data 11 (S12). This process is executed as an internal process of the LIDAR ECU 2.

[0039] The electronic system 110 synchronously executes the acquisition of camera image data 9 (S11) and the acquisition of LIDAR point cloud data 11 (S11), and executes the processes from the data acquisition to the generation of the travel trajectory 20 (S4) every 100 ms. Further, the electronic system 110 executes the generation of control command values (steering control command 13, accelerator control command 14, and brake control command 15) based on the travel trajectory 20 every 1 ms. Note that the period is merely an example and is not limited thereto.

[0040] Hereinafter, in the present embodiment, the processes from the acquisition of the camera image data 9 and the acquisition of the LIDAR point cloud data 11 to the generation of the travel trajectory 20 will be described in particular.

[0041] <Required Time for Inter-ECU Communication> The camera object detection data 10 is generated and transmitted by the camera ECU 1, and the LIDAR object detection data 12 is generated and transmitted by the LIDAR ECU 2. Since these two object detection data are received by the autonomous driving ECU 3, inter-ECU communication occurs. In the present embodiment, the time (tolerance limit) required for communication between the camera ECU 1 and the autonomous driving ECU 3 and between the LIDAR ECU 2 and the autonomous driving ECU 3 is set to 10 ms. That is, it is guaranteed that the camera image data 9 arrives at the autonomous driving ECU 3 10 ms after the camera image data 9 is transmitted from the camera ECU 1.

[0042] This is because the in-vehicle network 16 of the present embodiment adopts a communication method in which the times of all ECUs connected to the in-vehicle network 16 are synchronized and data transmission within a certain time can be guaranteed. As a result, it becomes possible to extend the LET between ECUs.

[0043] <Tasks from Data Acquisition to Trajectory Generation> FIG. 8 is a diagram showing an example in which the processes from data acquisition to trajectory generation in the first embodiment are mapped to tasks. In the camera ECU 1 (first electronic control unit), camera image data 9 is acquired from the camera 4, calculations are performed, and the results are transmitted as camera object detection data 10. In this specification, all of these processes are collectively referred to as a "camera object detection task 21" (first task).

[0044] In the LIDAR ECU 2 (second electronic control device), the LIDAR point cloud data 11 is acquired from the LIDAR 5, calculations are performed, and the results are transmitted as LIDAR object detection data 12. In this specification, all of these processes are collectively referred to as a "LIDAR object detection task 22" (second task).

[0045] In the autonomous driving ECU 3 (third electronic control device), the process from receiving the camera object detection data 10 to generating the camera risk map 17 and writing it to the global memory 54 of the autonomous driving ECU 3 is referred to as the "camera risk map generation task 23."

[0046] In addition, in the autonomous driving ECU 3, the process from receiving the LIDAR object detection data 12 to generating the LIDAR risk map 18 and writing it to the global memory 54 of the autonomous driving ECU 3 is referred to as a "LIDAR risk map generation task 24."

[0047] In addition, in the autonomous driving ECU 3, the processing of reading the camera risk map 17 and the LIDAR risk map 18 from the global memory 54 of the autonomous driving ECU 3, generating the risk map 19 and writing it to the global memory 54 of the autonomous driving ECU 3 is referred to as the "risk map superposition task 25."

[0048] Furthermore, the process of reading the risk map 19 from the global memory 54 of the autonomous driving ECU 3 and writing the driving trajectory 20 to the global memory 54 of the autonomous driving ECU 3 is referred to as a "trajectory generation task 26."

[0049] The autonomous driving ECU 3 generates a series of tasks (third task) consisting of the camera risk map generation task 23, the LIDAR risk map generation task 24, the risk map superposition task 25, and the trajectory generation task 26 described above.

[0050] That is, the camera object detection task 21 is executed in the camera ECU 1. Also, the LIDAR object detection task 22 is executed in the LIDAR ECU 2. Then, the camera risk map generation task 23, the LIDAR risk map generation task 24, the risk map superposition task 25, and the trajectory generation task 26 are executed in the autonomous driving ECU 3.

[0051] <Making tasks LET compatible> FIG. 9 shows an example before the task is made compatible with LET. Fig. 10 is a diagram showing an example after tasks in the first embodiment of the present invention are made to correspond to LET. In Fig. 9 and Fig. 10, the horizontal axis represents time (flow of time).

[0052] The LIDAR risk map generation task 24 will be taken as an example for explanation. In Fig. 9, the LIDAR risk map generation task 24 is composed of a plurality of processes 24a to 24d. The LIDAR risk map generation task 24 reads a global variable a in process 24a, and reads global variables a and c in process 24c. The LIDAR risk map generation task 24 then writes a global variable b in process 24b, and writes a global variable d in process 24d.

[0053] In this way, if the global variables are read and written at any timing, if there is a discrepancy in the execution timing of the LIDAR risk map generation task 24, the values ​​of the global variables read and written will differ and the calculation results will be non-deterministic. This is the reason why changing the task schedule requires a lot of verification work.

[0054] Therefore, LET is introduced into task scheduling, and the LIDAR risk map generation task 24 is divided into three tasks (LIDAR risk map generation R task 241, LIDAR risk map generation E task 242, and LIDAR risk map generation W task 243) shown in Fig. 10. First, in the LIDAR risk map generation R task 241, global variables a to d that are read and written for LIDAR risk map generation are copied from global memory 54 to local memory 55. The global variables a to d copied to local memory 55 are simply referred to as variables a to d.

[0055] Next, the LIDAR risk map generation E task 242 executes processes 24a to 24d. At this time, the LIDAR risk map generation E task 242 uses the variables a to d copied to the local memory 55 in the LIDAR risk map generation R task 241, rather than directly reading and writing the global variables a to d from the global memory 54.

[0056] Finally, in the LIDAR risk map generation W task 243, the variables a to d in the local memory 55 are written to the global variables a to d in the global memory 54.

[0057] By doing this, as long as the execution timing of the LIDAR risk map generation R task 241 and the LIDAR risk map generation W task 243 is fixed, the calculation results are guaranteed to remain unchanged even if the execution timing of the LIDAR risk map generation E task 242 varies.

[0058] 8 are divided into an R task, a W task, and an E task, similar to the LIDAR risk map generation task 24. Hereinafter, the method of determining the names of the tasks (R task, W task, E task) and numbering in this specification will follow the example of the LIDAR risk map generation task 24.

[0059] In this way, each task processing unit (camera ECU 1, LIDAR ECU 2, autonomous driving ECU 3) has a memory (global memory 54, local memory 55) to which information necessary for executing the corresponding task is read and the processing results of the task are written.

[0060] <Normal LET interval> Fig. 11 is a diagram for explaining intervals in normal LET, in which the horizontal axis represents time. The processing time required for the LIDAR risk map generation R task 241 and the LIDAR risk map generation W task 243 is sufficiently shorter than that of the LIDAR risk map generation E task 242. Therefore, the processing time of the LIDAR risk map generation task 24 and the processing time of the LIDAR risk map generation E task 242 are approximately equal. In Fig. 11, the processing times of the LIDAR risk map generation R task 241 and the LIDAR risk map generation W task 243 are merely depicted as being long in order to represent characters. Note that Fig. 11 shows the cases where the processing time of the LIDAR risk map generation task 24 is the shortest processing time T1, the average processing time T2 (corresponding to the budget), and the maximum processing time T3 which is the worst execution time.

[0061] The processing time for generating the LIDAR risk map varies depending on the surrounding environment of the vehicle 100. In the LET, it is important that the timing for reading and writing to the global memory 54 is fixed. Therefore, when the timing for the LIDAR risk map generation R task 241 and the LIDAR risk map generation W task 243 is fixed, it is necessary to ensure that the LIDAR risk map generation E task 242 is completed during that time. For that purpose, the time (LET interval T4) between the end of the LIDAR risk map generation R task 241 and the start of the LIDAR risk map generation W task 243 needs to be equal to or longer than the maximum processing time T3 of the LIDAR risk map generation task 24. If this is applied to the tasks in all the ECUs, it is equivalent to considering the condition that all the tasks require the worst execution time at the same time, and the CPU utilization efficiency is significantly reduced.

[0062] In addition, since the LIDAR risk map generation R task 241 and the LIDAR risk map generation W task 243 only read and write to the global memory 54 and the local memory 55, the processing time required for each task is almost constant each time.

[0063] <Budget and Margin> FIG. 12 is a diagram for explaining a reference time (budget) and a margin in the first embodiment. FIG. 12 also shows the cases where the processing time of the LIDAR risk map generation task 24 is the shortest processing time T1, the average processing time T2 (budget), and the maximum processing time T3 which is the worst execution time.

[0064] In this embodiment, the interval in LIDAR risk map generation is determined in consideration of the problems of the determination method shown in FIG. 11. That is, the interval in LIDAR risk map generation is determined not by the maximum processing time T3 of the LIDAR risk map generation E task 242, but by the average processing time T2 (average execution time) of the LIDAR risk map generation E task 242. This average processing time T2 is also described as the "average execution time T2" ​​and is set as the reference time (budget B). Furthermore, an appropriate allowance time (margin M) is determined, and the time obtained by adding the budget B and the margin M is set as the LET interval T5 in LIDAR risk map generation. Here, the method of determining the margin M may be, for example, twice the standard deviation of the processing time required for LIDAR risk map generation.

[0065] <Extended intervals and shared margins> When the budget B is the average execution time T2, if the worst-case execution time is required for LIDAR risk map generation, the completion of the LIDAR risk map generation E task 242 will not be in time for the start timing of the LIDAR risk map generation W task 243. Therefore, the margin M is shared between multiple tasks, and the execution timing of the LIDAR risk map generation W task 243 is made variable.

[0066] Fig. 13 is an example of a timing chart showing interval extension and margin sharing in the first embodiment. In Fig. 13, the horizontal axis represents time (time flow). Fig. 13 shows the execution timing of a camera object detection task 21, a LIDAR object detection task 22, a camera risk map generation task 23, a LIDAR risk map generation task 24, a risk map superposition task 25, and a trajectory generation task 26. Note that the reference symbols representing each task are omitted in the figure.

[0067] In this embodiment, as shown in Fig. 7, the electronic system 110 synchronously acquires camera image data 9 and LIDAR point cloud data 11, and executes the process from data acquisition to generation of the travel trajectory 20 in a cycle of 100 ms. For this reason, the camera object detection R task and the LIDAR object detection R task synchronized therewith are fixed, the trajectory generation W task is also fixed, and the remaining tasks are variable to share a margin between the tasks. In other words, the (extended) LET interval is the period from the start of the camera object detection E task and the LIDAR object detection E task to the end of the trajectory generation E task, and its value is 100 ms.

[0068] In this way, the (extended) LET interval (predetermined time interval) is the limit time from the timing when information required for executing the first or second task (e.g., camera object detection task 21 or LIDAR object detection task 22) is read from the first or second memory (e.g., global memory 54) to the timing when the processing result of the third task (e.g., trajectory generation task 26) is written to the third memory (e.g., global memory 54). This limit time is fixed in advance.

[0069] The budget for each task is based on the average execution time T2 of the E task. However, if communication (transmission) is included, the communication time d is added, and if there are tasks processed in parallel by other ECUs, the task with the longest average execution time T2 is used as the budget.

[0070] For example, the budget B1 for camera object detection is calculated by adding the average execution time T2 (E) of the camera object detection E task to the communication time of 10 ms (C). For LIDAR object detection (LIDAR ECU2) that is executed in parallel with camera object detection (camera ECU1), the average execution time T2 of the LIDAR object detection E task plus the communication time of 10 ms is smaller than B1, so it does not affect the calculation of budget B1.

[0071] If the value obtained by adding the average execution time T2 of the LIDAR object detection E task to the communication time required of 10 ms is greater than the value obtained by adding the average execution time T2 of the camera object detection E task to the communication time required of 10 ms, the value obtained by adding the average execution time T2 of the LIDAR object detection E task to the communication time required of 10 ms becomes the budget B1.

[0072] In FIG. 13, the time obtained by adding up the periods (shared margins 1 to 4) in which no processing is described becomes a margin, which is shared between the E tasks included in the (extended) LET interval. That is, if the lengths of the shared margins 1 to 4 are M1 to M4, respectively, the shared margin is M1+M2+M3+M4. The shared margins 1 to 4 are used in the processing of the corresponding tasks when an execution delay occurs in any of the first task (camera object detection task 21), the second task (LIDAR object detection task 22), and the third task (for example, the camera risk map generation task 23 to the activation generation task 26). If the processing time of each R task and each W task is constant at d, the following formula is established from the timing chart in FIG. 13. 2d or 3d represents two or three times the processing time d.

[0073] M1+M2+M3+M4 =100-(B1+B2+B3+B4+B5)-(d+3d+3d+2d+d)

[0074] This ensures that the generation of the travel trajectory 20 is performed in a 100 ms cycle, as long as multiple E tasks included in the (extended) LET interval do not cause processing delays at the same time.

[0075] In the case of normal LET, for example, the start timing of the camera object detection W task is fixed. Therefore, if (camera object detection E task + communication time required 10 ms) becomes larger than B1 + M1, a deadline miss occurs immediately, and LET scheduling fails. However, as in this embodiment, by sharing the LET interval and margin, if all other tasks are within the budget, it is possible to meet the deadline even if (camera object detection E task + communication time required 10 ms) is delayed to B1 + M1 + M2 + M3 + M4.

[0076] As shown in FIG. 13, in the autonomous driving ECU 3 of this embodiment, the camera risk map generation is usually scheduled to be executed before the LIDAR risk map generation.

[0077] <Timing chart changes to accommodate task processing order changes> FIG. 14 is an example of an improved timing chart that takes into account the change in the processing order in the first embodiment. In Fig. 13, the execution timing of tasks other than the camera object detection R task (and LIDAR object detection R task) and the trajectory generation W task is variable. Therefore, as shown in Fig. 14, the execution order of the camera risk map generation E task and the LIDAR risk map R task is switched. This is necessary to make it possible to switch the execution order of the camera risk map generation and the LIDAR risk map generation in Fig. 16 described later. Note that the execution order of tasks is synonymous with the start-up order of tasks.

[0078] <Maximum allowable processing delay time when processing order is not changed> FIG. 15 is an example of a timing chart showing the maximum allowable processing delay when the processing order change in the first embodiment is not performed. In order to comply with the tasks included in the (extended) LET interval, the maximum processing time allowed for the camera risk map generation E task is B1 + M1 + M2 + M3 + M4 - 10 ms (required communication time). If the processing time exceeds this, the trajectory generation W task will not be able to keep up with the 100 ms control period.

[0079] <Maximum allowable processing delay time when changing the processing order> FIG. 16 is an example of a timing chart showing the maximum allowable processing delay when the processing order is changed in the first embodiment. As described above, in the series of task processes, the generation of the camera risk map 17 and the generation of the LIDAR risk map 18 are not related to each other. Also, in the series of task processes, the risk map overlay is related to the camera risk map 17 and the LIDAR risk map 18. That is, in order to start the risk map overlay process, both the camera risk map 17 and the LIDAR risk map 18 need to be generated.

[0080] For these reasons, when the camera object detection E task is delayed, the electronic system 110 executes the LIDAR risk map generation E task first, and then executes the camera risk map generation E task after the camera object detection E task and the W task are completed. Then, finally, the camera risk map generation W task and the LIDAR risk map generation W task are executed.

[0081] Therefore, in order to comply with the tasks included in the (extended) LET interval, the maximum processing time allowed for the camera risk map generation E task is B1 + M1 + M2 + M3 + M4 + d + B3 - 10 ms (required communication time). If the processing time is longer than this, the trajectory generation W task will not be able to keep up with the 100 ms control period.

[0082] In this way, by switching the task processing order, the delay of the camera object detection E task is further tolerated compared to when the switching is not performed. This is exactly equivalent to the sum of the global variable read time in the switched task processing and the budget allocated to the task processing (d+B3).

[0083] <Recalculating the schedule> Here, the idea behind recalculating the schedule will be described with reference to FIG. Fig. 17 is a flowchart for determining whether or not to change the processing order in the third electronic control device (autonomous driving ECU 3) according to the first embodiment. Fig. 17 will be described assuming that the autonomous driving ECU 3 executes the camera risk map generation task 23, the LIDAR risk map generation task 24, the risk map superimposition task 25, and the trajectory generation task 26 as shown in Figs. 13 to 16.

[0084] First, in the autonomous driving ECU 3, the schedule recalculation unit 82 calculates the expected processing time of the camera object detection E task being executed by the camera ECU 1 (S21). The expected processing time is the expected time for the processing of the target task to be completed. For example, from FIG. 15, the expected processing time of the camera object detection E task is "B1".

[0085] Next, the scheduling recalculation unit 82 judges whether the expected processing time of the camera object detection E task is equal to or less than the time "B1+M1+M2+M3+M4-10" [ms] (S22). If the expected processing time is equal to or less than "B1+M1+M2+M3+M4-10" [ms] (YES in S22), the scheduling recalculation unit 82 advances the process to step S25. If the expected processing time exceeds "B1+M1+M2+M3+M4-10" [ms] (NO in S22), the scheduling recalculation unit 82 advances the process to the judgment process of step S23.

[0086] Next, in step S23, the scheduling recalculation unit 82 judges whether the expected processing time of the camera object detection E task is equal to or less than "B1+B3+d+M1+M2+M3+M4-10" [ms] (S23). In this judgment process, the budget B3 and the required communication time d of the LIDAR risk map generation E task are included in the margin. Then, if the expected processing time exceeds "B1+B3+d+M1+M2+M3+M4-10" [ms] (NO in S23), the scheduling recalculation unit 82 advances the process to step S25. Also, if the expected processing time is equal to or less than "B1+B3+d+M1+M2+M3+M4-10" [ms] (YES in S23), the scheduling recalculation unit 82 advances the process to step S24.

[0087] Next, if the determination in step S23 is YES, the schedule recalculation unit 82 switches the order of camera object detection and LIDAR risk map generation (see FIG. 16) (S24).

[0088] On the other hand, if the determination is YES in step S22 or NO in step S23, the schedule recalculation unit 82 does not switch the order of camera object detection and LIDAR risk map generation (see FIG. 15) (S25). After the process of step S24 or S25, the process of this flowchart ends.

[0089] Thus, in this embodiment, the autonomous driving ECU 3 determines whether to rearrange the execution order based on whether the estimated processing time of the camera object detection E task exceeds the maximum allowable processing time when the execution order is not rearranged and is within the maximum allowable processing time when the execution order is rearranged (S23). The autonomous driving ECU 3 switches the execution order of the camera risk map generation R / E task and the LIDAR risk map generation R / E task as shown in Figure 16 (S24) only when the estimated processing time exceeds the maximum allowable processing time when the execution order is not switched and is within the maximum allowable processing time when the execution order is switched (YES in S23). Conversely, if this condition is not met (YES in S22 or NO in S23), the execution order of each task will be as shown in FIG. 15 (no change in task scheduling) (S25).

[0090] The determination processes in steps S22 and S23 may be performed based on the expected overrun time [ms] included in the processing time overrun task information Ie, which will be described later.

[0091] <Configuration of the scheduling function> Next, a configuration for realizing the scheduling function shown in FIGS. 15-17 will be described. 18 is a block diagram showing the scheduling functions of each electronic control unit (ECU) according to the first embodiment. These functions are realized by a CPU 51 (see FIG. 2) included in each ECU executing a program stored in a ROM 52 or the like.

[0092] As shown in the figure, the first electronic control unit (camera ECU1) and the second electronic control unit (LIDAR ECU2) each include a scheduling unit 71 and a data transmission / reception unit 74.

[0093] The scheduling unit 71 executes tasks based on a processing schedule (activation order) of the tasks. The scheduling unit 71 includes a task activation unit 72 and a task processing time management unit 73. At least the camera ECU 1 includes the task processing time management unit 73.

[0094] The task starting unit 72 starts and executes the tasks assigned to each ECU in a set start order. The task processing time management unit 73 (an example of a processing time management unit) manages the processing time of the activated task. When the time required for processing the activated task exceeds a predetermined time, the task processing time management unit 73 generates processing time exceeded task information Ie (see FIG. 20 described later) including information on the expected time for the processing of the task to be completed, and transmits the information to the data transmission / reception unit 74 via the in-vehicle network 16.

[0095] The data transmitter / receiver 74 transmits and receives data to and from the autonomous driving ECU 3 via the in-vehicle network 16. Here, the data transmitter / receiver 74 transmits the processing time exceeded task information Ie to the autonomous driving ECU 3. The data transmitter / receiver 74 is realized by the network interface 57.

[0096] The task processing time management unit 73 of the scheduling unit 71 may be provided only in the camera ECU 1 that executes the camera object detection task 21 that requires a longer processing time.

[0097] The third electronic control unit (autonomous driving ECU 3) has a scheduling unit 81 and a data transmission / reception unit 84.

[0098] The scheduling unit 81 executes tasks based on the task processing schedule (startup order). The scheduling unit 81 includes a schedule recalculation unit 82 and a task startup unit 83.

[0099] The scheduling recalculation unit 82 recalculates the processing schedule of the autonomous driving ECU 3 based on the processing time exceeded task information Ie received from the camera ECU 1 or the LIDAR ECU 2. Then, the scheduling unit 81 generates a task activation order change command Cs and outputs it to the task activation unit 83 when the recalculation requires a change in the task activation order. The task starting unit 83 starts and executes the tasks assigned to each ECU in a set start order. When the task starting unit 83 receives a task start order change command Cs from the schedule recalculation unit 82, the task starting unit 83 changes the task start order based on the task start order change command Cs and starts the tasks.

[0100] The data transmitter / receiver 84 transmits and receives data to and from the camera ECU 1 and the LIDAR ECU 2 via the in-vehicle network 16. Here, the data transmitter / receiver 84 receives the processing time exceeded task information Ie from the camera ECU 1 and the LIDAR ECU 2. The data transmitter / receiver 84 is realized by the network interface 57.

[0101] <Camera object detection E-task processing time management (calculation of estimated processing time)> Next, calculation of the estimated processing time will be described with reference to FIG. Fig. 19 is a diagram showing an example of a method for calculating an expected processing time of the camera object detection E task in the first electronic control unit (camera ECU1) according to the first embodiment. In Fig. 19, the method for calculating the expected processing time is expressed in source code.

[0102] For camera object detection, a double loop process using a for statement is performed by scanning the camera image line by line until scanning of all pixels is completed, and a total of N_i * N_j calculations are required. Therefore, in the camera ECU 1, a timer interrupt is generated at the time "d+B1" when the camera object detection data 10 is transmitted (should be transmitted) from the camera ECU 1 to the autonomous driving ECU 3. Then, if the camera object detection E task is not completed at the time "d+B1", the task processing time management unit 73 calculates the progress based on the value of the double loop index (scanning position represented by subscripts i and j). The progress can be calculated from the ratio of the total number of pixels in the camera image to the number of pixels for which calculation has been completed. In other words, the progress rate ((N_i * i) * N_j + j) / (N_i * N_j).

[0103] Because the progress rate is "progress" when the processing time reaches B1, the estimated processing time est at which the double-loop processing ends can be calculated as B1 / progress. Therefore, the estimated excess time "over" of the processing for the budget B1 is calculated as "est - B1." Finally, the camera ECU 1 transmits the value of the estimated excess time "over" calculated by the task processing time management unit 73 to the autonomous driving ECU 3 as the processing time excess task information Ie (this transmission process becomes the camera object detection W task).

[0104] In this way, the time expected for task processing to end (estimated processing time) is calculated based on the progress rate of the task processing (e.g., a camera object detection task) when the reference time of the task processing has passed. For example, the progress rate is calculated by dividing the value of an index used in a repetitive process included in the task processing when the reference time has passed by the number of repetitions required (e.g., equivalent to the number of pixels in a camera image).

[0105] <Task information for which processing time has exceeded> Next, the processing time exceeded task information Ie will be described with reference to FIG. FIG. 20 is a diagram showing an example of the processing time exceeded task information Ie transmitted from the first electronic control unit (camera ECU 1) to the third electronic control unit (autonomous driving ECU 3) in the first embodiment.

[0106] The processing time exceeded task information Ie has items of "task type" indicating the type of task that exceeded the processing time, and "expected excess time" (the "over" value calculated above). FIG. 20 shows an example in which the task type is "camera object detection" and the expected excess time [ms] is "1.32". The task type may be described in a format that allows mutual identification between the camera ECU 1 and the autonomous driving ECU 3. For example, an identification ID may be assigned to the task in advance. The processing time exceeded task information Ie transmitted from the LIDAR ECU 2 to the autonomous driving ECU 3 is similar to that shown in FIG. 20.

[0107] Next, the start of a task in each electronic control unit will be described.

[0108] <Starting a task in the first electronic control unit (camera ECU)> In the camera ECU 1, a timer (not shown) mounted in the camera ECU 1 is used to set the camera object detection R task to be executed at a fixed cycle of 100 ms. In addition, the camera object detection E task is set to be started d [ms] after the camera object detection R task is started using the timer. Furthermore, using the above timer, the processing time management task "Interrupt_handler_high_priority(Timer_d_plus_B1)" shown in Fig. 19 is started B1 [ms] after the start of the camera object detection E task. The priority of the timer interrupt of the processing time management task is set higher than the priority of the timer interrupt of the camera object detection E task so that the processing time management task is started even during the execution of the camera object detection E task. Finally, when the camera object detection E task ends, the processing result of the camera object detection E task (camera object detection data 10) is transmitted to the autonomous driving ECU 3 (this becomes the camera object detection W task).

[0109] <Starting the task in the second electronic control unit (LIDAR ECU)> The task initiation in the LIDAR ECU 2 is similar to that in the first electronic control unit (camera ECU 1). Note that the timing at which the LIDAR object detection R task is executed is set to be synchronized with the timing at which the camera object detection R task is executed in the camera ECU 1.

[0110] <Task startup in the third electronic control unit (autonomous driving ECU)> FIG. 21 is a diagram showing, in source code, a method for starting a task in the third electronic control unit (autonomous driving ECU 3) according to the first embodiment. As shown in Figure 17 (recalculation of scheduling), only when the expected overrun processing time value of the camera object detection E task exceeds "M1+M2+M3+M4-10" [ms] and is equal to or less than "B3+d+M1+M2+M3+M4-10" [ms], the execution order of the camera risk map generation R / E task and the LIDAR risk map generation R / E task is changed as shown in Figure 16. Furthermore, if this condition is not met, the task execution order will be as shown in Figure 15 (no change in task scheduling).

[0111] Therefore, when the autonomous driving ECU 3 receives the processing time exceeded task information Ie, it receives the received event notification, obtains the expected excess time contained in the processing time exceeded task information Ie, and sets the value of the variable sch_mode, which represents the scheduling mode, to 1 only if the value exceeds "M1+M2+M3+M4-10" [ms] and is equal to or less than "B3+d+M1+M2+M3+M4-10" [ms].

[0112] Thereafter, when the autonomous driving ECU 3 receives the camera object detection data 10 from the camera ECU 1, it receives a reception event notification of the data, and if the value of the variable sch_mode is 0 (default value), it performs camera risk map generation, LIDAR risk map generation, risk map superimposition, and trajectory generation in that order according to Fig. 15. On the other hand, if the value of the variable sch_mode is 1, the autonomous driving ECU 3 has already performed LIDAR risk map generation when it receives the camera object detection data 10, so it performs the remaining processes of camera risk map generation, risk map superimposition, and trajectory generation in that order.

[0113] Furthermore, when the autonomous driving ECU 3 receives the LIDAR object detection data 12 from the LIDAR ECU 2, it receives a reception event notification of the data, and if the value of the variable sch_mode is 0 (default value), it does nothing. If the value of the variable sch_mode is 1, it executes LIDAR risk map generation.

[0114] At this time, the timing of reception of the LIDAR object detection data 12 and the arrival of the processing time exceeded task information Ie may possibly arrive at the time "d+B1+10" [ms] when the start of the (extended) LET interval is set to time 0, particularly if the LIDAR object detection ends exactly at the processing time B1. For this reason, the autonomous driving ECU 3 uses a flag to manage them so that it does not matter which one arrives first.

[0115] That is, if the processing time exceeded task information Ie arrives first, flag 1 is set, and a LIDAR risk map is generated when a reception event notification is issued for the LIDAR object detection data 12. On the other hand, if the LIDAR object detection data 12 arrives first, flag 0 is set, and a LIDAR risk map is generated when a reception event notification is issued for the processing time exceeded task information Ie. This realizes the processing shown in Figures 15-17.

[0116] As described above, in the electronic system according to the first embodiment, a plurality of task processing units (camera ECU 1, LIDAR ECU 2, autonomous driving ECU 3) that process assigned tasks are connected via a network (in-vehicle network 16). The multiple task processing units each include a task startup unit (task startup unit 72) that starts and executes each task, and the third task processing in the third task processing unit (autonomous driving ECU 3) is configured to utilize at least the processing result of the first task in the first task processing unit (camera ECU 1) that precedes the third task processing or the processing result of the second task in the second task processing unit (LIDAR ECU 2), and to periodically execute a series of processes from the preceding first task processing or second task processing to the third task processing at a predetermined time interval (LET interval).

[0117] Furthermore, in the electronic system according to this embodiment, the third task (task processing by the autonomous driving ECU 3) includes a task that uses the processing result of the first task (camera object detection data 10) and a task that does not use the processing result of the first task but uses only the processing result of the second task (LIDAR object detection data 12). The third task starting unit (task starting unit 83) is configured to start a task that does not use the processing result of the first task but uses only the processing result of the second task in advance when the first task processing exceeds a predetermined reference time, among the tasks assigned to the third task processing, based on a task activation order change command Cs from the scheduling recalculation unit (scheduling recalculation unit 82).

[0118] More specifically, in the electronic system according to the present embodiment, when the first task processing is completed within a reference time predetermined for the first task processing, the third task starting unit (task starting unit 83) is configured to first start a task (camera risk map generation task) using the processing result of the first task (camera object detection data 10) and then start a task (LIDAR risk map generation task) using the processing result of the second task (LIDAR object detection data 12). Also, when the first task processing exceeds the reference time and the expected time for the first task processing included in the processing time excess task information Ie is equal to or less than the sum of the reference time, the used slack time, and the reference time predetermined for the second task processing, the third task starting unit (task starting unit 83) is configured to first start a task (LIDAR risk map generation task) using only the processing result of the second task (LIDAR object detection data 12), and then start a task (camera risk map generation task) using the processing result of the first task (camera object detection data 10).

[0119] The processing results of the above first task and the processing results of the second task are the processing results of data obtained from the sensing devices (camera 4, LIDAR 5), and the third task processing unit (autonomous driving ECU 3) uses the processing results of the first task and / or the processing results of the second task to control the driving of the vehicle (generates a driving trajectory and calculates control command values).

[0120] The electronic system according to the first embodiment described above changes the task processing order in the third electronic control unit (autonomous driving ECU 3) that executes the subsequent process in accordance with the load status in the first electronic control unit (camera ECU 1) that executes the preceding process. This makes it possible to improve the utilization efficiency of the CPUs mounted in the first and third electronic control units in this embodiment. In addition, by observing the (extended) LET interval, it has the effect of theoretically guaranteeing that changes in task scheduling will not affect other processes.

[0121] [Second embodiment] An electronic system and an electronic control device according to a second embodiment of the present invention will be described. The second embodiment differs from the first embodiment in that when the processing delay in the electronic control device (first electronic control device) that executes the preceding process is large and the processing in the set control period cannot be completed in time, the subsequent process in another electronic control device (third electronic control device) is replaced with the previous value. The configurations of the vehicle and electronic system in the second embodiment are the same as those of the vehicle 100 and electronic system 110 in the first embodiment. Note that in the second embodiment, the same reference numerals are used for the configurations that are the same as those in the first embodiment, and the description thereof will be omitted.

[0122] <Recalculating the schedule> 22 is a flowchart for determining whether or not the processing order needs to be changed in the second embodiment of the present invention. In FIG. 22, the processing of step S31 is added compared to FIG. Fig. 23 is a diagram showing the timing at which processing is performed by each electronic control unit when processing is skipped in the second embodiment. The following will describe Figs. 22 and 23, focusing on the differences from the first embodiment.

[0123] In FIG. 22, if the expected processing time of the camera object detection E task exceeds "B1+B3+d+M1+M2+M3+M4-10" [ms] (NO in S23), the schedule recalculation unit 82 changes the task scheduling to skip the subsequent processing (see FIG. 23) (S31). In this case, the autonomous driving ECU 3 cannot generate the latest risk map 19. do not have Therefore, a travel trajectory 20 is generated using a previous risk map 19, and values ​​of various control commands 13 to 15 are output.

[0124] In this embodiment, only when the judgment result in step S22 is YES, the schedule recalculation unit 82 performs the process of step S25. That is, the schedule recalculation unit 82 does not change the order of the camera object detection and the LIDAR risk map generation (see FIG. 15). After the process of step S24, S25, or S31, the process of this flowchart ends.

[0125] In this manner, in this embodiment, as in the first embodiment, the decision to rearrange the execution order is made based on whether the estimated processing time exceeds the maximum allowable processing time when the execution order is not rearranged and is within the maximum allowable processing time when the execution order is rearranged (S23). Only when the estimated processing time exceeds the maximum allowable processing time when the execution order is not changed and is within the maximum allowable processing time when the execution order is changed (YES in S23), is the execution order of the camera risk map generation R / E task and the LIDAR risk map generation R / E task changed as shown in Figure 16 (S24). However, if the estimated processing time exceeds the maximum allowable processing time when the execution order is changed (NO in S23), the camera risk map generation, LIDAR risk map generation, risk map overlay and trajectory generation processes are skipped and not executed (S31). Only when the estimated processing time is equal to or less than the maximum allowable processing time when the execution order is not changed (YES in S22), the execution order of each task is set as shown in FIG. 15 (no change in task scheduling) (S25).

[0126] <Task startup in the third electronic control unit (autonomous driving ECU)> FIG. 24 is a diagram showing, in source code, a method for starting a task in the third electronic control unit (autonomous driving ECU 3) according to the second embodiment. When the autonomous driving ECU 3 receives the processing time exceeded task information Ie, it receives the received event notification, acquires the expected excess time included in the processing time exceeded task information Ie, and if the value exceeds "M1+M2+M3+M4-10" [ms] and is equal to or less than "B3+d+M1+M2+M3+M4-10" [ms], it sets the value of the variable sch_mode representing the scheduling mode to 1. Here, if the value of the expected excess time exceeds "B3+d+M1+M2+M3+M4-10" [ms], it sets the value of the variable sch_mode representing the scheduling mode to 2.

[0127] Thereafter, when the autonomous driving ECU 3 receives the camera object detection data 10 from the camera ECU 1, it receives a reception event notification of the data, and if the value of the variable sch_mode is 0 (default value), it performs camera risk map generation, LIDAR risk map generation, risk map superimposition, and trajectory generation in that order according to Fig. 15. On the other hand, if the value of the variable sch_mode is 1, LIDAR risk map generation has already been executed when the camera object detection data 10 is received, so the autonomous driving ECU 3 performs the remaining processes of camera risk map generation, risk map superimposition, and trajectory generation in that order. Furthermore, if the value of the variable sch_mode is 2, the autonomous driving ECU 3 does nothing.

[0128] Furthermore, when the autonomous driving ECU 3 receives the LIDAR object detection data 12 from the LIDAR ECU 2, it receives a reception event notification of the data, and does nothing if the value of the variable sch_mode is 0 (default value) or 2. Furthermore, if the value of the variable sch_mode is 1, it executes LIDAR risk map generation.

[0129] As described above, in the electronic system of the second embodiment, if the limit time is exceeded even when a task (e.g., a LIDAR risk map generation task) assigned to the third task processing by the third task startup unit (task startup unit 83) is executed based on the task startup order change command Cs, the third task processing unit (autonomous driving ECU 3) reads the previous processing result (previous value) of the third task from the third memory (global memory 54) without waiting for the processing result of the first task or the processing result of the second task.

[0130] The electronic system according to the second embodiment described above determines in advance that the previous value will be used continuously in the subsequent process when the processing delay in the first electronic control unit (camera ECU1) that executes the preceding process is large and the processing delay is not in time for a predetermined control period. This has the effect of preventing inconsistency in data (e.g., data for generating the driving trajectory 20) in the third electronic control unit (autonomous driving ECU3) in this embodiment.

[0131] [Third embodiment] An electronic system and an electronic control device according to a third embodiment of the present invention will be described. The third embodiment differs from the first embodiment in that when the processing delay in the electronic control device (first electronic control device) that executes the preceding process becomes large, the control method of another electronic control device (third electronic control device) that executes the subsequent process in the set control period is changed. Note that in the third embodiment, the same components as those in the first embodiment are denoted by the same reference numerals and their description is omitted.

[0132] <Recalculating the schedule> 25 is a flowchart for determining whether or not the processing order needs to be changed in the third embodiment of the present invention. In FIG. 25, the processing of step S41 is added compared to FIG. Fig. 26 is a diagram showing the timing of processing in each electronic control unit when the processing is changed in the third embodiment. The following will describe Figs. 25 and 26, focusing on the parts that are different from the first embodiment.

[0133] In Fig. 25, if the expected processing time of the camera object detection E task exceeds "B1+B3+d+M1+M2+M3+M4-10" [ms] (NO in S23), the scheduling recalculation unit 82 changes the task scheduling so that the camera risk map is not generated and only the LIDAR risk map 18 is generated (see Fig. 26) (S41). In this case, the autonomous driving ECU 3 generates the driving trajectory 20 using the risk map 19 on which only the LIDAR risk map 18 is superimposed, and outputs values ​​of the various control commands 13 to 15.

[0134] In this embodiment, only when the judgment result in step S22 is YES, the schedule recalculation unit 82 performs the process of step S25. That is, the schedule recalculation unit 82 does not change the order of the camera object detection and the LIDAR risk map generation (see FIG. 15). After the process of step S24, S25, or S41, the process of this flowchart ends.

[0135] Thus, in this embodiment, as in the first embodiment, the autonomous driving ECU 3 determines whether to rearrange the execution order based on whether the estimated processing time of the camera object detection E task exceeds the maximum allowable processing time when the execution order is not rearranged and is within the maximum allowable processing time when the execution order is rearranged (S23). The autonomous driving ECU 3 switches the execution order of the camera risk map generation R / E task and the LIDAR risk map generation R / E task as shown in Figure 16 (S24) only when the estimated processing time exceeds the maximum allowable processing time when the execution order is not switched and is within the maximum allowable processing time when the execution order is switched (YES in S23). However, if the expected processing time exceeds the maximum allowable processing time when the execution order is changed (NO in S23), the camera risk map is not generated. Then, only the LIDAR risk map is generated, and the trajectory generation process is executed using only the risk map (S41). Only when the estimated processing time is equal to or less than the maximum allowable processing time when the execution order is not changed (YES in S22), the execution order of each task is set as shown in FIG. 15 (no change in task scheduling) (S25).

[0136] <Task startup in the third electronic control unit (autonomous driving ECU)> FIG. 27 is a diagram showing, in source code, a method for starting a task in the third electronic control unit (autonomous driving ECU 3) according to the third embodiment. When the autonomous driving ECU 3 receives the processing time exceeded task information Ie, it receives the received event notification, acquires the expected excess time included in the processing time exceeded task information Ie, and if the value exceeds "M1+M2+M3+M4-10" [ms] and is equal to or less than "B3+d+M1+M2+M3+M4-10" [ms], it sets the value of the variable sch_mode representing the scheduling mode to 1. Here, if the value of the expected excess time exceeds "B3+d+M1+M2+M3+M4-10" [ms], it sets the value of the variable sch_mode representing the scheduling mode to 2.

[0137] Thereafter, when the autonomous driving ECU 3 receives camera object detection data 10 from the camera ECU 1, it receives a reception event notification of the data, and if the value of the variable sch_mode is 0 (default value), it performs camera risk map generation, LIDAR risk map generation, risk map superimposition, and trajectory generation in that order according to Fig. 15. On the other hand, if the value of the variable sch_mode is 1, the autonomous driving ECU 3 has already performed LIDAR risk map generation when it receives the camera object detection data 10, so it performs the remaining processes of camera risk map generation, risk map superimposition, and trajectory generation in that order. Furthermore, if the value of the variable sch_mode is 2, the autonomous driving ECU 3 does nothing (does not perform camera risk map generation).

[0138] Furthermore, when the autonomous driving ECU 3 receives the LIDAR object detection data 12 from the LIDAR ECU 2, it receives a reception event notification of the data, and does nothing if the value of the variable sch_mode is 0 (default value). Furthermore, when the value of the variable sch_mode is 1, the autonomous driving ECU 3 executes LIDAR risk map generation. Furthermore, when the value of the variable sch_mode is 2, the autonomous driving ECU 3 uses only the LIDAR object detection data 12 to perform LIDAR risk map generation, risk map superimposition, and trajectory generation.

[0139] As described above, in the electronic system of the third embodiment, if the limit time is exceeded even when a task (e.g., a LIDAR risk map generation task) assigned to the third task processing by the third task startup unit (task startup unit 83) is executed based on the task startup order change command Cs, the third task processing unit (autonomous driving ECU 3) executes the above-mentioned third task processing by starting a task (LIDAR risk map generation task) that uses only the processing result of the second task (LIDAR object detection data 12) by the third task startup unit (task startup unit 83) without waiting for the processing result of the first task (camera object detection data 10).

[0140] The electronic system according to the third embodiment described above switches the control method in the control cycle when the processing delay in the first electronic control unit (camera ECU 1) that executes the preceding process becomes large. This has the effect of enabling the third electronic control unit (autonomous driving ECU 3) to observe the control cycle while using the latest value (for example, LIDAR object detection data 12).

[0141] [Fourth embodiment] An electronic system and an electronic control device according to a fourth embodiment of the present invention will be described. The fourth embodiment differs from the third embodiment in that, when the processing delay in the electronic control device (first electronic control device) that executes the preceding process becomes large, the control method of another electronic control device (third electronic control device) that executes the subsequent process in the control cycle is changed, and another process is executed in the free time that is generated in the control cycle by the change. Note that in the fourth embodiment, the same reference numerals are used for the same configuration as in the third embodiment, and the description thereof is omitted.

[0142] <Recalculating the schedule> 28 is a flowchart for determining whether or not the processing order needs to be changed in the fourth embodiment of the present invention. In FIG. 28, the processing in step S51 is different from that in FIG. Fig. 29 is a diagram showing the timing at which processing is performed by each electronic control unit when the processing is changed in the fourth embodiment. The following will describe Figs. 28 and 29, focusing on the parts that are different from the third embodiment.

[0143] 28, if the expected processing time of the camera object detection E task exceeds "B1+B3+d+M1+M2+M3+M4-10" [ms] (NO in S23), the scheduling recalculation unit 82 changes the task scheduling so that the camera risk map is not generated, and only the LIDAR risk map is generated. In this change of task scheduling, the scheduling recalculation unit 82 determines that the autonomous driving ECU 3 will generate the risk map 19 and generate a trajectory using only the LIDAR risk map alone, and further execute log recording as an additional task α (as shown in FIG. 29) (S51).

[0144] Here, the log recording task is composed of an R task, an E task, and a W task, as shown in Fig. 10. Also, the reference time (budget), which is the average processing time of the log recording E task, is assumed to be the same as the budget B2 allocated to the skipped camera risk map generation E task. However, the reference time of the log recording E task may be equal to or less than the budget B2.

[0145] <Task startup in the third electronic control unit (autonomous driving ECU)> FIG. 30 is a diagram showing, in source code, a method for starting a task in a third electronic control unit (autonomous driving ECU 3) according to the fourth embodiment. In the autonomous driving ECU 3, the condition for switching the value of the variable sch_mode representing the scheduling mode is the same as in the third embodiment. When the autonomous driving ECU 3 receives the LIDAR object detection data 12 from the LIDAR ECU 2, it receives a reception event notification of the data, and does nothing if the value of the variable sch_mode is 0 (default value). Also, if the value of the variable sch_mode is 1, the autonomous driving ECU 3 executes LIDAR risk map generation. Also, if the value of the variable sch_mode is 2, the autonomous driving ECU 3 uses only the LIDAR object detection data 12 to perform LIDAR risk map generation, risk map superimposition, and trajectory generation, and further performs log recording as additional processing.

[0146] As described above, in the electronic system of the fourth embodiment, if the limit time is exceeded even when a task (e.g., a LIDAR risk map generation task) allocated to the third task processing by the third task startup unit (task startup unit 83) is executed based on the task startup order change command Cs, the scheduling recalculation unit (scheduling recalculation unit 82) generates the task startup order change command Cs to stop the startup of a task (camera risk map generation task) that uses the processing result of the first task (camera object detection data 10) among the tasks allocated to the third task processing, and to execute any task (e.g., log recording) whose execution is completed in a processing time within the sum of the reference time of the stopped task and the used slack time.

[0147] The electronic system according to the fourth embodiment described above switches the control method in the control cycle when the processing delay in the first electronic control unit (camera ECU 1) that executes the preceding process becomes large. This enables the third electronic control unit (autonomous driving ECU 3) to comply with the control cycle while using the latest value (e.g., LIDAR object detection data 12). In addition, it has the effect of enabling the CPU utilization efficiency to be improved by executing another process that falls within the reference time (budget) of the free time generated by the change in task scheduling.

[0148] [Fifth embodiment] An electronic system and an electronic control device according to a fifth embodiment of the present invention will be described. The fifth embodiment differs from the fourth embodiment in that, when the processing delay in the electronic control device (first electronic control device) that executes the preceding process becomes large, the control method in the electronic control device (third electronic control device) that executes the subsequent process in the control cycle is changed, and another process (corresponding to log recording in the fourth embodiment) to be executed in the free time created by the change is determined in advance and distributed from the cloud. Note that in the fifth embodiment, the same reference numerals are used for the same configuration as in the fourth embodiment, and the description thereof is omitted.

[0149] According to the above-mentioned fifth embodiment, when a process (function) is wirelessly distributed by OTA (Over-The-Air) from the cloud to the electronic control device of the vehicle 100, the process (function) is distributed as long as the process falls within a reference time (budget) that is available under the conditions for executing the distributed process. Therefore, there is an effect of ensuring that the distribution of the process does not affect all the calculation results of other processes (processes other than the distributed process) executed in the electronic control device that receives the distribution.

[0150] [Sixth embodiment] An electronic system and an electronic control device according to a sixth embodiment of the present invention will be described. The sixth embodiment differs from the first embodiment in that a part of the processing performed by the electronic control device (first electronic control device) is transferred to the cloud. In the sixth embodiment, the same components as those in the first embodiment are denoted by the same reference numerals and the description thereof is omitted.

[0151] <Configuration> FIG. 31 is a diagram showing an example of the overall configuration of an electronic system according to the sixth embodiment of the present invention. In the illustrated electronic system 110A, a wireless network 31 is used in parallel with the in-vehicle network 16. A communication method exemplified by WTSN (Wireless Time Sensitive Network) can be used for the wireless network 31. That is, the in-vehicle network 16 and the wireless network 31 are based on a communication method in which the times of all electronic control devices (LIDAR ECU 2, autonomous driving ECU 3), cloud server 32, and other computing devices (e.g., CPUs) connected to the in-vehicle network 16 and the wireless network 31 are synchronized, and data transmission between the computing devices is guaranteed within a certain period of time.

[0152] The electronic system 110A includes a transceiver 30 instead of the camera ECU1 (see FIG. 1) of the electronic system 110. The transceiver 30 is connected to a cloud server 32 (first electronic control device) via a wireless network 31. The transceiver 30 includes the configuration of the computer system (an example of a computer) shown in FIG. 2. However, the global memory 54 and the local memory 55 may be integrated into one memory or deleted.

[0153] In this embodiment, the second and third task processing units (the LIDAR ECU 2 and the autonomous driving ECU 3) are mounted on the vehicle 100, and the first task processing unit exists in a cloud server 32 outside the vehicle 100. The cloud server 32 can have a configuration similar to that of the computer system shown in Fig. 2. However, the input / output interface 56 may not be provided.

[0154] <Operation> The transmitting / receiving unit 30 receives camera image data 9 from the camera 4, and transmits the camera image data 9 through a wireless network 31 to a cloud server 32 (first electronic control device).

[0155] The cloud server 32 has a higher processing capacity than the camera ECU 1. The electronic system 110A causes the cloud server 32 to execute camera object detection data generation, which has a larger processing load than LIDAR object detection data generation. The cloud server 32 executes a camera object detection R / E / W task, and transmits the camera object detection data 10 to the transceiver 30 through the wireless network 31. Then, the transceiver 30 transmits the camera object detection data 10 to the autonomous driving ECU 3 (third electronic control device) using the in-vehicle network 16.

[0156] The electronic system according to the sixth embodiment described above has the effect of enabling the processing of the autonomous driving ECU 3 to be dynamically changed depending on the processing (data generation and communication) status on the cloud server 32 side, while ensuring that there is no impact on the operation of the electronic system between the cloud server 32 and the vehicle 100.

[0157] [Seventh embodiment] Next, an electronic system and an electronic control device according to a seventh embodiment of the present invention will be described. The seventh embodiment differs from the first embodiment in that the arithmetic units of the first electronic control unit (camera ECU1) and the second electronic control unit (LIDAR ECU2) are integrated into one electronic control unit. Note that in the seventh embodiment, the same components as those in the first embodiment are denoted by the same reference numerals and will not be described.

[0158] <Configuration> FIG. 32 is a diagram showing an example of the overall configuration of an electronic system according to the seventh embodiment of the present invention. The illustrated electronic system 110B includes a zone ECU 1B (first electronic control device) and an autonomous driving ECU 3. The zone ECU 1B and the autonomous driving ECU 3 are connected via an in-vehicle network 16. The zone ECU 1B is an electronic control device that controls functions present in any zone of the vehicle 100 when the vehicle 100 is divided into a plurality of zones (ranges). The zone ECU 1B processes both the camera object detection task and the LIDAR object detection task.

[0159] The zone ECU 1B has a first CPU core 111 and a second CPU core 112. Each of the CPU cores 111, 112 corresponds to the CPU 51 in FIG. 2. For example, the zone ECU 1B includes a ROM 52, a RAM 53, a global memory 54, and a local memory 55 that configure the computer system shown in FIG. 2 for each of the first CPU core 111 and the second CPU core 112. In the zone ECU 1B, the input / output interface 56 and the network interface 57 may be shared by the CPU cores 111, 112, or may be provided for each of the CPU cores 111, 112. The hardware configuration of the zone ECU 1B is an example, and is not limited to this example.

[0160] <Operation> The zone ECU 1B processes a camera object detection task in a first CPU core 111, and processes a LIDAR object detection task in a second CPU core 112. The first CPU core 111 receives camera image data 9 from the camera 4, executes the camera object detection R / E / W task, and transmits camera object detection data 10 to the autonomous driving ECU 3 using the in-vehicle network 16. In addition, the second CPU core 112 receives LIDAR point cloud data 11 from the LIDAR 5, executes the LIDAR object detection R / E / W task, and transmits LIDAR object detection data 12 to the autonomous driving ECU 3 using the in-vehicle network 16.

[0161] As mentioned above, 7In the electronic system of this embodiment, the first task processing (camera object detection task) and the second task processing (LIDAR object detection task) are executed in the same electronic control device (zone ECU1B), and the third task processing (e.g., each risk map generation task, risk map superposition task, etc.) is executed in an electronic control device (autonomous driving ECU3) different from the same electronic control device.

[0162] The electronic system 110B according to the seventh embodiment described above has the same effects as the electronic systems according to the first to fourth embodiments, while having the effect of reducing the number of electronic control devices, thereby reducing hardware costs.

[0163] In the seventh embodiment, the electronic system 110B including the zone ECU 1B has been described, but the technology of the electronic system according to the seventh embodiment may be applied to an electronic system including an integrated ECU. The integrated ECU is an electronic control device that controls a plurality of functions of the vehicle 100 in an integrated manner, regardless of the zone of the vehicle 100. The integrated ECU may include only one CPU core instead of multiple CPU cores.

[0164] As described above, the electronic control device (autonomous driving ECU3) according to the first to seventh embodiments is an electronic control device mounted on a vehicle and processes a plurality of tasks, and includes a calculation device (CPU 51) that executes task processing using results processed in an electronic control device (e.g., camera ECU1, LIDAR ECU2, zone ECU1B, etc.) different from the electronic control device or the cloud server 32. When a processing delay occurs in the different electronic control device or the cloud server, the calculation device receives information including the magnitude of the delay (processing time exceeded task information Ie) from the different electronic control device or the cloud server, and performs control to change the order of task processing in the electronic control device using the received information.

[0165] Furthermore, the present invention is not limited to the above-described embodiments, and various other applications and modifications are possible without departing from the gist of the present invention as described in the claims. For example, the above-described embodiments are detailed and specific descriptions of the configurations of the electronic system and electronic control device in order to clearly explain the present invention, and are not necessarily limited to those including all of the components described. In addition, it is possible to replace a 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 or to a part of the configuration of each embodiment.

[0166] In addition, the above-mentioned configurations, functions, processing units, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. 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. [Explanation of symbols]

[0167] 1...camera ECU, 1B...zone ECU, 2...LIDAR ECU, 3...autonomous driving ECU, 9...camera image data, 10...camera object detection data, 11...LIDAR point cloud data, 12...LIDAR object detection data, 16...vehicle network, 17...camera risk map, 18...LIDAR risk map, 19...risk map, 21...camera object detection task, 22...LIDAR object detection task, 23...camera risk map generation task, 24...LIDAR risk map generation task, 25...risk map overlay task, 26...trajectory generation task, 30...transmitter / receiver, 31...wireless network, 32...cloud server, 51...CPU, 54...global memory, 55...local memory, 71...scheduling unit, 72...task startup unit, 73...task processing time management unit, 74...data transmitter / receiver unit, 81...scheduling unit, 82... Scheduling recalculation unit, 83... Task initiation unit, 84... Data transmission / reception unit, 100... Vehicle, 110, 110A, 110B... Electronic system, B... Budget, M... Margin, Ie... Processing time exceeded task information, Cs... Task initiation order change command

Claims

1. An electronic system in which a plurality of task processing units that process one or more assigned tasks are connected via a network, each of the plurality of task processing units includes a task starting unit that starts and executes each of the tasks; a third task processing in a third task processing unit utilizes at least a processing result of a first task processing in a first task processing unit preceding the third task processing or a processing result of a second task processing in a second task processing unit, and periodically executes a series of processes from the preceding first task processing or the preceding second task processing to the third task processing at a predetermined time interval; at least the first task processing unit has a processing time management unit that, when a time required for processing the first task that has been started exceeds a predetermined time, generates processing time exceeded task information including information on an expected time for the first task processing to be completed, and transmits the processing time exceeded task information to the third task processing unit via the network; the third task processing unit has a schedule recalculation unit that recalculates a processing schedule of the third task processing unit based on the received processing time exceeded task information; the scheduling recalculation unit generates a task activation order change command in the third task processing unit by recalculation and transmits the command to a third task activation unit included in the third task processing unit; the third task starting unit changes a task start order of a plurality of tasks included in a third task executed in the third task processing based on the task start order change command; Each of the task processing units has a memory into which information necessary for executing the corresponding task is read and into which a processing result of the corresponding task is written; the predetermined time interval is a time limit that is fixed in advance from a timing at which information required for executing the first task or the second task is read from the first memory or the second memory to a timing at which a processing result of the third task is written to the third memory, The limit time is composed of a reference time, which is an average processing time of the task, and a slack time, the slack time is used in processing any one of the first task, the second task, and the third task when an execution delay occurs in the corresponding task; the third task includes a task that uses a processing result of the first task processing, and a task that does not use the processing result of the first task processing but uses only the processing result of the second task processing, The third task starting unit starts, in advance, a task that does not use a processing result of the first task processing but uses only a processing result of the second task processing when the first task processing exceeds the predetermined reference time, among the tasks assigned to the third task processing, based on the task activation order change command of the schedule recalculation unit. Electronic system.

2. when the first task processing is completed within the reference time that is predetermined for the first task processing, the third task starting unit first starts a task that uses a processing result of the first task processing, and then starts a task that uses a processing result of the second task processing; When the first task processing exceeds the reference time and the time expected to end the first task processing included in the processing time exceeded task information is equal to or less than the sum of the reference time, the used slack time, and a reference time predetermined for the second task processing, the third task starting unit first starts a task that uses only the processing result of the second task processing, and then starts a task that uses the processing result of the first task processing. The electronic system of claim 1 .

3. When the time limit is still exceeded even after the task allocated to the third task processing by the third task starting unit is executed based on the task start order change command, The third task processing unit executes reading of a previous processing result of the third task processing from the third memory without waiting for a processing result of the first task processing or a processing result of the second task processing. The electronic system of claim 1 .

4. When the time limit is still exceeded even after the task allocated to the third task processing by the third task starting unit is executed based on the task start order change command, The third task processing unit executes the third task processing by initiating a task that uses only the processing result of the second task processing by the third task initiation unit without waiting for the processing result of the first task processing. The electronic system of claim 1 .

5. When the time limit is still exceeded even after the task allocated to the third task processing by the third task starting unit is executed based on the task start order change command, The schedule recalculation unit generates the task activation order change instruction to cancel activation of a task that uses a processing result of the first task processing among the tasks allocated to the third task processing, and to execute an arbitrary task whose execution is completed within a processing time within a sum of a reference time of the canceled task and the used slack time. The electronic system of claim 1 .

6. The first, second and third task processing units are electronic control units mounted on a vehicle. The electronic system of claim 1 .

7. the second and third task processing units are electronic control units mounted on a vehicle, The first task processing unit exists in a cloud server outside the vehicle. The electronic system of claim 1 .

8. The estimated time for completing the first task processing is calculated based on a progress rate of the first task processing when the reference time for the first task processing has elapsed. The electronic system of claim 1 .

9. a processing result of the first task processing and a processing result of the second task processing are processing results of data obtained from a sensing device, The third task processing unit controls driving of a vehicle by using a processing result of the first task processing and / or a processing result of the second task processing. The electronic system of claim 1 .

10. the first task processing and the second task processing are executed in a same electronic control device; The third task processing is executed in an electronic control device different from the same electronic control device. The electronic system of claim 1 .

11. An electronic control device that is mounted on a vehicle and processes multiple tasks, A computing device that executes task processing using results processed in an electronic control device or a cloud server different from the electronic control device, The third task processing in the arithmetic device utilizes at least a processing result of a first task processing in the different electronic control device that precedes the third task processing or a processing result of a second task processing in the cloud server, and periodically executes a series of processes from the preceding first task processing or the second task processing to the third task processing at a predetermined time interval; The arithmetic device has a schedule recalculation unit that, when a processing delay occurs in the different electronic control device or the cloud server, receives information including a magnitude of the delay from the different electronic control device or the cloud server, and recalculates a processing schedule of the arithmetic device based on the received information including the magnitude of the delay; the scheduling recalculation unit generates a task activation order change command in the computing device by recalculation, and transmits the command to a task activation unit that activates and executes the tasks in the computing device; the task starting unit changes a task start order of a plurality of tasks included in a third task executed in the third task processing based on the task start order change command; The different electronic control devices, the cloud server, and the arithmetic device each have a memory to which information necessary for executing a corresponding task is read and a processing result of the corresponding task is written; the predetermined time interval is a time limit that is fixed in advance from a timing at which information required for executing the first task or the second task is read from the first memory or the second memory to a timing at which a processing result of the third task is written to the third memory, The limit time is composed of a reference time, which is an average processing time of the task, and a slack time, the slack time is used in processing any one of the first task, the second task, and the third task when an execution delay occurs in the corresponding task; the third task includes a task that uses a processing result of one of the first task and the second task, and a task that does not use a processing result of one of the first task and the second task, but uses only a processing result of the other task, The task activation unit, when one of the tasks allocated to the third task processing exceeds the predetermined reference time based on the task activation order change command of the schedule recalculation unit, activates in advance a task that does not use a processing result of the one task processing but uses only a processing result of the other task processing. Electronic control unit.

Images