Untersuchung von Ans atzen zur CAN-Kommunikation in Echtzeit unter Linux
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
L E H R S T U H L F Ü R R E A L Z E I T - C O M P U T E R S Y S T E M E
T E C H N I S C H E U N I V E R S I T Ä T M Ü N C H E N
U N I V. - P R O F. D R. - I N G. G. F Ä R B E R
Untersuchung von Ansätzen zur
CAN-Kommunikation in Echtzeit unter
Linux
Matthias Keller
BachelorarbeitUntersuchung von Ansätzen zur
CAN-Kommunikation in Echtzeit unter Linux
Bachelorarbeit
Betreut durch den Lehrstuhl für Realzeit-Computersysteme
Technische Universität München
Prof. Dr.-Ing. Georg Färber
Ausgeführt bei DaimlerChrysler Forschung&Technologie, Abteilung REI/AU, Ulm
Betreuer: Dipl.–Ing. Sebastian Drössler
Bearbeiter: Matthias Keller
Hildachstraße 7a
81245 München
Eingereicht im Mai 2006t4
Danksagung Ich möchte mich bei Herrn Prof. Dr.–Ing. G. Färber und Herrn Dipl.–Ing. S. Drössler be- danken, dass sie eine Betreuung dieser Bachelorarbeit durch den Lehrstuhl für Realzeit– Computersysteme möglich gemacht haben. Ebenso möchte ich mich bei Herrn N. Appenrodt und Herrn M. Skutek bedanken, dass sie diese Bachelorarbeit in der Abteilung REI/AU am Forschungszentrum Ulm der DaimlerChrysler AG ermöglicht haben. Ein weiterer Dank geht an Herrn M. Steiner aus der Abteilung für Messtechnik der Fahrzeu- gentwicklung in Sindelfingen für die Bereitstellung der Geräte zur Durchführung der für diese Arbeit sehr wichtigen Messungen. Mein besonderer Dank gilt meinen Betreuern, die mich jederzeit tatkräftig in allen Belangen unterstützt haben. Sie waren maßgeblich am Gelingen dieser Arbeit beteiligt. Außerdem möchte ich allen Mitarbeitern der Abteilung REI/AU für das freundliche, kollegiale Arbeitsklima danken. Angeregte Diskussionen verhalfen mir zu neuen Ansätzen München, im Mai 2006
Inhaltsverzeichnis
Abbildungsverzeichnis viii
Tabellenverzeichnis ix
Verzeichnis der verwendeten Symbole x
1 Einleitung 1
2 Grundlagen 3
2.1 CAN-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Medium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.3 Übertragungsrate und Leitungslänge . . . . . . . . . . . . . . . . . 4
2.1.4 Objektidentifier und Buszugriff . . . . . . . . . . . . . . . . . . . . 4
2.1.5 Frame-Formate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.6 Einschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Echtzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Latenzzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4 Deadline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.5 Weiche und harte Echtzeit . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.6 Programmierung von Echtzeitsystemen . . . . . . . . . . . . . . . . 7
2.3 Wichtige Konzepte eines Betriebssystems am Beispiel Linux . . . . . . . . 8
2.3.1 Rechenprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Kernel-Modus und Benutzer-Modus . . . . . . . . . . . . . . . . . . 8
2.3.3 Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.4 Kernelspace und Userspace . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.5 Ein-/Ausgabegeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.6 Multitasking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.7 Interruptsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.8 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.9 Semaphoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.10 Gemeinsam genutzte Speicherbereiche . . . . . . . . . . . . . . . . . 13
2.3.11 FIFO Puffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.12 Ringpuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
vInhaltsverzeichnis
3 Echtzeitsysteme auf Linux-Basis 15
3.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Einschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Lösungsansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Adeos Nanokernel mit Interrupt Pipeline . . . . . . . . . . . . . . . 19
3.2.3 Taktgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.4 Zeitmessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.5 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.6 Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.7 Weitere Funktionen von RTAI . . . . . . . . . . . . . . . . . . . . . 23
3.2.8 Entwicklung von RT Applikationen im Kernelspace . . . . . . . . . 26
3.2.9 Entwicklung von RT Applikationen mit LXRT im Userspace . . . . 29
3.2.10 Hinweise zur Entwicklung von RT Applikationen mit RTAI . . . . . 30
3.2.11 Hardwareunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Weitere Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Entwicklung eines CAN-Treibers für RTAI 32
4.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Realtime CAN for Linux/RTAI . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 Hardware-Abstraktions-Schicht . . . . . . . . . . . . . . . . . . . . 34
4.3.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.3 Unterstützte Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.4 Wichtige Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.5 Projektstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Entwicklung der Anpassung für den PCAN-PCI Adapter . . . . . . . . . . 35
4.4.1 Wahl des Rahmens . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.2 Einschränkungen und Probleme von Rtcan . . . . . . . . . . . . . . 35
4.4.3 Hardware-spezifische Anpassungen . . . . . . . . . . . . . . . . . . 37
4.4.4 Entwicklung einer Benutzerschnittstelle . . . . . . . . . . . . . . . . 38
4.4.5 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.6 Einschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.7 Installation und Verwendung . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Socket-basierter CAN-Treiber . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Messungen zur Beurteilung des Echtzeitverhaltens 42
5.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Ziel der Messungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.1 CAN Datenlogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.2 Testsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
viInhaltsverzeichnis
5.3.3 Konfigurationen des Linux-PC . . . . . . . . . . . . . . . . . . . . . 44
5.3.4 Lastgeneratoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4 Testszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4.1 Szenario 1: Periodisches Senden einer CAN-Nachricht . . . . . . . . 46
5.4.2 Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten 46
5.4.3 Szenario 3: Messung der Reaktionszeit über den CAN-Bus . . . . . 47
5.5 Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6.1 Allgemeine Aufbereitung der Daten . . . . . . . . . . . . . . . . . . 47
5.6.2 Periodische Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6.3 Reaktionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.7 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.7.1 Szenario 1: Periodisches Senden einer CAN-Nachricht . . . . . . . . 50
5.7.2 Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten 52
5.7.3 Szenario 3: Messung der Reaktionszeit über den CAN-Bus . . . . . 53
5.7.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6 Fazit und Ausblick 56
A Installation der verwendeten Software 57
B Auflistung aller Testergebnisse 59
C QT RTcan Display 63
D Quellcode 65
D.1 Rtcan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
D.2 Demo-Programme für Rtcan . . . . . . . . . . . . . . . . . . . . . . . . . . 65
D.3 QT RTcan Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
D.4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
D.5 Auswertung der Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Literaturverzeichnis 67
viiAbbildungsverzeichnis
2.1 Abrupter Schaden bei der Überschreitung der Deadline bei einer harten
Echtzeitanforderung. [Sch02] . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Interrupt Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Systemaufbau ohne und mit Interrupt Pipeline . . . . . . . . . . . . . . . . 20
4.1 PCAN-PCI Einsteckkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Aufbau des PCAN-PCI Adapters . . . . . . . . . . . . . . . . . . . . . . . 33
5.1 Messung 7: RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Messung 15: Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 Messung 11: PCAN-View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 Messung 4: LXRT, höchstpriorer Task . . . . . . . . . . . . . . . . . . . . 53
5.5 Messung 4: LXRT, niedrigstpriorer Task . . . . . . . . . . . . . . . . . . . 53
5.6 Messung 24: Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.7 Messung 29: LXRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
C.1 Screenshot von QT RTcan Display . . . . . . . . . . . . . . . . . . . . . . 63
viiiTabellenverzeichnis
2.1 Werte auf dem CAN-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Maximale Leitungslänge bei vorgegebener Übertragungsrate . . . . . . . . 4
2.3 Einige Ziele des Scheduling-Algorithmus bei verschiedenen Umgebungen . . 11
2.4 Prozesszustände unter Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 FIFO API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 Maximale Abweichung von der Periode von 1 ms . . . . . . . . . . . . . . 50
5.2 Durchschnittliche Abweichung von der Periode von 1 ms . . . . . . . . . . 51
5.3 Vergleich der maximalen Abweichung über Szenario 1 & 2 . . . . . . . . . 52
5.4 Vergleich der durchschnittlichen Abweichung über Szenario 1 &2 . . . . . 53
5.5 Maximale Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6 Durchschnittliche Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . 54
B.1 Szenario 1: Periodisches Senden einer CAN-Nachricht . . . . . . . . . . . . 60
B.2 Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten . . 61
B.3 Szenario 3: Messung der Reaktionszeit über den CAN-Bus . . . . . . . . . 62
ixVerzeichnis der verwendeten Symbole
ACPI Advanced Configuration and Power Interface
ADEOS Adaptive Domain Environment for Operating Systems
APM Advanced Power Management
API Programmierschnittstelle (Application Programming Interface)
CAN Feldbussystem (Controller Area Network)
CPU Prozessor (Central Processing Unit)
CRC zyklische Redundanzprüfung (Cyclic Redundancy Code)
CSMA/CA Carrier Sense Multiple Access/Collision Avoidance
DIAPM Dipartimento di Ingegneria Aerospaziale
DV Datenverarbeitung
EDF Scheduler-Strategie (Earliest Deadline First)
GNU GNU is not UNIX
GPL GNU Public Licence
HAL Hardware-Abstraktions-Schicht (Hardware Abstraction Layer)
IPC Interprozesskommunikation
IPIPE Interrupt Pipeline
LXRT Linux Real-Time
MOST Feldbussystem (Media Oriented Systems Transport)
PITA PCI Interface for Telephony/Data Applications
POSIX standardisiertes Applikationsebeneninterface, das die Schnittstelle
zwischen Applikation und dem Betriebssystem darstellt
(Portable Operating System Interface for UniX)
QT Programm-Bibliothek zum Entwickeln grafischer Oberflächen mit C++
RCS Lehrstuhl für Realzeit-Computersysteme
RPC Funktionsaufruf auf einem entfernten Rechner (Remote Procedure Call)
RT Echtzeit (Real-Time)
RTAI Real Time Application Interface
RTDM Real-Time Driver Model
RTHAL Real-Time Hardware Abstraction Layer
WCET Worst Case Execution Time
xZusammenfassung
Aktuelle Weiterentwicklungen am Linux-Kernel sollen den Einsatz von Linux auf Standard-
Hardware der x86-Architektur in Echtzeitumgebungen ermöglichen. Frei verfügbare Echtzei-
terweiterungen wie RTAI erheben den Anspruch für einen Betrieb unter harten Echtzeitbedin-
gungen ausgelegt zu sein. Die permanente Weiterentwicklung an RTAI erhöht die Stabilität,
die Zeitgenauigkeit, den Funktionsumfang und die Hardwareunterstützung. RTAI wird dadurch
konkurrenzfähiger gegenüber kommerziellen Lösungen.
Durch diese Entwicklung und die steigende Popularität von Echtzeitsystemen auf Linux-Basis
werden diese Systeme im Vergleich zu kostenintensiven kommerziellen Lösungen sowie stark an
einzelne Mitarbeiter gebundene Eigenentwicklungen auch in der industriellen Forschung immer
lukrativer.
Zur Beurteilung eines möglichen Einsatzes bei Forschungsarbeiten im Rahmen der Umfel-
derkennung im Automobilbereich werden zunächst die für einen Echtzeitbetrieb relevanten
Konzepte genauer betrachtet. Diese Betrachtungen umfassen vor allem den Scheduler und die
damit verbundene Auslegung der untersuchten Systeme.
Weiterhin wird das als Grundlage für RTAI dienende Konzept der Hardwarevirtualisierung durch
den Einsatz einer Interrupt Pipeline untersucht. Dieses Konzept ermöglicht den Betrieb von
RTAI parallel zum Linux-Kernel, die Priorisierung von RTAI in der Abarbeitungsreihenfolge
gegenüber dem Linux-Kernel ist die Basis für die Echtzeitfähigkeit von RTAI.
Die Erweiterung der Software des Realtime CAN for Linux/RTAI“ Projektes ermöglicht CAN-
”
Kommunikation unter RTAI auf x86-Hardware.
Durch Messungen auf dem CAN-Bus wird die Einsatzfähigkeit der vorgestellten Echtzeitsy-
steme objektiv untersucht. Dazu werden an eine spätere Applikation orientierte Testszenarien
definiert. Nach der Auswertung der Tests werden weitere Schritte für eine genauere Untersu-
chung der Einsatzfähigkeit geschildert.
xixii
1 Einleitung
Im Rahmen von Forschungsarbeiten zur Umfelderkennung im Automobilbereich wer-
den Testfahrzeuge zur Durchführung von Fahrversuchen aufgebaut. Diese Versuchsträger
verfügen über verschiedene Sensoren wie Laserscanner oder Radare, sowie über Aktoren
wie zum Beispiel reversible Gurtstraffer.
Zur Evaluierung von verschiedenen Algorithmen im Bereich der Objekterkennung und
-verfolgung wird eine ebenfalls im Fahrzeug eingebaute Datenverarbeitungsanlage ver-
wendet. Die Vernetzung der Komponenten wird über den im Automobilbereich üblichen
CAN-Bus bzw. über Ethernet realisiert.
Mehrere Gründe machen den Einsatz eines echtzeitfähigen Betriebssystems auf der zu
Versuchszwecken im Fahrzeug installierten Datenverarbeitungsanlage erforderlich:
Die Einleitung von Maßnahmen zur Erhöhung des Insassenschutzes muss unmittelbar bei
der Erkennung einer Gefahrensituation erfolgen.
Aus marktstrategischen Gründen sowie der Wirtschaftlichkeit beim Verkauf an mehre-
re Automobilhersteller werden die Sensoren von den Zulieferern häufig als komplette
Subsysteme verkauft, die bereits eine eigene Aufbereitung der Daten bis hin zu einer
vollständigen Objekterkennung beinhalten. Um Datenverluste bzw. fehlerhafte Messda-
ten zu vermeiden, müssen bei der Kommunikation mit diesen Subsystemen verschiedene
Echtzeitbedingungen eingehalten werden.
Beim späteren Einsatz einer Applikation auf einem Steuergerät im Fahrzeug müssen
durch Abhängigkeiten vom Gesamtsystem verschiedene Laufzeit- und Echtzeitbedingun-
gen eingehalten werden. Eine Entwicklung auf Echtzeitsystemen schon in der frühen
Entwicklungsphase erleichtert die spätere Portierung auf ein Steuergerät und stellt die
grundsätzliche Eignung der Applikation für den Einsatz auf einem Steuergerät sicher.
Neben den zeitkritischen Aufgaben wie z. B. der Steuerung der Sensoren und Aktoren,
gibt es nicht-zeitkritische Aufgaben wie die Visualisierung der Messdaten.
Der bisherige Ansatz sieht eine Auftrennung der zeitkritischen und nicht-zeitkritischen
Aufgaben über zwei unabhängige Rechnersysteme vor. Auf Seiten der zeitkritischen
Aufgaben wird das kommerzielle Echtzeitbetriebssystem LynxOS auf einer Motorola-
Architekur eingesetzt, für die nicht-zeitkritischen Aufgaben wird Linux auf Standard-
Hardware verwendet.
Diese Architektur bringt verschiedene Probleme mit sich:
11 Einleitung
• Die Anschaffung des Echtzeitrechners mit dem kommerziellen Betriebssystem ist
mit hohen Kosten verbunden.
• Sowohl innerhalb der Arbeitsgruppe als auch in der Öffentlichkeit ist ein wesentlich
geringeres Know-How zu LynxOS als zu Linux vorhanden.
• Die Standard C-Bibliothek von LynxOS hat im Vergleich zur Standard C-Bibliothek
von Linux einen geringeren Funktionsumfang.
• Die Verteilung der Software über zwei Systeme bringt einen erhöhten Entwicklungs-
und Wartungsaufwand mit sich.
Die Einschränkungen auf Seiten der Softwareentwicklung führen zu einem erhöhten Ein-
satz von Workarounds, und sind daher nicht optimal.
Aktuelle Weiterentwicklungen an Linux, sowie neue, frei verfügbare Echtzeiterweiterun-
gen, sollen einen Einsatz von Linux als Echtzeitbetriebssystem ermöglichen. Besonders
vielversprechend ist dabei die Echtzeiterweiterung RTAI. RTAI kann parallel mit Linux
auf Standard-Hardware betrieben werden und soll dabei für den Einsatz in einer Echt-
zeitumgebung geeignet sein.
Eine Einsatzfähigkeit eines Echtzeitsystems auf Linux-Basis würde den Austausch der
aktuellen Architektur durch eine neue auf Standard-Hardware basierende Architektur
ermöglichen. Gleichzeitig könnten die beschriebenen Probleme bei der Entwicklung von
RT Anwendungen auf der aktuellen Architektur dadurch vermindert werden.
Das Ziel der hier vorliegenden Arbeit besteht deshalb aus der Überprüfung der Ein-
satzfähigkeit von Linux und RTAI im beschriebenen Applikationsumfeld.
Kapitel 1 gibt die Motivation wieder und führt auf die Problematik hin.
In Kapitel 2 werden Begriffe eingeführt und die theoretischen Grundlagen geschaffen, die
zum Verständnis dieser Arbeit benötigt werden.
Die im Rahmen dieser Arbeit zu testenden Ansätze für Echtzeitbetriebssysteme werden
in Kapitel 3 technisch erläutert.
Kapitel 4 beschreibt die Entwicklung eines CAN-Treibers für die Echtzeiterweiterung
RTAI.
Das Ergebnis der durchgeführten Messungen sowie das dazu verwendete Testverfahren
werden im fünften Kapitel dieser Arbeit genauer beschrieben.
22 Grundlagen
Dieses Kapitel dient zur Einführung in das Umfeld der Thematik der vorliegenden Arbeit.
Zu den drei Begriffen CAN-Kommunikation“, Echtzeit“ und Linux“ aus dem Titel der
” ” ”
Arbeit wird jeweils ein grober Überblick gegeben. Die für die Arbeit relevanten Aspekte
der einzelnen Themen werden präziser dargestellt.
2.1 CAN-Bus
2.1.1 Einführung
Beim CAN-Bus (controller area network) handelt es sich um ein asynchrones, serielles
Feldbussystem zur digitalen Signalübertragung.
Der CAN-Bus wurde 1983 von Bosch zur Vernetzung von Steuergeräten im Automobil
entwickelt. Durch die serielle Verkabelung konnte im Vergleich zur vorher üblichen par-
allelen Verkabelung die Länge der verlegten Kabelbäume, und damit das Gewicht der
Fahrzeuge, verringert werden. Außerdem ist die verwendete digitale Übertragungstechnik
im Vergleich zur analogen Signalübertragung weniger anfällig für Störungen.
1991 wurde von Bosch die bis heute aktuelle CAN Spezifikation 2.0 [Bos91] veröffentlicht.
Im Jahr 1993 wurde das CAN Protokoll unter Verwendung des ISO-Schichtenmodells zum
internationalen Standard ISO 11898.
Der CAN-Bus wird sowohl zur Vernetzung von Steuergeräten im Automobilbereich, als
auch in vielen Industrie- und Automatisierungsanwendungen zum Messen und Steuern
verwendet.
2.1.2 Medium
Der CAN-Bus kann über Kupferleitungen oder Glasfaser geführt werden. Im Falle von
Kupferleitungen arbeitet der CAN-Bus mit Differenzsignalen. Es werden die zwei Leitun-
gen CAN HIGH und CAN LOW benötigt.
Ein Bit kann bei seiner Übertragung entweder dominant oder rezessiv auf die Busleitungen
wirken. Ein rezessives Bit wird von einem dominanten Bit überschrieben.
Die CAN Spezifikation 2.0 [Bos91] trifft dabei folgende Festlegung:
32 Grundlagen
dominant 0
rezessiv 1
Tabelle 2.1: Werte auf dem CAN-Bus
Die Entscheidung welches Bit überschrieben wird, kann somit als logisches UND-Gatter
interpretiert werden.
2.1.3 Übertragungsrate und Leitungslänge
Die maximale Datenübertragungsrate beträgt 1 MBit s−1 auf einem Highspeed Bus. Die
maximale Leitungslänge bei einer vorgegebenen Übertragungsrate wird von den physika-
lischen Eigenschaften des Trägers bestimmt.
Durch die Ausbreitungsgeschwindigkeit v in Kupfer ergeben sich folgende theoretisch ma-
ximal mögliche Leitungslängen:
1 MBit s−1 40 m Highspeed-Bus
500 KBit s−1 100 m
125 KBit s−1 500 m Lowspeed-Bus
Tabelle 2.2: Maximale Leitungslänge bei vorgegebener Übertragungsrate
Die Abhängigkeit von der Ausbreitungsgeschwindigkeit beruht darauf, dass das Signal das
Ende des Busses erreicht haben muss, bevor das Signal des folgenden Bits angelegt wird.
Im Automobilbereich wird in der Regel eine Datenübertragungsrate von 500 KBit s−1 auf
Highspeed-Bussen verwendet. Meistens werden noch zusätzliche Busse mit einer geringe-
ren Datenübertragungsrate eingesetzt.
2.1.4 Objektidentifier und Buszugriff
Der Objektidentifier, kurz Identifier, kennzeichnet den Inhalt einer Nachricht. Es wird
zwischen 11 Bit langen Identifiern im Base frame format“, sowie 29 Bit langen Identifiern
”
im Extended frame format“ unterschieden.
”
Der CAN-Bus arbeitet nach dem CSMA/CA-Verfahren, Kollisionen beim Buszugriff wer-
den durch die Arbitrierung vermieden.
Bei der Arbitrierung beginnt jeder Sender mit dem Versand des Identifiers seiner zu ver-
sendenden Nachricht. Sobald ein Sender am Bus ein dominantes Signal misst, obwohl er
ein rezessives Signal angelegt hat, beendet er seine Übertragung. Am Ende gewinnt der
Sender mit der Nachricht mit dem kleinsten Objektidentifier.
Somit lassen sich die Nachrichten über ihren Objektidentifier priorisieren. Die Nachricht
mit dem kleinsten Identifier hat die höchste Priorität.
42.2 Echtzeit
Ein Gerät kann als Sender mehrerer Identifier fungieren, wegen der Arbitrierung darf es
allerdings für jeden Identifier nur einen einzigen Sender am Bus geben.
2.1.5 Frame-Formate
Die CAN Spezifikation beschreibt vier Arten von Frames:
• Daten-Frame zum Transport von bis zu 8 Byte Daten
• Error-Frame zur Signalisierung eines erkannten Übertragungsfehlers an alle Teilneh-
mer
• Remote-Frame zur Anforderung eines Daten-Frames von einem anderen Teilnehmer
• Overload-Frame als Verzögerung zwischen Daten- und Remote-Frames
In einem Daten-Frame sind neben dem Objektidentifier und den Daten weitere Informa-
tionen wie z. B. eine CRC-Prüfsumme zur Sicherung der Daten enthalten.
2.1.6 Einschränkungen
Trotz der Hierarchie der Nachrichten ist auch bei hochprioren Nachrichten der Sendezeit-
punkt nicht exakt bestimmbar. Dieses nicht-deterministische Verhalten macht Schwierig-
keiten in hoch zeitkritischen Anwendungen. Eine Abhilfe ist die Verwendung eines für
eine Applikation exklusiven Busses. Für zukünftige Anwendungen wie zum Beispiel die
Elektrische Bremse“ (brake by wire) werden neue Standards benötigt.
”
Eine weitere Einschränkung stellt die für Multimedia-Anwendungen zu geringe maximale
Datenübertragungsrate von 1 MBit s−1 dar.
Als Bussystem der Zukunft wird dabei z. B. FlexRay [Fle] mit einer Datenübertragungsrate
von bis zu 10 MBit s−1 sowie garantierten Latenzzeiten gehandelt.
Für heutige Multimedia-Anwendungen wird bereits der MOST-Bus mit speziellen Kanälen
zur Audio- und Videoübertragung im Fahrzeug eingesetzt.
2.2 Echtzeit
2.2.1 Grundlagen
Der Begriff Echtzeit beschreibt eine Zeitanforderung an das Antwortverhalten einer An-
wendung bei der Bearbeitung von Rechenprozessen.
52 Grundlagen
Je nach Anwendung ist diese Zeitanforderung unterschiedlich. Sehr hohe Anforderungen
sind zum Beispiel im Automobilbereich vorhanden. Diese liegen hier teilweise im Mikro-
sekundenbereich (z. B. Motorsteuerung), für Regelungen meist in einem Bereich von 10
ms.
2.2.2 Latenzzeit
Bei der Latenzzeit handelt sich um eine Verzögerung. In Kommunikationsnetzwerken ent-
spricht die Latenzzeit der durch den Übertragungsweg bedingten Verzögerung. Leitungs-
wege und Gatterlaufzeiten führen zu Latenzen in elektrischen Schaltungen.
Beim Vergleich von Betriebssystemen wird oft die Interrupt-Latenzzeit betrachtet. Sie
gibt die Verzögerung zwischen dem Eintreffen einer Unterbrechung bis zum Start ihrer
Bearbeitungsroutine an.
Verschiedene Faktoren in einem Betriebssystem können die Interrupt-Latenzzeit ver-
schlechtern. Folgende Latenz-Killer“ sind zu vermeiden:
”
• hohe DMA Aktivitäten durch Festplatten oder andere PCI-Geräte
• Energiesparfunktionen (APM und ACPI)
• dynamischer Wechsel der Taktfrequenz des Prozessors
• Verwendung einer Hardware-beschleunigten grafischen Oberfläche
• System Maintenance Interrupt (SMI) auf neueren Mainboard-Chipsätzen
2.2.3 Jitter
Der Jitter ist laut [Kop97] die Differenz zwischen dem minimalen und dem maximalen
Wert der Verzögerung.
Der maximal zulässige Jitter ist ein wichtiges Designkriterium für Echtzeitanwendungen.
Unter einem hohen Jitter leidet die Worst-Case Abschätzung der Anwendung.
2.2.4 Deadline
Die Deadline gibt die maximal zulässige Antwortzeit eines Rechenprozesses an. In dieser
Antwortzeit sind die Latenzzeit, die Rechenzeit und weitere Wartezeiten während der
Abarbeitung enthalten.
Wartenzeiten können durch die Blockierung von benötigten Betriebsmitteln, durch Unter-
brechungen von höherprioreren Tasks, Unterbrechungen durch externe Ereignisse, sowie
bei der Kommunikation mit anderen Prozessen zu Stande kommen.
62.2 Echtzeit
2.2.5 Weiche und harte Echtzeit
Anhand des Schadens bei der Überschreitung einer Deadline kann zwischer weicher und
harter Echtzeit unterschieden werden [Sch02].
Bild 2.1: Abrupter Schaden bei der Überschreitung der Deadline bei einer harten Echt-
zeitanforderung. [Sch02]
Während die Verletzung einer harten Echtzeitbedingung zu einem schwerwiegenden Scha-
den wie dem physikalischen Defekt des gesteuerten Systems führen kann, wird bei der
Verletzung einer weichen Echtzeitbedingung nur die Güte des Ergebnisses beeinflusst.
Beispiele für Systeme mit weichen Echtzeitbedingungen sind die Übertragung von Vide-
odaten oder das Digitalisieren von analogen Audiodaten.
2.2.6 Programmierung von Echtzeitsystemen
Nach [Fär04] sollten bei der Programmierung von Echtzeitsystemen all diejenigen Kon-
strukte vermieden werden, die eine Bestimmung der WCET erschweren. Folgende Punkte
müssen dabei beachtet werden:
• Keine rekursiven Programme/Prozeduren verwenden, Umformen in Programm-
schleifen.
• Schleifen sollten immer durch eine maximale Schleifendurchlaufzahl begrenzt sein
(feste Obergrenze).
• Bei Verzweigung- und Schleifenbedingungen muss die Endbedingung sicher erreicht
werden. Eventuell Begrenzung durch übergeordnete Schleife mit fester Obergrenze.
• Datenstrukturen solltest möglichst statisch definiert werden, nicht erst zur Laufzeit
dynamisch entstehen (Zeitbedarf, Risiko des nicht mehr vorhandenen Speichers, der
dann zu einer aufwendigen Speicherreinigung führt).
72 Grundlagen
2.3 Wichtige Konzepte eines Betriebssystems am
Beispiel Linux
In diesem Abschnitt sollen die für diese Arbeit relevanten grundlegenden Konzepte ei-
nes modernen Betriebssystems wiederholt werden. Innerhalb der Theorie wird auf die
Umsetzung der vorgestelltungen Konzepte unter Linux eingegangen.
2.3.1 Rechenprozess
Ein Prozess bzw. Rechenprozess wird von [UB01] als Ablauf in einem Betriebssystem
definiert. Ein Prozess ist gleichzeitig eine Verwaltungseinheit des Betriebssystems.
Es wird zwischen Prozessen für Benutzeraufträge, den Benutzerprozessen, sowie Prozessen
des Betriebssystems, den Systemprozessen unterschieden.
Jeder Rechenprozess erhält einen eigenen, exklusiven Adressraum. Eine Ausnahme sind
die sog. leichtgewichtigen“ Prozesse (Threads), die über einen gemeinsamen Speicherbe-
”
reich verfügen.
Aus Sicht des Betriebssystems belegt jeder Rechenprozess ein oder mehrere Threads. Der
Begriff Task“ wird als Synonym für einen solchen Thread verwendet. Eine Verwendung
”
als Synonym für Prozess“ ist ebenso gebräuchlich.
”
Der Prozesskontext enthält alle Informationen, die das Betriebssystem über einen Rechen-
prozess besitzt. Neben dem Adressraum gehören dazu Informationen wie der Name des
Prozesses, die Stellung in der Prozesshierarchie oder der ausführende Systembenutzer.
Linux verwaltet alle Prozesse in einer Prozesstabelle, jeder Prozess wir dabei durch eine
Struktur vom Typ task struct (/usr/src/include/sched.h) beschrieben.
2.3.2 Kernel-Modus und Benutzer-Modus
Die Berechtigungsstufe eines Prozesses wird als Ring bezeichnet. Diese schränkt den Pro-
zess in dem auf dem Prozessor nutzbaren Befehlssatz und Speicherbereich ein.
Die x86-Architektur sieht die Ringe 0 bis 3 vor. Prozesse im Ring 0 befinden sich im
Kernel-Modus, alle anderen Prozesse sind im Benutzer-Modus. Ring 0 stellt die höchste
Berechtigungsstufe dar, die bis zur Stufe 3 immer weiter eingeschränkt wird.
2.3.3 Speicherverwaltung
Der Begriff Speicher“ wird im aktuellen Kontext als Synonym für Arbeitsspeicher“
” ”
verwendet.
82.3 Wichtige Konzepte eines Betriebssystems am Beispiel Linux
Folgende zwei Aspekte der virtuellen Speicherverwaltung eines modernen Betriebssystems
sollen hier betrachtet werden:
Über den virtuellen Adressraum kann mehr Speicher adressiert werden, als physikalisch
vorhanden ist. Dies wird durch eine Verdrängung von Speicherabschnitten auf die Festplat-
te erreicht. Das Verdrängen von Daten aus dem physikalischen Speicher auf die Festplatte
wird als Paging“ bezeichnet. Das Verdrängen sowie das Zurückladen sind sehr aufwendig,
”
Paging sollte in zeitkritischen Anwendungen daher vermieden werden.
Der Speicherschutz schützt den Speicherbereich eines Prozesses vor unberechtigten Zu-
griffen von anderen Prozessen. Dadurch kann die Beeinträchtigung der Stabilität anderer
Prozesse bzw. des Betriebssystems durch ein fehlerhaftes Programm vermieden werden.
Unter Linux wird der virtuelle Speicher über dreistufige Seitentabellen realisiert, als Er-
setzungsstrategie wird der Buddy-Algorithmus [Tan03] verwendet.
Bei einem Speicherzugriffsfehler wird der auslösende Prozess vom Betriebssystem beendet
(segmentation fault).
2.3.4 Kernelspace und Userspace
Der Speicherbereich des Kernels wird als Kernelspace“ bezeichnet. Er befindet sich immer
”
im physikalischen Speicher und wird nicht ausgelagert. Da der Linux-Kernel als ein Prozess
anzusehen ist, gibt es im Kernelspace keinen Speicherschutz.
Im Userspace“ befinden sich die Speicherbereiche der übrigen Prozesse. Diese Speicher-
”
bereiche können aus dem physikalischen Speicher verdrängt werden, der Speicherschutz
beschränkt die Prozesse auf ihren eigenen Speicherbereich.
2.3.5 Ein-/Ausgabegeräte
Ein-/Ausgabegeräte können in die zwei Klassen blockorientierte Geräte“ und zeichen-
” ”
orientierte Geräte“ unterteilt werden.
Bei blockorientierten Geräten wie Festplatten kann parallel auf verschiedenen Blöcken
lesen und geschrieben werden. Zu den zeichenorientierten Geräten zählen zum Beispiel
die Maus und die Tastatur.
Linux stellt Ein-/Ausgabegeräte in Form von Gerätedateien für den Benutzer zum Zugriff
bereit. Diese können dann über die grundlegenden Dateioperationen geöffnet, gelesen,
geschrieben und geschlossen werden.
92 Grundlagen
2.3.6 Multitasking
Linux unterstützt preemptives Multitasking, womit mehrere Rechenprozesse quasiparallel
ablaufen können.
Auf einem System von n Prozessoren können maximal n Rechenprozesse gleichzeitig ab-
laufen. Durch Multitasking wird die gleichzeitige Ausführung von m Rechenprozessen mit
m größer n simuliert. Da der Zeitpunkt eines Prozesswechsel nicht vorhergesagt werden
kann, geht jeder Prozess von echt parallelen Abläufen aus.
Folgende drei Komponenten werden für Multitasking benötigt:
• Unterbrechungssystem (Interruptsystem) zur Unterbrechung des aktiven Rechen-
prozesses
• Scheduler mit Prozessumschalter zur Verteilung der Ressourcen auf die Rechenpro-
zesse
• Speicherverwaltung mit exklusivem Adressraum für jeden Rechenprozess
2.3.7 Interruptsystem
Unter einem Interrupt versteht man die kurzfristige Unterbrechung eines Prozesses durch
eine vom Prozessor abzuarbeitende Befehlssequenz.
Interrupts können durch unterschiedliche Ereignisse ausgelöst werden. Einige Beispiele
sind das Ablaufen eines Timers, das Eintreffen eines Netzwerkpaketes am Ethernetcon-
troller und die Bewegung der Maus.
Ein Interrupt wird durch eine Signalisierung an den Prozessor angezeigt. Nachdem der
aktuell rechnende Prozess angehalten und sein Prozesskontext gesichert wurde, wird vom
Prozessor die Unterbrechungsroutine (Interrupt Service Routine) abgearbeitet. Nach der
Beendigung der Unterbrechungsroutine wird der vorherige Prozesskontext wiederherge-
stellt und der Prozess in den aktiven Zustand zurückgesetzt.
Innerhalb der Interrupts werden Prioritäten vergeben. Durch Maskierung kann ein Inter-
rupt unterbunden werden.
Neben den bisher beschriebenen Hardwareinterrupts, gibt es sog. Softwareinterrupts. Dies
sind Systemaufrufe, die ebenso zu einer Unterbrechung führen. Systemaufrufe ermöglichen
Prozessen aus dem Benutzer-Modus die Ausführung von Routinen im Kernel-Modus.
Interrupts sind die Grundbedingung für preemptives Multitasking. Ohne Interrupts wäre
es nicht möglich einem rechnenden Prozess von außen ein Betriebsmittel zu entziehen.
102.3 Wichtige Konzepte eines Betriebssystems am Beispiel Linux
2.3.8 Scheduling
Scheduling beschäftigt sich mit der Verteilung der Rechenzeit auf die Rechenprozesse. Ne-
ben der Verteilung der Rechenzeit gibt es auch Verfahren zur Verteilung anderer Ressour-
cen wie dem Massenspeicher. An dieser Stelle wird nur auf die Verteilung von Rechenzeit
eingegangen.
Zunächst werden die fünf Prozesszustände lauffähig, ruhend, aktiv, wartend und nicht exi-
stent eingeführt. Mit der Beachtung der Randbedingungen wie der Priorität des Prozesses
oder dem Belegungszustand der Betriebsmittel, entscheidet der Scheduling-Algorithmus
für jeden Prozess über die Übergänge in die verschiedenen Zustände. Jeder Übergang ist
mit einem Aufwand für das Sichern und Laden des Prozesskontextes verbunden.
[Tan03] definiert folgende Ziele für einen Scheduling-Algorithmus in verschiedenen Umge-
bungen:
Alle Systeme
Fairness – jeder Prozess bekommt Rechenzeit der CPU
Policy Enforcement – Politiken werden sichtbar durchgeführt
Balance – alle Teile des Systems sind ausgelastet
Stapelverarbeitungssysteme
Durchsatz – maximiere nach Jobs pro Stunde
Turnaround-Zeit – minimiere die Zeit vom Start bis zur Beendigung
CPU-Belegung – belege die CPU konstant mit Jobs
Interaktive Systeme
Antwortzeit – antworte schnellstmöglich auf Anfragen
Proportionalität – auf die Bedürfnisse des Nutzers eingehen
Echtzeitsysteme
Meeting Deadlines – keine Daten verlieren
Predictability – Qualitätsverlust bei Multimedia vermeiden
Tabelle 2.3: Einige Ziele des Scheduling-Algorithmus bei verschiedenen Umgebungen
Das Scheduling-Verfahren von Linux wird im folgenden beschrieben und auf die Einhal-
tung dieser Ziele untersucht.
Der Scheduler von Linux arbeitet nach einem Zeitverteilungsverfahren. Er wird dazu von
einer Uhr getaktet, die in den aktuellen Kernel-Versionen mit einer Frequenz von 100 Hz,
250 Hz oder 1000 Hz betrieben werden kann. Die Zeit zwischen zwei Ticks, im Falle von
1000 Hz entspricht dies 1 ms, wird als Jiffie bezeichnet.
Der Scheduler vergibt, ähnlich zu den bereits genannten allgemeinen Zuständen, folgende
Prozesszustände:
Alle Prozesse mit dem Status TASK RUNNING befinden sich in einer Warteschlange.
Jeder Prozess hat eine Priorität, diese kann entweder statisch oder dynamisch sein. Pro-
zesse mit einer dynamischen Priorität werden erst dann ausgeführt, wenn kein Prozess
112 Grundlagen
TASK RUNNING Task rechnet oder ist rechenbereit
TASK INTERRUPTIBLE Task wartet auf ein externes Ereignis, kann durch
einen Interrupt aufgeweckt werden
TASK UNINTERRUPTIBLE Task wartet auf ein externes Ereignis, kann nicht
durch einen Interrupt aufgeweckt werden
TASK ZOMBIE beendeter Task, dessen Prozessstruktur sich noch in der
Prozesstabelle befindet
TASK STOPPED Task, dessen Ausführung angehalten wurde
Tabelle 2.4: Prozesszustände unter Linux
mit einer statischen Priorität mehr im rechenbereiten Zustand ist.
Im folgenden soll der Standard-Scheduler-Algorithmus SCHED OTHER genauer beschrie-
ben werden. Prozesse mit statischer Priorität gehören zu den Echtzeit-Ansätzen von Li-
nux, und werden daher erst im nächsten Kapitel näher erläutert.
Zur Berechnung der dynamischen Prioritäten wird zunächst der Begriff der Epoche“
”
eingeführt. Eine Epoche entspricht einer bestimmten Rechenzeit.
Beim Beginn einer Epoche bekommt jeder rechenbereite Prozesse einen Anteil der Re-
chenzeit zugeteilt. Dieser Anteil in Jiffies ist seine Standardpriorität bzw. der Startwert
seines Quantums“. Das Quantum am Beginn einer Epoche setzt sich aus einem vordefi-
”
nierten Standardwert und einem vom ausführenden Benutzer bestimmbaren Wert (nice)
zusammen.
Falls ein Prozess in der aktuellen Periode auf dem Prozessor gerechnet hat, wird sein
Quantum nach dem Ablauf dieser Periode um eins erniedrigt. Bei Eingabe/Ausgabe-
Operationen verändert sich das Quantum nicht. Falls der Prozess in der vorhergehenden
Epoche nicht sein komplettes Quantum verwendet hat, erhält er einen Bonuspunkt. Eine
Epoche geht dann zu Ende, wenn alle rechenbereiten Prozesse ihr Quantum verbraucht
haben.
Die dynamische Priorität jedes Prozesses ergibt sich aus seiner Standardpriorität und der
aktuellen Höhe seines Quantums. Sie wird nach jedem Tick der Uhr neu berechnet.
Ein rechnender Prozess kann durch folgende Ereignisse verdrängt werden:
• Sein Quantum ist 0.
• Er blockiert wegen Eingabe/Ausgabe oder aus anderen Gründen.
• Ein anderer Prozess mit einer höheren Priorität wird rechenbereit.
• Er wird durch den Interrupt eines interaktiven Prozesses unterbrochen.
Der Scheduler-Algorithmus SCHED OTHER erfüllt somit folgende Anforderungen:
• Jeder Prozess bekommt nach einem fairen und durchsichtigen System Rechenzeit
der CPU zugeteilt.
122.3 Wichtige Konzepte eines Betriebssystems am Beispiel Linux
• Stapelverarbeitungs-Prozesse mit einem hohen Bedarf an Eingabe/Ausgabe-Operationen
werden gegenüber rechenlastigen Prozessen bevorzugt und erreichen damit einen
hohen Durchsatz bzw. eine kurze Turnaround-Zeit.
• Interaktive Prozesse erlangen durch Interrupts eine sehr hohe dynamische Priorität
und erzielen dadurch eine gute Antwortzeit.
Die Anforderungen von Realzeitsystemen können nicht eingehalten werden, das Schedu-
ling ist nicht vorhersagbar, garantierte Ausführungszeiten sind nicht möglich.
2.3.9 Semaphoren
Ein Semaphor ist eine Datenstruktur zur Prozesssynchronisation. Mit Hilfe von Sema-
phoren kann der gleichzeitige Zugriff mehrerer Prozesse auf ein begrenztes Betriebsmittel
verwaltet werden.
Eine zählende Semaphor wird mit der maximal möglichen Anzahl gleichzeitiger Zugriffe
initialisiert. Bei jeder Anforderung wird ihr Wert um eins dekrementiert, bei einer Freigabe
um eins erhöht.
Ein Wert von Null zeigt an, dass momentan keine weitere Zuteilung mehr stattfinden kann.
In diesem Fall wird der anfordernde Prozess blockiert. Die Blockierung wird aufgelöst,
sobald wieder eine Zuteilung des Betriebsmittels möglich ist.
2.3.10 Gemeinsam genutzte Speicherbereiche
Shared Memory“ ist eine Möglichkeit zum Datenaustausch zwischen Prozessen. Dies kann
”
auch zwischen Prozessen im Userspace und Prozessen im Kernelspace stattfinden. Dazu
wird ein Speicherbereich definiert, auf dem die Teilnehmer lesen und schreiben können.
Diese Form des Datenaustauschs ist sehr performant, allerdings müssen vom Anwen-
dungsentwickler Mechanismen zur Kontrolle des konkurrierenden Zugriffs sowie zur
Gültigkeitskontrolle der Inhalte implementiert werden.
2.3.11 FIFO Puffer
Bei einem Puffer nach dem First In - First Out Prinzip werden die Elemente in der gleichen
Reihenfolge abgerufen, in der sie zuvor abgelegt wurden.
Unter Linux entspricht eine named pipe“ einem FIFO Puffer.
”
132 Grundlagen 2.3.12 Ringpuffer Ein Ringpuffer ist eine spezielle Variante eines FIFO Puffers. Im Vergleich zu einer War- teschlange ist der Platz in einem Ringpuffer auf eine bestimmte Anzahl von Elementen begrenzt. Ein Ringpuffer kann über zwei Zeiger implementiert werden, die auf die aktuelle Schreib- bzw. Leseposition zeigen. Bei einer zu hohen Asynchronität zwischen dem Erzeuger und dem Verbraucher kann es zu einem Überlauf kommen. In diesem Fall werden nacheinander die ältesten Elemente durch neue Daten überschrieben, womit es zu einem Datenverlust kommt. 14
3 Echtzeitsysteme auf Linux-Basis
Im ersten Teil dieses Kapitels werden die Einsatzmöglichkeiten von Linux als Echtzeitbe-
triebssystem analysiert [3.1].
Als zweites Echtzeitsystem wird aufgrund der freien Verfügbarkeit sowie der erhöhten
Ausgereiftheit gegenüber anderen Ansätzen die Echtzeiterweiterung RTAI verwendet. Ein
Beschreibung von RTAI sowie ein Überblick über den mitgelieferten Funktionsumfang be-
findet sich im zweiten Teil dieses Kapitels [3.2]. Kurze Beispiele sollen dem Programmierer
einen groben Einblick über die Entwicklung von Anwendungen unter RTAI geben.
Die beschriebenen Funktionen und Konzepte sind ein Teil der heutigen Möglichkeiten,
durch die tägliche Weiterentwicklung an den Systemen ist eine alles umfassende Zusam-
menfassung nicht möglich.
3.1 Linux
Nachdem die grundlegenden Konzepte von Linux bereits erläutert wurden, sollen nun die
Aspekte für eine Verwendung als Echtzeitbetriebssystem erarbeitet werden.
Zuerst werden einige Punkte gegen einen Einsatz von Linux als Echtzeitbetriebssystem
genannt, danach werden mögliche Ansätze und Verbesserungen für einen solchen Einsatz
gezeigt.
3.1.1 Einschränkungen
Linux ist ein traditionelles Multitasking-Betriebssystem
Linux ist ein general purpose“ Betriebssystem und damit auf den durchschnittlich auf-
”
tretenden Fall optimiert. Im Multitasking-Betrieb wird eine große Anzahl von Diensten
parallel ausgeführt, das Scheduling ist auf eine Optimierung des Datendurchsatzes ausge-
legt.
Dies widerspricht dem Konzept eines auf den Worst-Case ausgelegten Echtzeitbetriebs-
systems, das die Minimierung von Latenzzeiten sowie garantierte Ausführungszeiten als
Ziel hat.
153 Echtzeitsysteme auf Linux-Basis Paging Das Auslagern von Speicherbereichen auf die langsame Festplatte ist sehr zeitaufwendig und kann daher zu einer Verletzung von Echtzeitbedingungen führen. Dynamische Speicherverwaltung Die Standard C-Bibliothek bietet mit den Funktionen malloc() und free() eine dynamische Speicherverwaltung an. Beim Aufruf von malloc() wird der Speicher zur Laufzeit über den Systemaufruf mmap() reserviert. Neben dem Effekt, dass dieser Systemaufruf aufwendig ist, kann er bei zu wenig frei verfügbarem physikalischen Speicher ein Auslöser für Paging sein. Zeitgranularität Bei einem Schedulertakt von 1000 Hz wird in jeder Millisekunde ein Interrupt ausgelöst. Die aufgerufene Routine entscheidet welcher Prozess als nächstes abzuarbeiten ist. Bei einer Verfeinerung der Granularität würde sich durch viele Scheduleraufrufe und die damit verbundenen Kontextwechsel der Overhead erhöhen. Das System kann dadurch sogar schlechter reagieren als zuvor. Dieses Problem wächst mit der Anzahl der im System gleichzeitig ablaufenden Prozesse. Allerdings sind selbst bei einem perfekten Scheduling ohne Wartezeiten durch andere Ereignisse keine Reaktionszeiten unter einer Millisekunde realisierbar. Echtzeitaufgaben im Mikrosekundenbereich sind daher mit Linux nicht lösbar. Nicht-preemptiver Kernel Sehr viele Codeabschnitte des Linux-Kernels sind nicht darauf ausgelegt während ihrer Abarbeitung unterbrochen zu werden. Kritische Abschnitte sind nicht klar herausgearbei- tet, weshalb der Linux-Kernel aus Sicherheitsgründen nicht-preemptiv ist. Dies hat zur Folge, dass ein niederpriorer Prozess, der über einen Systemaufruf Routinen im Kernel-Modus ausführt, einen höherprioreren Prozess blockieren kann. 3.1.2 Lösungsansätze Echtzeitfähige Scheduler-Strategien Neben der bereits beschriebenen Scheduler-Strategie SCHED OTHER sind die zwei wei- teren Strategien SCHED FIFO sowie SCHED RR vorhanden. 16
3.1 Linux
Beide Strategien arbeiten mit statischen Prioritäten, die immer über den dynamischen
Prioritäten der von SCHED OTHER verwalteten Prozesse liegen. Prozesse mit dynami-
schen Prioritäten werden daher erst abgearbeitet, wenn kein Prozess mit einer statischen
Priorität mehr rechenbereit ist.
Bei der SCHED FIFO Strategie werden die Prozesse innerhalb der selben Priorität in der
Reihenfolge ihrer Ankunft bearbeitet (First In - First Out). Bei der SCHED RR Strategie
wird zusätzlich ein Zeitscheibenverfahren nach dem Round Robin-Prinzip verwendet.
Der Name Echtzeit“ kommt vor allem daher, dass diese Scheduler-Strategien nach dem
”
POSIX.1b-1993 Standard für Echtzeitprozesse implementiert sind. Dies reicht nicht aus
um harte Echtzeitbedingungen zu erfüllen, vor allem da die bereits beschriebenen Ein-
schränkungen nicht aufgehoben werden.
Aus den Anforderungen an einen Scheduler-Algorithmus (2.3) zielen diese beiden Stra-
tegien auf die Punkte kurze Antwortzeit, Einhalten von Deadlines und Vorhersagbarkeit
des Schedulings ab. Diese Ziele können allerdings nicht immer vollständig erfüllt werden.
Preemption Patches
Preemption Patches versuchen die nicht-preemptiven Bereiche im Linux-Kernel auf ein
Minimum zu reduzieren. Die beschriebene Prioritätsinversion soll dadurch vermieden wer-
den.
Ein solcher Patch ist inzwischen in die offiziellen Quellen des Linux-Kernel 2.6 eingeflossen
und kann bei der Konfiguration aktiviert werden.
Low-Latency Patches
Mit diesen Patches soll die Latenzzeit verkürzt werden, indem nicht-deterministische Pfa-
de (zum Beispiel Schleifen mit einer nach oben unbegrenzten Anzahl von Iterationen) in
den Kernel-Quellen durch deterministische Routinen ersetzt werden.
Aufgrund der hohen Komplexität der Kernel-Quellen ist es allerdings nicht möglich alle
Pfade zu analysieren. Dieses Verfahren wird dadurch sehr ungenau und soll daher nicht
weiter behandelt werden.
Deaktivierung des Pagings
Mit der Funktion mlockall() aus der Standard C-Bibliothek kann das Paging für den
aktuellen Prozess gesperrt werden. Damit wird garantiert, dass alle eingebundenen Spei-
cherseiten im physikalischen Speicher bleiben.
173 Echtzeitsysteme auf Linux-Basis
3.1.3 Zusammenfassung
Einige dieser Ansätze klingen sehr vielversprechend und machen Linux zumindest als
Echtzeitbetriebssystem für weiche Echtzeitbedingungen interessant. Inwieweit sich diese
Ansätze mit richtigen Echtzeitbetriebssystemen messen können, wird im fünften Kapitel
dieser Arbeit ermittelt.
3.2 RTAI
3.2.1 Einführung
RTAI (Real Time Application Interface) ist eine Erweiterung von Linux zu einem Echt-
zeitbetriebssystem. Unter der Leitung von Prof. Paolo Mantegazza vom Dipartimento di
Ingegneria Aerospaziale (DIAPM) der Universität Mailand wurde RTAI zunächst für am
Institut anfallende Echtzeit-Aufgaben aus dem Bereich der Luftfahrttechnik verwendet.
Dabei sind viele Teile aus der bereits bestehenden Echtzeiterweiterung RTLinux eingeflos-
sen. Seit 1998 steht RTAI unter der GNU Public Licence als freie Software zur Verfügung.
Die Hauptidee von RTLinux und RTAI ist, dass der Linux-Kernel als normaler Benut-
zerprozess angesehen wird. Der Kernel bekommt nur Rechenzeit zugeteilt, wenn keine
Echtzeitaufgaben anstehen. Dazu wird bei RTAI auf der unterster Softwareebene der
Real-Time Hardware Abstraction Layer (RTHAL) eingefügt. Der RTHAL entzieht dem
Linux-Kernel die Kontrolle über die Interrupts und setzt ihn an eine untergeordnete Po-
sition.
RTAI wurde 1998 unter der Less GNU Public Licence (LGPL) veröffentlicht und steht
damit als freie Software zur Verfügung. Im Jahr 1999 entbrannte eine Patentdiskussion
im Bezug auf das im Besitz von FSMLabs, dem kommerziellen Betreiber von RTLinux,
befindlichen US-Patents Adding real-time support to general purpose operating systems“
”
(US 5,995,745). Als Ausweg wurde der patentgefährdete RTHAL im Dezember 2003 durch
den unter der GPL stehenden Adeos Nanokernel ersetzt.
Auf den für den Linux-Kernel 2.4 ausgelegten Zweig 24.x folgte der um die Unterstützung
für den Linux-Kernel 2.6 erweiterte Zweig 3.x von RTAI. Die aktuelle stabile Version von
RTAI hat die Version 3.3.
Zunächst werden nun die grundsätzlichen Konzepte hinter RTAI erläutert. Danach werden
die Funktionen beschrieben und Hinweise zur Entwicklung von Applikationen unter RTAI
gegeben. Zusätzlich befinden sich einige Quellcode-Beispiel im Anhang dieser Arbeit.
Zur Installation von RTAI auf einem vorhandenen Linux System wird ebenfalls im Anhang
dieser Arbeit eingegangen [A].
183.2 RTAI
3.2.2 Adeos Nanokernel mit Interrupt Pipeline
Nachdem der Real-Time Hardware Abstraction Layer wie bereits erwähnt durch den Ade-
os Nanokernel ersetzt wurde, soll an dieser Stelle ausschließlich der Adeos Nanokernel be-
trachtet werden. Beide Ansätze verfolgen das Ziel die Kontrolle über Teile der Hardware
zu übernehmen und Linux nur noch als einen Leerlauf-Prozess anzusehen. Die Umset-
zung ist dabei unterschiedlich, der Adeos Nanokernel beschreibt einen breiter gefächerten
Ansatz, während der RTHAL eine spezifische Lösung für RTAI ist.
Adeos steht für Adaptive Domain Environment for Operating Systems“ [Yag] und be-
”
schreibt zunächst ein allgemeines Konzept zur Virtualisierung von Hardware zum par-
allelen Betrieb mehrerer Betriebssysteme. Der Adeos Nanokernel für den Linux-Kernel
wird neben dem Einsatz von Linux als Echtzeitbetriebssystem zum Debuggen des Linux-
Kernels und für das Clustern von Mehrprozessorsystemen verwendet.
Im Vergleich zu Virtualisierungslösungen wie VMWare oder VirtualPC, bei denen auf
dem bestehenden Betriebssystem ein Simulator aufgesetzt wird, wird durch den Adeos
Nanokernel das bestehende Betriebssystem unterwandert.
Jedes registrierte Betriebsystem erhält einen Platz in der Interrupt Pipeline. Ein Platz
in der Interrupt Pipeline wird als Domäne bezeichnet, diese bildet den Rahmen für das
zugeordnete Betriebssystem.
Im Falle des Nanokernels für Linux geschieht dies durch einen Patch des Linux-Kernels.
Dieser Patch entzieht dem Linux-Kernel die direkte Kontrolle über die Interrupts und re-
gistriert Linux als eine Domäne im Adeos Nanokernel. Der Linux-Kernel hat weiterhin den
direkten Zugriff auf den gesamten Adressraum der Hardware, sämtliche Interruptvektoren
zeigen nun allerdings auf die Interrupt Pipeline (IPIPE) des Adeos Nanokernels.
Ein ankommender Interrupt wird zunächst an die Domäne an der vordersten Position
übergeben. Nachdem eine Domäne die Bearbeitung eines Interrupts beendet hat, wird
dieser an die nächste Domäne in der Pipeline weitergereicht. Die Bearbeitung endet,
nachdem die letzte Domäne durchlaufen wurde. Die letzte Domäne wird als Leerlauf-
Domäne bezeichnet, da sie nur dann bedient wird, wenn alle weiter vorne platzierten
Domänen im Leerlauf sind.
Bild 3.1: Interrupt Pipeline
Die einzelnen Domänen sind voneinander abgeschottet, jedes Betriebssystem sieht nur
sich selbst sowie den Adeos Nanokernel.
Es gibt zwei Arten, auf die ein Betriebssystem mit dem Adeos Nanokernel interagie-
ren kann. Die erste Möglichkeit ist die des reinen Verbrauchers, die nur sehr geringe
193 Echtzeitsysteme auf Linux-Basis
Änderungen am Betriebsystem bedingt. Das Betriebssystem hat die Möglichkeit ana-
log zu den Intel Befehlen Set Interrupt Flag (STI) und Clear Interrupt Flag (CLI) die
Interruptbearbeitung in der Pipeline kurzfristig anzuhalten, weitere Möglichkeiten exi-
stieren nicht. Das Ziel von Adeos möglichst wenig an den beteiligten Betriebssystemen zu
verändern wird bei dieser Variante erfüllt.
Bei der zweiten Möglichkeit nimmt das Betriebssystem Einfluß auf die Interrupt Pipeline.
Zum einen hat es die Möglichkeit sich selbst an einen höher priorisierten Platz weiter vorne
in der Interrupt Pipeline zu setzen. Zum anderen kann es entscheiden, ob ein Interrupt
entlang der Pipeline weitergegeben werden soll, und kann damit Einfluß auf die Ressourcen
der anderen Domänen in der Pipeline nehmen.
Im Falle von Linux und RTAI nimmt der Linux-Kernel die Rolle eines reinen Verbrauchers
ein, während RTAI sich an die vorderste Position der Pipeline setzt und den Linux-Kernel
bei Bedarf blockiert. Der Linux-Kernel wird nur dann bedient, wenn sich RTAI im Leerlauf
befindet.
Folgende Illustrationen zeigen die Struktur mit und ohne Interrupt Pipeline:
Bild 3.2: Systemaufbau ohne und mit Interrupt Pipeline
Es ist dabei zu beachten, dass die Interrupt Pipeline nur einen Einfluß auf die Interrupts
nimmt. Die Betriebssysteme können weiterhin direkt mit dem Prozessor kommunizieren
und haben Zugriff auf den kompletten Adressraum der Hardware des Rechners.
3.2.3 Taktgenerierung
RTAI unterstützt verschiedene Taktgeber zur Generierung des Taktes für den Scheduler
[Man99].
Auf der x86 Plattform ist als Bestandteil der Architektur in jedem System ein program-
mierbarer Zeitgeber vom Typ 8254 von Intel enthalten. Dieser heutzutage meistens im
Chipsatz integrierte Baustein besitzt drei unabhängige Zähler der Länge 16 Bit, jeder
203.2 RTAI
Zähler kann mit bis zu 10 MHz von einem externen Zeitgeber getaktet werden. Frequen-
zen unterhalb der Frequenz des externen Zeitgebers können über einen Teiler erreicht
werden, höhere Frequenzen sind nicht möglich.
Von den zahlreichen vom 8254 unterstützten Modi sind für RTAI der periodische Modus
sowie der sogenannte Oneshot-Modus interessant. Beim periodischen Modus wird nach
jedem Ablauf der Zeitvorgabe ein Interrupt ausgelöst, beim Oneshot-Modus muss der
Timer nach jeder Auslösung neu programmiert werden. Jeder der drei Timer kann nur
exklusiv in einem der beiden Modi betrieben werden.
Obwohl drei Zeitgeber vorhanden sind, muss sich RTAI den ersten Timer zusammen mit
Linux teilen. Dieser wird je nach Konfiguration des Linux-Kernels mit 100 Hz, 250 Hz
oder 1000 Hz getaktet. RTAI steht in diesem Fall also nur die gleiche Zeitgranularität wie
dem Linux-Kernel zur Verfügung. Die weiteren des 8254 Timer sind für andere Dienste
des Systems reserviert.
Die zweite Möglichkeit der Taktgenerierung auf der x86 Plattform ist bei modernen Mul-
tiprozessorsystemen die Verwendung des Local Advanced Programmable Interrupt Con-
trollers (Local APIC). Dieser Teil ist auf jedem Prozessor vorhanden und wird zusammen
mit dem IO APIC zur Synchronisation zwischen den Prozessoren verwendet. Der Local
APIC wird vom Front Side Bus des Systems getaktet und kann ebenso als Zeitgeber im
periodischen Modus bzw. im Oneshot-Modus verwendet werden.
Im verwendeten Testsystem mit einem Intel Pentium 4 Prozessor mit Hyper-Threading
Technologie konnte RTAI über den Local APIC mit 12 MHz versorgt werden. Diese weit
unter dem Takt des Front Side Bus liegende Taktfrequenz entsteht laut einer Nachfra-
ge auf der Mailingliste von RTAI durch die Hardware, RTAI selbst hat hier keine Be-
schränkungen.
Der Local APIC ist im Vergleich zum 8254 nicht pro System, sondern pro Prozessor,
einmal vorhanden. Daraus ergibt sich zusätzlich zum Vorteil des höheren Taktes die
Möglichkeit, sowohl einen Zeitgeber im periodischen Modus, als auch einen Zeitgeber
im Oneshot-Modus, parallel zur Verfügung zu haben.
Der Local APIC kann, sofern auf dem Prozessor vorhanden, über die Konfiguration des
Linux-Kernels aktiviert werden.
Der für den Entwickler relevante Unterschied zwischen dem periodischen Modus und dem
Oneshot-Modus wird zu einem späteren Zeitpunkt erläutert.
3.2.4 Zeitmessung
Seit der Intel Pentium Prozessorenreihe kann über den rdtsc-Befehl der interne Taktzy-
kluszähler des Prozessors ausgelesen werden. Dieser Zähler wird bei jedem Taktzyklus
inkrementiert und hat bei heutigen Prozessoren mit Taktfrequenzen im Bereich von meh-
reren Gigahertz somit eine sehr hohe Auflösung.
21Sie können auch lesen
