Studienarbeit

Transkript

1 Georg-Simon-Ohm-Fachhochschule Nürnberg Fachbereich Informatik Studienarbeit Stephan Meyer Matrikelnummer: Fach: Echtzeitbetriebssysteme Dozent: Prof. Dr. Ralf Kern

2 Gliederung Gliederung 1 Einleitung Motivation Geschichte Projektteam Architektur Systemvoraussetzungen Linux-Kernel Plattform ADEOS ADEOS I-Pipe I-Pipe in Xenomai Xenomai-Mikrokernel HAL Nucleus Skins RT-Tasks Primär- und Sekundärmodus Interprozesskommunikation UVMs RTDM Anwendung Verwandte Projekte LiRE ELROB Anhang 15 2

3 1 Einleitung 1 Einleitung Da der normale Linux-Kernel vor allem auf Durchsatz und weniger auf kurze Antwortzeiten einzelner Prozesse getrimmt ist, stellt dies eine groÿe Hürde dar, Echtzeitanwendungen unter Linux einzusetzen. Seit einigen Jahren gibt es jedoch verstärkte Bestrebungen, Linux echtzeitfähig zu machen. Neben Projekten wie RTLinux und RTAI gibt es noch Xenomai, welches sich von den Genannten in einigen Punkten unterscheidet. Xenomai ist hierbei kein vollwertiges Betriebssystem, sondern ein Framework, welches Echtzeitanwendungen unter Linux möglich macht. Diese Studienarbeit beschäftigt sich mit diesem Ansatz. Die hier verwendeten Informationen stützen sich hauptsächlich auf die angebotenen Publikationen auf der Xenomai-Homepage (siehe [Xenomai]), welche die einzelnen Konzepte sehr gut beschreiben. Xenomai wurde ursprünglich unter GNA gehostet, einer Internet-Plattform für freie Software. Der Xenomai-Workspace ist dort unter [GNA] zu nden. 1.1 Motivation Die Entwickler von Xenomai hatten vor allem zwei groÿe Ziele: Erstens sollte der Linux-Kernel zu harter Echtzeit fähig gemacht werden, was durch die Kombination der Virtualisierungslösung ADEOS und einem eigenen - von Linux unabhängigen - Mikrokernel erreicht werden soll. Das zweite Ziel ist, eine bestmögliche Portierbarkeit für Anwendungen gängiger Echtzeitbetriebssysteme wie zum Beispiel VxWorks oder VRTX auf Linux sicherzustellen, da dies oft eine groÿe Hürde für den Linux-Einsatz ist. Dies wird mit dem Skin-Konzept und dem RTDM sowie dem groÿen Angebot an nutzbaren Plattformen ermöglicht. 1.2 Geschichte Das Xenomai-Projekt wurde im August 2001 gestartet und fusionierte 2003 mit dem RTAI- Projekt zu RTAI/fusion. Das Ziel war hier, die neue Version 4 von RTAI zu entwickeln. Nach Dierenzen der Entwickler in technischen Fragen wurde Xenomai im Oktober 2005 wieder selbstständig. Auf der Homepage werden in oft nur monatlichen Abständen neue Versionen freigegeben. Die aktuelle 2.2-Version stammt vom und trägt die Revisionsnummer , während die neue 2.3-Version bereits am in der Revision freigegeben wurde. 3

4 1 Einleitung 1.3 Projektteam Das aktuelle Projektteam von Xenomai besteht aus: Projekt-Verwalter: Philippe Gerum (auch beteiligt an dem ADEOS-Projekt) Gilles Chanteperdrix Bruno Rouchouse Mitglieder: Alexis Berlemont Dmitry Adamushko Jan Kiszka (auch beteiligt an den Projekten LiRE, RACK, ELROB und RTnet) Stelian Pop Wolfgang Grandegger 4

