Vorlesung Informatik 2

Vorlesung Informatik 2 Teil 4: Rechnerarchitektur und Parallelverarbeitung Echtzeitbetriebssysteme Stand 6.3.2008 Lernziele für dieses Kapitel Die blau & kursiv gedruckten Begriffe sind Ihnen geläufig Sie wissen was der POSIX Standard ist, was standardisiert wird und seine Vor- und Nachteile für das Betriebssystem, welches den Standard erfüllen soll Sie können erklären, warum herkömmliche (nicht-realzeit) Betriebssysteme nicht realzeitfähig sein können. Sie kennen Ansätze, um Betriebssysteme realzeitfähig zu machen: wie erreicht man weiche Realzeitfähigkeit? wie erreicht man harte Realzeitfähigkeit? Slide 1

Inhalt Einführung UNIX Der IEEE 1003 (POSIX) Standard Eingebettete Betriebssysteme RT- Erweiterungen von UNIX/Linux RT- Erweiterungen von Windows Slide 2 Einleitung Definition Echtzeitbetrieb (DIN 44300): Echtzeitbetrieb ist der Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen. Echtzeitbetriebssysteme führen zwischen Hardware und Applikationen Abstraktionen ein, die es den Programmierern erlaubt (weitgehend) hardwareunabhängige Echtzeitanwendungen zu implementieren Ein Echtzeitbetriebssystem soll wenig Ressourcen verbrauchen und dabei stets zuverlässig und stabil laufen Programmfehler dürfen weder das Betriebssystem noch andere Programme beinflussen Slide 3

Einleitung Begriffsdefinition (Arten der Modellierung / Simulation) kontinuierlich deterministisch Robotersimulation statistisch Einschlagposition auf einer Zielscheibe diskret deterministisch Maschinenbelegung in der Fertigungsplanung statistisch Warteschlangen vor Ladenkassen Betriebssysteme, die nur weiche Echtzeit garantieren, machen statistische Angaben über Latenzzeiten Realzeitbetriebssysteme müssen deterministische Garantien abgeben Slide 4 Einleitung Eigenschaften von Realzeitbetriebssystemen sie erlauben die Bearbeitung von vielen externen Ereignissen mithilfe eines Unterbrechungskonzeptes ihre Antwortzeiten auf eine Unterbrechung sind definiert sie haben deterministisches zeitliches Verhalten (insbesondere bei zyklischer Einplanung von Prozessen wichtig) sie gewährleisten eine schnelle Reaktion und geringen overhead (bei I/O und Prozesswechsel) sie implementieren Multitaskingfähigkeit sie erlauben prioritätsgesteuertes Anlaufen von lauffähigen Programmen sie bieten effiziente und schnelle Interprozesskommunikation durch Skalierbarkeit sind sie in Systemen mit begrenzten Ressourcen einsetzbar sie weisen Lastunabhängigkeit auf sie verwenden / bieten Standardschnittstellen sie können auch mit nicht echtzeitfähigen Systemen kommunizieren sie sind für unterschiedliche Prozessorarchitekturen verfügbar es gibt spezielle Entwicklungswerkzeuge für Echtzeitanwendungen sie bieten guten und schnellen Durchgriff auf angeschlossene technische Prozesse Slide 5

Einleitung Eingebettetes Betriebssystem meistens im ROM abgelegt muss speichereffizient sein hat normalerweise keine GUI, da es nur mit dem technischen System interagiert Einarbeitungsaufwand meistens sehr hoch Wenige Applikationen und Entwicklungswerkzeuge vorhanden industrietauglich geringe Lizenzkosten ( geringe Stückkosten in eingebetteten Systemen) langfristige Verfügbarkeit des Supports Betriebssystem ist deterministisch Universalbetriebssystem auf der Festplatte abgelegt kann speichereffizient sein hat meist eine GUI, da es mit dem Benutzer interagiert Einarbeitungsaufwand eher gering Reichliche Auswahl an Applikationen und Entwicklungswerkzeugen kaum industrietauglich hohe Lizenzkosten ( hohe Stückkosten je eingebettetem System) oft kurzfristige Abkündigung des Supports Betriebsystem ist nichtdeterministisch Slide 6 Einleitung Echtzeitbetriebssysteme werden vorwiegend in komplexen eingebetteten Systemen verwendet, um vielfältige Betriebsmittel zu verwalten Das Echtzeitbetriebssystem führt eine für den Programmierer komfortable Abstraktionsschicht zwischen Hardware und seinen Programmen ein diese ist nicht "kostenlos" In weniger komplexen Systemen werden Betriebssysteme oft nicht verwendet, da sie dort nur unnötig Ressourcen verbrauchen und nicht zu einer Leistungssteigerung beitragen Grundfunktionen von Betriebssystemen werden dann, und nur soweit benötigt, durch eigene Funktionen implementiert (z.b. das Scheduling, I/O, usw.) benötigte Reaktionszeiten und adäquate Implementierungsalternativen Minuten Steuerung "von Hand" ~ 1 Minute Mechanisches System ~ 1 Sekunde Standardbetriebssystem ~ Millisekunden Realzeitbetriebssystem ~ μ-sekunden Interrupt-Service Routine darunter direkte Hardwareimplementierung Slide 7

