Real Java für Real-Zeit-Applikationen
plus Java public-domain experimentelle Software

Speicherverwaltung

Für die Freigabe von alloziierten Speicherbereichen benutzt Java keine delete- oder free-Funktion, sondern wenn mehr Speicher benötigt wird (new-Operator) als z.Z. im Heap vorhanden ist, werden alle laufenden Tasks für eine Weile suspendiert, während der Garbage Collector den gesamten Speicher untersucht und nach Blöcken sucht, zu denen es keine Referenz mehr gibt. Diese Blöcke werden als frei markiert und können wieder alloziiert werden. Man kann nicht vorhersagen wann und für wie lange der Garbage Collector aktiviert wird, und der Gargabe Collector kann nicht unterbrochen werden, bis er fertig ist. Dies kann das gesamte Timing der Applikation über Bord werfen und kritische Deadlines können verpaßt werden. Dies kann wiederum zu einem Systemversagen führen.

Eine Alternative ist hier ein inkrementeller Garbage Collector, der seine Aufgabe in kurze Phasen aufteilen kann. Ein inkrementeller Garbage Collector kann immer dann, wenn der Prozessor keine zeitkritischen Aufgaben ausführt, für eine kleine überschaubare Zeit aktiviert werden. Solch ein Garbage Collector gehört noch nicht zur Standard-Java-Umgebung, aber es sind bereits einige mit experimentellem Charakter fertiggestellt worden. Andere sind dabei, eine Java-Virtuelle-Maschine ohne Garbage Collector zu implementieren. An der Stelle wird eine delete-Funktion, wie man sie von C gewohnt ist, angeboten. Dies ist eine gute Lösung für kompakte eingebettete Systeme.

Das Sicherste für zeitkritische Aufgaben ist, alle benötigten Speicherbereiche im voraus, bei der Initialisierungsphase, zu alloziieren und während der Regelungs- oder Steuerungsaufgabe überhaupt keinen weiteren Speicher mehr zu alloziieren (keinen new-Operator und keine delete-Funktion mehr zu benutzen).

Ein ähnliches Problem, aber nicht Java-spezifisch, kommt vom virtuellen Speicher. Wenn der benötigte Speicherbereich ausgeswapt (ausgelagert) wurde, muß der betroffene Task warten, bis der Speicherbereich von der Festplatte zurückgeholt wurde. Dies kann wiederum das gesamte Timing des Programms ruinieren. Deswegen wird bei zeitkritischen Systemen kein virtueller Speicher benutzt, oder die benötigten Bereichen müssen gelockt (unswapbar) sein.

I/O

Die Einbettung von Java in eine spezielle Hardware (mit Sensoren und Aktuatoren) ist nicht vorgesehen. Es ist nicht möglich, auf bestimmte Register oder Adressen zuzugreifen. Man muß eine abstrakte Schnittstelle benutzen, die mittels einer anderen Programmiersprache (z.B. C) implementiert wurde. Bei der Erstellung von Java-Prozessoren soll sich das ändern. Diese Prozessoren sollen einen erweiterten Bytecode haben, der es erlaubt, auf bestimmte Adressen zuzugreifen. Es ist aber noch nicht definiert, wie man aus Java diese Funktionalität benutzen kann.

Das zweite Problem ist, daß Java nicht für asynchronen I/O (interruptsgesteuert) konzipiert ist. Eine einfache Lösung ist ein Thread (Task) pro Interrupt zu haben. Beim Eintreten eines Interrupts wird der passende Thread vom Laufzeitsystem aktiviert. Dies gehört nicht zur Standard-Java-Umgebung, kann aber einfach implementiert werden, wenn das System eingebettet wird.

Auf der anderen Seite sind asynchrone Interrupts ein Risiko wegen ihrer Unvorhersehbarkeit (Undeterminismus) bei der Ausführung der Tasks. Der Programmierer muß sehr aufpassen und atomare Blöcke definieren, weil der Scheduler sonst jeden Task an beliebigen Stellen unterbrechen kann, um andere Tasks fortzusetzen. Das kann unerwartete Nebenwirkungen haben. Bei sicherheitsrelevanten Systemen wird empfohlen, periodisch die Interruptquellen zu checken, und wenn nötigt, die passenden Server zu aktivieren. Ein asynchroner Interrupt soll nur zugelassen werden, wenn er eine gefährliche Ausnahme signalisiert. In diesem Fall muß eine Ausnahmebehandlung eingeleitet werden und die laufenden Tasks werden nicht unterbrochen, sondern abgebrochen. Nach der Ausnahme-Behandlung wird ein Recovery durchgeführt, und die normal laufenden Tasks werden wieder gestartet.

Scheduler

Der Standard-Java-Scheduler ist nicht für Real-Zeit-Applikationen konzipiert. Deadlines und Zeitfenster werden nicht unterstützt. In der Regel hat man einen nicht preemptiven Scheduler, der nicht in der Lage ist, Tasks ohne ihre aktive Beteiligung zu unterbrechen. Dadurch sind Timeouts nicht möglich.

