Suche Home Einstellungen Anmelden Hilfe

Betriebssystembaukasten

Betriebssysteme sind in ihrer Funktion, die Betriebsmittel eines Rechners bzw. Rechnernetzes zu verwalten, auch immer auf einen bestimmten Einsatzbereich spezialisiert. Im Falle von Vielzweckbetriebssystemen wie etwa Linux oder Windows-NT, die z.B. Mehrteilnehmerbetrieb ermöglichen, sind die zur Unterstützung der Anwendungsprogramme erforderlichen Funktionen meist nur sehr ungenau im Voraus festgelegt. Die daraus resultierende zusätzliche Betriebsmittelbelastung durch das Betriebssystem selbst geht in vielen Fällen auf Kosten der Anwendungen. Der Mehraufwand an Betriebssmitteln ergibt sich nicht nur durch meist statisch vorgehaltene Systemkomponenten (Folge: höherer Hauptspeicherbedarf), die gelegentlich nur von Anwendungen speziellen Typs benutzt werden (Folge: Benachteiligung von Anwendungen, die diese Komponenten nicht benutzen), er resultiert insbesondere auch aus den in den Kernfunktionen eingegangenen Kompromissen, um eine große Anwendungspalette unterstützen zu können (Folge: höherer Bedarf an CPU-Zyklen zur Ausführung eines Systemaufrufs). Demgegenüber ist das Einsatzgebiet für Einzweckbetriebssysteme sehr genau festgelegt (z.B. im Antiblockiersystem ABS oder im elektronischen Fahrsicherheitsprogramm ESP bei Kraftfahrzeugen). Kompromißlösungen sind hier nur sehr selten tolerierbar, der dafür dann ggf. zur Verfügung stehende Spielraum ist nur sehr klein: in den sogenannten tiefsten eingebetteten Systemen ist ein für Betriebssystem und Anwendung insgesamt zur Verfügung stehender Arbeitsspeicher von nur 2 Kilo-Bytes keine Seltenheit, und die vorherrschende CPU-Technologie ist 8-Bit.

Zwischen beiden Extremen gibt es viele Varianten mit den unterschiedlichsten Fähigkeiten und Eigenschaften, einhergehend mit Entwurfs- und Implementierungsentscheidungen, die den Einsatz- und Anwendungsbereich eingrenzen. Dennoch bestehen trotz aller Unterschiede zwischen all diesen Systemen viele Gemeinsamkeiten. In den beiden oben genannten Fallbeispielen sind z.B. Prozesse zu implementieren, und es ist für deren koordinierten Ablauf zu sorgen, Kommunikation und Kooperation zwischen Prozessen ist zu ermöglichen, Programmunterbrechungen und Nebenläufigkeit sind zu behandeln und Geräte sind zu bedienen. Bei genauerer Betrachtung wird erkennbar, dass sich die wesentlichen Unterschiede viel stärker auf die "Architektur" und nicht die "Funktion" beziehen. Dass etwa Dienste einer Linux-Prozeßverwaltung nicht für einen Einsatz z.B. in der Motorsteuerung eines Automobils wiederverwendbar sind, liegt weniger an der Funktion des Linux-Prozesses selbst als vielmehr daran, dass die Architektur seiner Implementierung einen solchen Einsatz nicht gestattet, da sie nicht anwendungsanpaßbar ist.

Es ist jedoch ein Trugschluß anzunehmen, dass z.B. für jedes tiefste eingebettete System aufgrund der extremen Randbedingungen ein Betriebssystem immer von der Pike auf neu entwickelt werden muß bzw. eine solche Entwicklung von vornherein zum Scheitern verurteilt ist und die Anwendung daher ohne Systemunterstützung auszukommen hat. Die Räder müßten hier nicht immer wieder neu erfunden werden, wenn der Entwurf von Betriebssystemen konsequent höchst modular erfolgen würde. Ziel muß es dabei sein, kleinste Systemkomponenten zu schaffen, die wiederverwendet werden können, um schrittweise und hierarchisch komplexere Komponenten zu schaffen, die dabei nur genau jene Funktionen umfassen, die zum Aufbau der nächst höheren Ebene unbedingt erforderlich sind.

Mit der bereits Mitte der Siebziger Jahre von dem amerikanischen Informatiker D.L. Parnas vorgestellten Idee der Programmfamilien läßt sich ein derartiger Entwurfsgedanke sehr gut umsetzen. Demnach besteht eine Betriebssystemfamilie aus einer minimalen Basis von Systemfunktionen, die schrittweise (inkrementell) durch minimale Systemerweiterungen funktional angereichert wird. Der Entwurf erfolgt dabei von unten nach oben, er ist jedoch zielgerichtet auf einen bestimmten Anwendungsbereich und wird damit in umgekehrter Richtung kontrolliert. Um kleinste wiederverwendbare Komponenten zu erhalten, sind Entwurfsentscheidungen, die die Verwendung der Komponenten einschränken würden, so weit wie möglich zurückzustellen. Darüberhinaus ist zu berücksichtigen, dass derartige Entscheidungen ggf. überhaupt nicht im System selbst getroffen werden müssen, sondern erst in der Anwendung. Solche Entscheidungen betreffen z.B. das Prozeßmodell (schwer-, leicht- oder federgewichtige Prozesse), das Scheduling (aktive und/oder passive Objekte, kooperativ, präemptiv, deterministisch, probabilistisch, feste oder dynamische Prioritäten) oder die Synchronisation nebenläufiger Aktivitäten (unterbrechungstransparent, optimistisch, blockierend, mit oder ohne Hardware-Unterstützung). Viele andere Beispiele lassen sich anführen, hinter denen sich jeweils immer ein bestimmter Anwendungsbereich verbirgt.

