diff options
Diffstat (limited to 'realtime/rt-basics/handout_rt-basics_de.tex')
| -rw-r--r-- | realtime/rt-basics/handout_rt-basics_de.tex | 116 |
1 files changed, 58 insertions, 58 deletions
diff --git a/realtime/rt-basics/handout_rt-basics_de.tex b/realtime/rt-basics/handout_rt-basics_de.tex index dd775b6..8580797 100644 --- a/realtime/rt-basics/handout_rt-basics_de.tex +++ b/realtime/rt-basics/handout_rt-basics_de.tex @@ -5,13 +5,13 @@ \subsubsection{Grundlagen} \paragraph{Was ist Echtzeit?} -Vor der Betrachtung verschiedener Ansätze, Linux echtzeitfähig zu machen, ist es -notwendig, einige grundlegende Begrifflichkeiten zur erläutern: +Vor der Betrachtung verschiedener Ans\"atze, Linux echtzeitf\"ahig zu machen, ist es +notwendig, einige grundlegende Begrifflichkeiten zur erl\"autern: \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 ihrer -logischen Korrektheit, sondern auch von der Ausführung zum korrekten Zeitpunkt +einem Echtzeitsystem h\"angt die Korrektheit einer Berechnung nicht nur von ihrer +logischen Korrektheit, sondern auch von der Ausf\"uhrung 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. @@ -19,47 +19,47 @@ Auftreten eines Events und der Reaktion auf dieses Event. \end{itemize} \paragraph{Anwendungsbereiche} -Die wohl gängigsten Anwendungsbereiche für Echtzeitsysteme sind die +Die wohl g\"angigsten Anwendungsbereiche f\"ur 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. +zuverl\"assige Abwicklung von Finanztransaktionen \"uber hochverteilte Systeme. \paragraph{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 +Ein Echtzeitsystem mu\ss in der Lage sein, in einem garantierten Zeitrahmen auf +ein Ereignis zu reagieren. Es mu\ss also m\"oglich sein, in m\"oglichst kurzer Zeit von einer niederprioren Task auf eine hochpriore Task umzuschalten, falls diese -Rechenzeit benötigt. Das System muß also möglichst ''feingranular'' +Rechenzeit ben\"otigt. Das System mu\ss also m\"oglichst ''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 +hochprioren Task ben\"otigt werden. Wird die niederpriore Task nun unterbrochen, +kommt es zur ''Priorit\"atsinversion / 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''. +Gel\"ost 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 +\item Priorit\"atsvererbung / priority inheritance: Hier wird die Priorit\"at der +niederprioren Task angehoben, um zu erreichen, da\ss die blockierte Resource freigegeben werden 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. +\item Priorit\"atsgrenzen / priority ceiling: Hier wird f\"ur jede Resource eine +Priorit\"atsgrenze festgelegt. Jede Task, die die Resource belegt, wird auf die +Priorit\"atsgrenze der Resource angehoben. \end{itemize} \subsubsection{Realtime Linux Varianten} \paragraph{Historisches zu Echtzeitlinux} -Im Gegensatz zu traditionellen Echtzeitsystem wurde Linux ursprünglich nicht als +Im Gegensatz zu traditionellen Echtzeitsystem wurde Linux urspr\"unglich 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. +und Durchsatz optimiert. Linux echtzeitf\"ahig zu machen, bedeutet also, ein +Standardbetriebssystem um Echtzeitfunktionen bzw. entsprechende Sonderf\"alle zu +erweitern. Mit dieser Tatsache lassen sich die zwei technischen Ans\"atze f\"ur +Realtime Linux erkl\"aren. \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 +\item Dual Kernel Ansatz: Hier koexistieren ein Echtzeitkernel, der f\"ur alle +zeitkritischen Dinge zust\"andig ist, und ein Standard Linux Kernel. Dieser Ansatz +setzt voraus, da\ss alle externen Events zuerst vom Echtzeitkernel bearbeitet +werden, bevor Sie an den Linux Kernel weitergereicht werden k\"onnen. 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 @@ -69,11 +69,11 @@ Hauptzweig von Linux abgenickt wurde. \paragraph{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 +Universit\"at Mailand und entstand unter der Schirmherrschaft von Professor Paolo +Mantegazza. Oberstes Designziel von RTAI ist und war es, die kleinstm\"oglichen 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, +Designziel bedingt diverse Einschr\"ankungen f\"ur RTAI Applikationen. Weiterhin +wird nur eine recht kleine Anzahl an Zielplattormen unterst\"utzt (derzeit x86, x86\_64 und diverse ARM Plattformen). \begin{figure}[h] \centering @@ -85,11 +85,11 @@ RTAI ist ein typischer Vertreter des Dual Kernel Ansatzes. Abbildung \ref{img:rtai} zeigt die Funktionsweise von RTAI. \paragraph{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). +Das Xenomai Projekt wurde im Jahre 2001 gegr\"undet. Im Gegensatz zu RTAI erlaubt +Xenomai auch Echtzeit im Userpace (RTAI erlaubt dies nur sehr eingeschr\"ankt). Die Besonderheit von Xenomai sind die sogenannten Skins, die es vereinfachen sollen, Applikationen von anderen Echtzeitsystemen nach Xenomai zu portieren. -Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit +Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterst\"utzt 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 @@ -97,12 +97,12 @@ 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 bereitzustellen, die Skins benötigen, um die Funktionalität -von RTOSsen nachbilden zu können. Der Hardware Abstraction Layer beinhaltet -den Plattform und CPU abhängigen Code. Alle darüberliegenden Layer (darunter auch Nucleus) +Nucleus beeinhaltet die Xenomai Core Funktionalit\"at. Dieser ist zust\"andig daf\"ur, +alle notwendigen Resourcen bereitzustellen, die Skins ben\"otigen, um die Funktionalit\"at +von RTOSsen nachbilden zu k\"onnen. Der Hardware Abstraction Layer beinhaltet +den Plattform und CPU abh\"angigen Code. Alle dar\"uberliegenden 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. +soll die dar\"uberliegenden 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] @@ -119,49 +119,49 @@ Komponenten. Abbildung \ref{img:ipipe} zeigt die Funktionsweise von IPIPE. \end{figure} \paragraph{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 +Der Realtime Preemption Patch entstand urspr\"unglich aus Arbeiten von Ingo Molnar +und Thomas Gleixner. Beide sind bis zum heutigen Zeitpunkt die treibenden Kr\"afte 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: +echtzeitf\"ahig. 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. +Spinlocks ersetzen die Eigenschaft der urspr\"unglichen 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 +Viele Mechanismen, die urspr\"unglich 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 +(Hochaufl\"osende Timer unabh\"angig vom Scheduler Tick), Priority Inheritance, +generisches Interrupthandling f\"ur 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 Preemption Patch den großen Vorteil, daß Echtzeitapplikationen als POSIX +da\ss Preempt RT in den Linux Kernel integriert wird. Weiterhin bietet der +Realtime Preemption Patch den gro\ss en Vorteil, da\ss Echtzeitapplikationen als POSIX Realtime Applikationen geschrieben werden. Es wird keine spezielle API -verwendet. Preempt RT Unterstützt eine Vielzahl von Architekturen (PowerPc, x86, +verwendet. Preempt RT Unterst\"utzt 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} +\caption{\"Uberblick Preempt RT} \label{img:preempt_rt} \end{figure} Wie Abbildung \ref{img:preempt_rt} zeigt, integriert Preempt RT die -Echtzeitfunktionalität ''nahtlos'' 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. +Echtzeitfunktionalit\"at ''nahtlos'' in den Linux Kernel. Auch die Entwickler +anderer Projekte haben die Vorz\"uge von Preempt RT bereits erkannt. Die Roadmap +f\"ur Xenomai 3 sieht Preempt RT Support vor. Dies w\"urde den Einsatz von Xenomai +Skins auf Preempt RT Kerneln ermg\"oglichen. \subsubsection{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 welche der oben -beschriebenen Ansätze verfolgen Sie? -\item Wird für das Schreiben einer Echtzeitapplikation mit Preempt RT eine -spezielle API benötigt? +\item Welche beiden Ans\"atze gibt es, um Linux echtzeitf\"ahig zu machen? +\item Was sind die bekanntesten Vertreter f\"ur Echtzeitlinux und welche der oben +beschriebenen Ans\"atze verfolgen Sie? +\item Wird f\"ur das Schreiben einer Echtzeitapplikation mit Preempt RT eine +spezielle API ben\"otigt? \end{enumerate} \input{tailhandout} |