CN110959152B - access control device - Google Patents

Abstract

The invention can prevent the task with low priority from affecting the actions of other tasks caused by the exclusive acquisition of the shared data. The access control device of the present invention comprises: an application unit that includes a 1 st task having a relatively low priority and a 2 nd task having a relatively high priority, which are classified according to the priority of execution; an execution unit that executes a 1 st task and a 2 nd task; a system state management unit which allocates a time slot of a predetermined length for each task to be executed, and sets a 1 st predetermined time at the end of the time slot as an access monitoring time in the time slot allocated to the 1 st task; a shared data unit which is accessed by the 1 st task and the 2 nd task; and a data access control unit that prohibits access to the shared data unit by the 1 st task within the access monitoring time.

Description

Access control device

Technical Field

The present invention relates to an access control device.

Background

The control device performs various tasks with different priorities. It is required that the operation of the task with the higher priority is not hindered by the task with the lower priority. Patent document 1 discloses a task execution control device for performing task scheduling under a condition that a priority of a 1 st task is higher than a priority of a 2 nd task in a system capable of predicting a 1 st task at a scheduled execution start time and a 2 nd task shared resource having a known time length for which a shared resource is used, the task execution control device comprising: a time calculation unit that obtains a scheduled time at which the next execution of the 1 st task starts and a scheduled time at which the 2 nd task is expected to release the shared resource before the 2 nd task occupies the shared resource; and a resource management unit that compares the next execution start scheduled time with the release scheduled time, and if the next execution start scheduled time is earlier than the release scheduled time, does not allow the 2 nd task to occupy the shared resource, and on the other hand, if the next execution start scheduled time is not earlier than the release scheduled time, allows the 2 nd task to occupy the shared resource.

Prior art literature

Patent literature

Patent document 1: japanese patent laid-open publication No. 2003-131892

Disclosure of Invention

Problems to be solved by the invention

The invention described in patent document 1 cannot prevent the influence of a task with a low priority on the operation of another task due to the exclusive acquisition of shared data.

Technical means for solving the problems

An access control device according to claim 1 of the present invention includes: an application unit that includes a 1 st task having a relatively low priority and a 2 nd task having a relatively high priority, which are classified according to the priority of execution; an execution unit that executes the 1 st task and the 2 nd task; a system state management unit that allocates a time slot of a predetermined length for each task to be executed, and sets a 1 st predetermined time at the end of the time slot as an access monitoring time in the time slot allocated to the 1 st task; a shared data unit which is accessed by the 1 st task and the 2 nd task; and a data access control unit that prohibits access to the shared data unit by the 1 st task within the access monitoring time.

ADVANTAGEOUS EFFECTS OF INVENTION

According to the present invention, it is possible to prevent the task with a low priority from affecting the operations of other tasks due to the exclusive acquisition of shared data.

Drawings

Fig. 1 is a schematic diagram of a vehicle system 2001.

Fig. 2 is an overall block diagram of the vehicle control device 2002.

Fig. 3 is a state transition diagram of a task.

Fig. 4 is a diagram showing an example of execution of a task.

Fig. 5 is a diagram showing an example of the schedule 501.

Fig. 6 is a diagram showing a detailed configuration of the task execution control unit 206.

Fig. 7 is a flowchart showing the operation of the scheduling unit 108.

Fig. 8 is a flowchart showing the operation of the task.

Fig. 9 is a diagram illustrating a data access monitoring time.

Fig. 10 is a flowchart showing the operation of the system state management unit 111.

Fig. 11 is a flowchart showing the operation of the task state management unit 107.

Fig. 12 is a schematic diagram showing the access of the 1 st task 101 to the shared data section 205.

Fig. 13 is a diagram illustrating access monitoring times across tasks.

Fig. 14 is a diagram showing an example of setting the access monitoring time.

Fig. 15 is a flowchart showing the operation of the data access control unit 105.

Fig. 16 is a flowchart showing a general access procedure to shared data.

Fig. 17 is a flowchart showing the operation of the data access control unit 105 in embodiment 2.

Fig. 18 is a flowchart showing the operation of the system state management unit 111 in embodiment 3.

Fig. 19 is a diagram showing the configuration of CPU 208 in embodiment 5.

Fig. 20 is a diagram showing an example of the system state table 1901.

Fig. 21 is a diagram illustrating rewriting of the system state table 1901.

Fig. 22 is a diagram showing a situation in which the access request of the 2 nd task 102 to the shared data section 205 is repeated.

Fig. 23 is a flowchart showing the operation of the system state management unit 111 in embodiment 5.

Fig. 24 is a diagram showing an outline of the operation of vehicle control device 2002 according to embodiment 6.

Fig. 25 is a block diagram of a vehicle control device 2002 according to embodiment 7.

Fig. 26 is a diagram illustrating the operation of the timer flag monitor 2303.

Fig. 27 is a flowchart showing the operation of the operation log management unit 213 in embodiment 8.

Fig. 28 is a diagram showing an example of the action log 1101.

Detailed Description

Embodiment 1

Next, embodiment 1 of a vehicle control device as an access control device will be described with reference to fig. 1 to 16.

< construction of vehicle System >

Fig. 1 is a schematic view of a vehicle system 2001 in which a vehicle control device 2002 is mounted. The vehicle system 2001 includes a vehicle control device 2002, a wireless communication unit 2003, a driving device 2004, a recognition device 2005, an output device 2006, an input device 2007, and a notification device 2008. The vehicle control device 2002 is an electronic control device that controls the vehicle, that is, an ECU (Electronic Control Unit electronic control unit). The wireless communication unit 2003 acquires information such as a map. The driving device 2004 drives, for example, an engine, wheels, a brake, a steering device, and the like, in accordance with an operation command of the vehicle control device 2002, to control the movement of the vehicle. The recognition device 2005 is, for example, a camera, a sensor, or the like, which acquires information input from the outside and outputs information for generating the outside recognition information. The output device 2006 displays information such as the speed of the vehicle and a warning. The input device 2007 is, for example, a pedal, a steering wheel, or the like, for the driver to input an instruction of the vehicle operation. The notification device 2008 is, for example, a lamp, an LED, a speaker, or the like, for the vehicle system 2001 to notify the state of the vehicle to the outside.

Structure of automatic driving ECU