Wir haben einen experimentellen Real-Zeit-Scheduler geschrieben, bei dem die Tasks ihre Zeitanforderungen anmelden können und er versucht, (ohne Garantie) diese Anforderungen zu erfüllen. Dieser Scheduler wird als Public-domain-Software unter der am Ende genannten URL angeboten.

Ein Framework-Beispiel mit einem Real-Zeit-Kern

Dieses Beispiel ist ein sehr kleines Framework. Große Frameworks können Tausende von Klassen haben.

Die Klasse TimeInterval gehört nicht zum Framework, sie ist nur eine Hilfe für die Behandlung von Zeitintervallen. Sie stellt Methoden zum Messen, Markieren und Vergleichen von Zeitpunkten und Zeitintervallen zur Verfügung .

Das Framework bietet einen Interrupt-Mechanismus und einen zeitgesteuerten Scheduler an. Diese Mechanismen aktivieren die passenden TimedEvents (Tasks) zur passenden Zeit oder als Reaktion auf Interrupts. Die im Framework definierten TimedEvents sind nur Platzhalter. Der Anwender soll seine gewünschte Funktion in eine Subklasse (vererben) von TimedEvent schreiben und die entsprechende Methode handle() und/oder interruptHandle() überladen. Ist dies geschehen, aktiviert das Framework automatisch die vom Anwender definierten Methoden zum passenden Zeitpunkt.

Der andere Anpassungsanschluß ist die OnGoing-Klasse. Damit kann ein ongoing zeitgebundener Task implementiert werden. Dieser Task läuft unabhängig von Scheduler und Interrupts, aber er kann sich mit Interrupts und/oder Zeit synchronisieren, indem er auf solche Ereignisse wartet. Dafür stellt die OnGoing-Klasse Methoden zur Verfügung. Der Benutzer soll seine gewünschte Funktionalität in einer Subklasse vom OnGoing schreiben und die Methode run() überladen.

Interruptbehandlung

Die Klasse InterruptTable verwaltet die Interrupts und ihre Server. Die Interrupts werden nicht durch Nummern sondern durch Namen (String) identifiziert. TimedEvents können sich als Server mittels der Methode InterruptTable.register() anmelden und mittels der Methode InterruptTable.cancel() abmelden. Das Feld TimedEvent.interruptIds enthält eine Liste von Interruptnamen, getrennt durch einen Blank " " (z.B. "hot cold low"), die der Server (eine Subklasse von TimedEvent) behandeln soll. Ein Interrupt wird signalisiert, indem der Interrupterzeuger die Methode InterruptTable.raise(id) mit dem Name des Interrupts als Parameter aufruft. Die InterruptTable aktiviert dann alle angemeldeten Server, die diesen Name in ihrer Liste halten, d.h er ruft ihre interruptHandle()-Methode auf.

Beispiel von einem Interrupt-Server:

 

Zeitgesteuertes Scheduling (Prozessorzuteilung)

Die Klasse RTScheduler ist ein zeitgesteuerter Scheduler, bei der sich TimedEvents mit ihren Zeitanforderungen anmelden können. Der Scheduler versucht, diese Zeitanforderungen zu erfüllen und die TimedEvents werden zum bestmöglichen Zeitpunkt aktiviert, d.h. ihre handle()-Methode wird aufgerufen. Das Feld TimedEvent.programedTime beinhaltet den Zeitpunkt (in Millisekunden), wann dieser Task zum ersten Mal bzw. zum nächsten Mal aktiviert werden soll. Das Feld TimedEvent.cycleTime bestimmt die Periode in Millisekunden für zyklische Ausführungen des Tasks. Wenn die cycleTime gleich null ist, dann wird der Task nur einmal aktiviert bzw. wenn er bereits läuft, dann wird er nicht wieder aktiviert.

Für die Registrierung von Tasks bietet der RTScheduler mehrere Methoden an. Beispiele davon sind:

• at(time,...) : für einmalige Aktivierung, zum gegebenen Zeitpunkt.
• every(cycle,..): für wiederholte Aktivierung mit der gegebenen Periode.
• after(time,..): für einmalige Aktivierung nach der gegebenen Zeit.
• schedule(...): für Aktivierung, wie es in den Feldern programedTime und cycleTime angegeben ist.

 

Ein Task kann durch die RTScheduler.cancel()-Methode abgemeldet werden.

Beispiel von einem zeitgebundenen Task

 

OnGoing

Eine OnGoing-Subklasse hat keine handle()-Methode, sondern sie führt die run()-Methode, so lange es nötig ist, aus. Damit andere Tasks arbeiten können, muß ein Ongoing-Task den Prozessor abgeben (yield()-Methode) oder wait()-Methoden aufrufen. OnGoing stellt einige Methoden zur Zeit- und Interrupt-Synchronisierung zur Verfügung. Z.B:

• waitInterrupt(timeout): wartet auf einen der in interruptIds genannten Interrupts, aber nicht länger als das angegebene Timeout.
• waitTime(time): Wartet so lange wie angegeben.
• waitUntil(time): Wartet bis zum angegebenen Zeitpunkt.

 

Beispiel von einem Ongoing-Task mit Interrupt-Synchronisierung: