Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

15.03.1991

Echtzeit-Betriebssysteme sind durch Unix nicht zu ersetzen

Dipl.-Ing. Roland Chochoiek, Marketing Manager Europe Force Computers GmbH

In letzter Zeit kursieren verstärkt Gerüchte, Unix würde über kurz oder lang im Bereich der Mikro- und Minicomputer "echte" Echtzeit-Betriebssysteme überflüssig machen, also nicht nur "nach oben hin" an der Domäne der Mainframes nagen, sondern auch "nach unten hin" den Echtzeit-Kernels ihre Existenz streitig manchen. Ist dem wirklich so oder versuchen hier nur diverse Hersteller sogenannter "Echtzeit-Unixe", mit gezielten Gerüchten auf mehr oder weniger plumpe Art und Weise zusätzliche Marktanteile zu ergattern? Die Wahrheit liegt wahrscheinlich, wie so oft, in der Mitte.

Betrachten wir zunächst die Situation, wie sie sich heute oder zumindest bis vor kurzem - als die ersten Hersteller auftraten und ihr "Echtzeit-Unix" dem Markt präsentierten - darstellte. Unix hat sich im Laufe der Jahre, ob man es will oder nicht, zumindest im Bereich der Mikro- und Minicomputer, als das bevorzugte Betriebssystem für die Programmentwicklung etabliert. Aufgrund seiner allgemein bekannten und geschätzten Eigenschaften zur Unterstützung von Software-Entwicklungen wird es oft und gerne als Entwicklungsumgebung eingesetzt, um Software sowohl für Echtzeit- als auch für Nicht-Echtzeit-Projekte zu erstellen und auszutesten.

Dieser Prozeß ging letztlich sogar so weit, daß für eine Reihe von Echtzeit-Betriebssystemen die Entwicklungswerkzeuge ausschließlich unter Unix beziehungsweise einen Unix-Verwandten bereitgestellt wurden. Das Echtzeit-Betriebssystem blieb außen vor, größtenteils auch dann, wenn es grundsätzlich für eine "self-hosted" Entwicklung geeignet war. Auch in Zielapplikationen, die keinerlei "echtes" Echtzeitverhalten erforderten, sich also damit zufriedengeben konnten, daß auf ein extremes Ereignis dann reagiert wird, wenn das Betriebssystem es erfordert, wurde Unix immer öfter eingesetzt. Aber eben immer nur in Anwendungen, die kein schnelles und vor allem kein deterministisches Antwortverhalten vorausetzten.

Für diese "hartnäckigen" Applikationen stand und steht eine breite Palette von spezialisierten und auf die Anforderungen der Echtzeitsysteme zugeschnittenen (Ziel-) Betriebssystemen zur Auswahl. Als Beispiele von mehr oder weniger prozessorunabhängigen Kernels dieser Art seien hier VRTX, PSOS, PDOS, MTOS und RTOS genannt. Anwendern, die auch in einer Echtzeit-Zielapplikation nicht auf Unix-typische Eigenschaften verzichten wollten, wurden sogenannte "Unix-Look-alikes" wie zum Beispiel das Betriebssystem OS-9 (OS. 9000) angeboten. Bei derartiger Systemsoftware war man bemüht, einen guten Kompromiß zwischen "echter" Echtzeitfähigkeit und Unix-Charakteristik, zum Beispiel im Hinblick auf das I/O-System, zu finden.

Unix selbst konnte sich aber trotz aller geschätzten Eigenschaften in diesen Anwendungsbereichen nicht durchsetzen - dies einfach aufgrund der Tatsache, daß es "echte" Echtzeitanforderungen, also deterministische (vorhersagbare) Reaktionen auf externe Ereignisse (Interrupts) innerhalb von Mikrosekunden, so wie es klassische Echtzeit-Applikationen wie Robotersteuerung erfordern, bis dato nicht bieten konnte.