Fig. 2 is an overall block diagram of the vehicle control device 2002. The detailed block diagram will be shown again later. The vehicle control device 2002 is composed of software 216 and hardware 215. The software 216 is realized by the CPU 208 described later expanding and executing a program stored in a ROM, not shown, in the memory 209.

The hardware 215 includes a CPU 208 as a central processing unit, a memory 209 as a nonvolatile memory unit, a timer 210 for managing the timing of real-time control, a network adapter 211 for accessing a network, and peripheral devices 212 such as sensors and an automatic brake device. CPU 208 is a so-called single core CPU having only 1 core. However, the CPU 208 includes a plurality of cores, but a case where only 1 core is used for execution of the application unit 214 described later is also included in the scope of the present embodiment. The software 216 includes an application unit 214, a shared data unit 205, a task execution control unit 206, an action log management unit 213, and an OS 207 which is an operating system.

The application unit 214 includes a sensor fusion 201 for processing external information by a peripheral device such as a sensor device, a map fusion 202 for processing map information for automated driving, an ADAS (Advanced Driving Assistant System advanced driving support system) 203 for realizing rear-end collision avoidance, following driving, and lane keeping, and automated parking 204 for realizing automated parking. However, the configuration of the application unit 214 described here is an example, and may include at least 1 application. Each application is composed of a plurality of tasks, and each task is set with priority.

The shared data section 205 manages data used by each application stored in the application section 214. The shared data unit 205 secures a storage area in the memory 209, for example, and manages reading and writing of data in the storage area. The task execution control unit 206 controls execution of each task constituting the application. The detailed configuration and operation of the task execution control unit 206 will be described later. The action log management unit 213 records actions of the respective tasks. The task execution control unit 206 manages the tasks 101 and 102 described later by the task state management unit 107 based on the time designated by the scheduling unit 108 according to the state transition described later.

< task >

The OS 207 divides the application into tasks as execution units and executes the tasks in order to execute the application included in the application unit 214. The OS 207 may perform multiple tasks substantially simultaneously, but strictly speaking, time-sharing the computing resources of the CPU 208. In other words, the OS 207 executes tasks one by one with the lapse of time. Each task is executed within a predetermined length of time, i.e., a "slot".

The importance of execution of tasks is not uniform, and depending on the processing content, there are tasks with high priority that must ensure execution time and tasks with low priority that can be slightly delayed in execution time. In ISO26262, tasks are classified in order of dangerous phenomenon from low to high as QM (Quality Management quality management), ASIL (Automotive Safety Integrity Level car safety integrity level) -A, ASIL-B, ASIL-C, ASIL-D from the viewpoint of functional safety. That is, when roughly classified, the task for which the execution time must be ensured in the security assurance is ASIL, and the task for which the execution time can be slightly delayed regardless of the security assurance is QM. In the present embodiment, the necessity of ensuring the execution time may be called a priority level, and for example, a task classified as QM may be called a "low priority task" and a task classified as ASIL-D may be called a "high priority task".

< State transition of task >)

Fig. 3 is a state transition diagram of a task. The states of the tasks are classified into the following 4 states. State 1 is the execution state (RUNNING) 301. The execution state 301 refers to a state in which the CPU 208 is assigned to execute a task. State 2 is an executable state (READY) 302. The executable state 302 is a state in which the condition for executing a task is complete but cannot be executed because a task having a higher priority than the task is an execution state. State 3 is a standby state (wait) 303. The standby state 303 is a state in which execution is interrupted until some conditions are complete. State 4 is inactive (dorant) 304. Rest state refers to a state in which a task has not been started or has ended.

State transitions of tasks are described. The newly generated task starts in a rest state 304 and transitions to an executable state 302 when the task is started. When the time allocated to the task is reached, the task is dispatched to transition to the execution state 301, and the task processing is executed. The task state transitions to the executable state 302 when execution of the task is complete or the time of the assigned slot ends. When a task requests a resource and cannot acquire the resource by exclusive control, the state transitions to the standby state 303. Thereafter, when the resource is released and the task is able to acquire the resource, the task state transitions from the standby state 303 to the executable state 302. When the task receives the forced end command or the task itself performs the end processing, the task state transitions to the rest state 304.

Time-driven scheduling

Fig. 4 is a diagram showing an example of execution of a task controlled in time-driven scheduling. The time-driven schedule is a task in which the OS 207 executes a time degree determined by a time determined by the determined execution order. In fig. 4, the horizontal axis represents time passage, and the illustrations SL1 to SL9 are IDs (hereinafter referred to as "slot IDs") assigned to respective slots. As shown in the enlarged view of the lower part of fig. 4, immediately after each time slot starts, the task execution control unit 206 performs processing and thereafter executes a task. The last slot ID in fig. 4 is SL9, but it is also possible to continue SL10 and SL11. Each task is performed within the time of the assigned slot. T_1 to t_3 shown in fig. 4 are IDs (hereinafter referred to as "task IDs") for identifying tasks to be executed. When the last time slot of the series is reached, the return to the first time slot, SL1, continues scheduling.

Fig. 5 is a diagram showing an example of a schedule table 501 for time-driven scheduling. The schedule table 501 is composed of a plurality of records, each of which has fields of a slot ID, a start time, an end time, a task ID, and a time error determination flag. The slot ID of the record is stored in the field of the slot ID. The fields of the start time and the end time store the start time and the end time of the recorded time slot. This time point sets the start time point of SL1 to zero. The task ID field stores the task ID of the task to be executed in the record. The time error determination flag field stores a flag to be referred to by the scheduling unit 108 described later. The time error determination is described in detail later.

The schedule 501 is prepared in advance based on information such as the execution cycle of each task, the expected maximum execution time, and the security requirement level. The length of 1 loop of the schedule 501 is made to satisfy the length of the execution cycle of all tasks. When the end of the cycle is reached, the control returns to SL1 to continue scheduling. For example, in the example shown in fig. 5, the last slot ID is SL12, and the end time is "5.1ms", so the length of 1 cycle is 5.1ms. Then, SL1 is performed after SL 12.

Structure of vehicle control device

Fig. 6 is a diagram showing a detailed configuration of the task execution control unit 206. Fig. 6 illustrates that the application unit 214 includes a plurality of 1 st tasks 101 having a low security requirement level and a plurality of 2 nd tasks 102 having a high security requirement level. The 1 st task 101 and the 2 nd task 102 are tasks constituting any one of the applications included in the application unit 214. Hereinafter, however, the 1 st task 101 and the 2 nd task 102 will also be collectively referred to simply as "tasks".

