JP6861591B2 - Vehicle control unit - Google Patents

Description

The present invention relates to time-driven scheduling of vehicle control devices and control systems.

As a background technique in this technical field, there is Japanese Patent Application Laid-Open No. 2003-131892 (Patent Document 1). The subject of this publication is "to provide a task execution control device that enables execution at a predetermined timing without being affected by exclusive control", and as a solution, "the semaphore management unit is a task C. When the shared resource is acquired, the estimated resource release time of task C is compared with the next scheduled start time of task A, and if the former is earlier than the latter, task C is allowed to occupy the resource. Also, while task C is occupying the resource. When interrupt processing by the third task B occurs, the priority management unit sets the priority of task C to the same priority as task A when the cumulative total of "interrupt processing time" of task B reaches the permissible limit. Control the scheduling unit so that it can be raised to. ".

Japanese Unexamined Patent Publication No. 2003-131892

The above-mentioned background technology describes a method for preventing the influence of exclusive control on a high-priority task when the task is operated by priority scheduling.

However, when it is not disclosed which shared resource each task accesses, it is difficult to prevent the influence of exclusive control and integrate each task. Time-driven scheduling is a technology that facilitates task integration. In time-driven scheduling, it is an issue to guarantee task start timing and CPU resources.

The present invention has been made in view of the above problems, and provides a means for facilitating the integration of tasks of a vehicle control device.

In order to solve the above problems, one embodiment of the present invention may use, for example, the technical idea described in the claims. Specifically, this can be solved by providing an access monitoring time for suspending the start of access to the shared data at the final part of the execution slot assigned to the task with the low safety requirement level.

According to the present invention, when the time-driven scheduling is realized in the vehicle control device, it is not necessary to consider the data access shared with other tasks, and the tasks of the control system can be easily integrated while facilitating the integration of the tasks. It is possible to not affect the operating time. This facilitates task integration in a highly reliable system that operates with time-driven scheduling.

This is a configuration example inside the vehicle control device. This is a configuration example of a vehicle control device. This is an example of task state transition. This is an example of time-driven control slots and task execution. This is an example of a schedule table. This is an example of the operation flow of the scheduling section. This is an example of access monitoring time for data access monitoring. This is an example of the access monitoring time for data access monitoring in a straddling task. This is an example of arranging access monitoring time. This is an example of the operation flow when accessing shared data. This is an example of an operation log. This is an example of task operation flow. This is an example of the operation flow of the system status management unit. This is an example of the operation flow of the task status management unit. This is an example of the operation flow of the shared data group. This is an example of the operation flow of the operation log management unit. This is a configuration example of a vehicle control device in a multi-core environment. This is an example of access monitoring time in a multi-core environment. This is an example of a system status table. This is a configuration example of a vehicle system. This is an operation example in the access monitoring state.

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

<Vehicle system configuration>
FIG. 20 is an outline of a vehicle system having a vehicle control device of this embodiment. 2001 is a vehicle system having a vehicle control device inside such as an automobile, 2002 is a vehicle control device for controlling a vehicle, 2003 is a wireless communication unit for acquiring information such as a map, and 2004 is a vehicle movement according to the control of the vehicle control device 2002. A drive device that controls, for example, an engine, a wheel, a brake, a steering device, etc., 2005 is a camera, a sensor, or the like that acquires information input from the outside world and outputs information for generating outside world recognition information. The recognition device, 2006 is an output device that displays necessary information such as the speed and warning of the vehicle, 2007 is an input device for inputting vehicle operation instructions such as pedals and handles, and 2008 is the vehicle system 2001 of the vehicle to the outside world. A notification device such as a lamp, an LED, or a speaker for notifying a state or the like is shown.

