DE60211703T2

DE60211703T2 - Verfahren und system zur zeitverwaltung in einem echtzeitsystem

Info

Publication number: DE60211703T2
Application number: DE60211703T
Authority: DE
Inventors: Francois Bossard
Original assignee: Centre National dEtudes Spatiales CNES
Current assignee: Centre National dEtudes Spatiales CNES
Priority date: 2001-03-12
Filing date: 2002-03-11
Publication date: 2007-05-10
Anticipated expiration: 2022-03-12
Also published as: ATE327535T1; FR2821940A1; WO2002077801A2; EP1410178A2; FR2821940B1; WO2002077801A3; EP1410178B1; DE60211703D1

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Zeitverwaltung in einem Echtzeitsystem.
Sie findet insbesondere, jedoch nicht ausschließlich bei jeglichem Echtzeitsystem Anwendung, das mitgeführt wird oder in einer automatischen Einrichtung integriert ist, dessen Funktion auf einer Software- und Hardwarearchitektur beruht, die mit einem Echtzeitbetriebssystem versehen ist.
Die meisten Echtzeitsysteme enthalten einen Rechner, mit dem Sensoren und Aktuatoren verbunden sind, welche die Schnittstelle zwischen dem Rechner und dem bzw. den zu steuernden physikalischen Prozessen bilden. Die Steuerung eines Prozesses wird über einen numerischen Algorithmus gewährleistet, welcher der Ausführung eines Softwareprogramms auf dem sogenannten "Anwenderniveau" durch den Rechner entspricht, welche die Bedürfnisse des Anwenders integriert. Ein komplexes Echtzeitsystem bewirkt die gleichzeitige Ausführung von mehreren Programmen, wobei ein Programm sich aus einer Folge von Operationen zusammensetzt, von denen bestimmte parallel ausgeführt werden können. Derartige Programme können im Falle eines kontinuierlichen physikalischen Prozesses periodisch sein oder auch nicht periodisch, wenn sie nach dem Auftreten von internen bzw. externen Ereignissen ausgelöst werden. Ferner kann ein komplexes System veranlasst werden, den Betriebsmodus nach dem Auftreten von normalen Ereignissen bzw. Zwischenfällen zu wechseln. Mit anderen Worten werden die von einem Echtzeitsystem ausgeführten Programme dazu gebracht, sich im Laufe der Zeit in Abhängigkeit von systeminternen bzw. -externen Zuständen zu ändern.
Es hat sich herausgestellt, dass Echtzeitsysteme aufgrund des Aufwands der auszuführenden Funktionen immer teurer in der Herstellung und immer schwieriger zu validieren sind.
Bei einem Echtzeitsystem ist es nämlich erforderlich, die Ausführung von verschiedenen Programmen zu planen und zu koordinieren. Insbesondere werden die Programme nach dem Auftreten von Ereignissen ausgelöst bzw. abgebrochen, die oftmals eine explizite Bindung mit dem laufenden Zeitpunkt bzw. mit dem Ablauf eines Zeitraums ab Auftreten einer Kombination von Ereignissen haben. Bei jedem periodischen Programm muss nach Beginn der ersten Iteration des Programms für das periodische Auslösen der weiteren Iterationen gesorgt werden. Bei der Ausführung eines Programms können einzuhaltende zeitliche Bedingungen in der Verknüpfung der Operationen des Programms bestehen, das dann diskontinuierlich ist. Ferner muss bei der Ausführung eines Programms im allgemeinen eine Fälligkeit eingehalten werden, die mit einer Ansprechzeit verbunden ist, die vom Benutzer als Leistungskriterium oder durch die Merkmale des zu steuernden physikalischen Prozesses vorgegeben wird. Ferner ist die Überwachung der Gesamtdauer eines Programms unentbehrlich, um Gewissheit über den korrekten Betrieb des Systems zu haben. Die vom System geforderte Reaktionsfrist auf eine Anomalie oder auf ein normales Ereignis ist bei kritischen Betriebsmodi oftmals sehr kurz, was erfordern kann, gleichzeitig auf den Verlauf von mehreren Programmen einzuwirken. Wenn eine zeitliche Anomalie während der Ausführung eines Programms schnell erfasst werden soll, muss angestrebt sein, Kontrollen über die dieses bildenden Operationen, meistens über die oberen Zeitdauergrenzen durchzuführen. Auch können Kontrollen über die unteren Zeitdauergrenzen angestrebt sein. Schließlich werden in bestimmten Fällen die Zeitpunkte des Auftretens von Ereignissen ab bestimmten Schritten im Ablauf des Systems vorhersagbar. Um die Robustheit des Systems zu erhöhen, können somit die effektiven Zeitpunkte des Auftretens dieser Ereignisse in offenen Zeitspannen liegen.
In einem Echtzeitsystem ist somit die Zeitverwaltung ausschlaggebend. Dazu bestehen Informatikkomponenten, die in Form von Mikroprozessoren oder Softwaremodulen einsatzfähig sind.
Diese Komponenten können in Form von zyklischen Echtzeitexekutiven vorliegen, die eine konstante Zeitbasis verwenden, die periodisch ein Hardwaresignal erzeugt, das eine Ablaufsteuerung durch eine Unterbrechungseinrichtung auslöst, wobei die Ablaufsteuerung die periodische Anwendung aufruft, welche in den Programmsteuerungstabellen definiert ist. Sämtliche von dem System angewendete Zeiten sind somit synchron mit dieser Zeitbasis. Derartige Echtzeitexekutiven verwenden nicht den Begriff der Aktivität der Programme, wobei das Starten bzw. Abbrechen eines Programms über eine Aktualisierung der Programmsteuerungstabellen erfolgt und die Taktung eines Programms dadurch erfolgt, dass die Anzahl von abgelaufenen Zyklen gezählt wird. Ein Betriebsmoduswechsel erfolgt dadurch, dass die Programmsteuerungstabellen geändert werden, wenn die Periode betroffen ist; sind dagegen die Algorithmen betroffen, muss das Programm eine den laufenden Betriebsmodus darstellende geteilte Variable prüfen, welche von einem anderen Programm aktualisiert werden konnte.
Periodische Exekutiven werden immer weniger benutzt, weil sie einen sehr starren Konzeptionsansatz synchroner Art vorgeben. Die wesentlichen Nachteile dieser Art von Exekutive liegen darin, dass dann, wenn eine feine zeitliche Auflösung erforderlich ist, das Quantum der Zeitbasis klein sein muss, wodurch der Prozessor in verbietender Weise mit Rechenzeit überlastet wird. Ferner erfolgt die Programmsteuerung der programminternen Operationen über eine Programmschleife, welche eine Zeitdauer simuliert. Ferner sieht diese Art von Exekutive weder eine zeitliche Überwachung noch eine Überwachung des Betriebsverhaltens der Operationen vor.
Weitere Komponenten können in Form von Echtzeitkernen vorliegen, bei denen Tasks die Grundelemente der Softwarearchitektur sind und der Konzeptionsansatz asynchroner Art ist. Bei einem solchen Echtzeitkern erfolgt die Verwaltung der Tasks (Aktivierung, Abbrechen) durch Aufruf von Primitivelementen des Echtzeitkerns.
Es stellt sich als schwierig heraus, eine anpassbare Anwendung zu konzipieren, um ein vorhersagbares Echtzeitverhalten der Programme zu erhalten. Eine klassische Lösung besteht darin, auf eine zyklische Exekutive zurückzugreifen, indem die periodischen Anwendungen auf eine dazu vorgesehene Zeitbasis synchronisiert werden.
Bei bestimmten Fällen kann der Kern eine Funktion bereitstellen, die dazu ausgelegt ist, periodische Ereignisse zu erzeugen, indem eine nicht veränderbare interne Zeitbasis zugrunde gelegt wird. Diese Lösung ist damit mit den gleichen Nachteilen der Überlastung des Prozessors behaftet, wie bei zyklischen Exekutiven. Hinsichtlich der Programmsteuerung der programminternen Operationen erfolgt die Synchronisierung auf Fristen durch Aufruf von Primitivelementen des Kerns. Hinsichtlich des dynamischen Betriebsmoduswechsels ist dann, wenn dieser Moduswechsel die Periode betrifft, es erforderlich, die Parameter neu zu berechnen, die für die Aufrufe der Zeitfunktionen bestimmt sind, die vom Kern bereitgestellt werden. Wenn er die Algorithmen ändert, muss das Programm auch eine geteilte Variable prüfen, die den laufenden Modus darstellt.
Die einzigen zeitlichen Überwachungen, die von dem Echtzeitkern vorgesehen sind, betreffen die Überwachungsfristen, welche mit den Primitivelementen einhergehen, welche die Durchführung eines Tasks aufschieben können. Ansonsten ist keine Beobachtung des Verhaltens im Betrieb vorgesehen, wobei die einzigen bestehenden Mittel nur in der Entwicklungsphase der Anwendung verwendbar sind.
In allgemeiner Weise bieten die Software- und Hardwarekomponenten aus dem Stand der Technik nur grundlegende Dienste an. Ferner haben sie einen großen Spielraum im funktionellen Bereich und liegen auf einem sehr detaillierten funktionellen Niveau, so dass sie Anwendungsfehler hervorrufen können. Sie erfordern somit das Eingreifen eines Fachmanns für Echtzeit. Ferner ist die Konzeption eines Systems ausgehend von derartigen Komponenten mit einer mangelnden Vereinheitlichung behaftet und variiert zum Nachsehen eines jeden Fachmanns für Echtzeit.
Die US 5 902 352 beschreibt eine Komponente zur Verarbeitung von Tasks bei einem Nichtechtzeitsystem, das bei Fälligkeit von Zählern Programme starten kann. Die EP 0 362 903 beschreibt eine Einrichtung zur Verwaltung von Ereignissen bei einer Nichtechtzeitumgebung und einen speziell ausgelegten Prozessor, der die Ausführung der Tasks steuert, indem er die Zuweisung von Verarbeitungsressourcen zu den verschiedenen Tasks in Abhängigkeit von den den Tasks zugewiesenen Prioritäten und von Ablaufinformationen und Ereignissen steuert.
Die vorliegende Erfindung zielt darauf ab, die vorangehend genannten Nachteile zu beseitigen. Dieses Ziel wird dadurch erreicht, dass ein Verfahren zur Zeitverwaltung in einem Echtzeitsystem vorgesehen ist, bei dem Anwenderprogramme ausgeführt werden und mit Hilfe von einem Zeitverwaltungssystem übertragenen Befehlen miteinander kommunizieren, wobei die von den Anwenderprogrammen dem Zeitverwaltungssystem übertragenen Befehle Befehle zum Aktivieren eines Anwenderprogramms zu einem bestimmten Aktivierungszeitpunkt enthalten, wobei das Zeitverwaltungssystem bei jedem empfangenen Aktivierungsbefehl die folgenden Schritte ausführt:

– Berücksichtigen des Befehls zum Aktivieren eines Anwenderprogramms,
– Zuordnen eines Aktivierungsereignisses zum Befehl, welchem Ereignis zumindest ein Ereignisfälligkeitszeitpunkt zugewiesen ist, der dem Zeitpunkt zum Aktivieren des Anwenderprogramms entspricht, und Einfügen des Ereignisses in Verbindung mit seinem Fälligkeitszeitpunkt in eine Liste zu verarbeitender Ereignisse,
– Bestimmen des nächstfolgenden Ereignisses aus der Ereignisliste, das in Abhängigkeit von den jeweiligen Fälligkeitszeitpunkten der Ereignisse aus der Liste zu verarbeiten ist, und Aktivieren eines Zählers, damit dieser am Fälligkeitszeitpunkt des nächstfolgenden zu verarbeitenden Ereignisses auslöst, und
– bei Auslösen des Zählers Aktivieren des dem nächstfolgenden zu verarbeitenden Ereignis zugeordneten Anwenderprogramms.

Erfindungsgemäß umfasst jedes Anwenderprogramm zumindest einen Aufruf eines Aktivierungsrückstellbefehls, der das Programm über das Zeitverwaltungssystem in einen Aktivierungsrückstellzustand bringt, wobei das Anwenderprogramm, wenn es in einem normalen Betriebsmodus aktiviert wurde, normale Operationen durchführt, bevor es erneut den Aktivierungsrückstellbefehl aufruft.
Vorteilhaft enthalten die Anwenderprogramme eine Anwendungsendlosschleife, in welche ein Aktivierungsrückstellbefehl eingefügt ist.
Vorzugsweise ist einem Aktivierungsbefehl für eine Anwendung in Aktivierungserwartung ein Phasenparameter zugeordnet, der den Zeitraum zwischen Zeitpunkt für die Aktivierung der Anwendung und einem Bezugszeitpunkt definiert.
Nach einer Besonderheit der Erfindung umfasst dieses Verfahren bei Aktivierung einer Anwendung in Aktivierungserwartung die Übertragung eines Zustandsparameters zur zu aktivierenden Anwendung, der auf einem Normalwert liegt, um der Anwendung zu melden, dass sie normale Operationen durchführen soll, oder auf einem Endwert, um der Anwendung zu melden, dass sie sich beenden soll.
Gemäß einer weiteren Besonderheit der Erfindung umfasst dieses Verfahren die Bereitstellung eines Zeitgebers für einen laufenden Zeitraum mit begrenzter Dynamik, die Definition eines Referenzzeitpunkts über ein Anwenderprogramm und die Aktualisierung des Referenzzeitpunkts zu jedem Zeitraum der ersten periodischen Anwendung, die der genannten Definition des Referenzzeitpunkts folgend aktiviert wird.
Vorzugsweise ist zum Aktivieren einer periodischen Anwendung in Aktivierungserwartung dem Aktivierungsbefehl ein Zeitraumparameter zugeordnet, der einen Aktivierungszeitraum für die Anwendung definiert, und bei Aktivierung einer periodischen Anwendung fügt das Zeitverwaltungssystem in die Liste der zu verarbeitenden Ereignisse ein Aktivierungsereignis ein, das einem Aktivierungszeitpunkt zugeordnet ist, der dem laufenden Zeitraum entspricht, dem der Zeitraum der Anwendung hinzugefügt ist.
Vorteilhaft ist dem Aktivierungsbefehl für eine Anwendung ein Fälligkeitsparameter zugeordnet, der eine maximale Zeitdauer zum Durchführen einer Anwendung definiert, und das Zeitverwaltungssystem überwacht, ob die Durchführung der Anwendung während dieser Zeitdauer erfolgt.
Gemäß einer Ausführungsform der Erfindung führt zum Überwachen der Zeitdauer zum Durchführen einer Anwendung das Zeitverwaltungssystem Schritte aus, die darin bestehen,

– bei Aktivierung einer Anwendung in eine Liste zu verarbeitender Ereignisse ein Fälligkeitsereignis zum Beenden der Anwendung einzufügen, dem ein Zeitpunkt zugeordnet ist, der dem laufenden Zeitraum entspricht, dem die Fälligkeit der Anwendung hinzugefügt ist,
– bei Beendigung der Durchführung der Anwendung, und zwar bevor das entsprechende Fälligkeitsereignis zur Anwendung gelangt, das Fälligkeitsereignis zum Beenden der Anwendung von der Liste der zu verarbeitenden Ereignisse zurückzunehmen,
– bei Auftreten des Fälligkeitsereignisses zum Beenden der Anwendung eine Fälligkeitsüberschreitungsmeldung zu einem Supervisor-Programm zu übertragen.