The task execution control unit 206 includes a data access control unit 105, a system state determination unit 106, a task state management unit 107, and a scheduling unit 108. The data access control unit 105 controls an access request from a task to the shared data unit 205 using an access flag described later. The system state determination unit 106 determines the state of the system by referring to a system state management unit 111 described later that manages the system state. The task state management unit 107 manages the state of the task. The scheduling unit 108 performs scheduling management of tasks in coordination with the data access control unit 105, the system state determination unit 106, and the task state management unit 107.

The hardware 215 includes an access time monitor 109, a slot time monitor 110, and a system state manager 111. The access time monitoring unit 109 is implemented by a timer 210, and monitors the arrival of the access monitoring time set. The access monitoring time is described later. The slot time monitoring unit 110 is implemented by a timer 210, and monitors the arrival of each slot time set. The system state management unit 111 is implemented by a hardware circuit, not shown, and manages the system state in coordination with the access time monitoring unit 109 and the slot time monitoring unit 110.

The access time monitor 109, the slot time monitor 110, and the system state manager 111 are described here as being constituted by hardware, but the inclusion of software is not excluded. However, when the software is included, the resource is independent of the software 216, and the operation timings of the access time monitor 109, the slot time monitor 110, and the system state manager 111 are prevented from affecting the operation timings of the software 216.

< action of scheduling section >)

Fig. 7 is a flowchart showing the operation of the scheduling unit 108. When the start time of each slot is reached, the scheduler 108 starts operation according to an operation command from the timer 210. The main execution body of each step described below is the CPU 208.

The scheduling unit 108 first determines whether or not the task in the previous slot has been executed (S101). When it is judged that the task of the preceding slot has been executed (S101: yes), the scheduling unit 108 sets the timer 210 so as to start operation at the end time of the current slot in the schedule table 501 (S102). Then, the scheduling unit 108 transitions the task allocated to the current slot to the execution state (S103). If a task is not assigned to a slot, the task is not activated in the slot. By performing the task execution processing at the time determined in this way, the execution time of each task is ensured. The processing of the task of transitioning to the execution state is described later with reference to fig. 8.

If it is determined that the task in the preceding slot has not been executed (S101: NO), the scheduling unit 108 refers to the time error determination flag in the slot in the schedule table 501, and if it is "not performed" (S104: NO), the task in the preceding slot is brought into the standby state 303 (S105). The task to be transitioned to the standby state 303, in other words, the task determined to be "not in progress" by the time error in the schedule table 501 is referred to as a "crossing task". The spanning task is a task requiring a long time for which no processing is completed within 1 slot, and acts across a plurality of slots. When the time error determination flag is "on" (S104: yes), an error flag of the preceding slot is set (S106), and the task of the preceding slot is changed to the inactive state 304 (S107). Since the forced termination requires time, the task may be temporarily shifted to the standby state 303 and shifted to the rest state 304 in the idle slot in S107. When execution of S105 or S107 is completed, the process proceeds to S102 described above.

< action of task >)

Fig. 8 is a flowchart showing the operation of each task in the execution state. First, the task execution includes a task process of accessing the shared data section 205 (S301), and when the execution is completed, an execution completion flag is set (S302), thereby indicating that the execution is completed to the scheduling section 108. The scheduling unit 108 refers to the execution completion flag of the task executed in the time slot before the eye, and if the execution completion flag is set, it changes the task to the executable state 302. When execution is started next, the task cancels the execution completion flag (S303). But the execution completion flag may be canceled by the scheduling unit 108.

< data Access monitoring time of task >)

Fig. 9 is a diagram illustrating data access monitoring time of a task. The situation in which tasks 1 and 102 are executed is shown in fig. 9. Further, the 1 st task 101 operates between the allocated slot times T1a to T1 d. Within the time slot allocated to the 1 st task 101, access monitoring times for monitoring data accesses are set for the last time slots, i.e., T1b to T1 d. The length of the access monitor time is longer than the data access time, that is, the time required for the task to access the shared data portion 205, for example, T1b to T1 c. The length of the access monitoring time is fixed irrespective of the task. Further, since the security requirement level of the 2 nd task 102 is high, the access monitoring time is not set for the slot allocated to the 2 nd task 102.

In the present embodiment, a time that is an access monitoring time is referred to as an "access monitoring state", and a time that is not an access monitoring time is referred to as a "non-access monitoring state". The state in which the access monitoring state or the non-access monitoring state is adopted is referred to as a "system state". That is, as shown in the lower part of fig. 9, the system state is the non-access monitoring state at ordinary times, and is the access monitoring state from the end of the time slot to which the 1 st task 101 belongs to the predetermined time before the end of the time slot to which the 1 st task 101 belongs.

Operation of System State management section

Fig. 10 is a flowchart showing the operation of the system state management unit 111. Next, the operation of the system state management unit 111 will be described with reference to fig. 9. The main execution body of each step described below is the CPU 208.

At the start of each time slot, for example, at time T1a in fig. 9, the system state management unit 111 determines whether or not the task executed in the time slot is the 1 st task 101 (S400A), and if it is determined that the task executed is the 1 st task 101, the process proceeds to S401. In the case where it is determined that the executed task is not the 1 st task 101, that is, the 2 nd task 102 is to be executed, the end time of the slot is set to the slot time monitoring unit 110 (S400B), and the process proceeds to S404 based on the count of the timer 210. In S401, the system state management unit 111 sets the start time of the access monitoring time to the slot time monitoring unit 110, and sets the end time of the slot to the slot time monitoring unit 110 to start counting.

The system state management unit 111 monitors the register state of the access time monitoring unit 109, determines whether the set access monitoring time has been reached based on the register state (S402), and if it is determined that the access monitoring time has not been reached, it remains in S402. When it is determined that the access monitoring time has arrived, the system state management unit 111 transitions the system state from the non-access monitoring state to the access monitoring state (S403).

The system state management unit 111 monitors the register state of the slot time monitoring unit 110, determines whether or not the set time slot end time has been reached based on the register state (S404), and if it is determined that the time slot end time has not been reached, it remains in S404. When determining that the end time of the slot has been reached, the system state management unit 111 transitions the system state from the access monitoring state to the non-access monitoring state (S405). In next S406, the system state management unit 111 determines whether or not the system is terminated, for example, whether or not the ignition key switch of the vehicle on which the vehicle control device 2002 is mounted has been turned off. If it is determined that the system is not to be ended, the system state management unit 111 returns to S400A, and if it is determined that the system is to be ended, the operation shown in fig. 10 is ended.