<Configuration of vehicle control device>
Various automobile autonomous driving technologies are being realized. Many autonomous driving technologies are realized by computer-controlled devices. FIG. 2 is a block diagram of the vehicle control device 2002. As application 214, sensor fusion 201 that processes external information from peripheral devices such as sensor devices, map fusion 202 that processes map information for automatic driving, and automatic braking are activated just before colliding with other vehicles. ADAS (Advanced Driving Assistant System) 203 that realizes functions such as stopping, following the vehicle running in front while keeping a certain distance, and controlling the steering so that it does not go out of the lane, auto parking that realizes automatic parking There are 204 and so on. In addition, the data used in the application is processed and managed in a unified manner by the shared data group 205. As a result, the data management function in each application can be omitted, and the high-speed response required for controlling the vehicle in automatic driving is realized. These applications are executed by the task execution control unit 206 by time-driven scheduling while maintaining real-time performance. The task execution control unit 206 manages the tasks 101 and 102 described later by the task state management unit 107 based on the timing specified by the scheduling unit 108 based on the state transition described later.

The embedded OS 207 is used as the operating system. Hardware 215 is from CPU 208, memory 209, timer 210 for timing real-time control, network adapter 211 for accessing the network, and peripheral devices 212 such as sensors and peripheral devices such as automatic braking devices. It is composed. Further, in order to record the operation of each task, there is an operation log management unit 213.

<Task>
A unit of parallel execution of programs managed by the OS, that is, programs in one task are executed sequentially, whereas programs of different tasks are executed in parallel. However, the fact that they are executed in parallel is a conceptual operation from the perspective of the application, and in terms of implementation, each task is executed in a time-driven manner under the control of the OS. At least one task is generated per application.

Some tasks have to guarantee the execution time according to the content of the process, and some tasks may have a slight delay in execution time. In ISO26262, from the viewpoint of functional safety, tasks are assigned from the lowest to the highest dangerous event in order from QM (Quality Management), ASIL-A (Automotive Safety Integrity Level-A), ASIL-B (Automotive Safety Integrity Level-B), ASIL. -C (Automotive Safety Integrity Level-C), ASIL-D (Automotive Safety Integrity Level-D). Broadly speaking, tasks that must guarantee execution time in terms of security are ASIL, and tasks that are not related to security and whose execution time may be slightly delayed are QM.

<Task state transition>
FIG. 3 is a state transition diagram of the task. The task states are classified as follows.
1. 1. RUNNING 301: The state in which the CPU is allocated and the task is running.
2. Executable state (READY) 302: A state in which the conditions for executing a task are met, but the task cannot be executed because the task with a higher priority than the task is in the executing state.
3. 3. WAITING 303: Execution suspended until some condition is met.
4. DORMANT 304: The task has not yet been started or has ended.

First, the newly generated task first shifts to the hibernation state 304, and then transitions to the executable state 302 by starting the task. In the time-driven scheduling, the task is dispatched at the start timing of the time (slot) assigned to the task, transitions to the execution state 301, and the task process is executed. When the execution of the task is completed or the time of the allocated slot is completed, the task state is changed to the executable state 302.

When the task makes a resource request and the resource cannot be acquired by exclusive control, the task state is changed to the standby state 303. After that, when the resource is released and the task can acquire the resource, the task state is changed from the standby state 304 to the executable state 302. When the task receives a forced termination command or the task itself performs termination processing, the task state is transitioned to the hibernation state 304.

<Time-driven scheduling>
Time-driven scheduling is task execution scheduling of an OS that executes tasks at a fixed time and for a fixed time according to a fixed execution order. FIG. 4 shows an example of task execution when controlled by time-driven scheduling. In FIG. 4, the horizontal axis represents the passage of time, and the slot IDs (here, SL1 to SL9) are assigned to the slots. Tasks can be processed (here, t_1, t_2, t_3) within the time of the allocated slot. When the last slot is reached, it returns to the first slot (SL1) and continues scheduling.

The scheduling table 501 shown in FIG. 5 is used for time-driven scheduling. The configuration of the scheduling table consists of a slot ID, a slot start time, a slot end time, a task ID, a time error determination flag, and an exclusive ID for the task to transition to the standby state by itself. The scheduling table 501 is created based on information such as the execution cycle of each task, the worst execution time, and the safety requirement level. The length of one cycle of the scheduling table 501 is created so as to satisfy the execution cycle of all tasks. When the end of the cycle is reached, it returns to slot 1 and continues scheduling.

