diff options
Diffstat (limited to 'realtime/rt-basics/handout_rt-basics_de.tex')
| -rw-r--r-- | realtime/rt-basics/handout_rt-basics_de.tex | 168 |
1 files changed, 162 insertions, 6 deletions
diff --git a/realtime/rt-basics/handout_rt-basics_de.tex b/realtime/rt-basics/handout_rt-basics_de.tex index 4c391b2..8576b7d 100644 --- a/realtime/rt-basics/handout_rt-basics_de.tex +++ b/realtime/rt-basics/handout_rt-basics_de.tex @@ -1,17 +1,173 @@ -\documentclass{article} +\documentclass{lxarticle} \usepackage{german} \usepackage[utf8]{inputenc} +\usepackage{lxheaders} +\usepackage{lxextras} \begin{document} -\section*{Titel} +\section*{Realtime Linux} -\subsection*{Abschnitt1} +\subsection*{Grundlagen} -Text +\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} -\subsection*{Abschnitt2} +\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. -Text +\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} |