Nun erscheinen plötzlich Betriebssysteme auf dem Markt, die sich "Echtzeit-Unix" nennen. Von ihren Anbietern wird behauptet, daß sie sämtliche Eigenschaften der "echten" Echtzeit-Betriebssysteme neben den bekannten Unix-Eigenschaften in ein und derselben Systemsoftware zur Verfügung stellen. Heißt das, wir brauchen in Zukunft eigentlich nur noch ein Betriebssystem, das allen Anforderungen gerecht wird, also ein Echtzeit-Unix für die Programmentwicklung? Ein Echtzeit-Unix für Nicht-Echtzeit-Zielapplikationen und schließlich ein Echtzeit-Unix für, wie der Name schon sagt, Echtzeit-Zielanwendungen? Oder müssen wir uns weiterhin damit abfinden, daß es für unterschiedliche Applikationen auch unterschiedliche Betriebssysteme gibt?

Der monogamen Zukunft stehen sicherlich - zumindest mit Blick auf die nächsten drei bis vier Jahre - eine Reihe von Faktoren entgegen. Da ist zum einen die spezialisierte Leistungsfähigkeit der Echtzeit-Betriebssysteme. Die heutigen Echtzeit-Kernel stagnierten in ihrer Entwicklung ja keineswegs und verfügen neben den beim Echtzeit-Unix kopierten Eigenschaften wie Determinismus und der Fähigkeit zur "Preemption" - also der Möglichkeit, einen laufenden Prozeß bei Lauffähigkeit eines höherpriorisierten Prozesses sofort unterbrechen zu können, und verhältnismäßig kurzen Antwortzeiten (im Mikrosekundenbereich) über einzigartige Charakteristika.

Das heißt, sie sind sehr kompakt, was den Umfang des Programmcodes anbelangt. Oft benötigen sie nur ein paar KB Speicherkapazität. Man mag entgegenhalten, daß heutzutage Speicherplatz, auch der in Festwertspeichern (EPROMs), nahezu beliebig zur Verfügung steht und dieser Punkt somit relativiert würde. Dennoch ist festzustellen, daß gerade bei "Embedded Zielsystemen", also Systemen, wo der Rechner integraler und oftmals nur kleiner Bestandteil eines Gesamtsystems ist, die Frage, ob das Betriebssystem wenige KB Umfaßt, durchaus zum entscheidenden (Kosten-)Faktor werden kann. Insbesondere auch, weil die Systeme häufig in sehr großen Stückzahlen produziert werden (Stichwort Waschmaschinensteuerung).

Ferner ist der Umfang des Programmcodes nach wie vor mit der Ausführungsgeschwindigkeit verknüpft. Ein spezialisierter, kleiner Echtzeit-Kernel wird also immer schneller sein, als es ein komplexes, an Standards gebundenes Echtzeit-Unix sein kann. Diese Spezialisierung bringt es zudem mit sich, daß Mechanismen zur Verfügung gestellt werden, die ein modifizierter Unix-Kernel zusätzlich zu den Standard-Unix- Funktionen einfach nicht bieten kann, wenn sich die Modifikation in einem vertretbaren Rahmen bewegen soll. Ein weiterer Punkt bezüglich der Kosten: Die Echtzeit-Kernels, die ja im Vergleich zu einem vollwertigen Echtzeit-Unix einen anders gearteten Funktionsumfang besitzen, sind im Hinblick auf die Lizenzkosten bei Volumenproduktion deutlich preisgünstiger - ein zusätzlicher Grund also, weswegen man auf sie nicht verzichten wollen wird.

Soweit die beispielhaft herausgegriffenen Unterschiede bei den Eigenschaften. Man sollte aber darüber hinaus die Rechnung nicht ohne den Wirt machen, genauer: ohne die Hersteller der spezialisierten Echtzeit-Kernels. Diese werden sicherlich nicht tatenlos zusehen, wie ihnen Marktanteile von einem der "Echtzeit-Unixe" weggenommen werden. Schließlich haben sie auch bisher den Markt nicht nur reaktionslos beobachtet. Ihre Kernels wurden immer kleiner, immer schneller und verfügten über immer mehr komfortable Multitasking-Kommunikations- und Syncronisationsmechanismen. Um nicht auf die (auch von ihnen anerkannten) Vorzüge von Unix verzichten zu müssen, beinhalten sie immer mehr Tools als Verknüpfung von Unix mit ihren Echtzeit-Kernels, getreu dem Leitsatz: "Das Beste aus beiden Welten"