Einleitung Echtzeitbetriebssysteme lassen sich in zwei wesentliche Kategorien unterteilen: Systeme, die auf optimierten Versionen konventioneller Betriebssystem aufsetzen, wie Lynx, Linux-RT Systeme, die von Grund auf neu für Realzeitanwendungen entwickelt wurden, wie QNX, OSE, VxWorks ausserdem gibt es noch Betriebssysteme, die für weiche Echtzeitbedingungen (eingebettete Anwendungen) optimiert sind: Windows-basiert (WinCE) Linux-basiert (Monta-Vista Patches) spezielle Handy- und PDA-Betriebssysteme (Palm-OS, Symbian) und Speicherprogrammierbare Steuerungen Slide 8 Einleitung hier behandelt: VxWorks QNX embedded Linux Symbian OS Palm OS Windows CE Echtzeit Betriebssysteme mobile (eingebettete) Betriebssysteme es gibt derzeit über 100 verschiedene eingebettete Betriebssysteme, die aber z.t. nur für spezielle Prozessoren geeignet sind und/oder spezielle Anforderungen (z.b. an Ressourcen) stellen Beispielsweise benötigt Windows CE 5.0 eine 32 bit CPU (ARM, SHx, MIPS oder x86), 250 KB Flash und mindestens 6-8 MB RAM hat man sich für einen Prozessor entschieden, kann man meist noch zwischen einem Dutzend Betriebssystemen entscheiden die meisten sind keine Echtzeit-Betriebssysteme, sondern für mobile Rechnersysteme gedacht (PDAs, MDAs, Smartphones, Wearables, ) allerdings auf die besonderen Anforderungen der Mobilität ausgelegt: Reaktivität, schnelle Betriebsbereitschaft, geringe Ressourcen, Slide 9

Inhalt Einführung UNIX Der IEEE 1003 (POSIX) Standard Eingebettete Betriebssysteme RT- Erweiterungen von UNIX/Linux RT- Erweiterungen von Windows Slide 10 UNIX 1965: General Electric, AT&T Bell Telephone Laboratories und MIT entwickeln ein neues Betriebssystem für multi-user / multitasking: MULTICS 1969: Bell Labs steigen aus, da MULTICS nicht die gesteckten Ziele erreichen wird Das MULTICS-Team von Bell um Ken Thompson und Dennis Ritchie entwickeln ein Dateisystem Aus MULTICS 'Resten', dem Dateisystem und weiteren Ergebnissen aus der Implementierung eines "Space Travel" Programms auf einer DEC PDP-7 entstanden frühe Komponenten von UNIX 1971 wurde UNIX auf eine PDP-11 portiert: 16kB für das System 8kB für Benutzerprogramme 512kB Harddisk 64kB maximale Dateigröße Slide 11

