EP0612917A1 - Engine control - Google Patents

Abstract

A control (1) for an engine of a motor vehicle contains a computing component (2) by means of which measured values which represent operational variables of the engine (e.g. the intake air temperature) are detected and evaluated and control signals for actuators which act on the operation of the engine (e.g. control the injection of fuel) are produced. The control 1 has an operating system which simplifies the management of operations which are to be initiated in a time-dependent manner. It includes a first time monitoring for operations whose activation is to be tested at short time intervals (e.g. diagnostic communication), and a second time monitoring for operations whose activation is to be tested at long time intervals (e.g. measurement of the intake air temperature and coolant temperature, heating of the lambda probe heater etc.). <IMAGE>

Description

The invention relates to an engine control according to the preamble of claim 1.

In a known engine control system (DE 38 26 526 A1), programs of different temporal priority run, namely time-independent programs and programs dependent on crank angle. Priority-high are programs that trigger an engine control process at a given crank angle, e.g. Fuel is injected or ignited. So-called background programs run with low priority. Time-dependent programs are divided into different groups, at least one so-called shortest-distance program group and longer-distance programs. At least one of the longer programs is appended to the shortest-distance programs, forming a network group. This operating system is complex.

For many applications in engine control technology, it is important not to activate tasks that are to be processed by the engine control system - also referred to as tasks below - by triggering them depending on the crankshaft, but rather to initiate them as a function of time. An authenticity operating system therefore has to provide tools that allow time-dependent events to be controlled.

The invention has for its object to provide a motor controller, the operating system reduces the effort for time management.

This object is achieved according to the invention by the engine control according to claim 1.

Advantageous further developments of the invention are laid down in the subclaims.

Figur 1

die wesentlichen Bestandteile einer erfindungsgemäßen Motorsteuerung als Blockschaltbild,

Figur 2

den Aufbau einer ersten Zeitüberwachung der Motorsteuerung nach Figur 1,

Figur 3

ein Struktogramm einer zyklischen Routine der ersten Zeitüberwachung,

Figur 4

den Aufbau einer zweiten Zeitüberwachung der Motorsteuerung nach Figur 1,

Figur 5

das Struktogramm einer zyklischen Routine der zweiten Zeitüberwachung,

Figur 6

das Struktogramm einer Routine zur Erteilung eines Zeitauftrags, und

Figur 7

das Struktogramm einer Routine zum Löschen eines Zeitauftrags.

An embodiment of the invention is explained below with reference to the drawing. Show it:

Figure 1

the essential components of an engine control according to the invention as a block diagram,

Figure 2

the structure of a first time monitoring of the motor control according to FIG. 1,

Figure 3

a structogram of a cyclical routine of the first time monitoring,

Figure 4

the structure of a second time monitoring of the engine control system according to FIG. 1,

Figure 5

the structure diagram of a cyclical routine of the second time monitoring,

Figure 6

the structogram of a routine for placing a time task, and

Figure 7

the structogram of a routine for deleting a time job.

Essential components of an engine control system 1 are a computing part 2 and a real-time part 3 (FIG. 1). The computing part and the real-time part are connected to one another by a so-called two-port or three-port RAM 4, by a plurality of so-called handshake lines 5 and by an interrupt line 6.

Several input lines 10 and output lines 11 are also connected to the computing part 2. Analogue temperature signals, for example, reach the computing part via an input line 10 and are digitized in this in an internal AD converter. Other input lines 10 are connected to a so-called HSI input and to port pins of the computing part 2. About the output lines 11 are from a so-called HSO output of the computation part, pulse-width-modulated control signals LLFS to the engine idling fill actuator and signals TEV to the vehicle tank vent valve. In the drawing, the vehicle and engine components not belonging to the engine control 1 are not shown, nor is the internal structure of the processors used, since they can be found in the manufacturer's manuals. Only a few of the input and output lines are shown as representative of all actually existing lines.

A line 14 forms a serial interface of the computing part 2 and via a bus 15 it is connected to two memory components, a RAM 16 and an EPROM 17.

The task of the computing part in FIG. 2 is to record and evaluate the measurement data received, either directly or via the real-time part 3, and to calculate control signals for the ignition, injection, etc. based on this and output them to the corresponding actuators via the real-time part 3. In order to be able to do the work with the required accuracy and speed, an operating system is used for the motor control, which is designed as described below.

• Ein Zeitereignis ist von jeder Task (jedem Auftrag) zu jeden Zeitpunkt einer - in bestimmten Grenzen - wählbaren Laufzeit zu starten.
• Ein gestartetes aber noch nicht erreichtes Zeitereignis muß jederzeit und von jeder Task abgebrochen können.
• Die Reaktion auf einen Zeitauftrag hat innerhalb einer Grundeinheit des Systemzeitrasters zu erfolgen.

The operating system contains a time management, by means of which the following requirements must be met:

• A time event is to be started by every task (every order) at any time of a selectable runtime - within certain limits.
• A started but not yet reached time event must be able to be canceled at any time and by any task.
• The response to a time job must take place within a basic unit of the system time grid.

