Echtzeit Linux (RT- Linux)

Zusammenfassung: Der Author gibt eine gute übersicht über die Welt der Echtzeit Betriebssysteme. Dieser Artikel ist für interessierte Leser ohne spezielle Informatik Kenntnisse geschrieben.

Was ist Echtzeit?

Vor der Einführung in RT-Linux müssen noch ein paar Gedanken zu Echtzeit erläutert werden. Man sagt:

"Ein Echtzeit-System ist ein Informationssystem, dessen Eigenschaften nicht nur von der logischen Ausgabe der Algorithmen bestimmt werden, sondern auch vom Zeitpunkt der Ausgabe."

Es reicht nicht aus, daß die resultierende Ausgabe richtig ist, diese Ausgabe muß zusätzlich auch in einem bestimmten Zeitintervall geschehen. Interessant daran ist, daß ein Echtzeit-System nicht unbedingt schnell sein muß, wie man vielleicht im ersten Moment denken mag. Als Beispiel ist hier das Steuerungssystem eines Schiffes zu nennen, denn seine Geschwindigkeit ist gering und das Steuerungssystem hat normalerweise "genug" Zeit (in einer Größenordnung von Minuten) zur Entscheidungsfindung. Trotzdem ist es laut unserer Definition tatsächlich ein Echtzeit-System.

Man muß beachten, daß wir ein "Echtzeit-System" definiert haben und nicht ein System in Echtzeit. Ein "System in Echtzeit" ist normalerweise ein schnelles System, daß einen Eindruck von "Wirklichkeit" vermittelt. Typisch sind hier Simulationen und interaktive Spiele, die dem Benutzer Kontinuität vermitteln müssen. Dabei gilt dieses Ziel als umso besser erreicht, je mehr Bilder pro Sekunde generiert werden.

Auf die "zeitliche Einschränkung" muß noch im Detail eingegangen werden. Angenommen, man will die Geschwindigkeit einer Maschine kontrollieren, die unter einer sich ständig veränderden Last arbeitet, und man will auch einen PID-Regler (Proportional-Integral-Differential-Regler) laufen lassen. Der PID-Regler ist eine Funktion, die, von außen betrachtet, eine Reihe Parameter benötigt - in diesem Beispiel die Geschwindigkeit der Maschine - und den Wert des Regelsignales zurückgibt, daß an der Maschine angewendet werden muß - die Spannung, die der Maschine zugeführt werden muß. Die Theorie der PID-Algorithmen, die nebenbei gesagt sehr umfangreich ist, nimmt an, daß die Zeit, die zur Berechnung benötigt wird, vernachlässigt werden kann. Daß heißt, daß das Zeitintervall vom Lesen des Signals bis zu einer Reaktion sehr klein ist. Unter normalen Umständen erlauben Systeme eine kurze Verzögerung. Ein anderes Merkmal dieser Art Regelung ist, daß sie periodisch durchgeführt werden muß, in anderen Worten, der PID-Algorithmus muß regelmäßig ausgeführt werden; mit anderen Worten: Wenn die Zeit zwischen zwei aufeinander folgenden Aufrufen zu groß ist, kann die Maschine eine unerwünschte Geschwindigkeit erreichen. Zusammenfassung: Die PID-Funktion kann als ein Programm angesehen werden, daß periodisch ausgeführt werden muß (Pi); vom Start bis zur Komplettierung muß ein Zeitintervall eingehalten werden, daß in der PID eingeplant wurde (Di); und abhängig vom Prozessor braucht der PID-Code eine bestimmte Zeit (Ci).

Pi: Periode des Tasks i.

Di: Deadline des Tasks i.

Ci: größte Rechenzeit für den schlechtesten Fall von Task i.

Wenn das System aus einem Task besteht, dann gibt es kein Problem mit Echtzeit. Entweder kann der Prozessor den Prozeß in der vorgegebenen Zeit abarbeiten oder nicht. Falls der Prozessor nicht schnell genug ist, tauscht man ihn einfach gegen einen schnelleren aus.

Die Probleme tauchen erst auf, wenn ein System mehrere Tasks gleichzeitig verarbeitet und die Leistung des Prozessors (oder der Prozessoren) zwischen ihnen aufgeteilt werden muß. Dann muß man von der Verwendung eines klassischen, auf Zeitaufteilung basierten Systems Abstand nehmen. Natürlich muß nicht extra erwähnt werden, daß überhaupt nicht versucht zu werden braucht, Programme unter Windows zu schreiben, die Echtzeit benötigen.... Ein noch besserer Rat wäre, kein einziges Programm unter Windows zu schreiben.