UNIX Ken Thompson entwickelt die interpretierte Sprache B (Resultat: mangelnde Performanz) Dennis Ritchie entwickelt daher die übersetzte, sehr maschinennahe und effiziente Sprache C 1973 wird UNIX in C re-implementiert hohe Akzeptanz von UNIX (und C) Formierung der UNIX Systems Group bei Bell Labs AT&T durfte aber aufgrund einer Vereinbarung mit der Regierung UNIX zunächst nicht kommerziell vertreiben 1977 gab es bereits 500 UNIX-Installationen, davon 125 an Universitäten UNIX wurde als Betriebssystem bei Telefon-Companies eingesetzt, da es sich wegen seiner Realzeitservices, guter Programmentwicklung und für die Implementierung von Netzwerkmanagementsystemen eignet 1977 wurde UNIX zum ersten Mal von einem VAR* verkauft und auf eine nicht-pdp Maschine portiert * VAR Value Added Reseller Slide 12 UNIX UNIX verbreitetet sich nun schnell, wurde vielfach portiert und aufgrund seiner Einfachheit und Klarheit gerne erweitert 1982 integrierte AT&T mehrere eigene UNIX-Varianten zum System III Erweiterungen führten dann zum System V, welches ab 1983 von AT&T kommerziell vertrieben und supported wurde An der Universität von California in Berkley wurde eine UNIX Variante für DEC VAX entwickelt, die als 4.3 BSD bekannt wurde BSD UNIX hat ggü System V einige interessante Features, die zu weiter Verbreitung führte 1984 gab es 100.000 UNIX Installationen auf einem breiten Spektrum von Rechnern (von Mikrocomputer bis Host) kein anderes Betriebssystem hat das jemals erreicht Obwohl C "die" Sprache des UNIX Systems ist gibt es Compiler bzw. Interpreter für alle wichtigen Sprachen, bspw: FORTRAN, BASIC, PASCAL, ADA, C, C++, COBOL, LISP, PROLOG, Aufbauend auf System V und BSD gibt es eine Reihe von hersteller-spezifischen UNIX-Derivaten: HP-UX, IRIX, SINIX, DEC-UNIX, AIX, Standardisierung?! Slide 13

Inhalt Einführung UNIX Der IEEE 1003 (POSIX) Standard Eingebettete Betriebssysteme RT- Erweiterungen von UNIX/Linux RT- Erweiterungen von Windows Slide 14 Der IEEE 1003 (POSIX) Standard POSIX Portable Operating System Interface Spezifikation wurde bis Anfang der 90er Jahre von der IEEE erarbeitet und von ANSI und ISO standardisiert (*) Ziel: die Portatibilität (Übertragbarkeit) von Programmen auf Quellcodeebene zu gewährleisten, indem eindeutige Schnittstellen in Form von Funktionen spezifiziert werden, die von jedem POSIX-konformen Betriebssystem bereitgestellt werden müssen Ein POSIX-konformer Quellcode (der ausschließlich Funktionen des Betriebssystems aus dem POSIX-Standard verwendet) ist auf jedem POSIX-Betriebssystem kompilierbar Außer der Betriebssystemschnittstelle beschreibt POSIX auch noch die Themen: shell and utility, system administration und test methods beachte: meist wird mit POSIX aber nur der "System Interface Standard" gemeint ISO Standards: www.iso.org www.posix.com (*) IEEE Institute of Electrical and Electronics Engineers ANSI American National Standards Institute ISO International Standards Organization Slide 15

Der IEEE 1003 (POSIX) Standard Idee eines Schnittstellen-Standards: idealisiert real Anwendung 1 mit Aufrufen an Betriebssystem A Antworten des Betriebssystems A Standardisierte Aufrufschnittstelle Anwendung 1 mit Aufrufen an Betriebssystem B Zu A identische Antworten des Betriebssystems B POSIX konforme Applikation POSIX Schnittstelle teilweise konforme Applikation proprietäres Betriebssystem Hardware proprietäre Applikation proprietäre Schnittstelle Hardware X Hardware Y mit X = Y oder X Y; aber A B Slide 16 Der IEEE 1003 (POSIX) Standard POSIX basiert sehr stark auf UNIX, da in den frühen 90er Jahren UNIX das einzige (annähernd) standardisierte und dabei herstellerunabhängige Betriebssystem war Da es aber verschiedene UNIX Varianten gibt, wurde POSIX mit den wichtigsten UNIX "flavors" kompatibel definiert POSIX umfasst standardisierte Aufrufe für folgende Dienste: Prozesse Timer Dateien und Verzeichnisse Ein/Ausgabe Fehlerbehandlung Systeminformationen UNIX (und damit POSIX) war aber nur für "weiche" Echtzeit- Anwendungen entworfen und konnte auch nicht als im Realzeit- Sinne deterministisch betrachtet werden Daher wurde sogennante real-time extensions vorgenommen: Prioritätsbasiertes prä-emptives Scheduling Hochauflösende Timer Asynchrone Ein/Ausgabe Message Handling Speichermanagement Task Synchronisierung Wechselseitiger Ausschluß Slide 17