The occurrence of a time event is to be equated with the statement that the waiting time specified for the event has expired.

The present engine control system has two different time monitors. The time grid is the same for both time monitors and is 10 ms. A finer grading is possible, but not necessary. It depends on the processor used.

A first time monitoring ZV_KURZ of the operating system generates short time intervals, i.e. Time intervals up to about 50 ms as described below. Every task, i.e. each order to be processed by the first engine control is assigned its own time entry, which is managed by the time management. After activating the task, this time entry is set to its initial value. When entering a time order, the event time to be entered is calculated from the current system time plus the time interval of the order.

Due to the first time monitoring, a task time counter is now compared with the current system time AKZEIT with each program run. When the counter reaches its final value, i.e. the entered waiting time has expired, the actions to be carried out to process the tasks are activated or initiated. Very short actions are carried out immediately while the time management is running, otherwise a task is set to the "ready" state. Each action is carried out by a program part - e.g. a subroutine - carried out. Accordingly, each action is assigned an address in a program memory.

The advantage of this first time monitoring is the low administrative effort when placing and deleting time orders. However, the amount of processing time is for querying the time counters larger, since each counter must be queried for every basic time event. This time management is therefore primarily suitable for recurring events with different durations. For one-off events, however, the processing effort is relatively high.

The first time management is primarily used for diagnostic communication, i.e. used to carry out a data exchange between the engine control 1 and an external diagnostic device.

• eine Zeitauftragsliste 19 (Figur 2),
• eine Adressenliste für die auszuführenden Aktionen und
• eine Tabelle der zyklischen Zeiten.

The first time monitoring has three tables:

• a time job list 19 (Figure 2),
• an address list for the actions to be performed and
• a table of cyclical times.

$\text{2⁷ = Zeitauftrag ist eingetragen und nicht abgelaufen}$

.
The structure of the time job list 19, which is stored as a table in the RAM 16, can be seen from FIG. A list position 0.1, ..., n is assigned to each time task. Each time job consists of 4 bytes. Two of these are written into a first line 20 of a list position, for example list position 0. Of these, the high-order high byte represents the address and the low-order low byte the associated status information. This status information is coded as follows:

$\text{2⁶ = Time order is re-issued after the expiry}$

$\text{2⁷ = time task has been entered and has not expired}$

.

The time of the event is entered in a second line 21 of the list position, ie the time at which the respective event occurs with the expiration of the waiting time and the associated action is started. The time calculated for an event and entered in line 21 is compared in the system time grid, ie every 10 ms, with the current time, that of a time not produced here System clock is delivered. If both times match, the respective event is triggered, for example a program run is started, a request is set or a task is assigned to a priority level.

A time job is issued by a macro call SETZA (= "set time job") with the parameters time interval, list position, Reg_1, Reg_2 and Reg_3. Therein the time interval is the length of time from the current point in time to the point in time at which the event occurs. The time interval can be a constant or a definable quantity. The list position indicates at which point in the list the time event is entered and which actions are to be carried out when the event occurs. The status contains the above-mentioned additional information about the time task. Reg_1 to Reg_3 are working registers of the respective task level.

A time task that has already been issued can be canceled by calling RESZA (= "reset time task") with the parameters status, list position, Reg_1 and Reg_2.

The above-described first time monitoring ZV_KURZ is shown in a structure diagram 22 in FIG. 3 in the overview.

A second time monitor ZV_LANG is implemented in such a way that the processing time that occurs for each basic time event is as short as possible and that even one-off events can be managed without much additional effort. It is used for time intervals from approximately 50 ms up to the maximum permissible time of around 655,350 ms in the motor control described here. When a time event occurs, actions to be performed here are to activate a task or to forward time stamps to one or more tasks. The second time monitoring is used, for example, to control a run-on time during which the motor control After switching off the ignition, carry out tasks (e.g. troubleshooting) and must therefore be supplied with power. It is also used to control intake air and coolant temperature measurement, λ-probe heating, the generation of the actual throttle valve signal, the fuel pump and much more.

An essential part of the second time monitoring are two lists: a time job list 24, which contains freely definable time events, and an address list 24, which contains the start addresses of the actions to be carried out, which are assigned to the individual time jobs (FIG. 4). If a time order is placed, it is entered in the time order list 24. If the time order placed is not the only one in the list, the orders are sorted according to the event times. The time task whose event time is the next occurrence is then the first in the list. The job with the furthest future is at the bottom of the list. The advantage of this second time monitoring is the short processing time. With every time management call occurring in the basic time grid, only the first entry must be queried for expiry. Has the event not yet occurred, i.e. the time until the event has not yet expired, the list 24 need not be queried any further.

If there are already several orders in the list 24, then if a new order is placed and it cannot be added to the end of the list due to its event time, at least part of the time order list would have to be copied over. Such time-consuming copying actions and the associated processor load are avoided here by so-called link connections. In addition to a time field 26, each time order in the time order list 24 also has a link field 27 which establishes the connection between the individual time orders. During a sorting process In the worst case, a maximum of three links - also referred to as pointers or address pointers - 28 must be treated. The beginning of the list is noted in a so-called list anchor 30, which contains the number of list entries (in the example 5) and a reference to the first time order in the list (in the example: list position 3).