Auf der Grundlage des familienbasierten Entwurfes lassen sich Betriebssysteme konstruieren, die aus fundamentalen Komponenten bestehen, die sowohl für tiefste eingebettete Systeme wie auch für konventionelle Mehrteilnehmersysteme geeignet sind. Diese Komponenten sind Bestandteil einer Betriebssystemfamilie, aus der sich je nach Anwendung verschiedene Betriebssysteme als Ausprägung bestimmter Familienmitglieder ergeben. Ein solches Verständnis von Betriebssystementwurf besteht z.B. bei der Entwicklung von PURE (http://www.pure-systems.de). Die PURE-Familie legt den Grundstock für einen Betriebssystembaukasten, der neben den einzelnen "verschiedenfarbigen" Bausteinen (d.h. Komponenten) auch Werkzeuge zur Komposition anwendungsangepaßter Betriebssysteme enthält.

Der Aufbau einer Betriebssystemfamilie, die aus sehr vielen wiederverwendbaren Komponenten besteht, ist eine Sache, die Komposition von Betriebssystemen aus diesen Komponenten ist eine andere Sache und nur mit Werkzeugunterstützung praktikabel. Hinter dem zuletzt genannten Punkt verbirgt sich, mehr als zum ersten Punkt, ein beträchtlicher Forschungsbedarf, der sich allgemein auf die Konfigurierung und Maßschneiderung von (System-)Software bezieht. Die Eigenschaften aller in der Betriebssystemfamilie vorhandenen Komponenten (oder Abstraktionen) sind spezifiziert und bilden zusammen mit den Komponenten eine Datenbasis, aus der anhand von Anforderungsspezifikationen das für den vorgegebenen Einsatzbereich am besten passende und hinsichtlich seiner Funktion formal verifizierte Betriebssystem automatisch generiert wird. Dies ist die hinter PURE stehende Vision, die es noch weiter umzusetzen gilt und die zu einem Forschungsschwerpunkt meiner Arbeitsgruppe zählt.

Literatur

• D. Beuche, A. Guerrouat, H. Papajewski, W. Schröder-Preikschat, O. Spinczyk und U. Spinczyk: The PURE Family of Object-Oriented Operating Systems for Deeply Embedded Systems. Proc. of the 2nd IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC'99), St Malo, France, May 1999
• D.L. Parnas: On the Design and Development of Program Families. IEEE Transactions of Software Engineering 2 (1976) 1-9

Adresse
Prof. Dr.-Ing. Wolfgang Schröder-Preikschat
Fakultät für Informatik
Otto-von-Guericke-Universität Magdeburg
Universitätsplatz 2
39106 Magdeburg
Email: wosch@cs.uni-magdeburg.de
WWW: http://ivs.cs.uni-magdeburg.de/~wosch

Lebenslauf
Prof. Dr.-Ing. Wolfgang Schröder-Preikschat (44 Jahre) leitet seit 1997 die Arbeitsgruppe Betriebssysteme und Verteilte Systeme an der Fakultät für Informatik der Otto-von-Guericke-Universität Magdeburg. Derzeit umfaßt die Arbeitsgruppe zehn wissenschaftliche Mitarbeiterinnen und Mitarbeiter. Die Arbeiten befassen sich mit der Entwicklung anwendungsangepaßter Betriebssysteme für parallele/verteilte eingebettete Systeme.
Herr Schröder-Preikschat hat Informatik studiert und 1987 promoviert. Nach Forschungsaufenthalten am International Computer Science Institute (ICSI) in Berkeley, USA, und längerer Tätigkeit beim Berliner GMD-FIRST Forschungsinstitut für Rechnerarchitektur und Softwaretechnik der GMD-Forschungszentrum Informationstechnik mbH, einer Großforschungseinrichtung des Bundes, hat er sich 1994 habilitiert. 1995 übernahm er die Professur für Rechnernetze und Betriebssysteme am Institut für Informatik der Universität Potsdam, bevor er 1997 nach Magdeburg wechselte.

Glossar
Eingebettetes System: Meist kleines Hard- und Softwaresystem zur Kontrolle, Steuerung oder Unterstützung der Funktion eines (umgebenden) Gerätes oder einer Maschine (Steuerung der Benzineinspritzung, Garkontrolle in Mikrowellenöfen, ABS). "Eingebettet" deutet zum einen an, daß das Hard- und Softwaresystem integraler Bestandteil des Gerätes oder der Maschine ist und daß es sich in die strengen, meist unveränderlichen Umgebungsbedingungen einfügen muß. Tiefste eingebettete Systeme sind in diesem Sinne dann diejenigen Systeme, deren Umgebung die schärfsten Bedingungen (z.B. hinsichtlich Temperatur, Reaktionsgeschwindigkeit, Größe) an das eingebettete System stellt.

Scheduling: (dt. Zuteilung) Aufgabe des Betriebssystems, die (knappen) Betriebsmittel, wie Speicher, Prozessoren, Geräte, den in Bearbeitung befindlichen Prozessen bedarfsgerecht zuzuteilen. Es gibt eine Vielzahl von Strategien für das Scheduling.

Benutzer: Gast • Besitzer: schwill • Zuletzt geändert am: