JP2018049405A - Vehicle controller and vehicle control system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a vehicle controller capable of facilitating integration of tasks in a time division control scheduling.SOLUTION: The vehicle controller for controlling activation of tasks based on the time confirms a running task in operation at start time of each task and determines whether the running task is continuable. When determining that the running task is continuable, the vehicle controller controls to temporarily stop the running task, and when determining that the running task is not continuable, to terminate the running task.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a vehicle control device and a vehicle control system.

  As background art in this technical field, there is JP-A-2006-013782 (Patent Document 1). This gazette has an object of “providing an in-vehicle electronic control device that appropriately manages execution of a scheduled task.” As a means for solving the problem, “the in-vehicle electronic control device is a scheduled task activated at a predetermined time interval. After executing the essential process A among the processes A, B, and C (S400), the remaining time X from the current time until the scheduled task is started next time is calculated (S404), and the priority is higher than the scheduled task. Is calculated according to the length of the remaining time X (S408, S410, S412) The in-vehicle electronic control unit calculates the remaining time X and the execution time. The difference (X−Z) from Z is calculated as the execution time of the scheduled task, and it is determined based on the execution time whether or not the process B out of the processes B and C is executed (S414). The device is S414. Results for managing the execution of processing B on the basis of (S416, S418). Has been described as ".

  As another background art, there is JP-A-2005-071141 (Patent Document 2). In this publication, there is a need to “provide a stack management method that does not require an increase in the total capacity of the stack even if the number of tasks increases as long as the task configuration does not change significantly, and provides high stack utilization efficiency”. As a solution, “a task stack that can be shared by all suspended tasks is provided, the storage area of the task stack is composed of a plurality of blocks having a predetermined block length, and the data is divided into the blocks. When the data in the shared stack is saved to the task stack in order to interrupt execution of a task, the data is stored in the unused block according to the amount of data in the shared stack. The block identification data and the task identification data are stored using the block identification data and the task identification data. Returning the serial data in the shared stack. It has been described as ".

JP 2006-013782 A JP 2005-071141 A

  The above background art describes a method of operating a system efficiently based on the conditions of a task when the task is operated by priority control and time-driven scheduling.

  However, a method for facilitating task integration at the time of system design in a scheduling method that fixes tasks to be operated within a predetermined time, such as time-driven scheduling used to make control systems highly reliable, is described. It is not done.

  In particular, when integrating a task with a short control cycle (eg, 1 ms cycle) and a task with a long execution time (eg, 5 ms), it is necessary to divide the task with a long execution time, which is difficult to design.

  The present invention has been made in view of the above problems, and provides a vehicle control device and a vehicle control system that facilitate task integration.

  In order to solve the above-described problems, an embodiment of the present invention may use, for example, the technical idea described in the claims. For example, in a vehicle control apparatus that performs control to start a task according to time, it checks the running task that is in the running state at the start time of each task, and determines whether the running task can be continuously executed. When it is determined that the running task can be continuously executed, the running task is paused. When it is determined that the running task cannot be continuously executed, the running task is terminated. I do.

  According to the present invention, task integration can be facilitated when time-driven scheduling is realized.

It is the determination flow at the time of the scheduling execution concerning the 1st example of the present invention. It is an example of a system. It is an example of a vehicle control system configuration. It is a structural example of a controller. It is an example of the software module structure of a controller. It is an example of a task state transition. It is an example of a slot of time division control and task execution. It is an example of a schedule table. It is an example of an action log. It is an example of the data copy of the task management part concerning 2nd Example of this invention. It is an example of the design information concerning the 3rd example of the present invention. It is the determination flow at the time of the scheduling execution concerning the 4th Example of this invention. It is an example of task design information and operation information. It is an example of the execution result of a task.

  Hereinafter, examples (examples) of the preferred embodiments of the present invention will be described. The present embodiment mainly describes a vehicle control system and a vehicle control device in a vehicle system, which is suitable for implementation in a vehicle system, but does not hinder application to other than the vehicle system.