FIG. 6 shows an operation flow of the scheduling unit 208 when performing time-driven scheduling. At the start time of each slot, the timer 210 starts the operation of the scheduling unit 208, and determines whether the task of the previous slot has been executed (S101). When the task in the previous slot has been executed (yes in S101), the timer 210 is set so that the scheduling unit 208 starts operating at the end time of the scheduling table 501 (S102), and the task assigned to the current slot is assigned. To the execution state (S103). If no task is assigned to a slot, the task will not run in that slot. By performing the task execution process at the time determined in this way, the execution time of each task is secured.

The operation flow of the task is shown in FIG. When the task processing (S301) completes execution, the execution completion flag is raised (S302), the exclusion assigned to the own task is acquired (S303), and the execution is completed by transitioning to the standby state 303. .. The scheduling unit 108 determines whether or not the operation is completed by referring to the execution completion flag of the task in the previous slot. Further, by releasing the exclusion assigned to the task, the task transitions to the executable state 302, and when the scheduling unit 108 transitions to the standby state 303, the task transitions to the execution state 301. The execution completion flag is lowered by the scheduling unit 108, or the task is lowered when the task is restarted in the next slot of the task.

<Time error judgment>
The processing when the operation of the task is not completed within the time of the allocated slot will be described. When the task in the previous slot has not been executed (no in S101), the time error determination flag is referred to, and in the case of "Yes", the task in the previous slot is transitioned to the standby state 303 (S105). The task that performs this process is called a straddle task. The straddling task is a task that takes a long time and the processing is not completed in one slot, and operates over a plurality of slots.

When the time error determination flag is “not” (yes in S104), the error flag in the previous slot is set (S106), and the task in the previous slot is transitioned to the hibernation state 304 (S107). Since it takes time for the forced termination, the task may be temporarily transitioned to the standby state 303 in S107, and may be transitioned to the hibernation state 304 in the vacant slot.

<Configuration of vehicle control device>
A configuration example of a control device that manages task execution will be described with reference to FIG. FIG. 1 is an example of one configuration inside the vehicle control device of FIG. There is a first task 101 having a low safety requirement level and a second task 102 having a high safety requirement level. The processing of the application having a low safety requirement level is the first task 101, and the processing of the application having a high safety requirement level is the second task.

The task execution control unit 206 includes a data access control unit 105 that controls an access request to the shared data group 205 from a task, a system state management unit 106 that manages the system status, a task status management unit 107 that manages the task status, and these. It is composed of a scheduling unit 108 that performs task scheduling in cooperation with each other.

<Problems with task data access>
The problem in accessing the shared data group 205 will be described with reference to FIG. Some tasks are classified as ASIL, which must guarantee the execution time, and some are classified as QM, which may be slightly delayed in execution time. If there is a shared data group 205 that performs common access among tasks when a plurality of tasks are executed, exclusive control (S601, S603) must be performed so that simultaneous access does not occur. However, while the QM task is executing and occupying and accessing the shared data group, the execution time is the execution time of the ASIL task for which the execution time must be guaranteed, and even if the execution of the ASIL task is started, the same shared data as the QM task. When accessing the group 205, the access to the shared data group 205 of the ASIL task is exclusively controlled, and the ASIL task is put into a standby state. Time-driven scheduling must avoid such delays in executing ASIL tasks.

<Task data access monitoring time>
The data access monitoring time of the task will be described with reference to FIGS. 7 and 13. If there is a first task with a low safety requirement level and a second task with a high safety requirement level, the first task operates between the allocated slot times T1a and T1d. For slots assigned to tasks with a low safety requirement level, an access monitoring time for data access monitoring is provided at the end of the slot (T1b to T1d). The access monitoring time should be longer than the expected data access time (T1b to T1c). At the start of the access monitoring time (T1b), the system status management unit 106 shifts the system status from the non-access monitoring status to the access monitoring status (S402), and at the end of the access monitoring time (T1d), the system status is changed to the access monitoring status. Transition to the access non-monitoring state from (S403).