5 2 Architektur Die Architektur von Xenomai unterscheidet sich in einigen Punkten von der von RTLinux oder RTAI. Bei Xenomai wird die Hardware mittels ADEOS virtualisiert, zur Anwendungsebene sind die API-Skins ein besonderes Merkmal. Gemeinsam hat Xenomai mit den anderen Echtzeitbetriebssystemen den Mikrokernel, der von dem eigentlichen Linux-Kernel getrennt läuft. Während bei RT-Linux der Linux-Kernel als Leerlaufprozess des Mikrokernels läuft, kann Xenomai hier ADEOS benutzen, um eine Priorisierung zu erreichen. Programme laufen entweder wie gewohnt als Module des Mikrokernels, können aber in Xenomai auch zwischen dem Kernelspace und dem Userspace wechseln. Noch sehr junge Konzepte sind die UVM-Verwendung und das RTDM. 2.1 Systemvoraussetzungen Linux-Kernel Xenomai kann prinzipiell auf jedem Linux-Kernel der Version 2.4 oder 2.6 installiert werden. Wichtig ist hier, dass das dem System unterliegende ADEOS-Layer den ausgewählten Kernel auch unterstützt. Bei den Minorreleases des Linux-Kernels kann es Unterschiede bei den unterstützen Versionen geben, da die Entwickler Xenomai häug erst für wichtigere Plattformen anpassen Plattform Xenomai unterstützt für den Linux-Kernel der Version 2.6 mittlerweile die Plattformen x86 x86_64 (neu seit dem , vollständig in Version 2.4) IA64 (Intel Itanium) PowerPC 32 PowerPC 64 Diverse ARM-Prozessoren (PXA, SA1100, Integrator, S3C24xx, imx21, AT91) Blackn BF53x (Mikroprozessor von Analog Devices für Multimedia-Anwendungen) Für den Kernel 2.4 werden nur die Plattformen x86 und PowerPC 32 angeboten und es muss zusätzlich noch ein Kompatibilitäts-Layer verwendet werden, um Xenomai zu nutzen. 5

6 2.2 ADEOS ADEOS steht für Adaptive Domain Environment for Operating Systems. Es ist eine Virtualierungslösung, die es erlaubt, mehrere (Echtzeit-)Betriebssysteme unabhängig voneinander auf der selben Hardware laufen zu lassen. Diese Umgebungen nennt ADEOS Domains. Es können zusätzlich auch Domains erstellt werden, die kein Betriebssystem enthalten. Ein wesentlicher Bestandteil von ADEOS ist die sog. I-Pipe. Allgemeine Informationen über das ADEOS-Projekt nden Sie unter [ADEOS] ADEOS I-Pipe Als I-Pipe wird die Interrupt-Pipeline von ADEOS bezeichnet. Am Beginn der I-Pipe steht der Interrupt-Handler von ADEOS, welcher alle Hardware- oder Software-Interrupts sowie System Calls oder Signale des Linux-Kernels (im weiteren Verlauf nur noch als Interrupts bezeichnet) abfängt, bevor ein Betriebssytem diese erhält und eventuell maskieren könnte. Will eine Domain die Unterbrechungsanforderungen erhalten, so muss sie dies beim Handler anmelden. Auÿerdem werden alle Domains in einer vorher festzulegenden Reihenfolge an die Pipeline angebunden, was eine Priorisierung der einzelnen Domains erlaubt. Eine hoch priorisierte Domain kann eine niedriger priorisierte Domain immer sofort verdrängen, wenn sie rechnen möchte. Erhält der Handler nun einen Interrupt, so gibt er diesen an die erste Domain der Pipeline (höchste Priorität) weiter. Diese kann den Interrupt entweder sofort an die nächste Domain weiterleiten oder bearbeiten und dann erst weitergeben. Die Interrupts ieÿen so von Domain zu Domain, kommen aber auch an Domains vorbei, welche sie nicht erhalten wollen. Abbildung 1 zeigt eine schematische Darstellung der Interrupt-Pipeline. Die I-Pipe bietet für Domains noch zwei wichtige Funktionen: Die sogenannte Optimistic Interrupt Protection erlaubt es einer Domain, die Pipeline zu unterbrechen. Alle Interrupts ieÿen dann wie gewohnt bis vor die Domain, welche die Unterbrechung aufgerufen hat und werden dann in eine Log-Datei geschrieben. Die aufrufende Domain und alle nachfolgenden Domains erhalten dann diese Interrupts nicht mehr. Wird die Unterbrechung wieder aufgehoben, so werden erst die Interrupts der Log-Datei abgearbeitet und wieder auf die Pipeline gelegt. Diese Funktion kann verwendet werden, um zu Verhindern, dass eine Anwendung in einer kritischen Phase durch den Interrupt-Handler der eigenen Domain zu oft unterbrochen wird und somit eventuell ihre Zeitschranke verletzt. Eine weitere Funktion ist die Maskierung von Interrupts durch Domains. Eine Domain kann so die Weitergabe von für andere Domains unwichtigen Interrupts verhindern, so dass diese von den anderen Domains nicht mehr behandelt werden müssen. 6