<Configuration of vehicle control system>
FIG. 2 is an outline of a vehicle system having a vehicle control system and a vehicle control apparatus according to this embodiment. 1 is a vehicle system having a vehicle control system inside, such as an automobile, and 2 is an in-vehicle network (CAN: Controller Area Network, CANFD: CAN with Flexible Data-rate, Ethernet (registered trademark), etc.) and a controller (ECU: Electronic Control). A vehicle control system 3 configured by a unit, etc., and wireless communication with the outside of the vehicle system 1 (for example, mobile phone communication, wireless LAN, WAN, C2X (Car to X: vehicle-to-vehicle or vehicle-to-infrastructure communication)), etc. Communication using the above protocol or communication using GPS (Global Positioning System), and information on the external world (infrastructure, other vehicles, maps) or information on the vehicle must be acquired and transmitted. A communication device 4 having a diagnostic terminal (OBD), an Ethernet terminal, an external recording medium (for example, a USB memory, an SD card, etc.) terminal, etc., and performing communication with the vehicle control system 2, For example, a vehicle control system 5 constituted by a network using a protocol different from or the same as that of 2 is a mechanical and electrical device (for example, an engine, a transmission, a wheel, a brake, etc.) that controls the vehicle motion according to the control of the vehicle control system 2. 6, a driving device such as an actuator for driving the steering device, etc., acquires information input from the outside world, and outputs information for generating outside world recognition information, which will be described later, a camera, radar, LIDAR, super An external sensor such as a sound wave sensor, and the state of the vehicle system 1 (movement state, position information, acceleration, A recognition device configured by a dynamic sensor that recognizes wheel speed, etc., is connected to the network system by wire or wireless, receives data transmitted from the network system, and receives message information (for example, video, sound), etc. An output device 8 for displaying or outputting necessary information, such as a liquid crystal display, a warning light, a speaker, etc., is used for generating an input signal for a user to input an operation intention or instruction to the vehicle control system 2. For example, an input device 9 such as a steering wheel, a pedal, a button, a lever, a touch panel, etc., 9 indicates a notification device such as a lamp, LED, speaker, etc., for the vehicle system 1 to notify the outside of the vehicle state and the like. ing.

  The vehicle control system 2 is connected to the other vehicle control system 4, the wireless communication unit 3, the drive device 5, the recognition device 6, the output device 7, the input device 8, the notification device 9, and the like, and transmits and receives information.

  FIG. 3 shows an example of the H / W (Hardware) configuration of the vehicle control system 2. Reference numeral 301 denotes a network link for connecting network devices on the in-vehicle network, for example, a network link such as a CAN bus, and 302 denotes a network link 301 and a network link other than the driving device 5 and the recognition device 6 and 301 (including dedicated lines). ECU (Electronic Control Unit) 303 that controls the drive device 5 and the recognition device 6, acquires information, and transmits / receives data to / from the network, 303 connects a plurality of network links 301, and each network link and data 1 shows a gateway (hereinafter referred to as GW) that performs transmission / reception.

  In addition to the bus type example in which a plurality of ECUs are connected to the two buses shown in FIG. 3, examples of the network topology include a star type in which a plurality of ECUs are directly connected to the GW, and an ECU in a series of links. There are a link type connected in a ring shape, a mixed type in which each type is mixed and configured by a plurality of networks, and the like. The GW 303 and the ECU 302 include an ECU having a GW function or a GW having an ECU function.

Based on the data received from the network, the ECU 302 outputs control signals to the drive device 5, acquires information from the recognition device 6, outputs control signals and information to the network, changes the internal state, etc. I do.
FIG. 4 is an example of an internal configuration of the ECU 302 or the GW 303 which is a network device according to the present invention. Reference numeral 401 denotes a storage element such as a cache and a register, and a processor such as a CPU, GPU, or FPGA that executes control. Reference numeral 402 denotes a network link 301 or a driving device 5 and / or a recognition device 6 connected by a network or a dedicated line. I / O (Input / Output) for transmitting and receiving data, 403 using a clock (not shown), a timer for managing time and time, and 404 for reading only memory (ROM) for storing programs and nonvolatile data ), 405 indicates a RAM (Random Access Memory) for storing programs and volatile data, and 406 indicates an internal bus used for communication within the ECU.

  The processor includes a processor having one or more arithmetic devices inside called a multi-core. As shown in the figure, there are both timers that are accessed via a network and those that the processor itself has.

  Next, the configuration of a software module that operates on the processor 401 is shown in FIG. A task management unit 501 controls the entire software module, particularly a task management unit that manages tasks to be described later. A communication management unit 502 manages the operation and state of the communication I / F 402 and instructs the communication I / F 402 via the internal bus 406. 503, a time management unit that manages the timer 403 to acquire and control information relating to time, 504, an operation log management unit that manages an operation log, which will be described later, and 505, calculation and control for operating the vehicle control system 2. 506 represents a data table holding information necessary for vehicle control, 507 represents a schedule table described later, and 508 represents an operation log described later.

  5 shows the concept of operation on the processor 401, and information necessary at the time of operation is appropriately acquired from the ROM 404 and RAM 405, or written to the ROM 404 and RAM 405 as appropriate.