<Access monitoring status>
Data access control of the task according to the access monitoring state will be described with reference to FIGS. 14 and 21. When the first task attempts to access the shared data group 205, if the system state is the access monitoring state, the data access control unit 105 prohibits the first task from accessing the shared data group 205, and the task state management The task state of the first task is changed to the hibernation state 304 by the unit 107 (S504). When the system state is the access monitoring state, the task state of the first task may not be changed to the hibernation state 304, but may be changed to the standby state 303 or an infinite loop may be executed to determine a time error. When the first task attempts to access the shared data group 205, if the system state is the access non-monitoring state, the first task accesses the shared data group 205.

<Data access control for straddling tasks>
The data access control of the straddling task will be described with reference to FIG. If there is a first task with a low safety requirement level and a second task with a high safety requirement level that operate across multiple slots, the first task operates from the allocated slot time T2a to T2d, and continues. Is performed between T2e and T2h.

Even in the slots of tasks with straddles, access monitoring time for data access monitoring is provided at the final part of the slots (T2b to T2d and T2f to T2h) in all the slots assigned to the tasks with low safety requirements.

When the first task attempts to access the shared data group 205, if the system status is the access monitoring state, the data access control unit 105 suspends the access to the shared data group 205 by the first task and manages the task status. The task state of the first task is changed to the standby state by unit 107 (S502). When the system state is the access monitoring state, the task state of the first task may not be changed to the waiting state 303, the infinite loop may be executed, and the time error determination may be made to make the transition to the waiting state 303. Access to the reserved shared data 104 is started in the slot (T2e to T2f) following the first task. When the first task attempts to access the shared data group 205, if the system state is the access non-monitoring state, the first task accesses the shared data group 205.

<Access monitoring time allocation based on allocated slots>
The allocation of access monitoring time does not depend on the start timing of tasks with high safety requirements, but is determined by the slot time of tasks with low safety requirements. This will be described with reference to FIG. If there is a third task with the same safety requirement level as the first task, the first task operates from T3a to T3d and from T3j to T3l. The third task operates from T3f to T3h. The access monitoring time is arranged in the final slot (T3b to T3d, T3f to T3h, and T3j to T3l) assigned to the first task and the third task, respectively. By arranging the access monitoring time based on the slot time of a task with a low safety requirement level, it is possible to prevent the influence of task switching during exclusion even when there is no task information for accessing shared data. ..

<Operation during data access>
The operation flow when the task attempts to access data will be described with reference to FIG. When the data access control unit 105 receives the data access request from the task, the system state management unit 106 confirms the system status (S201), and if the system status is the access non-monitoring state (no of S201), the shared data group. The access flag indicating the access status to 205 is changed to during access (S202), and the access to the shared data group 205 is executed (S203). After the access to the shared data group 205 is completed, the access flag is changed to non-access (S204). When the system state is the access monitoring state (yes of S201), the content of the time error determination flag of the current slot is determined in the schedule table 507 (S205). When the time error determination flag is "not" (no in S205), the task status management unit 107 shifts the task status to the standby status 303 (S206), and the task status shifts to the execution status 301 in the subsequent slots. Data is accessed after the transition (S202, S203, S204). When the time error determination flag is "Yes" (yes in S205), the error flag in the margin of the current slot is changed to ON (S207), and the task in the current execution state 301 is forcibly terminated to be in the hibernation state 304. (S208). Since it takes time to forcibly terminate the task, the task may be temporarily transitioned to the standby state 303 in S208, and may be transitioned to the hibernation state 304 in an empty slot.

<Operation log>
The method of creating the operation log will be described with reference to FIGS. 11 and 16. The start time, end time, task ID, and state at the end of the slot in each slot are acquired (S701, S702) and recorded (S703). In particular, by recording the state at the end, it depends on whether the task is operating normally, a straddling task with a long operation time, forced termination due to an abnormality, or data access within the access monitoring time. It is possible to confirm from the operation log whether it is the end or the interruption due to data access within the access monitoring time.

According to the above-described embodiment, in time-driven scheduling, regardless of the presence or absence of access information of the shared data group used for exclusive control, the exclusive acquisition of a task with a low safety requirement level prevents the influence on the operation of other tasks. It becomes possible. In addition, by recording the operation log for these processes, it is possible to discover the task that tried to access the data at the timing that affects other tasks.

