Unix ist auf dem besten Wege, ein allgemein akzeptiertes Betriebsystem auf 16/32-Bit-Mikros zu werden. Besonders geeignet bei speziellen Anforderungen wie etwa Interaktion - einem hohen Grad an Mensch-Maschine-Kommunikation - oder für Abläufe mit mehreren Benutzern und Anwendungen gleichzeitig. Schlecht sieht es hingegen aus, wenn auf garantierte Antwortzeiten oder viele asynchrone, externe Unterbrechungen Wert gelegt wird. Ergebnis der Analyse: Unix ist für interaktiv orientierte Applikationen durchaus geeignet, für den Echtzeitbetrieb aber um so weniger.
Bei der Schlußfolgerung könnte man es belassen, würden sich die Anwendungen immer sauber den Begriffen "Echtzeit" und "lnteraktiv" zuordnen lassen. Die Rede ist hier von Applikationen, die im wesentlichen "Unix-nahe" sind, aber auch einige unverzichtbare Realzeitanforderungen haben.
Beispiel dafür ist die automatische Meßwerterfassung im Bereich Lagerhaltung und Produktion. Solche Geräte zur Meßwerterfassung erwarten im allgemeinen ein garantiertes Zeitverhalten und die Möglichkeit, asynchron Unterbrechungen abzusetzen.
Gerade dies ist aber in Unix, wenn überhaupt, nur schwer zu bewerkstelligen. Andererseits ist das Erstellen von Listen, Tabellen oder interaktives Abfragen:"ein wesentlicher Bestandteil dieser Anwendungen.
Ein anderes Beispiel, in dem ähnliche Probleme hinsichtlich des Zeitverhaltens auftreten, ist die Abwicklung komplexer Kommunikationsprotokolle. An dieser Stelle stellt sich zwangsläufig die Frage: Scheidet Unix als Betriebssystem damit aus und folglich auch der Einsatz von auf dem Markt verfügbarer Standardsoftware?
Verschiedene Lösungsansätze bieten sich an: Einsatz zweier unabhängiger Rechnersysteme, die über LAN gekoppelt sind. Das eine System übernimmt dabei den "Mensch-Maschine" -orientierten Teil, das andere die Echtzeitaufgaben.
Dieser Ansatz ist sicherlich gut, wenn die Applikation umfangreich genug ist, um zwei Systeme auszulasten. Ist das aber nicht der Fall, so rutscht man in ein sehr ungünstiges Preis/Leistungs-Verhältnis.
Die Tatsache, daß sich nicht jede Aufgabenstellung programmtechnisch einfach in einen interaktiven und einen Realzeit-Teil aufteilen läßt, kann insbesondere für das Kommunikationssystem problematisch werden.
Ein zweiter Lösungsvorschlag propagiert die Auslagerung der Realzeitaufgaben auf intelligente Spezialplatinen. Dies ist sicherlich der beste Ansatz, wenn der Anteil der Realzeitaufgaben klein ist. Hauptnachteil: Solche Platinen sind wenig flexibel hinsichtlich Ausbaufähigkeit und Anpassung an spezielle Kundenapplikationen.
Im folgenden wird ein dritter Weg aufgezeigt, der sich an den vorhergehenden Vorschlag anlehnt, ohne allerdings den Nachteil der mangelnden Flexibilität mit zu übernehmen: Einplatinen-Computer als "Peripheriegeräte" aus der Sicht von Unix. Dieser Einplatinen-Computer wird durch ein Echtzeitbetriebssystem unterstützt. Damit kann der Realzeitonentierte Teil der Applikation darauf ausgelagert werden. Für Unix ist er ein Peripheriegerät. Die Schnittstelle dazu bilden Dual-Port-Hauptspeicher und Interrupts.
Ein Beispiel soll diesen Gedanken naher erläutern. Das 286/310 Mikrocomputersystem unter Xenix bildet das Basissystem, auf welchem der Hauptteil der Applikation abläuft In einen der freien Multibus-Steckpiätze kommt beispielsweise ein auf iAPX 186 basierender Einplatinen Computer. Darauf läuft der Realzeit orientierte Teil der Applikation unter dem Echtzeitbetriebssystem RMX. Der Datenaustausch erfolgt über Dual-Port-Memory. Die Software für den Einplatinen-Computer wird beim Hochfahren des Systems in den lokalen Hauptspeicher der Platine geladen beziehungsweise als PROM eingebaut.
Ein solches System in einer "Box" besteht somit aus einem Hauptsystem und einem oder mehreren Subsystemen, basierend auf einem Echtzeitbetriebssystem. Für eine solche
Lösung sind jedoch einige technische Voraussetzungen erforderlich:
- Die Möglichkeit, neue Treiber mit vertretbarem Aufwand zu erstellen und einzubinden, wie beispielsweise in Xenix;
- ein Echtzeitbetriebssystem, welches Hauptspeicher-residente Systeme unterstützt, wie beispielsweise RMX, und
- modulare Hardwarearchitekturen, wie sie in modernen Mikrocomputersystemen Standard sind.
Vorteile dieser Lösung sind ein günstiges Preis/Leistungs-Verhältnis, eine hohe Flexibilität hinsichtlich kundenspezifischer, sich ändernder Aufgabenstellungen sowie die Möglichkeit, Anpassungen nicht nur vom Hersteller, sondern auch vom Systemprogrammierer des Anwenders vornehmen zu lassen.
Georg Brugger ist Applikations-lngenieur im Bereich Technisches Marketing der Intel
Semiconductor GmbH, München.