path: root/realtime/rt-basics/handout_rt-basics_de.tex

\documentclass{lxarticle}
\usepackage{german}
\usepackage[utf8]{inputenc}
\usepackage{lxheaders}
\usepackage{lxextras}

\begin{document}

\section*{Realtime Linux}

\subsection*{Grundlagen}

\subsubsection*{Was ist Echteit?}
Vor der Betrachtung verschiedener Ansätze, Linux echtzeitfähig zu machen, ist es
notwendig einige grundlegende Begrifflichkeiten zur erläutern:
\begin{itemize}
\item Echtzeit:
Zur Definition eines Echtzeitsystems kann man folgende Aussagen Treffen: Auf
einem Echtzeitsystem hängt die Korrektheit einer Berechnung nicht nur von deren
logischen Korrektheit, sondern auch von der Ausführung zum korrekten Zeitpunkt
ab. Das Nichteinhalten eines bestimmten Zeitrahmens resultiert in einem Fehler.
\item Latenzzeit: Unter Latenzzeit versteht man den Zeitraum zwischen dem
Auftreten eines Events und der Reaktion auf dieses Event.
\item Jitter: Mit Jitter bezeichnet man die Varianz der Latenzzeit.
\end{itemize}

\subsubsection*{Anwendungsbereiche}
Die wohl gängigsten Anwendungsbereiche für Echtzeitsysteme sind die
Steuerungs- und Automatisierungstechnik, Multimediasysteme und die Luft- und
Raumfahrttechnik. Ein weiteres interessantes Einsatzgebiet stellt die 
Finanzdienstleistung dar. Hier geht es insbesondere um die zeitgenaue,
zuverlässige Abwicklung von Finanztransaktionen über hochverteilte Systeme.

\subsubsection*{Anforderungen an ein Echtzeitsystem}
Ein Echtzeitsystem muß in der Lage sein, in einem garantierten Zeitrahmen auf
ein Ereignis zu reagieren. Es muß also möglich sein, in möglichst kurzer Zeit
von einer niederprioren Task auf eine hochpriore Task umzuschalten, falls diese
Rechenzeit benötigt. Das System muß also möglichst ''feingranular''
unterbrechbar sein.
Doch allein die Unterbrechbarkeit kann kein deterministisches Zeitverhalten
garantieren. So kann eine niederpriore Task Resourcen blockieren, die von einer
hochprioren Task benötigt werden. Wird die niederpriore Task nun unterbrochen,
kommt es zur ''Prioritätsinversion / priority inversion'', da die hochpriore Task
auf die Freigabe der Resource wartet, diese aber erst wieder dann freigegeben
wird, wenn die niederpriore Task wieder Rechenzeit bekommt.
Gelöst werden kann dieses Problem durch ''prioriy inheritance'' und ''priority ceiling''.
\begin{itemize}
\item Prioritätsvererbung / priority inheritance: Hier wird die Priorität der
niederprioren Task angehoben, um zu erreichen, daß die blockierte Resource
freigegeben kann.
\item Prioritätsgrenzen / priority ceiling: Hier wird für jede Resource eine
Prioritätsgrenze festgelegt. Jede Task, die die Resource belegt, wird auf die
Prioritätsgrenze der Resource angehoben.
\end{itemize}

\subsection*{Realtime Linux Varianten}
\subsubsection*{Historisches zu Echtzeitlinux}
Im Gegensatz zu traditionellen Echtzeitsystem wurde Linux ursprünglich nicht als
solches designt. Als General Purpose Operating System wurde Linux auf Fairness
und Durchsatz optimiert. Linux echtzeitfähig zu machen, bedeutet also, ein
Standardbetriebssystem um Echtzeitfunktionen bzw. entsprechende Sonderfälle zu
erweitern. Mit dieser Tatsache lassen sich die zwei technischen Ansätze für
Realtime Linux erklären.
\begin{itemize}
\item Dual Kernel Ansatz: Hier koexistieren ein Echtzeitkernel, der für alle
zeitkritischen Dinge zuständig ist, und ein Standard Linux Kernel. Dieser Ansatz
setzt voraus, daß alle externen Events zuerst vom Echtzeitkernel bearbeitet
werden, bevor Sie an den Linux Kernel weitergereicht werden können. Die
bekanntesten Vertreter dieser Technik sind RTAI und Xenomai.
\item In-Kernel Ansatz: Diese Methode macht Linux an sich zu einem
Echtzeitsystem. Dieser Ansatz wird mit dem Realtime Preemption Patch verfolgt
und ist die Variante, die von den Linux Entwicklern zur Integration in den
Hauptzweig von Linux abgenickt wurde.
\end{itemize}

\subsubsection*{RTAI}
Das Realtime Application Interface (RTAI) ist eine Entwicklung der Technischen
Universität Mailand und entstand unter der Schirmherrschaft von Professor Paolo
Mantegazza. Oberstes Designziel von RTAI ist und war es, die kleinstmöglichen
Latenzzeiten auf einer gegebenen Hardwareplattform zu erzielen. Dieses
Designziel bedingt diverse Einschränkungen für RTAI Applikationen. Weiterhin
wird nur eine recht kleine Anzahl an Zielplattormen unterstützt (derzeit x86,
x86\_64 und diverse ARM Plattformen).
\begin{figure}[h]
\centering
\includegraphics[height=0.5\textwidth]{images/rtai.png}
\caption{Technischer Aufbau von RTAI}
\label{img:rtai}
\end{figure}
RTAI ist ein typischer Vertreter des Dual Kernel Ansatzes. Abbildung
\ref{img:rtai} zeigt die Funktionsweise von RTAI.