A second embodiment according to the present invention will be described. In this embodiment, an example is shown when there is a task that accesses data beyond the access monitoring time. In this embodiment, system control is performed using an access flag indicating that the first task 101 or the second task 102 is accessing the shared data group 205. When the data access of the task is started, the data access control unit 105 changes the access flag to "accessing", and when the data access is completed, the access flag is changed to "non-accessing". If the access flag is "accessing" at the end of the access monitoring time, the vehicle control device 2001 is restarted to reset the total exclusion. As a result, when data is accessed beyond the access monitoring time, the influence of exclusion on other tasks is minimized, and early recovery is possible. If the task state is the execution state and the access flag is "non-accessing" at the start of the access monitoring time, it may be determined that an abnormality has occurred and the task state management unit 107 may shift the task to the standby state. Further, the object to be restarted is not limited to the vehicle control device 2001, and may be restarted in the entire mounted other system.

According to the embodiment described above, by managing the status of data access, it is possible to prevent the influence of data access exceeding the access monitoring time on the operation of other tasks.

A third embodiment according to the present invention will be described. In this embodiment, an example in which the second task having a high safety requirement level is not allowed to affect other tasks will be described. In this embodiment, not only the access monitoring time for data access monitoring is provided at the final portion of the slot assigned to the first task 101 having a low safety requirement level, but also the access monitoring time is assigned to the second task 102 having a high safety requirement level. Even if the slot next to the slot has the same safety requirement level, an access monitoring time for data access monitoring is provided at the final portion of the slot assigned to the second task 102. As a result, when the second task 102 having a high safety requirement level malfunctions, it is possible to prevent the influence on the other second task 102 having a high safety requirement level.

According to the embodiment described above, by changing the allocation target of the access monitoring time, it is possible to prevent the influence of the task having a high safety requirement level on other tasks.

A fourth embodiment according to the present invention will be described. In this embodiment, an embodiment when generating the scheduling table 501 of the present patent from the development tool will be described. In this embodiment, the scheduling table 501 is automatically generated from the design information such as the cycle of each task, the worst execution time, and the safety requirement level. At the time of automatic generation, it is decided whether to provide an access monitoring time for data access monitoring at the final part of each slot based on the information of the safety requirement level. When the access monitoring time is provided, the slot time including the access monitoring time is arranged. This makes it possible to design an application without considering the necessity of access monitoring time.

A fifth embodiment of the present invention will be described with reference to FIGS. 17, 18 and 19. In a control device in which a plurality of cores 1701, 1702, and 1703 from the first core to the Nth core access data to a shared data group, each core has a first task 101 having a low safety requirement level and a second task 101 having a high safety requirement level. Has task 102. In each core controlled by time-driven scheduling, there is an access monitoring time at the end of each slot (T4b to T4d and T4e to T4h). In the slot for the first task 101, the access monitoring time is arranged so that "access time (T4b to T4c) <access monitoring time (T4b to T4d)".

In the slot for the second task 102, the access monitoring time is arranged so that “access time × 2 (T4e to T4g) <access monitoring time (T4e to T4h)”. In this embodiment, the system state table 1901 that manages the state of each core is used. The system status table holds information on whether each core is in access monitoring status or access non-monitoring status, and "access monitoring counter for all cores". The access monitoring counter for all cores increases or decreases between 0 and the number of cores. At the start of the access monitoring time (T4b) in the slot for the first task 101, the system state management unit 105 shifts the system state of the core to the access monitoring state.