Operation of task State management section

Fig. 11 is a flowchart showing the operation of the task state management unit 107. The task state management unit 107 is also designated as which state to transition to when called. That is, the task state management unit 107 is called together with the designation of any one of the standby state, the rest state, and the executable state.

When the transition to the standby state is designated (yes in S501), the task state management unit 107 transitions the task to the standby state (S502). When it is determined that the specified state is not the standby state (S501: NO), it is determined whether or not a transition to the rest state is specified (S503). When it is determined that the transition to the rest state is designated, the task state management unit 107 transitions the task to the rest state (S504), and when it is determined that the transition to the rest state is not designated, transitions the task to the executable state (S505).

< Access to shared data portion >)

Fig. 12 is a schematic diagram showing the access of the 1 st task 101 to the shared data section 205. When the 1 st task 101 attempts to access the shared data section 205, the data access control section 105 acquires the system state managed by the system state management section 111 via the system state determination section 106. When the system state is determined to be the non-access monitoring state, the data access control unit 105 permits the 1 st task 101 to access the shared data unit 205. When the system state is determined to be the access monitoring state, the data access control unit 105 denies the access of the 1 st task 101 to the shared data unit 205, and further, the task state management unit 107 is used to transition the 1 st task 101 to the rest state 304. However, in the case where the system state is the access monitor state, the data access control unit 105 may perform transition to the standby state 303 or endless loop without changing the task state of the 1 st task 101 to the rest state 304, and perform time error determination.

Data Access control across tasks

Fig. 13 is a diagram illustrating access monitoring times across tasks. The example shown in fig. 13 shows a situation in which the 1 st task 101 and the 2 nd task 102 are executed. Further, the 1 st task 101 operates across a plurality of time slots, specifically, operates in time slots from time T2a to time T2d and time slots from time T2e to time T2 h. That is, the 1 st task 101 in this example is a spanning task. In the time slot allocated with the crossing task, the access monitoring time for data access monitoring is set for the last time slot in all time slots allocated with the task with low security requirement level. In the example shown in fig. 13, time T2b to T2d and time T2f to T2h are access monitoring times. Further, as shown in the lower layer of fig. 13, the system state is set to the access monitoring state according to the access monitoring time.

When the task 1 101 attempts to access the shared data section 205, the data access control section 105 performs the following processing when the system state is the access monitoring state. That is, the data access control section 105 prohibits the access of the 1 st task 101 to the shared data section 205, and the task state management section 107 transitions the task state of the 1 st task 101 to the standby state. However, when the system state is the access monitor state, the task state of the 1 st task 101 may be changed to the standby state 303 by performing an infinite loop instead of being changed to the standby state 303, and the time error determination may be used to change to the standby state 303. The access to the shared data portion 205 by the 1 st task 101 starts outside the access monitoring time of the subsequent time slot of the 1 st task 101, that is, within the time T2e to T2 f. When the 1 st task 101 attempts to access the shared data portion 205, if the system state is a non-access monitoring state, the 1 st task 101 accesses the shared data portion 205.

< Access monitoring time configuration based on allocated time slots >

Fig. 14 is a diagram showing an example of setting the access monitoring time. Next, a case will be described in which the access monitoring time is determined not by the starting time of the task with the high security requirement level but by the slot time of the task with the low security requirement level.

In the example shown in fig. 14, the 3 rd task is lower in security requirement level as in the 1 st task 101. Task 1 operates at times T3a to T3d and times T3j to T3 l. The 3 rd task operates from time T3f to time T3 h. The access monitoring time is arranged at the end of the time slots allocated to the 1 st task 101 and the 3 rd task, that is, at the time points T3b to T3d, at the time points T3f to T3h, and at the time points T3j to T3l, respectively. By disposing the access monitoring time in accordance with the slot time of the task having the low security requirement level in this way, even in the case where there is no information about the presence or absence of access to the shared data section 205 or details of access objects, the influence of task switching in the exclusive can be prevented.

Operation of data Access control section 105

Fig. 15 is a flowchart showing the operation of the data access control unit 105. The main execution body of each step described below is the CPU 208.

When receiving an access request to the shared data section 205 from a task, the data access control section 105 confirms the system state in the system state determination section 106 (S201). When the system state is determined to be the non-access monitoring state (S201: NO), the data access control unit 105 changes an access flag indicating an access status to the shared data unit 205 to "access" (S202), and executes access to the shared data unit 205 (S203). When the access of the task to the shared data section 205 is completed, the data access control section 105 transitions the access flag to "no access" (S204).

When the system state is the access monitoring state (yes in S201), the data access control unit 105 determines the content of the time error determination flag of the current slot in the schedule table 501 (S205). When the time error determination flag is "no" (S205: no), the data access control unit 105 causes the task state management unit 107 to transition the state of the task to the standby state 303 (S206). Then, after the task state transitions to the execution state 301 in the subsequent slot, the data access control section 105 performs data access (S202, S203, S204). When the time error determination flag is "ON" (yes in S205), the data access control unit 105 turns ON the error flag within the margin of the current slot (S207), and forcibly ends the task in the execution state 301 to set the task in the rest state 304 (S208). However, since a time is required for the forced termination, the task may be temporarily shifted to the standby state 303 and shifted to the rest state 304 in the idle slot in S208.

According to embodiment 1 described above, the following operational effects are obtained.

(1) The vehicle control device 2002 includes: an application unit 214 that includes a 1 st task 101 having a relatively low priority and a 2 nd task 102 having a relatively high priority, which are classified according to the priority of execution; a system state management unit 111 that allocates a time slot of a predetermined length for each task to be executed, and sets a 1 st predetermined time at the end of the time slot as an access monitoring time in the time slot allocated to the 1 st task 101; a shared data unit 205 which is accessed by the 1 st task 101 and the 2 nd task 102; and a data access control unit 105 that prohibits access to the shared data unit 205 by the 1 st task 101 during the access monitoring time.

The vehicle control device 2002 does not have information as to whether or not any task accesses the shared data section 205, and which data contained in the shared data section 205 is accessed. However, since the access monitoring time is set at the end of the slot to which the 1 st task 101 is allocated, it is possible to prevent a situation in which access to the shared data portion 205 by another task is blocked by access to the shared data portion 205 by the 1 st task 101 having a low priority. The problems of the related art that are supposed will be described with reference to fig. 16.

Fig. 16 is a flowchart showing a general access procedure to shared data. As a general access to shared data, a task accessing shared data performs exclusive acquisition, in other words, acquires access rights to shared data (S601). Then, the data processing is performed (S602), and finally the exclusive is released, in other words, the access right to the shared data is released (S603), and the series of processing ends. If the time slot of the task performing the processing shown in fig. 16 ends in the middle of the data processing, the processing shifts to other tasks without performing exclusive release. In this case, if the processing of the task is not resumed, the exclusive release is not performed, and the other task cannot perform the exclusive acquisition, and thus cannot access the shared data.

In the past, the vehicle control device 2002 sets a predetermined time at the end of the time slot allocated to the 1 st task 101 as the access monitoring time, and prohibits access to the shared data unit 205 during the access monitoring time, so that the above-described problem can be avoided. That is, since the vehicle control device 2002 does not have the case where the 1 st task 101 comes to the end of the slot while maintaining the access right, it is possible to prevent adverse effects on other tasks related to access to the shared data portion 205 from being caused by exclusive acquisition of the 1 st task 101. Further, this advantage can be obtained even when the vehicle control device 2002 does not have the presence or absence of access to the shared data portion 205 for each task as in the present embodiment. That is, the vehicle control device 2002 can prevent the exclusive acquisition of the 1 st task 101 having a low security requirement level from affecting the operation of other tasks, regardless of the presence or absence of the access information of the shared data section 205 used for the exclusive control.

(2) The access monitoring time is longer than the time required for the task 1 101 to access the shared data. Therefore, before the start of the access monitoring time, which is a time for which the 1 st task 101 has access to the shared data portion 205, the 1 st task 101 is permitted to access the shared data portion 205. Further, even when the 1 st task 101 starts access to the shared data section 205 immediately before the access monitoring time, the access monitoring time is longer than the time required for the 1 st task 101 to access the shared data, and therefore, the operation of other tasks can be prevented from being affected until the exclusive release is completed in the time slot.

(3) The data access control unit 105 transitions the 1 st task 101 that has attempted to access the shared data unit 205 during the access monitoring time to the end state. Therefore, the operation of the 1 st task 101, which cannot be accessed to the shared data section 205 as the next process, can be terminated, and the resources of the CPU 208 can be saved.

(4) When the 1 st task 101 executed across the plurality of slots attempts to access the shared data section 205 within the access monitoring time beyond the final slot, the data access control section 105 causes the 1 st task 101 to stand by until the start time of the next slot. Therefore, the 1 st task 101 executed across a plurality of slots can be caused to access the shared data section 205 in the slot to be executed next.

(5) The priority is determined according to the level of functional security required by the task. Specifically, tasks requiring a higher level of functional security, such as ASIL-D, are prioritized higher, and tasks requiring a lower level of functional security, such as QM, are prioritized lower. Thus, tasks with high functional safety levels are preferentially executed.

Modification 1

In embodiment 1, only 2 types of priorities are set. However, 3 or more priorities may be set. In this case, the processing is classified into the highest priority and the priority other than it. For example, when priorities 1 to 5 are set and the higher the number is, the more prioritized the tasks of priorities 1 to 4 are, the task of lower priority in embodiment 1, that is, task 1 101. Then, only the task with priority 5 corresponds to the task with high priority in embodiment 1, i.e., the task 2 102.

Modification 2

In embodiment 1, the priority is determined according to the functional security level required for the task. But may also determine the priority of the task based on other criteria. For example, the priority of tasks may also be determined based on the magnitude of the impact on other tasks, user preference, or functional security level and combinations thereof.

Embodiment 2

Embodiment 2 of a vehicle control device as an access control device will be described with reference to fig. 17. In the following description, the same components as those in embodiment 1 are denoted by the same reference numerals, and mainly different points will be described. The contents not specifically described are the same as those in embodiment 1. In the present embodiment, the difference is that the access to the shared data section 205 in the slot is not completed, but is mainly different from embodiment 1. That is, the following task is assumed in embodiment 2. That is, a certain task starts access to the shared data section 205 before the access monitoring time starts, and the access is not ended even if the access monitoring time starts. Further, even if the access monitor time ends, in other words, the end time of the slot is reached, the access of the task to the shared data section 205 is not ended.

In the present embodiment, the access flag of the data access control unit 105 is effectively used. The access flag is, for example, information stored in the memory 209. As described in embodiment 1, when access to the shared data unit 205 is permitted in response to a request from a task, the data access control unit 105 changes the access flag to "in-access", and changes the access flag to "not in-access" when data access is completed. When detecting that the access flag is "in access" at the end of the access monitoring time, the data access control section 105 resets all exclusive control by restarting the vehicle control device 2002.

Thus, the influence on other tasks due to exclusivity in the case of performing data access beyond the access monitoring time can be minimized, and recovery can be performed as early as possible. Further, when the task state is the execution state at the start of the access monitoring time and the access flag is "access in progress", it may be determined that an abnormality has occurred and the task may be changed to the standby state by the task state management unit 107. The restart target is not limited to the vehicle control device 2002, and may be restarted by the entire other deployed system.

Operation of data Access control section 105

Fig. 17 is a flowchart showing the operation of the data access control unit 105 in embodiment 2. The processing up to S203 is the same as that of embodiment 1, and therefore, the description thereof is omitted. When the access to the shared data portion 205 is started in S203, the data access control portion 105 determines whether or not the access to the shared data portion 205 by the task has been completed, and if it is determined that the access has been completed (yes in S211), the process proceeds to S204. When it is determined that the access has not been completed (S211: no), the data access control unit 105 determines whether the access monitoring time has been completed, and when it is determined that the access monitoring time has been completed (S212: yes), the vehicle control device 2002 is restarted (S213). If it is determined that the access monitoring time has not ended (no in S212), the data access control unit 105 returns to S211.

According to embodiment 2 described above, the following operational effects are obtained.

(6) The vehicle control device 2002 includes an access flag indicating an access state of the task to the shared data portion 205, and a data access control portion 105, wherein the data access control portion 105 sets the access flag on when the task starts to access the shared data portion 205, and sets the access flag off when the task ends to access the shared data portion 205. When the access flag is on at the end of the access monitoring time, the data access control unit 105 restarts the vehicle control device 2002. Therefore, the influence on other tasks due to exclusivity in the case of performing data access beyond the access monitoring time can be suppressed to the minimum, and the recovery can be performed as early as possible.