The address list 25 contains in the individual list places the addresses 32 of the actions to be carried out, which are assigned to the respective time event.

• Erteilung von Zeitaufträgen,
• zyklische Überprüfung auf abgelaufene oder eingetretene Zeitereignisse und Überprüfung der damit verbundenen Aktionen, sowie
• vorzeitiges Abbrechen von generierten Zeitaufträgen, ohne daß eine zugeordnete Aktion ausgeführt wird.

Ein Zeitauftrag wird durch eine Task mit einem Makroaufruf
ZAERT [Listenplatz], [Zeitintervall]
erteilt. Dessen Parameter sind:
   Listenplatz gibt an, an welcher Stelle in der Liste das Zeitereignis eingetragen wird und welche Aktionen bei Eintreten des Ereignisses durchgeführt werden.
   Zeitintervall ist die Zeitdauer ab dem augenblicklichen Zeitpunkt, bis das Ereignis eintritt. Das Zeitintervall kann eine Konstante oder eine vorgebbare Größe sein.The management of time orders includes three routines:

• Placing time orders,
• cyclical checking for expired or occurring time events and checking the associated actions, as well
• premature cancellation of generated time orders without an assigned action being carried out.

A time job is created by a task with a macro call
ZAERT [ list position ] , [ time interval ]
granted. Its parameters are:
List position specifies at which point in the list the time event is entered and which actions are carried out when the event occurs.
Time interval is the length of time from the current point in time until the event occurs. The time interval can be a constant or a predeterminable quantity.

If a time job has already been issued and has not yet expired, the original job is ignored and the event is set to the new time.

A time order that has already been placed can be called up with a call
ZADEL [ list place ]
be canceled; it is removed from the time task list.

In the grid of the system base time, i.e. at intervals of 10 ms, the time job list is searched for expired time jobs. If an expired time job is found, i.e. An order whose waiting time has expired is removed from the list and the actions associated with it are carried out. The list is then searched again for another expired time job. The process is repeated until there is no longer an expired time job in the list. The cyclical time monitoring routine SUABZA (= search for expired time orders) carried out for this purpose is illustrated in FIG. 5 in the form of a structogram 34.

When setting up a new time job, the following steps must be carried out in the program:
In a data module SYSDAT.A96, in which the RAM 16 is described, a table ZA_LIST_LA is to be increased by the number of new time orders to be inserted. This is possible by reserving 4 bytes per time job. In a module ZEITVERW.A96 there is an EQU instruction or assignment instruction for the list position for each time task. Each new time task must be assigned its list position number using an EQU instruction. The start address of the program section to be executed in the time event is entered in a table AKTIONS_TAB. The place where the start address is stored must match the list place number. The actions to be performed are defined at the end of the module. The program sequence must be concluded with an unconditional jump to the SUABZA label.

A routine SETIM (= set time job) to be processed when the time job is issued is shown in FIG. 6 in the form of a structogram 35. The routine deltim (= set time job) to be processed to delete a time job is correspondingly illustrated by a structogram 36 in FIG. The individual steps of these structograms 22 and 34 to 36 are laid down in plain text, so that the structograms themselves are explanatory.

Claims (9)

Motor control (1) with a computing part (2), through the measured values, the operating variables of the motor, recorded and evaluated under program control and control signals for actuators which act on the motor operation are generated, and with one the detection and evaluation and the generation of Operating system controlling control signals, under which different types of programs are activated depending on time,
characterized in that the operating system defines a time management with the following time monitors: - a first time monitoring for tasks, the respective activation time of which must be checked at short intervals, and - a second time monitor for tasks, the respective activation time of which must be checked at long intervals. Motor control according to claim 1, characterized in that tasks are managed by the first time monitoring, the processing or activation of which has to take place within a few system time units, and tasks are managed by the second time monitoring, the processing or activation of which takes a larger number of system time units. Motor control according to claim 1, characterized in that the system time is divided into a grid with a time unit of 10 ms. Motor control according to claim 1, characterized in that the first time monitoring includes three tables: - a time task list (19), - an address list for the actions to be carried out and - a table of cyclical times. Motor control according to claim 4, characterized in that in the time job list (19) each time job is entered in a list place (0, ..., n), and in that the time job to be entered contains an address, status information and a time at which the Time task assigned to activate is included. Motor control according to Claim 5, characterized in that the entered time is compared with the content of a counter representing the current system time (AKZEIT) each time the program is run and, in the event of a match, the actions assigned to the time task are triggered. Motor control according to Claim 1, characterized in that the second time monitor contains a time job list (24) in which the time jobs are stored and an address list (25) in which the start addresses of the actions which are assigned to the individual time jobs are stored. Motor control according to claim 7, characterized in that the time orders in the time order list (24) are arranged in ascending chronological order and that this order is realized by links (pointers) which define the connections between the individual time orders. Motor control according to claim 7, characterized in that each time the time management calls in the system time grid, only the first order in the time order list (24) is queried for expiry.

Images