Untersuchung von Ansätzen zur CAN-Kommunikation in Echtzeit unter Linux

Größe: px
Ab Seite anzeigen:

Download "Untersuchung von Ansätzen zur CAN-Kommunikation in Echtzeit unter Linux"

Transkript

1 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 TECHNISCHE UNIVERSITÄT MÜNCHEN UNIV.-PROF. DR.-ING. G. F ÄRBER Untersuchung von Ansätzen zur CAN-Kommunikation in Echtzeit unter Linux Matthias Keller Bachelorarbeit

2

3 Untersuchung 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: Bearbeiter: Dipl. Ing. Sebastian Drössler Matthias Keller Hildachstraße 7a München Eingereicht im Mai 2006

4 t4

5 Danksagung Ich möchte mich bei Herrn Prof. Dr. Ing. G. Färber und Herrn Dipl. Ing. S. Drössler bedanken, 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 Fahrzeugentwicklung 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

6

7 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der verwendeten Symbole viii ix x 1 Einleitung 1 2 Grundlagen CAN-Bus Einführung Medium Übertragungsrate und Leitungslänge Objektidentifier und Buszugriff Frame-Formate Einschränkungen Echtzeit Grundlagen Latenzzeit Jitter Deadline Weiche und harte Echtzeit Programmierung von Echtzeitsystemen Wichtige Konzepte eines Betriebssystems am Beispiel Linux Rechenprozess Kernel-Modus und Benutzer-Modus Speicherverwaltung Kernelspace und Userspace Ein-/Ausgabegeräte Multitasking Interruptsystem Scheduling Semaphoren Gemeinsam genutzte Speicherbereiche FIFO Puffer Ringpuffer v

8 Inhaltsverzeichnis 3 Echtzeitsysteme auf Linux-Basis Linux Einschränkungen Lösungsansätze Zusammenfassung RTAI Einführung Adeos Nanokernel mit Interrupt Pipeline Taktgenerierung Zeitmessung Scheduler Speicherverwaltung Weitere Funktionen von RTAI Entwicklung von RT Applikationen im Kernelspace Entwicklung von RT Applikationen mit LXRT im Userspace Hinweise zur Entwicklung von RT Applikationen mit RTAI Hardwareunterstützung Weitere Ansätze Entwicklung eines CAN-Treibers für RTAI Einführung Hardware Realtime CAN for Linux/RTAI Hardware-Abstraktions-Schicht Funktionsweise Unterstützte Hardware Wichtige Dateien Projektstatus Entwicklung der Anpassung für den PCAN-PCI Adapter Wahl des Rahmens Einschränkungen und Probleme von Rtcan Hardware-spezifische Anpassungen Entwicklung einer Benutzerschnittstelle Fehlerbehandlung Einschränkungen Installation und Verwendung Socket-basierter CAN-Treiber Messungen zur Beurteilung des Echtzeitverhaltens Einführung Ziel der Messungen Versuchsaufbau CAN Datenlogger Testsysteme vi

9 Inhaltsverzeichnis Konfigurationen des Linux-PC Lastgeneratoren Testszenarien Szenario 1: Periodisches Senden einer CAN-Nachricht Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten Szenario 3: Messung der Reaktionszeit über den CAN-Bus Testdurchführung Auswertung Allgemeine Aufbereitung der Daten Periodische Tests Reaktionstests Ergebnisse Szenario 1: Periodisches Senden einer CAN-Nachricht Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten Szenario 3: Messung der Reaktionszeit über den CAN-Bus Zusammenfassung 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 D.2 Demo-Programme für Rtcan D.3 QT RTcan Display D.4 Tests D.5 Auswertung der Tests Literaturverzeichnis 67 vii

10 Abbildungsverzeichnis 2.1 Abrupter Schaden bei der Überschreitung der Deadline bei einer harten Echtzeitanforderung. [Sch02] Interrupt Pipeline Systemaufbau ohne und mit Interrupt Pipeline PCAN-PCI Einsteckkarte Aufbau des PCAN-PCI Adapters Messung 7: RTAI Messung 15: Linux Messung 11: PCAN-View Messung 4: LXRT, höchstpriorer Task Messung 4: LXRT, niedrigstpriorer Task Messung 24: Linux Messung 29: LXRT C.1 Screenshot von QT RTcan Display viii

11 Tabellenverzeichnis 2.1 Werte auf dem CAN-Bus Maximale Leitungslänge bei vorgegebener Übertragungsrate Einige Ziele des Scheduling-Algorithmus bei verschiedenen Umgebungen Prozesszustände unter Linux FIFO API Maximale Abweichung von der Periode von 1 ms Durchschnittliche Abweichung von der Periode von 1 ms Vergleich der maximalen Abweichung über Szenario 1 & Vergleich der durchschnittlichen Abweichung über Szenario 1 & Maximale Reaktionszeit Durchschnittliche Reaktionszeit B.1 Szenario 1: Periodisches Senden einer CAN-Nachricht B.2 Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten.. 61 B.3 Szenario 3: Messung der Reaktionszeit über den CAN-Bus ix

12 Verzeichnis der verwendeten Symbole ACPI ADEOS APM API CAN CPU CRC CSMA/CA DIAPM DV EDF GNU GPL HAL IPC IPIPE LXRT MOST PITA POSIX QT RCS RPC RT RTAI RTDM RTHAL WCET Advanced Configuration and Power Interface Adaptive Domain Environment for Operating Systems Advanced Power Management Programmierschnittstelle (Application Programming Interface) Feldbussystem (Controller Area Network) Prozessor (Central Processing Unit) zyklische Redundanzprüfung (Cyclic Redundancy Code) Carrier Sense Multiple Access/Collision Avoidance Dipartimento di Ingegneria Aerospaziale Datenverarbeitung Scheduler-Strategie (Earliest Deadline First) GNU is not UNIX GNU Public Licence Hardware-Abstraktions-Schicht (Hardware Abstraction Layer) Interprozesskommunikation Interrupt Pipeline Linux Real-Time Feldbussystem (Media Oriented Systems Transport) PCI Interface for Telephony/Data Applications standardisiertes Applikationsebeneninterface, das die Schnittstelle zwischen Applikation und dem Betriebssystem darstellt (Portable Operating System Interface for UniX) Programm-Bibliothek zum Entwickeln grafischer Oberflächen mit C++ Lehrstuhl für Realzeit-Computersysteme Funktionsaufruf auf einem entfernten Rechner (Remote Procedure Call) Echtzeit (Real-Time) Real Time Application Interface Real-Time Driver Model Real-Time Hardware Abstraction Layer Worst Case Execution Time x

13 Zusammenfassung Aktuelle Weiterentwicklungen am Linux-Kernel sollen den Einsatz von Linux auf Standard- Hardware der x86-architektur in Echtzeitumgebungen ermöglichen. Frei verfügbare Echtzeiterweiterungen wie RTAI erheben den Anspruch für einen Betrieb unter harten Echtzeitbedingungen 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 Umfelderkennung 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 Echtzeitsysteme objektiv untersucht. Dazu werden an eine spätere Applikation orientierte Testszenarien definiert. Nach der Auswertung der Tests werden weitere Schritte für eine genauere Untersuchung der Einsatzfähigkeit geschildert. xi

14 xii

15 1 Einleitung Im Rahmen von Forschungsarbeiten zur Umfelderkennung im Automobilbereich werden 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 verwendet. 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 mehrere 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 Messdaten 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 Echtzeitbedingungen 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: 1

16 1 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 Entwicklungsund Wartungsaufwand mit sich. Die Einschränkungen auf Seiten der Softwareentwicklung führen zu einem erhöhten Einsatz von Workarounds, und sind daher nicht optimal. Aktuelle Weiterentwicklungen an Linux, sowie neue, frei verfügbare Echtzeiterweiterungen, 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 Echtzeitumgebung 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 Einsatzfä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. 2

17 2 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 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 parallelen 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 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 Der CAN-Bus wird sowohl zur Vernetzung von Steuergeräten im Automobilbereich, als auch in vielen Industrie- und Automatisierungsanwendungen zum Messen und Steuern verwendet 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 Leitungen 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: 3

18 2 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 Ü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 physikalischen Eigenschaften des Trägers bestimmt. Durch die Ausbreitungsgeschwindigkeit v in Kupfer ergeben sich folgende theoretisch maximal mögliche Leitungslängen: 1 MBit s 1 40 m Highspeed-Bus 500 KBit s m 125 KBit s 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 geringeren Datenübertragungsrate eingesetzt 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 werden durch die Arbitrierung vermieden. Bei der Arbitrierung beginnt jeder Sender mit dem Versand des Identifiers seiner zu versendenden 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. 4

19 2.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 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 Teilnehmer 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 Informationen wie z. B. eine CRC-Prüfsumme zur Sicherung der Daten enthalten Einschränkungen Trotz der Hierarchie der Nachrichten ist auch bei hochprioren Nachrichten der Sendezeitpunkt nicht exakt bestimmbar. Dieses nicht-deterministische Verhalten macht Schwierigkeiten 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 Grundlagen Der Begriff Echtzeit beschreibt eine Zeitanforderung an das Antwortverhalten einer Anwendung bei der Bearbeitung von Rechenprozessen. 5

20 2 Grundlagen Je nach Anwendung ist diese Zeitanforderung unterschiedlich. Sehr hohe Anforderungen sind zum Beispiel im Automobilbereich vorhanden. Diese liegen hier teilweise im Mikrosekundenbereich (z. B. Motorsteuerung), für Regelungen meist in einem Bereich von 10 ms Latenzzeit Bei der Latenzzeit handelt sich um eine Verzögerung. In Kommunikationsnetzwerken entspricht die Latenzzeit der durch den Übertragungsweg bedingten Verzögerung. Leitungswege 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 verschlechtern. 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 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 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 Unterbrechungen von höherprioreren Tasks, Unterbrechungen durch externe Ereignisse, sowie bei der Kommunikation mit anderen Prozessen zu Stande kommen. 6

21 2.2 Echtzeit 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 Echtzeitanforderung. [Sch02] Während die Verletzung einer harten Echtzeitbedingung zu einem schwerwiegenden Schaden 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 Videodaten oder das Digitalisieren von analogen Audiodaten Programmierung von Echtzeitsystemen Nach [Fär04] sollten bei der Programmierung von Echtzeitsystemen all diejenigen Konstrukte vermieden werden, die eine Bestimmung der WCET erschweren. Folgende Punkte müssen dabei beachtet werden: Keine rekursiven Programme/Prozeduren verwenden, Umformen in Programmschleifen. 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). 7

22 2 Grundlagen 2.3 Wichtige Konzepte eines Betriebssystems am Beispiel Linux In diesem Abschnitt sollen die für diese Arbeit relevanten grundlegenden Konzepte eines modernen Betriebssystems wiederholt werden. Innerhalb der Theorie wird auf die Umsetzung der vorgestelltungen Konzepte unter Linux eingegangen 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 Speicherbereich 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 Rechenprozess 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 Kernel-Modus und Benutzer-Modus Die Berechtigungsstufe eines Prozesses wird als Ring bezeichnet. Diese schränkt den Prozess 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 Speicherverwaltung Der Begriff Speicher wird im aktuellen Kontext als Synonym für Arbeitsspeicher verwendet. 8

23 2.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 Festplatte 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 Zugriffen 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 Ersetzungsstrategie wird der Buddy-Algorithmus [Tan03] verwendet. Bei einem Speicherzugriffsfehler wird der auslösende Prozess vom Betriebssystem beendet (segmentation fault) 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 Speicherbereiche können aus dem physikalischen Speicher verdrängt werden, der Speicherschutz beschränkt die Prozesse auf ihren eigenen Speicherbereich Ein-/Ausgabegeräte Ein-/Ausgabegeräte können in die zwei Klassen blockorientierte Geräte und zeichenorientierte 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. 9

24 2 Grundlagen 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 ablaufen. 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 Rechenprozesses Scheduler mit Prozessumschalter zur Verteilung der Ressourcen auf die Rechenprozesse Speicherverwaltung mit exklusivem Adressraum für jeden Rechenprozess 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 Ethernetcontroller 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 wiederhergestellt und der Prozess in den aktiven Zustand zurückgesetzt. Innerhalb der Interrupts werden Prioritäten vergeben. Durch Maskierung kann ein Interrupt 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. 10

25 2.3 Wichtige Konzepte eines Betriebssystems am Beispiel Linux Scheduling Scheduling beschäftigt sich mit der Verteilung der Rechenzeit auf die Rechenprozesse. Neben der Verteilung der Rechenzeit gibt es auch Verfahren zur Verteilung anderer Ressourcen 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 existent 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 Umgebungen: 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 Einhaltung 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. Prozesse mit einer dynamischen Priorität werden erst dann ausgeführt, wenn kein Prozess 11

26 2 Grundlagen TASK RUNNING TASK INTERRUPTIBLE TASK UNINTERRUPTIBLE TASK ZOMBIE TASK STOPPED Task rechnet oder ist rechenbereit Task wartet auf ein externes Ereignis, kann durch einen Interrupt aufgeweckt werden Task wartet auf ein externes Ereignis, kann nicht durch einen Interrupt aufgeweckt werden beendeter Task, dessen Prozessstruktur sich noch in der Prozesstabelle befindet 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 beschrieben werden. Prozesse mit statischer Priorität gehören zu den Echtzeit-Ansätzen von Linux, 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 Rechenzeit zugeteilt. Dieser Anteil in Jiffies ist seine Standardpriorität bzw. der Startwert seines Quantums. Das Quantum am Beginn einer Epoche setzt sich aus einem vordefinierten 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. 12

27 2.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 Scheduling ist nicht vorhersagbar, garantierte Ausführungszeiten sind nicht möglich Semaphoren Ein Semaphor ist eine Datenstruktur zur Prozesssynchronisation. Mit Hilfe von Semaphoren 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 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 Anwendungsentwickler Mechanismen zur Kontrolle des konkurrierenden Zugriffs sowie zur Gültigkeitskontrolle der Inhalte implementiert werden 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. 13

28 2 Grundlagen Ringpuffer Ein Ringpuffer ist eine spezielle Variante eines FIFO Puffers. Im Vergleich zu einer Warteschlange 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 Schreibbzw. 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

29 3 Echtzeitsysteme auf Linux-Basis Im ersten Teil dieses Kapitels werden die Einsatzmöglichkeiten von Linux als Echtzeitbetriebssystem 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 befindet 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 Zusammenfassung 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 Einschränkungen Linux ist ein traditionelles Multitasking-Betriebssystem Linux ist ein general purpose Betriebssystem und damit auf den durchschnittlich auftretenden Fall optimiert. Im Multitasking-Betrieb wird eine große Anzahl von Diensten parallel ausgeführt, das Scheduling ist auf eine Optimierung des Datendurchsatzes ausgelegt. Dies widerspricht dem Konzept eines auf den Worst-Case ausgelegten Echtzeitbetriebssystems, das die Minimierung von Latenzzeiten sowie garantierte Ausführungszeiten als Ziel hat. 15

30 3 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 herausgearbeitet, 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 Lösungsansätze Echtzeitfähige Scheduler-Strategien Neben der bereits beschriebenen Scheduler-Strategie SCHED OTHER sind die zwei weiteren Strategien SCHED FIFO sowie SCHED RR vorhanden. 16

31 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 dynamischen 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 Einschränkungen nicht aufgehoben werden. Aus den Anforderungen an einen Scheduler-Algorithmus (2.3) zielen diese beiden Strategien 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 werden. 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 Pfade (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 Speicherseiten im physikalischen Speicher bleiben. 17

32 3 Echtzeitsysteme auf Linux-Basis 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 Einführung RTAI (Real Time Application Interface) ist eine Erweiterung von Linux zu einem Echtzeitbetriebssystem. 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 eingeflossen. 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 Benutzerprozess 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 Position. 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]. 18

33 3.2 RTAI Adeos Nanokernel mit Interrupt Pipeline Nachdem der Real-Time Hardware Abstraction Layer wie bereits erwähnt durch den Adeos Nanokernel ersetzt wurde, soll an dieser Stelle ausschließlich der Adeos Nanokernel betrachtet 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 Umsetzung 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 beschreibt zunächst ein allgemeines Konzept zur Virtualisierung von Hardware zum parallelen 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 registriert 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 interagieren kann. Die erste Möglichkeit ist die des reinen Verbrauchers, die nur sehr geringe 19

