1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
\input{confighandout}
\subsection{Realtime Linux}
\subsubsection{Grundlagen}
\paragraph{Was ist Echtzeit?}
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\"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.
\item Jitter: Mit Jitter bezeichnet man die Varianz der Latenzzeit.
\end{itemize}
\paragraph{Anwendungsbereiche}
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\"assige Abwicklung von Finanztransaktionen \"uber hochverteilte Systeme.
\paragraph{Anforderungen an ein Echtzeitsystem}
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\"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\"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\"ost werden kann dieses Problem durch ''prioriy inheritance'' und ''priority ceiling''.
\begin{itemize}
\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\"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\"unglich nicht als
solches designt. Als General Purpose Operating System wurde Linux auf Fairness
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\"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
und ist die Variante, die von den Linux Entwicklern zur Integration in den
Hauptzweig von Linux abgenickt wurde.
\end{itemize}
\paragraph{RTAI}
Das Realtime Application Interface (RTAI) ist eine Entwicklung der Technischen
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\"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
\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.
\paragraph{Xenomai}
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\"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
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\"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\"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]
\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}
\paragraph{Preempt RT}
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\"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\"unglichen Spinlocks.
\item Threaded Interrupt Handlers: Interrupt Handler laufen per Default nicht im
harten Interruptkontext, sondern als Kernelthread.
\end{itemize}
Viele Mechanismen, die urspr\"unglich in Preempt RT entwickelt wurden, haben
bereits Ihren Weg in den Mainline Linuxzweig gefunden: High Resolution Timer
(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\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\"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{\"Uberblick Preempt RT}
\label{img:preempt_rt}
\end{figure}
Wie Abbildung \ref{img:preempt_rt} zeigt, integriert Preempt RT die
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\"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}
|