Es sind nicht alle Echtzeit-Systeme identisch; es ist schließlich nicht dasselbe, ein ABS-System in einem Auto, die Einspritzanlage in einem Düsentriebwerk oder die Dekompression und Visualisierung einer mpeg-Datei zu kontrollieren. Im ersten Fall und im zweiten Fall kann eine kleine Verzögerung in der Ausführung den Verlust eines Menschenlebens oder große materielle Verluste bedeuten; im dritten Fall verliert das System nur an Qualität (das Bild bleibt eingefroren und einige Bilder werden nicht gezeigt). Der erste Typ Systeme wird als strenges Echtzeit-System bezeichnet und der zweite als weiches Echtzeit-System. Wir werden uns auf strenge Echtzeit-Systeme konzentrieren.

Der Entwurf eines Echtzeit-Systems hat verschiedene Phasen. Zuerst werden die auszuführenden Tasks und die zeitlichen Restriktionen identifiziert. Dann wird der Code geschrieben, die Laufzeit jedes Tasks gemessen und ein gut beschriebener Plan zur Ausführung wird umrissen. Dieser Plan beruht dann auf mehreren Testläufen aller Tasks, und wenn sie ihre Tests bestanden haben, ist es möglich zu garantieren, daß kein Task seine Ausführungszeit verpassen wird. Wenn die Tests nicht bestanden werden, muß nochmal von vorn begonnen werden, zum Beispiel mit einer schnelleren CPU oder mit Verwendung anderer Algorithmen zur Implementierung der Tasks.

Zusammenfassung: Die Tasks werden mit drei Buchstaben identifiziert, P, D und C. Die Objektive des Systems ist die Garantierung der Einhaltung der geplanten Ausführungszeiten aller Tasks (bei jedem ihrer Aufrufe). Um die Ausführungszeiten zu garantieren, muß das System vorhersagbar sein. Zu sagen, daß ein System Echtzeit-gemäß arbeitet, und zu sagen ein System sei vorhersagbar, ist praktisch dasselbe.

Worin besteht das Verhältnis zwischen Betriebssystem und Echtzeit?

Die semantische Korrektur der Antwort verantwortet der Programmierer, und die zeitliche Korrektur hängt vom Betriebssystem ab.

Das Betriebssystem muß die Ausführung aller Tasks unterstützen und organisieren, es liegt auch in der Verantwortlichkeit des Betriebssystems, die Interrupts zu handhaben. Das Betriebssystem muß folgendes bieten:

• den Algorithmus für die Planung,
• den Mechanismus für Kommunikation der Prozesse untereinander,
  (semaphores, messages, usw.),
• die Handhabung von Interrupts und
• die Aktivierung von Tasks zu Beginn jeder ihrer vorgeschriebenen Laufzeiten.

Im Gegensatz zu einem "normalen" Betriebssystem ist das Ziel bei Echtzeit-Betriebssystemen eine Minimierung der Komplexität. Man braucht nicht ein Betriebssystem, das möglichst viel kann. Wirklich wichtig ist, daß Tasks periodisch und schnell ausgeführt werden.
Ein Betriebssystem, das normalerweise 10 Zeiteinheiten (time units; t. u.) und im schlechtesten Fall 12 t. u. braucht, um etwas bestimmtes zu machen, ist einem Betriebssystem vorzuziehen, daß durchschnittlich 3 t. u. braucht, aber von Zeit zu Zeit auch bis zu 20 t. u. brauchen kann, um dieselbe Aufgabe zu erledigen (Anm. d. Ü.: da dies zu einer Beeinträchtigung der Vorhersagbarkeit führt).

Man sollte nicht überrascht sein, wenn man entdeckt, daß Echtzeit-Betriebssysteme "langsamer" sind als normale Betriebssysteme. Gelegentlich kann es sogar nötig sein, daß das Cache-Memory ausgeschaltet werden muß, um ein vorhersagbares Verhalten zu erreichen, wodurch natürlich dessen Leistungsschub verloren geht. Das Cache-Memory, Prozessoren mit Pipline-Einheiten und die Algorithmen für Sprung-Vorhersage sind klare Feinde von Vorhersagbarkeit und deshalb auch von Echtzeit-Betriebssystemen.

POSIX RT-Erweiterungen