34 3 Echtzeitsysteme auf Linux-Basis Änderungen am Betriebsystem bedingt. Das Betriebssystem hat die Möglichkeit analog zu den Intel Befehlen Set Interrupt Flag (STI) und Clear Interrupt Flag (CLI) die Interruptbearbeitung in der Pipeline kurzfristig anzuhalten, weitere Möglichkeiten existieren 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 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 programmierbarer 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 20

35 3.2 RTAI Zähler kann mit bis zu 10 MHz von einem externen Zeitgeber getaktet werden. Frequenzen 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 Multiprozessorsystemen die Verwendung des Local Advanced Programmable Interrupt Controllers (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 Nachfrage auf der Mailingliste von RTAI durch die Hardware, RTAI selbst hat hier keine Beschrä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 Zeitmessung Seit der Intel Pentium Prozessorenreihe kann über den rdtsc-befehl der interne Taktzykluszähler des Prozessors ausgelesen werden. Dieser Zähler wird bei jedem Taktzyklus inkrementiert und hat bei heutigen Prozessoren mit Taktfrequenzen im Bereich von mehreren Gigahertz somit eine sehr hohe Auflösung. 21

36 3 Echtzeitsysteme auf Linux-Basis Vor allem bei einem Betrieb des programmierbaren Zeitgebers im Oneshot-Modus wird diese Methode zur Zeitmessung verwendet und dient in diesem Fall unter anderem für Entscheidungen des Schedulers. Auf Rechnern mit einem zum Intel 486er kompatiblen Prozessor wird der dritte Zähler des 8254 für diesen Zweck verwendet, normal ist dieser Zähler für die Generierung der Systempieptöne reserviert Scheduler Der Scheduler wird wie unter Linux bei jedem Interrupt des Zeitgebers aufgerufen. Als Quelle dient dazu wie bereits erläutert der 8254 bzw. der Local APIC. Die genaue Taktfrequenz hängt von der Einstellung der Software ab. Jeder Task befindet sich in einem der folgenden zehn Zustände: READY, SUSPENDED, DELAYED, SEMAPHORE, SEND, RECEIVE, RPC, RETURN, RUNNING, DELETED [Mou02]. Die Aufteilung in mehrere Arten von Blockierungen kann vom Entwickler genutzt werden um einen detailierten Überblick über den aktuellen Prozessstatus zu erhalten. Es kann für jeden Task eine individuelle Priorität vergeben werden, die höchste Priorität hat den Wert 0, die niedrigste Priorität den Wert RT SCHED LOWEST PRIORITY. Die Standard-Strategie des Schedulers verwendet innerhalb jeder Priorität das First In - First Out Prinzip, d.h. der älteste Task innerhalb einer Priorität bekommt den Prozessor zugeteilt. Über die Funktion rt set sched policy() besteht die Möglichkeit auf Task-Basis eine Round Robin-Strategie einzusetzen. Über die Funktion rt task set resume end times() kann innerhalb der FIFO Scheduler- Strategie ein fester Zeitpunkt für die Ausführung eines Tasks angegeben werden. Dem Task wird dazu die höchste Priorität zugeteilt, die für den Scheduler relevanten Zeiten werden angepasst. In der RTAI Dokumentation aus der 24.x Distribution wird diese Vorgehensweise als Earliest Deadline First Scheduling angeboten. Da der Scheduler von RTAI keine Informationen über die Ausführungszeit eines Tasks besitzt, entspricht dies keinem richtigen EDF. Mit der Funktion rt spv RMS() können alle laufenden Tasks so umsortiert werden, dass das Scheduling nach einer Rate Monotonic Scheduling Strategie betrieben wird. Bei dieser Strategie bekommt der Task mit der kleinsten Periode die höchste Priorität zugeteilt Speicherverwaltung Um die Nachteile von Linux bei der dynamischen Speicherverwaltung zu vermeiden, bietet RTAI über die Funktionen rt malloc() und rt free() eine eigene Speicherverwaltung an. Im Gegensatz zur Allokierung bei der Laufzeit unter Linux, wird von RTAI beim Start ein Speicherblock reserviert. Beim Aufruf von rt malloc() wird dem anfordernden Task 22

37 3.2 RTAI ein Bereich aus diesem Block zugewiesen Weitere Funktionen von RTAI RTAI ist modular aufgebaut und wird in Form mehrerer Module für den Linux-Kernel geliefert. Über eine nicht POSIX-konforme API hat der Entwickler Zugriff auf die verschiedenen Funktionalitäten. Die verschiedenen Funktionen können in Gruppen eingeordnet werden, in den meisten Fällen wird jede Gruppe durch ein eigenes Modul realisiert. Im folgenden soll nun ein grober Überblick über die Gruppen und ihre Funktionen gegeben werden, auf die API selbst wird im Detail nicht eingegangen. Weiterführende Informationen zu diesem Themengebiet befinden sich in der aus der RTAI Distribution erzeugbaren API Dokumentation bzw. im RTAI Programming Guide [DIA00]. Die folgenden drei Gruppen bilden die Grundfunktionen von RTAI und werden in nahezu allen Applikationen benötigt: Funktionen zur Steuerung von Tasks In dieser Gruppe sind die Funktionen zum Anlegen, Löschen, Anhalten und Fortsetzen eines Tasks enthalten. Es ist möglich mehrere parallele Tasks mit unterschiedlichen Prioritäten und verschiedenen Scheduler-Strategien zu betreiben. Außerdem kann ein Task als periodischer Task mit einer bestimmten Periode eingerichtet werden. Auf Multiprozessorsystemen besteht die Möglichkeit einen Task einem bestimmten Prozessor zuzuweisen. Einige wichtige Funktionen aus dieser Gruppe: rt task init() rt task init cpuid() rt task delete() rt task make periodic() rt task resume() rt sleep() rt set sched policy() rt get prio() rt change prio() 23

38 3 Echtzeitsysteme auf Linux-Basis Funktionen zur Steuerung des Zeitgebers Neben Methoden zum Setzen des Modus, sowie dem Starten des Zeitgebers, bietet diese Gruppe Funktionen zur Zeitmessung. Die Zeiten werden dabei in sogenannten Counts gemessen. Ein Count entspricht einer Auslösung des Zeitgebers und kann in Nanosekunden umgerechnet werden. Wichtige Funktionen: rt set oneshot mode() rt set periodic mode() rt start timer() rt stop timer() rt get time() rt get time cpuid() nano2count() count2nano() Funktionen für allgemeine Dienste In dieser Gruppe sind die Funktionen zur Interruptbehandlung enthalten. Interrupts können aktiviert und mit einem Handler verknüpft werden, dies ist sowohl für RTAI als auch für Linux möglich. Interrupts können an den Linux-Kernel weitergegeben werden kann. Wichtige Funktionen zur Interruptbehandlung inklusive den Funktionen zum Sichern und Laden des Kontexts: rt enable irq() rt disable irq() rt request global irq() rt ack irq() rt pend linux irq() rt global save flags() rt global restore flags() Die folgenden weiteren Gruppen bieten Funktionalitäten an, die nicht in allen Applikationen benötigt werden. 24

39 3.2 RTAI Funktionen zur Verwaltung von FIFO Puffern FIFO Puffer eignen sich unter RTAI besonders zum Datenaustausch zwischen Echtzeitund Linuxprozessen. Auf der Seite von RTAI ist eine API zur Verwaltung von FIFO Puffern vorhanden, gleichzeitig wird unter Linux eine Gerätedatei angelegt. Auf diese Datei kann mit den üblichen Funktionen zum Lesen und Schreiben von Dateien zugegriffen werden. Folgende Tabelle stellt den Zugriff auf von RTAI angelegte FIFO Puffer gegenüber: Semantik RTAI Linux Öffnen rtf create() mknod(), open() Löschen rtf destroy() close(), unlink() Lesen rtf get() read() Schreiben rtf put() write() Tabelle 3.1: FIFO API Weitere Funktionsgruppen Im folgenden soll nach Gruppen sortiert ein grober Überblick über weitere Module gegegeben werden. In der Regel handelt es sich hierbei um Konzepte, die bereits in den Grundlagen erläutert wurden. Steuerung von Semaphoren: rt sem init() rt sem delete() rt sem signal() rt sem wait() Steuerung von Mailboxen: rt mbx init() rt mbx delete() rt mbx send() rt mbx receive() Anlegen und Freisetzen von Shared Memory: rtai malloc() rtai free() Versand von Nachrichten zwischen Echtzeit-Tasks: 25

40 3 Echtzeitsysteme auf Linux-Basis rt send() rt receive() RPC-Funktionen: rt rpc() rt return() POSIX-konforme API Neben der eigenen nicht POSIX-konformen API, ist für folgende Module eine POSIXkonforme API vorhanden: Pthread Mutex Condition Variables Message Queues Entwicklung von RT Applikationen im Kernelspace Echtzeitapplikationen für RTAI werden als Module für den Linux-Kernel entwickelt. Die Anwendung wird durch das Laden des Modules gestartet, durch das Entladen des Modules wird die Anwendung beendet. Jedes Kernel-Modul, und somit auch jede RTAI Applikation im Kernelspace, muss gemäß dem folgenden Grundgerüst zwei Einstiegspunkte bereitstellen: 26

41 3.2 RTAI Grundgerüst für Kernel-Module in C-Code #include <linux/module.h> int init module(void) { /* auszuführender Code beim Laden des Modules */ return 0; } void cleanup module(void) { /* auszuführender Code beim Entladen des Modules */ return; } Die Standardwerte init module() bzw. cleanup module() können über die Makros module init() bzw. module exit() durch andere Funktionsnamen ersetzt werden. Seit der Kernel Version 2.6 kann der sogenannte kbuild-mechanismus zum Übersetzen von Kernel-Modulen verwendet werden. Makefile zur Übersetzung einer RTAI Applikation für Kernel 2.6 obj-m := meine applikation.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) EXTRA CFLAGS := -I/usr/realtime/include -I/usr/include/ -I$(KDIR)/include/asm-i386/mach-default/ meine applikation: $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules Das folgende Beispiel soll einen groben Einstieg in die Entwicklung von RTAI Applikationen geben. Die Struktur RT TASK enthält den kompletten Kontext des neuen Tasks Mein Task (Zeile 6). Beim Laden des Modules wird die Funktion init module() (Zeile 14) aufgerufen. In Zeile 18 wird der neue Task initialisiert, der Funktionspointer zeigt auf die Funktion Mein Thread(), ein Stack mit der Größe von 2000 Bytes wird reserviert, der Task bekommt eine Scheduler-Priorität von 1. Nachdem der Zeitgeber in den Oneshot-Modus 27

42 3 Echtzeitsysteme auf Linux-Basis versetzt wird (Zeile 19), wird er mit der Periode von 1 ms gestartet (Zeile 20). Der Task Mein Task wird anschließend gestartet, die erste Ausführung findet in einer Millisekunde vom aktuellen Zeitstempel aus statt, die Periode beträgt ebenso eine Millisekunde (Zeile 22). Bei der Ausführung springt das Programm in eine Endlosschleife (Zeile 9-12) und wartet nach jedem Durchgang auf den Beginn der neuen Periode (Zeile 11). Während dieser Wartezeit kann das System von anderen Tasks benutzt werden. Der vom Scheduler verwendete Zeitgeber wird nach jeder Periode neu eingerichtet. Beim Entladen des Modules wird die Funktion cleanup module() (Zeile 25) aufgerufen, die den Zeitgeber anhält (Zeile 27) und zuletzt den Task entfernt (Zeile 28). Beispiel C-Code für eine RTAI Applikation mit einem Task im Oneshot-Modus 1 #include <linux/module.h> 2 #include <asm/io.h> 3 #include <rtai.h> 4 #include <rtai sched.h> 5 #define PERIOD // 1 ms 6 static RT TASK Mein Task; 7 static void Mein Thread(int t) 8 { 9 while (1) { 10 /* periodisch auszuführender Code */ 11 rt task wait period(); 12 } 13 } 14 int init module(void) 15 { 16 RTIME tick period; 17 RTIME now; 18 rt task init(&mein Task, Mein Thread, 0, 2000, 1, 0, 0); 19 rt set oneshot mode(); 20 tick period = start rt timer(nano2count(period)); 28

43 3.2 RTAI Fortsetzung Beispiel C-Code für eine RTAI Applikation 21 now = rt get time(); 22 rt task make periodic(&mein Task, now + tick period, tick period); 23 return 0; 24 } 25 void cleanup module(void) 26 { 27 stop rt timer(); 28 rt task delete(&mein Task); 29 return; 30 } Die Entwicklung von Software im Kernelspace stellt hohe Anforderungen an den Entwickler. Durch den nicht vorhandenen Schutz kann es zu Speicherverletzungen kommen, die zu einem Absturz des Systems bis hin zu einem Schaden am System führen können. Außerdem ist es sehr aufwendig Software im Kernelspace zu debuggen, ohne größeren Aufwand steht hier nur die Ausgabe von Meldungen auf die Kernel-Konsole mit printk() bzw. rt printk() zur Verfügung. Als letzter Nachteil ergibt sich, dass im Kernelspace keine dynamisch gelinkten Bibliotheken geladen werden können, womit der Funktionsumfang sehr begrenzt ist. Für die Entwicklung von Geräte-Treibern ist die Entwicklung im Kernelspace unumgänglich, als Alternative zum Betrieb von Applikationen mit harten Echtzeitanfordungen im Kernelspace bietet RTAI mit LXRT eine Lösung für harte Echtzeit im Userspace an Entwicklung von RT Applikationen mit LXRT im Userspace Mit Hilfe des LXRT soll harte Echtzeit im Userspace möglich sein. Hierzu wird zunächst ein Kernelmodul geladen, das die Funktion eines Servers übernimmt. Sobald im Userspace eine LXRT Applikation einen Task anlegt, legt dieser Server einen echten RT Task im Kernelspace an. Jeder API Aufruf aus der LXRT Applikation wird über einen Software- Interrupt in den Kernelspace übertragen und dort vom echten RT Task ausgeführt. Durch diesen Umweg in den Kernelspace entsteht im Vergleich zu RT Applikationen im Kernel ein Overhead. Dieser ist laut den Entwicklern von RTAI allerdings sehr gering. 29

44 3 Echtzeitsysteme auf Linux-Basis Für LXRT Applikationen steht nahezu die selbe API wie für RT Applikationen im Kernelspace zur Verfügung, eine wichtige Ausnahme ist die Funktion rt task init() zum Anlegen eines Tasks, hier sind die Parameter unterschiedlich. Neben dem Zugriff auf die RTAI API ist es aus LXRT Applikationen ebenso möglich Linux Systemaufrufe zu verwenden. Die zwei ergänzten API Aufrufe rt make hard real time() bzw. rt make soft real time() ermöglichen den Wechsel zwischen harter und weicher Echtzeit. Im Falle von harter Echtzeit ist der Userspace-Prozess in der Prozesstabelle von Linux nicht mehr sichtbar. Der Einsatz von LXRT bietet neben dem Einsatz von Linux-Systemaufrufen die weiteren Vorteile der Softwareentwicklung im Userspace wie den Speicherschutz, die Verwendung von dynamisch gelinkten Bibliotheken und die vereinfachten Möglichkeiten des Debuggings. Diese Vorteile sind beim Einsatz weicher Echtzeit vollständig vorhanden, nach dem Wechsel in harte Echtzeit kann es zu Problemen wie Deadlock-Situationen kommen. Die Entwicklung von LXRT Anwendungen ist der Entwicklung von RTAI Applikationen im Kernelspace sehr ähnlich, Beispiel-Quellen für LXRT Anwendungen befinden sich im Anhang dieser Arbeit Hinweise zur Entwicklung von RT Applikationen mit RTAI Eine wichtige Designentscheidung beim Einsatz von RTAI ist die Wahl des Modus des Zeitgebers. Sofern alle Tasks mit der selben Periode aufgerufen werden oder die Perioden Vielfache voneinander sind, ist der periodische Modus zu empfehlen. Falls dies nicht der Fall ist, muss der Oneshot-Modus zum Einsatz kommen. Dieser hat den Nachteil, dass durch die neue Programmierung des Timers nach jeder Auslösung ein geringer Overhead entsteht. Dieser Overhead ist bei der Verwendung des APIC als Zeitgeber kleiner als bei der Verwendung des Sofern die Anwendung keinen Zugriff auf Speicherabschnitte des Kernelspace benötigt, sollte die Entwicklung im Userspace mit Hilfe des LXRT stattfinden. Zunächst sollte hier nur weiche Echtzeit verwendet werden, nachdem der Code geprüft wurde kann auf harte Echtzeit umgestellt werden. Zur Vermeidung des Overheads durch den Einsatz des LXRT kann die funktionsfähige Applikation zuletzt für den Kernelspace umgeschrieben werden. Dazu muss der Quellcode an das Grundgerüst für Kernelmodule angepasst werden. Während der Laufzeit werden einige Informationen von RTAI unter dem Pfad /proc/rtai/ bereitgestellt, hier befindet sich zum Beispiel die aktuelle Prozesstabelle des Schedulers (/proc/rtai/scheduler) Hardwareunterstützung Bei der Unterstützung von Hardware ist RTAI gegenüber Linux noch weit unterlegen. Das Real-Time Driver Model RTDM soll die Entwicklung von Gerätetreibern beschleunigen, 30