POSIX Spezifikationen Der IEEE 1003 (POSIX) Standard 1003.0 POSIX Guide 1003.1 System Interface 1003.2 Shells and Utilities (Tools) 1003.3 Common Test Methods 1003.4 Real Time API 1003.5 Ada Bindings 1003.6 Security Extensions for 1003.1 1003.7 System Administration 1003.8 Network Transparent File Access (TFA) API 1003.9 Fortran Bindings 1003.10 Supercomputing Application Environment Profile (AEP) 1003.11 Transaction Processing AEP 1003.12 Protocol Independant Network Interfaces 1003.13 Real Time AEP 1003.14 Multiprocessing AEP 1003.15 Supercomputing Batch System Administration 1003.16 C Language Binding 1003.17 Directory Servive API (renumbered to 1224.2) 1003.18 POSIX Platform Environment Profile 1003.19 Fortran 90 Binding 1003.20 Real Time Ada Bindings 1003.21 Real Time Distributed Communication Servives 1003.22 Distributed Security Framework [Stand 1993] Slide 18 Der IEEE 1003 (POSIX) Standard Der POSIX Substandard IEEE 1003.1b behandelt die o.g. echtzeitspezifischen Erweiterungen sowie I/O Erweiterungen Die Nutzung des POSIX Standards hat Konsequenzen: overhead Kosten POSIX-konforme Betriebssysteme sind groß (> 0,5 MB und nutzen wesentlich mehr RAM als ROM); für kleinere Microcontroller ist das nicht akzeptabel Sprachabhängigkeiten POSIX bezieht sich zunächst auf die Sprache C und später wurden Ada, Fortran und Fortran90 hinzugenommen; es werden jedenfalls übersetzte Hochsprachen mit den Nachteilen der Übersetzung (z.b. Overhead im Code) eingesetzt Portabilität kommt darauf an wie POSIX-konform Betriebssystem und Anwendungsprogramm wirklich sind welche Standard-Variante sie nun benutzen (ISO, ANSI, ) ob mit oder ohne Aufrufen aus Standard-Erweiterungen ob mit oder ohne Aufrufe der proprietären Schnittstelle Slide 19

Inhalt Einführung UNIX Der IEEE 1003 (POSIX) Standard Eingebettete Betriebssysteme RT- Erweiterungen von UNIX/Linux RT- Erweiterungen von Windows Slide 20 Eingebettete Betriebssysteme hier beispielhaft behandelt: VxWorks QNX Symbian OS Palm OS Windows CE Echtzeit Betriebssysteme mobile (eingebettete) Betriebssysteme es gibt derzeit über 100 verschiedene eingebettete Betriebssysteme, die aber z.t. nur für spezielle Prozessoren geeignet sind und/oder spezielle Anforderungen (z.b. an Ressourcen) stellen Beispielsweise benötigt Windows CE 5.0 eine 32 bit CPU (ARM, SHx, MIPS oder x86), 250 KB Flash und mindestens 6-8 MB RAM hat man sich für einen Prozessor entschieden, kann man meist noch zwischen einem Dutzend Betriebssystemen entscheiden die meisten sind keine Echtzeit-Betriebssysteme, sondern für mobile Rechnersysteme gedacht (PDAs, MDAs, Smartphones, Wearables, ) allerdings auf die besonderen Anforderungen der Mobilität ausgelegt: Reaktivität, schnelles Booten (oder always on), geringe Ressourcen, Slide 21

Eingebettete Betriebssysteme VxWorks (von Wind River Systems Inc., www.wrs.com) auf der US-amerikanischen Pathfinder- Mission 1996 zum Mars eingesetzt derzeit in der Formel 1 als Betriebssystem in Rennfahrzeugen verwendet, um Kommunikation und Interaktion zwischen Fahrer/Fahrzeug und Rennstall zu realisieren VxWorks wurde speziell für Steuerungs- und Datenerfassungszwecke entwickelt: Es unterstützt zum Beispiel den VME Bus Es gibt, im Unterschied zu Windows- oder UNIX-artigen Betriebssystemen, keinen Benutzerbereich (der deutlich vom System abgegrenzt ist und nur begrenzte direkte Zugriffsrechte besitzt) Routinen für Hardwarezugriffe werden direkt in den Kernel geladen (keine gesonderte Treiberschicht) Es ist multiprozessorfähig, unterstützt shared memory, message queues, und einen effektiven inter-task Koordinierungsmechanismus Slide 22 Eingebettete Betriebssysteme VxWorks ist aus verschiedenen Komponenten aufgebaut, die drei wesentlichen sind: Hochleistungs-Mikrobetriebssystemkern mit Echtzeitfunktionen, wie schnellem Multitasking, Interrupt Support, pre-emptive und round-robin scheduling; dieser Kern kann auf die Zielhardware skaliert werden nur die notwendigen Ressourcen müssen installiert werden Das Netzwerkmodul dient zur Implementierung verteilter Systeme und unterstützt TCP/IP und Ethernet Die Cross-Entwicklungsumgebung Tornado Der Kern von VxWorks ist Linux-ähnlich aufgebaut Dienste sind allerdings auf der Taskebene implementiert, nicht im Kernel Skalierbarkeit System-Entwicklungswerkzeuge Netzwerk Subsystem Betriebssystem I/O Subsystem POSIX Schnittstellen WIND Microkernel VxWorks kann parallel zu Windows auf PCs installiert werden Windows kann als Bedienoberfläche und für Auswertungen genutzt werden während VxWorks die Steuerung und Regelung übernimmt Slide 23