Vorteilhaft überwacht das Zeitverwaltungssystem dann, wenn eine gerade erfolgende Anwendung vor Ablauf ihrer maximalen Durchführungsdauer aktiviert wird, ob die Durchführung der Anwendung während einer Zeitdauer gleich der n-fachen maximalen Zeitdauer der Durchführung der genannten Anwendung ab dem Zeitpunkt der ersten Durchführung der genannten Anwendung erfolgt, wobei n die Anzahl von Aktivierungen der genannten Anwendung ist, die aufeinanderfolgend durchgeführt werden.
Gemäß einer weiteren Ausführungsform der Erfindung umfasst dieses Verfahren für jede Anwendung die Registrierung sämtlicher Tätigkeiten des Zeitverwaltungssystems in einer Aufstellung datierter Beobachtungen, um die Anwendung in Aktivierungserwartung zu versetzen oder sie aus einer Aktivierungserwartung herauszunehmen.
Vorteilhaft wird die Registrierung der Beobachtungsaufstellungen über eine Quellcode-Kompilierungsregel bei der Systementwicklung aktiviert.
Gemäß einer weiteren Ausführungsform der Erfindung umfasst dieses Verfahren ferner die Anweisung eines Supervisor-Programms bei dem Zeitverwaltungssystem und die unmittelbare oder verzögerte Berücksichtigung von Ereignissen durch das Supervisor-Programm, die von den weiteren Anwendungen erstellt werden, wobei das Supervisor-Programm dazu über das Zeitverwaltungssystem aktiviert wird.
Vorzugsweise umfasst es die Zustellung eines Ereignisses zu dem Supervisor-Programm über eine Anwendung, wobei dieser Zustellung eine maximale Frist bis zur nächsten Zustellung eines weiteren Ereignisses zugeordnet ist, die über die gleiche Anwendung nach einer Folge von Anweisungen erfolgt ist, deren Ausführung zu überwachen ist, sowie das Ausgeben einer Teilfälligkeitsüberschreitungsmeldung von dem Zeitverwaltungssystem zum Supervisor-Programm, wenn die Ausführung der Folge von Anweisungen nicht in der maximalen Frist erfolgt ist.
Vorzugsweise überwacht das Zeitverwaltungssystem die Zeitdauer, welche das Supervisor-Programm braucht, um ein Ereignis oder eine Fehlermeldung zu verarbeiten, wobei es im Falle des Überschreitens einer maximalen Frist ein Notprogramm aufruft.
Gemäß einer weiteren Ausführungsform der Erfindung umfasst dieses Verfahren ferner einen Schritt zum Wechseln des getakteten Betriebsmodus, der das Blockieren der Aktivierung der von dem Moduswechsel betroffenen Anwendungen und die Aktivierung dieser Anwendungen mit Zeitparametern umfasst, die dem neuen Betriebsmodus entsprechen, sowie mit einem Modusparameter, um den Anwendungen anzugeben, in welchem Modus sie arbeiten sollen.
Die Erfindung betrifft auch ein Echtzeitsystem mit Anwenderprogrammen, einer Verarbeitungseinheit, einem Echtzeitbetriebssystem, einem Echtzeit-Zeitgeber und einem Zeitverwaltungssystem, das Einrichtungen zum Aktivieren und Deaktivieren der Anwenderprogramme zu bestimmten Zeitpunkten und zum Überwachen der Ausführung derselben zusammenfügt, wobei diese Einrichtungen in einer von der Verarbeitungseinheit, vom Betriebssystem und von dem Zeitgeber unabhängigen Art und Weise ausgeführt sind.
Erfindungsgemäß umfasst jedes Anwenderprogramm zumindest einen Aufruf eines Aktivierungsrückstellbefehls, der die Anwendung in einen inaktiven Zustand bringt, in dem sie in Erwartung einer Aktivierung durch das Zeitverwaltungssystem ist, wobei jedes Anwenderprogramm ferner zumindest einen aktiven Zustand aufweist, in dem es normale Operationen ausführt, bevor es erneut den Aktivierungsrückstellbefehl aufruft, sowie einen Beendigungszustand, in dem es Beendigungsoperationen ausführt, bevor es sich selbst beendet.
Gemäß einer Ausführungsform der Erfindung enthält dieses Echtzeitsystem eine Schnittstelle zwischen den Anwenderprogrammen und dem Zeitverwaltungssystem, wobei diese Schnittstelle Zeitverwaltungsfunktionen vereint, die von den Anwenderprogrammen aufgerufen werden.
Vorteilhaft enthält die Schnittstelle zwischen den Anwenderprogrammen und dem Zeitverwaltungssystem eine Aktivierungsrückstellfunktion, über welche die Anwendung, welche diese aufruft, in den inaktiven Zustand gebracht wird, sowie eine Auslösefunktion für eine Anwendung, um die Ausführung einer Anwendung im inaktiven Zustand auszulösen.
Vorzugsweise nimmt die Funktion zum Auslösen einer Anwendung als Eingangsparameter einen Parameter an, welcher den Zeitpunkt angibt, an dem die Ausführung der Anwendung ausgelöst werden soll, einen Zeitdauerparameter, der eine Ausführungszeitdauer angibt, wenn die Anwendung periodisch ist, einen Fälligkeitsparameter, der die maximale Zeitdauer der Ausführung der Anwendung bestimmt, einen Zustandsparameter, der angibt, ob die Anwendung normal ausgeführt oder beendet werden soll, und einen Modusparameter, der die Ausführung bzw. Beendigung der Anwendung kennzeichnet.
Gemäß einer weiteren Ausführungsform der Erfindung enthält die Schnittstelle zwischen den Anwenderprogrammen und dem Zeitverwaltungssystem eine Funktion zum Einfrieren der Anwendung, um die Aktivierung einer Anwendung in Aktivierungserwartung zu verhindern oder die Rückkehr einer Anwendung in den inaktiven Zustand zu melden, wenn diese nicht in Aktivierungserwartung ist.
Gemäß einer Ausführungsform der Erfindung sind sämtliche Zugänge zu den Funktionen des Betriebssystems und des Zeitgebers, die für das Zeitverwaltungssystem erforderlich sind, in Schnittstellen zusammengestellt, die in Abhängigkeit von dem Betriebssystem, der Verarbeitungseinheit und dem Zeitgeber ausgeführt sind.
Gemäß einer noch weiteren Ausführungsform der Erfindung enthält dieses System ferner einen Wächter, um die Ausführung der von dem Zeitverwaltungssystem durchgeführten Operationen zu überwachen, dessen Aktualisierung auf Kommando eines Zählers getaktet ist, der dazu bestimmt ist, das nächstfolgende zu verarbeitende Ereignis auszulösen.
Nachfolgend wird eine bevorzugte Ausführungsform der Erfindung beispielhaft und nicht einschränkend anhand der beigefügten Zeichnungen beschrieben, worin zeigt:
1 die generelle Architektur eines Systems, bei dem das erfindungsgemäße Echtzeitverwaltungssystem Verwendung findet,
2 die Verknüpfung der verschiedenen Zustände einer periodischen Anwendung nach der Erfindung,
3 bis 6 verschiedene Verwendungen des erfindungsgemäßen Verwaltungssystems, und
7 die Verknüpfung verschiedener Anwendungen durch das erfindungsgemäße Echtzeitverwaltungssystem in Form von Ablaufdiagrammen.
In 1 besteht das erfindungsgemäße System aus Software- und Hardwarekomponenten, die in drei Ebenen verteilt sind. Die obere Ebene enthält die Echtzeitanwendung 2, welche die von dem Benutzer bestimmten Funktionen ausführt, die Zwischenebene enthält ein erfindungsgemäßes Zeitverwaltungssystem 1, welches der Benutzeranwendung die Dienste bietet, die sie zum Verwalten der Zeit braucht, wobei diese Dienste in einer Benutzerschnittstelle 6 zusammengestellt sind und auf dem System 1 interne Einrichtungen 3 zurückgreifen.
Sämtliche Hardware- und Softwareressourcen niedrigen Niveaus, d. h. der Rechner 10, befinden sich in der unteren Ebene, welche Hardwareressourcen 12 enthält, die insbesondere eine Verarbeitungseinheit, ein Betriebssystem 11 für die Verarbeitungseinheit, das beispielsweise aus einem Echtzeitkern bzw. einer Echtzeitexekutive besteht, und eine Zeitgeber-Funktion 13 enthalten.
Das Betriebssystem 11 bietet Dienste niedrigen Niveaus und insbesondere Taktungseinrichtungen und eine Einrichtung zum Aufteilen der Hardwareressourcen zwischen den verschiedenen Programmen, die geläufig "Prozessverwalter bzw. Scheduler" genannt wird.
Um das Zeitverwaltungssystem 1 auf andere Hardware-Konfigurationen übertragbar und für andere Anwendungen verwendbar zu machen, ist es vorzugsweise gattungsgemäß ausgeführt, d. h. auf eine von den Hardware- und Softwareressourcen niedrigen Niveaus unabhängigen Weise, die von der Anwendung 2 verwendet werden. Dazu greift es auf eine Schnittstelle 7 mit dem Echtzeitkern 11 zurück, der sämtliche Dienste niedrigen Niveaus zusammenstellt, die von dem Zeitverwaltungssystem 1 aufgerufen werden, insbesondere um die in der Schnittstelle 6 zusammengestellten Benutzerdienste auszuführen. Es greift auch auf eine Schnittstelle 8 mit der Hardware zurück, wobei diese Schnittstelle sämtliche Dienste zusammenstellt, die von der Verarbeitungseinheit 12 geleistet werden und von dem Zeitverwaltungssystem 1 aufgerufen werden, sowie auf eine Schnittstelle 9 mit dem Zeitgeber 13.
Sämtliche Anwenderprogramme 2, von denen die Ausführungsauslöse- und Abbrechvorgänge verwaltet werden sollen, sind in einer Tabelle 5 definiert, die deren jeweilige Bezeichnungen bzw. Identifikatoren zusammenfügen. Jedes Programm besitzt damit einen einzigen Identifikator, der von dem Benutzer in statischer Weise in der Verarbeitungstabelle 5 definiert ist, die durch die verschiedenen Ebenen der Systemarchitektur unterteilt ist. Auf diese Weise kann jedes Programm zugleich von dem Zeitverwaltungssystem 1 und von der Anwendung 2 erkannt werden. Die Verarbeitungstabelle 5 ermöglicht es dem Benutzer, ein eigenes Bezeichnungssystem anstatt der dem Echtzeitkern 11 eigenen Identifikatoren zu verwenden, wodurch Verwechselungen vermieden werden. Andererseits ermöglicht es diese Tabelle, die Programme bzw. Tasks in Klassen und Unterklassen nach ihren Eigenschaften zusammenzufassen. Somit kann beispielsweise die Klasse der Benutzer des Zeitverwaltungssystems definiert werden.
Ebenso sind sämtliche zwischen den verschiedenen Anwenderprogrammen 2 zirkulierenden Ereignisse in einer Tabelle 4 definiert, die deren jeweilige Bezeichnungen bzw. Identifikatoren zusammenstellen.
Man unterscheidet zwischen Ereignissen, die mit der Beobachtung des Verlaufs der Programme verbunden sind, Ereignissen, die mit zeitlichen Durchführungsbedingungen verbunden sind, und Ereignissen, die rein anwendermäßig und vom Benutzer eingeführt sind.
Dennoch sind allen diesen Ereignissen, die vom Benutzer definiert sind, Programme zugeordnet.
Die Beobachtungsereignisse stellen die verschiedenen entscheidenden Übergänge im Verlauf der Programme dar. Obgleich die Ereignisse vom Benutzer definiert sind, gewährleistet das Zeitverwaltungssystem 1 das Auftreten dieser Ereignisse und deren Registrierung in Beobachtungsaufstellungen. Die Rolle dieser Ereignisse besteht darin, das dynamische Verhalten der Programme sowie die Aktivierungsanforderungen aufzuzeichnen.
Bestimmte zeitliche Ereignisse können die Fälligkeitsüberschreitung für die Programme kennzeichnen, weitere können die Überschreitung einer Frist für das Einleiten eines Schrittes bei einem Programm kennzeichnen. Im Rahmen der Möglichkeiten des Systems steht es dem Benutzer frei, so viele Ereignisse zu definieren, wie er wünscht und somit über zeitliche Überwachungspunkte bei seiner Anwendung zu verfügen.
Das Auftreten eines Ereignisses dieser Art führt zu einer Registrierung in der Aufstellung der Beobachtungen zum Programm und kann gegebenenfalls zu einer Zustellung des Ereignisses zu einem Supervisor-Programm, sofern vorhanden, führen.
Neben den mit zeitlichen Aspekten verbundenen Ereignissen kann der Benutzer die Ereignisse in einer Weise definieren, die unabhängig von jeglicher zeitlicher Betrachtung ist. Er kann nämlich bei einer Anwendung entscheiden, vom Zeitverwaltungssystem 1 zu fordern, ein derartiges Ereignis aufzunehmen. Neben der Registrierung des Ereignisses in der Aufstellung der Beobachtungen zu dem Ereignis, das Urheber dieser Anforderung ist, kann das Ereignis einem Supervisor-Programm zugestellt werden, damit dieses die geeigneten Operationen durchführen kann.
Somit ist es erforderlich, dass der Benutzer im Rahmen einer Struktur die verschiedenen Ereignisse definiert, welche zwischen den Programmen verkehren können oder die vom Zeitverwaltungssystem selbst direkt einem spezifischen Programm zugestellt werden.
In allgemeiner Weise werden zwei Kategorien von Ereignissen unterschieden:

– unkritische Ereignisse, die Zustellungsereignisse genannt und dazu genutzt werden, den Übergang zu für den Benutzer entscheidenden Schritten mitzuteilen und die zu einem Supervisor-Programm, sofern vorhanden, übertragen werden, und
– kritische Ereignisse, die auch Hauptereignisse genannt werden und die definierten und als solche vom Benutzer gemeldeten Ereignisse zusammenfassen, und Ereignisse, die mit von dem System 1 erfassten Zeitfehlern verbunden sind.

Das Überwachen der kritischen Ereignisse erfordert, vom Benutzer geführt zu werden, sobald diese bei Ausführen eines Programms auftreten. Eine derartige Überwachung macht somit eine schnelle Berücksichtigung derartiger Ereignisse erforderlich.
Obgleich die diesen beiden Kategorien von Ereignissen zugeordneten Einrichtungen sich voneinander unterscheiden, besteht bei der allgemeinen Kennzeichnung der Ereignisse kein Unterschied. Es wird nämlich jedes Ereignis mit einem einzigen Identifikator dargestellt, der vom Benutzer in der Ereignistabelle 4 definiert ist.
In jedem Fall gibt das Auftreten solcher Ereignisse Anlass zu einer Registrierung in den Beobachtungsaufstellungen der betreffenden Programme.
Dazu enthält die Zwischenebene auch ein Ereignisregistrierungsmodul 14, das dem Zeitverwaltungssystem 1 Registrierungs- und Beobachtungsdienste liefert, die in einer Registrierschnittstelle 15 zusammengefasst sind.
Das Zeitverwaltungssystem ist dazu ausgelegt, zwei Kategorien von Programmen zu berücksichtigen, nämlich periodische bzw. nicht periodische Anwenderprogramme, und die sogenannten Supervisor-Programme, deren einziger Zweck darin besteht, das Auslösen der Anwenderprogramme und/oder die Berücksichtigung von Ausführungsereignissen zu gewährleisten.
Jedem Programm ist zum Zeitpunkt seiner Auslösung eine Phase und, falls periodisch, eine Periode zugeordnet.
Die Phase eines Programms entspricht der Zeit, die einen Referenzzeitpunkt und von einer Programmaktivierungsanforderung durch das Zeitverwaltungssystem an das Betriebssystem trennt. Sie ermöglicht es, in zeitlich deterministischer Weise die Aktivierungsanforderungen eines jeden Programms bezüglich dieser Referenzzeit zu verteilen.
Die Periode zum Ausführen eines periodischen Programms ist die Zeit in einer Einheit, die vom Zeitverwaltungssystem definiert ist und zwei Iterationen (zwei Aktivierungsanforderungen) des Programms trennt.
Für periodische Programme wird auch eine Fälligkeit definiert, die der maximalen Zeit entspricht, die einem Programm zugewiesen ist, um seit seiner Aktivierungsanforderung durch das System 1 abzulaufen. Im Falle, dass ein laufendes Programm nicht in seiner offenen Fälligkeit seine Beendigung erreicht hat, empfängt ein "Supervisor" genanntes Programm eine Fälligkeitsüberschreitungsmeldung.
In allgemeiner Weise müssen die bei Anforderung von Diensten des Zeitverwaltungssystems 1 abgefragten Zeitparameter (Phase, Periode, usw.) in einer sogenannten "Benutzereinheit" ausgedrückt werden, die willkürlich definiert wird, beispielsweise in Millisekunden (ms). Die Informationen über die absolute Zeit oder dem Zeitpunkt werden in der Einheit des Bord-Zeitgebers ausgedrückt und hängen damit mit der Implementierung zusammen.
Die vom System intern benutzte Zeiteinheit kann sich von der Benutzereinheit unterscheiden und bleibt nahe der Zeiteinheit, die von der externen physikalischen Zeitquelle verwendet wird. Die Größenordnung dieser Einheit ist die Mikrosekunde (μs).
Ferner können die Programme weitere komplementäre Merkmale aufweisen, jedoch sind diese entweder spezifischen Funktionalitäten oder der Art und Weise zugeordnet, wie das Zeitverwaltungssystem 1 implementiert ist. Es handelt sich beispielsweise um Informationen, die mit dem Überwachen des Programmablaufs zusammenhängen.
Ein Anwenderprogramm ist mit einer Einheit von Zuständen und Übergängen zwischen diesen Zuständen gekennzeichnet. Wie in 2 dargestellt ist, sind die Zustände eines Programms folgende:

– Initialisierung 22,
– unaktiv 23,
– aktiv 24, und
– Beendigung 25.

Zu jedem Zeitpunkt ist ein Anwenderprogramm mit ein und dem gleichen dieser Zustände gekennzeichnet. Das Zeitverwaltungssystem 1 zielt darauf ab, auf Anforderung des Benutzers Übergänge zwischen diesen verschiedenen Zuständen auszuführen.
Diese Übergänge kommen nach dem Auftreten von Zeitereignissen vor, die vom System erfasst wurden, oder nach dem Auftreten von Anwenderereignissen, die vom Benutzer definiert und eingeleitet werden.
Die periodischen Programme müssen jeweils in einer Endlosschleife 21 gekapselt werden, in welcher das Ausführen jeder Iteration einem Wartevorgang im inaktiven Zustand 23 zum Auslösen durch das Zeitverwaltungssystem 1 unterliegt (2).
Diese Verarbeitungsstruktur ist auch im Falle eines nicht periodischen Programms vorzuziehen. Ferner ist sie unabdingbar, damit der Zeitverwaltungsdienst 1 die Fälligkeit der Verarbeitung überwachen kann.
In allgemeiner Weise enthalten die Dienste der Anwenderschnittstelle 6, die von dem Zeitverwaltungssystem 1 angeboten werden, folgende Funktionen:

