Real Time Specification for Java Echtzeitfähigkeit mit Java auf Systemen mit geringen Ressourcen

Eingeschränkte Ressourcen und Echtzeitfähigkeit: Im Automobilbau oder der Luftfahrt kommen vermehrt Echtzeitbetriebssysteme zum Einsatz. In unserem Beitrag stellen wir Ihnen die Erweiterungen der Real Time Specification for Java vor.

Anbieter zum Thema

ROHM Semiconductor GmbH

N & H Technology GmbH

DMB Technics AG

Mixed Mode GmbH

Bereits 1999 wurden die Requirements für eine Echtzeiterweiterung der Java Spezifikation vom „National Institute of Standards and Technology“ (NIST) veröffentlicht. Daraufhin wurden zwei unterschiedliche Spezifikationen. Der erste Lösungsansatz wurde vom „J Consortium“ vorgestellt. Die Spezifikation wurde unter dem Namen „The Real-Time Core Extension“ veröffentlicht. Diese ist bis heute immernoch im Entwicklungsstadium und es existiert keine bekannte Referenzimplementierung.

Der zweite Lösungsansatz ist die RTSJ der „Real-Time for Java Expert Group“ (RTJEG). Diese Spezifikation definiert eine neue API, die auf „Java Virtual Machine“ (JVM) aufsetzt. Eine Referenzimplementierung ist bereits in die Spezifikation aufgenommen worden. Die RTSJ wurde als Erweiterung der „Java Standard Editon“ (J2SE) entwickelt und nicht für die „Java Micro Edition“ (J2ME). Theoretsch sollten alle Applikationen, die bisher für die J2SE geschrieben wurden, auf einer Implementierung der RTSJ laufen sollten.

Die komplette RTSJ ist sehr komplex. Dadurch ist allerdings auch der Memory Footprint gewachsen. Eine JVM nach RTSJ mit einem darunterliegenden RT-Linux als Echtzeitbetriebssystem hat eine Größe von 5 MByte. Damit ist die RTSJ für die meisten Systeme mit eingeschränkten Ressourcen erst einmal zu groß. Aber die Hersteller der Real-Time Java VMs haben oftmals eigene Lösungen parat, um dieses Problem in den Griff zu bekommen. Hierfür werden unterschiedliche Compiler- und Linkerverfahren eingesetzt, sowie oftmals nur eingeschränkte Standardbibliotheken zur Verfügung gestellt.

In der RTSJ werden sieben Leitlinien definiert. Diese sollen die Ziele der Real-Time Spezifikation aufzeigen:

• Applicability to Particular Java Environments: Die RTSJ soll in allen Java Umgebungen einsatzfähig sein und darf deswegen keine Bibliotheken und Spezifikationen nutzen, die sie an ein bestimmtes „Java Developement Kit“ (JDK) oder eine Edition binden würde.

• Backward Compatibility: Alle nach dem Java Standard geschriebenen Applikationen sollen auf einer Implmentierung der RTSJ lauffähig sein.

• Write once, Run Anywhere: Die Portabilität verliert im Bereich Embedded Systems nicht ihre grundsätzliche Bedeutung, muss aber auf Grund der Plattformvielfalt manchmal zurückstecken.

• Current Practice Vs. Advanced Features: Die RTSJ muss aktuelle Standards unterstützen, aber auch Platz für Erweiterungen bieten.

• Predictible Execution: Die Sicherheit und Vorhersagbarkeit hat in der RTSJ höchste Priorität. Dies kann zu Lasten der Performance gehen.

• No Syntactic Extension: Die RTSJ soll keine neuen Schlüsselwörter oder syntaktische Erweiterungen einführen um die Arbeit und die Einarbeitungszeit der Tool-Entwickler und Programmierer zu minimieren

• Allow Variation in Implementation Decisions: Die RTSJ versucht dem Entwickler nicht vorzuschreiben, wie er die Applikation umzusetzen hat.

Die erste große Erweiterung betrifft die Zeit/Timer. Java selbst bietet eine Auflösung in Millisekunden an. Viele Systeme brauchen eine deutlich bessere Auflösung. Die RTSJ erweitert diese auf den Nanosekundenbereich. Hierfür wird der long Wert (64 Bit) für Millisekunden um einen integer Wert (32 Bit) für Nanosekunden erweitert. Dabei wird der Millisekundenwert alle 1.000.000 Nanosekunden inkrementiert. Das stellt die Kompatibilität zur Auflösung von Standard Java sicher.

Zugriff und Berechnungen von Zeiten werden in der abstrakten Klasse HighResolutionTime umgesetzt. Diese bietet die Klassen AbsoluteTime und RelativeTime sowie das Interface Comparable zum einfachen Vergleichen von Zeiten an. Mit AbsoluteTime wird die exakte Zeitangabe dargestellt: 11.06.2010, 19:30 Uhr. Das erste darstellbare Datum ist, wie in der IT-Branche üblich, der 1.1.1970, 00:00:00 Uhr GMT.

Von diesem Datum an lassen sich sämtliche Zeitpunkte bis in etwa 292 Millionen Jahren auf die Nanosekunde genau angeben. AbsoluteTime ist mit der Standard Klasse java.util.date kompatibel. RelativeTime repräsentiert Zeiträume, wie Stunden. Da der vorher schon beschriebene Datentyp verwendet wird. Lassen sich Zeiträume zwischen einer Nanosekunde und 292 Millionen Jahre festlegen.

Die zwei Schwächen bei der Zeitenverarbeitung

Früher konnten zusätzlich mit der Klasse RationalTime Zeitintervalle vorgegeben werden. Diese Klasse wurde jedoch in der RTSJ 1.0.1 nicht weitergeführt, da das zugrundeliegende Konzept mit der RTSJ keine geeignete Umsetzung erlaubt. Die Klasse ist inzwischen als „deprecated“ gekennzeichnet. Insgesamt offenbart die Klasse HighResolutionTime zwei Schwächen.

Erstens müssen Zeiten mit Bedacht bearbeitet werden. Der Nanosekundenwert darf nicht >999.999 sein. Dann erfolgt das Inkrementieren des Millisekundenwertes. Da der Nanosekundenwert ein Integer ist, kann er allerdings unbemerkt mit größeren Werten initialisiert werden.

(ID:26657820)