JP2000293382A - Task start controller using real-time operating system - Google Patents

Abstract

(57) [Problem] To provide a task activation control device using a real-time operating system capable of optimizing task activation by eliminating unnecessary processing. A CPU of an ECU detects the occurrence of each event and executes a desired arithmetic program. The arithmetic program includes a first event executed when the first event occurs.
A task group and a second task group that is executed when a second event occurs.
Contains two identical tasks. Before putting the tasks into the standby state to activate the first and second task groups due to the occurrence of the event, the task state is determined in the step 104, and when the same task is already in the standby state, the process in the step 105 is bypassed. To prohibit the transition to the standby state. Therefore, if the same task is connected, the task cannot be connected to the list.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a task activation control device using a real-time operating system.

[0002]

2. Description of the Related Art Conventionally, there is an apparatus disclosed in Japanese Patent Application Laid-Open No. 10-105416 for activating a task. That is, in an activation control device that activates a task using a real-time operating system that processes data within a requested time from the occurrence of an event (at the time of capturing parameters), a task activated by an event is made a common header file. By doing so, only the task header file needs to be changed for the change of the task connection mode, and the change can be easily implemented.

[0003]

In the above-mentioned technology, a task is activated by the occurrence of an event (although the task is linked), but when a plurality of events that activate the same task occur simultaneously, the task is set to the same task. It starts many times at the timing.

[0004] More specifically, in the case of a task to be executed when any one of the intake pressure pm, the intake temperature th a, and the water temperature thw changes in an automobile ECU (engine control ECU), as shown in FIG. If the intake air temperature “tha” changes immediately after the change of “pm”, the same process (task 1) is called twice, and finally the same task is executed twice.

[0005] This may cause an increase in processing load. The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a task activation control device using a real-time operating system capable of eliminating unnecessary processing and optimizing task activation. It is in.

[0006]

According to the first aspect of the present invention, a task state is determined before a task is put into a standby state to activate the first and second task groups upon occurrence of an event, When the same task is already in the standby state, the transition to the standby state is prohibited.

As described above, if the same task is connected, the task is not connected to the list, so that useless processing can be eliminated and task activation can be optimized.

[0008]

Embodiments of the present invention will be described below with reference to the drawings. In the present embodiment, an engine control ECU (ECU; Electric Contr)
olUnit).

FIG. 1 shows the overall configuration of the ECU 1. E
CU1 is for controlling the engine of the automobile. The ECU 1 is connected to the multiplex transmission line 2 and the multiplex transmission line 2
Connected to other electronic devices via LAN to build LAN,
It can be connected to a repair tool (not shown).

The ECU 1 comprises an MPU (microcomputer) 3, an external RAM (random access memory) 4, an input / output (I / O) unit 5, a communication unit 6, and an interface circuit 7. MPU3 is RO
M (read only memory) 8, internal RAM 9, and CPU
(Central processing unit) 10.

The ECU 1 is connected to an intake pipe pressure sensor 11, an engine speed sensor 12, a water temperature sensor 13, and an intake temperature sensor 14. The intake pipe pressure sensor 11 outputs a signal corresponding to the intake pipe pressure pm of the engine, and the engine speed sensor 12 outputs a signal corresponding to the engine speed Ne. Further, a signal corresponding to the engine cooling water temperature thw is output from the water temperature sensor 13 and the intake air temperature sensor 1
4 outputs a signal corresponding to the intake air temperature th. The signals from the sensors 11 to 14 are taken into the MPU 3 via the input / output (I / O) unit 5.

A fuel injection valve 15 is connected to the ECU 1, and the MPU 3 controls the driving of the fuel injection valve 15 via an input / output (I / O) unit 5. The communication unit 6 and the interface circuit 7 are used to send data from the MPU 3 to the multiplex transmission line 2 and to receive data from the multiplex transmission line 2.

The CPU 10 calculates the optimum fuel injection amount (injection time) according to the operating state of the engine based on the signals from the sensors 11 to 14 and the data through communication, and controls the driving of the fuel injection valve 15. In addition, the CPU 10 performs a self-diagnosis and determines whether or not various sensors and actuators are abnormal.

The MPU 3 is connected to a battery 17 via an ignition switch 16. The external RAM 4 is directly connected to the battery 17 and retains the stored contents even after the switch is turned off. This self-diagnosis result is stored in the external RAM 4.