– Funktionen zum Steuern des Zeitverwaltungssystems 1,
– Funktionen zum Verwalten der periodischen und nicht periodischen Programme und
– Funktionen zum zeitlichen Verfolgen der Programme und zum Verwalten von eventuellen Fehlern.

Das Zeitverwaltungssystem muss auf Initiative des Benutzers hin aktiviert und abgebrochen werden können. Die Systemsteuerung enthält somit die beiden folgenden Funktionen:

– "Dienst_initialisieren" und
– "Dienst_abbrechen".

Die Funktion "Dienst_initialisieren" hat den Zweck, die internen Strukturen und Zeitkontrolleinrichtungen des Systems 1 zu initialisieren, d. h. eine bestimmte Anzahl von Funktionsmerkmalen des Systems 1 und Beschreibungsmerkmalen des allgemeinen Ausführungskontextes des Systems zu definieren.
Diese Merkmale hängen mit der Hardware- und Softwareimplementierung der Zielplattform (Mikroprozessor, Betriebssystem, usw.) und der Anwendung 2 zusammen. Unter diesen Merkmalen ist allgemein die maximale Anzahl an von dem System geführten Programmen, die verwendeten Zeiteinheiten sowie die zeitliche Auflösung und Präzision zu nennen. Weitere Merkmale sind genauer mit dem Implementierungskontext verbunden, d. h. rühren beispielsweise vom Typ von Mikroprozessor des Rechners oder des Betriebssystems her.
Die Spezifikation der Initialisierungsfunktion ist bei sämtlichen Implementierungen des Systems Standard. Daraus ergibt sich, dass die Definition der verschiedenen Merkmale des Systems in statischer Weise bei der Implementierung desselben erfolgt.
Mit Aufrufen dieser Funktion wird ein Fehlercode zurückgeführt, "OK" im Falle, dass die Funktion erfolgreich ausgeführt wurde, oder aber "Dienst_bereits_aktiv" falls das System 1 bereits initialisiert wurde.
Die Funktion "Dienst_abbrechen" ermöglicht es, die Aktivität des Systems unter der Bedingung zu beenden, dass die gesamten Anwendungen, die diesem übertragen wurden, beendet sind. Der Benutzer hat somit die Aufgabe, die Anwendungen abzubrechen, mit deren Führung das System 1 betraut wurde, bevor der Aufruf dieser Funktion durchgeführt wird.
Der Aufruf dieser Funktion führt dann einen Fehlercode "OK" zurück, wenn das Abbrechen des Systems 1 erfolgreich durchgeführt wurde, oder aber "Programm_noch_aktiv", wenn das System beim Aufruf erfasst, dass zumindest eine Anwendung nicht beendet wurde, oder auch "Dienst_nicht_aktiv", wenn das Zeitverwaltungssystem 1 nicht zuvor aktiviert wurde.
Die Verwaltung der periodischen und nicht periodischen Anwendungen enthält die folgenden Funktionen:

– "Auslösung_akzeptieren",
– "Referenzzeit_definieren",
– "Anwendung_auslösen",
– "Zeitpunkt_Anwendung_auslösen",
– "Anwendung_aufschieben",
– "Zeitpunkt_Anwendung_aufschieben",
– "Anwendung_einfrieren",
– "Anwendung_beenden",
– "Zusatzprogramm_auslösen", und
– "Zeitpunkt_Zusatzprogramm_auslösen".

Die Funktion "Auslösung_akzeptieren" führt zur Übernahme der Aktivierung einer periodischen oder nicht periodischen Anwendung durch das System. Der Aufruf dieser Funktion bewirkt das Blockieren der Anwendung am Ursprung der Anforderung, die dann in den inaktiven Zustand 23 (2) übergeht, bis das System 1 die dieses betreffende Aktivierungsanforderung an den Echtzeitkern stellt. Sobald ein weiteres Programm das System 1 über seine Aktivierungsparameter, Phase, Periode, usw. informiert hat, übernimmt das System 1 die Aktivierung des Programms und gibt es von seinem Wartezustand zu entsprechenden Zeitpunkten frei. Diese Freigabe geht mit einem Ereignis einher, das dem Programm übertragen wird und seinen Ausführungsmodus angibt: Entweder führt es seine perdiodische Anwendung normal durch (Übergang zum aktiven Zustand 24), oder es tritt aus der Schleife aus und führt eine Beendigungssequenz (Übergang zum Beendigungszustand 25) durch, falls eine solche Anforderung zuvor über eine andere Anwendung durchgeführt wurde.
Nach einer Initialisierungsphase (siehe 2) wird von der periodischen Anwendung und von den meisten nicht periodischen Anwendungen die Funktion "Auslösen_akzeptieren" verwendet, um sich in Auslöseerwartung zu versetzen.
Vor jeglicher Auslöseanforderung muss zumindest ein Programm der Anwendung 2 die Referenzzeit definieren, die vom System verwendet wird, um die Aktivierungsanforderungen für die verschiedenen Programme zeitlich in Phase zu bringen.
Das Zeitverwaltungssystem 1 weckt sich selbst, wenn der Auslösezeitpunkt erreicht ist, und aktualisiert seine Weckinformationen. Es bringt dann bei der Echtzeitexekutive eine Aktivierungsanforderung für die betreffenden Anwendungen vor. Die effektive Aktivierung der periodischen Anwendung, d. h. das Ende ihres Wartens auf den Aufruf der Funktion "Auslösung_akzeptieren" und die Weiterführung ihrer Aktivität hängen mit der Ablaufplanung zusammen, die von der Echtzeitausführung angewendet wird. Die Kumulation von Auslösungsanforderungen wird in dem Maße zugelassen, wie dies von der Implementierung akzeptiert wird. Ist die Kumulationsschwelle erreicht, wird dem Supervisor ein Fehler gemeldet.
Nachdem die betreffende Anwendung vom Prozessverwalter der Exekutive aktiviert wurde, tritt dieser von dem Aufruf "Auslösung_akzeptieren" zurück (Übergang vom inaktiven Zustand 23 zum aktiven Zustand 24 oder zum Beendigungszustand 25) und wird ausgeführt (Zustand 24), bevor er in die Wartestellung (Zustand 23) zurückkehrt, indem erneut die Funktion "Auslösung_akzeptieren" aufgerufen wird, oder aber endet, indem er seinen Beendigungsanweisungen im Zustand 25 folgt.
Im Falle einer periodischen Aktivierung wird vom System 1 eine erneute Auslösung programmiert, um zu Beginn der nächsten Periode zu erfolgen.
Der für diese Anwendung angeforderte Zustand wird in Form eines Ereignisses durch Aufruf der Funktion zurückgeführt, das als Wert einen der Identifikatoren annimmt, die in der Ereignistabelle 4 für die Erfordernisse der Auslösung abgelegt sind.
Die von dieser Funktion verwendeten Ereignisidentifikatoren sind beispielsweise folgende:

– "Normales_Ende", wenn eine Abbrechanforderung von einer weiteren Anwendung beim System 1 erfolgt ist,
– "Anormales_Ende", wenn eine Abbrechanforderung auf eine Anomalie hin von einer weiteren Anwendung beim System 1 erfolgt ist; die Anwendung muss dann mit einer spezifischen Sequenz enden,
– "Normal", wenn eine Aktivierungsanforderung von einer weiteren Anwendung erfolgt ist, um in einen sogenannten "Normal"-Modus zu gelangen, und
– "Rekonfiguration", wenn eine Aktivierungsanforderung von einer weiteren Anwendung erfolgt ist, um in einen Rekonfigurationsmodus zu gelangen.

Die Funktion führt auch einen Fehlercode zurück, der als Wert "OK" annehmen kann, um anzugeben, dass die Anwendung aktiviert wurde und seine Durchführung fortgesetzt werden kann, oder aber "Dienst_nicht_aktiv", um darauf hinzuweisen, dass das Zeitverwaltungssystem 1 nicht zuvor aktiviert wurde.
Bei der Programmierung fügt sich der Aufruf der Funktion "Auslösen_akzeptieren" in folgendes Modell ein:
Die Funktion "Referenzzeit_Definieren" ermöglicht es, den ursprünglichen Referenzzeitpunkt zu definieren, der für die Auslösevorgänge der Anwendungen (Aktivierungsanforderungen) verwendet wird, mit welchen das System betraut ist. Dieser Zeitpunkt, der in der Bord-Zeitgeber-Einheit 13 ausgedrückt wird, wird vom Benutzer beim Aufrufen der Funktion geliefert.
Die Phaseninformationen, die während der Berechtigungen zum Auslösen der Anwendungen dem System übertragen werden (siehe nachfolgende Beschreibung), beziehen sich stets auf diesen Referenzzeitpunkt.
Dieser Referenzzeitpunkt wird aufgrund von Zeitinformationen der ersten periodischen Anwendung ständig erneut berechnet, mit deren Auslösen das System betraut ist, und zwar für jede Iteration dieser Anwendung.
Er kann dynamisch in der Zeit geändert werden, indem dieser Aufruf mit einem neuen Parameterwert wiederholt wird. Jegliche erneute Auslöseanforderung bezieht sich in gleicher Weise auf diesen neuen Referenzzeitpunkt.
Die Funktion "Referenzzeit_definieren" führt einen der nachfolgenden Fehlercodes zurück: "OK", "Dienst_nicht_aktiv" und "Zeitpunkt_nicht_konform", um anzugeben, dass die als Argument dienende absolute Zeit nicht konform ist mit den Systembedingungen.
Die Funktion "Anwendung_auslösen" ermöglicht es, das Auslösen einer Anwendung zu gestatten und neue Parameter zum Aktivieren der Anwendung abzuspeichern. Diese Funktion empfängt am Eingang einen Anwendungsidentifikator, Phasenwerte, Periode (für eine periodische Anwendung) und Fälligkeit sowie einen Parameter, der einen Betriebsmodus definiert. Die neuen Aktivierungsparameter werden dann stets vom System benutzt, um die Führung der Anforderungen zum Aktivieren der Anwendungen zu aktualisieren.
Jegliche Anwendung kann das System 1 auffordern, periodisch oder nicht periodisch eine weitere Anwendung auszulösen, indem die Funktion "Anwendung_auslösen" verwendet wird.
Wenn die Phaseninformation gleich einem bestimmten vordefinierten Wert, beispielsweise –1 ist, bedeutet dies, dass die Anforderung zum Aktivieren der Anwendung unmittelbar erfolgt. Wenn die Phaseninformation null ist, bedeutet dies, dass die Anwendungsaktivierung mit einer Phase null bezüglich des laufenden Referenzzeitpunkts ausgeführt werden soll, d. h. im Referenzzeitpunkt, der später als der laufende Zeitpunkt ist.
Wenn die Periodeinformation null ist, bedeutet dies, dass die Anwendungsaktivierung nicht periodisch ist.
Die Fälligkeitsinformation ermöglicht es, die maximale Zeit zu definieren, die der Anwendung zugewiesen ist, um ab ihrer Aktivierungsanforderung durch das System ausgeführt zu werden. Es wird dem Supervisor-Programm ein Fälligkeitsüberschreitungsereignis mitgeteilt, wenn die Anwendung nicht in der offenen Frist ihr Ende erreicht. Ein bestimmter Wert für diesen Parameter, beispielsweise null, bedeutet, dass keine für die betrachtete Anwendung zu überwachende Fälligkeit besteht.
Wenn die Fälligkeitsinformation beim Aufruf dieser Funktion geliefert wird, überwacht das Verwaltungssystem 1 die Fälligkeit zum Durchführen der Anwendung. Der dem Fälligkeitsendpunkt entsprechende Zeitpunkt wird bei jeder Anwendungsaktivierungsanforderung erneut berechnet, die vom System 1 betroffen ist, und stellt einen Weckzeitpunkt für diesen dar. Wenn die Anwendung erneut nicht die Funktion "Auslösung_akzeptieren" vor dem Fälligkeitszeitpunkt erreicht, weckt sich das System 1 zu diesem Zeitpunkt von selbst und leitet die nächste Anwendung ein.
Im Falle, dass das Wecken des Systems 1, das für diese Fälligkeit vorgesehen ist, eintritt, bevor die betreffende Anwendung den rekurrenten Teil 24 seiner Ausführung beendet hat, überträgt das System das dieser allgemeinen Fälligkeitsüberschreitung zugeordnete Ereignis zu einem Supervisor-Programm, das sich in den Zustand der Erwartung eines Empfangs eines Ereignisses versetzt hat, und zwar aufgrund des Aufrufs der Funktion "Ereignis_akzeptieren", die später in der Beschreibung erläutert wird. Wenn keine Anwendung diesen Aufruf erteilt hat, wird vom System 1 keine Meldung übertragen. Wenn eine solche Anwendung besteht und nicht gerade ein vorheriges Ereignis verarbeitet wird, wird dieses neue Ereignis von dem Supervisor-Programm unmittelbar verarbeitet, ansonsten wird es in einer Ereigniswarteschlange gespeichert. Diese bei einem Fälligkeitsüberschreitungsfehler angewandte Einrichtung hat auf die Anwendung keine Auswirkung, die für ihr Erscheinen zuständig ist.
Wenn die Anwendung die Funktion "Auslösen_akzeptieren" vor dem Fälligkeitszeitpunkt erreicht, wird das der Fälligkeit zugewiesene Wecken durch das System deaktiviert.
Der Eingangsparameter "Modus" dieser Funktion ermöglicht es, der betreffenden Anwendung eine Moduswechselmeldung zu übertragen: Aktivierung der periodischen Anwendung, normales Ende, anormales Ende, Rekonfiguration, usw. Der Modus ist unter den der Aktivierung in der Ereignistabelle 4 vorbehaltenen Symbolen auszuwählen.
Der Moduswechsel erfolgt bei der nächsten Aktivierung der betreffenden Anwendung.
Es kann ein bestimmter Vorgabewert für jeglichen Parameter vorgesehen sein, der nicht verändert werden soll.
Die Funktion "Anwendung_auslösen" führt einen der nachfolgenden Fehlercodes zurück: "OK", "Dienst_nicht_aktiv" und "Id_Anwendung_nicht_konform", um anzugeben, dass der als Eingangsparameter angenommene Anwendungsidentifikator beim System nicht bekannt ist (erscheint nicht in der Verarbeitungstabelle 5).
Diese Funktion kann auch einen der nachfolgenden Fehlercodes zurückführen: "Phase_nicht_konform", "Periode_nicht_konform", "Fälligkeit_nicht_konform" oder "Modus_nicht_konform", wenn der entsprechende Eingangsparameter nicht mit den Systembedingungen konform ist. In Falle der Phase entsteht diese Nicht-Konformität beispielsweise, wenn der entsprechende absolute Zeitpunkt die Kapazitäten des Bord-Zeitgebers übersteigt oder wenn dieser gleiche absolute Zeitpunkt über dem laufenden Zeitpunkt liegt.
Der Fehlercode "Referenz_unbekannt" wird von dieser Funktion hervorgerufen, wenn keine Referenzzeit zuvor vom Benutzer geliefert wurde.
Wenn die betreffende Anwendung nicht betriebsbereit ist, d. h. wenn diese Anwendung entweder beendet oder nicht initialisiert ist, führt der Aufruf dieser Funktion zum Fehlercode "Anwendung_nicht_betriebsbereit".
Wenn die betreffende Anwendung gerade beendet wird, dann führt der Aufruf dieser Funktion zum Fehlercode "Laufende_Beendigung_Anwendung".
Diesbezüglich ist es wichtig anzumerken, dass bei einer periodischen Anwendung eine Auslöseberechtigung die laufenden Aktivierungsparameter ersetzt, die bei einer vorherigen Berechtigung eingesetzt wurden. Ferner ist es bei einer nicht periodischen Anwendung möglich, mehrere Auslöseberechtigungen zu kumulieren, unter der Voraussetzung, dass diese unmittelbar erfolgen. In diesem Fall werden die als Aufrufparameter bereitgestellten Fälligkeiten nach den später in der Beschreibung erläuterten Bestimmungen kumuliert. Eine zurückgestellte Auslöseberechtigung ersetzt dagegen die laufenden Aktivierungsparameter, die bei einer zuvor zurückgestellten Auslöseberechtigung erstellt wurden. Diese Bedingungen sind aus Gründen der Einfachheit bei der Ausführung des Zeitverwaltungssystems 1 gerechtfertigt.
Die Funktion "Zeitpunkt_Anwendung_auslösen" ermöglicht es, das Auslösen einer Anwendung zu einem absoluten Zeitpunkt zu gestatten und neue Anwendungsaktivierungsparameter abzuspeichern. Diese Funktion ist analog zur Funktion "Anwendung_auslösen", mit dem Unterschied, dass sie am Eingang anstatt eines Phasenwertes einen absoluten Zeitpunkt erhält. Die von diesen beiden Funktionen hervorgerufenen Fehlercodes sind die gleichen, abgesehen von denjenigen, welche die Phase betreffen und in der Funktion "Zeitpunkt_Anwendung_auslösen" durch den Fehlercode "Zeitraum_nicht_konform" ersetzt werden, falls der als Parameter angenommene absolute Zeitpunkt nicht mit den Systembedingungen konform ist.
Die Verwendung der Funktionen "Anwendung_auslösen" oder "Zeitpunkt_Anwendung_auslösen" und "Auslösung_akzeptieren" ist in 3 und 4 dargestellt. 3 zeigt den Fall einer zentralen Anwenderprogrammarchitektur 2 mit einem Supervisor-Programm 31 und zumindest einem Anwenderprogramm N 32. Diese Programme wurden zuvor hochgefahren und sind damit präsent. Nach einer Initialisierungssequenz wird von dem Programm N ein Aufruf 34 der Funktion "Auslösen_akzeptieren" gestartet, um sich in Erwartung einer Aktivierung durch ein anderes Programm zu versetzen, im vorliegenden Fall durch das Supervisor-Programm 31.
Während dieser Zeit wird das Supervisor-Programm ausgeführt und erreicht den Aufruf der Funktion "Anwendung_auslösen", welche das Programm N bestimmt. Der Aufruf 35 dieser Funktion ermöglicht es, das System 1 aufzufordern, Aktivierungsparameter (Aktivierungsphase bzw. -zeitpunkt, Periode, Modus, usw.) für das Programm N in Form eines Aktivierungsereignisses zu speichern, das in eine Warteschlange eingeführt wird. Der Aufruf dieser Funktion bewirkt die Rückkehr 36 eines Rückkehrcodes. Wenn das so eingefügte Ereignis das nächstfolgend zu verarbeitende ist, programmiert das System 1 einen Zähler 33 mit der Differenz zwischen Zeitpunkt der Aktivierung des Programms N und dem laufenden Zeitpunkt. Wenn der Zähler 33 die Fälligkeit erreicht, sendet 37 das System 1 einen Rückkehrcode als Rückkehrparameter der Funktion "Auslösen_akzeptieren", wodurch die Anwendung 32 freigegeben wird, wobei die von dieser ausgeführte Sequenz von diesem Rückkehrcode abhängt. Wenn der Rückkehrcode "Normal" ist, führt das Programm 32 die Sequenz aus, für die es ausgelegt ist, geht dann wieder in den Wartezustand über, indem es erneut die Funktion "Auslösen_akzeptieren" aufruft.
4 zeigt den Fall einer dezentralen Anwenderprogrammarchitektur 2. Dabei wird jedes von der Anwendung 2 gestartete Programm 41 initialisiert und ruft 42 die Funktion "Programm_auslösen" auf, um dem System 1 seine Aktivierungsparameter (Aktivierungsphase bzw. -zeitpunkt, Periode, Modus, usw.) anzugeben. Das System 1 fügt in eine Warteschlange ein Aktivierungsereignis ein, das diesem Parameter zugeordnet ist, und überträgt 43 dem Programm 41 einen Rückkehrcode. Das Programm 41 ruft dann die Funktion "Auslösen_akzeptieren" auf 44, um sich in einen Zustand zum Warten auf eine Aktivierung durch das System zu versetzen.
Auf gleiche Art und Weise wie vorangehend für eine Anwendung mit zentraler Architektur erwähnt wurde, sendet 45 das System 1 dann, wenn der Zähler 33 die Fälligkeit erreicht hat, einen Rückkehrcode als Rückkehrparameter der Funktion "Auslösen_akzeptieren", wodurch das Programm 41 freigegeben wird.
Die Funktion "Programm_aufschieben" ermöglicht es, die Ausführung des diese Funktion aufrufenden Programms für eine bestimmte als Parameter angenommene Zeitdauer in einen Schlafzustand zu versetzen. Diese Funktion fordert das Zeitverwaltungssystem 1 auf, die Ausführung des den Aufruf gestellten Programms für die als Parameter vorgesehene Zeitdauer auszusetzen. Mit Aufruf dieser Funktion kehrt einer der nachfolgenden Fehlercodes zurück, der auf das Ende der Operation hinweist: "OK", "Dienst_nicht_aktiv" und "Frist_nicht_konform", wenn der Eingangsparameter nicht mit den Systembedingungen konform ist, im vorliegenden Fall wenn er die Kapazitäten der Zeitressourcen (Zähler 33, Zeitgeber 13) überschreitet.
Die Funktion "Zeitpunkt_Programm_aufschieben" ermöglicht es, die Ausführung des diese Funktion aufrufenden Programms bis zu einem als Parameter angenommenen absoluten Zeitpunkt in einen Schlafzustand zu versetzen. Diese Funktion ist analog zu der Funktion "Programm_aufschieben", abgesehen davon, dass sie am Eingang einen absoluten Zeitpunkt anstatt einer Zeitdauer empfängt.
Das die Funktion "Programm_aufschieben" aufrufende Programm wird umgehend in seiner Ausführung ausgesetzt. Das System 1 berücksichtigt die Informationen zum Wecken dieses Programms und aktualisiert eine Weckliste. Die Echtzeitexekutive aktiviert ein weiteres Programm gemäß seiner Ablaufplanung. Dieser Vorgang führt auch zur Registrierung in der Beobachtungsaufstellung über das betreffende Programm.
Das Zeitverwaltungssystem weckt sich von selbst, wenn der Zeitpunkt der Wiederaufnahme eines Programms erreicht ist, und aktualisiert seine Weckinformationen. Die Echtzeitexekutive wird dann von dem System aufgefordert, die Ausführung des betreffenden Programms fortzusetzen.
Die über diese beiden Funktionen zurückgeführten Fehlercodes sind die gleichen, abgesehen von dem Code bezüglich der Zeitdauer, der in der Funktion "Zeitpunkt_Programm_aufschieben" ersetzt wird durch den Fehlercode "Zeitpunkt_nicht_konform".
Wichtig ist zu betonen, dass aus Gründen der Einfachheit bei der Ausbildung des Zeitverwaltungssystems 1 die Funktionen "Programm_aufschieben" bzw. "Zeitpunkt_Programm_aufschieben" mit weiteren Funktionen unkompatibel sind, welche diese Fristen in Frage stellen könnten. Die praktischen Folgen davon sind:

– wenn eine Anwendung eine Zusatzprogrammauslösung programmiert (siehe weiter unten in der vorliegenden Beschreibung), wird mit dem nächstfolgenden Aufruf einer Funktion zum Versetzen eines Programms in den Schlafzustand die entsprechende Auslösung annulliert,
– wenn eine Anwendung eine unmittelbare Zustellung mit einer maximalen Frist bis zur nächsten Zustellung programmiert, verhindert der nächstfolgende Aufruf einer Funktion zum Versetzen eines Programms in den Schlafzustand die Erfassung eines eventuellen Überschreitens dieser Frist.

Die Funktion "Anwendung_einfrieren" ermöglicht das Einfrieren einer Anwendung, d. h. die Ausführung einer weiteren Anwendung zu blockieren. Der Aufruf dieser Funktion bedeutet für das Zeitverwaltungssystem 1, dass es die Anforderungen zum Aktivieren der als Parameter spezifizierten Anwendung aussetzen muss, bis eine nächstfolgende Auslöseberechtigung erfolgt ist.
Eine Anwendung kann das Einfrieren einer weiteren Anwendung anfordern, indem sie die Funktion "Anwendung_einfrieren" aufruft. Dieser Aufruf ermöglicht es, dem System 1 mitzuteilen, jegliche zukünftige Auslösung der betrachteten Anwendung zu unterbinden. Das System 1 aktualisiert die dieses betreffenden Auslöseinformationen und erteilt der diesen Aufruf erteilten Anwendung den Vorrang.
Sobald die betrachtete Anwendung die Funktion "Auslösen_akzeptieren" aufruft, um ihre nächstfolgende Aktivierung zu erwarten, führt das System 1 den äquivalenten Vorgang der Funktion "Ereignis_melden" (siehe weiter unten) durch, um das Supervisor-Programm auf das effektive Einfrieren der Anwendung hinzuweisen. Falls diese Anwendung zum Zeitpunkt der Einfrieraufforderung bereits in Erwartung der Funktion "Auslösen_akzeptieren" war, führt das System 1 diesen Vorgang unmittelbar durch, bevor es der den Aufruf erteilten Anwendung den Vorrang gibt. Um nach einem Einfrieren einen Auslöseprozess wieder aufzunehmen, genügt es, dass eine Anwendung die Funktion "Anwendung_auslösen" aufruft.
Wenn die Ausführung des betreffenden Programms effektiv eingefroren ist, d. h. wenn das Programm seine Ausführung beendet hat und in den Zustand zum Warten auf die Funktion "Auslösen_akzeptieren" zurückgekehrt ist, wird beim Supervisor- Programm ein vorbestimmtes Ereignis höherer Art "Anwendung_einfrieren" erzeugt. Dieser Aufruf kann für nicht periodische Anwendungen verwendet werden, um das Ende der Ausführung des Hauptteils der Anwendung zu erkennen.
Ein solches Verfahren ermöglicht es dem Supervisor, sich auf das Ende der Ausführung einer Einheit von Anwendungen zu synchronisieren, unabhängig davon, ob deren Aktivierungen zusammenhängen oder unabhängig sind. Der Supervisor kann somit einen dynamischen Betriebsmoduswechsel durchführen, der bei sämtlichen Anwendungen synchronisiert ist, indem die Funktion "Anwendung_einfrieren" aufgerufen wird, um die Aktivierungen der Anwendungen abzubrechen, deren Betriebsmodus gewechselt werden soll, dann um für jede dieser Anwendungen die Funktion "Anwendung_auslösen" aufzurufen, die den Zeitparametern des neuen Betriebsmodus und dem Modusparameter zugeordnet ist, der den Anwendungen angibt, in welchem Modus sie arbeiten sollen.
Auf diese Weise kann ein dynamischer Moduswechsel auf einfache und synchronisierte Weise erfolgen, ohne dabei einen Test einer geteilten Variablen zu verwenden, die den Betriebsmodus spezifiziert.
Anzumerken ist, dass das Einfrieren der Anwendung, die in der Berechnung des Referenzzeitpunkts für die Phasen verwendet wird, keinerlei Auswirkung auf diesen hat.
Diese Funktion führt einen Fehlercode zurück, der einen der nachfolgenden Werte annehmen kann: "OK", "Dienst_nicht_aktiv", "Id_Anwendung_nicht_konform", "Anwendung_nicht_betriebsbereit" oder "Laufende_Beendigung_Anwendung".
Die Funktion "Anwendung_beenden" ermöglicht es, dem System 1 anzugeben, dass es die Ausführung einer Anwendung beenden soll, deren Identifikator als Parameter vorgesehen ist. Dazu sendet es der betreffenden Anwendung eine Beendigungsmeldung. Diese Funktion nimmt auch als Eingangsparameter einen Modusidentifizierer an, der unter den Identifizierern von Ereignissen auszuwählen ist, die der Beendigung vorbehalten sind.
Eine Anwendung kann vom System erfordern, die Ausführung einer weiteren Anwendung zu beenden, indem die Funktion "Anwendung_beenden" (3) aufgerufen wird 39.
Bevor der diese Anforderung erteilenden Anwendung der Vorrang gewährt wird 40, unterbindet das System 1 jegliche künftige Auslösung der betreffenden Anwendung und sendet 38 die Abbrechmeldung, die dieser Anwendung als Parameter bereitgestellt wird, welche diese auswertet, sobald erneut der Aufruf der Funktion "Ereignis_akzeptieren" erfolgt ist. Wenn diese Anwendung bereits bei der Funktion "Auslösung_akzeptieren" zum Zeitpunkt der Beendigungsanforderung im Wartezustand war, ist sie unmittelbar dazu berechtigt, ihren Endteil 25 auszuführen, sobald die Echtzeitexekutive sie gemäß der Ablaufplanung aktiviert hat.
In gleicher Weise wie in 4 dargestellt ist, ruft 46 dann, wenn ein Programm 41 einer Anwendung mit dezentraler Architektur in einen Zustand gelangt, in welchem es sich beenden muss, es die Funktion "Programm_beenden" mit unmittelbarer Rückkehr 47 eines Rückkehrcodes durch das System auf. Im Laufe dieser Funktion löst das System erneut das Programm 41 aus. Wenn das Programm 41 wieder zum Aufruf der Funktion "Auslösen_akzeptieren" gelangt, empfängt 45 es als Rückkehrcode einen Endcode "Normales_Ende" oder "Anormales_Ende" und führt also seine Beendigungsanweisungssequenz aus.
Diese Funktion führt einen Fehlercode zurück, der einen der nachfolgenden Werte annehmen kann: "OK", "Dienst_nicht_aktiv", "Id_Anwendung_nicht_konform" "Anwendung_nicht_betriebsbereit" oder "Laufende_Beendigung_Anwendung".
Die Funktionen "Zusatzprogramm_auslösen" und "Zeitpunkt_Zusatzprogramm_auslösen" ermöglichen es, das Zeitverwaltungssystem 1 aufzufordern, ein gegebenes Unterpogramm auszuführen, dessen Adresse als Parameter vorgesehen ist, und zwar nach einer Frist oder zu einem absoluten Zeitpunkt, der auch als Parameter vorgesehen ist. Dieses Unterprogramm erfolgt außerhalb der laufenden Menge an Anweisungen und muss somit mehrere Bedingungen erfüllen:

– es enthält keine blockierenden Aufrufe,
– es hat eine kurze Ausführungszeitdauer, und
– es verwendet keine Ortsdaten, die zum Zeitpunkt des Aufrufs der Funktion bekannt sind; die Eingangs- bzw. Ausgangsdaten sind allgemein und in dem Modul definiert, wo er erteilt wird, oder aber in Mantelmodulen.

Die als Parameter vorgesehenen Informationen werden von dem Verwaltungssystem 1 dazu verwendet, den Zeitpunkt zu bestimmen, welcher seiner Weckliste hinzugefügt wird. Umgehend wird demjenigen Programm Vorrang gewährt, das diese Funktion aufgerufen hat.
Das System 1 erweckt sich von selbst, wenn der Zeitpunkt zum Auslösen des Zuatzprogramms erreicht ist, und aktualisiert seine Weckinformationen.
Es führt dann das Unterprogramm aus, welches das Zusatzprogramm enthält.
Dieses Unterprogramm wird unabhängig von dem Ablauf des ursprünglichen Programms ausgeführt und läuft im Ausführungskontext des Systems ab. Aus diesem Grund ist es erforderlich, dass dieses Zusatzprogramm möglichst kurz und nicht blockierend ist.
Das Auslösen eines Zusatzprogramms kann mit Aufruf der Funktion "Verlauf_zustellen" rückgängig gemacht werden, die weiter. unten in der Beschreibung erläutert wird. Diese Möglichkeit wird dazu genutzt, dem Zusatzprogramm eine Überwachungsfrist zuzuordnen. In diesem Fall darf das Zusatzprogramm nur dann erfolgen, wenn die Überwachungsfrist erreicht ist, was beinhaltet, dieses zu annullieren, wenn die zu überwachende Operation rechtzeitig beendet wurde.
Die Funktion führt einen der nachfolgenden Fehlercodes zurück: "OK", "Dienst_nicht_aktiv", "Frist_nicht_konform" oder "Zeitpunkt_nicht_konform".
Die zeitliche Verfolgung der Anwendungen und die Fehlerverwaltung tragen zur Ausbildung dreier Funktionalitäten bei.

– Beobachtung des Verlaufs einer Anwendung durch Sammlung von Registrierungen, welche die verschiedenen Phasen ihrer Ausführung und die entsprechenden Zeitpunkte beschreiben,
– Erfassung von zeitlichen Ereignissen (Überschreiten der Fälligkeit einer Anwendung oder eines Teils einer Anwendung) und implizite oder explizite Übertragung dieser Ereignisse zu einem Supervisor-Organ, falls vorhanden, und
– rein explizite Zustellung von Anwenderereignissen (vom Programmierer definiert) zu einem Supervisor-Organ, um den der Art dieser Ereignisse entsprechenden Vorgang auszulösen.

Dazu enthalten die zeitliche Verfolgung der Anwendungen und die Fehlerverwaltung die nachfolgenden Funktionen:

– "Zustellung_Supervisor_bestimmen",
– "Haupt-Supervisor_bestimmen",
– "Zustellung_akzeptieren",
– "Ereignis_akzeptieren",
– "Verlauf_zustellen",
– "Zeitpunkt_Verlauf_zustellen",
– "Ereignis_melden",
– "Zeitpunkt_Ereignis_melden", und
– "Ereignis_aufheben".