45 3.3 Weitere Ansätze zum Beispiel der Netzwerkstack RTnet setzt auf diesem Modell auf. Neben der Unterstützung von Ethernet befassen sich einige Projekte mit der Unterstützung von USB und Firewire. Der Stand dieser Projekte ist nicht bekannt. Im nächsten Kapitel wird die Entwicklung eines Treibers für einen CAN-Adapter sowie einer API zum Zugriff auf diesen Treiber beschrieben. 3.3 Weitere Ansätze Diese Liste soll einen kurzen Überblick über weitere, in dieser Arbeit nicht untersuchte, Ansätze geben. Die Liste erhebt keinen Anspruch auf Vollständigkeit. RTLinux Über die Entstehungsgeschichte von RTAI ergeben sich sehr starke Ähnlichkeiten zwischen RTAI und RTLinux. Im Gegensatz zu RTAI ist die API von RTLinux vollständig POSIX-kompatibel [Kuh00], womit eine einfachere Portierung von Software ermöglicht wird. Der Zweig zum Einsatz auf Linux-Kerneln der Reihe 2.6 wird von der Firma FSMLabs kommerziell vertrieben. Xenomai Xenomai ist ein frei verfügbares Framework zur Entwicklung von Echtzeitanwendungen unter Linux. Es besteht aus einem Nanokernel sowie einer Abstraktionsschicht, auf die verschiedene Emulatoren (Skins) aufgesetzt werden können. Ein Skin ermöglicht die Verwendung der API des emulierten Echtzeitbetriebssystem. RTAI/fusion RTAI/fusion ist ein komplett neuer Entwicklungszweig von RTAI, der sowohl auf dem Adeos Nanokernel sowie auf Xenomai aufsetzt. Das Ziel von RTAI/fusion ist die Unterstützung von harter Echtzeit im Userspace. Dies würde zum Beispiel die Verwendung der bereits vorhandenen Hardwareunterstützung von Linux ermöglichen. 31

46 4 Entwicklung eines CAN-Treibers für RTAI 4.1 Einführung Eine Unterstützung für Kommunikation über den CAN-Bus ist eine Grundvoraussetzung für den Einsatz eines Betriebssystems im Automobilbereich. Bei Beginn dieser Arbeit im November 2005 war eine derartige Unterstützung für RTAI auf der x86 Plattform noch nicht verfügbar. Aus diesem Grund umfasst diese Arbeit die Entwicklung eines CAN-Treibers für RTAI, als Hardware wird dabei ein PCAN-PCI Adapter von PEAK-System Technik GmbH verwendet. Der Treiber wird aufbauend auf dem unter der GPL stehenden Rtcan Framework entwickelt. Die während dieser Arbeit entstandene Weiterentwicklung ist als freie Software unter der GPL ebenso frei zugänglich. Im März 2006 wurde als Ergebnis einer Diplomarbeit am Lehrstuhl für Systems Engineering der Universität Hannover ein weiteres Framework für CAN-Kommunikation unter RTAI entwickelt. Der Ansatz dieses Frameworks wird am Ende dieses Kapitels kurz erläutert. 4.2 Hardware Im Rahmen der Arbeit stand die Zweikanalversion des PCAN-PCI Adapters von PEAK- System zur Verfügung. Es handelt sich hierbei um eine Einsteckkarte für den PCI-Bus. Für jeden Kanal ist ein CAN-Kontroller vom Typ SJA1000 von Philips zuständig. Der SJA1000 unterstützt die CAN Spezifikationen CAN 2.0A und CAN 2.0B für die Übertragung von Nachrichten im Standard Frame-Format sowie im erweiterten Frame- Format bei einer Übertragungsrate von bis zu 1 MBit s 1. Über einen PITA vom Typ PSB4600 der Siemens AG werden die beiden CAN-Kontroller an den PCI-Bus angebunden. Der PITA fordert vom System einen Interrupt sowie einen 2048 Bit großen Adressraum an. Er kann über die PCI Vendor ID sowie die PCI Product ID identifiziert werden. 32

47 4.2 Hardware Bild 4.1: PCAN-PCI Einsteckkarte Die CAN-Kontroller werden über das parallele Interface des PITA angeschlossen, neben einem 8 Bit breiten Adress- und Datenbus wird jeder Kontroller mit einer Interruptleitung sowie weiteren Steuerleitungen versorgt. Die Interrupts der angeschlossenen Geräte werden vom PITA verwaltet. Nachdem der PITA die CPU über einen Interrupt benachrichtigt hat, muss dieser über interne Register des PITA identifiziert werden. Das folgende Diagramm veranschaulicht den Aufbau des PCAN-PCI Adapters: Bild 4.2: Aufbau des PCAN-PCI Adapters Nachdem die Initialisierung des PITA abgeschlossen ist, kann über Memory-Mapped I/O transparent auf die CAN-Kontroller durch Lesen und Schreiben von Speicherbereichen zugegriffen werden. Peak-System bietet für Linux und Windows einen Treiber für den PCAN-PCI Adapter an, die Quellen des Linux-Treibers stehen unter der GPL. 33

48 4 Entwicklung eines CAN-Treibers für RTAI 4.3 Realtime CAN for Linux/RTAI Rtcan ist ein Framework zur CAN-Kommunikation unter RTAI. Es wird in Form eines Kernel-Moduls in das System eingebunden. Das Framework ist darauf ausgelegt eine einfache Portierung zwischen unterschiedlichen Plattformen sowie eine einfache Ergänzung der unterstützten Hardware zu ermöglichen Hardware-Abstraktions-Schicht Dies wird über eine Hardware-Abstraktions-Schicht (HAL) realisiert. Die Datenstruktur rtcan hal bildet den Kern dieser Schicht, sie beschreibt eine für CAN-Treiber allgemeine Liste von Funktionen wie zum Beispiel die Initialisierung der Hardware oder das Lesen und Schreiben von Nachrichten. Beim Hinzufügen einer neuen Hardware muss für diese Liste von Funktionen eine auf die jeweilige Hardware angepasste Implementierung erstellt werden. Die Hardware-spezifischen Funktionen werden über Zeiger mit der abstrakten Funktion verknüpft, die gesamte Ablaufsteuerung von Rtcan basiert auf der Verwendung der abstrakten Funktionen. Neben der Abstraktion der Funktionsaufrufe liefert das Rtcan Framework eine Struktur zur Modellierung von CAN-Hardware. Jede Hardware (rtcan hw) kann über mehrere Chips (rtcan chip) verfügen, jeder Chip kann mehrere logische Geräte (rtcan device) zur Verfügung stellen Funktionsweise Nachdem die Hardware initialisiert ist, werden zwei Echtzeittasks gestartet. Der erste Task dient zum Schreiben von Nachrichten aus einer fest codierten Liste, der zweite Task gibt gelesene Nachrichten auf der Kernel-Konsole aus. Die Nachrichten werden in zwei Ringpuffern zwischengespeichert. Schnittstellen zur Interprozesskommunikation sind nicht vorhanden. Eine Rückfrage beim Entwickler von Rtcan ergab, dass in der ursprünglichen Applikation eine Kommunikation über Shared Memory verwendet wurde. Dieser Teil wurde allerdings nicht veröffentlicht Unterstützte Hardware Die unterstützte Hardware von Rtcan beschränkt sich auf ein Modul vom Typ TQM8XXL von TQ Systems auf einer Motorola MPC8xx Plattform. Als CAN-Kontroller verwendet dieses Modul einen von Intel. In den Quellen von Rtcan befinden sich angefangene Implementierungen für weitere Hardware, diese sind allerdings nicht funktionsfähig. 34

49 4.3.4 Wichtige Dateien 4.4 Entwicklung der Anpassung für den PCAN-PCI Adapter Die folgenden Dateien gehören zum Kern von Rtcan und werden unabhängig von der eingesetzten Hardware benötigt: main.c Enthält die Einstiegspunkte des Kernel-Moduls. hal-chipcommon.h Enthält die Deklaration der Liste von abstrakten Funktionen. rtcan.h Enthält die Deklarationen weiterer Datenstrukturen des HAL. canhardware.h Enthält Hardware-spezifische Informationen für alle unterstützten Geräte. deviceinit.c Enthält die Ablaufsteuerung für die Initialisierung der Hardware Projektstatus Bis zur Wiederaufnahme des Projekts im Rahmen dieser Arbeit hat seit dem Jahr 2003 keine Weiterentwicklung stattgefunden. 4.4 Entwicklung der Anpassung für den PCAN-PCI Adapter Wahl des Rahmens Am Anfang der Entwicklung standen als Möglichkeiten die Entwicklung eines unabhängigen Treibers auf Basis der Standard-API von RTAI, die Entwicklung eines unabhängigen Treibers unter dem seit RTAI 3.3 vorhandenen Real-Time Driver Model (RTDM), sowie die Entwicklung eines Treibers im Rahmen des Rtcan Frameworks zur Wahl. Da bei Beginn der Arbeit im November 2005 das RTDM nur in Entwicklerversionen von RTAI vorhanden war, ist die Entscheidung auf eine Entwicklung im Rahmen des Rtcan Frameworks gefallen. Im Vergleich zur Entwicklung eines komplett neuen Treibers versprach dies außerdem eine Zeitersparnis durch bereits vorhandene Strukturen Einschränkungen und Probleme von Rtcan Während der Entwicklung sind einige Einschränkungen und Probleme von Rtcan zum Vorschein gekommen. Diese konzeptionellen Probleme sind größtenteils auf Eigenschaften der bisher unterstützten Hardware zurückzuführen. 35

50 4 Entwicklung eines CAN-Treibers für RTAI Eine chronologische Liste der aufgetretenen Probleme beschreibt die Probleme mit ihrer Lösung. Unterstützte Kernel-Version Rtcan wurde für RTAI 24.x auf einem Linux-Kernel der Reihe 2.4 entwickelt. Zur Verwendung unter RTAI 3.x mit einem Linux Kernel der Reihe 2.6 muss Makefile aktualisiert werden. Unvollständige Abstraktion Einige Hardware-spezifisch benannte Variablen werden für eine verbesserte Durchsetzung der Abstraktion umbenannt. Fehlende Unterstützung für den PCI-Bus Die bisher unterstützte Hardware wird über den ISA-Bus angebunden, der Interrupt sowie die Basisadresse dieser Hardware sind in Konstanten hinterlegt. Als Lösung wird die Erkennung von PCI-Geräten mit nicht vorbestimmtem Interrupt und nicht vorbestimmter Basisadresse implementiert. Die dazu benötigte Funktionalität wird vom Linux-Kernel bereitgestellt. Nachrichtenfilter des Intel Der CAN-Kontroller von Intel verfügt intern über 15 Nachrichtenlisten. Die ersten 14 Listen können auf einen bestimmten Objektidentifier eingehender Nachrichten konfiguriert werden, alle davon nicht erfassten Nachrichten werden in die 15. Liste eingeordnet. Auf der Seite von Rtcan sind dazu spezielle Funktionen und Datenstrukturen zur Konfiguration sowie zum Auslesen dieser Listen vorhanden. Da der SJA1000 im Vergleich dazu nur die letzte empfangene Nachricht in seinen Registern bereitstellt, müssen über Präprozessor-Anweisungen einige Abschnitte des Quellcodes bei der Verwendung eines SJA1000 ausgeblendet werden. Globale Ringpuffer Zur Zuordnung einer Nachricht auf einen der beiden Kanäle werden anstatt eines globalen Ringpuffers für eingehende Nachrichten sowie eines globalen Ringpuffers für ausgehende Nachrichten nach der Überarbeitung pro Chip extra Ringpuffer geführt. 36

51 4.4 Entwicklung der Anpassung für den PCAN-PCI Adapter Fehlender Zeitstempel Die Datenstruktur für CAN Nachrichten wird um einen Zeitstempel erweitert. Dieser Zeitstempel wird beim Einlesen einer Nachricht vom CAN-Kontroller vergeben. Fehlende Benutzerschnittstelle Wie bereits erwähnt, bietet das Rtcan Framework keine Schnittstellen zur Kommunikation mit dem Treiber an. Als Lösung wird eine API zum Senden und Empfangen von Nachrichten implementiert. Die Vorgehensweise bei der Entwicklung sowie die Umsetzung wird in einem späteren Abschnitt dieses Kapitels erläutert [4.4.4] Hardware-spezifische Anpassungen Die Hardware-spezifischen Anpassungen lassen sich in zwei Abschnitte unterteilen. Der erste Abschnitt ist die Implementierung des SJA1000 CAN-Kontrollers, der zweite Teil die Anpassung für den PCAN-PCI Adapter. Diese Aufteilung bietet den Vorteil, dass bei der Entwicklung eines Treibers für eine andere Hardware mit dem SJA1000 CAN-Kontroller der erste Teil übernommen werden kann. Die Grundidee bei der Entwicklung von Treibern für RTAI ist die Implementierung der nicht-zeitkritischen Inititalisierung über den Linux-Kernel, für den zeitkritischen Betrieb wird danach auf harte Echtzeit unter RTAI umgestellt. Dies ermöglicht eine gute Orientierung an dem vorhandenen Linux-Treiber für den PCAN-PCI Adapter von Peak-System. Bei der Initialisierung der Hardware werden zunächst der Interrupt und die Basisadresse ermittelt. Im nächsten Schritt werden der PITA sowie die beiden CAN-Kontroller in den Speicherbereich der CPU eingeblendet. Alle weiteren Schritten basieren auf dem Lesen und Schreiben von den Registern des PITA sowie der CAN-Kontroller über die eingeblendeten Speicherbereiche (Memory-Mapped I/O). Eine Beschreibung der Register befindet sich in den Spezifikationen des SJA1000 bzw. des PSB4600. Für den Interrupt des PSB4600 wird ein Interrupthandler eingerichtet. Bei einer Auslösung des Interrupts wird über die Einträge in den Registern des PSB4600 der auslösende SJA1000 bestimmt. Über das Interrupt-Status-Register des SJA1000 kann zwischen verschiedenen Zuständen wie einer eingehenden Nachricht oder einem Fehler auf dem CAN-Bus unterschieden werden. Falls der Interrupt von einer eingehenden Nachricht ausgelöst wurde, wird der betreffende CAN-Controller ausgelesen. Beim Beginn der Ausleseroutine wird ein Timestamp vergeben, die empfangenen Nachrichten werden in den bereits vorhandenen Ringpuffer gelegt. Bei der Signalisierung eines Überlaufs im CAN-Controller wird der Überlauf über das Setzen eines Registers aufgelöst. Ein Fehler auf dem Bus wird in der Kernel-Logfile zur 37