Eingebettete Betriebssysteme Das VxWorks Laufzeitsystem: der Kernel bietet eine Multitasking Umgebung mit Mechanismen zur Interprozeß-kommunikation und Synchronisation binäre und zählende Semaphore Message Queues Shared Memory Events Pipes Sockets (technische Grundlage für Kommunikation, z.b. TCP/IP) RPCs (remote procedure calls) alle anderen Betriebssystemaufgaben werden auf die Ebene der Tasks verlagert die Zuteilung der Tasks ist prioritätsbasiert und pre-emptive es stehen 256 Prioritätsstufen zur Verfügung; jeder können beliebig viele Tasks zugeordnet werden der Kernel ist (aus Gründen der Portabilität der Anwendungen) mit einer Schnittstelle nach POSIX 1003.1b versehen Slide 24 Eingebettete Betriebssysteme QNX (von QNX Software Systems Ltd., www.qnx.com) 32 Bit Multi-User echtzeitfähiges Betriebssystem Multitasking, prioritätsgesteuertes, verdrängendes Scheduling mit schneller Kontextumschaltung Orientierung am POSIX Standard Durch flexible, modulare Architektur skalierbar auf kleine eingebettete Systeme wie auch auf große im Netzwerk verteilte Anwendungen Microkernel-Architektur und nachrichtenbasierte Interprozess- Kommunikation Im Kernel arbeiten kooperierende Prozesse: Prozess- Manager, Geräte- Manager, verschiedene Filesystem- Manager, Netzwerk- Manager, GUI) Außer dem Prozess- Manager können alle anderen Manager- Tasks während der Laufzeit gestartet und beendet werden Slide 25

Eingebettete Betriebssysteme Der Prozeß- Manager ist mit dem Microkernel in einem Modul verbunden, welches in allen Konfigrationen erforderlich ist; beide benutzen den gleichen Adressraum Prozeß-Erzeugung geschieht über Message-Passing und kann daher auch auf anderen Netzknoten erfolgen Der Geräte-Manager bildet die Schnittstelle zwischen Anwendung und den Gerätetreibern Der Dateisystem- Manager kann verschiedene Dateisysteme auch nebeneinander laufen lassen; sie werden in 5 Kategorien unterteilt: Image, Block, Flash, Network und Virtual Filesystem Der Power- Manager ermöglicht die feingranulare Kontrolle der Leistungsaufnahme jeder einzelnen Systemkomponente. Dem Anwender werden verschiedene Strategien des power-managements zur Einstellung der Leistungsaufnahme seines Systems angeboten (Schnelligkeit vs Batterielebensdauer) Das GUI ist sehr leichtgewichtig, besteht aus kooperierenden Prozessen und bietet auch bei begrenzten Ressourcen noch umfangreiche Fensterfunktionalität Anwendungen werden mit der Werkzeugkette von GNU erstellt. Portierungen von Linux nach QNX werden damit möglich. Slide 26 Eingebettete Betriebssysteme Symbian OS (vom 1998 gegründeten Konsortium aus Arima, benq, Fujitsu, Lenovo, LG Electronics, Mitsubishi Electric, Nokia, Motorola, Panasonic, Sanyo, Sendo, Sony Ericsson, Psion, Siemens; www.symbian.com) Betriebssystem für PDAs und Smartphones Abgeleitet aus Psions 32 Bit EPOC Plattform Unterstützt zahlreiche Kommunikationsprotokolle, insbesondere drahtlose Protokolle: WAP, Bluetooth, Anwendungen (Prozesse) laufen in geschützten Bereichen und ein Absturz ist fast unmöglich Symbian unterstützt RAM, ROM, Flash und Erweiterungskarten Um Arbeitsspeicher zu sparen ist es mit der execute-in-place Methode möglich, Programme direkt aus dem Flash Speicher heraus auszuführen Symbian unterstützt prä-emptives Multitasking und Multithreading Anwendungen können in C++, Java, OPL und.net entwickelt werden Slide 27