Die Funktion "Zustellung_Supervisor_bestimmen" bzw. "Haupt-Supervisor_bestimmen" ermöglicht es dem Programm, das diese aufruft, sich als zuständig für die Verwaltung der Zustellereignisse bzw. der Hauptereignisse zu erklären. Der Aufruf dieser Funktion kann aufeinanderfolgend von mehreren Programmen erfolgen, wohl weißlich, dass jedes Zustellereignis bzw. Hauptereignis, das bei den Anwenderprogrammen auftritt, zu dem sich zuletzt als zuständig erklärten übertragen wird. Ein gleiches Programm kann sich für die Verwaltung der beiden Arten von Ereignissen als zuständig erklären. Wenn kein Programm bestimmt wird, um die Verwaltung der Zustellereignisse bzw. der Hauptereignisse zu gewährleisten, werden die Ereignisse nicht vom System 1 übertragen, das sich begnügt, sie mit Hilfe des Registrierers 14 zu registrieren.
Diese Funktionen führen einen der Fehlercodes "OK" oder "Dienst_nicht_aktiv" zurück.
Die Funktion "Zustellung_akzeptieren" ermöglicht es dem Zustellungs-Supervisor-Programm, sich in Zustellereigniserwartung gemäß dem allgemeinen Schema der Struktur eins in 2 dargestellten Programms zu versetzen.
Diese Funktion nimmt am Eingang einen den Modus identifizierenden Parameter an, der es ermöglicht, die Merkmale des Aufrufs zu definieren:

– Blockiermodus: Der Aufruf dieser Funktion wirkt blockierend, bis zumindest ein Zustellereignis in der Liste von auftretenden Ereignisses vorhanden ist. Das Ereignis wird dann aus der Liste von Zustellereignissen genommen und über die Funktion zurückgeführt.
– Nichtblockiermodus: Der Aufruf dieser Funktion wirkt nicht blockierend, d. h. wenn zumindest ein Ereignis aufgetreten ist, wird dieses von der Liste von Zustellereignissen genommen und über die Funktion zurückgeführt. Andernfalls wird ein Fehlercode "Leer" über die Funktion zurückgeführt.
– Durchlaufmodus: Der Aufruf dieser Funktion wirkt nicht blockierend, und wenn die Liste von Zustellereignissen nicht leer ist, wird das erste dieser Ereignisse über die Funktion zurückgeführt und in der Schlange der Liste verschoben (und nicht herausgenommen). Mit aufeinanderfolgender Wiederholung des Aufrufs kann der Benutzer die Ereignisliste in nicht zerstörender Weise durchlaufen, um beispielsweise ein bestimmtes Ereignis in der Liste der aufgetretenen Zustellereignisse zu suchen.

Wichtig ist anzumerken, dass in diesem letztgenannten Modus der Aufruf dieser Funktion mehrere Folgen hat:

– Der Benutzer hat die Aufgabe, Iterationen der Aufrufe der Funktion zu kontrollieren. Insbesondere deshalb, weil die Ereignisse mit Fortschreiten ihrer Rückkehr über die Funktion nicht von der Liste genommen werden, muss der Benutzer eine maximale Anzahl von Iterationen definieren, die unabhängig von der Rückkehr des Aufrufs der Funktion ist.
– Die Chronologie von auftretenden Ereignissen geht verloren.
– Die über die aufeinanderfolgenden Aufrufe zurückgeführten Ereignisse werden nicht fortschreitend zerstört. Somit ist insbesondere zu vermeiden, mehrfach ein Ereignis zu verarbeiten, das nur einmal aufgetreten sein soll.

Die Funktion "Zustellung_akzeptieren" erhält auch als Aufrufparameter eine "Frist vor nächstfolgender Erwartung", die es ermöglicht, die maximale Frist zu definieren, welche das Ausgeben eines Ereignisses durch das System 1 und den nächstfolgenden Aufruf dieser Funktion durch den Supervisor trennen, der gezwungenermaßen vorhanden ist, um das Ereignis zu empfangen. Der Zweck liegt darin, das Erfassen einer Anomalie im Bereich des Supervisors zu ermöglichen, falls dieser zu viel Zeit bräuchte, um ein vorhergehendes Ereignis zu verarbeiten. Ein Wert gleich null für diesen Parameter verlangt keinerlei Prüfung dieser Frist, welche die nächstfolgende Ereigniserwartung trennt. Der Sonderwert –1, der ersatzweise für diesen Parameter definiert wird, ermöglicht es, zu melden, dass die Frist bezüglich ihres laufenden Wertes unverändert bleibt.
Wenn diese Frist überschritten wird, führt das System dann eine kritische Reinitialisierungssequenz durch, indem es ein abgelegtes Unterprogramm "Schweren_Fehler_verarbeiten" aufruft, dessen Inhalt systemextern definiert ist.
Der Aufruf der Funktion "Zustellung_akzeptieren" führt den Identifikator des Ereignisses und den Identifikator des Programms zum Ursprung desselben zurück, sowie einen Fehlercode, der einen der nachfolgenden Werte annehmen kann: "OK", "Frist_nicht_konform" oder "Dienst_nicht_aktiv" oder auch "Leer" im dem Falle, dass kein Ereignis im Nichtblockiermodus vorliegt, "unmöglich", wenn das System 1 bereits einem anderen Programm das Recht zugestanden hat, Supervisor der Zustellereignisse zu sein, oder auch "Modus_nicht_konform", wenn der Moduseingangsparameter nicht gültig ist.
Wichtig ist zu erwähnen, dass die "Frist vor nächstfolgender Erwartung" für den Supervisor einer Fälligkeit seiner Anwendung gleichkommt.
Die Funktion "Ereignis_akzeptieren" ist analog zur Funktion "Zustellung akzeptieren", mit dem Unterschied, dass sie nicht auf Zustellereignisse zutrifft, sondern auf Hauptereignisse.
Sowohl für das Supervisor-Programm für die Hauptereignisse als auch für das Supervisor-Programm für die Zustellereignisse, welche ein und das gleiche Programm sein können, ist es somit möglich, dem System 1 eine Fälligkeit für die Verarbeitung dieser Ereignisse zu melden. Diese Überwachung wird aktiviert, indem dem System 1 der Wert dieser Fälligkeit bei Aufruf der Funktion "Ereignis_akzeptieren" oder "Zustellung_akzeptieren" bereitgestellt wird. Sobald das System 1 aufgefordert wird, dem Supervisor, der dieser Überwachung unterliegt, ein Hauptereignis oder ein Zustellereignis zu melden, aktualisiert das System seine Weckliste, indem es den der Ereignisverarbeitungsfälligkeit entsprechenden Zeitpunkt berechnet, und fordert das Betriebssystem 11 auf, das Supervisor-Programm zu aktivieren, indem diesem das Ereignis bereitgestellt wird. Wenn das Supervisor-Programm erneut den Aufruf der Funktion "Ereignis_akzeptieren" oder "Zustellung_akzeptieren" erreicht, um das nächstfolgende Ereignis abzuwarten, bevor das System für das betreffende Ereignis geweckt wurde, wird dieser Weckvorgang deaktiviert. Umgekehrt wird dann, wenn das System am Fälligkeitszeitpunkt sich selbst weckt und das Programm den dem Ereignis zugeordneten Vorgang nicht beendet hat, ein von dem System bereitgestelltes Sonderprogramm durchgeführt, das zu einer Reinitialisierung des Systems führen kann.
Dieses Sonderprogramm wird auch dann aufgerufen, wenn der Schwellwert von kumulierten Ereignissen mit Destination zu dem einen oder anderen Supervisor erreicht ist.
Die Funktionen "Verlauf_zustellen" und "Zeitpunkt_Verlauf_zustellen" ermöglichen es, die Registrierung einer Spur bei der Verfolgung einer Anwendung zu planen bzw. dem Zustell-Supervisor das Erreichen eines Schrittes zu melden, sofern letztgenannter Supervisor besteht und sich für zuständig erklärt hat. Diese Funktionen nehmen als Eingangsparameter eine Frist oder einen absoluten Zeitpunkt an, der den Augenblick definiert, zu dem vom System 1 das Zustellereignis erzeugt wird, dessen Identifikator auch als Parameter der Funktion vorgesehen ist. Ein charakteristischer Wert, der ersatzweise für den Parameter der Frist bzw. des absoluten Zeitpunkts erstellt wird, gibt an, dass die Meldung des Ereignisses unmittelbar erfolgen muss.
Der Aufruf der Funktion "Verlauf_zustellen" ermöglicht auch, die Einhaltung einer Zwischenfälligkeit bei der Anwendung zu überprüfen. Dies erfolgt dadurch, dass in einem weiteren Parameter die maximale Frist bis zur nächstfolgenden Zustellung angegeben wird, die nur bei einer unmittelbaren Zustellung anwendbar ist.
Eine Folge von Anweisungen kann somit über einen Aufruf dieser Funktion zu Beginn und am Ende dieser Folge überwacht werden.
Diese Funktion führt einen Zeitpunkt in die Weckliste des Systems 1 ein. Wenn die betreffende Anwendung die Funktion "Verlauf_zustellen" vor dem der Fälligkeit zugeordneten Weckvorgang des Systems aufruft, wird somit der Zeitpunkt dieses Weckvorgangs deaktiviert.
Falls der für diese Fälligkeit vorgesehene Weckvorgang des Systems auftritt, bevor das betreffende Programm die überwachte Folge von Anweisungen beendet hat und somit erneut die Funktion "Verlauf_zustellen" ausgeführt hat, registriert das System die Anomalie und erzeugt ein vorbestimmtes Hauptereignis "Überschreiten_Zwischenfälligkeit", welches dem vom Benutzer definierten zuständigen Organ übertragen wird, d. h. einem sogenannten Supervisor-Programm, das sich in Erwartung des Empfangs eines Ereignisses aufgrund des Aufrufs "Ereignis_akzeptieren" versetzt hat. Wenn kein Programm diesen Aufruf für dieses Ereignis erteilt hat, wird vom System keine Meldung übertragen. Wenn dagegen ein solches Programm besteht und es nicht gerade dabei ist, ein früheres Ereignis zu verarbeiten, wird dieses neue Ereignis unmittelbar von dem Supervisor-Programm verarbeitet, andernfalls in der dem Supervisor-Programm zugeordneten Ereigniswarteschlange gespeichert. Diese auf einen Zwischenfälligkeitsüberscheitungsfehler anwendete Einrichtung hat keinerlei Auswirkung auf das für dessen Erscheinen zuständige Programm.
Ein Nullwert für diese Frist unterbindet jegliche Zwischenfälligkeitsüberprüfung. Die Zustellung eines Ereignisses führt in erster Linie zur Registrierung desselben in einer Beobachtungsaufstellung. Der Zeitpunkt des Auftretens des Ereignisses wird nicht dem Supervisor-Programm übertragen.
Es ist wichtig, die Modalitäten einer gleichzeitigen Verwendung von Verlaufszustellungen zu betonen: Es ist möglich, mehrere Zustellungen zu einem Supervisor-Programm unter der Bedingung zu kumulieren, dass sie unmittelbar erfolgen. In diesem Fall werden die in der Funktion "Zustellung_akzeptieren" parametrierten Überwachungsfristen gemäß den weiter unten in der vorliegenden Beschreibung genannten Bedingungen kumuliert.
Wenn dagegen eine aufgeschobene Zustellung in Vorbereitung ist, ersetzt jede erneut aufgeschobene Zustellung die vorhergehende.
Diese Bedingung ist aus Gründen der Einfachheit bei der Ausbildung des Zeitverwaltungssystems gerechtfertigt.
Hinsichtlich der maximalen Frist bis zu nächstfolgenden Zustellung ergeben sich daraus nachfolgende Bestimmungen:

– Wenn eine unmittelbare Zustellung eine maximale Frist enthält, wird mit Ablaufen des Programms über eine erneute unmittelbare Zustellung vor Ablauf dieser Frist deren Zählung unterbrochen oder mit einem neuen Wert ersetzt, und zwar je nachdem, ob die erneute Zustellung eine maximale Nullfrist oder einen entscheidenden Wert enthält.
– Das vorangehende Prinzip findet in gleicher Weise dann Anwendung, wenn eine unmittelbare Zustellung nach einem Aufruf einer Funktion zum Auslösen eines Zusatzprogramms einprogrammiert ist.
– Die Programmierung einer Zusatzprogrammauslösung nach einer unmittelbaren Zustellung mit maximaler Frist oder nach einer Zustellung, die sich von einer Frist vor Zustellung ableitet, bewirkt systematisch eine Annullierung der mit dieser Zustellung verbundenen Zählung. Diese Bedingung ist aus Gründen der einfacheren Ausbildung des Zeitverwaltungssystems gerechtfertigt.