Embodiment 3

Embodiment 3 of a vehicle control device as an access control device will be described with reference to fig. 18. In the following description, the same components as those in embodiment 1 are denoted by the same reference numerals, and mainly different points will be described. The contents not specifically described are the same as those in embodiment 1. In the present embodiment, the access monitoring time is mainly set for the time slot allocated to the 2 nd task 102, which is different from that of the 1 st embodiment.

In this embodiment, the operation of the vehicle control device 2002 in the case where the 2 nd task 102 having a high safety requirement level is not allowed to affect other tasks will be described. That is, in the present embodiment, even when the next slot of the slots allocated to the 2 nd task 102 is the slot allocated to the 2 nd task 102, the access monitoring time for data access monitoring is set to the slot ending part allocated to the preceding 2 nd task 102. Thus, when a malfunction occurs in the 2 nd task 102 having a high security requirement level, the influence on the 2 nd task 102 having another high security requirement level can be prevented.

Operation of the system State management section 111

Fig. 18 is a flowchart showing the operation of the system state management unit 111 in embodiment 3. The same steps as those in embodiment 1 are denoted by the same reference numerals, and description thereof is omitted. When a negative determination is made in S400A, the system state management section 111 determines whether or not both the current slot and the next slot are assigned the 2 nd task 102 (S400C). In the case where a positive determination is made in this step, the system state management unit 111 proceeds to S401, and in the case where a negative determination is made, proceeds to S400B. The following operations are the same as those of embodiment 1, and therefore, description thereof will be omitted.

According to embodiment 3, by changing the arrangement target of the access monitoring time, it is possible to prevent the task having a high security requirement level from affecting other tasks.

Embodiment 4

Embodiment 4 of a vehicle control device as an access control device will be described. In the following description, the same components as those in embodiment 1 are denoted by the same reference numerals, and mainly different points will be described. The contents not specifically described are the same as those in embodiment 1. In the present embodiment, the difference is mainly that the schedule 501 is automatically generated, and that is, the present embodiment is different from embodiment 1.

A development tool, not shown, automatically generates the schedule 501. The development tool automatically generates the schedule 501 based on design information such as the period, worst execution time, security requirement level, etc. of each task. In the automatic generation, it is determined whether or not to set an access monitoring time for data access monitoring to the final part of each slot, based on the security requirement level information. In the case where the access monitor time is set, the configuration of the slot time including the access monitor time is performed.

According to embodiment 4 described above, since the schedule table 501 is automatically generated, application design can be performed regardless of the necessity of access monitoring time.

Embodiment 5

Embodiment 5 of a vehicle control device as an access control device will be described with reference to fig. 19 to 23. In the following description, the same components as those in embodiment 1 are denoted by the same reference numerals, and mainly different points will be described. The contents not specifically described are the same as those in embodiment 1. The present embodiment differs from embodiment 1 mainly in that the CPU208 of the vehicle control device 2002 includes a plurality of cores.

As shown in fig. 19, the CPU208 in the present embodiment is a so-called multi-core CPU including a 1 st core 1701, a 2 nd core 1702, and a 3 rd core 1703. However, the number of cores provided in the CPU208 may be 2 or more, and the number thereof is not limited. All cores execute the 1 st task 101 with a low security requirement level and the 2 nd task 102 with a high security requirement level, and each task accesses the shared data section 205. In the present embodiment, the system state is classified into 3 states, i.e., an overall monitoring state, an individual monitoring state, and a non-monitoring state.

Fig. 20 is a diagram showing an example of the system state table 1901. The system state table 1901 holds information on whether each core is in an individual monitoring state or a non-monitoring state, and "all-core access monitoring counter". The access monitor counter for the full core is increased or decreased between 0 and the core number. The state in which the value of the all-core access monitor counter is 1 or more is referred to as "the overall monitor state". That is, the access monitoring state and the non-access monitoring state in embodiment 1 correspond to the individual monitoring state and the non-monitoring state in the present embodiment, and indicate whether each core can access the shared data section 205. The overall monitoring state affects all cores, which are the whole of the vehicle control device 2002, and in the overall monitoring state, the 1 st task 101 in all cores is prohibited from newly accessing the shared data section 205.

In the present embodiment, the system state management unit 111 sets a monitoring time not only for the 1 st task 101 but also for the 2 nd task 102. The monitoring time of the 2 nd task 102 is set to be 2 times or more the access time.

With reference to fig. 21, description will be made on how to rewrite the system state table 1901. At the start of the access monitoring time in the 1 st task 101 slot (T4 b), the system state management unit 111 changes the system state of the 1 st core to the individual monitoring state. At the end of the access monitoring time in the 1 st task 101 slot (T4 c), the system state management unit 111 changes the system state of the 1 st core to the non-monitoring state. As described above, in the core of the individual monitoring state, the 1 st task 101 is prohibited from accessing the shared data section 205 newly. At the beginning of the access monitoring time in the time slot of task 2 (T4 e), the system state management unit 111 changes the system state of the core to the individual monitoring state, and also changes the access monitoring counter for the whole core to the whole monitoring state by incrementing the access monitoring counter by 1. At the end of the access monitoring time in the time slot of task 2 (T4 h), the system state management unit 111 changes the system state of the core to the non-monitoring state, and the access monitoring counter for the whole core is reduced by 1. When the reduction causes the value of the all-core access monitor counter to become zero, the entire monitor state is released.

As described above, when the access monitor counter for the whole core is 1 or more, the entire monitor state is set, and thus, the 1 st task 101 in all cores is prohibited from accessing new data in the shared data section 205. When there is a data access request to the shared data unit 205 by the 2 nd task 102 of the cores 1701, 1702, 1703, the data access control unit 105 preferentially performs data access to the 2 nd task 102 that is shortest until the end time of the executing slot. However, in the case where the entire monitoring state is not performed, that is, in the case where the shared data section 205 is accessed by all cores for a sufficient time before the end of the slot, the data access control section 105 may cause the 2 nd task 102 to access the shared data section 205 in the order in which the requests are received. Thus, even when the 1 st task 101 of the other core is accessed before the access monitoring time, the time for executing the data access of the 2 nd task 102 after the data access of the 1 st task 101 is completed can be ensured. Therefore, the influence on the 2 nd core 1702 caused by the data access of the 1 st task 101 in the multi-core environment can be prevented. This is specifically described with reference to fig. 22.

Fig. 22 is a diagram showing a situation in which the access request of the 2 nd task 102 to the shared data section 205 is repeated. In fig. 22, time passes from the left to the right in the drawing, and states of the 1 st core 1701, the 2 nd core 1702, and the 3 rd core 1703 are shown from above. However, fig. 22 is a schematic diagram showing that the time axis is not uniform in length. For example, in fig. 22, the access time of core 3 1703 is plotted very long compared to the other cores, but this is caused by a mapping problem, all access times being approximately the same. The 1 st core 1701 and the 2 nd core 1702 execute the 2 nd task 102, and the 3 rd core 1703 executes the 1 st task 101. The end time of the slot in the 1 st core 1701 is t6, and the overall monitoring time from time t3 is calculated from the monitoring time of the 2 nd task 102. The end time of the slot in the 2 nd core 1702 is t7, and the overall monitoring time from time t5 is calculated from the monitoring time of the 2 nd task 102. At time t0, the 1 st task 101 in the 3 rd core 1703 is accessing the shared data portion 205. This access continues until time t 4.

At time t1, as shown by the downward triangle, an access request for the shared data portion 205 by the 2 nd task 102 is generated in the 2 nd core 1702. At the next time t2, as shown by the downward triangle, the 1 st core 1703 generates a request for access to the shared data portion 205 by the 2 nd task 102. Then, at time t3, the 1 st core 1703 starts the overall monitoring time. At time t4 when the 1 st task 101 of the 3 rd core 1703 completes access to the shared data portion 205, the data access control portion 105 determines that the 1 st core 1701 is shorter than the 2 nd core 1702 in terms of time until the end of the slot, and allows the 2 nd task 102 of the 1 st core 1701 to access the shared data portion 205. Thereafter, at time t5, the access to the shared data portion 205 by the 1 st core 1701 is ended, and at this time, the data access control portion 105 starts the access to the shared data portion 205 by the 2 nd core 1702.

(operation of System State management section 111)

Fig. 23 is a flowchart showing the operation of the system state management unit 111 in embodiment 5. In fig. 23, the same steps as those in embodiment 1 are denoted by the same reference numerals, and description thereof is omitted. The system state management unit 111 determines whether or not the task to be executed in each slot is the 1 st task 101 at the start of the slot (S400A), and if it determines that the task to be executed is the 1 st task 101 (S400A: yes), it proceeds to S401A. In the case where it is determined that the task to be executed is not the 1 st task 101, that is, the 2 nd task 102 is to be executed (S400A: no), the following processing is performed in S400B.

That is, the system state management unit 111 sets the end time of the slot to the slot time monitoring unit 110, calculates the start time of the access monitoring time from the monitoring time for the task 2 102, sets the start time to the access time monitoring unit 109, and starts counting (S400B). When the system state management unit 111 determines that the monitoring time is the monitoring time (yes in S402B), the system state management unit changes the system monitoring state of the core to the individual monitoring state, increments the access monitoring counter for the whole core, changes the system state to the whole monitoring state (S403B), and proceeds to S404. However, when the system state is already the overall monitoring state, only the access monitoring counter for the full core is incremented.

In S401A, the system state management unit 111 calculates the start time of the access monitor time from the monitor time for the 1 st task 101, sets the start time to the access time monitor unit 109, sets the end time of the slot to the slot time monitor unit 110, starts counting, and proceeds to S402. In S402, when it is determined that the monitoring time is required (S402A: yes), the system state management unit 111 transitions the system monitoring state of the core to the individual monitoring state and proceeds to S404 (S403A). In S404, when the determination is made as the slot time, the system monitoring state of the core is changed to the non-monitoring state, and the access monitoring counter for the whole core is reduced (S405A). When the reduction causes the value of the all-core access monitor counter to be zero, the entire monitor state is released.

According to embodiment 5 described above, the following operational effects are obtained.

(7) The system state management unit 111 sets the 2 nd predetermined time at the end of the slot in the slot allocated to the 2 nd task 102 as the overall monitoring time, and the overall monitoring time has a length equal to or longer than the individual monitoring time, in the core including the CPU 208 executing the plurality of tasks. The data access control unit 105 determines whether or not the access monitoring time is set for each core of the CPU 208, and prohibits the access of the 1 st task 101 executed in all cores in the entire monitoring time to the shared data unit 205. Therefore, in the case where the CPU 208 includes a plurality of cores and can execute a plurality of tasks in parallel, by setting the access monitoring time for each core, it is possible to prevent the task with a low security requirement level from affecting the task with a high security requirement level. Further, by limiting the access of the 1 st task 101 to the shared data section 205 in all cores by setting the overall monitoring time at the end of the slot of the 2 nd task 102, it is possible to make the 2 nd task 102 being executed in all cores access the shared data section 205 preferentially, preventing delay in execution.

(8) When the 2 nd task 102 in the plurality of cores attempts to access the shared data section 205, the data access control section 105 preferentially makes an access to the shared data section 205 by the 2 nd task 102 whose time until the end of the slot being executed is less than the total monitoring time. Therefore, when the accesses to the shared data portion 205 by the 2 nd task 102 are repeated, the access to the shared data portion 205 by the 2 nd task 102 is provided as much as possible with priority given to the access to the task having a shorter time until the execution ends.

(modification of embodiment 5)

The overall monitoring time may be longer than the product of the number of cores and the time required for the task to access the shared data section 205. This can prevent the influence of the data access of the 2 nd task 102 being executed in the other cores.

Embodiment 6

Embodiment 6 of a vehicle control device as an access control device will be described with reference to fig. 24. In the following description, the same components as those in embodiment 1 are denoted by the same reference numerals, and mainly different points will be described. The contents not specifically described are the same as those in embodiment 1. The present embodiment is mainly different from embodiment 1 in that a system state management unit is not provided.

In the present embodiment, the system state management unit 111 is replaced with a plurality of modes of the hardware timer and a plurality of flags corresponding to the modes to perform system state management. The timer holds a flag indicating that the set time has been reached.

Fig. 24 is a diagram showing an outline of the operation in the present embodiment. The operation of the timer will be described with reference to fig. 24. In the first mode, i.e., the continuous execution mode, when the counter reaches the set time (T5 d), the flag 1 is transitioned to the matching state, and the counter is reset to 0 to start counting again. When counting starts, flag 1 transitions to a non-matching state. By using this mode for the monitoring of the slot time, the task will be started at a defined time.