<Task>
The task 505 is one of the operation units of a software module also called a thread, an application, a process, or a software component (SWC), and the communication management unit 502, the time management unit 503, the operation log management unit 504, and the like described above are also tasks. In some cases.

  The task is executed by the processor 401 when it becomes an execution state due to a state transition described later, and performs control (execution of a program) assigned to each task. For example, data is obtained from the network and the driving device or the recognition device via the communication management unit 503 or the I / O 402, necessary processing is performed on the data of the data table 506, and the network is obtained via the communication management unit 503 or the I / O 402. Alternatively, the vehicle control system is operated by performing processing such as outputting data to the I / O.

  When data is shared between tasks, the writing task writes in a specific area of the data table 506, and the reading task reads data from the specific area to share the data. When accessing this data, exclusive control described later is performed.

<Exclusive control>
In order to perform data sharing and operation arbitration between tasks, each task performs exclusive control on shared resources (for example, the processor 401, the memory area (RAM 405, the data table 506, etc.), and the I / O 402. Uses semaphores, mutexes, flags, etc. For example, when one task owns (subtracts) a semaphore, other tasks can no longer have the same semaphore, etc. Implement exclusive control.

<Task state transition>
FIG. 6 shows an example of task state transition. The task management unit 501 manages the task 505 based on such state transition.

  First, a task newly generated by the task management unit 501 is first shifted to a dormant state, and then the task management unit 501 starts the task and makes a transition to an executable state.

  In the executable state, for example, in time-driven scheduling, when the time (slot) in which the task (for example, task T1) can be executed is reached, the task management unit 501 determines that the task T1 has acquired the execution right, Transition to a state. For the task in the execution state, the processor 401 executes processing of the task.

  Thereafter, when the time during which the task can be executed ends, or when the processing of the task ends and the task issues an instruction to abandon the execution right, the task management unit 501 enters the task T1 into an executable state. And transition. At that time, if there is a task to be executed next, the task management unit 501 transitions the task to be executed next from the executable state to the execution state.

  On the other hand, when a task in the execution state requests a resource, for example, and the resource cannot be acquired by exclusive control, the task management unit 501 transitions the task to a standby state. A task that has transitioned to a standby state is in a standby state until resources can be acquired. After that, when another task releases the resource, for example, when the task in the standby state becomes in a state where the resource can be acquired, the task management unit 501 requests the resource and enters the task in the standby state. Is transitioned to an executable state.

  When a task that is in an executable state, an execution state, or a standby state receives a forcible termination instruction from, for example, the task management unit 501 or another task, the task that has received the instruction enters a dormant state, and the task again It will be in a dormant state until it receives a start command from the management unit 501. A task in a dormant state that has received a start command from the task management unit 501 transitions to an executable state.

  As described above, the task performs these state transitions by receiving an instruction from the task management unit 501 or by abandoning the execution right or requesting resources.

  Here, in an environment such as a multi-core, there may be a plurality of tasks in the execution state, but the state transition is similarly performed.

  In the standby state, task management information (stack, heap, data table area managed by the task, owned resources), etc. are inherited to the next executable state, and in the rest state, part of the management information. And everything is initialized. For this reason, the time from the standby state to the executable state and the execution state is short, but it takes time from the hibernation state to the execution state, and the management information before the hibernation state cannot be taken over. May become discontinuous.

  On the other hand, by initializing the management information in the hibernation state, it is possible to return from an unauthorized state in which the same processing is repeated infinitely to a non-invalid state such as an initial state.

<Time division control>
FIG. 7 shows an example in which task execution is controlled in a time-sharing manner. In FIG. 7A, the horizontal axis indicates time, each time is divided into slots (windows), and IDs (here, S1 to S11) are assigned to the respective slots. Here, by allowing only the assigned task to operate in each slot, it is possible to execute the task in a time division manner. The operation of selecting a task to be executed at a certain time is called scheduling.

  The configuration of the schedule table 507 used for scheduling is shown in FIG. The schedule table 507 includes a slot ID, a slot start time, a slot end time, a task ID assigned to the slot, and a time error determination flag used for straddle determination described later. In this way, the time of each slot and the tasks that can operate within that time are allocated in advance.

  An example of task operation is shown in FIG. Here, the task management unit 501 is set so that the operation is started by an alarm using, for example, the timer 403 at time 0.0, and scheduling is performed at that timing. The task management unit 501 that has started operation due to the alarm confirms that the current time is 0.0, and since the slot ID is S1, confirms the state of the task with the task ID T1 and sets it to the execution state. To process. Thereafter, the task management unit 501 sets an alarm at the next slot start time (in this example, time 0.2) and ends the operation. Thereafter, the task T1 performs processing. When the processing is completed, the task T1 shifts to a standby state by a resource request or the like. Task execution processing is performed by scheduling at the time determined in this way.

  In the schedule table 507, both the start time and the end time are described here, but only the start time may be used. In that case, the end time of each slot is expressed by the start time of the next slot. By doing so, the data amount of the schedule table 507 can be reduced.

  If no task is assigned to the slot, the dedicated task ID describes that no task is assigned to the current slot. (Task ID: NA in FIG. 8)

<Stride determination>
Next, the stride determination process will be described with reference to FIG. The straddle is not only forcibly terminated when task processing does not end at the end of the slot, but also preliminarily assumes a task that is allowed not to end processing within the slot, and the task is executed up to the next executable slot. It is to pause the process.

  When the task management unit 501 starts operation by an alarm at the slot start time described in the time division control, the task management unit 501 determines whether or not the task of the previous slot is in an execution state (S101). The determination is made based on the ID of the task currently being executed, whether or not the task in the previous slot is requesting a resource for transitioning to the standby state, and the like. If the task in the previous slot is not in the execution state (no in S101), the execution time of the next task is acquired from the schedule table 507 and an alarm is set (S102), and the task in the current slot is set in the schedule table 507. To obtain an execution state from the above (S103).

  If the task in the previous slot is in the execution state (Yes in S101), the content of the time error determination flag in the previous slot is determined. When the time error determination flag is “Yes” (Yes in S104), the task in the previous slot is forcibly terminated. At that time, an operation log including error information is created by a method described later (S105), and the currently executing task is forcibly terminated and put into a dormant state (S106). Is determined from the schedule table and an alarm is set (S102), and the task of the current slot is determined from the schedule table to enter an execution state (S103).

  On the other hand, if the time error determination flag is “NO” (no in S104), the task in the previous slot is set in a standby state (S107), and thereafter, the same processing as normal is executed (S102, S103).

  By executing straddle processing by time-sharing control in this way, depending on the state of the time error determination flag set for the task, the task is put in a standby state or forcibly terminated, and the task straddles other windows This process can be executed.

  In S103, when executing the task of the current slot, processing is performed according to the current state of the task to be executed. For example, in a standby state (a standby state based on a resource acquisition request by itself or a standby instruction by the task management unit), the operation is resumed by a resource release or a transition instruction to an executable state according to each standby state. If it is in a dormant state, it transitions to an executable state upon activation.

  As a process in the case where the task in the previous slot is in the execution state, the task management unit 501 may place the task in the standby state once instead of forcibly ending and put the next task in the execution state or the like, good. By doing so, the next task can be quickly executed.

<Child task management>
In the crossing process, it is necessary to similarly manage child tasks generated by the respective tasks. For example, when the task T3 generates a child task (for example, the task T3A) in the slot IDS3, it is necessary to similarly put the child task in a standby state in the crossing process. Therefore, the task management unit 501 performs the process for setting the standby state on both the task T3 and the task T3A. Similarly, restart from the standby state is performed for both task T3 and task T3A. As a result, even when the task generates a child task, processing based on the straddling determination is possible.

  Regarding the processing for the child task, when the task that generated the child task notifies the task management unit 501 of the ID of the child task or receives an instruction for each task to transition to a standby state, It can be realized by a method of shifting a child task to a standby state under management.

<Operation log>
An operation log creation method will be described with reference to FIG. Here, an example is shown in which the task start time, end time, task ID, and state at the end of each slot are recorded. The operation log management unit 508 receives these states from the task management unit 501 at a task state transition timing or the like, and records them as an operation log 508. In particular, by recording the error log and the operation at the time of straddling in the straddle determination process for the state at the end, whether the compulsory termination occurred because of an abnormality or whether the straddling process as expected did not occur It can be confirmed from the operation log.

  The operation log is output to the outside via the communication management unit 502, the network link 301, the communication device 3, and the like, so that the state of the vehicle control system can be monitored from the outside.

  A second embodiment according to the present invention will be described. The difference from the first embodiment is that the task management unit 501 copies data that is shared and accessed between tasks.

  FIG. 10 shows the task 505 and the area inside the data table 507 accessed by the task. Here, the area A is an area that is accessed by both the task 1 and the task 2 and requires exclusive control by a semaphore or the like. Task 2 is a task for straddling. In such a case, when task 2 has acquired a semaphore to access area A, task 1 accesses area A if task 2 pauses in the process of crossing determination There is a possibility of deadlock and the like.

  Therefore, the task management unit 501 copies the data in the shared area to another area (for example, area B) at the start of execution of a task that straddles task 2 or the like. By doing so, the task 2 does not need to access the resource for exclusive control, and it becomes possible to prevent deadlock.

  Similarly, data access from task 1 is performed by writing back data in area B to area A at the end of task 2, or before execution of the next task after task 2 or before execution of task 1 is started. It is possible to return a value correctly for.

  Here, with regard to the operation of task 2, the semaphore acquisition (acquisition of access authority to exclusive control resource) instruction is accessed via the task management unit 501, and the accessed data is copied to an area where exclusive control is not performed. The task management unit 501 hides the semaphore acquisition instruction so as not to execute it, so that the software can be ported without replacing the source code of task 2 depending on whether the copying is performed or not. It becomes possible.

  In this example, the data area accessed by the task 2 is changed from the area A to the area B. The physical memory map is changed for the access method such as virtual memory, and the data access address held by the task 2 is changed. Or by rewriting the pointer, rewriting the variable name (label) of the source code or the object code, and the like.

  Here, regarding the time for the task management unit 501 to copy the data, if the start time of the slot of task 2 is t2 and the time required for copying is tc, the time t2-tc is when the previous task is completed. It is desirable to start on. By doing so, even when data is copied, it can be executed without delaying the task execution start time. Similarly, when the write-back process (required time tcr) is performed before the start time of the slot of task 2, it is preferable to start the process at time t2-tc-tcr in consideration of that time.

  A third embodiment according to the present invention will be described. In this embodiment, the schedule table 507 is automatically created from design information and information measured during operation.

  An example of the design information 1101 is shown in FIG. Here, for the design information of each task, information such as task ID, control cycle, (worst case) execution time, presence / absence of crossing permission is given. A schedule table 507 is created based on these pieces of information.

  As a result, for example, for the task with the task ID T3, the crossing permission is OK, so for example, a schedule table as shown in FIG. 8 is created, and a time error is generated for the slot (S3 and S5) where the crossing occurs. A flag indicating that the determination is “not performed” is given. In this way, the schedule table 507 can be created from the design information 1101.

  In this example, the task whose task ID is T2 in the design information 1101 is set to allow crossing permission, but since it can be arranged without causing crossing, a flag indicating that the time error determination is “not done” is not given.

  Also, in this example, when the crossing permission of the task with the task ID T3 is NG, when the schedule table 507 is automatically created, an error message indicating that the scheduling table cannot be created due to the crossing is communication management. The data is output to the network link 301 and the communication device 3 via the unit 502.

  Here, for tasks for which crossover permission NG, for example, safety-related functions such as safety-related functions, it is possible for a safety-related function to generate a crossover even during automatic creation by giving an instruction of crossover permission NG for a task for which processing is not interrupted due to crossing. Therefore, it is possible to design without causing a processing delay.

  The schedule table can be created not only from the design information 1101 but also from the network link 301. As a result, when updating the function, not only the calculation inside the processing apparatus but also the schedule information can be set from the external network.

  The automatic creation of the schedule table 507 is calculated not only at the time of designing the vehicle control system or at the first startup, but also every time the vehicle control system 2 is started (ignition is turned on, etc.) Can be executed including recalculation and reacquisition of the control period and execution time of the design information 1101. As a result, the schedule table 507 is recalculated in accordance with the change in the system state, and the schedule table can be constructed in accordance with the system state.

  With reference to FIG. 12, description will be given of an example in which a determination flow at the time of scheduling execution according to the fourth embodiment of the present invention is performed by automatic determination based on a scheduled execution time that is design information without using a time error determination flag. The difference from the first embodiment is that the determination based on the time error flag in S104 in FIG. 1 is replaced with the determination based on the accumulated execution time and the assumed execution time in S1201.

  Here, an operation example will be described in which each task is operating at the start and end times shown in FIG. 14 based on the control cycle and the scheduled execution time for each task described in FIG.

  In this case, for example, at time 0.4, since the task T2 exceeds the scheduled execution time (0.2) indicated by the design information 1101, the task (T2) of the previous slot is determined by the determination of S1201. Force termination. On the other hand, at time 1.0, the cumulative execution time (0.6 ms) of task T3 does not exceed the scheduled execution time (2.2 ms) of the design information shown in FIG. Process.

  Thus, even when the time error determination flag based on the schedule table is not used, it is possible to perform the straddle determination by comparing the scheduled execution time of the design information for each task with the accumulated execution time.

  In this case, the design information 1301 shown in FIG. 13 is held in the ECU similarly to the schedule table 507 or the data table 506.

  According to the embodiment described above, in the time-driven scheduling, when there is a task that needs to straddle slots of other tasks, the information that permits the straddle process is added and the straddle process is permitted. If the task is running at the end of the slot, the task is paused. In other words, for a specific task, even if the task window time has passed, the task execution is suspended without being forcibly terminated. As a result, when implementing time-driven scheduling, it is not necessary to redesign tasks that divide long-running tasks, making task integration easier and not affecting the operating time of control system tasks. Is possible. This facilitates task integration in a highly reliable system that operates with time-driven scheduling.

  Even when the task performs a process of generating a child task, it is possible to perform the straddle process in the same manner. Further, by recording an operation log for these processes, it is possible to confirm the operation from the outside even when a task goes over.

  In another embodiment, when there is data shared between tasks, it is possible to prevent the resource of the task from being held during the crossing process by moving the data to another area in advance. In addition, by executing the timing in advance in consideration of the copy time, it is possible to shift to the execution state without delaying the task execution start.

  In another embodiment, a table including a straddling process can be automatically created from design information and measured operation information for a schedule table.

  In yet another embodiment, even if there is no flag for executing the straddling process, it is possible to determine whether to perform the straddling process from the scheduled execution time and the accumulated execution time of the task, and to realize the straddling process. Become.

DESCRIPTION OF SYMBOLS 1 ... Vehicle system, 2 ... Vehicle control system, 3 ... Communication apparatus, 4 ... Vehicle control system, 5 ... Drive apparatus, 6 ... Recognition apparatus, 7 ... Output apparatus, 8 ... Input apparatus, 9 ... Notification apparatus, 301 ... Network Link 302 ... ECU 303 ... GW 401 401 Processor 402 ... I / O 403 Timer Timer 404 ROM 405 RAM 406 Internal bus 501 Task management unit 502 Communication management unit 503 ... Time management unit, 504 ... Operation log management unit, 505 ... Task, 506 ... Data table, 507 ... Schedule table, 508 ... Operation log, 1101 ... Design information, 1301 ... Design information

Claims (10)

In a vehicle control device that performs control to start a task according to time,
Check the running task that is in the running state at the start time of each task, determine whether the running task can be continuously executed,
When it is determined that the running task can be continuously executed, the running task is temporarily stopped. When it is determined that the running task cannot be continuously executed, the running task is terminated. The vehicle control apparatus characterized by performing. The vehicle control device according to claim 1,
The vehicle control apparatus according to claim 1, wherein the determination when the continuous execution is possible is made based on an accumulated execution time from a start time of the task being executed. The vehicle control device according to claim 1,
The vehicle control device characterized by performing post-determination processing on the child task of the task being executed as well as the task being executed. The vehicle control device according to claim 1,
A vehicle control apparatus for recording task execution time and operation at the end of each slot. The vehicle control device according to claim 1,
When a task that can be continuously executed is activated, data that is accessed by both the task and another task is copied to an area that is accessed only by the task. The vehicle control device according to claim 5, wherein
Copying to the area is executed before the task execution start time, the vehicle control device. The vehicle control device according to claim 1,
A vehicle control device, comprising: creating a scheduling table used for determining whether or not the ongoing task can be continuously executed from design information. The vehicle control device according to claim 7, wherein
A vehicle control device that sets whether or not continuous execution is possible in the scheduling table based on the determination of safety. The vehicle control device according to claim 7, wherein
In the creation of the scheduling table, a vehicle control apparatus is characterized in that a scheduling period is created by measuring or acquiring a control cycle or execution time of a task of design information from a network. Including the vehicle control device according to claim 1 or 7,
In the creation of the scheduling table, a vehicle control system is characterized in that each vehicle control device creates a scheduling table by measuring or obtaining a control period or execution time of a task of design information from a network.

Images