POSIX sind die Initialen für Portable Operating System Interface (Anm. d. Ü.: Portierbares Betriebssystem Interface) (Und was ist schon ein Betriebssystem ohne ein X am Ende?). Dies ist ein Standard, der beabsichtigt, die Portierbarkeit von Software auf Quellcode-Niveau zu erreichen. In anderen Worten, ein Programm für ein POSIX-gemäßes Betriebssystem sollte unter jedem anderen POSIX kompilierbar sein, sogar wenn es von einem anderen Produzenten kommt. Der POSIX-Standard definiert das Interface, das Applikationen vom Betriebssystem zur Verfügung gestellt werden soll, die Systemaufrufe. POSIX wird entwickelt vom IEEE (Institute of Eletrical and Electronic Engineering; Anm. d. Ü.: Institut der elektrischen und elektronischen Ingenieurarbeit), vom ANSI (American National Standards Institute; Anm. d. Ü.: amerikanisches nationales Institut für Standarisierung) und vom ISO (International Standards Organisation; Anm. d. Ü.: internationale Organisation für Standarisierung). POSIX basiert eindeutig auf UNIX. Die Mehrheit der Betriebssysteme (auch Windows NT) streben durch verschiedene Versionen zu POSIX-Kompatibilität.

Die Arbeit an den POSIX-Definitionen wird auf verschiedene Arbeitsgruppen verteilt, darunter sind Computerhersteller, Softwarefirmen, Regierungsangestellte und Computer-Gurus. Jede Gruppe übernimmt einen Aspekt der Planung des Betriebssystems. Zum Beispiel bearbeitet die Gruppe POSIX 4 die Echtzeit-Implementationen.

Die Erweiterung POSIX 4 -- seit 1993 in 1003.1b umbenannt -- erlaubt die Verwendung eines Betriebssystems in Echtzeit-Situationen. Natürlich bezieht sich der größte Teil dieser Erweiterungen auf Zeitverwaltung und Prozessvorrechte, aber es gibt auch Systemaufrufe um die Kommunikation der Prozesse untereinander zu erleichtern.

Die POSIX-Erweiterungen sind dazu gedacht, die Kontrolle über die Verwaltung der Ressourcen eines Betriebssystems zu verbessern.

In Linux 2.0 sind viele der Systemaufrufe der POSIX-Erweiterungen zu Echtzeit implementiert... aber auf diesen Aspekt von Linux wird noch in einem zukünftigen Artikel eingegangen werden. Version 2.2 wird höchstwahrscheinlich 100% kompatibel zu POSIX 1003.1b sein.

Echtzeit-Linux

RT-Linux wurde am Department of Computer Science des Institute for Mining and Technology von New Mexico von Victor Yodaiken und Michael Barabanow entwickelt. Es ist Teil der von Michael vorgelegten Arbeiten zum Erlangen des Titels in Computerwissenschaften. Die letzte erhältliche Version ist 0.6. Im Moment ist es nur für Intel-Architekturen erhältlich.

RT-Linux löst das Problem auf radikal andere Weise. Im Gegensatz zu Veränderungen am Kernel von Linux,die nötig wären, um ihn vorhersagbar zu machen, setzt es einfach einen kleinen Kernel mit einer Zeitverwaltung direkt über den Prozessor (i386) -- dieser neue Kernel arbeitet dann unabhängig vom Linux-Kernel. Der Hauptkern läuft über dem kleinen und teilt die Prozessorzeit mit anderen Tasks. Die Rechenzeit wird also mit anderen Tasks geteilt, präziser gesagt läuft Linux im Hintergrund, wenn kein anderer Task läuft.

Ich glaube, viele Leser werden durch die beschriebenen Gedanken verwirrt worden sein, vielleicht weil es so aussieht, als wenn das Betriebssystem allmächtig ist, und es unmöglich ist, damit zu spielen.

Es wird noch überraschender sein zu erfahren, daß es möglich ist, die Zeitverwaltung dynamisch in den Kernel zu integrieren und wieder zu entfernen, denn sie wird als Modul kompiliert.

Der Linux-Kernelcode (wie bei jedem anderen Betriebssystem) macht normalerweise die Interrupts als Synchronisationshilfe oder als Unterstützung bei der Implementation von kritischen Teilen unbrauchbar. Wenn es einen Uhr-Interrupt gibt, während Linux die Interrupts unbrauchbar gemacht hat, wird auch dieser geblockt, und daraus resultiert dann ein Verlust an Präzision. RT-Linux implementiert eine interessante Lösung. Alle Aufrufe zu cli, sti und iret (Assembleraufrufe zur Modifizierung der Zustände der Interrupts) gehen an S_CLI, S_STI und S_IRET, die diese emulieren, daher kann Linux niemals die Interrupts blockieren.

Die Standard-Zeitverwaltung von RT-Linux basiert auf statistischen Prioritäten und weist dem Linux-Task die niedrigste Priorität zu. Wenn die Echtzeit-Tasks die gesamte Rechenzeit verbrauchen, dann wird der Linux-Task keine Rechenzeit erhalten und es kann der Eindruck eines gestoppten Systems entstehen.