The MPU 3 is equipped with a real-time operating system, and detects the occurrence of each event and executes a desired arithmetic program. In other words, MPU
3, the first detecting means for detecting the occurrence of the first event (the first environmental change) and the occurrence of the second event (the second event) different from the occurrence of the first event (the first environmental change) 2
Detecting means for detecting an environmental change), first and second
And an arithmetic unit for executing a desired arithmetic program based on the information from the detecting means. The arithmetic program includes a first task group executed when a first event occurs (first environment change) and a second task group executed when a second event occurs (second environment change). Task groups, and both task groups include at least one identical task.

The real-time operating system will be described in detail with reference to FIG. FIG. 2 shows a task activated by a certain parameter (changes in the intake pipe pressure pm, the intake air temperature th a, and the water temperature thw) in the real-time operating system. A task group when the intake pipe pressure pm changes is composed of task 5, task 6, and task 1, and a task group when the intake temperature th is changed is composed of task 1, task 2, and task 3, and the water temperature A task group when thw changes is composed of task 1 and task 4. Each task group for each event is selected (switched) by an event handler of the real-time operating system.

That is, the occurrence of an event (intake pipe pressure p
m, the intake air temperature tha, and the water temperature thw), the scheduling is performed so as to correspond to the type of the event. Specifically, when the intake pipe pressure pm changes, the task 5, the task 6, and the task 1 are connected, and when the intake temperature th a changes, the task 1, the task 2, and the task 3 are connected, Further, when the water temperature thw changes, task 1 and task 4 are linked.

As described above, the tasks 1 to 6 are executed only when any one of the intake pipe pressure pm, the intake air temperature tha, and the water temperature thw changes, and each task group includes at least one task. The same task (in the case of FIG. 2,
Task 1) is included.

Then, this task group is started with the occurrence of the event, and the tasks in the standby state (the tasks constituting the task group) are executed in order. For example, the intake pipe pressure p
When m changes, tasks 5, 6, and 1 are executed in order.

Next, the operation of the ECU 1 configured as described above, that is, the operation of the task activation control device using the real-time operating system will be described. In the description of this operation, the intake pipe pressure pm and the intake air temperature t
A case will be described in which ha and the water temperature thw are used, and they are taken into the CPU 10 for processing.

FIG. 3 shows a flowchart of the scheduling. This process starts every 4 ms. FIG. 4 shows an example of task data to be activated and scheduling. FIG. 4 shows a case where the intake air temperature tha changes immediately after the intake pipe pressure pm changes, and the water temperature thw changes immediately thereafter. That is, this is an example in which pm, tha, and thw continuously change before the task is executed.

In FIG. 3, the CPU 10 determines in step 10
At 0, the parameters are fetched. That is, the intake pipe pressure pm, the intake air temperature tha, and the water temperature thw are taken in every 4 ms. Then, in step 101, the CPU 10 determines whether or not the intake pipe pressure pm, the intake air temperature tha, and the water temperature thw have changed from the previous intake value. If there is no change, the CPU 10 ends the processing of the flowchart in FIG.

On the other hand, if there is a change from the previous captured value in step 101, the CPU 10 determines that an event has occurred due to a change in the environment, interrupts the event handler of the real-time operating system, and executes the subsequent processing ( Add tasks to OS scheduling).

First, the routine proceeds to step 102, where the CPU
Reference numeral 10 indicates the head of the task list to be started (pointing to the head of the task list by a pointer). Then, the CPU 10 reads out the states of the tasks one by one in order from the leading task in step 103, and determines in step 104 whether the task state is the standby state (whether or not the task has been registered). For example, when it is determined that the intake pipe pressure pm has changed, as shown in FIG. 2, since the tasks 5, 6, and 1 are programs to be executed, the state of task 5, which is the first task, is determined first. Is done.

The state of a task is determined as follows. Each task is coded by a program statement as shown in FIG. 5, and the task is configured. At the head address of each task, flag information (flag) indicating the status of the task is arranged along with the task function name (Tsk) and the task priority (pri). To be precise, FIG.
Only the corresponding address is described in the program sentence of (1), and the flag state is stored in an arbitrary RAM area indicated by the address as shown in FIG. In the example of FIG. 6, $ 00 indicates that the job is being executed, $ 01 indicates that the job is waiting, and $ 11 indicates that the job is paused.
The CPU 10 looks at this flag information, and in the example of FIG.
It is determined whether it is not 1.