\subsubsection*{Xenomai}
Das Xenomai Projekt wurde im Jahre 2001 gegründet. Im Gegensatz zu RTAI erlaubt
Xenomai auch Echtzeit im Userpace (RTAI erlaubt dies nur sehr eingeschränkt).
Die Besonderheit von Xenomai sind die sogenannten Skins, die es vereinfachen sollen,
Applikationen von proprietären Echtzeitsystemen nach Xenomai zu portieren.
Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit
folgende Architekturen: PowerPC32, PowerPC64, x86, x86\_64, Blackfin, ARM und
ia64). Die zentralen Begriffe im Designkonzept von Xenomai stellen Xenomai
Nucleus, die Interrupt Pipeline (IPIPE), Hardware Abstraction Layer (HAL) und
System Abstraction Layer (SAL) dar.
IPIPE kann bildlich als virtueller Interruptkontroller betrachtet werden.
Sie organisiert das System in verschiedenen Domains. Interrupts werden von
IPIPE entgegengenommen und an die einzelnen Domains verteilt.
Nucleus beeinhaltet die Xenomai Core Funktionalität. Dieser ist zuständig dafür,
alle notwendigen Resourcen, die Skins benötigen, um die Funktionalität von
RTOSsen nachzubilden. Der Hardware Abstraction Layer beinhaltet den Plattform
und CPU abhängigen Code. Alle darüberliegenden Layer (darunter auch Nucleus)
bauen darauf auf. HAL ist kombiniert mit dem System Abstraction Layer. Dieser
soll die darüberliegenden Layer, wie z.B. Nucleus, noch portierbarer machen.
Abbildung \ref{img:xenomai} zeigt das technische Zusammenspiel der Xenomai
Komponenten. Abbildung \ref{img:ipipe} zeigt die Funktionsweise von IPIPE.
\begin{figure}[h]
\centering
\includegraphics[height=0.5\textwidth]{images/xenomai.png}
\caption{Technischer Aufbau von Xenomai}
\label{img:xenomai}
\end{figure}
\begin{figure}[h]
\centering
\includegraphics[height=0.5\textwidth]{images/ipipe.png}
\caption{Technische Funktionsweise von IPIPE}
\label{img:ipipe}
\end{figure}

\subsubsection*{Preempt RT}
Der Realtime Preemption Patch entstand ursprünglich aus Arbeiten von Ingo Molnar
und Thomas Gleixner. Beide sind bis zum heutigen Zeitpunkt die treibenden Kräfte
bei der Entwicklung von Preempt RT.
Im Gegensatz zu RTAI und Xenomai macht Preempt RT den Linux Kernel an sich
echtzeitfähig. Dies wird im Besonderen durch folgende Mechanismen erreicht:
\begin{itemize}
\item Sleeping Spinlocks: Spinlocks werden durch RT Mutexe ersetzt. Raw
Spinlocks ersetzen die Eigenschaft der ursprünglichen Spinlocks.
\item Threaded Interrupt Handlers: Interrupt Handler laufen per Default nicht im
harten Interruptkontext, sondern als Kernelthread.
\end{itemize}
Viele Mechanismen, die ursprünglich in Preempt RT entwickelt wurden, haben
bereits Ihren Weg in den Mainline Linuxzweig gefunden: High Resolution Timer
(Hochauflösende Timer unabhängig vom Scheduler Tick), Priority Inheritance,
generisches Interrupthandling für alle Architekturen und mit 2.6.30 nun auch die
Threaded Interrupt Handler.
Weiterhin hat sich die Linux Entwicklergemeinde bereits 2006 darauf geeinigt,
daß Preempt RT in den Linux Kernel integriert wird. Weiterhin bietet der
Realtime Preempton Patch den großen Vorteil, daß Echtzeitapplikationen als POSIX
Realtime Applikationen geschrieben werden. Es wird keine spezielle API
verwendet. Preempt RT Unterstützt eine Vielzahl von Architekturen (PowerPc, x86,
x86\_64, MIPS, ARM, ...).
\begin{figure}[h]
\centering
\includegraphics[height=0.5\textwidth]{images/preempt_rt.png}
\caption{Überblick Preempt RT}
\label{img:preempt_rt}
\end{figure}
Wie Abbildung \ref{img:preempt_rt} zeigt, integriert Preempt RT die
Echtzeitfunktionalität ''natlos'' in den Linux Kernel. Auch die Entwickler
anderer Projekte haben die Vorzüge von Preempt RT bereits erkannt. Die Roadmap
für Xenomai 3 sieht Preempt RT Support vor. Dies würde den Einsatz von Xenomai
Skins auf Preempt RT Kerneln ermgöglichen.

\subsection*{Kontrollfragen}

\begin{enumerate}
\item Was sind die wichtigsten Anforderungen an ein Echtzeitsystem?
\item Welche beiden Ansätze gibt es, um Linux echtzeitfähig zu machen?
\item Was sind die bekanntesten Vertreter für Echtzeitlinux und welchen der oben
beschriebenen Ansätze verfolgen Sie?
\item Wird für das Schreiben einer Echtzeitapplikation mit Preempt RT eine
spezielle API benötigt?
\end{enumerate}

\end{document}