Echtzeitfähiges Java ist keine Vision mehr

IT-Dienstleistungen aus dem Internet werden von Maschinen erbracht. Immer häufiger sind aber auch diejenigen, die diese Dienste anfordern Maschinen, und zwar nicht im Sinn von Mittlern – das ist eh klar – sondern im Sinne eines wirklichen Urhebers. Das gilt in erster Linie für alle Bereiche der Produktions- und Leittechnik sowie der lebenserhaltenden Systeme im Gesundheitswesen, der Luft- und Raumfahrt und der Wehrtechnik. Trotz mancher Schwächen stellen diese Branchen immer noch die Quelle europäischen Wohlstands dar.
Wenn die informationstechnische Seite der Produktionstechnik zumindest in den Medien eher ein Schattendasein führt, dann vermutlich gerade weil die Kommunikation zwischen Menschen und Maschine eben publikumsträchtiger ist als die zwischen Maschine und Maschine beziehungsweise ganzen Maschinenketten; und weil die Produktionstechnik in der Regel Hochleistungsanforderungen hinsichtlich Geschwindigkeit und Zuverlässigkeit stellt, die vom Internet und den ihm zugrunde liegenden Programmierparadigmata nur schwer zu erfüllen sind.

Die Kommunikation zwischen Maschinen in der Produktionstechnik ist sehr oft zeitkritisch. Ein- und Ausgabesignale müssen in berechenbarer und vorhersagbarer Weise (‘deterministisch’) verarbeitet und die Reaktions- und Antwortzeiten müssen garantiert werden können. Sonst wird Schrott erzeugt, Züge entgleisen, Flugzeuge stürzen ab oder Herz-Lungen-Maschinen fallen aus.

Traditionsgemäß haben zeitkritische Anwendungen und ihre Geräte – Sensoren, Steuerungen und Prozessrechner – eigene Systemumgebungen, das heißt spezielle Programmiersprachen und vor allem eigene Betriebssysteme, die sie ‘echtzeitfähig’ machen.

Zeitkritische Systeme und der Mainstream

Diese Systeme sind zwar maßgeschneidert für zeitkritische Aufgaben, koppeln diese aber auch vom ‘Mainstream’ der betriebswirtschaftlichen Großsysteme sowie der in diesem Bereich immer mehr dominierenden Internet-Kommunikation ab, und zwar nicht nur technisch, sondern auch architektonisch.

Der Bruch zwischen betriebswirtschaftlicher und zeitkritischer technischer EDV ist umso störender als das heutige Denken in Geschäftsprozessen und Services genau diesen Bruch zu überwinden sucht. Darüber hinaus wird durch spezielle Echtzeitsysteme eine durchgängige Entwicklungsumgebung und die Verwendung von Standards unmöglich. Die Folge: viele Ressourcen, die in den letzten Jahren im Rahmen des Internets und der digitalen Ökonomie entwickelt worden sind, können in Echtzeitsystemen nicht eingesetzt werden.

Dabei wäre gerade das Internet selbst das ideale Medium, um Maschinen auf eine orts- und geräteunabhängige Weise zu verknüpfen, kurz: um Web Services und Portalstrukturen zwischen Maschinen zu etablieren. Ebenso könnten die Plattformunabhängigkeit, der Entwicklungskomfort und die einfache Konnektivität einer Programmiersprache wie Java auch im Echtzeitbereich Ressourcen optimieren und damit Kosten sparen.

Ist Java überhaupt echtzeitfähig?

Das Aufbohren von Java in Richtung Echtzeit ist deshalb ein Thema, das schon fast so lange diskutiert wird, wie es diese Sprache gibt. Das ist freilich leichter gedacht als getan, weil einige Mechanismen, die eigentlich den technischen Charme von Java in Sachen Internetprogrammierung ausmachen, für Echtzeitanwendungen eher hinderlich sind.

In erster Linie betrifft das die Möglichkeit, während der Laufzeit Code einzubinden und vor allem die automatische Speicherbereinigungstechnik. Beide Automatismen stehen der Anforderung, im Milli- oder gar Nanosekundenbereich auf Maschinenanforderungen reagieren zu können, diametral entgegen. Genau solche Anforderungen sind aber für zeitkritische Anwendungen typisch.

