Startseite


Communities: 
  • Hardware-FAQ
  • Diskussionsforen
  • RC5-72 Projekt
  • RC5-Proxy
  • Forenarchiv

  • RTOS - Echtzeitbetriebssysteme

    Der Begriff 'ECHT-ZEIT' drückt aus, dass die mit diesem Begriff verbundene Datenverarbeitung die Zeit als Physikalische Grösse in die Datenverarbeitung einbezieht. Datenverarbeitung 'in Echtzeit' erfolgt mit fester zeitlicher Bindung an die aktuelle, erlebbare Zeit d.h. dass die Echtzeit-Datenverarbeitung Daten verarbeitet und produziert, die stets einen zeitlichen Bezug zur realen Welt haben.

    Echtzeitbetriebssystem/RTOS (Real Time Operating Systems):

    Nach DIN gilt ein Computersystem als echtzeitfähig, wenn es innerhalb einer benenn- und garantierbaren Zeit auf zufällige, externe Ereignisse reagieren kann. Über die Größe dieser Zeit sagt die Norm nichts aus. Im industriellen Steuerungsumfeld sind Reaktionszeiten im Mikrosekundenbereich ein unbedingtes muss. So haben zum Beispiel die hauptsächlich in der VME-Bus Welt oder in Embedded-Systemen eingesetzten ,,harten' Echtzeit-Betriebssysteme typische Reaktionszeiten von 5 bis 60 Mikrosekunden. Um diese Eigenschaften erfüllen zu können sind einige grundlegende Voraussetzungen notwendig:

    Deadlines einhalten:
     
    Wenn ein Ereignis eintritt muss eine Aktion in einer vorbestimmten Zeitspanne erfolgen. Kann eine Deadline nicht eingehalten werden, tritt ein (fataler) Softwarefehler auf.

    Gleichzeitige oder simultane Verarbeitung:
     
    Wenn mehr als ein Ereignis gleichzeitig eintritt, müssen dennoch alle Deadlines für alle Ereignisse eingehalten werden. Dies bedeutet, dass ein Echtzeitsystem einen inhärenten Parallelismus haben muss. Dies wird durch Verwendung von mehreren Prozessoren erreicht und/oder der Verwendung einer MultiTask Lösung.

    Ein Betriebssystem, welches Echtzeitverhalten haben will muss bestimmte Forderungen erfüllen:

    - Garantie der geforderten Rechenzeitigkeit und Gleichzeitigkeit - Management und Hardwaresteuerung (Gerätetreiberverwaltung)

    - Sicherstellung der Unterbrechungsfähigkeit (Interruptverwaltung)

    - Sichere Verwaltung der Rechenprozesse und des Systemspeichers (Taskverwaltung)

    - Definierte Reaktion auf Fehlerzustände (Fehlerverwaltung - und behandlung)

    - Bereitstellung der Resourcen zur Taskkommunikation und Synchronisation

    - Bereitstellung von Resourcen zur Steuerung zeitlicher Abläufe


    Aufbau eines Echtzeitbetriebssystems:

    Ein Echtzeitsystem besteht aus einem Rechnerteil (Hardware), einem Echtzeitbetriebssystem mit den für die Anwendung angepassten Bestandteilen, und der Applikationssoftware. Die Applikationssoftware beinhaltet in der Regel die Anwendung, d.h. dort werden die vom Anwender gewünschten Aufgaben ausgeführt. Diese drei Komponenten müssen im Zusammenspiel das beschriebene Antwortverhalten, d.h. den zeitlichen Determinismus garantieren. Hier gilt je 'härter' die zeitlichen Anforderungen sind, desto schneller muss die eingesetzte Hardware sein, oder desto simpler muss das eingesetzte Betriebsystem sein.

    Echtzeitbetriebssysteme besitzen einen Microkernel. Dies ist im Prinzip ein hardwareunabhängiger effizienter Scheduler mit präzise definierten Schnittstellen. Das Echtzeitbetriebssystem bildet eine Schale um den Microkernel, die von Applikationsprogrammen nicht durchdrungen wird. Der Microkernel beinhaltet die System Uhr, den Scheduler (Taskmanager) und die Semaphorenverwaltung. Er steuert die Rechenprozesse des Rechensystems und realisiert das Ablaufen der Rechenprozesse. Wird eine Task erzeugt, d.h. dem Kern bekannt gemacht, laufen verschieden Aktionen gleichzeitig ab.

    Eine Task ist organisatorische Einheit, die aus ausführbarem Programmcode, eigenem Speicher und Variablen besteht und ist gekennzeichnet durch eine Priorität und eienm Taskzustand. Es kann auch als eine lebendige Einheit die eine gewisse Lebensdauer hat und je nach Notwendigkeit auch wieder aus dem System genommen werden kann, angesehen werden.

    Die Task wird mit ihrer Priorität in eine Kernelliste eingetragen. Der Kern verwaltet mehrere Listen und für den richtigen zeitlichen Ablauf wird eine 'Ready Queue' angelegt, die die einzelnen ablaufbereiten Tasks beinhaltet. Manipuliert der Kernel einer seiner Listen aufgrund bestimmter Ereignisse, so tritt er in den 'Kernel State'. Verlässt der Kernel den Kernel State so wird der Scheduler aktiviert. Der Scheduler arbeitet mit einem Scheduling Algorithmus und steuert die verschiedenen Rechenprozesse. Der Scheduler prüft anhand der Ready Liste welche Task die CPU zugeteilt bekommt. In Prioritätsgesteuerten Systemen bekommt diejenige Task die CPU zugeteilt, die ablaufbereit ist und die höchste Priorität besitzt.

    Intertask Communication:
     
    Das ist der Datentransfer zwischen Tasks. Es wird zwischen Synchroner und Asynchroner Kommunikation unterschieden.
    Im erste Fall geht der Kommunikation eine Synchronisation voraus, die fordert dass die kommunizierende Tasks zu einem bestimmten Zeitpunkt eine bestimmte Stelle ihres Programmcodes durchlaufen. Nach erfolgter Synchronisierung kann die Kommunikation stattfinden.
    Die Asynchrone Kommunikation läuft über Pufferspeicher ab, die von einem Rechenprozess (Produzent) gefüllt und von einem oder mehreren anderen Rechenprozessen (konsument) geleert werden. Die beiden Aktionen erfolgen ohne zeitliche oder logische Verkopplung.

     
    Memory Management (Speicherverwaltung):

    Die Speicherverwaltung beeinflusst die Effizienz eines Echtzeitbetriebssystems sehr stark. Bei der Speicherverwaltung muss in mindestens zwei oder bei entsprechenden Echtzeitbetriebssysteme n sogar in drei Arten unterschieden werden:

    - Speicherzuweisung beim Kompilieren und statischem binden der Programme
    - Speicherverwaltung bei dynamischen Binden (Dynamic Linker)
    - Speicherverwaltung zur Laufzeit

    Der erste Speicherverwaltung ist in der Regel die Aufgabe des Compilers und Linkers und unterscheidet das Echtzeitbetriebssystem nicht prinzipiell von herkömmlichen Betriebssystemen.
    Der zweite Speicherverwaltung aufgeführte Aufgabe ist hingegen beschränkt auf Echtzeitbetriebssysteme. Hierzu sind z.B. in VxWorks eine Reihe von speziellen Listen und Mechanismen notwendig, um den im System vorhandenen Arbeitsspeicher zur Laufzeit mit Programmcode zu füllen. Der letzte Speicherverwaltung gewinnt vor allem für die Programmiersprache C an Bedeutung. Dort sollen entsprechende Routinen so geschrieben sein, dass sie zur Laufzeit allokierte, d.h. belegte oder reservierte Speicher, nach Beendigung der Aufgabe wieder freigeben. Hier liegt die Hauptaufgabe des Betriebessystems, das den System Memory Pool, d.h. den gesamten dem System zur Verfügung stehenden Speicher, verwalten muss.
     
    Interrupt (Fehlerbehandlung):

    Die Sprachmittel zur Reaktion und Nutzung von sogenannten asynchronen Ereignissen wie z.B. Interrupt, Signale, spezielle Elemente zur zeitlichen Steuerung und Behandlung von Ausnahmen, zeichnen Echtzeitsysteme aus. In der gezielten Nutzung dieser Sprachmittel besteht wohl der Hauptunterschied zur Programmierung in gewöhnlichen 'Betriebssystemen'. Je nachdem um welches Sprachmittel es sich handelt wird der reguläre Programmablauf von externen (Interrupts) oder internen Ereignissen (Signalen) unterbrochen. Interrupts sind im Prinzip elektrische Signale, die direkt oder über sogenannte Interrupt Controller an die CPU gemeldet werden. Setzt man voraus, dass Echtzeitsysteme für kürzeste Reaktionszeiten konstruiert sind, so muss jeder externe Interrupt in der Lage sein, die aktuell ablaufende Task zu unterbrechen.

    Die Zeit, die vom Anlegen des Interrupts bis zum Start der entsprechenden Interrupt-Serviceroutine vergeht, nennt man 'Interrupt-Latenzzeit'. Sie wird oftmals zum Vergleich der verschiedenen Echtzeitsysteme herangezogen. Typische Interrupt-Latenzzeiten liegen bei heutigen Echtzeitbetriebssystemen im Bereich um die 10 Mikrosekunden. Sie hängen natürlich neben der Effizienz des Betriebssystems wesentlich von der eingesetzten CPU ab.

    Ein Betriebssystem sollte in der Lage sein, den Großteil aller Softwarefehler, die sich direkt auf das Gesamtsystem auswirken, so abzufangen, dass zumindest noch eine Meldung über den Grund des Fehlers am Bildschirm erscheint.

    Timer (Synchronisation zwischen Tasks):

    Echtzeitsysteme sind meist Multitasking-Systeme. Dort fordert der zu steuernde Prozess in zahlreichen Fällen die parallele Bearbeitung von Rechenprozessen. Für die CPU (im Falle einer mono-processing Einheit) gibt es nur die sequentielle Bearbeitung von Rechenprozessen.


    Möglichkeiten der Synchronisation:

    Synchronisation der Rechenprozesse auf der CPU z äußeren Abläufen im zu steuernden Prozess: Diese Synchronisation stimmt den Ablauf der Rechenprozesse mit ihren zeitlichen und logischen Anforderungen mit dem Ablauf des technischen Prozesses ab. So wird z.B. ein Rechenprozess für das Einlesen von Daten blockiert bis alle Daten eingelesen sind. Würde man den Einleseprozess nicht warten lassen bis die Daten vollständig sind, so würde die weitere Verarbeitung mit einem unvollständigen Satz Daten arbeiten, was mit Sicherheit zu Fehlern führen würde.

    Synchronisation der Rechenprozesse untereinander zur gemeinsamen Verwendung von Betriebsmitteln: Diese Synchronisierung bedeutet einfach ausgerückt, dass ein Rechenprozess so lange blockiert wird, bis ein zweiter Rechenprozess mittels eines entsprechenden Signals meldet, dass er am Synchronisationspunkt angekommen ist. Synchronisation bedeutet auch hier das Einfügen von Wartebedingungen. Synchronisation heißt für das Echtzeitsystem immer ein Verlust an Performanz, da sich ständig einer oder mehrere Rechenprozesse in einem Wartezustand befinden. Für das Systemdesign folgt daraus, dass die Anzahl der Synchronisierungspunkte innerhalb eines Echtzeitsystems möglichst klein zu halten ist.

    Die Umsetzung der Synchronisation geschieht durch Sprachmittel des Echtzeitbetriebssystems. Je nach Ausstattung besitzt ein Echtzeitbetriebssystem eine Reihe von Konstrukten, die es erlauben, eine beliebige Anzahl von Rechenprozessen während des Ablaufs zu synchronisieren. Effiziente Echtzeitbetriebssysteme zeichnen sich durch sehr wenige zusätzliche Verwaltungs-software aus. Das bekannteste Sprachmittel zur Synchronisation von Rechen- prozessen sind die sogenannten Semaphoren (Ursprung ital. Semaphoro bedeutet Ampel). Dabei funktionieren Semaphoren ähnlich wie Ampeln. Stellt man sich eine Kreuzung als gemeinsame Resource mehrerer Fahrzeuge vor, so müssen diejenigen Fahrzeuge, die abbiegen wollen, an der roten Ampel warten, bis der Geradeausverkehr durchgefahren ist. Entsprechendes gilt bei der umgekehrten Ampelschaltung. Genauso verhält es sich mit Semaphoren. Ein Rechenprozess A muss warten bis die Semaphore 'grünes Licht' anzeigt. Da Rechenprozesse keine Signalleuchten verstehen, hat man sich auf folgende Semaphorenoperationen und Definitionen zur Synchronisation von Rechenprozessen geeinigt:

    Semaphorvariablen SV sind Ganzzahlen aus dem Bereich von null bis unendlich. Auf die Menge der Semaphoren werden zwei mathematische Operationen definiert.

    Inkrementieren um l, auch mit V(SV) bezeichnet; je nach Definition der SV kann sie nur die Werte 0 und 1 annehmen (Binäre Semaphore). In diesem Fall hätte das Inkrementieren einer auf 1 gesetzten Semaphore keinen Effekt. Daneben gibt es noch sogenannte 'Counting Sema- phoren', die beliebig oft inkrementiert werden können.

    Dekrementieren um l und Überprüfung auch mit P(SV) bezeichnet; ist der Wert von SV nach erfolgter Operation positiv, so wird SV um eins erniedrigt. Würde der Wert -1 werden so wird die Operation nicht ausgeführt. Genau für diesen Fall würde der Rechenprozess, der die Dekrementierung vornehmen wollte, blockiert werden.

    Da Rechenprozesse unter den genannten Umständen auf eine Semaphore blockieren, muss die Verwendung von Semaphoren sehr sorgfältig geplant werden. Insbesondere im Verlauf der Programmentwicklung können sich unvorhergesehene Zustände einstellen, die dazu führen, dass Rechenprozesse ungewollt blockieren. Daraus kann sich für das Gesamtsystem ein Fehlerzustand ergeben aus dem das System ohne Hilfe nicht mehr heraus kommt. Man bezeichnet derartige Zustände als 'Dead Locks', zu deutsch Verklemmungen.
    Aufgrund der Möglichkeit, dass Semaphoren Verklemmungen hervorrufen können, dürfen z.B. innerhalb von Interrupt-Service Routinen (ISR) innerhalb von Systemen wie VxWorks keine Dekremtierungsoperationen P(S) vorgenommen werden. Damit ist sichergestellt, dass eine ISR nicht blockieren kann. Dies ist notwendig, da eine ISR aufgrund ihrer hohen Priorität (höher als alle Rechenprozesse) bei einer Verklemmung mit Sicherheit einen fatalen Systemzustand provozieren würde.


    Treiber- oder Gerätetreiberschicht:

    Das sind Programme, die direkt die Hardware, d.h. Register und Adressen von Bausteinen, ansprechen. Die Qualität der Hardwareunterstützung ist ein wichtiger Faktor für die Realisierung effizienter und schneller Echtzeitsysteme. Solche Architekturen stellen die Portabilität von Echtzeitbetriebssysteme sicher. Es genügt einfach die hardwarenahe Treiberschicht Prozessor zu ersetzen um das Betriebssystem und somit auch die Applikation auf eine neue Plattform zu bringen.
    An dieser Stelle stösst man auf einen weiteren wesentlichen Unterschied im Umgang mit Echtzeitsystemen im Gegensatz zu herkömmlichen Systemen. Das Systemdesign und der Programmentwurf müssen zusätzlich zu der logischen Programmarchitektur den zeitlichen Ablauf mit entsprechenden spezifischen Fehlerquellen berücksichtigen. Hier kann es sehr leicht passieren, dass ein Algorithmus syntaktisch korrekt ist, d.h. in der logischen Simulation die richtigen Ausgangsdaten produziert. Trotzdem kann das Programm insgesamt fehlerhaft sein, da aufgrund von nicht beachteten zeitlichen Randbedienungen, wie z.B. zu kurz zur Verfügung stehende Rechenzeit, das relevante Programmstück nie zur Ausführung kommt, also nie Ausgangsdaten produzieren kann. Für Echtzeitentwickler folgt daraus, dass der zeitliche Entwurf von Echtzeitsystemen mindestens genauso wichtig für das Funktionieren einer Applikation ist wie der Entwurf.

    Weiche und Harte Echtzeitsysteme:

    Die Gültigkeitsdauer von Eingangsdaten bzw. Änderungsgeschwindigkeit von externen Ereignissen bestimmen die zeitlichen Deadlines der Echtzeitsysteme. Man unterscheidet in Harte und Weiche Echtzeitsysteme. Der Unterschied zwischen einem harten und einem weichen Echtzeitsystem besteht aufgrund der Systemanforderungen: es wird hart genannt wenn das Merkmal heißt 'das System soll auf keinen Fall eine Deadline verpassen 'und weich wenn 'das System eine Deadline verpassen darf'.

     
    Die Merkmale eines harten Echtzeitsystems sind:
     
    - unter keinen Umständen dürfen Verzögerungen akzeptiert werden
    - Ergebnisse sind nutzlos wenn sie zu spät erfolgten
    - katastrophale Störungen wenn die Deadline nicht eingehalten wird
    . unendlich hohe Kosten für verpasste Deadlines

    Beispiele für harte Echtzeitsysteme sind:

    - Steuerung eines Kernreaktors
    - Steuerung kritischer chemischer Prozesse
    - Antiblockiersystem
    - Überwachungssysteme auf einer Intensivstation
    - Digitalsteuerung im Airbus Flugzeug

    Charaktere eines weichen Echtzeitsystems:

    - niedrige Kosten beim verspäteten Eintreffen der Ergebnisse
    - Akzeptierung einer geringeren Performance bei einer Verspätung

    Beispiele:
     
    - Werkzeugrevolver
    - digitale Telefonanlage
    - multimediale Anwendungen
    - Steuerung unkritischer chemischer Prozesse
    - Verkaufsautomat
    - Teilsystem einer Netzwerkschnittstellenkarte
     
    Bei letzterem kann, falls ein Paket verloren gegangen ist, der Fehler behoben werden indem das fehlende Paket noch einmal angefordert wird. Wenn so verfahren wird, akzeptiert man auch eine Verringerung der Performance.

    Kriterien zur Auswahl eines RTOS:

    Die erste Frage beim geplanten Einsatz von Echtzeitbetriebssytemen ist die folgende:

    1. Ist ein RTOS-Einsatz überhaupt notwendig?

    Wenn es sich um eine single-Task-Application handelt, besteht kein Grund für den Einsatz eines RTOS. Wenn nur wenig Speicher zur Verfügung steht, z.B. bei einem Hardware-Layout ohne externen Speicher (single-chip), ist ein RTOS-Einsatz fast immer auszuschließen, da der RAM im Normalfall nicht reichen wird.
    Der Einsatz eines RTOS bietet bei Multitaskingsystemen eine Reihe von Vorteilen. So muss das Taskmanagement nicht selbst implementiert werden, sondern steht in Form des Schedulers zur Verfügung. Ein RTOS verlangt darüber hinaus die saubere Strukturierung der Software.

    2. Betriebssystemverhalten muss bekannt sein !

    Zu guter letzt, müssen die Zeitanforderungen in den Entwurf mit einbezogen werden. Der Entwickler muss alle Zeiten für Systemaufrufe und das Systemverhalten in all seinen Variationen kennen. Deshalb sollten die folgenden Angaben vom Echtzeitbetriebssystem-Hersteller bekannt sein:
     
    - Die Interrupt Verzögerungszeit (die Zeit zwischen Interrupt und Tasklaufzeit): diese muss zu den Anforderungen der Anwendung passen   und vorhersagbar sein. Dieser Wert hängt ab von der Anzahl der gleichzeitig eintretenden Interrupts.

    - Für jeden Systemaufruf muss die notwendige Zeit angegeben werden. Diese sollte vorhersagbar und unabhängig sein von der Anzahl der Objekte im System.

    - Die maximale Zeit die das Betriebssystem und die Treiber benötigen um einen Interrupt zu verarbeiten.

    Der Entwickler sollte zusätzlich noch folgende Punkte beachten:

    - System Interrupt Levels
    - Geräte Treiber IRQ Levels, wieviel Zeit benötigen sie, etc.

    Wenn alle Daten bekannt sind, ist es erst möglich ein hartes Echtzeitbetriebssystem auf einem gewählten Betriebssystem aufzusetzen. Nicht unwichtig bei der Entwicklung sind sicherlich auch die Geschwindigkeitsanforderungen an das System. Diese sollten für das gewählte Echtzeitbetriebssystem und die gewählte Hardware geeignet sein.

    Welches ist das geeignete RTOS ?

    Um ein RTOS zu selektieren, muss zuerst ein Anforderungskatalog aufgestellt werden. Dabei wird das Vorhandensein grundlegender RTOS-Eigenschaften (wie z.B Preemptives Multitasking, deterministisches Verhalten, Modularität etc.) nicht extra aufgeführt, sondern als selbstverständlich vorausgesetzt dafür, dass ein Betriebssystem überhaupt als echtzeitfähig eingestuft wird.
    Es ist kein RTOS am Markt verfügbar, das für jede mögliche Applikation die optimale Lösung darstellt. Wichtig ist daher, aus der Projektspezifikation für die geplante Applikation einen Anforderungskatalog abzuleiten, der mit den Möglichkeiten der einzelnen Produkte verglichen wird.
    Diese Auswahl führt - wenn sie systematisch durchgeführt wird schließlich zu einem RTOS, dessen Eigenschaften es am besten für die spezifischen Anforderungen geeignet erscheinen lassen.





    Alle Angaben wie immer ohne Gewährleistung !
    © 2001-2016 Alle Rechte vorbehalten. Mit Urteil vom 12. Mai 1998 - 312 O 85/98 - "Haftung für Links" hat das Landgericht (LG) in Hamburg entschieden, dass man durch die Anbringung eines Links, die Inhalte der gelinkten Seite ggf. mit zu verantworten hat. Dies kann - so das LG - nur dadurch verhindert werden, indem man sich ausdrücklich von diesen Inhalten distanziert. Hiermit distanzieren wir uns ausdrücklich von allen Inhalten aller gelinkten Seiten auf unseren Foren.