52 4 Entwicklung eines CAN-Treibers für RTAI Nachforschung bei der Fehlerbehebung protokolliert. Aufgrund der gemeinsamen Nutzung von Interrupts durch mehrere Geräte kann der Interrupthandler aufgerufen werden, obwohl keiner der beiden CAN-Controller diesen ausgelöst hat. In diesem Fall wird der Interrupt an den Linux-Kernel weitergereicht. Da der Interrupthandler im Kontext von RTAI registriert wurde, besitzen die Interrupts eine höhere Priorität als die im Kontext des Linux-Kernels. Die Zugriffe auf den Adressraum der Hardware finden außerhalb des Adeos Nanokernels statt, weshalb dazu auch im zeitkritischen Betrieb Systemaufrufe von Linux verwendet werden Entwicklung einer Benutzerschnittstelle Anforderungen Folgende Anforderungen werden an die zu entwickelnde Benutzerschnittstelle gestellt: Senden und Empfangen von CAN Nachrichten Zugriff aus RT Anwendungen im Kernelspace möglich Zugriff aus LXRT Anwendungen im Userspace möglich gleichzeitige Nutzung durch mehrere RT Tasks möglich Eingrenzung der zu empfangenden Nachrichten über den Objektidentifier nach RT Task getrennt möglich Bereitstellung der Schnittstelle für andere Tasks Ein klassischer Ansatz für den Datenaustausch zwischen Prozessen in Kernel- und Userspace ist die Verwendung von Shared Memory. Aufgrund der aufwendigen Synchronisation ist dieser Ansatz im Vergleich zum verwendeten Ansatz nicht konkurrenzfähig. Das von Linux bekannte Konzept der Verwendung von Dateioperationen auf Gerätedateien ist für einen schnellen Datenaustausch ebenfalls nicht geeignet. Die folgenden vier Funktionen werden implementiert: Aufbau einer Verbindung zum CAN-Treiber Versenden einer Nachricht über den CAN-Treiber Empfangen einer Nachricht vom CAN-Treiber Abbau der Verbindung mit dem CAN-Treiber Innerhalb des Kernelspace werden diese Funktionen als Symbole exportiert und damit anderen Modulen bereitgestellt, zur Verwendung aus dem Userspace wird der LXRT um diese Funktionen erweitert. 38

53 4.4 Entwicklung der Anpassung für den PCAN-PCI Adapter Funktionsweise Für alle Ringpuffer wurde das bestehende Konzept zur Verwaltung von Rtcan übernommen. Dieses Konzept sieht eine dynamische Speicherbelegung des durch RTAI beim Start vorreservierten Speicherbereichs vor. Da die aufwendige Reservierung des Speichers durch mmap() hier bereits erfolgt ist, wird diese Speicherverwaltung als echtzeitfähig angesehen. Bei der Anmeldung am CAN-Treiber müssen der Kanal gewählt sowie der Bereich der zu empfangenden Nachrichten bestimmt werden. Die Anzahl der gleichzeitigen Verbindungen ist auf 10 begrenzt, bei einer erfolgreichen Anfrage wird ein eindeutiger Bezeichner für die Verbindung zurückgeliefert. Falls alle Plätze belegt sind, wird dem Aufrufer der Wert -1 zurückgeliefert. Aufgrund des frei wählbaren Bereiches an empfangenden Nachrichten wird für jede Verbindung ein separater Ringpuffer für eingehende Nachrichten vom CAN-Bus geführt. Beim Versenden einer Nachricht wird zur Zuordnung der Verbindung der Verbindungsbezeichner sowie ein Zeiger auf die Nachricht übergeben. Die Nachricht wird in den Speicherbereich des CAN-Treibers kopiert und anschließend in den pro Chip vorhandenen Ringpuffer für ausgehende Nachrichten eingefügt. Eine Sortierung nach Nachrichten-Prioritäten findet aufgrund der kurzen Periode des Tasks zum Versand der Nachrichten nicht statt, der Ringpuffer wird nach dem First In - First Out Prinzip abgearbeitet. Zum Auslesen des pro Verbindung exklusiven Ringpuffers für eingehende Nachrichten werden der Verbindungsbezeichner sowie ein Zeiger auf einen Speicherbereich im Adressraum des Benutzers übergeben. Der Zugriff ist nicht-blockierend, bei einem Rückgabewert von 0 wurde eine Nachricht in den angegebenen Speicherbereich kopiert. Falls keine Nachricht vorhanden war, wird -1 zurückgeliefert. Beim Abbau der Verbindung wird der zur Verbindung gehörende Ringpuffer aufgelöst. Schutz der Ringpuffer Die Verwaltung der Ringpuffer erfordert mehrere Operationen. Auf die pro Chip vorhandenen Ringpuffer wird sowohl aus dem nicht-unterbrechbaren Interrupthandler sowie aus den unterbrechbaren Tasks zur Übergabe der Nachrichten auf die Benutzerschnittstelle zugegriffen. Die Benutzerschnittstelle ist reentrant, womit es zu Race Conditions [AR02] bei den zur Benutzerschnittstelle gehörenden Ringpuffern kommen kann. Zur Vermeidung dieser Probleme werden die kritischen Abschnitte der Operationen zur Verwaltung der Ringpuffer in unterbrechbaren Bereichen durch Semaphoren und das Deaktivieren von Interrupts geschützt. Unmittelbar nach der Zugangsberechtigung in den kritischen Abschnitt durch die Semaphore werden die Interrupt-Flags gespeichert und das Interrupt-Enable Flag gelöscht. Vor dem engültigen Verlassen des kritischen Abschnitts werden die Interrupt-Flags wieder hergestellt, Interrupts sind wieder aktiviert. 39

54 4 Entwicklung eines CAN-Treibers für RTAI Fehlerbehandlung Es können drei Fehlerklassen mit unterschiedlichen Härten identifiziert werden. Überlauf der Ringpuffer Da die Ringpuffer nur eine begrenzte Anzahl von Elementen aufnehmen können, kann es bei einer zu hohen Asynchronität zwischen Erzeuger und Verbraucher zu einem Überlauf kommen. Bei einem Überlauf kommt es durch das Überschreiben von noch nicht abgeholten Daten zu einem Datenverlust. Zur Behebung kann die Größe der Ringpuffer erhöht werden, oft ist dieses Problem allerdings durch einen zu langsamen auslesenden Task bedingt. Dieser Fehler hat keine Auswirkungen auf die Stabilität des Gesamtsystems. Entzogene Sendeberechtigung Beim Auftreten bestimmter Fehler auf dem CAN-Bus kann dem Teilnehmer die Sendeberechtigung entzogen werden, er befindet sich dann im Bus-Off Modus. Dieser Status wird regelmäßig überprüft und bei der Erkennung durch einen Reset behoben. Dieser Fehler hat ebenso keine Auswirkungen auf die Stabilität des Gesamtsystems. Speicherfehler im Kernelspace Aufgrund des nicht vorhandenen Speicherschutzmechanismus im Kernelspace können Zugriffe auf ungültige Speicherbereiche zu einem Absturz des CAN-Treibers oder zu einem Absturz des Gesamtsystems führen. Zur Vermeidung dieser sehr kritischen Problematik wird jede Speicherzuweisung vom Entwickler über den Rückgabewert von rt malloc() auf ihre Gültigkeit überprüft. Die konsequente Überprüfung des Quellcodes auf die Freigabe nicht mehr benötigter Speicherbereiche soll eine Blockierung des Treibers durch keinen weiteren verfügbaren Speicher vermeiden Einschränkungen Fehlende Unterstützung für Remote-Frames Über einen Remote-Frame kann ein Teilnehmer am CAN-Bus einen anderen Teilnehmer zum Senden einer Nachricht auffordern. Aufgrund der fehlenden Anwendung wird eine Unterstützung für Remote-Frames nicht implementiert. 40

55 4.5 Socket-basierter CAN-Treiber Installation und Verwendung Die Installation und Verwendung des CAN-Treibers werden im Anhang dieser Arbeit kurz beschrieben. 4.5 Socket-basierter CAN-Treiber Im Rahmen einer Diplomarbeit am Lehrstuhl für Systems Engineering der Universität Hannover wurde ein Socket-basierter CAN-Treiber für RTAI entwickelt. Der im März 2006 veröffentlichte Treiber unterstützt die CAN-Karten PHYTEC enet und Advantech PCM3680 CAN, die beide einen SJA1000 als CAN-Kontroller verwenden. Als Entwicklungsrahmen wurde das Real-Time Driver Model (RTDM) eingesetzt. Das Ziel der Arbeit war der Beweis eines Konzeptes zur Socket-basierten CAN-Kommunikation. Dies steht in Verbindung mit dem Low Level CAN Framework (LLCF), das an einer einheitlichen Socket-basierten CAN-Unterstützung für den Linux-Kernel arbeitet. 41

56 5 Messungen zur Beurteilung des Echtzeitverhaltens 5.1 Einführung Zur Beurteilung des Echtzeitverhaltens der vorgestellten Ansätze werden Messungen durchgeführt. Um einen möglichst nahen Bezug zu einer möglichen späteren Applikation zu erlangen, werden die Messungen auf dem CAN-Bus durchgeführt. 5.2 Ziel der Messungen Die Ergebnisse der Messungen sollen die folgenden Fragen klären: Welche Zeitgenauigkeit liefert die Echtzeiterweiterung RTAI? Wie groß ist der Unterschied zwischen Echtzeit im Kernelspace und im Userspace (LXRT)? Wird RTAI von einer hohen CPU- bzw. Bus-Last in der Linux-Domäne beeinflußt? Kann Linux mit den beschriebenen Strategien in diesem Umfeld mithalten? Welche Veränderung in der Zeitgenauigkeit ergibt sich durch den Einsatz eines Preemption Patches? Kann ein hochlastiger Prozess mit dynamischer Priorität einen Prozess mit statischer Priorität beeinflussen? Wie reagiert Linux unter Last? 5.3 Versuchsaufbau Zur Klärung dieser Fragen werden Messungen auf dem CAN-Bus durchgeführt. Dazu wird die Kommunikation zwischen der zu testenden Konfiguration und einem zweiten Teilnehmer von einem CAN Datenlogger protokolliert. 42

57 5.3 Versuchsaufbau Die Funktion des zweiten Teilnehmers hängt vom Testszenario ab und wird daher erst im Kontext der Testszenarien genauer beschrieben CAN Datenlogger Der Car Communication Observer der Condalo GmbH kann zur simultanen Überwachung von bis zu fünf CAN-Datenströmen und einem MOST-Datenstrom in Echtzeit eingesetzt werden. Die Daten werden auf der internen Festplatte gespeichert und können am Ende der Messung per USB auf einen Computer übertragen werden. Auszug eines Kommunikationprotokolls base hex timestamps absolute internal events logged Rx d B7 F A Rx d B7 F5 00 BA Rx d B7 F5 00 FB B4 Der integrierte Controller-Kern des Datenloggers ist auf einem FPGA realisiert. Dieser wird von einem externen Quartz getaktet. Für jeden CAN-Kanal steht ein Philips SJA1000 CAN-Controller zur Verfügung. Die CAN-Controller werden mit einer Periode von 1 µs abgefragt. Durch das Auslesen entsteht eine Verzögerung von 1 µs, die Übertragung und Verarbeitung einer Nachricht nimmt 12 µs pro Kanal in Anspruch. Bei der Verwendung von nur einem CAN-Kanal liefert der Datenlogger somit eine Genauigkeit von 1 µs bei einer statischen Verzögerung von 13 µs 1) Testsysteme Linux-PC Alle Konfigurationen von Linux und RTAI werden auf einem Rechner von Fujitsu-Siemens ausgeführt. Dieser Rechner verfügt über einen mit 2,8 GHz getakteten Intel Pentium 4 mit Hyper- Threading Technologie und 512 MB Arbeitsspeicher. Zur CAN-Kommunikation ist ein PCAN-PCI Adapter eingebaut. Zur Taktgenerierung stehen ein 8254 und der Local APIC zur Verfügung. 1) Alle Zeitangaben basieren auf einem Telefonat mit dem zuständigen Entwickler der Condalo GmbH. 43

58 5 Messungen zur Beurteilung des Echtzeitverhaltens Auf dem Rechner ist Debian GNU/Linux sid/unstable mit Linux-Kernel installiert. Toshiba Laptop mit PCAN-USB Adapter Für Messungen mit dem Windows-Programm PCAN-View von PEAK-System wird ein Toshiba Laptop mit Windows XP und einem PCAN-USB Adapter verwendet. Toshiba Laptop mit Vector Informatik CANcardXL Ein weiterer Toshiba Laptop mit dem Betriebssystem Windows XP und einer Vector Informatik CANcardXL PC-Card wird zum Einsatz von CANoe von Vector Informatik verwendet. Vector Informatik CANister CANister ist ein auf Mikrocontrollern basierendes Gerät mit einer Anbindung an den CAN-Bus. Die im Gerät verwendeten Mikrocontroller Infineon 80C167 und Infineon 80C161 können über das Windows-Programm CANister Configurator programmiert werden Konfigurationen des Linux-PC Alle Konfigurationen des Linux-PC verwenden einen Linux-Kernel mit deaktivierten Energiesparfunktionen. Der Scheduler von Linux wird mit einer Frequenz von 1000 Hz betrieben. Einige grundlegende Systemdienste sind immer aktiviert, die grafische Oberfläche ist nicht gestartet. Konfiguration 1: nicht-preemptibler Linux-Kernel Diese Konfiguration verwendet einen nicht-preemptiblen Linux-Kernel. Der PCAN-PCI Adapter wird über den Linux-Treiber von PEAK-System in das System eingebunden. Die Test-Applikationen werden bei deaktiviertem Paging nach der Strategie SCHED FIFO gescheduled. Konfiguration 2: preemptibler Linux-Kernel Im Vergleich zur Konfiguration 1 wird bei dieser Konfiguration der in den offiziellen Kernel-Quellen mitgelieferte Preemption Patch verwendet. Die Test-Applikationen werden auch hier bei deaktiviertem Paging nach der Strategie SCHED FIFO gescheduled. 44

59 5.3 Versuchsaufbau Konfiguration 3: RTAI Bei dieser Konfiguration wird ebenfalls ein nicht-preemptibler Linux-Kernel eingesetzt. Der PCAN-PCI Adapter wird über den im Rahmen dieser Arbeit erweiterten Rtcan- Treiber eingebunden. Die Test-Applikationen werden als RT-Tasks im Kernelspace ausgeführt. Konfiguration 4: LXRT Im Vergleich zur Konfiguration 3 werden die Tests in dieser Konfiguration als LXRT Anwendungen mit harter Echtzeit (rt make hard real time()) im Userspace ausgeführt Lastgeneratoren Unter Linux werden zwei Arten von Lastgeneratoren eingesetzt. Zur Generierung einer fast vollständigen Prozessorauslastung wird eine Endlosschleife als Prozess mit einer dynamischen Priorität ausgeführt. Über diesen Lastgenerator soll die Beeinträchtigung von kritischen Prozessen durch im Hintergrund laufende Systemdienste oder die für eine Visualisierung unter Linux verwendete grafische Oberfläche simuliert werden. Da diese Dienste bzw. die grafische Oberfläche immer als Prozesse mit einer dynamischen Priorität gestartet werden, wird auch der Lastgenerator mit einer dynamischen Priorität ausgeführt. Lastgenerator zur Erzeugung von CPU-Last in C-Code #include <stdio.h> int main() { int i; while(1) { i++; } return 0; } Der zweite Lastgenerator wird zur Erzeugung einer hohen Buslast verwendet. Dazu werden über das Netzwerk Daten von einem anderen Rechner geladen, komprimiert und auf der Festplatte gespeichert. Zur Erhöhung des Interrupt-Aufkommens wird der DMA-Modus der Festplatte deaktiviert. Ein hohes Interrupt-Aufkommen führt zu einer großen Anzahl von Kontextwechseln durch die Unterbrechungen. 45

60 5 Messungen zur Beurteilung des Echtzeitverhaltens Ohne den Lastgenerator kann mit dem Tool mpstat ein Interrupt-Aufkommen von knapp über 1000 Interrupts pro Sekunde gemessen werden. Bei einem Scheduler-Takt von 1000 Hz und den damit verbundenen 1000 Auslösungen des Zeitgebers pro Sekunde entspricht dies einem unbelasteten System. Nach der Deaktivierung des DMA-Modus der Festplatte und dem Starten des Lastgenerators pendelt sich ein Wert von etwa 8000 Interrupts pro Sekunde ein. Es ist zu beachten, dass die Deaktivierung des DMA-Modus der Festplatte neben der Auswirkung auf das Interrupt-Aufkommen eine weitere Auswirkung auf die Interrupt-Latenzzeit [2.2.2] haben kann. Es ist zu beachten, dass diese Zahlen nur das Interrupt-Aufkommen aus Sicht des Linux- Kernels beinhalten. Dieser wird bei Konfigurationen mit mehreren Domänen in der Interrupt Pipeline nicht über alle Interrupts benachrichtigt. 5.4 Testszenarien Bei jedem Testszenario wird vorausgesetzt, dass der CAN-Bus exklusiv für den Test zur Verfügung steht. Als Datenübertragungsrate auf dem CAN-Bus werden 500 KBit s 1 verwendet Szenario 1: Periodisches Senden einer CAN-Nachricht Anhand dieses Szenarios soll ermittelt werden mit welcher Genauigkeit und mit welchen maximalen Abweichungen das zu testende System periodische Aufträge erledigt. Das zu testende System sendet dem zweiten Teilnehmer im Abstand von 1 ms eine CAN- Nachricht zu. Diese Kommunikation wird vom Datenlogger protokolliert. Der zweite Teilnehmer bestätigt den Empfang der Nachrichten auf Busebene, der Datenlogger sendet keine Empfangsbestätigungen aus. Aufgrund der damit verbundenen erweiterten Möglichkeiten der Testüberwachung wird als zweiter Teilnehmer der Laptop mit CANoe verwendet Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten Als Erweiterung von Szenario 1 werden hier fünf parallele Tasks zum Versand von CAN- Nachrichten gestartet. Die Tasks versenden mit einer Periodendauer von 10 ms, 15 ms, 20 ms, 40 ms und 50 ms jeweils eine CAN-Nachricht. Die Nachrichten der unterschiedlichen Tasks werden durch ihren Objektidentifier priorisiert. Der Task mit der kleinsten Periode versendet die Nachrichten mit dem kleinsten Identifier. 46