In the second mode, i.e., the single-flush execution mode, when the counter reaches the set time (T5 b), the flag 2 is changed to the matching state, and the counter is stopped until the time can be set again (T5 d). This mode is used for monitoring the access monitoring time. The starting time of the access monitoring time is set at the beginning of the time slot (T5 a). When the task attempts data access, the system state determination unit 106 refers to the flag 2, and determines that the task is in the access monitoring state when the flag 2 is in the matching state, and the data access control unit 105 prohibits data access of the task.

According to embodiment 6, the management of the system state can be achieved by using only the hardware timer by simultaneously using a plurality of timer modes.

Embodiment 7

Embodiment 7 of a vehicle control device as an access control device will be described with reference to fig. 25 to 26. In the following description, the same components as those in embodiment 1 are denoted by the same reference numerals, and mainly different points will be described. The contents not specifically described are the same as those in embodiment 1. In this embodiment, the difference is mainly that an FPGA is used from embodiment 1.

(constitution)

Fig. 25 is a block diagram of a vehicle control device 2002 according to embodiment 7. In the present embodiment, the access time monitor 109, the slot time monitor 110, and the system state manager 111 are configured in an FPGA (field-programmable gate array field programmable gate array). In addition to the configuration of embodiment 1, the FPGA is provided with a timer flag monitor 2303.

Fig. 26 is a diagram illustrating the operation of the timer flag monitor 2303. The timer flag monitor 2303 always compares the access time monitor 109 and the time slot monitor 110 with the time of the timer. Then, when the access time monitor 109 matches the timer (time T6b in fig. 26), the timer flag monitor 2303 changes the monitor flag to the matching state, and when the slot time monitor matches the timer (time T6 d), changes the slot flag to the matching state. The system state management unit 111 monitors the state transition of the monitor flag and the slot flag, and when the monitor flag transitions to the matching state (time T6 b), transitions the system state to the access monitor state. When the slot flag is changed to the matching state (time T6 d), the system state management unit 111 changes the system state to the non-access monitoring state.

According to embodiment 7 described above, a plurality of times can be monitored by one timer by time monitoring and state management using an FPGA.

Embodiment 8

Embodiment 8 of a vehicle control device as an access control device will be described with reference to fig. 27 to 28. In the following description, the same components as those in embodiment 1 are denoted by the same reference numerals, and mainly different points will be described. The contents not specifically described are the same as those in embodiment 1. In this embodiment, the operation log management unit 213 is mainly different from embodiment 1 in that the operation is clarified.

Fig. 27 is a flowchart showing the operation of the operation log management unit 213. The action log management unit 213 acquires and records the start time and end time of the task in each slot, the task ID, and the state at the end of the slot (S701 and S702) (S703). In particular, the state at the end is recorded, and thus, whether or not a task is operating normally, whether or not it is a crossing task having a long operating time, whether or not it is a forced end due to occurrence of an abnormality, whether or not it is an end due to data access in the access monitoring time, and whether or not it is a crossing interrupt due to data access in the access monitoring time are held in the operation log.

Fig. 28 is a diagram showing an example of the action log 1101 recorded by the action log management unit 213. The action log 1101 records the start time, end time, task ID, and end time of each slot.

According to embodiment 8, the status of the task at each time can be confirmed by recording the action log. Further, a task that attempts data access at a time that affects other tasks can be found.

While various embodiments and modifications have been described above, the present invention is not limited to these. Other forms contemplated within the scope of the technical idea of the present invention are also included within the scope of the present invention.

Symbol description

101. Task 1

102. Task 2

105. Data access control unit

106. System state determination unit

107. Task state management unit

108. Scheduling unit

109. Access time monitoring unit

110. Time slot time monitoring unit

111. System state management unit

205. Shared data section

206. Task execution control unit

208 CPU

210. Time-piece

213. Action log management part

214. Application part

215. Hardware

216. Software for providing a plurality of applications

501. Scheduling table

1101. Action log

1901. System state table

2001. Vehicle system

2002. Vehicle control device

2303. A timer mark monitoring part.

Claims (7)

1. An access control device, comprising:

an application unit that includes a task 1 having a low priority and a task 2 having a high priority, which are classified according to the priority of execution;

an execution unit that executes the 1 st task and the 2 nd task;

a system state management unit that allocates a time slot of a predetermined length for each task to be executed, and sets a 1 st predetermined time at the end of the time slot as an access monitoring time in the time slot allocated to the 1 st task;

a shared data unit which is accessed by the 1 st task and the 2 nd task; and

a data access control unit that prohibits access to the shared data unit by the 1 st task in the access monitoring time,

the access monitoring time is longer than a time required for the 1 st task to access the shared data portion.

2. The access control device according to claim 1, wherein,

the data access control unit transitions the 1 st task for which access to the shared data unit is attempted during the access monitoring time to an end state.

3. The access control device according to claim 1, wherein,

When the 1 st task executed across a plurality of the time slots attempts access to the shared data section within the access monitoring time beyond a final time slot, the data access control section stands by the 1 st task until a start time of a next time slot.

4. The access control apparatus according to claim 1, further comprising:

an access flag indicating an access state of a task to the shared data section; and

a flag management unit that sets the access flag to on when the access of the task to the shared data unit is started, sets the access flag to off when the access of the task to the shared data unit is ended,

and if the access flag is on at the end of the access monitoring time, the data access control unit restarts the access control device.

5. The access control device according to claim 1, wherein,

comprising a plurality of execution units for executing the tasks,

the system state management unit further sets a 2 nd predetermined time at the end of the time slot within the time slot allocated to the 2 nd task as an overall access monitoring time, the 2 nd predetermined time being equal to or longer than the 1 st predetermined time,

The data access control unit determines for each of the execution units whether or not the access monitoring time is set, and prohibits the 1 st task executed by all the execution units within the overall access monitoring time from accessing the shared data unit.

6. The access control device according to claim 5, wherein,

when the 2 nd task among the plurality of execution units attempts to access the shared data unit, the data access control unit prioritizes the access of the 2 nd task to the shared data unit, which is performed for a short time until the end of the slot.

7. The access control device according to claim 1, wherein,

the priority is determined according to the level of functional security required by the task.