Eingebettete Betriebssysteme Palm OS (von PalmSource, www.palmsource.com) das mit am weitesten verbreitete eingebettete Betriebssystem (PDAs, medizinische Instrumente, Smartphones): 21 Mio ausgelieferte Geräte; 13.000 Applikationen sind für Palm OS verfügbar 32 Bit, ereignisgesteuert, eingeschränkte Multitaskingfähigkeit (nur auf Betriebssystemebene können nebenläufige Tasks ausgeführt werden, aber nicht auf Applikationsebene) Palm OS ist um einen Kernel mit Grundfunktionalität aufgebaut Höhere Funktionen werden über einen "Manager" zur Verfügung gestellt; dies bietet eine hohe Abstraktionsebene für die Entwickler und wechselseitigen Schutz der Applikationen zum permanenten Speichern von Daten und Programmen wird RAM (aufgeteilt in dynamic area und storage area) verwendet zur Platzersparnis wird execute-in-place angewandt Slide 28 Eingebettete Betriebssysteme Windows CE (Microsoft, www.microsoft.com) Ziel war es, möglichst nahe an den Universalbetriebssystemen der Windows-Familie zu bleiben Design ("vertraute Oberfläche") und Ressourcenbedarf sind daher weniger konsequent auf eingebettete Systeme zugeschnitten Windows CE hat eine offene Architektur und unterstützt eine Vielzahl von Hardwarekomponenten Informations-, Kommunikations-, und Unterhaltungsbereich (Internet-TV, Set-Top-Boxen) Speicherverwaltung erfolgt wie bei Palm OS in 2 Bereichen im RAM Das System selbst ist in ROM abgespeichert und nur es wird inplace ausgeführt Applikationen werden in den Arbeitsspeicher kopiert und von dort ausgeführt Daten im permanenten Speicher sind komprimiert abgelegt Slide 29

Eingebettete Betriebssysteme Windows CE unterstützt eine große Anzahl an Speichererweiterungen, so dass auch größere Anwendungen und Datenmengen abgelegt werden können Windows CE arbeitet mit prä-emptivem Multitasking Die Anzahl der maximal gleichzeitig laufenden Tasks wird auf 32 begrenzt; wird die Grenze erreicht kann Windows CE eine Applikation schließen Applikationen werden meist in C, C++, Visual Basic mit den Embedded Visual Tools (ohne Aufpreis erhältlich, ähnlich zu Visual Studio) entwickelt; bietet: Source Code und Resource Editor umfangreiche Klassensammlung detailliertes Hilfesystem Debugging Tools Windows CE Emulator Slide 30 Eingebettete Betriebssysteme einige weitere Echtzeit- / embedded Betriebssysteme Ada BeOS ChorusOS ecos FreeRTOS ITRON LynxOS MicroC/OS-II OS-9 OSE OSEK/VDX psos RMX RSX-11 RT-11 RTOS-UH VRTX Slide 31

Inhalt Einführung UNIX Der IEEE 1003 (POSIX) Standard Eingebettete Betriebssysteme RT- Erweiterungen von UNIX/Linux RT- Erweiterungen von Windows Slide 32 RT- Erweiterungen von UNIX/Linux Linux die unter der GNU Public License (GPL) frei verfügbare Implementierung von UNIX ist ein Multiuser Multitasking 32 und 64 Bit POSIX- konformes Betriebssystem Linux wird seit vielen Jahren vor allem auf Internetservern, zunehmend aber auch im Desktop Bereich eingesetzt Unter embedded Linux versteht man eine Zusammenstellung aus einem speziellen für Echtzeit-Anwendungen angepassten Linux Kernel und weiterer Software, die sich aber von der Desktop und Server Version von Linux nicht grundsätzlich unterscheidet Der Name Linux bezieht sich genaugenommen auf den Betriebssystemkernel; Werkzeuge und Software, die darauf aufsetzen, stammen aus dem GNU Projekt, sind unter der GPL frei verfügbar und auf anderen UNIX Systemen (teilweise sogar auf Windows) lauffähig Slide 33