61 5.5 Testdurchführung Szenario 3: Messung der Reaktionszeit über den CAN-Bus Zum Test der Reaktionszeit wird CANoe zum Versand von CAN-Nachrichten mit einer Periode von 10 ms konfiguriert. Das zu testende System pollt mit einer Periode von 100 µs auf neue Nachrichten und sendet beim Empfang einer Nachricht unmittelbar eine Antwort zurück. Der Datenlogger protokolliert diese Kommunikation. 5.5 Testdurchführung Es werden insgesamt 31 Tests durchgeführt, davon 15 von Szenario 1, vier von Szenario 2 und 12 von Szenario 3. Die Laufzeit pro Test beträgt 10 Minuten, acht Tests werden aus Zeitgründen nur mit einer Laufzeit von fünf Minuten durchgeführt. Im Anhang dieser Arbeit befindet sich eine Übersicht über alle durchgeführten Tests [B]. 5.6 Auswertung Allgemeine Aufbereitung der Daten Bei der Testdurchführung werden knapp über 400 MB Daten erzeugt. Nach der Testdurchführung steht pro Test eine Protokolldatei zur Verfügung. Diese enthält auf den Startzeitpunkt der Messung bezogene Zeitangaben. Zur Betrachtung eines eingeschwungenen Systems ohne Verfälschungen durch alte gepufferte Daten o.ä. werden die ersten 50 Werte aus jedem Protokoll verworfen. Als nächster Schritt erfolgt bei Tests mit mehreren Sendern die Aufteilung der Protokolldatei der kompletten Kommunikation in eine separate Protokolldatei pro Objektidentifier bzw. Sender. Danach werden bei allen Protokolldateien die für die Zeitauswertung nicht benötigten Daten wie der Objektidentifier und die Länge der Nachricht entfernt. Diese Schritte erfolgen über ein PHP-Skript, die aufbereiteten Daten werden in einem zu Matlab kompatiblen Format gespeichert Periodische Tests Aus den aufbereiteten Daten wird in Matlab die Differenz zwischen den auf den Startpunkt der Messung bezogenen Zeitangaben berechnet. Zur Vergleichbarkeit von Messreihen mit unterschiedlichen Sendeperioden wird zur Normierung von dieser Differenz die jeweilige Sendeperiode abgezogen. Die nun vorliegenden Werte geben pro Nachricht die relative Abweichung vom über die Sendeperiode vorgegebenen zeitlichen Abstand zweier Nachrichten an. 47

62 5 Messungen zur Beurteilung des Echtzeitverhaltens Diese Abweichung vom zeitlichen Soll-Abstand zweier Nachrichten kann positiv oder negativ sein. Sie enthält keine Aussage über die Abweichung zwischen Soll- und Ist-Wert des absoluten Zeitstempels der Nachricht. Da die Abweichung des absoluten Zeitstempels bei einer durchschnittlichen relativen Abweichung größer 0 über eine von der Anzahl der Nachrichten streng monoton steigende Funktion beschrieben wird, ist sie für eine vergleichende Betrachtung nicht geeignet. Feste Latenzzeiten durch die Übertragung über den CAN-Bus und das Auslesen der Werte am Datenlogger sind in dieser Abweichung aufgrund des einheitlichen Messpunktes nicht mehr enthalten. Der Jitter beim Auslesen am Datenlogger sowie zeitliche Schwankungen bei der Übertragung auf dem Medium sind nicht bekannt und können daher nicht exakt berücksichtigt werden. Über alle beteiligte Faktoren außerhalb des zu testenden Systems ist ein Jitter von 2-5 µs zu erwarten. Zur Auswertung der periodischen Tests werden folgende Vergleichsgrößen definiert: Minimale und maximale Abweichung Diese beiden Größen geben die minimale bzw. die maximale Abweichung des relativen Abstands zweier Nachrichten von der Sendeperiode an. Sei t i der absolute Zeitstempel der i-ten Nachricht und p die Periodendauer, so gilt: abw min = min(t i t i 1 p) bzw. abw max = max(t i t i 1 p) Durchschnitt der relativen Abweichungen Der Durchschnitt der relativen Abweichungen ist der Quotient aus der Summe der relativen Abweichungen und der Anzahl der Sendeperioden. Sei t i abw avg = der absolute Zeitstempel der i-ten Nachricht und p die Periodendauer, so gilt: n i=2 t i t i 1 p n Absoluter Durchschnitt der relativen Abweichungen Der absolute Durchschnitt der relativen Abweichungen ist der Quotient aus der Betragssumme der relativen Abweichungen und der Anzahl der Sendeperioden. Bei dieser Größe können sich im Vergleich zum Durchschnitt negative und positive Werte im Mittel nicht eliminieren. Sei t i der absolute Zeitstempel der i-ten Nachricht und p die Periodendauer, so gilt: n i=2 abw absavg = t i t i 1 p n Anhand der Differenz zwischen dem absoluten Durchschnitt und dem Durchschnitt kann eine Aussage über das Sendeverhalten eines Senders getroffen werden. Je höher die Differenz ist, desto unregelmäßiger werden die Nachrichten gesendet. 48

63 5.6 Auswertung Verpasste Perioden Bei einer durchschnittliche Abweichung größer 0 wird nach einem bestimmten Zeitraum eine Periode verpasst. Dieser Zeitraum ist dann erreicht, wenn die Zwischensumme der Abweichungen eine ganze Periode ergibt. Dazu wird der prozentuelle Anteil der verpassten Perioden betrachtet. Zunächst wird die Differenz der Anzahl der empfangenen Nachrichten und der Anzahl der in der erfassten Zeitspanne möglichen Nachrichten berechnet. Diese wird durch die Anzahl der möglichen Nachrichten dividiert Reaktionstests Zur Auswertung der Reaktionstests wird in Matlab für jedes Paar aus Anfrage und Antwort die Differenz berechnet. Dieser Wert entspricht somit der Reaktionszeit. Da sowohl die Anfrage als auch die Antwort aufgrund der Verzögerung im Datenlogger einen um ca. 13 µs verspäteten Zeitstempel erhalten, werden die vom Datenlogger bedingten festen Latenzen eliminiert. Die Latenzzeit auf dem Medium ist nicht bekannt und kann daher nicht berücksichtigt werden. Es ist von einer durch die Übertragung bedingten Latenzzeit von µs zu rechnen. Der Jitter bei der Erfassung am Datenlogger ist nicht bekannt und liegt schätzungsweise im Bereich von 1-2 µs. Zur Auswertung der Reaktionstests werden folgende Vergleichsgrößen verwendet: Minimale und maximale Reaktionszeit Diese beiden Größen geben die minimale bzw. die maximale Reaktionszeit an. Sei t i das Ergebnis der i-ten Reaktionsmessung, so gilt: r min = min(t i ) bzw. r max = max(t i ) Durchschnittliche Reaktionszeit Die durchschnittliche Reaktionszeit ist der Quotient aus der Summe aller Reaktionszeiten und der Anzahl der Tests. Sei t i das Ergebnis der i-ten Reaktionsmessung, so gilt: r avg = n i=1 t i n 49

64 5 Messungen zur Beurteilung des Echtzeitverhaltens 5.7 Ergebnisse Szenario 1: Periodisches Senden einer CAN-Nachricht Das Ziel bei diesem Szenario ist die möglichst genaue Einhaltung der geforderter Periode bei möglichst geringen statistischen Schwankungen in der Abweichung von der Periode. Bei der Betrachtung des Worst-Case anhand der maximalen Abweichung von der Zeitvorgabe kann folgende vereinfachte Reihenfolge aufgestellt werden. Die prozentuale Steigerung der maximalen Abweichung bezieht sich immer auf den Wert aus der obersten Zeile. Für eine verbesserte Übersichtlichkeit sind die Werte gerundet. System/Konfiguration Max. Abw. proz. Steigerung RTAI / LXRT, ohne Last/Lastgen. 1/Lastgen µs CANister 870 µs +120 % Linux, nicht-preemptiv, ohne Last/Lastgen. 1 6 ms % PCAN-View 7 ms % CANoe 14 ms % Linux, preemptiv, ohne Last/Lastgen ms % Linux mit Lastgen ms % Tabelle 5.1: Maximale Abweichung von der Periode von 1 ms Von den relevanten Möglichkeiten liefern nur RTAI und der LXRT eine maximalen Abweichung unter 1 ms. Auffällig ist der hohe Unterschied zwischen dem nicht-preemptiven und dem preemptiven Linux-Kernel. Dieser kann zunächst nicht erklärt werden. Gemäß den Protokollen der während der Tests durchgeführten Systemüberwachung 2) waren die Testbedingungen bei beiden Kerneln zu jeder Zeit gleich. Anhand der Unabhängigkeit der maximalen Abweichungen von der Prozessorbelastung bei den Tests mit Linux kann gezeigt werden, dass der zum Senden verwendete Prozess mit einer statischen Scheduler-Priorität dem mit einer dynamischen Priorität versehenen Lastgenerator über die gesamte Testdauer überlegen ist. Durch die Buslast von Lastgenerator 2 steigt die maximale Abweichung bei den Tests mit Linux hingegen deutlich an. Dies zeigt, dass Interrupt-Routinen eine höhere Priorität als Benutzerprozesse mit einer statischen Scheduler-Priorität haben. Es ist weiterhin sichtbar, dass RTAI und der LXRT von beiden unter Linux ausgeführten Lastgeneratoren nicht beeinflußt werden. Dieses Verhalten kann über die Funktionsweise der Interrupt Pipeline erklärt werden. Im nächsten Schritt wird die gemittelte durchschnittliche Abweichung von der Periode von 1 msbetrachtet: 2) Diese Protokolle wurden mit mpstat erstellt und befinden sich auf der CD-ROM. 50

65 System/Konfiguration durchschn. Abw. verpasste Perioden CANister PCANView 0 µs 0,00 % CANoe RTAI 1 µs 0,1 % LXRT 2 µs 0,2 % Linux 2 ms 67 % Tabelle 5.2: Durchschnittliche Abweichung von der Periode von 1 ms 5.7 Ergebnisse Die mit 3 ms um 200 % erhöhte durchschnittliche Periodendauer bei den Tests mit Linux ist auf die Zeitgranularität des Schedulers von Linux zurückzuführen. Bei der verwendeten Scheduler-Frequenz von 1000 Hz wird nach jedem Ablauf von 1 ms der Prozessor für 1 ms einem Prozess zugeteilt. Damit ein bestimmter Prozess nach jeder Millisekunde eine Nachricht versenden kann, müsste er demnach bei jeder Entscheidung des Scheduler den Zuschlag erhalten. Dies widerspricht dem Ansatz der fairen Ressourcenverteilung und ist somit auch mit priorisierten statischen Scheduler-Prioritäten nicht möglich. Der Vergleich der folgenden beiden Histogramme verdeutlicht dies. Während RTAI verspätete Nachrichten durch vorzeitig abgesendete Nachrichten ausgleicht, sind bei Linux alle Nachrichten um etwa 2 ms verzögert. Bild 5.1: Messung 7: RTAI Bild 5.2: Messung 15: Linux Die Differenz von 1 µs zwischen der durchschnittlichen Abweichung von RTAI und LXRT kann durch den beim LXRT bei der Kommunikation zwischen Userspace und Kernelspace entstehenden Overhead begründet sein. Der Vergleich zwischen der durchschnittlichen Abweichung und der absoluten durchschnittlichen Abweichung deutet beim Test mit PCAN-View auf ein sehr stark schwankendes Sendeverhalten hin. Das folgende Histogramm verdeutlicht, dass PCAN-View durch schubweises vorzeitiges Versenden die sehr gute durchschnittliche Abweichung von 0 µs erreicht. 51

66 5 Messungen zur Beurteilung des Echtzeitverhaltens Bild 5.3: Messung 11: PCAN-View Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten In der folgenden Tabelle sind die maximale Abweichung aus Szenario 1 sowie die größte und kleinste maximale Abweichung aus Szenario 2 für die getesteten Systeme dargestellt. Die größte und kleinste maximale Abweichung ergibt sich aus den Werten der fünf parallelen Tasks. System/Konfiguration Szenario 1 min. Szenario 2 max. Szenario 2 Linux, nicht-preemptiv 5,9 ms 3,0 ms 3,5 ms Linux, preemptiv 30,0 ms 6,9 ms 28,9 ms RTAI 326 µs 20,3 ms 1,7 s LXRT 447 µs 45,3 ms 4,12 s Tabelle 5.3: Vergleich der maximalen Abweichung über Szenario 1 & 2 Die erste Beobachtung zeigt, dass Linux sich durch die wesentlich längeren Periodendauern in diesem Szenario verbessern konnte. Gleichzeitig haben sich RTAI und der LXRT bis um den Faktor verschlechtert. Die größten Werte stammen von den Sendetasks mit der jeweils längsten Periodendauer. Diese haben die niedrigste Priorität im Scheduler und auf dem CAN-Bus. Da alle Tasks zwar parallel, aber über die selbe Hardware ihre Nachrichten versenden, hat die Arbitrierung des CAN-Busses hier keine Auswirkungen. Eine mögliche Quelle der Abweichungen kann eine ungünstige Wartesituation bei der Zuteilung des Schreibzugriffs auf den Ringpuffer für ausgehende Nachrichten im CAN- Treiber sein. Die zweite Möglichkeit ist eine ungünstige Verteilung der Task-Prioritäten. Anhand der vorhandenen Messdaten kann die Ursache nicht geklärt werden. Die durchschnittliche Abweichung von der Periode aus Szenario 1 sowie die größte 52

67 5.7 Ergebnisse und kleinste durchschnittliche Abweichung aus Szenario 2 werden in dieser Tabelle gegenübergestellt: System/Konfiguration Szenario 1 min. Szenario 2 max. Szenario 2 Linux, nicht-preemptiv 2,0 ms 2,0 ms 2,0 ms Linux, preemptiv 2,0 ms 2,0 ms 2,0 ms RTAI 1 µs 160 µs 1,73 ms LXRT 2 µs 168 µs 3,6 ms Tabelle 5.4: Vergleich der durchschnittlichen Abweichung über Szenario 1 & 2 Während Linux die durchschnittliche Abweichung auch bei fünf parallelen sendenden Tasks unverändert halten kann, verschlechtern sich RTAI und der LXRT sehr stark. Dies deutet auf erhöhte Kosten durch die nun hinzugekommen Kontextwechsel sowie eine fehlende Fairness bei der Bedienung niederpriorer Tasks hin. Das Histogramm des niederpriorsten Tasks zeigt im Vergleich zum Histogramm des höchstpriorsten Tasks aus dem Test mit dem LXRT eine sehr breite Streuung der Werte: Bild 5.4: Messung 4: LXRT, höchstpriorer Task Bild 5.5: Messung 4: LXRT, niedrigstpriorer Task Szenario 3: Messung der Reaktionszeit über den CAN-Bus Bei der Messung der Reaktionszeit ist vor allem die maximale Reaktionszeit zur Abschätzung des Worst-Case von Interesse. Da keine eindeutige Verknüpfung zwischen Faktoren wie der Last und der maximalen Reaktionszeit hergestellt werden kann, werden in der folgenden Tabelle der größte und der kleinste Wert der maximalen Reaktionszeit gegenübergestellt: Nach dem selben Schema werden anschließend die durchschnittlichen Reaktionszeiten gegenübergestellt: 53