7 Abbildung 1: Die ADEOS Interrupt-Pipeline (allgemein) I-Pipe in Xenomai Xenomai legt in ADEOS drei Domains an: Die erste Domain enthält den Xenomai-Mikrokernel und ist am höchsten priorisiert, weshalb sie auch Primary Domain genannt wird. Der Linux- Kernel erhält eine Domain mit niedriger Priorität am Ende der Pipeline, sie wird auch Secondary Domain genannt. Zwischen diesen beiden wird eine zusätzliche Domain mit dem Namen Interrupt-Shield angelegt, die kein Betriebssystem enthält und nur für das Maskieren von Interrupts und die Unterbrechung der Pipeline zuständig ist. Sie spielt nur eine Rolle, wenn man RT-Anwendungen im sekundären Modus verwendet (siehe Kapitel 2.4.1) und ist deshalb in der Standardinstallation deaktiviert. Abbildung 2 zeigt die I-Pipe nach der Installation von Xenomai. Abbildung 2: Die ADEOS Interrupt-Pipeline in Xenomai 7

8 2.3 Xenomai-Mikrokernel Der Xenomai-Mikrokernel wird per Kernel-Patch auf einem bestehenden Linux-Kernel installiert. Er bildet die im Kapitel angesprochene primäre Domain und kann deshalb jederzeit den Linux-Kernel der sekundären Domain verdrängen. Seine Bestandteile sind ein HAL, der Nucleus und verschiedene optionale Skins. Abbildung 3 zeigt die Anordnung der im folgenden beschriebenen Komponenten. Abbildung 3: Die Struktur des Mikrokernels HAL HAL steht für Hardware Abstraction Layer. Es bildet eine Abstraktionsschicht zwischen der Hardware (hier ADEOS) und dem Mikrokernel. Das HAL von Xenomai bildet die unterliegenden Plattformen auf Folgende ab: x86 x86, x86_64, IA64 PowerPC PowerPC 32 und 64 ARM PXA, SA1100, Integrator, S3C24xx, imx21, AT91 Blackn BF53x Der Mikrokernel muss demnach nur noch für diese vier Architekturen geschrieben werden, was den Aufwand erheblich erleichtert. 8

9 2.3.2 Nucleus Der eigentliche Mikrokernel wird in Xenomai auch als Nucleus bezeichnet. Er bietet einen Satz generischer Funktionen und Echtzeitdienste an, welche hauptsächlich die Bereitstellung von Timern, die Synchronisation und Kommunikation von Prozessen sowie das I/O-Handling übernehmen. Auÿerdem enthält er einen eigenen Scheduler für die auf ihm laufenden RT- Tasks. Dieser Scheduler stellt für die RT-Prozesse Prioritätsstufen von 1 bis 99 bereit, welche auf die ersten Prioritätstufen des Linux-Schedulers abgebildet werden können. Zu beachten ist hier, dass unter Xenomai 99 die höchste Priorität und 1 die niedrigste Priorität darstellt, während unter Linux dies umgekehrt ist. Linux-Tasks der Prioritätsstufen 1 bis 99 werden auch als Echtzeit-Tasks bezeichnet, obwohl sie keine deterministischen Antwortzeiten ermöglichen Skins Die Skin-Schicht ist ein sehr wichtiger Bestandteil des Xenomai-Mikrokernels. Sie bildet die APIs verschiedener anderer Echtzeitbetriebssysteme auf die generischen Funktionen des Mikrokernels ab. Gegenwärtig werden folgende APIs unterstützt: Native RTDM POSIX VxWorks VRTX psos+ µitron RTAI Native bezeichnet hier die eigene Schnittstelle des Xenomai-Mikrokernels, welche der API von RTAI stark ähnelt. Das RTDM wird in Kapitel 2.5 behandelt. 2.4 RT-Tasks Bei Echtzeitlösungen im Linux-Bereich wie z.b. RTLinux laufen Echtzeitanwendungen als Kernelmodule des Mikrokernels. Dies bringt einige Nachteile mit sich: So kann ein fehlerhaft programmiertes Modul einen Absturz des gesamten Betriebssystems verursachen (Kernel Panic). 9