Then, as a result of reading the data of FIG. 6 in step 104 of FIG. 3, if this data is not $ 01 indicating that the task is waiting, then in step 105, the task is set to $ 01 indicating that the task is waiting (# 11 To $ 01).

Here, in FIG. 4, when the intake pipe pressure pm changes, the process of [1] is performed in step 104 of FIG.
Since the first task 5 (see FIG. 2) is not in standby, it is set in standby (registered) in step 105.

On the other hand, if the task is in the standby state in step 104 of FIG. 3, the processing of step 105 is not performed. Then, after performing the processing of step 105 or 104, the CPU 10 proceeds to step 106 to determine whether there is a task to be read, and if there is a task to be read, returns to step 103. Therefore, if there is a task to be read, the processing of steps 103 to 105 is repeated.

In the case of FIG. 4, as described above, after the task 5 is put on standby when the intake pipe pressure pm changes, the task 6 is read out (step 103). (Step 105), and the task 1 is read out (step 103). Since the task 1 is not waiting, the task 1 is put on standby (step 105).

Then, in step 106 of FIG.
When there is no task to be read, the process of the flowchart in FIG. 3 ends. In the case of FIG. 4, when the intake air temperature th changes next [2], the first task 1 (see FIG. 2) is read in step 103 of FIG. 3, and the data of FIG. 6 is read in step 104. As a result, since this data is $ 01 indicating standby, the process of step 105 is not performed. Therefore, the task 1 at the end of the task group associated with the change in the intake pipe pressure pm cannot be connected to the task 1 at the head of the task group associated with the change in the intake air temperature th.

Thereafter, the task 2 in FIG. 2 is read (step 103), and is set in a standby state because it is not in standby (step 105). Further, the task 3 is read out (step 103) and is in standby state because it is not in standby. (Step 105).

Then, in step 106 of FIG.
When there is no task to be read, the process of the flowchart in FIG. 3 ends. In the case of FIG. 4, when the water temperature thw changes next [3], the first task 1 (see FIG. 2) is read in step 103 of FIG.
As a result of reading this data, the data is $ 01 indicating that it is on standby, so that the processing of step 105 is not performed.
Therefore, the task 1 at the head of the task group associated with the change in the water temperature thw cannot be connected after the task 3 at the end of the task group associated with the change in the intake air temperature th.

Thereafter, the task 4 in FIG. 2 is read (step 103), and is in a standby state (step 105) because it is not in a standby state. Then, when there is no task to be read in step 106 of FIG. 3, the processing of the flowchart of FIG. 3 ends.

As described above, if there is a difference even if the intake pipe pressure pm is compared with the previous value, a task is added to the scheduling of the OS. Next, when the intake air temperature “tha” changes and is added to the scheduling of the OS, the task 1 has already been registered, so that the task 1 is omitted and registered. Similarly, when the water temperature thw changes, the task 1 is registered, so that the task 1 is omitted. This allows
Since the same task is not executed, the processing load is reduced.

That is, the task state is already waiting ($ 0
If it is 1), it is determined that registration has been completed in step 104 of FIG. 3, and the processing of step 105 is not executed. Therefore, the same task (task 1 in FIG. 4) is not executed twice.

As described above, this embodiment has the following features. (B) When both task groups in at least two task groups include at least one same task,
As shown in FIG. 3, before the task is put into a standby state in order to activate the first and second task groups due to the occurrence of an event in step 105, the task state is determined in step 104, and the same task is already in the standby state. In some cases, the process of step 105 is bypassed to prohibit the transition to the standby state.

Therefore, if the same task is connected, the task is not connected to the list, thereby eliminating unnecessary processing and optimizing task activation. In other words, if the same task is connected, the task is not connected to the list, so that a structure that does not start a useless task having the same result as the previous result can be constructed (useless processing can be omitted).

[Brief description of the drawings]

FIG. 1 is a configuration diagram of an engine control ECU.

FIG. 2 is an explanatory diagram of a task list.

FIG. 3 is a flowchart showing processing contents of a CPU.

FIG. 4 is a diagram for explaining scheduling.

FIG. 5 is a diagram showing an example of an OS program source.

FIG. 6 is a diagram showing a memory for storing data indicating a flag state;

FIG. 7 is a diagram for explaining a conventional technique.

[Explanation of symbols]

 1 ... ECU, 3 ... MPU, 10 ... CPU

Claims (1)

[Claims] A first event detecting means for detecting occurrence of a first event; a second event detecting means for detecting occurrence of a second event different from the first event; , An arithmetic device that executes a desired arithmetic program based on the occurrence of a second event, wherein the arithmetic program includes a first task group executed when the first event occurs, and a second event And a second task group to be executed when the event occurs. In addition, both task groups include at least one same task, and the first and second task groups are activated when an event occurs. A real-time operating system characterized in that the task status is determined before the task is put into the standby state, and the transition to the standby state is prohibited when the same task is already in the standby state. There was a task start control device.