68 5 Messungen zur Beurteilung des Echtzeitverhaltens System/Konfiguration kleinster Wert größter Wert RTAI/LXRT 603 µs 663 µs Linux, preemptiv und nicht-preemptiv 3,1 ms 9,7 ms Tabelle 5.5: Maximale Reaktionszeit System/Konfiguration kleinster Wert größter Wert RTAI, keine Last 391 µs 391 µs LXRT, keine Last 393 µs 393 µs RTAI/LXRT, Lastgen µs 396 µs RTAI, Lastgen µs 402 µs LXRT, Lastgen µs 404 µs Linux 813 µs 1,1 ms Tabelle 5.6: Durchschnittliche Reaktionszeit Während bei der maximalen Reaktionszeit ein 5-15 facher Unterschied zwischen Linux und RTAI bzw. LXRT vorhanden ist, ist bei der Betrachtung der durchschnittlichen Reaktionszeit nur noch ein Faktor von 2 bis 3 zu erkennen. Die zwei folgenden Histogramme zeigen eine sehr breite Verteilung der Werte bei einer Messung unter Linux und eine sehr enge Verteilung bei einer Messung mit dem LXRT: Bild 5.6: Messung 24: Linux Bild 5.7: Messung 29: LXRT Dieses Beispiel verdeutlich damit grafisch den Unterschied zwischen dem auf den durchschnittlichen Fall ausgelegten Linux und dem auf den Worst-Case ausgelegten RTAI. Zwischen den Messungen unter RTAI und den Messungen unter dem LXRT kann erneut eine kleine Differenz von bis zu 2 µs erkannt werden. 54

69 5.7 Ergebnisse Zusammenfassung RTAI/LXRT Beim periodischen Senden einer Nachricht erreichen RTAI und der LXRT sehr gute Werte sowohl bei der Betrachtung des Worst-Case als auch bei der Betrachtung des allgemeinen Falls. Der Overhead durch die Kommunikation zwischen Kernelspace und Userspace beim LXRT erzeugt eine Verschlechterung der Werte um 1-2 µs. Bei Echtzeitanforderungen im Millisekundenbereich ist diese Verschlechterung vernachlässigbar. Durch den Einsatz mehrerer paralleler Tasks brechen RTAI und der LXRT ein, ein zuverlässiger Betrieb im Millisekundenbereich kann nicht mehr gewährleistet werden. Besonders bei Messungen mit dem LXRT werden sehr hohe Abweichungen gemessen. Eine Beeinträchtigung der Zeitgenauigkeit durch eine Last im durch die Interrupt Pipeline niederpriosierteren Linux kann nicht festgestellt werden. Linux Bei kleinen Periodendauern in der Nähe der Taktfrequenz des Schedulers werden unter Linux sehr hohe Abweichungen von der Zeitvorgabe gemessen. Ein Betrieb im Millisekundenbereich ist nicht möglich. Es kann gezeigt werden, dass Linux mit höheren Periodendauern besser zurecht kommt, ein Betrieb im Millisekundenbereich kann weiterhin nicht garantiert werden. Prozesse mit einer statischen Scheduler-Priorität werden vor hochlastigen Prozessen mit einer dynamischen Priorität geschützt, eine exklusive Nutzung des Prozessors ist nicht möglich. Durch den Einsatz eines preemptiblen Kernels kann in den hier beschriebenen Szenarien keine Verbesserung erzielt werden. Sonstige Systeme Die weiteren getesteten Systeme werden für einen allgemeinen Vergleich zwischen Linuxbasierten Systemen mit anderen Betriebssystemen in die Untersuchung mit einbezogen. Da sie nicht explizit zum Thema dieser Arbeit gehören, wird nur das Szenario 1 auf diesen Systemen getestet. Eine Beurteilung der Ergebnisse findet aufgrund der nicht bekannten Hintergründe nicht statt. 55

70 6 Fazit und Ausblick Die hier vorgestellte Untersuchung betrachtet die konzeptionellen Unterschiede der verwendeten Echtzeitsysteme auf Linux-Basis. Im Vordergrund der Untersuchung steht dabei die Betrachtung des Schedulers. Neben den verfügbaren Strategien ist die Taktfrequenz und die damit verbundene Zeitgranularität ein wichtiges Merkmal. Die weitere Untersuchung umfasst Punkte wie die allgemeine Auslegung des Echtzeitsystems und Maßnahmen zur Vermeidung von Latenzzeiten im Bereich von 100 µs. Auf Strategien zur gezielten Vermeidung von Latenzzeiten im Bereich von unter 10 µs wird nicht eingegangen. Die Erweiterung der Software des seit 2003 nicht mehr gepflegten Projektes Realtime CAN for Linux/RTAI (Rtcan) ermöglicht den Einsatz eines PCAN-PCI Adapters von PEAK-System zur CAN-Kommunikation unter RTAI auf der x86-plattform. Durch die hinzugefügte Benutzerschnittstelle ist der Zugriff auf den CAN-Treiber aus mehreren parallelen RT Tasks möglich. Die durchgeführten Messungen geben einen Applikations-orientierten Überblick über die Zeitgenauigkeit der beschriebenen Ansätze und überprüfen die Relevanz einiger Konzepte, wie dem Preemption Patch von Linux 2.6. Keines der verwendeten Echtzeitsysteme auf Linux-Basis kann in allen Testszenarien eine Zeitgenauigkeit im Millisekundenbereich garantieren. Während diese Ergebnisse für Linux anhand der Theorie nachvollziehbar sind, gibt es für die hohen Abweichungen von der vorgegebenen Periode beim parallelen Einsatz mehrerer Tasks unter RTAI noch keine vollständige Erklärung. Zur Klärung dieses Sachverhalts werden weitere Tests mit auf diese Problematik angepassten Testszenarien benötigt. Neben einer Untersuchung des Skalierverhaltens von RTAI bzw. des LXRT, ist eine Untersuchung auf Verzögerungen zwischen dem Aufruf eines Sendetasks und dem Anliegen der versendeten Nachricht am Bus erforderlich. Neben Testszenarien zur Untersuchung der hohen Abweichungen, sind im nächsten Schritt noch mehr an eine Applikation orientierte Szenarien wie eine Kombination von mehreren sendenden Tasks und gleichzeitigen Reaktionstests denkbar. Der Einsatz von Linux ohne Echtzeiterweiterungen als neuen Echtzeitrahmen ist trotz der jüngsten Weiterentwicklungen von Linux in dieser Richtung nicht empfehlenswert. Die Einsetzbarkeit von RTAI sowie weiteren auf dem Adeos Nanokernel basierenden System wie Xenomai muss in weiteren Untersuchungen überprüft werden. 56

71 A Installation der verwendeten Software Die folgende Beschreibung soll anhand von Stichworten einen kurzen Überblick zu den kritischen Punkten bei der Installation von RTAI und Rtcan geben. Es werden Kenntnisse über das Erstellen eines Linux-Kernels mit einer eigenen Konfiguration vorausgesetzt. Verwendete Versionen RTAI 3.3 von Linux-Kernel sowohl die Quellen von kernel.org als auch die von Debian modifizierten Kernelquellen konnten erfolgreich verwendet werden. GCC 3.3 Wichtig! Mit einer höheren GCC Version ist RTAI nicht kompilierbar. Konfiguration des Kernels Nach dem Auspacken der Quellen müssen die Kernel-Quellen mit einem Patch aus der RTAI Distribution bearbeitet werden. Die Patches befinden sich im Verzeichnis base/arch/i386/patches/. Bei der Konfiguration des Kernels müssen folgende Einstellungen beachtet werden: Loadable Module Support Module versioning support deaktivieren Processor type and features Interrupt Pipeline aktivieren Processor type and features Use register arguments deaktivieren Processor type and features Local APIC support on uniprocessors aktivieren, wenn kein SMP aktiviert ist Es ist außerdem zu empfehlen, dass alle Energiesparfunktionen wie APM und ACPI deaktiviert werden. Der Kernel kann nun übersetzt und eingerichtet werden. Installation von RTAI Bei der Konfiguration von RTAI sind bis auf die korrekte Angabe des Pfades zu den Kernel-Quellen keine Optionen zu beachten. 57

72 A Installation der verwendeten Software Nach der erfolgreichen Installation befindet sich RTAI im Ordner /usr/realtime/ und kann durch das Laden der entsprechenden Kernel-Module gestartet werden. Bei einer entsprechenden Konfiguration der Anwendung werden die benötigten Module beim Start über rtai-load automatisch geladen. rtai-load kümmert sich außerdem auch um das Entladen nicht mehr benötigter Kernel-Module. Die Konfiguration von rtai-load erfolgt über die Datei.runinfo im Programmverzeichnis. Installation von Rtcan Nach der Anpassung der Pfade zu den Quellen des Linux-Kernels sowie den Header- Dateien von RTAI in der Makefile kann Rtcan mit make übersetzt werden. Das enstandene Modul rtcan.ko benötigt die RTAI-Module rtai hal.ko, rtai ksched.ko, rtai shm.ko und rtai sem.ko. Nachdem diese Module geladen sind, kann der Treiber unter Voraussetzung eines im System vorhandenen, noch nicht belegten PCAN-PCI Adapters erfolgreich geladen werden. Zugriff auf die Benutzerschnittstelle von Rtcan Zum Zugriff auf die Benutzerschnittstelle von Rtcan muss in der Anwendung die Datei rtcan.h eingebunden werden. 58

73 B Auflistung aller Testergebnisse In den folgenden drei Tabellen sind die Meßergebnisse aller Messungen aufgelistet. Neben den in [5.6] definierten Vergleichgrößen sind alle weiteren Informationen zum Test wie das getestete System und die Dauer des Tests enthalten. Die Tests sind nach dem angewandeten Szenario gruppiert, innerhalb eines Szenarios wird nach der aufsteigenden laufenden Nummer des Tests sortiert. Bei Szenario 2 wird innerhalb eines Tests zusätzlich aufsteigend nach der Nummer des sendenden Tasks sortiert. Legende lfd. Nr. Dauer System Last alle Szenarien laufende Nummer angesetzte Dauer des Tests reale Testdauer kann um bis zu 30 Sekunden abweichen getestetes System Lastsituation während des Tests. CPU entspricht dem ersten Lastgenerator, Bus entspricht dem zweiten Lastgenerator [5.3.4]. Szenario 1 & 2 n Anzahl der Perioden T Nummer des Tasks bei mehreren Sendern Periodendauern: 10 ms, 15 ms, 20 ms, 40 ms, 50 ms Min minimale Abweichung von der Sendeperiode Max maximale Abweichung von der Sendeperiode Avg Durchschnitt der relativen Abweichungen AbsAvg Absoluter Durchschnitt der relativen Abweichungen VerPer Verpasste Perioden n Min Max Avg Szenario 3 Anzahl der aus Anfrage und Antwort bestehenden Reaktionsmessungen minimale Reaktionszeit maximale Reaktionszeit durchschnittliche Reaktionszeit 59

74 B Auflistung aller Testergebnisse lfd. Nr. Dauer System Last n Min Max Avg AbsAvg VerpPer 1 10 min RTAI , s 0, s 0, s 0, s 0,07 % 3 10 min LXRT , s 0, s 0, s 0, s 0,17 % 5 10 min RTAI Bus , s 0, s 0, s 0, s 0,08 % 6 10 min LXRT CPU , s 0, s 0, s 0, s 0,26 % 7 10 min RTAI CPU , s 0, s 0, s 0, s 0,02 % 8 10 min LXRT CPU , s 0, s 0, s 0, s 0,15 % min PCANView , s 0, s 0, s 0, s 0,00 % min Linux, nicht-preemptibel , s 0, s 0, s 0, s 66,78 % min Linux, nicht-preemptibel Bus , s 0, s 0, s 0, s 66,91 % min Linux, nicht-preemptibel CPU , s 0, s 0, s 0, s 66,77 % min CANister , s 0, s 0, s 0, s 0,00 % min Linux, preemptibel , s 0, s 0, s 0, s 66,84 % min Linux, preemptibel Bus , s 0, s 0, s 0, s 66,94 % min Linux, preemptibel CPU , s 0, s 0, s 0, s 66,82 % min CANoe , s 0, s 0, s 0, s 0,00 % Tabelle B.1: Szenario 1: Periodisches Senden einer CAN-Nachricht 60

75 lfd. Nr. Dauer System Last T n Min Max Avg AbsAvg VerpPer 2 10 min RTAI keine , s 0, s 0, s 0, s 1,57 % 2 10 min RTAI keine , s 0, s 0, s 0, s 3,28 % 2 10 min RTAI keine , s 1, s 0, s 0, s 2,34 % 2 10 min RTAI keine , s 1, s 0, s 0, s 2,10 % 2 10 min RTAI keine , s 1, s 0, s 0, s 3,34 % 4 10 min LXRT keine , s 0, s 0, s 0, s 1,65 % 4 10 min LXRT keine , s 0, s 0, s 0, s 15,29 % 4 10 min LXRT keine , s 2, s 0, s 0, s 15,28 % 4 10 min LXRT keine , s 4, s 0, s 0, s 5,84 % 4 10 min LXRT keine , s 1, s 0, s 0, s 4,01 % min Linux, nicht-preemptibel keine , s 0, s 0, s 0, s 16,75 % min Linux, nicht-preemptibel keine , s 0, s 0, s 0, s 11,82 % min Linux, nicht-preemptibel keine , s 0, s 0, s 0, s 9,13 % min Linux, nicht-preemptibel keine , s 0, s 0, s 0, s 4,78 % min Linux, nicht-preemptibel keine , s 0, s 0, s 0, s 3,85 % min Linux, preemptibel keine , s 0, s 0, s 0, s 16,80 % min Linux, preemptibel keine , s 0, s 0, s 0, s 11,86 % min Linux, preemptibel keine , s 0, s 0, s 0, s 9,16 % min Linux, preemptibel keine , s 0, s 0, s 0, s 4,79 % min Linux, preemptibel keine , s 0, s 0, s 0, s 3,87 % Tabelle B.2: Szenario 2: Paralleles, periodisches Senden mehrerer CAN-Nachrichten 61

76 B Auflistung aller Testergebnisse lfd. Nr. Dauer System Last n Min Max Avg 9 10 min RTAI , s 0, s 0, s min LXRT , s 0, s 0, s min Linux, nicht-preemptibel , s 0, s 0, s min Linux, preemptibel , s 0, s 0, s 23 5 min Linux, preemptibel Bus , s 0, s 0, s 24 5 min Linux, preemptibel CPU , s 0, s 0, s 26 5 min Linux, nicht-preemptibel Bus , s 0, s 0, s 27 5 min Linux, nicht-preemptibel CPU , s 0, s 0, s 28 5 min RTAI Bus , s 0, s 0, s 29 5 min LXRT Bus , s 0, s 0, s 30 5 min LXRT CPU , s 0, s 0, s 31 5 min RTAI CPU , s 0, s 0, s Tabelle B.3: Szenario 3: Messung der Reaktionszeit über den CAN-Bus 62

77 C QT RTcan Display Das während dieser Arbeit entwickelte Programm QT RTcan Display dient als proof-ofconcept für die Visualisierung von Daten aus einem RTAI Task im Kernelspace in einer QT Applikation im Userspace. Die Schnittstelle in Form von zwei RTAI FIFO-Puffern wird vom ebenso entwickelten Kernelmodul rtcan fifo bereitgestellt. Die QT Applikation greift über Gerätedateien wie /dev/rtf1 auf die FIFO-Puffer zu. Der folgende Screenshot zeigt die drei Module von QT RTcan Display. Bild C.1: Screenshot von QT RTcan Display Im ersten Unterfenster in der oberen linken Ecke werden die eingehenden Nachrichten angezeigt. Zur Übersichtlichkeit werden Nachrichten mit dem gleichen Identifier gruppiert. Neben dem Inhalt der letzten empfangenen Nachricht und dem Zeitstempel wird die Anzahl der empfangenen Nachrichten vom gleichen Identifier angezeigt. Im zweiten Unterfenster in der oberen rechten Ecke können vom Benutzer Nachrichten definieren. Bei einem Klick auf die jeweilige Zeile wird die Nachricht verschickt. 63

Echtzeitanforderung und Linux

Echtzeitanforderung und Linux Echtzeitanforderung und Linux Slide 1 - http://www.pengutronix.de - 21.01.2007 Definition Harte Echtzeit I Was zeichnet ein Echtzeitsystem aus? Zeitverhalten ist Teil der System-Spezifikation! Bei Embedded-Systemen

Mehr

CPU-Scheduling - Grundkonzepte

CPU-Scheduling - Grundkonzepte CPU-Scheduling - Grundkonzepte Sommersemester 2015 Seite 1 Gesamtüberblick 1. Einführung in Computersysteme 2. Entwicklung von Betriebssystemen 3. Architekturansätze 4. Interruptverarbeitung in Betriebssystemen

Mehr

Systeme 1. Kapitel 5. Scheduling

Systeme 1. Kapitel 5. Scheduling Systeme 1 Kapitel 5 Scheduling Scheduling Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse Beispiel: -> Zeitablaufsteuerung Zwei Prozesse zur gleichen Zeit rechenbereit auf

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

POSIX Echtzeit: Kernel 2.6 und Preempt-RT

POSIX Echtzeit: Kernel 2.6 und Preempt-RT POSIX Echtzeit: Kernel 2.6 und Preempt-RT Slide 1 - http://www.pengutronix.de - 21.01.2007 Echtzeit-Systemplanung Wenn das zeitliche Verhalten spezifiziert ist, kann auch spezifiziert werden, welche Applikationsteile

Mehr

Betriebssysteme (BTS)

Betriebssysteme (BTS) 9.Vorlesung Betriebssysteme (BTS) Christian Baun cray@unix-ag.uni-kl.de Hochschule Mannheim Fakultät für Informatik Institut für Betriebssysteme 10.5.2007 Exkursion Die Exkursion wird am Freitag, den 18.5.2007

Mehr

2 Echtzeitbetriebssysteme

2 Echtzeitbetriebssysteme 35 2 Echtzeitbetriebssysteme In den letzten Jahren hat sich die Automobilindustrie zu einem der wesentlichen Anwender von Echtzeitbetriebssystemen für eingebettete Systeme entwickelt. Relativ zeitig erkannten

Mehr

Echtzeit mit Linux. Erweiterungen und deren Anwendung. Martin Krohn. 2. Februar 2006

Echtzeit mit Linux. Erweiterungen und deren Anwendung. Martin Krohn. 2. Februar 2006 Erweiterungen und deren Anwendung 2. Februar 2006 1 Einleitung Anwendungsgebiete 2 Linux als Echtzeitbetriebssystem Eignung von Linux 3 Erweiterungen für Linux RT-Linux RTAI- Real-Time Application Interface

Mehr

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 7 Scheduling Maren Bennewitz Version 23.01.2013 1 Inhalt Vorlesung Aufbau einfacher Rechner Überblick: Aufgabe, Historische Entwicklung, unterschiedliche Arten von Betriebssystemen

Mehr

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS geschrieben von Oliver Botschkowski 1 Offene Systeme und deren Schnittstelle für die Elektronik im Kraftfahrzeug 1 Oliver Botschkowski - OSEK-OS

Mehr

Adeos & Xenomai. Echtzeitbetriebssysteme / SS09. Alexander Behringer. Georg-Simon-Ohm-Hochschule Nürnberg. 24. Juni 2009

Adeos & Xenomai. Echtzeitbetriebssysteme / SS09. Alexander Behringer. Georg-Simon-Ohm-Hochschule Nürnberg. 24. Juni 2009 Adeos & Xenomai Echtzeitbetriebssysteme / SS09 Alexander Behringer Georg-Simon-Ohm-Hochschule Nürnberg 24. Juni 2009 Alexander Behringer (GSO Nbg) Adeos & Xenomai 24. Juni 2009 1 / 39 Übersicht Einführung

Mehr

LINUX und Echtzeit. Eine Übersicht prinzipieller Lösungsansätze. Your partner for industrial, embedded Linux

LINUX und Echtzeit. Eine Übersicht prinzipieller Lösungsansätze. Your partner for industrial, embedded Linux LINUX und Echtzeit Eine Übersicht prinzipieller Lösungsansätze Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial

Mehr

RTEMS- Echtzeitbetriebssystem

RTEMS- Echtzeitbetriebssystem RTEMS- Echtzeitbetriebssystem Name: Hussein Hammoud Matrikel- Nr.: 230768 Studiengang: Technische Informatik Fach: Projekt Eingebettete Kommunikation Technische Universität Berlin Sommersemester 2006 RTEMS-

Mehr

Embedded OS für ARM Cortex Microcontroller

Embedded OS für ARM Cortex Microcontroller Embedded OS für ARM Cortex Microcontroller RTOS Design, Timinganalyse und Test mit Core Simulation und Hardware Debugger Entscheidende Fragen für oder gegen RTOS Lohnt sich der Einsatz eines RTOS auch

Mehr

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching Rainer Müller 21. November 2013 Spezialisierung von Betriebssystemen Vielzweckbetriebssysteme (General Purpose OS,

Mehr

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin Scheduling in Echtzeitbetriebssystemen Prof. Dr. Margarita Esponda Freie Universität Berlin Echtzeitsysteme Korrekte Ergebnisse zum richtigen Zeitpunkt Hart Echtzeitsysteme Eine verspätete Antwort ist

Mehr

Dämon-Prozesse ( deamon )

Dämon-Prozesse ( deamon ) Prozesse unter UNIX - Prozessarten Interaktive Prozesse Shell-Prozesse arbeiten mit stdin ( Tastatur ) und stdout ( Bildschirm ) Dämon-Prozesse ( deamon ) arbeiten im Hintergrund ohne stdin und stdout

Mehr

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012 Übung zu Grundlagen der Betriebssysteme 7. Übung 27.11.2012 Threads Thread (Faden des (Kontrollflusses)): ist ein sequentieller Abarbeitungsablauf (Kontrollfluss) innerhalb eines Prozesses. Umfasst ein

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

5) Realzeitscheduling

5) Realzeitscheduling Inhalte Anforderungen Klassifizierungen Verschiedene Verfahren: FIFO, Round Robin, Least Laxity, EDF, fixed/dyn. Prio. Beispiele und Aufgaben Seite 1 Motivation Gegeben: Ein Einprozessorsystem, das Multiprogrammierung

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

8. Vorlesung Betriebssysteme

8. Vorlesung Betriebssysteme Dr. Christian Baun 8. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 1/69 8. Vorlesung Betriebssysteme Dr. Christian Baun Hochschule Mannheim Fakultät für Informatik wolkenrechnen@gmail.com Dr. Christian

Mehr

Scheduling. Prozess-Ablaufplanung. Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012

Scheduling. Prozess-Ablaufplanung. Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012 Scheduling Prozess-Ablaufplanung Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012 Scheduler Der Scheduler ist ein besonders wichtiges Programmteil jedes Betriebssystems. Prozesse P 1 P

Mehr

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse)

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse) 5 CPU-Scheduling Im folgenden wird von Threads gesprochen. Bei Systemen, die keine Threads unterstützen, ist der einzige "Thread" eines Prozesses gemeint. Früher wurde dieser Thread synonym mit dem Begriff

Mehr

Vorbereitung zur Prüfung Echtzeitbetriebssysteme

Vorbereitung zur Prüfung Echtzeitbetriebssysteme Vorbereitung zur Prüfung Echtzeitbetriebssysteme Zugelassene Hilfsmittel: Taschenrechner Bitte verwenden Sie keinen roten Farbstift! 1. Echtzeitbetriebssysteme - Allgemein (15 Punkte) 1.1. Warum setzen

Mehr

Embedded Software Engeneering mit dem Raspberry Pi

Embedded Software Engeneering mit dem Raspberry Pi Embedded Software Engeneering mit dem Raspberry Pi Übersicht Rasperry Pi Betriebssystem Hardware ARM Μ-Controller vs. Μ-Prozessor vs. SoC Embedded Software Engineering vs. Software Engineering Fazit Raspberry

Mehr

Echtzeitbetriebssysteme

Echtzeitbetriebssysteme Echtzeitbetriebssysteme QNX 409 Geschichte: Einführung 1980 entwickeln Gordon Bell und Dan Dodge ein eigenes Echtzeitbetriebssystem mit Mikrokernel. QNX orientiert sich nicht an Desktopsystemen und breitet

Mehr

Betriebssysteme I WS 2013/2014. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404

Betriebssysteme I WS 2013/2014. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Betriebssysteme I WS 2013/2014 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 16. Januar 2014 Betriebssysteme / verteilte Systeme Betriebssysteme

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

Mehr

Prozesse und Scheduling

Prozesse und Scheduling Betriebssysteme für Wirtschaftsinformatiker SS04 KLAUSUR Vorbereitung mit Lösungen / Blatt 1 Prozesse und Scheduling Aufgabe 1 : Scheduling Gegeben seien die folgenden Prozesse und die Längen des jeweiligen

Mehr

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit Dipl.-Inf. J. Richling Wintersemester 2003/2004 Weiche Echtzeit Wiederholung - Resultat/Wert-Funktion "harte" Echtzeit Wert Zeit Wert Zeit Wert Deadline Zeit "weiche" Echtzeit Wert Deadline Zeit Deadline

Mehr

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

Mehr

User Level Device Driver am Beispiel von TCP

User Level Device Driver am Beispiel von TCP September 17, 2004 Einleitung Motivation für Userlevel Device Driver Probleme von Userlevel Device Driver Motivation für Userlevel Device Driver Modularität, leichterer Austausch/Erneuerung von Komponenten.

Mehr

6.Vorlesung Betriebssysteme Hochschule Mannheim

6.Vorlesung Betriebssysteme Hochschule Mannheim Christian Baun 6.Vorlesung Betriebssysteme Hochschule Mannheim SS2011 1/40 6.Vorlesung Betriebssysteme Hochschule Mannheim Christian Baun Karlsruher Institut für Technologie Steinbuch Centre for Computing

Mehr

Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet.

Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet. Prozessverwaltung Prozesse Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet. Prozesse sind Abfolgen von Aktionen, die unter Kontrolle

Mehr

Embedded Linux. Arthur Baran

Embedded Linux. Arthur Baran Arthur Baran Inhalt Embedded System Aufbau von Embedded Linux Systemen Echtzeit Einige Beispiele Arthur Baran 2 Was ist Embedded System? klein verborgen im Gerät soll eine bestimmte Aufgabe erledigen Arthur

Mehr

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation Inhaltsverzeichnis Systemprogrammierung - Kapitel 2 Prozessverwaltung 1/21 2.1 Was ist ein Prozess? Definition Prozesszustände Prozesskontrollblöcke 2.4 Thread-Systeme Sinn und Zweck Thread-Arten Thread-Management

Mehr

13. Übung mit Musterlösung

13. Übung mit Musterlösung 13. Übung mit Musterlösung 1 Lösung 1 Teil 1.Multiple Choice) Bewertung: Ein Punkt für richtige Antwort, für jede falsche Antwort ein Punktabzug. a) Für die Exponentialverteilung ist die Zeit bis zum nächsten

Mehr

OSEKtime - Time-Triggered OSEK/OS

OSEKtime - Time-Triggered OSEK/OS OSEKtime - Time-Triggered OSEK/OS Gregor Kaleta gregor.kaleta@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung OSEKtime Task-Zustandsmodell, Scheduling-Verfahren Interrupt-Verarbeitung

Mehr

Echtzeit-Linux mit dem RT-Preemption-Patch

Echtzeit-Linux mit dem RT-Preemption-Patch Echtzeit-Linux mit dem RT-Preemption-Patch IT-Klinger Andreas Klinger ak@it-klingerde 22072008 Der RT-Preemption-Patch integriert sich beinahe nahtlos in den Standard-Kernel und bietet Echtzeitfähigkeit

Mehr

Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene. Andi Drebes Fachbereich Informatik Universität Hamburg

Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene. Andi Drebes Fachbereich Informatik Universität Hamburg Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene Andi Drebes Fachbereich Informatik Universität Hamburg Gliederung Notwendigkeit des Schedulings Einführung: Begriff des Multitaskings

Mehr

Unterschiede in den Konzepten von TinyOS und Embedded Linux

Unterschiede in den Konzepten von TinyOS und Embedded Linux Fakultät Informatik Institut für Angewandte Informatik, Professur Technische Informationssysteme Unterschiede in den Konzepten von TinyOS und Embedded Linux Dresden, 29.11.2010 Inhalt 1. Einführung 1.1

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Hardware Virtualisierungs Support für PikeOS

Hardware Virtualisierungs Support für PikeOS Virtualisierungs Support für PikeOS Design eines Virtual Machine Monitors auf Basis eines Mikrokernels Tobias Stumpf SYSGO AG, Am Pfaenstein 14, 55270 Klein-Winternheim HS Furtwangen, Fakultät Computer

Mehr

Embedded-Linux-Seminare. Linux als Betriebssystem

Embedded-Linux-Seminare. Linux als Betriebssystem Embedded-Linux-Seminare Linux als Betriebssystem http://www.embedded-linux-seminare.de Diplom-Physiker Peter Börner Spandauer Weg 4 37085 Göttingen Tel.: 0551-7703465 Mail: info@embedded-linux-seminare.de

Mehr

B1 Stapelspeicher (stack)

B1 Stapelspeicher (stack) B1 Stapelspeicher (stack) Arbeitsweise des LIFO-Stapelspeichers Im Kapitel "Unterprogramme" wurde schon erwähnt, dass Unterprogramme einen so genannten Stapelspeicher (Kellerspeicher, Stapel, stack) benötigen

Mehr

Mikrokernbasierte Betriebssysteme in industriellen Anwendungen

Mikrokernbasierte Betriebssysteme in industriellen Anwendungen Mikrokernbasierte Betriebssysteme in industriellen Anwendungen Diplomverteidigung André Puschmann 1. Dezember 2009 Überblick 1 Einführung 2 Echtzeit- und Verlässlichkeitsanalyse 3 Entwurf/Implementierung

Mehr

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme. Eine Einführung. Klaus Kusche, Okt. 2011

Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme. Eine Einführung. Klaus Kusche, Okt. 2011 Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme Eine Einführung Klaus Kusche, Okt. 2011 Ziele des Vortrags Überblick über das Thema Praktisches Verständnis von Anforderungen Problembereichen

Mehr

Linux-Kernel- Programmierung

Linux-Kernel- Programmierung Michael Beck, Harald Böhme, Mirko Dziadzka, Ulrich Kunitz, Robert Magnus, Dirk Verworner Linux-Kernel- Programmierung Algorithmen und Strukturen der Version 1.0 ADDISON-WESLEY PUBLISHING COMPANY Bonn Paris

Mehr

Studienarbeit 19.06.2007

Studienarbeit 19.06.2007 Georg-Simon-Ohm-Fachhochschule Nürnberg Fachbereich Informatik Studienarbeit Stephan Meyer Matrikelnummer: 837840 Email: stephan.meyer2@student.fh-nuernberg.de 19.06.2007 Fach: Echtzeitbetriebssysteme

Mehr

OS/2 System- und Netzwerkprogrammierung

OS/2 System- und Netzwerkprogrammierung Hans Joachim Müschenborn OS/2 System- und Netzwerkprogrammierung Multitasking Interprozeßkommunikation Multithreading DB/2-lntegration tewi Verlag sverzeichnis / I Inhaltsverzeichnis 5 In eigener Sache

Mehr

Technische Informatik II

Technische Informatik II Institut für Technische Informatik und Kommunikationsnetze Technische Informatik II Übung 1: Prozesse und Threads Aufgabe 1: Prozesse und Threads a) Wie verhält sich eine Applikation die aus mehreren Prozessen

Mehr

Performance Messungen von FreeRTOS und

Performance Messungen von FreeRTOS und Performance Messungen von FreeRTOS und µc/os-iii auf ARM-Architekturen Tim Wacher (wht4@bfh.ch) Master of Science in Engineering MRU Production Technology 16. August 2011/ CH-3400 Burgdorf Outline 1 Ziel

Mehr

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel Aufgabe 1 (5 Punkte) (Multiple Choice) Beantworten Sie folgende Fragen durch Ankreuzen der richtigen Antwort. Für jede falsche Antwort wird ein Punkt abgezogen (es werden minimal 0 Punkte vergeben). Welche

Mehr

Kernel Programmierung unter Linux. Programmierung von Kernelmodulen. Referent Klaus Ruhwinkel

Kernel Programmierung unter Linux. Programmierung von Kernelmodulen. Referent Klaus Ruhwinkel Kernel Programmierung unter Linux Programmierung von Kernelmodulen Referent Klaus Ruhwinkel Das Betriebssystem Aufbau des Betriebssystem: Es besteht aus den Betriebssystemkern und den sonstigen Betriebssystemkomponenten

Mehr

B.5 Prozessverwaltung B.5. Prozessverwaltung. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.5 Prozessverwaltung B.5. Prozessverwaltung. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Prozessverwaltung Prozessverwaltung 2002 Prof. Dr. Rainer Manthey Informatik II 1 Prozesse Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) ) von einem Rechner abgearbeitet.

Mehr

2.2 Rechnerorganisation: Aufbau und Funktionsweise

2.2 Rechnerorganisation: Aufbau und Funktionsweise 2.2 Rechnerorganisation: Aufbau und Funktionsweise é Hardware, Software und Firmware é grober Aufbau eines von-neumann-rechners é Arbeitsspeicher, Speicherzelle, Bit, Byte é Prozessor é grobe Arbeitsweise

Mehr

183.579, SS2012 Übungsgruppen: Do., 14.6. Mi., 20.6.2012

183.579, SS2012 Übungsgruppen: Do., 14.6. Mi., 20.6.2012 VU Technische Grundlagen der Informatik Übung 8: Systemsoftware und Netzwerke 183.579, SS2012 Übungsgruppen: o., 14.6. Mi., 20.6.2012 ufgabe 1: Virtual Memory Zeichnen Sie ein System das Paging zur Speicherverwaltung

Mehr

Quantitative Methoden. Betriebssysteme

Quantitative Methoden. Betriebssysteme Quantitative Methoden Betriebssysteme Problem und Gegenstand Problem Erfüllen von QoS-Anforderungen mit zeit- bzw. größenbeschränkten Ressourcen Gegenstand Scheduling basierend auf deterministischen Modellen

Mehr

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Dezember 007 Dipl.-Ing. Stefan Abu Salah Dipl.-Ing. Achim Marikar QoS (Quality of Service): Sicherstellung der Qualität Zeitkritische

Mehr

Universität Koblenz-Landau. Fachbereich 4: Informatik. Prof. Dr. Dieter Zöbel. Seminararbeit OSEK/VDX. Seminar Echtzeitsysteme.

Universität Koblenz-Landau. Fachbereich 4: Informatik. Prof. Dr. Dieter Zöbel. Seminararbeit OSEK/VDX. Seminar Echtzeitsysteme. Universität Koblenz-Landau Fachbereich 4: Informatik Prof. Dr. Dieter Zöbel Seminararbeit Seminar Echtzeitsysteme Thema 4 Wintersemester 1999/2000 Von Thorsten Schaub (thorsten@schaub-home.de) 17.12.1999

Mehr

20 Eingebettete Software

20 Eingebettete Software 20 Eingebettete Software 20.0 Einführung Lernziele Echtzeitsysteme Eingebettete Systeme 20.1 Entwurf eingebetteter Systeme Modellierung von Echtzeitsystemen Programmierung von Echtzeitsystemen 20.2 Architekturmuster

Mehr

Betriebssysteme. CPU-Scheduling - Fallbeispiele. Sommersemester 2014 Prof. Dr. Peter Mandl. Prof. Dr. Peter Mandl Seite 1.

Betriebssysteme. CPU-Scheduling - Fallbeispiele. Sommersemester 2014 Prof. Dr. Peter Mandl. Prof. Dr. Peter Mandl Seite 1. CPU-Scheduling - Fallbeispiele Sommersemester 2014 Prof. Dr. Peter Mandl Prof. Dr. Peter Mandl Seite 1 Gesamtüberblick 1. Einführung in 2. Betriebssystemarchitekturen und Betriebsarten 3. Interruptverarbeitung

Mehr

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002 Die L4-Mikrokern Mikrokern-Familie Hauptseminar Ansätze für Betriebssysteme der Zukunft 18.04.2002 Folie 1 Aufbau des Vortrags 1. Mikrokerne: Idee und Geschichte 2. L4: ein schneller Mikrokern 3. L4Linux:

Mehr

5.6 Realzeitarchitektur auf Multicore-Basis

5.6 Realzeitarchitektur auf Multicore-Basis 5.6 Realzeitarchitektur auf Multicore-Basis 63 VxWorks Vertreter eines klassischen Realzeitbetriebssystems mit einer starken Marktdurchdringung ist VxWorks der Firma Wind River. Ursprünglich als Realzeitbetriebssystem

Mehr

Inhaltsverzeichnis XII

Inhaltsverzeichnis XII 1 Einführung... 1 1.1 Computersysteme... 1 1.1.1 Einführung... 2 1.1.2 Aufgabe von Betriebssystemen... 3 1.1.3 Grundlegende Hardwaremodelle... 3 1.1.4 CPU-Registersatz... 7 1.1.5 Multicore-Prozessoren

Mehr

Virtualisierung im Echtzeitbereich. Andreas Hollmann FH Landshut EADS Military Air Systems

Virtualisierung im Echtzeitbereich. Andreas Hollmann FH Landshut EADS Military Air Systems Virtualisierung im Echtzeitbereich Andreas Hollmann FH Landshut EADS Military Air Systems 2 Überblick Hintergrund und Motivation Vorstellung von Lösungsansätzen Auswahl und Evaluierung Einschränkungen

Mehr

C. Betriebssystem-Strukturen C.1 Monolithische Betriebssysteme

C. Betriebssystem-Strukturen C.1 Monolithische Betriebssysteme C. Betriebssystem-Strukturen C.1 Monolithische Betriebssysteme Sammlung von Routinen, ohne Hierarchie, Kapselung und Schichtung. Jede Prozedur kann beliebige andere Prozeduren aufrufen und Datenstrukturen

Mehr

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar "Eingebettete drahtlose Systeme"

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar Eingebettete drahtlose Systeme Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de Embedded Linux 30.01.2009 Daniel Buchheim Inhalt: Was ist Embedded Linux? Hardwareunterstützung in Eingebetteten Systemen Open Source Aspekte Aufbau

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Betriebssysteme. Dipl.-Ing.(FH) Volker Schepper

Betriebssysteme. Dipl.-Ing.(FH) Volker Schepper 1. Der Prozess beginnt im Zustand Erzeugt, nachdem sein Vaterprozess den Systemaufruf fork() (s.u.) abgesetzt hat. In diesem Zustand wird der Prozess-Kontext initialisiert. 2. Ist diese Aufbauphase abgeschlossen,

Mehr

Ethernet als Bus für Echtzeitanwendungen im Automobil:

Ethernet als Bus für Echtzeitanwendungen im Automobil: Ethernet als Bus für Echtzeitanwendungen im Automobil: Konzepte aus der Automatisierungsbranche Hochschule für Angewandte Wissenschaften Hamburg Anwendungen 1 WS 08/09 16. Dezember 2008 Wie alles began

Mehr

5 CPU Scheduling. FH Regensburg BT/SS04 Betriebssysteme Wirtschaftsinformatik. 5.1 Grundlagen - 54 - 5.1.1 CPU Burst / I/O Burst

5 CPU Scheduling. FH Regensburg BT/SS04 Betriebssysteme Wirtschaftsinformatik. 5.1 Grundlagen - 54 - 5.1.1 CPU Burst / I/O Burst FH Regensburg BT/SS04 5 CPU Scheduling 5.1 Grundlagen 5.1.1 CPU Burst / I/O Burst Beobachtung: Programme rechnen typischerweise etwas, dann tätigen sie Ein/Ausgabe: CPU-Burst: das Programm rechnet eine

Mehr

Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling

Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling Betriebssysteme Kap F: CPU-Steuerung CPU-Scheduling 1 termini technici Der englische Fachausdruck scheduler wurde eingedeutscht : Der Scheduler Für scheduling ist im Deutschen auch zu verwenden: Ablaufplanung

Mehr

^ Springer Vi eweg. Grundkurs Betriebssysteme. Synchronisation, Prozesskommunikation, Virtualisierung. Architekturen, Betriebsmittelverwaltung,

^ Springer Vi eweg. Grundkurs Betriebssysteme. Synchronisation, Prozesskommunikation, Virtualisierung. Architekturen, Betriebsmittelverwaltung, Peter Mandl Grundkurs Betriebssysteme Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation, Virtualisierung 4. Auflage ^ Springer Vi eweg 1 Einführung 1 1.1 Computersysteme 1

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 Verarbeitungsgrundlagen Teil 3 Betriebssystem Überwacher

Mehr

Virtualisierung Betrachtung aktueller Hypervisor wie Xen, KVM und Hyper-V

Virtualisierung Betrachtung aktueller Hypervisor wie Xen, KVM und Hyper-V Ausgewählte Kapitel der Systemsoftware Virtualisierung Betrachtung aktueller Hypervisor wie Xen, KVM und Hyper-V Guilherme Bufolo Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik

Mehr

Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte

Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte Matthias Lange Informatikstudent, TU-Dresden 27. September 2005 http://www.matze-lange.de Warum entwickelt jemand einen Treiber für

Mehr

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

Mehr

Fragenkatalog Echtzeitsysteme/Realzeitsysteme. Jürgen Quade

Fragenkatalog Echtzeitsysteme/Realzeitsysteme. Jürgen Quade Fragenkatalog Echtzeitsysteme/Realzeitsysteme Jürgen Quade Fragenkatalog Echtzeitsysteme/Realzeitsysteme von Jürgen Quade V1.4, 31. Januar 2008 Versionsgeschichte Version $Revision: 1.1 $ $Date: 2005/01/25

Mehr

Grundkurs Betriebssysteme

Grundkurs Betriebssysteme Grundkurs Betriebssysteme Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation von Peter Mandl 3., akt. und erw. Aufl. 2013 Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck im

Mehr

Lokales Storage Teil 1

Lokales Storage Teil 1 Lokales Storage Teil 1 Zinching Dang 08. Juli 2015 1 Lokales Storage im Allgemeinen Lokales Storage im Allgemeinen Datenträger, die direkt am Host angeschlossen sind Anbindung über verschiedene Bus-Systeme

Mehr

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Betriebssysteme Betriebssysteme 2002 Prof. Dr. Rainer Manthey Informatik II 1 Bekannte Betriebssysteme Windows 2000 CMS UNIX MS-DOS OS/2 VM/SP BS 2000 MVS Windows NT Solaris Linux 2002 Prof. Dr. Rainer

Mehr

Jens Peter Lindemann Lehrstuhl Neurobiologie. 13. Januar 2009

Jens Peter Lindemann Lehrstuhl Neurobiologie. 13. Januar 2009 Real-Time Linux Jens Peter Lindemann Lehrstuhl Neurobiologie 13. Januar 2009 Was ist ein RTOS? Linux-basierte RT-Lösungen RT-Erweiterungen des Mainline-Kernels What's good for RT is good for the Kernel

Mehr

Scheduling-Verfahren für Mehrbenutzer-Systeme. Klaus Kusche, Juni 2012

Scheduling-Verfahren für Mehrbenutzer-Systeme. Klaus Kusche, Juni 2012 Scheduling-Verfahren für Mehrbenutzer-Systeme Klaus Kusche, Juni 2012 Inhalt Einleitung & Begriffe Ziele & Voraussetzungen Das Round-Robin-Verfahren...... und seine Probleme Die Scheduler in Windows und

Mehr

DBUS Interprozess-Kommunikation für Embedded-Plattformen

DBUS Interprozess-Kommunikation für Embedded-Plattformen DBUS Interprozess-Kommunikation für Embedded-Plattformen Andreas Schwarz Neratec Solutions AG Firmenprofil Neratec Solutions AG Produkt-Entwicklungen für kundenspezifische elektronische Produkte Produkte

Mehr

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Martin Däumler Matthias Werner Lehrstuhl Betriebssysteme Fakultät für Informatik

Mehr

Echtzeitfähigkeit mit dem Linux RT-Preempt Patch in FPGAbasierten

Echtzeitfähigkeit mit dem Linux RT-Preempt Patch in FPGAbasierten Forschungsbericht SS 2011 Echtzeitfähigkeit mit dem Linux RT-Preempt Patch in FPGAbasierten Prozessorsystemen Prof. Dr.-Ing. Rainer Bermbach Einleitung Viele Anwendungen von Embedded Systemen erfordern

Mehr

Studienvertiefungsrichtung Informationstechnik

Studienvertiefungsrichtung Informationstechnik Studienvertiefungsrichtung Informationstechnik Prof.Dr.-Ing. Ulrich Sauvagerd Lehrgebiet Informationstechnik Nov. 2006, Seite 1 www.etech.haw-hamburg.de/~sauvagerd Lehrgebiet Informationstechnik Nov. 2006,

Mehr

Timm M. Steinbeck und Arne Wiebalck Lehrstuhl für Technische Informatik Universität Heidelberg. Prozess-Monitoring auf CPU-Takt Ebene

Timm M. Steinbeck und Arne Wiebalck Lehrstuhl für Technische Informatik Universität Heidelberg. Prozess-Monitoring auf CPU-Takt Ebene Timm M. Steinbeck und Arne Wiebalck Lehrstuhl für Technische Informatik Universität Heidelberg Prozess-Monitoring auf CPU-Takt Ebene Einleitung Unser Arbeitsgebiet: ALICE Teilchenphysik Experiment Cluster

Mehr

Einführung in die Echtzeitbetriebssysteme

Einführung in die Echtzeitbetriebssysteme Einführung in die Echtzeitbetriebssysteme Hauptseminararbeit in dem Studiengang B.Sc. Informatik von Maximilian von Piechowski Technische Hochschule Mittelhessen Inhaltsverzeichnis 1 Was versteht man unter

Mehr

Virtualisierung ein Überblick

Virtualisierung ein Überblick Virtualisierung ein Überblick Frank Hofmann Potsdam 18. April 2007 Frank Hofmann (Potsdam) Virtualisierung ein Überblick 18. April 2007 1 / 33 Gedanken zum Thema Fragen, die sich jeder stellt Virtualisierung

Mehr

Betriebssystembau (BSB)

Betriebssystembau (BSB) Betriebssystembau (BSB) 6. Übung http://ess.cs.tu-.de/de/teaching/ws2013/bsb/ Olaf Spinczyk olaf.spinczyk@tu-.de http://ess.cs.tu-.de/~os AG Eingebettete System Informatik 12, TU Dortmund Agenda Vorstellung

Mehr

Sowohl RTX64 als auch RTX bieten harten Echtzeitdeterminismus und symmetrische Multiprocessing- Fähigkeiten (SMP).

Sowohl RTX64 als auch RTX bieten harten Echtzeitdeterminismus und symmetrische Multiprocessing- Fähigkeiten (SMP). Produktbeschreibung Februar 2014 RTX RTOS-Plattform Mit der RTX-Echtzeitsoftware von IntervalZero wird aus Microsoft Windows ein Echtzeitbetriebssystem (RTOS). RTX64 von IntervalZero unterstützt 64-Bit-Betriebssysteme

Mehr

Advanced DAQ System Development Using NI-DAQmx and Intelligent DAQ (FPGA)

Advanced DAQ System Development Using NI-DAQmx and Intelligent DAQ (FPGA) Advanced DAQ System Development Using NI-DAQmx and Intelligent DAQ (FPGA) Rudolf Gierlinger National Instruments, Österreich AGENDA Teil 1: Advanced NI-DAQmx Datenerfassungsmöglichkeiten Konfiguration

Mehr

*DE102007042999A120090312*

*DE102007042999A120090312* *DE102007042999A120090312* (19) Bundesrepublik Deutschland Deutsches Patent- und Markenamt (10) DE 10 2007 042 999 A1 2009.03.12 (12) Offenlegungsschrift (21) Aktenzeichen: 10 2007 042 999.3 (22) Anmeldetag:

Mehr

Betriebssystem? Übersicht. Ziele. Grundlagen. Das ist nur die Oberfläche... Wissen, was man unter einem Betriebssystem versteht

Betriebssystem? Übersicht. Ziele. Grundlagen. Das ist nur die Oberfläche... Wissen, was man unter einem Betriebssystem versteht Betriebssysteme Grundlagen Quellen: InSy Folien zum Thema Unix/Linux Wikipedia Das ist nur die Oberfläche... 1 Ziele 2 Übersicht Wissen, was man unter einem Betriebssystem versteht Was Was ist istein einbetriebssystem?

Mehr

Angewandte Informatik

Angewandte Informatik Angewandte Informatik Teil 2.1 Was ist Hardware? Die Zentraleinheit! 1 von 24 Inhaltsverzeichnis 3... Was ist Hardware? 4... Teile des Computers 5... Zentraleinheit 6... Die Zentraleinheit 7... Netzteil

Mehr