10 Auch ist es schwieriger, solche Programme zu debuggen und der Datenaustausch mit normalen Anwendungen im Linux-Userspace ist komplizierter. Um diese Probleme abzuschwächen verfügt Xenomai über die Möglichkeit, Programmen einen Wechsel zwischen der primären und der sekundären Domain zu erlauben. Eine Anwendung läuft dann im sog. Primär- oder Sekundärmodus Primär- und Sekundärmodus Im Primärmodus läuft eine Anwendung wie gewohnt im Adressraum der Betriebsystems. Sie ermöglicht harte Echtzeitbedingungen, wird vom Scheduler des Mikrokernels verwaltet und kann die angebotenen Skins verwenden. Für den Linux-Kernel ist die Anwendung nicht sichtbar. Wird von der Anwendung ein Linux-System-Call durchgeführt, wechselt sie in den Sekundärmodus. Hier wird sie wie ein gewöhnlicher Linux-Task vom Linux-Scheduler verwaltet, kann System-Calls aufrufen und mit anderen Linux-Prozessen kommunizieren. Da sie nun auch im Userspace von Linux läuft, kennt der Xenomai-Mikrokernel nur noch einen sogenannten Shadow-Task, der nur als Platzhalter fungiert. Ihre Priorität unter dem Xenomai-Scheduler wird auf eine Linux-Priorität abgebildet (siehe Abschnitt 2.3.2). Jedoch sind hier Antwortzeiten der Anwendung nicht mehr deterministisch, da sie mit anderen Linux-Prozessen um die Rechenzeit konkurrieren muss. Hier kann der in Kapitel angesprochene Interrupt-Shield helfen, indem er die Interrupts anderer Linux-Tasks vom Linux-Kernel fernhält, solange ein Prozess im sekundären Modus rechnet. Damit werden die Antwortzeiten etwas verbessert, weil der Interrupt-Handler des Linux-Kernels oder andere Linux-Tasks den RT-Task nicht mehr so oft verdängen können. Wie ein Moduswechsel abläuft, zeigt auch Abbildung 4. Anwenden könnte man dieses Schema bei dem Start von Programmen, da hier noch keine Echtzeiteigenschaften nötig sind, aber z.b. Log-Meldungen des Programms angezeigt werden können. Denkbar wäre auch eine Anwendung, die mit einem RT-Thread im primären Modus Daten einliest und diese dann mit einem zweiten Thread im sekundären Modus weiterverarbeitet. Zum Datenaustausch können die im nächsten Kapitel beschriebenen Mittel zur Interprozesskommunikation verwendet werden Interprozesskommunikation Die Interprozesskommunikation kann auf zwei Arten erfolgen: Läuft ein Task im Sekundärmodus, so kann er einfach die Mechanismen des Linux-Kernels zur Kommunikation mit anderen Prozessen nutzen. Für einen Prozess im Primärmodus stellt Xenomai sogenannte RT-Pipes zur Verfügung. Diese sind FIFO-Puer, welche von Prozessen des Linux-Systems als auch von RT-Tasks des Mikrokernels gelesen und geschrieben werden können. Ein Linux-Prozess greift 10

11 Abbildung 4: Wechsel vom Sekundär- in den Primärmodus und zurück hierzu auf die im Linux-Gerätebereich bereitgestellten Devices /dev/rtp0-31 zu, für RT-Tasks werden die jeweiligen API-Befehle der Skins (sofern vorhanden) an die RT-Pipes angehängt. Beispielsweise kann ein RT-Task im primären Modus Daten von einem Bus lesen und diese über einen API-Befehl auf die RT-Pipe legen. Ein zweiter Task auf Linux-Seite kann diese Daten von einem angelegten Device lesen und am Bildschirm ausgeben oder in eine Datenbank schreiben. Somit kann eine einfache Kommunikation auch mit RT-Tasks ermöglicht werden, welche nur im Kernelspace laufen dürfen UVMs UVMs (Userspace Virtual Machines) sind ein relativ neuer Ansatz in Xenomai. UVMs sollen es erlauben, RT-Tasks komplett in den Linux-Userspace einzubetten und trotzdem Echtzeitfähigkeit zu erhalten. Auÿerdem enthalten UVMs die von dem Task benötigten Skins, weshalb sich der Mikrokernel nicht mehr um diese zu kümmern braucht. Führt ein RT-Task in der UVM einen API-Aufruf durch, so wird dieser von dem unterliegenden Skin in einen generischen Mikrokernel-Aufruf übersetzt und an den Mikrokernel weitergegeben. Der Mikrokernel nutzt wie in Abschnitt Shadow-Tasks, um die UVM-Tasks in den Kernelspace abzubilden. Abbildung 5 zeigt das bisherige Prinzip von Primär- und Sekundärmodus sowie den Betrieb mit UVMs. Dieses Konzept bietet eine Reihe von Vorteilen: Da die Skins nicht mehr als Kernelmodule laufen, kann ein Programmierfehler nur noch die UVM, nicht aber das ganze System zum Absturz bringen. Die Entwicklung wird ebenfalls dadurch erleichtert. Es können (je nach Hardware) sehr viele parallele UVMs erstellt werden, die unabhängig voneinander laufen. Durch die 11