Die Funktionen "Verlauf_zustellen" und "Zeitpunkt_Verlauf_zustellen" führen einen der nachfolgenden Fehlercodes zurück: "OK", "Dienst_nicht_aktiv", "Id_Ereignis_nicht_konform", "Frist_nicht_konform" oder "Zeitpunkt_nicht_konform".
Die Funktionen "Ereignis_melden" und "Zeitpunkt_Ereignis_melden" ermöglichen es einem Programm, über das Zeitverwaltungssystem 1 das Auftreten eines außergewöhnlichen Ereignisses zu planen. Eine Frist bzw. ein absoluter Zeitpunkt, der als Argument vorgesehen ist, ermöglicht es, die Zeit zu spezifizieren, bei deren Ablauf das Ereignis durch das System 1 gemeldet wird. Ein für diesen Parameter ersatzweise erstellter Kennwert gibt an, dass die Meldung des Ereignisses unmittelbar erfolgen muss. Die Art dieser Ereignisse ist nicht unbedingt mit der Zeit verbunden und kann auf mehrere Programme Einfluss haben.
Das Auftreten eines solchen Ereignisses führt zur Erstellung einer Beobachtungsaufstellung und zur Meldung beim Supervisor-Programm, das die Verwaltung des Ereignisses gewährleistet.
Die Unterscheidung zwischen Verwaltung von Hauptereignissen und Zustellereignissen liegt in der Bedeutung der Frist, die von dem Ereignis erster Art berücksichtigt wird. Die Hauptereignisse sind nämlich dazu bestimmt, eine Reaktivität des Systems zu erwecken, während die Zustellereignisse dazu bestimmt sind, offline betrieben zu werden.
Um eine schnelle Berücksichtigung der Ereignisse durch den Supervisor zu erhalten, genügt es, diesem Programm im Bereich des Betriebssystems eine Priorität zuzuweisen, die höher ist als die des Programms, das die Meldung anfordert. Sobald somit das Zeitverwaltungssystem 1 die Aktivierung des Supervisors anfordert, wird dieses auf Kosten des Anforderungsprogramms ausgeführt.
Die Funktionen führen einen Fehlercode zurück, der einen der nachfolgenden Werte annehmen kann: "OK", "Dienst_nicht_aktiv", "Id_Ereignis_nicht_konform", und "Frist_nicht_konform" oder "Zeitpunkt_nicht_konform".
Wenn hier auch eine aufgeschobene Meldung über ein Hauptereignis programmiert ist, ersetzt jegliche aufgeschobene Meldung die vorhergehende.
Der Verlauf eines Programms kann somit auf Anfrage des Benutzers hin in Ausführungspunkten verfolgt werden, die er selbst definiert, indem er die Funktionen "Verlauf_zustellen" oder "Ereignis_melden" aufruft. Neben dieser Beobachtungseinrichtung ermöglicht diese Funktion, durch ein Ereignis das Erreichen eines betreffenden Schritts beim Supervisor-Programm zu melden, wenn dieses sich als solches erklärt hat, indem es sich in Erwartung eines Zustellereignisses aufgrund des Aufrufs "Zustellung_akzeptieren" oder in Erwartung eines Hauptereignisses aufgrund des Aufrufs "Erzeignis_akzeptieren" versetzt. Somit führt das Programm N 32, wie in 5 dargestellt ist, einen Vorgang i aus und muss bei bestimmten Fällen dem Supervisor 31 melden, dass dieser Vorgang durchgeführt wurde, und dann einen Vorgang i+1 ausführen. Um zu melden, dass der Vorgang i ausgeführt wurde, ruft 51 es die Funktion "Ereignis_melden" auf, indem es als Parameter einen Ereignisidentifikator annimmt, der dem Ende des Vorgangs i entspricht, wobei das System diesem unmittelbar einen Rückkehrcode überträgt 52. Bei bestimmten Fällen muss es einen weiteren Vorgang i+2 ausführen und melden, dass es den Vorgang i+2 beendet hat, indem es die Funktion "Ereignis_melden" aufruft 55, wobei dieser Aufruf unmittelbar einen Rückkehrcode zurückführt 56.
Parallel dazu versetzt sich das Supervisor-Programm in Erwartung eines Ereignisses, indem es die Funktion "Ereignis_akzeptieren" aufruft 53. Zu dem vom Programm 32 zum Melden des Ereignisses angeforderten Zeitpunkt aktiviert das System 54 das Supervisor-Programm 31. Je nach gemeldetem Ereignis "Ende Vorgang i" oder "Ende Vorgang i+2" führt das Supervisor-Programm 31 den entsprechenden Vorgang zum Beenden der Verarbeitung des Vorgangs i oder i+2 durch und ruft erneut die Funktion "Ereignis_akzeptieren" auf, um sich in Erwartung eines neuen Ereignisses zu versetzen.
Wenn bei der Meldung das Supervisor-Programm sich dann in Ereigniserwartung befindet, wird es von diesem unmittelbar verarbeitet. Wenn umgekehrt dieses Programm gerade dabei ist, ein vorheriges Ereignis zu verarbeiten, wird dieses neue Ereignis in der dem Supervisor-Programm zugeordneten Ereigniswarteschlange abgespeichert.
Anzumerken ist, dass im Falle eines Anwenderprogramms mit dezentraler Architektur diese Einrichtung nicht anwendbar ist, sofern kein Supervisor-Programm besteht. Um zwei Programme 32 und 61 zu synchronisieren, werden somit vorzugsweise die Funktionen "Programm_auslösen" und "Auslösung_akzeptieren" verwendet, wie in 6 dargestellt ist, sowie damit verbunden ein Programmidentifikator mit den Vorgängen i und i+2. In dieser Figur wird am Ende des Vorgangs i bei bestimmten Fällen die Funktion "Programm_auslösen" mit einem Modusparameter aufgerufen 62, der das Ende des Vorgangs i angibt, und mit unmittelbarer Rückkehr 63 des Systems 1, um dem Programm 61 das Ende des Vorgangs i zu melden, bevor zum Vorgang i+1 übergegangen wird. In anderen Fällen führt das Programm 32 den Vorgang i+2 aus und ruft 66 die Funktion "Programm_auslösen" mit einem Modusparameter auf, der das Ende des Vorgangs i+2 angibt, und mit unmittelbarer Rückkehr 67 des Systems 1, um dem Programm 61 das Ende des Vorgangs i+2 zu melden. Das Programm 61, das in Erwartung der Auslösung nach dem Aufruf 64 der Funktion "Auslösung_akzeptieren" ist, wird von dem System 1 aktiviert, das diesem einen Rückkehrcode zurückführt 65 und je nach auszulösendem Programm ein Programm ausführt, das dem Ende des Vorgangs i oder dem Ende des Vorgangs i+2 entspricht.
Die Funktion "Ereignis_aufheben" ermöglicht es, die zuletzt von einem beliebigen Programm ausgegebene aufgeschobene Anforderung zum Zustellen eines Verlaufs oder Melden eines Hauptereignisses zu löschen. Die Wahl zwischen einer Meldeanforderung bzw. einer Zustellanforderung erfolgt mittels eines Parameters zum Aufrufen der Ereignisklasse.
Diese Funktion führt einen der nachfolgenden Fehlercodes zurück: "OK", "Dienst_nicht_aktiv" oder "Id_Ereignis_nicht_konform".
Auch hier ersetzt dann, wenn eine aufgeschobene Meldung eines Hauptereignisses programmiert ist, jegliche aufgeschobene neue Meldung die vorhergehende.
Schließlich schlägt das Zeitverwaltungssystem 1 aufgrund seiner Schnittstelle 6 Funktionen vor, die es ermöglichen, die Ausführung der periodischen bzw. nicht periodischen Anwendungen zu kontrollieren, sowie Werkzeuge zur zeitlichen Überwachung und Verwaltung von Ereignissen. Dagegen muss diese Funktion verwendet werden, indem bestimmte Bedingungen, die über die Systemarchitektur eingefügt wurden, und der Belegungsgrad der Ressourcen desselben eingehalten werden.
Die Architektur des Systems stellt zunächst Bedingungen hinsichtlich Struktur zum Programmieren einer Anwendung, wie in 2 dargestellt ist.
Die Ausführung einer Funktion bei der Schnittstelle 6 darf nicht unnütz die Ressourcen der Verarbeitungseinheit monopolisieren. Je mehr Mittel zur Zeitkontrolle das Zeitverwaltungssystem zur Verfügung stellt, desto mehr wird es die Ressourcen der Verarbeitungseinheit beanspruchen, um die Fälligkeiten zu überprüfen bzw. den Zustand der Anwendungen zu aktualisieren.
Es erfolgt somit keine Stapelung von aufgeschobenen Aktivierungs- bzw. Überwachungsbefehlen, wobei jeder Aufruf die vorhergehenden Informationen und/oder die mit einer weiteren laufenden Funktionalität geteilten Informationen überschreibt.
Dies drückt sich auf Seiten des Benutzers auch mit der Unmöglichkeit aus, zugleich bei einer gleichen Anwendung auf zwei verschiedene Funktionalitäten zurückzugreifen, die jedoch die gleichen systeminternen Einheiten betreffen. Somit ist es ausgeschlossen, im Rahmen einer gleichen Anwendung Aufrufe von Funktionen zum Überführen in den Schlafzustand, zum Auslösen des Zusatzprogramms, zur verzögerten Zustellung (Etappenübergangsfälligkeit) und zum Überwachen von eintreffenden Ereignissen gleichzeitig zu verwenden, wobei jeder dieser Aufrufe eine gleiche Einheit nutzt und die vorhergehenden Informationen ersetzt.
Die vorangehende Beschreibung erläutert Werkzeuge, mit denen es möglich ist, die Überwachung der Programme durchzuführen. Die nachträgliche Betrachtung des Verlaufs der Programme erfolgt teilweise durch Sammlung von Registrierungen auf Initiative des Zeitverwaltungssystems 1 hin. Dazu verfügt das Registriermodul 14 über eine Schnittstelle 15, welche das Schreiben und Lesen von Registrierungen und damit die Auswertung der Informationen zum Verfolgen der Programme gewährleistet.
Diese Spezifikationen sind festgelegt und hängen nicht vom Implementierungskontext ab.
Die Dimensionierung des Zeitverwaltungssystems 1 umfasst eine Dimensionierung des Registriermoduls 14. Die wesentlichen Merkmale dieses Moduls sind die Anzahl von beobachteten Anwendungen sowie die der Beobachtung einer jeden Anwendung zugewiesene Größe, die direkt proportional ist zu Anzahl von verarbeiteten Ereignissen.
Die Beobachtungsaufstellungen verhalten sich wie "kreisrunde" Pufferspeicher. Wenn diese Speicher einmal gesättigt sind, werden die in der Aufstellung zuerst aufgeführten Registrierungen von den nachfolgenden Registrierungen überschrieben.
Die Registrierschnittstelle 15 vereint nachfolgende Funktionen:

– "Beobachtung_initialisieren",
– "Reg_aktivieren",
– "Reg_deaktivieren",
– "Fenster_definieren",
– "Aufstellung_schreiben",
– "Letzte_Aufstellung_herausnehmen", und
– "Anzahl_Registrierungen_erhalten".