RT- Erweiterungen von UNIX/Linux Es gibt zwei verschiedene Ansätze für Realzeit Erweiterungen: (1) Veränderung der Linux Kernel-pre-emption Strategie Ausgangsüberlegung: Die Ausführungszeit des längsten Code- Abschnitts des Linux Kerns, der ununterbrechbar ausgeführt werden muss, definiert die kürzeste garantierbare Latenzzeit für Interrupts Ansatz: Verringerung der Längen der ununterbrechbaren Code- Abschnitte Zusätzlich: Optimierung des Zeitaufwands des Schedulers Problem: Die Bestimmung des "längsten Code-Abschnitts" ist nicht sicher möglich, daher können keine echten Garantien gegeben werden da täglich Patches zum Kernel hinzugefügt werden, würde sich ein prohibitiver Aufwand ergeben, immer wieder den längsten Pfad zu bestimmen nicht alle möglichen Pfade können überhaupt betrachtet werden Dieser Ansatz ist also nur für weiche Echtzeitanforderungen geeignet Slide 34 RT- Erweiterungen von UNIX/Linux (2) Interrupt-Abstraktion (micro-kernel system) Einschieben einer Schicht zwischen Hardware und Linux, welche Interrupts und wesentliche Prozessor- Features behandelt, sowie das Scheduling übernimmt (max. ca 64 k an Code, der für die Interrupt- Latenzgarantie untersucht werden muss) Das Linux-System bleibt (fast) unverändert Aber: Realzeit-Applikationen müssen als kernel-loadable modules entwickelt werden (keine Schutzmechanismen vorhanden) API der real-time Erweiterungen von POSIX stehen zur Verfügung es gibt zwei wesentliche Implementierungen: RTLinux (von Universität Mexico und von FSMLabs Inc. lizensiert) RTAI (Real Time Application Interface, von Universität Mailand, unter GPL) Dieser Ansatz ist für harte Echtzeitanforderungen geeignet http://www.linuxdevices.com/articles/at7005360270.html http://bernia.disca.upv.es/rtportal/comparative/rtl vs rtai.html Slide 35

RT- Erweiterungen von UNIX/Linux Die Grundidee von RTLinux (Virtualisierung von Interrupts in einem RT- HAL (real-time hardware abstraction layer)) wurde im März '96 publiziert Am 30.11.'99 wurde darauf das US-Patent: Adding real-time support to general purpose operating systems (US 5,995,745) erteilt 1999 erfolgte Gründung der FSMLabs, Inc. zur kommerziellen Nutzung von RTLinux obwohl FSMLabs die Nutzung von RTLinux erlaubt ist eine "ernsthafte" (langfristig ungestörte) industrielle Nutzung kaum möglich, da die Nutzung des RT-HAL jederzeit beschränkt bzw. Lizenzkosten eingeführt werden könnten RTAI (Real-Time Application Interface) wurde ab etwa 1998 am Dipartimento di Ingegneria Aerospaziale Politecnico di Milano (DIAPM ) als frei verfügbarer Konkurrent zu RTLinux entwickelt In RTAI wird der patentierte RT- HAL durch ein frei verfügbares System namens ADEOS (Adaptive Domain Environment for Operating Systems) ersetzt Slide 36 RT- Erweiterungen von UNIX/Linux Grundprinzipien von RTLinux und RTAI Virtualisierung der Interrupt-Hardware: Interrupts werden in Nachrichten umgesetzt, die zielgerichtet zugestellt werden RT-Applikationen müssen sich für Interrupts registrieren (rt_request_global_irq()), um diese empfangen zu können Bei Eintreffen eines Interrupts im RT- HAL: für RT-Applikation: Zustellung des Interrupts an die beanspruchende RT-Applikation (Aufruf des installierten Handlers) ansonsten: Zustellung an Linux-Kern (wenn dieser Interrupts temporär verboten hat Warteschlange) Das klassische (unveränderte) Linux-System (Kern und Nutzerprozesse) wird zu einer RT-Task mit niedrigster Priorität Beachte: die RT Tasks müssen genügend Zeit "übrig lassen", damit das klassische Unix noch zur Ausführung kommt Slide 37