At the end of the access monitoring time (T4c) in the slot for the first task 101, the system state management unit 105 shifts the system state of the core to the access non-monitoring state. In the core in the access monitoring state, new data access to the shared data group 205 in the first task 101 is prohibited. At the start of the access monitoring time (T4e) in the slot for the second task 102, the system state management unit 105 shifts the system state of the core to the access monitoring state, and the system state management unit 105 monitors access for all cores. The counter is incremented by 1. At the end of the access monitoring time (T4h) in the slot for the second task 102, the system state management unit 105 shifts the system state of the core to the access non-monitoring state, and decrements the access monitoring counter for all cores by one. .. When the access monitoring counter for all cores is 1 or more, new data access to the shared data group 205 by the first task in all cores is prohibited. When there is a data access request to the shared data group 205 by the plurality of cores 1701, 1702, 1703, the data access by the second task 102 of the core whose system state is the access monitoring state is prioritized. As a result, even when the first task 101 of the other core accesses before the access monitoring time, it is possible to secure the time for executing the data access by the second task 102 after the data access by the first task 101 is completed. This makes it possible to prevent the data access of the first task 101 from affecting the second core 102 in the manycore environment. Further, the access monitoring time in the slot for the second task 102 may be arranged so as to be “access time × number of cores <access monitoring time”. This makes it possible to prevent the influence of the data access of the second task 102 of the other core.

According to the embodiment described above, when there are a plurality of cores, it is possible to prevent the influence of the task with the low safety requirement level on the task with the high safety requirement level by providing the access monitoring time for each core. It will be possible.

101 1st task 102 2nd task 105 Data access control unit 106 System status management unit 107 Task status management unit 108 Scheduling unit 201 Sensor fusion 202 Map fusion 203 ADAS
204 Auto parking 205 Shared data group 206 Task execution control unit 207 Embedded OS
208 CPU
209 Memory 210 Timer 211 Network adapter 212 Peripheral device 213 Operation log management unit 214 Application 215 Hardware 301 Execution state 302 Executable state 303 Standby state 304 Hibernate state 501 Scheduling table 1101 Operation log 1701 First core 1702 Second core 1703 Third Core 2001 Vehicle system 2002 Vehicle control device 2003 Wireless communication unit 2004 Drive device 2005 Recognition device 2006 Output device 2007 Input device

Claims (9)

Tasks that can be continuously executed in execution slots that are separated into multiple parts and have a specified start time and end time are started based on the specified execution order, processed and executed in the assigned execution slots, and under exclusive control. In the vehicle control device that performs control via the shared data group in
The execution slot includes an access monitoring time beginning after the defined start time,
A system state management unit that transitions the system state to the access monitoring state at the start of the access monitoring time and transitions to the state before the transition at the end of the access monitoring time.
In the access monitoring state, a data access control unit that prohibits new data access to the shared data group by the task, and a data access control unit.
A vehicle control device characterized by having. The final part of the execution slot, the longer than the data access time which is assumed to shared data groups under the exclusive control of the task, and having the access monitoring time, the vehicle according to claim 1 Control device. The vehicle control device according to claim 1, further comprising a task state management unit that transitions the task to the end state when the system state is the access monitoring state at the start of data access accompanied by exclusion by the task. The vehicle according to claim 1, wherein when the task is activated, the access monitoring time is provided in the final portion of each separated execution slot in the execution slots other than the final execution slot of the task. Control device. The execution slot is characterized by having a task state management unit that confirms the system state at the start of data access accompanied by exclusion by the task and transitions the task to the standby state when it is in the access monitoring state. , The vehicle control device according to claim 1. A flag management unit that has an access flag indicating that the task is accessing shared data, transitions the access flag during access at the start of data access, and transitions the access flag during non-access at the end of data access. The first aspect of the present invention is characterized by having a mechanism for restarting the system and releasing all exclusions when the access flag is being accessed at the end of the defined access monitoring time. Vehicle control device. The first task according to claim 1, further comprising a first task having a low safety requirement level and a second task having a high safety requirement level, and having the access monitoring time at the final portion of the execution slot of the first task. Vehicle control device. When the task assigned to the execution slot next to the execution slot of the second task is the same as the safety requirement level of the second task, the access monitoring time is provided in the final part of the execution slot of the second task. The vehicle control device according to claim 7, wherein the vehicle control device is characterized by the above. In a multi-core environment composed of a plurality of cores, the data access control unit prohibits new access to a shared data group by the task in one or all the cores within the access monitoring time. The vehicle control device according to claim 1.

Images