Mit Linux hat man nicht nur ein Echtzeitsystem, sondern auch ein klassisches Betriebssystem. Man kann im Web surfen, während gleichzeitig auch ein physisches System getestet und kontrolliert wird.

Installation von RT-Linux

Die Dateien für die Distribution sind unter http://luz.cs.nt.edu/~rtlinux zu finden.

Um ein Linux-System in RT-Linux zu verwandeln, muß der Quellcode des Kernels gepatcht werden. Dieser Patch ist in RT-Linux enthalten. Danach muß der Kernel natürlich neu kompiliert werden. Hier ist das Rezept dazu. Ich nehme dabei an, daß die Datei rtlinux-0.6-2.0.33.tgz im Verzeichnis /usr/src liegt und in /usr/src/rtlinux-0.6 entpackt wurde. Weiterhin nehme ich an, daß alle Optionen für den Kernel schon konfiguriert sind (make config), dann:

# cd /usr/src/linux
# patch -p1 <../rtlinux-0.6-2.0.33/kernel_path
# make dep; make clean; make zlilo; make modules; make modules_install
# reboot

Der neue Kernel scheint mit einem normalen Kernel identisch zu sein, jedoch ist er schon auf die Verwandlung in ein Echtzeit-System vorbereitet. Im Verzeichnis /usr/src/rtlinux-0.6-2.0.33/testing gibt es verschiedene Demo-Programme.

Von dem tollen Beispiel, das bei der Distribution (im Verzeichnis testing) dabei ist, abgesehen, können Anwender ein weiteres, von Oleg vorbereitetes, Beispiel aus dem Netz herunterladen. Das erlaubt dann die Erstellung einer Tabelle zur Ausführung von den Tasks. Eine anderes mitgeliefertes Demoprogramm ist ein Zeitverwalter mit ein paar zusätzlichen Modifikationen. Diese erlauben nicht nur Verwaltung der Aufrufe von Tasks, sondern liefern auch Informationen über die getroffenen Entscheidungen. Diese Informationen werden gesammelt und in einer Datei gespeichert, die dann später graphisch dargestellt werden kann. Ein Ergebnis ist, daß man sehen kann, in welcher Reihenfolge die verschiedenen Tasks ausgeführt wurden, und wie der wichtigste Task den mit der kleinsten Priorität ausschließt. Der Linux-Task wird nicht dargestellt.

Jeder Task wird durch eine horizontale Achse repräsentiert. Die Rechtecke zeigen die Zeiten, in denen jeder Task den Prozessor nutzt (zu einem gegebenen Zeitpunkt kann nur ein Task ausgeführt werden, denn dies ist ein mono-Prozessor System). In diesem Beispiel ist die Deadline für jeden Task gleich seiner Periode, die Periode von jedem Task wird durch ein Zeitintervall markiert
(repräsentiert von:) während dem der Task ausgeführt sein muß. Die Tasks auf dem oberen Teil haben eine größere Priorität und können andere Tasks vom Prozessor ausschließen, wie zum Beispiel bei 600.

Die Zukunft von RT-Linux

Es gibt schon eine Multiprozessor-Version von RT-Linux. Die Dienste, die RT-Linux zur Verfügung stellt, sind minimal und sollen es auch sein, denn unnötige Funktionalität wurde weggelassen, um das System so vorhersagbar wie möglich zu gestalten. Trotzdem gibt es schon einige Erweiterungen, die die Arbeit mit Semaphoren erlauben und es ermöglichen, auf Tasks in Echtzeit mit den Linux-Prozessen durch /proc/sys Einfluß zu nehmen.

Vor einigen Wochen begann der Aufbau eines Manuals bzw. Tutorials für RT-Linux.

Fazit

Vor dem Erscheinen von RT-Linux mußten Ingenieure, die ein Echtzeit-System benutzen wollten, entweder MS-DOS nehmen und alle nötigen Treiber schreiben, oder ein Echtzeit-OS kaufen (zu unerschwinglichen Preisen). Jetzt haben Entwickler ein komplettes Betriebssystem, um Echtzeit-Applikationen auf dem selben System zu entwickeln, auf dem diese später ausgeführt werden sollen. Man kann sogar mehrere Echtzeit-Applikationen simultan laufen lassen und ohne Probleme gleichzeitig im Web surfen.

Unser nächster Artikel in dieser Serie wird auf verschiedene Beispiele von Echtzeit-Applikationen eingehen und zeigen, wie man selber eine solche schreiben kann.