Die Funktion "Beobachtung_initialisieren" ermöglicht es, eine einem Programm zugeordnete Aufstellung zu schaffen, indem als Parameter der Identifizierer des betreffenden Programms und die der entsprechenden Beobachtungsaufstellung zugewiesene Größe spezifiziert wird.
Jede Registrierung ist damit spezifisch für jedes Programm. Diese Lösung gestattet, hinsichtlich gespeicherter Mengen Beobachtungen zu begünstigen, die sich auf ein bestimmtes Programm beziehen, und zwar durch Einwirken auf den Registrier-Dienst anstatt durch Filtereingriffe im Bereich Anwenderprogramme. Ein weiterer Vorteil dieses Verfahrens besteht darin, die Registrierung der Identifizierung des Programms zu vermeiden.
Diese Funktion führt einen der nachfolgenden Fehlercodes zurück: "OK", "Id_Programm_nicht_konform" und "Größe_nicht_konform", wenn die als Eingangsparameter vorgesehene Größe nicht konform ist mit den Systembedingungen.
Die Funktionen "Reg_aktivieren" und "Reg_deaktivieren" ermöglichen es, die Registrierung der Aufstellungen für sämtliche gerade beobachteten Programme zu aktivieren bzw. zu deaktivieren, die mit dem Aufruf der Funktion "Beobachtung_initialisieren" bezeichnet werden.
Die Funktion "Fenster_definieren" ermöglicht es, die Zeitparameter zum Beobachten der Programme festzulegen. Sie nimmt als Argument die Anfangs- und Enddaten an, zwischen denen die Beobachtung effektiv ist. Dieses Fenster wird nur dann betrachtet, wenn keine Aktivierungs-/Deaktivierungsfunktion verwendet wird.
Diese Funktion führt einen der nachfolgenden Fehlercodes zurück: "OK", "Zeitpunkt_nicht_konform".
Die Funktion "Aufstellung_schreiben" ermöglicht es, der Beobachtungsaufstellung eines Programms eine Registrierung bezüglich des Auftretens eines Ereignisses zu einem gegebenen Zeitpunkt hinzuzufügen. Sie verwendet als Eingangsparameter den Identifikator des betreffenden Programms, den Identifikator des aufgetretenen Ereignisses und den Zeitpunkt seines Auftretens.
Diese Funktion führt einen der nachfolgenden Fehlercodes zurück: "OK", "Id_Programm_nicht_konform", "Id_Ereignis_nicht_konform", "Zeitpunkt_nicht_konform" oder "Registrierer_nicht_aktiv", wenn das Beobachtungsmodul nicht initialisiert ist.
Die Funktion "Letzte_Aufstellung_herausnehmen" ermöglicht es, die letzte Registrierung in der Beobachtungsaufstellung eines Programms zu erhalten. Sie nimmt als Eingangsparameter den Identifikator des betreffenden Programms an und führt den Identifikator des aufgetretenen Ereignisses und den Zeitpunkt seines Auftretens sowie einen der nachfolgenden Fehlercodes zurück: "OK", "Id_Programm_nicht_konform", "Registrierer_nicht_aktiv" und "Ende_Aufstellung", wenn das Ende der Beobachtungsaufstellung erreicht ist.
Die Funktion "Anzahl_Registrierungen_erhalten" ermöglicht es, die Anzahl an in der Beobachtungsaufstellung seit ihrer Initialisierung erfolgten Schreibvorgängen zu erhalten. Diese Funktion führt den Fehlercode "OL" oder "Registrierer_nicht_aktiv" zurück.
Das System 1 ermöglicht schließlich zwei Arten von Beobachtungen, wobei die eine im Anwenderbereich explizit von Zustellfunktionen bereitgestellt wird und die andere im makroskopischen Bereich von dem System 1 erzeugt wird und auf den Registrierer 14 zurückgreift. Die makroskopische Beobachtung ist dazu bestimmt, die Auswirkungen des Systems 1 auf den Echtzeitverlauf der Programme fein aufzuzeichnen. Somit gibt jeder Übergang eines Programms vom inaktiven Zustand 23 in den aktiven Zustand 24 oder Beendigungszustand 25 Anlass zu einer geeigneten, datierten Registrierung in seiner Aufstellung. Eines der Felder der Registrierung enthält entweder einen die Inaktivierung angebenden Code oder das Ereignis, das dem Ereignis-Supervisor, dem Zustell-Supervisor oder jeglichem anderen Programm über die Funktionen "Ereignis_akzeptieren", "Zustellung_akzeptieren" bzw. "Auslösung_akzeptieren" zurückgeführt wird.
Die Übergänge zwischen den Zuständen des von dem System 1 ausgeführten Programms, die Überschreitung der Überwachungsfristen sowie die Aktivierungsanforderungen, die an das Betriebssystem gerichtet werden, sind auch Gegenstand von Registrierungen in einer spezifischen Aufstellung. Jede Registrierung enthält somit ein Ereignis, das in die Warteschlange eines Empfängerprogramms gestellt wurde.
Schließlich geben die Aufforderungen zum Auslösen, Melden oder Zustellen von Ereignissen, die über die Funktionen "Programm_auslösen", "Zusatzprogramm_auslösen", "Verlauf_zustellen" oder "Ereignis_melden" abgegeben werden, Anlass zu einer Registrierung in der Aufstellung des anfordernden Programms. Die Registrierung enthält entweder das bei Aufruf der Funktion bereitgestellte Ereignis oder ersatzweise einen die Funktion kennzeichnenden Code.
Die Auswertung der Beobachtungsaufstellungen ermöglicht es, insbesondere aufgrund der Zeitpunkte das abgelaufene Echtzeitverhalten sämtlicher Programme auszuwerten, ohne dabei auf das Betriebssystem zurückgreifen zu müssen.
Die soeben beschriebene Schnittstelle 6 enthält eine verminderte Anzahl von Funktionen. Sie ist somit einfach auszubilden und bietet dabei die für eine Echtzeitanwendung erforderlichen Zeitverwaltungsfunktionalitäten, und zwar unabhängig von der Architektur derselben. Insbesondere enthält sie eine einzige Funktion ("Programm_auslösen) zum Auslösen und Melden eines Programms. Daraus ergibt sich, dass der Aufbau eines Programms einfach und somit der Auflauf seiner Ausführung leichter zu steuern ist, sofern es nur einen Synchronisierungspunkt aufweist.
Ferner verwaltet das System 1 effektiv dynamische Moduswechsel hinsichtlich der zeitlichen Merkmale der Programme. Das System kann nämlich dynamisch Auslöseparameter (Phase, Periode) der Programme ändern. Bei einem Moduswechsel ermöglicht es ferner, über Übergangszustände zu verfügen, in welchen die Programme noch im vorherigen Modus arbeiten, und gleichzeitig weitere Programme im neuen Modus arbeiten. Die Schnittstelle 6 enthält nämlich die Funktion "Programm_einfrieren", die es ermöglicht, das Auslösen aller betreffenden Programme aufzuschieben, bevor sie zusammen im neuen Modus wieder gestartet werden.
Das Zeitverwaltungssystem 1 erfordert ferner die Verwendung von Einrichtungen, die vom Betriebssystem 11 des Rechners 10 abhängen. In allgemeiner Weise stellt jedes Echtzeitsystem Einrichtungen und Werkzeuge zur Verfügung, welche die angeforderten Funktionalitäten gewährleisten, deren Verwendung für sie jedoch im allgemeinen einmalig und nicht standardisiert ist. Aus diesem Grund enthält das Verwaltungssystem 1 eine Schnittstelle 7 mit dem Betriebssystem, bei welcher ein Vereinheitlichungsbegriff für die Aufrufe eingeführt worden ist, indem den weiteren Diensten Systemaufrufe vorgeschlagen werden, deren Schnittstellen festgelegt sind, deren Implementierung jedoch von dem Zielrechner 10 abhängt.
Die Schnittstelle 7 stellt Einrichtungen zur Synchronisierung, zum Zugang und zum Schutz geteilter Ressourcen, Einrichtungen zum Definieren von Gruppen verbundener Anweisungen und zum Identifizieren von Programmen zusammen.
Die Einrichtungen zur Synchronisierung ermöglichen es, Programme durch Meldungen zur gleichen Zeit zu synchronisieren, ein Kommunikationsmittel zwischen den Programmen durch eine Warteschlange von Meldungen zu bieten. Die Übertragung der Ereignisse zwischen den Programmen bzw. die Aktivierung der Programme verwendet diese Einrichtungen.
Die Synchronisierungseinrichtungen enthalten die nachfolgenden Funktionen:

– "Init_Synchro_Meldung",
– "Empfang_Synchro_Meldung" und
– "Senden_Synchro_Meldung".

Die Funktion "Init_Synchro_Meldung" ermöglicht es, die maximale Anzahl von Meldungen zu definieren, die gesammelt und einem Synchronisierungsobjekt (Mailbox) zugewiesen werden können, das von einem Identifikator bezeichnet wird. Diese Funktion erhält als Eingangsparameter einen Mailbox-Identifikator und die dieser Mailbox zuzuweisende maximale Kapazität. Sie führt einen der nachfolgenden Fehlercodes zurück: "OK", "Id_Mailbox_nicht_konform", wenn der Mailbox-Identifikator nicht vom System erkannt wird, oder "Größe_Mailbox_nicht_konform", wenn die Kapazität der Mailbox die Systembedingungen übersteigt.
Die Funktion "Empfang_Synchro_Meldung" ermöglicht es, den Ablauf eines Programms bis zum Empfang einer Synchronisierungsmeldung zu blockieren. Ein als Parameter dieser Funktion vorgesehener Identifikator bezeichnet das verwendete Synchronisierungsobjekt (Mailbox). Der Aufruf dieser Funktion führt den Identifikator der empfangenen Meldung zurück.
Auch ist eine Überwachungsfrist als Eingangsparameter vorgesehen, um die maximale Dauer der Erwartung einer Meldung zu spezifizieren. Nach Ablauf dieser Frist führt die Funktion den Fehlercode "Frist_überschritten" zurück. Andernfalls führt sie einen der nachfolgenden Fehlercodes zurück: "OK", "Id_Mailbox_nicht_konform" und "Frist_nicht_konform".
Anzumerken ist, dass das Bestehen einer Überwachungseinrichtung von der Implementierung des Echtzeitkerns abhängt, ohne jegliche Bindung mit dem Zeitverwaltungssystem 1.
Die Funktion "Senden_Synchro_Meldung" ermöglicht es, eine Synchronisierungsmeldung zu senden, so dass ein weiteres Programm in Erwartung dieser Meldung freigegeben wird. Ein als Parameter angenommener Mailbox-Identifikator bezeichnet das verwendete Synchronisierungsobjekt. Ein weiterer Eingangsparameter stellt den Identifikator der zu sendenden Meldung bereit.
Diese Funktion führt einen der nachfolgenden Fehlercodes zurück: "OK", "Id_Mailbox_nicht_konform", "Id_Ereignis_nicht_konform" und "Überschreiten_Kapazität", wenn die Meldung deshalb verloren geht, weil die Mailbox voll ist.
Die Einrichtungen zum Schützen der geteilten Ressourcen ermöglichen es, die zwischen mehreren Programmen aufgeteilten Ressourcen zu schützen, indem sie den Zugang nur für eines der Programme gestatten. Diese Einrichtungen ermöglichen es, einen kritischen Abschnitt zu definieren, dessen Ausführung nicht von einem anderen Programm unterbrochen werden darf. Jedoch werden sämtliche Hardware-Unterbrechungen akzeptiert. Ein kritischer Abschnitt darf keine Operation enthalten, bei welcher eine Erwartung vorgesehen ist, die einen Übergang zu einem anderen Programm bewirkt.
Diese Einrichtungen umfassen die Funktionen "Beginn_kritischer_Abschnitt" und "Ende_kritischer_Abschnitt".
Der Aufruf der Funktion "Beginn_kritischer_Abschnitt" hat den Zweck, zu verhindern, dass mehrere Programme (beim Lesen oder Schreiben) gleichzeitig auf Ressourcen zugreifen. Dieser Aufruf hindert andere Programme als das von dem Aufruf angeforderte daran, einzugreifen solange letzterer ihnen nicht explizit die Berechtigung erteilt, ihre Ausführung fortzusetzen. Diese Berechtigung wird durch den Aufruf der Funktion "Ende_kritischer_Abschnitt" gegeben, die das Ende der Verwendung von geteilten Ressourcen bedeutet.
Die Einrichtungen zum Definieren von Gruppen von verbundenen Anweisungen ermöglichen es, die Ausführung eines Blocks von Anweisungen auf "atomare" Weise, d. h. nicht unterbrechbar zu gewährleisten. Mit anderen Worten garantieren sie, dass die Ausführung der in diesem Block enthaltenen Anweisungen nicht von anderen Programmen oder vom System unterbrochen werden kann.
Anzumerken ist, dass die Atomarität nicht vollständig ist, sofern der Block eine Operation enthalten kann, die einen Wartezustand beinhaltet. Daraus ergibt sich ein Übergang zu einem weiteren Programm, das seine eigenen Unterbrechbarkeitskriterien hat.
Die Definition eines nicht unterbrechbaren Blocks von Anweisungen erfolgt über den Aufruf der Funktion "Beginn_atomare_Sequenz" zu Beginn des Blocks und der Funktion "Ende_atomare_Sequenz" am Ende des Blocks. Die Funktion "Beginn_atomare_Sequenz" führt die Maske für Unterbrechungen zum Zeitpunkt ihres Aufrufs zurück, während die Funktion "Ende_atomare_Sequenz" als Eingangsparameter die Maske für Unterbrechungen annimmt, die bei dem Aufruf wieder herzustellen sind.
Die Schnittstelle mit dem Betriebssystem enthält auch eine Funktion zum Identifizieren der Programme "Name_Programm", welche den Identifikator des die Funktion aufgerufenen Programms zurückführt.
Die Schnittstelle 8 mit der Hardware enthält zwei Funktionen, nämlich "Nächste_Aktualisierung_festlegen" und "Aktualisieren".
Die Funktion "Nächste_Aktualisierung_festlegen" ermöglicht es, den dem System 1 internen Fristenzähler 33 auszulösen, um die Frist zwischen dem laufenden Zeitpunkt und dem Zeitpunkt zu zählen, an dem die nächste Aktualisierung der Programmzustände erfolgen soll. Nach Ablauf dieser Frist hat der Zähler die Aufgabe, die Ausführung der Prozedur zum Aktualisieren der Programmzustände zu starten, indem die Funktion "Aktualisieren" aufgerufen wird. Diese Frist wird ausgehend von Zeitinformationen der Programme berechnet, um die Kontrolle der Fälligkeiten bzw. Aufforderungen zum Aktivieren der periodischen Anwendungen zu ermöglichen.
Diese Funktion erhält als Parameter diese Frist, die in der von dem System festgelegten internen Zeiteinheit ausgedrückt wird. Sie führt den Fehlercode "OK" oder "Frist_nicht_konform" zurück, wenn der als Parameter angenommene Wert außerhalb der vom Hardware-Träger gebotenen Zeitauflösung liegt.
Die Funktion "Aktualisieren" ermöglicht es, die aktuell vom System verwalteten Programmzustände zu aktualisieren. Sie gehört zum System 1, wird jedoch von der Hardware 12 über eine Hardware-Unterbrechung aufgerufen, die dem Fristenzähler 33 zugeordnet ist.
Die Schnittstelle 8 wird auch dazu verwendet, eine Hardware-Überwachungsfrist einzuleiten, wenn der Rechner mit Wächtervorrichtungen ausgestattet ist. Immer wenn das System 1 die Funktion "Nächste_Aktualisierung_festlegen" aufruft, um den Zähler 33 zu programmieren, programmiert es parallel dazu die Hardware-Überwachungsfrist mit einem äquivalenten Wert. Da am Ende der Verarbeitung eines Ereignisses das System 1 sehr wahrscheinlich eine Aktualisierung des nächsten Ereignisses verknüpft, wird die Hardware-Überwachungsfrist erneut geladen, bevor das Ende des Zählvorgangs erreicht ist. Dagegen läuft im Falle einer Fehlfunktion des Systems 1 diese Überwachungsfrist ganz ab und löst über eine Hardware-Unterbrechung ein abgelegtes Unterprogramm "Schweren_Fehler_verarbeiten" aus. Das System 1 erspart somit den Programmen, einen gemeinsamen Wächter zu verwalten.
Auf diese Weise brauchen die Anwenderprogramme bezüglich der Echtzeitsysteme aus dem Stand der Technik nicht mehr den bzw. die Wächter des Rechners zu verwalten.
Die Schnittstelle 9 mit dem Zeitgeber 13 ermöglicht es, über Zeitinformationen zu verfügen, deren Quellen von einer Implementierung zur nächsten variieren. Diese Schnittstelle fasst Einrichtungen zusammen, welche die Führung eines Absolutzeit-Zeitgebers 13 gewährleisten, wobei deren Spezifikationen unabhängig von dem Implementierungskontext festgelegt sind.
Der Absolutzeit-Zeitgeber 13 kann initialisiert oder befragt werden. Die der Anwendung 2 über diese Schnittstelle gelieferte Zeiteinheit wird "Bord-Zeiteinheit" genannt. Die über diese Schnittstelle zurückgeführten Zeiten und die aufgrund von unteren Ebenen des Systems manipulierten Zeiten können verschiedene Auflösungen und Präzisionen besitzen. Aus diesem Grund liefert diese Schnittstelle Eingangspunkte, welche die Bordzeit entweder in einer Bordeinheit für den Benutzer oder in einer Einheit nahe der systemintern benutzen Einheit ausdrückt, die auch nahe bei einer Mikrosekunde (μs) vorgesehen ist. Diese Schnittstelle erfordert somit, dem System die Umsetzungsverhältnisse zwischen den Einheiten "Benutzer" und "System" und der Mikrosekunde zu liefern.
Die Zeiten werden innerhalb eines Zeitraums ausgedrückt, der von der Implementierung abhängt. Somit ist es möglich, zwecks Leistung des Zeitgeber-Verwalters Negativwerte zuzulassen.
Diese Schnittstelle enthält die nachfolgenden Funktionen:

– "Erhalt_Einheit_Benutzer", die ermöglicht, die Bord-Zeiteinheit des Zeitgebers in Mikrosekunden ausgedrückt zu erhalten,
– "Erhalt_Einheit_Dienst", die ermöglicht, die in Mikrosekunden ausgedrückte Einheit der dem Zeitverwaltungssystem 1 über den Zeitgeber 13 bereitgestellten Zeit zu erhalten,
– "Erhalt_Zeit_max", die ermöglicht, den maximalen Systemeinheitswert der absoluten Zeit zu erhalten, den die Repräsentation gestattet, die den vom Zeitgeber dem System gelieferten Zeiten zugeordnet ist,
– "Initialisieren", die es ermöglicht, den Zeitgeber 13 bei einem anfänglichen Referenzwert zu initialisieren, der bei der Implementierung gewählt wird,
– "Lesen_Zeit_Benutzer", die es ermöglicht, den laufenden Zeitpunkt zu erhalten, der in der Benutzereinheit bezüglich der absoluten Referenzzeit ausgedrückt wird, die durch Aufrufen der Funktion "Initialisieren" definiert wird,
– "Lesen_Zeit_Dienst", die es ermöglicht, den laufenden Zeitpunkt zu erhalten, der in der Einheit der dem System gelieferten Zeiten ausgedrückt wird, indem als Referenz der Zeitpunkt genommen wird, an dem der Zeitgeber durch Aufrufen der Funktion "Initialisieren" initialisiert wird.

Insbesondere entspricht der maximale Wert des absoluten Zeit, der durch die Funktion "Erhalt_Zeit_max" geliefert wird, der maximalen Abweichung, die zwischen einem absoluten Zeitpunkt und dem laufenden Zeitpunkt bestehen kann.
Das Zeitverwaltungssystem 1 erfordert die Erfassung einer absoluten lokalen Zeit, die vom Zeitgeber 13 bereitgestellt wird und deren anfänglicher Wert willkürlich definiert ist, wobei das Starten ausgehend von diesem Wert durch die Funktion "Initialisieren" gesteuert wird. Da dieser Zeitgeber beim Algorithmus zum Aktualisieren der Zustände der Programme oder bei der Registrierung von Ereignissen in der Beobachtungsaufstellung verwendet wird, erfolgt jegliche Bezeichnung der absoluten Zeit bei der Verwendung des Zeitverwaltungssystems 1 im Verhältnis mit diesem Zeitgeber.
Die als Parameter beim Aufrufen der Funktion "Programm_auslösen" verwendete Phase ermöglicht es, die Zeitpunkte der Anforderungen zum Aktivieren der periodischen und nicht periodischen Anwendungen zeitlich zu verteilen. Sie bezieht sich stets auf einen sogenannten Referenzzeitpunkt.
Diese Referenzzeit wird anfänglich durch Aufrufen der Funktion "Referenzzeit_definieren" definiert.
Die Phase der ersten periodischen Anwendung, deren Auslöseanforderung beim System 1 erfolgt, bezieht sich auf diese Referenzzeit. In der Folge wird die Phase der erneuten periodischen und nicht periodischen Anwendungen bezüglich einer Referenzzeit ausgedrückt, die in Abhängigkeit von der Phase dieser ersten Anwendung und bezüglich ihrer nächsten Aktivierungsanforderung periodisch erneut berechnet wird.
Andererseits wird diese Referenz regelmäßig reaktualisiert, sie behält eine dauerhafte Bedeutung bei, um die Phase der erneuten Anwendungen über eine lange Zeitskala zu definieren. Wenn dagegen die Referenz der Phasen statisch wäre, ruft die Zuordnung einer Phase bei einer erneuten Aktivierung größere Berechnungen hervor, die Ressourcen verbrauchen.
Der Benutzer kann jederzeit eine neue absolute Referenzzeit mit Hilfe des gleichen Aufrufs der Funktion "Referenzzeit_definieren" definieren. Die bereits vom System kontrollierten Anwendungen unterliegen keiner Änderung. Der Prozess zum Aktualisieren der Bezugszeit ist der gleiche wie anfänglich. Die Anwendung, deren Informationen zum Aktualisieren der Referenzzeit verwendet werden, ist die erste, deren Auslöseanforderung dieser Änderung der Referenzzeit durch den Benutzer folgt.
7 zeigt den Betrieb und die Verwendung der Referenzzeit. Diese Figur stellt in Form von Ablaufdiagrammen die Zeiträume dar, bei denen drei Programme N1, N2, N3 von der Verarbeitungseinheit ausgeführt werden.
Zum Zeitpunkt t0 wird die Referenzzeit tref beispielsweise durch eine in dieser Figur nicht dargestellte Anwendung definiert, welche die Funktion "Referenzzeit_definieren" aufruft. Zum Zeitpunkt t1 wird die periodische Anwendung N1 mit einer Phase von 5 ms und einer Periode von 20 ms angesetzt. Diese Anwendung ist somit die erste, die von dem Zeitverwaltungssystem nach der Definition der Referenzzeit tref berücksichtigt wird. Die Anwendung N1 wird somit zum ersten mal zum Zeitpunkt tref+5 aktiviert und wird einige Augenblicke später in Abhängigkeit von der Belegung der Verarbeitungseinheit ausgeführt.
Zum Zeitpunkt t2 wird die periodische Anwendung N2 mit einer Phase von 30 ms und einer Periode von 40 ms angesetzt. Die zum Starten der Anwendung N2 verwendete Referenzzeit ist die Zeit tref.
Gerade vor Aktivierung der Anwendung N1 zum Zeitpunkt tref+5 definiert das Verwaltungssystem 1 erneut die Referenzzeit tref mit tref1, die der Zeit tref entspricht, welcher die Periode der Anwendung N1 hinzugefügt wurde, oder aber dem Zeitpunkt der nächsten Aktivierung der Anwendung N1, von der die Phase der Anwendung N1 abgeleitet wird.
Einige Millisekunden nach dem Ende der ersten Ausführung der Anwendung N1 wird zum Zeitpunkt t3 die Anwendung N3 mit einer Phase und einer Periode von 60 ms angesetzt. Das System 1 berechnet somit den Zeitpunkt zum Auslösen der Anwendung N3 ausgehend von der neuen Referenzzeit tref1, d. h. zum Zeitpunkt tref1+60. Parallel dazu löst das System periodisch die Anwendungen N1 und N2 aus, indem es sich auf deren jeweilige Periode stützt. Ferner wird gerade vor der nächstfolgenden Aktivierung der Anwendung N1 die Referenzzeit erneut definiert, um tref 2 zu werden, die auf eine spätere Periode der Anwendung N1 festgelegt ist. Die Referenzzeit wird somit zu jeder Periode der Anwendung N1 erneut definiert.
Auf diese Weise findet eine vereinfachte Datierung Anwendung, die vermeidet, die absoluten Zeiten einer großen Dynamik zu manipulieren, d. h. ausgedrückt in Form von großen Binärworten. Dies hat zur Folge, dass die von dem Zeitgeber bereitgestellte Zeit periodisch null wird. Es ergibt sich auch, dass zum Vermeiden der Gefahr von äquivalenten Zeitpunkten das System 1 vorgeben muss, dass die als Parameter der Funktionen der Schnittstelle 6 vorgesehenen Zeiten von der laufenden Zeit um weniger als die halbe Dynamik der Zeit des Zeitgebers 13 entfernt sind.
Dann wird zum Zeitpunkt t4 die Referenzzeit von einer Anwendung geändert, um tref* zu werden, beispielsweise von der Anwendung N1 durch Aufrufen der Funktion "Referenzzeit_definieren", wobei tref* die neue Referenz für sämtliche Anwendungen wird, die nach dem Zeitpunkt t4 vorgesehen sind. Somit wird zum Zeitpunkt t5 die Anwendung N2 erneut mit einer Phase von 30 ms und einer Periode von 50 ms vorgesehen, wobei dieses Vorsehen der Anwendung N2 zur Definition einer erneuten Referenzzeit tref* führt, die gleich dem Zeitpunkt der nächstfolgend vorgesehenen Aktivierung von N2 ist, an dem die Phase abgeleitet wurde. Wie vorangehend erläutert wurde, wird zu jeder erneuten periodischen Aktivierung von N2 die Referenzzeit erneut definiert, um tref*2 zu werden, usw.
Anzumerken ist, dass das Einfrieren der bei der Aktualisierung der Referenzzeit verwendeten Anwendung keinerlei künftige Auswirkung auf diese Berechnung hat. Die Informationen, die ermöglichen, jederzeit die Referenzzeit zu berechnen, werden kontinuierlich aktualisiert, selbst dann, wenn diese Anwendung nicht mehr aktiviert ist.
Die Überwachung einer Fälligkeit besteht darin, die Dauer einer Anwendung von seiner Aktivierungsanforderung durch das System 1 bis zum Ende seiner Ausführung zu überwachen. Bei jeder Aktivierungsanforderung einer Anwendung wird die Überwachungseinrichtung erneut aktualisiert, wenn die Überwachung der Fälligkeit für die betreffende Anwendung effektiv ist.
Insbesondere wenn das System Aktivierungsanforderungen für eine überwachte Anwendung ausführt, während die seiner letzten Aktivierung entsprechende Ausführung nicht beendet ist, werden die Informationen der Einrichtung zum Überprüfen der Fälligkeiten für jede Aktivierungsanforderung erneut berechnet und die Kontrolle der Fälligkeit für die laufende Iteration erfolgt nicht mehr.
Somit wird die Überwachung der Fälligkeit der ersten Anwendungsaktivierungsanforderung unterbrochen, wenn eine zweite Anwendungsaktivierungsanforderung stattfindet. Das System 1 geht dann davon aus, dass die Anwendung die Bedingungen hinsichtlich Fälligkeit einhält, wenn das Ende der letzten Ausführung vor der Summe der entsprechenden Fälligkeiten erreicht wird. Dennoch erfolgt keine Überprüfung, um die Einhaltung der Zwischenfälligkeiten zu überprüfen.
Dieses Prinzip hängt damit zusammen, dass eine Vervielfachung von Aktivierungsanforderungen durch das System 1 besteht, ohne dass eine Kontrolle auf das den vorangehenden Aktivierungsanforderungen entsprechende Ausführungsende gerichtet wäre.
Eine dem Benutzer gebotene Lösung, um die Kontrolle der Zwischenfälligkeiten abzusichern, besteht darin, das Einfrieren der Anwendung vor jeglicher Aktivierungsanforderung derselben anzufordern. Somit wird mit Empfang des Ereignisses zum Durchführen des Einfrierens, das von dem Supervisor-Programm erhalten wird, diesem angegeben, dass das Programm effektiv seine vorhergehende Ausführung beendet hat und somit entweder ein Programmkonfigurationswechsel oder eine unmittelbare Auslöseanforderung für dieses Programm erfolgen kann. Jede Ausführung unterliegt somit der Kontrolle der Fälligkeit, die vom Benutzer angegeben wird.
Das Prinzip der Sammlung von Fälligkeiten bei der Ausführung der Programme findet in gleicher Weise bei der Überprüfung der Fälligkeiten zum Verwalten der Ereignisse (Zustellungen oder Hauptereignisse) durch die Supervisor-Programme Anwendung.
In allgemeiner Weise speichert das System 1 in zumindest einer Warteschlange sämtliche Ereignisse, die es verarbeiten soll, um sämtliche Fristen zu verwalten, wobei jedes Ereignis einem absoluten Ausführungszeitpunkt zugeordnet ist. Vorzugsweise verwaltet das System eine Warteschlange durch initialisierte Anwendung. Zu jedem Auftreten eines aufgeschobenen oder wiederholten Ereignisses vergleicht es seinen absoluten Zeitpunkt mit dem des nächstfolgend zu verarbeitenden Ereignisses. Wenn der Zeitpunkt des neuen Ereignisses nicht der der laufenden Zeit am nächsten liegende ist, fügt es das Ereignis in die Warteschlange in Verbindung mit dem Zeitpunkt seiner Anwendung ein. Im gegenteiligen Fall wird die Frist, welche die laufende Zeit mit dem Zeitpunkt der Ausführung von dem neuen Ereignis trennt, in den Zähler 33 geladen und das System 1 versetzt sich in den Schlafzustand. Am Ende der Zählung erzeugt der Zähler eine Unterbrechung, welche das System 1 auslöst, das sämtliche Ereignisse verarbeitet, die zum laufenden Zeitpunkt zu verarbeiten sind.
Wenn das zu verarbeitende Ereignis dem Auslösen eines Zusatzprogramms entspricht, ruft das System das entsprechende Zusatzprogramm auf. Wenn andernfalls das Ereignis einer Aktivierung entspricht und es sich um eine periodische Aktivierung handelt, fügt das System 1 in die Warteschlange ein Ereignis vom Typ periodische Aktivierung zum Zeitpunkt der nächstfolgenden Aktivierung ein und nimmt aus der Warteschlange das eventuell zugeordnete Fälligkeitsüberschreitungsereignis heraus. Wenn es sich ferner um eine periodische Aktivierung mit Fälligkeitskontrolle handelt, fügt es in die Warteschlange ein Fälligkeitsüberschreitungsereignis zum Zeitpunkt der zu programmierenden Fälligkeit ein. Wenn es sich um ein Ereignis vom Typ Zustellung handelt, schiebt das System das Zwischenfälligkeitsüberschreitungsereignis auf. Wenn das Ereignis die Programmierung der Supervisor-Überwachungsfrist oder ein Hauptereignis ist, programmiert es in die Warteschlange des Supervisors ein Überwachungsfristüberschreitungsereignis zum entsprechenden Zeitpunkt.
Dann verfolgt das System die Verarbeitung des Ereignisses, indem es dieses dem Empfängerprogramm anzeigt. Diese Anzeige besteht darin, eine Meldung in eine der beiden Mailboxen abzulegen, die jedem Programm zugeordnet sind. Die eine Mailbox dient nämlich zum Auslösen eines Programms, während die andere der Funktion "Programm_aufschieben" vorbehalten ist. Auf diese Weise ist es möglich, dass das Auslösen und die Fälligkeitskontrolle unabhängig von einer Aufschiebung des Programms fortgesetzt werden. Dann sucht es das nächstfolgend zu verarbeitende Ereignis, lädt den Zähler 33 mit der Frist, die dem Zeitpunkt entspricht, welcher dem Ereignis zugeordnet ist und versetzt sich in den Schlafzustand.
Wenn die in den Zähler 33 einzuprogrammierende Frist höher ist als der maximale Wert des Zählers, lädt das System 1 den Zähler auf seinen maximalen Wert und das nächstfolgend erwartete Ereignis wird als fiktiv betrachtet.
Wenn der neue Befehl in unmittelbarer Ausführung ist, führt das System 1 den Befehl unmittelbar aus.
Das Zeitverwaltungssystem 1 ist so ausgebildet, dass es in den von jeder Verwendung festgesetzten Grenzen die Aspekte einhält, die mit den Belegungsraten der Verarbeitungseinheit und mit der Genauigkeit der mitwirkenden Zeiten (Zeitraum, Fälligkeit, usw.) verbunden sind. Insbesondere soll die zur Aktualisierung der Zustände der Programme verwendete Zeit möglichst kurz sein.
Die Beobachtungsfunktionalität, welche die Verfolgung des Ablaufs der Anwendungen in aufgeschobener Zeit ermöglicht, wird dynamisch durch Programmierung aktiviert bzw. deaktiviert, wenn dessen Vorhandensein über eine Kompilierungsregel bei der Systementwicklung gestattet wird.
Ferner können auch aus Gründen der Leistung bestimmte Überprüfungen, wie etwa die Kohärenz der als Parameter übertragenen Informationen der Aufrufe an das System 1 durch die Kompilierungsregel aktiviert bzw. deaktiviert werden.

Claims

Verfahren zur Zeitverwaltung in einem Echtzeitsystem, bei dem Anwenderprogramme ausgeführt werden und mit Hilfe von in einem Zeitverwaltungssystem übertragenen Befehlen miteinander kommunizieren, wobei die von den Anwenderprogrammen dem Zeitverwaltungssystem übertragenen Befehle Befehle zum Aktivieren eines Anwenderprogramms zu einem bestimmten Aktivierungszeitpunkt enthalten, wobei das Zeitverwaltungssystem bei jedem empfangenen Aktivierungsbefehl die folgenden Schritte ausführt: – Berücksichtigen des Befehls zum Aktivieren eines Anwenderprogramms, – Zuordnen eines Aktivierungsereignisses zum Befehl, welchem Ereignis zumindest ein Ereignisfälligkeitszeitpunkt zugewiesen ist, der dem Zeitpunkt zum Aktivieren des Anwenderprogramms entspricht, und Einfügen des Ereignisses in Verbindung mit seinem Fälligkeitszeitpunkt in eine Liste zu verarbeitender Ereignisse, – Bestimmen des nächstfolgenden Ereignisses aus der Ereignisliste, das in Abhängigkeit von den jeweiligen Fälligkeitszeitpunkten der Ereignisse aus der Liste zu verarbeiten ist, und Aktivieren eines Zählers (33), damit dieser am Fälligkeitszeitpunkt des nächstfolgenden zu verarbeitenden Ereignisses auslöst, und – bei Auslösen des Zählers Aktivieren des dem nächstfolgenden zu verarbeitenden Ereignis zugeordneten Anwenderprogramms, dadurch gekennzeichnet, dass jedes Anwenderprogramm zumindest einen Aufruf eines Aktivierungsrückstellbefehls umfasst, der das Programm über das Zeitverwaltungssystem in einen Aktivierungsrückstellzustand bringt, wobei das Anwenderprogramm, wenn es in einem normalen Betriebsmodus aktiviert wurde, normale Operationen durchführt, bevor es erneut den Aktivierungsrückstellbefehl aufruft.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Anwenderprogramme eine Anwendungsendlosschleife enthalten, in welche der Aufruf des Aktivierungsrückstellbefehls eingefügt ist.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass einem Aktivierungsbefehl für eine Anwendung in Aktivierungserwartung ein Phasenparameter zugeordnet ist, der den Zeitraum zwischen Zeitpunkt für die Aktivierung der Anwendung und einen Bezugszeitpunkt definiert.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass es bei Aktivierung einer Anwendung in Aktivierungserwartung die Übertragung eines Zustandsparameters zur zu aktivierenden Anwendung umfasst, der auf einem Normalwert liegt, um der Anwendung zu melden, dass es normale Operationen durchführen soll, oder auf einem Endwert, um der Anwendung zu melden, dass sie sich beenden soll.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass es die Bereitstellung eines Zeitgebers für einen laufenden Zeitraum mit begrenzter Dynamik, die Definition eines Referenzzeitpunkts über ein Anwenderprogramm und die Aktualisierung des Referenzzeitpunkts zu jedem Zeitraum der ersten periodischen Anwendung umfasst, die der genannten Definition des Referenzzeitpunkts folgend aktiviert wird.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass zum Aktivieren einer periodischen Anwendung in Aktivierungserwartung dem Aktivierungsbefehl ein Zeitraumparameter zugeordnet ist, der ein Aktivierungszeitraum für die Anwendung definiert, und dass bei Aktivierung einer periodischen Anwendung das Zeitverwaltungssystem in die Liste der zu verarbeitenden Ereignisse ein Aktivierungsereignis einfügt, das einem Aktivierungszeitpunkt zugeordnet ist, der dem laufenden Zeitraum entspricht, dem der Zeitraum der Anwendung hinzugefügt ist.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass dem Aktivierungsbefehl für eine Anwendung ein Fälligkeitsparameter zugeordnet ist, der eine maximale Zeitdauer zum Durchführen einer Anwendung definiert, und dass das Zeitverwaltungssystem überwacht, ob die Durchführung der Anwendung während dieser Zeitdauer erfolgt.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass zum Überwachen der Zeitdauer zum Durchführen einer Anwendung das Zeitverwaltungssystem Schritte ausführt, die darin bestehen, – bei Aktivierung einer Anwendung in eine Liste zu verarbeitender Ereignisse ein Fälligkeitsereignis zum Beenden der Anwendung einzufügen, dem ein Zeitpunkt zugeordnet ist, der dem laufenden Zeitraum entspricht, dem die Fälligkeit der Anwendung hinzugefügt ist, – bei Beendigung der Durchführung der Anwendung, und zwar bevor das entsprechende Fälligkeitsereignis zur Anwendung gelangt, das Fälligkeitsereignis zum Beenden der Anwendung von der Liste der zu verarbeitenden Ereignisse zurückzunehmen, – bei Auftreten des Fälligkeitsereignisses zum Beenden der Anwendung, die einer Fälligkeitsüberschreitungsmeldung zu einem Supervisor-Programm zu übertragen.
Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass dann, wenn eine gerade erfolgende Anwendung vor Ablauf ihrer maximalen Durchführungsdauer aktiviert wird, das Zeitverwaltungssystem überwacht, ob die Durchführung der Anwendung während einer Zeitdauer gleich der n- fachen maximalen Zeitdauer der Durchführung der genannten Anwendung ab dem Zeitpunkt der ersten Durchführung der genannten Anwendung erfolgt, wobei n die Anzahl von Aktivierungen der genannten Anwendung ist, die aufeinanderfolgend durchgeführt werden.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass es für jede Anwendung die Registrierung sämtlicher Tätigkeiten des Zeitverwaltungssystems in einer Aufstellung datierter Beobachtungen umfasst, um die Anwendung in Aktivierungserwartung zu versetzen oder sie aus einer Aktivierungserwartung herauszunehmen.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Registrierung der Beobachtungsaufstellungen über eine Quellcode-Kompilierungsregel bei der Systementwicklung aktiviert wird.
Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass es ferner die Anweisung eines Supervisor-Programms bei dem Zeitverwaltungssystem und die unmittelbare oder verzögerte Berücksichtigung von Ereignissen durch das Supervisor-Programm umfasst, die von den weiteren Anwendungen erstellt werden, wobei das Supervisor-Programm dazu über das Zeitverwaltungssystem aktiviert wird.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass es die Zustellung eines Ereignisses zu dem Supervisor-Programm über eine Anwendung umfasst, wobei dieser Zustellung eine maximale Frist bis zur nächsten Zustellung eines weiteren Ereignisses zugeordnet ist, die über die gleiche Anwendung nach einer Folge von Anweisungen erfolgt ist, deren Ausführung zu überwachen ist, sowie das Ausgeben einer Teilfälligkeitsüberschreitungsmeldung von dem Zeitverwaltungssystem zum Supervisor-Programm, wenn die Ausführung der Folge von Anweisungen nicht in der maximalen First erfolgt ist.
Verfahren nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass das Zeitverwaltungssystem die Zeitdauer überwacht, welche das Supervisor-Programm braucht, um ein Ereignis oder eine Fehlermeldung zu verarbeiten, wobei es im Falle des Überschreitens einer maximalen Frist ein Notprogramm aufruft.
Verfahren nach einer dem Ansprüche 1 bis 14, dadurch gekennzeichnet, dass es ferner einen Schritt zum Wechseln des getakteten Betriebsmodus umfasst, der das Blockieren der Aktivierung der von dem Moduswechsel betroffenen Anwendungen und die Aktivierung dieser Anwendungen mit Zeitparametern umfasst, die dem neuen Betriebsmodus entsprechen, sowie mit einem Modusparameter, um den Anwendungen anzugeben, in welchem Modus sie arbeiten sollen.
Echtzeitsystem mit Anwenderprogrammen (2), einer Verarbeitungseinheit (12), einem Echtzeitbetriebssystem (11), einem Echtzeit-Zeitgeber (13) und einem Zeitverwaltungssystem (1), das Einrichtungen (3) zum Aktivieren und Deaktivieren der Anwenderprogramme (2) zu bestimmten Zeitpunkten und zum Ausführen derselben zusammenfügt, wobei diese Einrichtungen in einer von der Verarbeitungseinheit (12), vom Betriebssystem (11) und von dem Zeitgeber (13) unabhängigen Art und Weise ausgeführt sind, dadurch gekennzeichnet, dass jedes Anwenderprogramm zumindest einen Aufruf eines Aktivierungsrückstellbefehls umfasst, der die Anwendung in einen inaktiven Zustand (23) bringt, in dem sie in Erwartung einer Aktivierung durch das Zeitverwaltungssystem (1) ist, wobei das Anwenderprogramm ferner zumindest einen aktiven Zustand (24) aufweist, in dem es normale Operationen ausführt, bevor es erneut den Aktivierungsrückstellbefehl aufruft, sowie einen Beendigungszustand (25), in dem es Beendigungsoperationen ausführt, bevor es sich selbst beendet.
System nach Anspruch 16, dadurch gekennzeichnet, dass es eine Schnittstelle (6) zwischen den Anwenderprogrammen (2) und dem Zeitverwaltungssystem (1) enthält, wobei diese Schnittstelle Zeitverwaltungsfunktionen vereint, die von den Anwenderprogrammen aufgerufen werden.
System nach Anspruch 17, dadurch gekennzeichnet, dass die Schnittstelle (6) zwischen den Anwenderprogrammen (2) und dem Zeitverwaltungssystem (1) eine Aktivierungsrückstellfunktion enthält, über welche die Anwendung, welche diese aufruft, in den inaktiven Zustand (23) gebracht wird, sowie eine Auslösefunktion für eine Anwendung, um die Ausführung einer Anwendung im inaktiven Zustand auszulösen.
System nach Anspruch 18, dadurch gekennzeichnet, dass die Funktion zum Auslösen einer Anwendung als Eingangsparameter einen Parameter annimmt, welcher den Zeitpunkt angibt, an dem die Ausführung der Anwendung ausgelöst werden soll, einen Zeitdauerparameter, der eine Ausführungszeitdauer angibt, wenn die Anwendung periodisch ist, einen Fälligkeitsparameter, der die maximale Zeitdauer der Ausführung der Anwendung bestimmt, einen Zustandsparameter, der angibt, ob die Anwendung normal ausgeführt oder beendet werden soll, und einen Modusparameter, der die Ausführung bzw. Beendigung der Anwendung kennzeichnet.
System nach einem der Ansprüche 16 bis 19, dadurch gekennzeichnet, dass die Schnittstelle (6) zwischen den Anwenderprogrammen (2) und dem Zeitverwaltungssystem (1) eine Funktion zum Einfrieren der Anwendung enthält, um die Aktivierung einer Anwendung in Aktivierungserwartung zu verhindern oder die Rückkehr einer Anwendung in den inaktiven Zustand zu melden, wenn diese nicht in Aktivierungserwartung ist.
System nach einem der Ansprüche 16 bis 20, dadurch gekennzeichnet, dass sämtliche Zugänge zu den Funktionen des Betriebssystems und des Zeitgebers, die für das Zeitverwaltungssystem erforderlich sind, in Schnittstellen (7, 8, 9) zusammengestellt sind, die in Abhängigkeit von dem Betriebssystem (11), der Verarbeitungseinheit (12) und dem Zeitgeber (13) ausgeführt sind.
System nach einem der Ansprüche 16 bis 21, dadurch gekennzeichnet, dass es einen Wächter enthält, um die Ausführung der von dem Zeitverwaltungssystem (1) durchgeführten Operationen zu überwachen, dessen Aktualisierung auf Kommando eines Zählers (33) getaktet ist, der dazu bestimmt ist, das nächstfolgende zu verarbeitende Ereignis auszulösen.