EP0612917A1 - Motorsteuerung - Google Patents

Motorsteuerung Download PDF

Info

Publication number
EP0612917A1
EP0612917A1 EP93102978A EP93102978A EP0612917A1 EP 0612917 A1 EP0612917 A1 EP 0612917A1 EP 93102978 A EP93102978 A EP 93102978A EP 93102978 A EP93102978 A EP 93102978A EP 0612917 A1 EP0612917 A1 EP 0612917A1
Authority
EP
European Patent Office
Prior art keywords
time
list
motor control
control according
job
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP93102978A
Other languages
English (en)
French (fr)
Other versions
EP0612917B1 (de
Inventor
Heinz Dipl.-Ing. Neugebauer (Fh)
Herbert Dipl.-Ing. Ziegler (Fh)
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE59303660T priority Critical patent/DE59303660D1/de
Priority to EP19930102978 priority patent/EP0612917B1/de
Publication of EP0612917A1 publication Critical patent/EP0612917A1/de
Application granted granted Critical
Publication of EP0612917B1 publication Critical patent/EP0612917B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02D—CONTROLLING COMBUSTION ENGINES
    • F02D41/00—Electrical control of supply of combustible mixture or its constituents
    • F02D41/24—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means
    • F02D41/26—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor
    • F02D41/266—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor the computer being backed-up or assisted by another circuit, e.g. analogue

Definitions

  • the invention relates to an engine control according to the preamble of claim 1.
  • 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.
  • the invention has for its object to provide a motor controller, the operating system reduces the effort for time management.
  • 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.
  • 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.
  • an operating system is used for the motor control, which is designed as described below.
  • 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.
  • a task time counter is now compared with the current system time AKZEIT with each program run.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • each time order in the time order list 24 also has a link field 27 which establishes the connection between the individual time orders.
  • link field 27 which establishes the connection between the individual time orders.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the individual steps of these structograms 22 and 34 to 36 are laid down in plain text, so that the structograms themselves are explanatory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Mechanical Engineering (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)

Abstract

Eine Steuerung (1) für einen Kraftfahrzeugmotor enthält einen Rechenteil (2), durch den Meßwerte erfaßt und ausgewertet werden, die Betriebsgrößen des Motors wiedergeben (z.B. die Ansauglufttemperatur), und Steuersignale für Stellglieder erzeugt werden, die auf den Motorbetrieb einwirken (z.B. die Kraftstoffeinspritzung steuern). Die Steuerung 1 weist ein Betriebssystem auf, das die Verwaltung von zeitabhängig anzustoßenden Aufgaben vereinfacht. Es schließt ein eine erste Zeitüberwachung für Aufgaben, deren Aktivierung in kurzen Zeitabständen zu überprüfen ist (z.B. Diagnosekommunikation), und eine zweite Zeitüberwachung für Aufgaben, deren Aktivierung in langen Zeitabständen zu überprüfen ist (z.B. Messung der Ansaugluft- und der Kühlmitteltemperatur, Heizung der λ-Sondenheizung usw.). <IMAGE>

Description

  • Die Erfindung betrifft eine Motorsteuerung nach dem Oberbegriff von Anspruch 1.
  • Bei einer bekannten Motorsteuerung (DE 38 26 526 A1) laufen Programme unterschiedlicher zeitlicher Priorität ab, und zwar zeitunabhängige Programme und kurbelwinkelabhängige Programme. Prioritätshoch sind Programme, mit denen bei einem vorgegebenen Kurbelwinkel ein Motorsteuervorgang ausgelöst wird, z.B. Kraftstoff eingespritzt oder gezündet wird. Mit niedriger Priorität laufen sogenannte Hintergrundprogramme ab. Zeitabhängige Programme sind in verschiedene Gruppen eingeteilt, mindestens eine sogenannte abstandskürzeste Programmgruppe und abstandlängere Programme. An die abstandskürzesten Programme ist mindestens eines der abstandslängeren Programme angefügt, wobei eine Verbundgruppe gebildet wird. Dieses Betriebssystem ist aufwendig.
  • Bei vielen Anwendungen in der Motorsteuerungstechnik ist es wichtig, Aufgaben, die von der Motorsteuerung abzuarbeiten sind - im folgenden auch als Tasks bezeichnet - nicht durch kurbelwellenabhängige Anstöße zu aktivieren, sondern zeitabhängig anzustoßen. Ein Echtheitbetriebssystem hat deshalb Hilfsmittel zur Verfügung zu stellen, die es erlauben, zeitabhängige Ereignisse zu steuern.
  • Der Erfindung liegt die Aufgabe zugrunde, eine Motorsteuerung zu schaffen, durch deren Betriebssystem der Aufwand für die Zeitverwaltung verringert wird.
  • Diese Aufgabe wird erfindungsgemäß durch die Motorsteuerung nach Anspruch 1 gelöst.
  • Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen niedergelegt.
  • Ein Ausführungsbeispiel der Erfindung wird im folgenden anhand der Zeichnung erläutert. Es zeigen:
    • 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.
  • Wesentliche Bestandteile einer Motorsteuerung 1 sind ein Rechenteil 2 und ein Echtzeitteil 3 (Figur 1). Der Rechenteil und der Echtzeitteil sind durch ein sog. Zwei- oder Drei-Port-RAM 4, durch mehrere sog. Handshake-Leitungen 5 und durch eine Interrupt-Leitung 6 miteinander verbunden.
  • An den Rechenteil 2 sind ebenfalls mehrere Eingangsleitungen 10 und Ausgangssleitungen 11 angeschlossen. Über eine Eingangsleitung 10 gelangen z.B. analoge Temperatursignale zu dem Rechenteil und werden in diesem in einem internen AD-Wandler digitalisiert. Andere Eingangsleitungen 10 sind an einen sog. HSI-Eingang und an Port-Pins des Rechenteils 2 angeschlossen. Über die Ausgangsleitungen 11 werden von einem sog. HSO-Ausgang des Rechenteils pulsweitenmodulierte Steuersignale LLFS an den Leerlauffüllungssteller des Motors und Signale TEV an das Tankentlüftungsventil des Fahrzeugs ausgegeben. In der Zeichnung sind die nicht zu der Motorsteuerung 1 gehörenden Fahrzeugs- und Motorbestandteile nicht dargestellt, ebenso nicht der interne Aufbau der verwendeten Prozessoren, da sie den Handbüchern des Herstellers entnommen werden können. Von den Eingangs- und Ausgangsleitungen sind nur einige wenige stellvertretend für alle tatsächlich vorhandenen Leitungen dargestellt.
  • Eine Leitung 14 bildet eine serielle Schnittstelle des Rechenteils 2 und über einen Bus 15 ist dieser mit zwei Speicherbausteinen, einem RAM 16 und einem EPROM 17, verbunden.
  • Die Aufgabe des Rechenteils in 2 ist es, die - entweder direkt oder über den Echtzeitteil 3 - empfangenen Meßdaten zu erfassen und auszuwerten und darauf basierend Steuersignale für die Zündung, die Einspritzung usw. zu berechnen und über den Echtzeitteil 3 an die entsprechenden Aktoren auszugeben. Um die Arbeiten mit der erforderlichen Genauigkeit und Schnelligkeit erledigen zu können, wird für die Motorsteuerung ein Betriebssystem eingesetzt, das wie nachfolgend beschrieben ausgebildet ist.
  • Das Betriebssystem enthält eine Zeitverwaltung, durch die folgende Anforderungen zu erfüllen sind:
    • 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.
  • Der Eintritt eines Zeitereignisses ist hierbei gleichzusetzen mit der Aussage, daß die für das Ereignis vorgegebene Wartezeit abgelaufen ist.
  • Die vorliegende Motorsteuerung weist zwei verschieden ablaufende Zeitüberwachungen auf. Das Zeitraster ist für beide Zeitüberwachungen gleich und beträgt 10 ms. Eine feinere Zeitstufung ist möglich, aber nicht erforderlich. Sie hängt von dem verwendeten Prozessor ab.
  • Eine erste Zeitüberwachung ZV_KURZ des Betriebssystem generiert kurze Zeitintervalle, d.h. Zeitintervalle bis etwa 50 ms, wie nachfolgend beschrieben. Jeder Task, d.h. jedem von der ersten Motorsteuerung abzuarbeitenden Auftrag, wird ein eigener Zeiteintrag zugeordnet, der durch die Zeitverwaltung verwaltet wird. Nach einer Aktivierung der Task wird dieser Zeiteintrag auf seinen Initialwert gesetzt. Beim Eintragen eines Zeitauftrags wird der einzutragende Ereigniszeitpunkt aus der aktuellen Systemzeit plus dem Zeitintervall des Auftrags errechnet.
  • Durch die erste Zeitüberwachung wird nun bei jedem Programmdurchlauf ein Taskszeitzähler mit der aktuellen Systemzeit AKZEIT verglichen. Erreicht der Zähler seinen Endstand, d.h. die eingetragene Wartezeit ist abgelaufen, werden die zur Abarbeitung der Tasks durchzuführenden Aktionen aktiviert oder angestoßen. Zeitlich sehr kurze Aktionen werden dabei noch während des Ablaufs des Zeitverwaltung sofort ausgeführt, andernfalls wird eine Task in den Zustand "bereit" versetzt. Jede Aktion wird durch ein Programmteil - z.B. ein Unterprogramm - durchgeführt. Dementsprechend ist jeder Aktion eine Adresse in einem Programmspeicher zugeordnet.
  • Vorteilhaft ist bei dieser ersten Zeitüberwachung der geringe Verwaltungsaufwand beim Erteilen und Löschen von Zeitaufträgen. Allerdings ist der Aufwand an Verarbeitungszeit für das Anfragen der Zeitzähler größer, da bei jedem Grundzeitereignis jeder Zähler abgefragt werden muß. Diese Zeitverwaltung eignet sich somit in erster Linie für wiederkehrende Ereignisse mit unterschiedlicher Zeitdauer. Für einmalig auftretende Ereignisse hingegen ist der Verarbeitungsaufwand relativ hoch.
  • Die erste Zeitverwaltung wird in erster Linie für die Diagnosekommunikation, d.h. zum durchführen eines Datenaustausches zwischen der Motorsteuerung 1 und einem externen Diagnosegerät, eingesetzt.
  • Die erste Zeitüberwachung weist drei Tabellen auf:
    • eine Zeitauftragsliste 19 (Figur 2),
    • eine Adressenliste für die auszuführenden Aktionen und
    • eine Tabelle der zyklischen Zeiten.
  • Der Aufbau der Zeitauftragsliste 19, die als Tabelle in dem RAM 16 abgelegt ist, ist aus Figur 2 ersichtlich. Jedem Zeitauftrag wird ein Listenplatz 0,1, ..., n zugeteilt. Jeder Zeitauftrag besteht aus 4 Bytes. Zwei davon werden in eine erste Zeile 20 eines Listenplatzes, z.B. des Listenplatzes 0, eingeschrieben. Von diesen stellt das höherwertige High-Byte die Adresse und das niederwertige Low-Byte die zugehörige Statusinformation dar. Diese Statusinformation ist folgendermaßen codiert:

    2⁶ = Zeitauftrag wird nach Ablauf neu erteilt
    Figure imgb0001
    2⁷ = Zeitauftrag ist eingetragen und nicht abgelaufen
    Figure imgb0002
     .
  • In einer zweiten Zeile 21 des Listenplatzes wird der Ereigniszeitpunkt eingetragen, d.h. der Zeitpunkt, zu dem mit Ablauf Wartezeit das jeweilige Ereignis eintritt und die zugehörige Aktion gestartet wird. Die für ein Ereignis berechnete und in die Zeile 21 eingetragene Zeit wird in dem Systemzeitraster, d.h. alle 10 ms, mit der aktuellen Zeit verglichen, die von einer hier nicht hergestellten Systemzeituhr geliefert wird. Stimmen beide Zeiten überein, so wird das jeweilige Ereignis ausgelöst, z.B. ein Programmlauf gestartet, ein Bitt gesetzt oder eine Task einer Prioritätsstufe zugeordnet.
  • Ein Zeitauftrag wird durch einen Makroaufruf SETZA (= "setze Zeitauftrag") mit den Parametern Zeitintervall, Listenplatz, Reg_1, Reg_2 und Reg_3 erteilt. Darin ist das Zeitintervall die Zeitdauer ab dem augenblicklichen Zeitpunkt bis zu dem Zeitpunkt, zu dem das Ereignis auftritt. Das Zeitintervall kann eine Konstante oder eine festlegbare Größe sein. Der Listenplatz gibt an, an welcher Stelle in der Liste das Zeitereignis eingetragen wird eintreten und welche Aktionen beim Eintreten des Ereignisses durchzuführen sind. Der Status enthält die oben genannten zusätzlichen Informationen über den Zeitauftrag. Reg_1 bis Reg_3 sind Arbeitsregister der jeweiligen Taskebene.
  • Ein bereits erteilter Zeitauftrag kann mit einem Aufruf RESZA (= "reset Zeitauftrag") mit den Parametern Status, Listenplatz, Reg_1 und Reg_2 annulliert werden.
  • Die vorstehend beschriebene erste Zeitüberwachung ZV_KURZ ist in einem Struktogramm 22 in Figur 3 in der Übersicht dargestellt.
  • Eine zweite Zeitüberwachung ZV_LANG, ist so realisiert, daß die Bearbeitungszeit, die zu jedem Grundzeitereignis auftritt, möglichst gering ist und daß auch einmalige Ereignisse ohne großen Mehraufwand verwaltet werden können. Sie wird eingesetzt für Zeitintervalle ab etwa 50 ms bis zu der bei der hier beschriebenen Motorsteuerung maximal zulässigen Zeit von rund 655.350 ms. Bei Eintritt eines Zeitereignisses hier auszuführende Aktionen sind, eine Task zu aktivieren oder Zeitmarken an eine oder mehrere Tasks weiterzuleiten. Die zweite Zeitüberwachung wird z.B. für die Steuerung einer Nachlaufzeit, während der die Motorsteuerung nach Abschalten der Zündung noch Aufgaben (z.B. Fehlersuche) durchführen und deshalb mit Strom versorgt werden muß. Sie wird auch zum Steuern der Ansaugluft- und Kühlmittel-Temperaturmessung, der λ-Sondenheizung, der Erzeugung des Drosselklappen-Istwertsignals, der Kraftstoffpumpe und von vielem anderem eingesetzt.
  • Wesentlicher Bestandteil der zweiten Zeitüberwachung sind zwei Listen: eine Zeitauftragsliste 24, die frei definierbare Zeitereignisse enthält, und eine Adreßliste 24, die die Anfangsadressen der auszuführenden Aktionen, die den einzelnen Zeitaufträgen zugeordnet sind, aufnimmt (Figur 4). Wird ein Zeitauftrag erteilt, wird er in die Zeitauftragsliste 24 eingetragen. Ist der erteilte Zeitauftrag nicht der einzige in der Liste, werden die Aufträge nach den Ereigniszeitpunkten sortiert. Derjenige Zeitauftrag, dessen Ereigniszeitpunkt als nächster Auftritt, steht danach als erster in der Liste. Der Auftrag mit dem am weitesten in der Zukunft liegenden Zeit ist an der letzten Stelle in der Liste aufgeführt. Der Vorteil dieser zweiten Zeitüberwachung liegt in der geringen Bearbeitungsdauer. Bei jedem im Grundzeitraster auftretenden Zeitverwaltungsaufruf muß immer nur der erste Eintrag auf Ablauf abgefragt werden. Ist dessen Ereignis noch nicht eingetreten, d.h. die Zeit bis zum Ereignis noch nicht abgelaufen, so braucht die Liste 24 nicht weiter abgefragt werden.
  • Sind bereits mehrere Aufträge in der Liste 24 enthalten, so müßte, wenn ein neuer Auftrag erteilt wird und er wegen seiner Ereigniszeit nicht hinten an der Liste angefügt werden kann, zumindest ein Teil der Zeitauftragsliste umkopiert werden. Solche zeitraubenden Umkopieraktionen und die damit verbundene Prozessorbelastung werden aber hier durch sogenannte Linkverbindungen vermieden. Jeder Zeitauftrag in der Zeitauftragsliste 24 weist neben einem Zeitfeld 26 auch ein Linkfeld 27 auf, das die Verbindung zwischen den einzelnen Zeitaufträgen herstellt. Bei einem Sortiervorgang müssen im ungünstigsten Fall maximal drei Links - auch als Pointer oder Adreßzeiger bezeichnet - 28 behandelt werden. Der Anfang der Liste wird in einem sogenannten Listenanker 30 vermerkt, der die Anzahl der Listeneinträge (im Beispiel 5) und einen Verweis auf den ersten Zeitauftrag in der Liste (im Beispiel: Listenplatz 3) enthält.
  • Die Adreßliste 25 enthält in den einzelnen Listenplätzen die Adressen 32 der auszuführenden Aktionen, die dem jeweiligen Zeitereignis zugeordnet sind.
  • Die Verwaltung von Zeitaufträgen schließt drei Routinen ein:
    • 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.
  • Ist ein Zeitauftrag bereits erteilt worden und noch nicht abgelaufen, so wird der ursprüngliche Auftrag ignoriert, und das Ereignis auf die neue Zeit gesetzt.
  • Ein bereits erteilter Zeitauftrag kann mit einem Aufruf
    ZADEL [Listenplatz]
    annulliert werden; er wird dabei aus der Zeitauftragsliste entfernt.
  • Im Raster der Systemgrundzeit, d.h. in Intervallen von 10 ms, wird die Zeitauftragsliste nach abgelaufenen Zeitaufträgen durchsucht. Wird ein abgelaufener Zeitauftrag gefunden, d.h. ein Auftrag dessen Wartezeit abgelaufen ist, wird er aus der Liste entfernt und die mit ihm verbundenen Aktionen ausgeführt. Anschließend wird die Liste erneut nach einem weiteren abgelaufenen Zeitauftrag durchsucht. Der Vorgang wird solange wiederholt, bis kein abgelaufener Zeitauftrag in der Liste mehr vorhanden ist. Die hierzu durchgeführte zyklische Zeitüberwachungsroutine SUABZA ( = suche nach abgelaufenen Zeitaufträgen) ist in Figur 5 in Form eines Struktogramms 34 veranschaulicht.
  • Beim Einrichten eines neuen Zeitauftrags sind programmtechnisch folgende Schritte durchzuführen:
    In einem Datenmodul SYSDAT.A96, in dem der RAM-Speicher 16 beschrieben ist, ist eine Tabelle ZA_LIST_LA um die Anzahl der neu einzufügenden Zeitaufträge zu vergrößern. Dies ist durch eine Platzreservierung von 4 Bytes pro Zeitauftrag möglich. In einem Modul ZEITVERW.A96 ist für jeden Zeitauftrag eine EQU-Anweisung oder Zuordnungsanweisung des Listenplatzes vorhanden. Jedem neuem Zeitauftrag ist seine Listenplatznummer über eine EQU-Anweisung zuzuteilen. In einer Tabelle AKTIONS_TAB wird die Anfangsadresse des Programmabschnitts eingetragen, der bei dem Zeitereignis auszuführen ist. Der Platz an dem die Anfangsadresse hinterlegt wird, muß mit der Listenplatznummer übereinstimmen. Die Aktionen, die auszuführen sind, werden am Ende des Moduls definiert. Die Programmsequenz ist mit einem unbedingten Sprung auf das Label SUABZA abzuschließen.
  • Eine bei der Zeitauftragserteilung abzuwickelnde Routine SETIM ( = setze Zeitauftrag) ist in Figur 6 in Gestalt eines Struktogramms 35 dargestellt. Entsprechend ist die zum Löschen eines Zeitauftrags abzuarbeitende Routine deltim ( = setze Zeitauftrag) durch ein Struktogramm 36 in Figur 7 verdeutlicht. Die einzelnen Schritte dieser Struktogramme 22 und 34 bis 36 sind in Klartext niedergelegt, so daß die Struktogramme selbst erläuternd sind.

Claims (9)

  1. Motorsteuerung (1) mit einem Rechenteil (2), durch den Meßwerte, die Betriebsgrößen des Motors wiedergeben, programmgesteuert erfaßt und ausgewertet und Steuersignale für Stellglieder, die auf den Motorbetrieb einwirken, erzeugt werden, und mit einem die Erfassung und Auswertung und die Erzeugung von Steuersignalen steuernden Betriebssystem, unter welchem unterschiedliche Arten von Programmen zeitabhängig aktiviert werden,
    dadurch gekennzeichnet, daß durch das Betriebssystem eine Zeitverwaltung mit folgenden Zeitüberwachungen festgelegt ist:
    - eine erste Zeitüberwachung für Aufgaben, deren jeweilige Aktivierungszeit in kurzen Zeitabständen zu überprüfen ist, und
    - eine zweite Zeitüberwachung für Aufgaben, deren jeweilige Aktivierungszeit in langen Zeitabständen zu überprüfen ist.
  2. Motorsteuerung nach Anspruch 1, dadurch gekennzeichnet, daß durch die erste Zeitüberwachung Aufgaben verwaltet werden, deren Abarbeitung oder Aktivierung innerhalb einiger wenige Systemzeiteinheiten zu erfolgen hat, und durch die zweite Zeitüberwachung Aufgaben verwaltet werden, deren Abarbeitung oder Aktivierung eine größere Anzahl Systemzeiteinheiten dauert.
  3. Motorsteuerung nach Anspruch 1, dadurch gekennzeichnet, daß die Systemzeit in ein Raster mit einer Zeiteinheit von 10 ms unterteilt ist.
  4. Motorsteuerung nach Anspruch 1, dadurch gekennzeichnet, daß die erste Zeitüberwachung drei Tabellen einschließt:
    - eine Zeitauftragsliste (19),
    - eine Adressenliste für die auszuführenden Aktionen und
    - eine Tabelle der zyklischen Zeiten.
  5. Motorsteuerung nach Anspruch 4, dadurch gekennzeichnet, daß in der Zeitauftragsliste (19) jeder Zeitauftrag in einen Listenplatz (0,..., n) eingetragen wird, und daß der einzutragende Zeitauftrag eine Adresse, eine Statusinformation und einen Zeitpunkt, an dem die dem Zeitauftrag zugeordnete Aktion zu aktivieren ist, enthält.
  6. Motorsteuerung nach Anspruch 5, dadurch gekennzeichnet, daß der eingetragene Zeitpunkt bei jedem Programmdurchlauf mit dem Inhalt eines die aktuelle Systemzeit (AKZEIT) darstellenden Zählers verglichen und im Falle einer Übereinstimmung die dem Zeitauftrag zugeordneten Aktionen angestoßen werden.
  7. Motorsteuerung nach Anspruch 1, dadurch gekennzeichnet, daß die zweite Zeitüberwachung eine Zeitauftragsliste (24), in der die Zeitaufträge abgelegt sind, und eine Adreßliste (25) enthält, in der die Anfangsadressen der Aktionen abgelegt sind, die den einzelnen Zeitaufträgen zugeordnet sind.
  8. Motorsteuerung nach Anspruch 7, dadurch gekennzeichnet, daß die Zeitaufträge in der Zeitauftragsliste (24) in aufsteigender zeitlicher Reihenfolge angeordnet sind und daß diese Reihenfolge durch Links (Pointer), realisiert ist, die die Verbindungen zwischen den einzelnen Zeitaufträgen festlegen.
  9. Motorsteuerung nach Anspruch 7, dadurch gekennzeichnet, daß bei jedem im Systemzeitraster erfolgenden Aufruf durch die Zeitverwaltung jeweils nur der erste Auftrag in der Zeitauftragsliste (24) auf Ablauf abgefragt wird.
EP19930102978 1993-02-25 1993-02-25 Motorsteuerung Expired - Lifetime EP0612917B1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE59303660T DE59303660D1 (de) 1993-02-25 1993-02-25 Motorsteuerung
EP19930102978 EP0612917B1 (de) 1993-02-25 1993-02-25 Motorsteuerung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP19930102978 EP0612917B1 (de) 1993-02-25 1993-02-25 Motorsteuerung

Publications (2)

Publication Number Publication Date
EP0612917A1 true EP0612917A1 (de) 1994-08-31
EP0612917B1 EP0612917B1 (de) 1996-09-04

Family

ID=8212638

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19930102978 Expired - Lifetime EP0612917B1 (de) 1993-02-25 1993-02-25 Motorsteuerung

Country Status (2)

Country Link
EP (1) EP0612917B1 (de)
DE (1) DE59303660D1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0017219A2 (de) * 1979-04-06 1980-10-15 Hitachi, Ltd. Verfahren und Vorrichtung zur elektronischen Steuerung eines Motors
DE3826526A1 (de) * 1988-08-04 1990-02-08 Bosch Gmbh Robert Verfahren und vorrichtung zum einstellen von betriebsgroessen einer brennkraftmaschine

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0017219A2 (de) * 1979-04-06 1980-10-15 Hitachi, Ltd. Verfahren und Vorrichtung zur elektronischen Steuerung eines Motors
DE3826526A1 (de) * 1988-08-04 1990-02-08 Bosch Gmbh Robert Verfahren und vorrichtung zum einstellen von betriebsgroessen einer brennkraftmaschine

Also Published As

Publication number Publication date
DE59303660D1 (de) 1996-10-10
EP0612917B1 (de) 1996-09-04

Similar Documents

Publication Publication Date Title
EP1330685B1 (de) Prüfverfahren und prüfvorrichtung zur inbetriebnahme von mittels einer programmlogik gesteuerten systemen
DE102006028695B4 (de) Elektronisches Steuersystem mit Fehlfunktionsüberwachung
EP0759195B1 (de) Leitsystem für eine technische anlage
DE4410775C2 (de) Steuergerät und Arbeitsverfahren eines Betriebssystems für dieses Steuergerät
DE4125389C1 (de)
EP0525432A2 (de) Verfahren zur Änderung von Systemkonfigurationsdatensätzen in einem Fernmeldevermittlungssystem
DE2813574C2 (de) Elektronische Zündsteuervorrichtung für einen Verbrennungsmotor
DE3033526A1 (de) Elektronisches steuerverfahren fuer brennkraftmaschinen
DE10232875B4 (de) Verfahren und Steuereinheit zur Steuerung der Antriebseinheit eines Fahrzeugs
DE3513937A1 (de) Verfahren zur ueberwachung eines drehzahlgeber-signals
DE102019001129A1 (de) Numerische Steuervorrichtung
EP1300792A2 (de) Computergestützten Verfahren und Anordnung zur Überwachung einer Nutzung von Lizenzen
DE69406959T2 (de) Verfahren zur Verwaltung von Anwendungen mit Standardprotokollen
EP0799441B1 (de) Verfahren zur steuerung von technischen vorgängen
EP0525350B1 (de) Verfahren und Vorrichtung zur Prüfung von Steuergeräten
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
EP1005216A2 (de) Verfahren und Vorrichtung zur Validierung von Konfigurationsdaten für Telekommunikationssysteme
EP1514180A2 (de) Reaktionszeit-beschränkung eines software-prozesses
EP0303869A1 (de) Modular strukturiertes digitales Kommunikationssystem mit betriebstechnischen Kommunikationsmitteln
DE3318410A1 (de) Verfahren zur veraenderung und optimierung von daten und programmablaeufen fuer programmierte steuergeraete in kraftfahrzeugen
EP0612917B1 (de) Motorsteuerung
EP0990964A1 (de) Verfahren zum Betrieb eines Automatisierungssystems
EP0175162A2 (de) Elektronische Einrichtung zum Erzeugen eines Kraftstoffzumesssignals für eine Brennkraftmaschine
DE4428818B4 (de) Verfahren zur Einstellung einer serienmäßig hergestellten Brennkraftmaschaschine
DE19647407A1 (de) Steuergerät, insbesondere für den Einsatz in einem Kraftfahrzeug

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LI LU MC NL PT SE

17P Request for examination filed

Effective date: 19940915

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT

17Q First examination report despatched

Effective date: 19950516

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE FR GB IT

REF Corresponds to:

Ref document number: 59303660

Country of ref document: DE

Date of ref document: 19961010

ET Fr: translation filed
ITF It: translation for a ep patent filed
GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)

Effective date: 19961107

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed
REG Reference to a national code

Ref country code: GB

Ref legal event code: IF02

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20040205

Year of fee payment: 12

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES;WARNING: LAPSES OF ITALIAN PATENTS WITH EFFECTIVE DATE BEFORE 2007 MAY HAVE OCCURRED AT ANY TIME BEFORE 2007. THE CORRECT EFFECTIVE DATE MAY BE DIFFERENT FROM THE ONE RECORDED.

Effective date: 20050225

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20050225

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20050225

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20090219

Year of fee payment: 17

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20090213

Year of fee payment: 17

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20101029

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100301

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100901