12 Abbildung 5: RT-Tasks ohne und mit UVM Einbettung kann jede Echtzeitanwendung bequem über ein Linux-Executable gestartet werden. Jedoch wirkt sich eine UVM nachteilig auf die Antwortzeiten eines Tasks aus. Bei gröÿerer Systemlast verursacht durch Linux-Prozesse ist das Verhalten einer UVM nicht mehr deterministisch. Auÿerdem muss für jede einzubettende Anwendung eine neue UVM entwickelt und angepasst werden. 2.5 RTDM Das Realtime Driver Model wurde mit dem Gedanken entwickelt, ein einheitliches Treibermodell mit Echtzeitfähigkeit zu schaen. Das RTDM wird als eigener Skin für den Mikrokernel geladen, um die Funktionen anderer Skins nicht zu beeinussen. Es bietet eine High-Level-API, die dem POSIX-I/O-Modell ähnelt und eine eigene, sehr kompakte Low-Level-API. Ein Gerät kann als Protokoll Device eingebunden werden, was eine nachrichtenbasierte Kommunikation wie bei POSIX-Sockets ermöglicht. Andererseits kann es auch als Name Device behandelt werden, was einen Stream mit einer sehr kompakt gehaltenen API darstellt, der nur einfache Lese- und Schreiboperationen erlaubt. 12

13 3 Anwendung 3 Anwendung 3.1 Verwandte Projekte Mittlerweile gibt es eine Vielzahl von Projekten, die Echtzeit-Erweiterungen für Linux entwickeln und auch schon unter Xenomai einsetzbar sind: RTnet: Echtzeit-Netzwerk-Stack RT-Firewire: Echtzeit-Firewire-Stack USB4RT, USB20RT: Echtzeit-USB-Stack COMEDI over RTDM: Datenerfassung OROCOS: Open Robot Control Software RACK: Robotics Application Construction Kit CANFestival: CANOpen Framework Xeno- -: C++ Interface für das Native Skin (andere Skins geplant) LTTng: Linux Tracer Toolkit Next Generation kgdb: Remote Kernel Debugger BusyBox: Abgespeckte Varianten der GNU-Tools 3.2 LiRE Diese Linux-Distribution für Robotik-Anwendungen wurde an der Leibniz Universität Hannover entwickelt. LiRE steht für Linux Realtime Environment. Seit der Version 0.6 setzt LiRE Xenomai ein, vorher wurde RTAI genutzt. Von den in Kapitel 3.1 genannten Projekten verwendet LiRE in der aktuellen Version den Netzwerk-Stack RTNet und die Robotik-Anwendung RACK Es basiert auf dem Linux-Kernel der Version und Xenomai ELROB Das ELROB 2006 Projekt des Instituts für System Engineering an der Leibniz Universität Hannover beschäftigt sich mit Robotik. ELROB steht für 1st European Land Robot Trial. Kern 13

14 3 Anwendung sind die drei Forschungs-Roboter RTS-Dora, RTS-MoRob-Kit und RTS-Crawler mit jeweils unterschiedlichen Anwendungsbereichen. RTS-Dora wird primär zur Erprobung von Navigation in urbanem Gelände eingesetzt, RTS-MoRob-Kit als autonomer mobiler WLAN-Repeater und RTS-Crawler zur Erkundung von unwegsamen Gelände. Alle Roboter setzen hierbei das im vorherigen Kapitel angesprochene LiRE ein und basieren auf der Robotik-Anwendung RACK. Abbildung 6 zeigt die drei Roboter. Datenblätter, Bilder und Videos von Fahrten sind unter [ELROB] zu nden. Abbildung 6: RTS-Dora, RTS-MoRob-Kit und RTS-Crawler 14

15 4 Anhang 4 Anhang Abbildungsverzeichnis 1 Die ADEOS Interrupt-Pipeline (allgemein) Die ADEOS Interrupt-Pipeline in Xenomai Die Struktur des Mikrokernels Wechsel vom Sekundär- in den Primärmodus und zurück RT-Tasks ohne und mit UVM RTS-Dora, RTS-MoRob-Kit und RTS-Crawler Literatur [ADEOS] [ELROB] Forschung Navigation autonomer Systeme im Outdoor-Bereich [GNA] [LiRE] [Xenomai] 15