Generell sind auch die herkömmlichen Java-Interpreter der Laufzeitumgebung (Java Virtual Machine) für zeitkritische Anforderungen unbrauchbar. Das gilt nicht nur für harte Echtzeitanforderungen – darunter versteht man Reaktionszeiten von unter 100 Millisekunden bis zu weniger als 100 Nanosekunden – sondern auch für weiche Echtzeitanforderungen, wo Reaktionszeiten über 100 Millisekunden akzeptabel sind. Nur als Richtgröße sei angegeben, dass gängige Java-Interpreter Programmbefehle 10- bis 50-mal langsamer umsetzen als dies bei der Abarbeitung durch Hardware direkt vonstatten ginge.

Maschinensignale müssen Priorität haben

Trotz dieser Hindernisse sind die Vorteile einer IT-Architektur, die zeitkritische und weniger zeitkritische Anwendungen verbindet sowie die Möglichkeit bietet, die im Umfeld von Java und Internet vorhandenen Standards zu integrieren, so interessant, dass die Entwicklung von Java-Echtzeitplattformen breit angegangen wird.

Schon seit vier Jahren gibt es ja mehrere Spezifikationen für ein Echtzeit-Java, sowohl aus dem Dunstkreis des Java-Gralshüters Sun als auch von anderen Konsortien. Für Details in Sachen Spezifikation sei auf die Arbeit ‘Echtfähige Java-Plattformen’ aus dem Wilhelm-Schickard-Institut der Universität Tübingen hingewiesen (Link am Ende des Artikels).

Um Java auch in harten oder weniger harten zeitkritischen Applikationen einsetzen zu können, müssen einerseits die Java Virtual Machine modifiziert und mit zusätzlichen Klassenbibliotheken versehen werden, andererseits vor allem der Mechanismus der Speicherbereinigung verändert werden.

Das Prinzip, das diese Änderungen leitet, ist einfach: in allen Bereichen (Ablaufsteuerung, Speicherbereinigung, Sprachumsetzung) müssen die Prioritäten so gestaltet werden, dass Signalanforderungen von den Maschinen oder Signalisierungen an die Maschinen absolute Priorität haben.

Vorübersetzer simulieren Echtzeit

Je nachdem ob man sehr harte oder eher weiche Echtzeitanforderungen hat, wird man bestimmte technische Stellschrauben benützen. Details dazu finden sich beispielsweise in ‘Echtzeit-Java – Eine Einführung’ von Thorsten Preuss (siehe Link am Ende des Artikels). Bei Echtzeitanforderungen unter 100 Millisekunden müssen beispielsweise bei der Java Virtual Machine so genannte Vorübersetzer eingesetzt werden. Diese Vorübersetzer halten mögliche Objektcode-Ergebnisse quasi auf Vorrat. Der Übersetzungsprozess läuft dann dahingehend ab, dass der Interpreter so gebaut ist, dass er aufgrund des jeweiligen Kontexts bestimmte Ergebnisse antizipieren kann. Diese Ergebnisse werden dann “aus dem vorübersetzten Vorrat” genommen. Damit wird  Echtzeit sehr erfolgreich simuliert.

Es gibt mittlerweile eine große Anzahl von echtzeitfähigen Java-Interpretern. Als Beispiele seien nur SICOMP RVTM von Siemens für das Echtzeitbetriebssystem RMOS3,  J9 von IBM für das System QNX, JamaicaVM der Karlsruher Firma Aicas oder die Echtzeit-JVM des Zürcher Unternehmens Esmertec genannt.

Daneben finden sich am Markt viele andere gekapselte Lösungen im Rahmen von zeitkritischen Steuerungen. So setzt TRW Airbag in Rostock in einer Fertigungslinie für die Montage von Gasgeneratoren für Airbags eine Echtzeit-Java-Lösung des Münchner Unternehmens Software Factory ein, und der Hannoveraner Automationsspezialist Gyronet hat eine Client-Server-Kommunikationssoftware entwickelt, die Geräte und Anlagen, die auf der Standardschnittstelle OLE for Process Control (OPC) laufen, an Java-gesteuerte Geräte koppelt. Diese OPC-Java-Brücke wird dabei auf der Basis der Java 2 Micro Edition (J2ME) bewerkstelligt.

Durch diese Brücke werden Prozessdaten via Internet zeit-, geräte- und ortsunabhängig. Das bringt erhebliches Optimierungspotenzial für Wartungsarbeiten. Es sind keine speziellen Wartungsschnittstellen, keine eigenen Wartungsleitungen und keine speziellen Servicerechner mehr notwendig. Und vor allem gilt: viele Wartungsfälle kann der Servicetechniker aus der Ferne lösen. Teilweise reicht dafür schon ein Java-fähiges Smartphone.