RT- Erweiterungen von UNIX/Linux Vgl. Kapitel 4 Folie 113, 114 Grundprinzipien von RTLinux und RTAI (Fortsetzung) Alle RT- Komponenten (RT-Scheduler, RT- Applikationen, HAL) sowie der Linux-Kern werden im Kernel-Mode abgearbeitet: die Kernel-API des Linux Kerns ist für RT-Module nutzbar keine Adressraumwechsel zwischen RT-Applikationen (Vermeidung von Paging) gesamtes System modular aufgebaut direkter Zugriff auf Hardware aus RT-Applikationen Achtung: gegenseitige Abschottung der RT-Applikationen fehlt; jeder Programmfehler ist fatal Schnittstelle zum Linux-Kern für zeitunkritische Aktionen In Praxis werden Applikationen so aufgeteilt, dass nur die Realzeitanteile als Kernel-Module implementiert werden, der Rest als Prozesse im klassischen Linux User-Space RTAI: http://www.aero.polimi.it/ rtai RTLinux: http://www.fsmlabs.com/index.html Slide 38 RT- Erweiterungen von UNIX/Linux Struktur eines RT- Linux Systems Slide 39

RT- Erweiterungen von UNIX/Linux Installation eines RT- Linux (Prinzip): 1. Standard-Kern-Quellen und RT-Quellen herunterladen 2. Kern patchen entweder für proprietäres RT-HAL oder für freies ADEOS 3. Kern übersetzen, installieren 4. RT-Linux konfigurieren 5. RT-Linux übersetzen und installieren Slide 40 Inhalt Einführung UNIX Der IEEE 1003 (POSIX) Standard Eingebettete Betriebssysteme RT- Erweiterungen von UNIX/Linux RT- Erweiterungen von Windows Slide 41

RT-Erweiterungen von Windows Ein deterministisches Zeitverhalten ist unter den Betriebssystemen Windows (NT, 2000 oder XP) nur mit dezidierten Echtzeit-Subsystemen realisierbar. Bei reinen Windows-Lösungen muss aufgrund des Betriebssystemmanagements mit erheblichem Jitter (statistisches Zeitverhalten) gerechnet werden. Beispiel: Windows XP Tasks welche der niedersten Prioritätsstufe zugeordnet sind, werden typischerweise mit einer 10 msec Unterbrechung nach dem Zeitscheiben-Verfahren (Round Robin) abgearbeitet Höchstpriorisierte Tasks werden nicht-präemptiv abgearbeitet, und verhindern somit ein deterministisches Zeitverhalten. Das XP-Multitasking ist für eine optimale Overall-Performance ausgelegt, jedoch nicht für Prozessbearbeitung in Echtzeit. Slide 42 RT-Erweiterungen von Windows Beispiel: SHA (Sybera Hardware Access von SYBERA) für Windows (NT, 2000, XP, XP Embedded, CE) Eine Realtime-Engine, die eine vollständige Abkopplung der Realtime- Task zum bestehenden Betriebssystem umsetzt und so Jitter minimiert und auch bei extremer CPU-Belastung zeitstabil bleibt. Mit der SHA X-Realtime-Engine sind Echtzeit-Task-Zyklen bis zu 10µsec realisierbar. Ein integriertes Watchdog-System überwacht die Echtzeittask und ermittelt die verbleibende Task-Zeit. Das SHA X-Failsafe-System bietet zusätzlich die Möglichkeit, auch bei schweren Ausnahme-Fehlern (z. B. Blue-Screen) das System mit einer Rescue-Task aktiv zu halten oder kontrolliert zu beenden. Der Entwickler arbeitet mit dem SHA System innerhalb seiner gewohnten Entwicklungsumgebung (z. B. Visual C++). Zugriff auf alle Hardware-Resourcen direkt von der Applikationsebene. IO-Portzugriffe, Mapped Memory, Timer- und Interrupt-Steuerung Slide 43

RT-Erweiterungen von Windows CeWin und VxWin von KUKA Echtzeitfähige und hardwarenahe Programmierung unter Windows XP und 2000 Reaktionszeiten im Mikrosekundenbereich Hochauflösender Echtzeit-Timer zahlreiche Software und Treiber auf dem Markt verfügbar Leistungsfähige Realtime-Analysetools Integration von Windows CE Software unter Windows 2000/XP (CeWin) Integration von VxWorks Software unter Windows 2000/XP (VxWin) Slide 44