Sie sind auf Seite 1von 260

Harte und weiche Echtzeitsysteme

Material zur Vorlesung Echtzeitsysteme I+II im


Studienfach Technische Informatik an der
Hochschule Niederrhein.

Jürgen Quade
Harte und weiche Echtzeitsysteme: Material zur Vorlesung Echtzeitsysteme I+II im Studienfach Technische
Informatik an der Hochschule Niederrhein.
von Jürgen Quade

V2.0, So Jul 11 13:47:06 CEST 2004


Dieses Buch darf unter der Bedingung, dass die eingetragenen Copyright-Vermerke nicht modifiziert werden, kopiert und weiterverteilt
werden. Die kommerzielle Nutzung (Weiterverkauf) ist ohne Zustimmung des Autors bislang nicht erlaubt. Da auch die Quellen des Buches
zur Verfügung stehen, ist die Modifikation, Erweiterung und Verbesserung durch andere Autoren möglich und sogar erwünscht.

$Id: ezsI.sgml,v 1.44 2004/03/18 16:20:18 quade Exp $


$Id: legalnotice.sgml,v 1.3 2001/01/04 21:44:42 quade Exp $
$Id: literatur.sgml,v 1.7 2002/04/22 18:24:23 quade Exp $
$Id: definitionen.sgml,v 1.4 2003/03/27 07:55:08 quade Exp $
$Id: prozess.sgml,v 1.12 2003/04/07 18:44:38 quade Exp $
$Id: realtime.sgml,v 1.47 2004/07/11 11:47:06 quade Exp quade $
$Id: os.sgml,v 1.30 2004/07/11 11:47:06 quade Exp quade $
$Id: programmierung.sgml,v 1.25 2004/07/11 11:47:06 quade Exp quade $
$Id: feldbus.sgml,v 1.8 2003/03/27 07:55:08 quade Exp $
$Id: Multiplex.sgml,v 1.3 2001/01/04 21:44:42 quade Exp $
$Id: sicherheit.sgml,v 1.8 2003/09/27 15:00:48 quade Exp $
$Id: verfuegbar.sgml,v 1.3 2001/01/04 21:44:42 quade Exp $
$Id: algorithm.sgml,v 1.7 2004/07/11 11:47:06 quade Exp quade $
$Id: entwicklung.sgml,v 1.4 2003/03/27 07:55:08 quade Exp $
$Id: distributed.sgml,v 1.4 2003/04/07 18:44:38 quade Exp $
$Id: petri.sgml,v 1.4 2003/04/07 18:44:38 quade Exp $
$Id: socket.sgml,v 1.6 2003/04/07 18:44:38 quade Exp $
$Id: IoSubSystem.sgml,v 1.9 2003/05/05 19:49:02 quade Exp $
$Id: ir.sgml,v 1.5 2001/11/25 14:14:23 quade Exp $

Versionsgeschichte
Version V2.0 $Date: 2004/03/18 16:20:18 $ Geändert durch: $Author: quade $
Inhaltsverzeichnis
Vorwort........................................................................................................................................................ ??
1. Lernziele ......................................................................................................................................... ??
1. Realzeitsysteme Überblick..................................................................................................................... ??
1.1. Definitionen ................................................................................................................................. ??
1.1.1. Prozesse........................................................................................................................... ??
1.1.1.1. Technischer Prozess............................................................................................ ??
1.1.1.2. Rechenprozess .................................................................................................... ??
1.1.1.3. Steuerung............................................................................................................ ??
1.1.1.4. Kognitiver Prozess.............................................................................................. ??
1.2. Kennzeichen von Realzeitsystemen............................................................................................. ??
1.2.1. Ausprägungen von Realzeitsystemen ............................................................................. ??
1.2.2. Einsatzbeispiele............................................................................................................... ??
1.3. Realzeitsystem-Komponenten ..................................................................................................... ??
1.3.1. Abbildung des technischen Prozesses auf Rechenprozesse............................................ ??
2. Schritthaltende Verarbeitung und Echtzeitbetrieb............................................................................. ??
2.1. Echtzeitbedingungen.................................................................................................................... ??
2.1.1. Auslastung....................................................................................................................... ??
2.1.2. Pünktlichkeit ................................................................................................................... ??
2.1.3. Harte und weiche Echtzeit .............................................................................................. ??
2.2. Unterbrechbarkeit und Prioritäten ............................................................................................... ??
2.3. Worst Case Betrachtungen........................................................................................................... ??
2.4. Echtzeitnachweis ......................................................................................................................... ??
2.4.1. Abschätzung der Worst Case Execution Time (WCET) ................................................. ??
2.4.2. Abschätzung der Best Case Execution Time (BCET) .................................................... ??
2.4.3. Echtzeitnachweis bei prioritätengesteuertem Scheduling............................................... ??
2.4.3.1. Grafische Bestimmung der maximalen Reaktionszeit........................................ ??
2.4.3.2. Mathematischer Ansatz ...................................................................................... ??
2.4.4. Echtzeitnachweis bei Deadline-Scheduling.................................................................... ??
2.4.4.1. Ereignisstrom-Modell......................................................................................... ??
2.4.4.2. Behandlung abhängiger Ereignisse .................................................................... ??
3. Realzeitbetriebssysteme ......................................................................................................................... ??
3.1. Lernziele ...................................................................................................................................... ??
3.2. Überblick ..................................................................................................................................... ??
3.2.1. Aufgaben und Anforderungen......................................................................................... ??
3.3. Aufbau und Struktur .................................................................................................................... ??
3.4. Betriebssystemkern...................................................................................................................... ??
3.4.1. Prozess-Management ...................................................................................................... ??
3.4.2. Memory-Management..................................................................................................... ??
3.4.2.1. Segmentierung.................................................................................................... ??
3.4.2.2. Seitenorganisation .............................................................................................. ??
3.4.3. I/O Subsystem ................................................................................................................. ??
3.4.3.1. Gerätezugriff auf Applikationsebene.................................................................. ??
3.4.3.1.1. Schnittstellenfunktionen ........................................................................ ??
3.4.3.1.2. Zugriffsarten .......................................................................................... ??
3.4.3.2. Gerätezugriff innerhalb des Betriebssystemkerns .............................................. ??
3.4.3.2.1. Vorgehen bei der Treibererstellung........................................................ ??
3.4.3.2.2. Interruptbetrieb ...................................................................................... ??
3.4.3.2.3. Kernel-Queues ....................................................................................... ??

iii
3.4.3.2.4. Timer-Queues......................................................................................... ??
3.4.3.2.5. Code-Beispiel......................................................................................... ??
3.4.3.3. Task-Latency ...................................................................................................... ??
3.4.3.4. Filesystem........................................................................................................... ??
3.4.4. Systemcall-Interface........................................................................................................ ??
3.4.5. Services ........................................................................................................................... ??
3.4.6. Bibliotheken .................................................................................................................... ??
3.4.7. Zeitgeber ......................................................................................................................... ??
3.5. Scheduling ................................................................................................................................... ??
3.5.1. Scheduling Points............................................................................................................ ??
3.5.2. Bewertungskritierien ....................................................................................................... ??
3.5.3. First Come First Serve (FCFS) ....................................................................................... ??
3.5.4. Round Robin Scheduling ................................................................................................ ??
3.5.5. Prioritätengesteuertes Scheduling ................................................................................... ??
3.5.6. Deadline-Scheduling....................................................................................................... ??
3.5.7. POSIX 1003.1b ............................................................................................................... ??
3.5.8. Schedulingverfahren in der Anwendung......................................................................... ??
3.5.8.1. Zuteilung von Prioritäten.................................................................................... ??
3.5.9. Scheduling in VxWorks .................................................................................................. ??
3.5.9.1. Verfahren ............................................................................................................ ??
3.5.9.2. Wind Scheduling ................................................................................................ ??
3.5.9.3. Unterschiede....................................................................................................... ??
3.5.10. Systemfunktionen zur Scheduler-Parametrierung......................................................... ??
3.5.10.1. Wind-Scheduling-Funktionen .......................................................................... ??
3.5.10.2. POSIX-Scheduling-Funktionen........................................................................ ??
3.5.11. Codefragment zum Setzen einer Priorität ..................................................................... ??
3.5.12. Der O(1) Scheduler im Linux-Kernel 2.5.xx ................................................................ ??
3.6. Realzeitbetriebssystem versus Standardbetriebssysteme ............................................................ ??
3.6.1. Unterschiede zwischen Realzeit- und Standardbetriebssystemen................................... ??
3.6.2. Realzeiteigenschaften von Standard-Betriebssystemen.................................................. ??
3.7. Standard-Betriebssysteme in Realzeitanwendungen ................................................................... ??
3.8. Realzeiterweiterungen der Standard-Betriebssysteme ................................................................ ??
3.8.1. RT-Linux ......................................................................................................................... ??
4. Prozessankopplung................................................................................................................................. ??
4.1. Übersicht...................................................................................................................................... ??
4.2. Physikalische Ankopplung .......................................................................................................... ??
4.2.1. Übersicht Systembus....................................................................................................... ??
4.2.2. Peripherieanbindung über den Systembus ...................................................................... ??
4.2.2.1. Erfassung serieller Prozesssignale...................................................................... ??
4.2.2.2. Erfassung analoger Prozesssignale..................................................................... ??
4.2.3. Ankopplung der Signale aus dem technischen Prozess .................................................. ??
4.2.3.1. Direkter Speicherzugriff..................................................................................... ??
4.2.3.2. Programmgesteuerter Kanal ............................................................................... ??
4.2.3.3. Interruptbetrieb................................................................................................... ??
4.2.3.4. DMA................................................................................................................... ??
4.2.4. Sonstige Varianten........................................................................................................... ??
4.2.4.1. Gemultiplexte Ein-/Ausgabe .............................................................................. ??
4.2.4.1.1. Datenmultiplex....................................................................................... ??
4.2.4.1.2. Zeitmultiplex.......................................................................................... ??
4.3. Softwaretechnische Ankopplung................................................................................................. ??
4.3.1. Einfache Peripherie ......................................................................................................... ??

iv
4.3.2. Intelligente Peripherie ..................................................................................................... ??
4.3.3. Kommunikationsmodule/Feldbusse................................................................................ ??
4.3.3.1. Grundlagen ......................................................................................................... ??
4.3.3.1.1. Protokolle............................................................................................... ??
4.3.3.1.2. Schichtenmodell der Kommunikation ................................................... ??
4.3.3.1.3. Paketaufbau............................................................................................ ??
4.3.3.1.4. Adressierung .......................................................................................... ??
4.3.3.1.5. Physikalische Verbindungsstrukturen.................................................... ??
4.3.3.1.6. Buszugriffsverfahren.............................................................................. ??
4.3.3.1.6.1. Zentraler Master ........................................................................ ??
4.3.3.1.6.2. Token Protokoll ......................................................................... ??
4.3.3.1.6.3. CSMA/CD ................................................................................. ??
4.3.3.1.6.4. CSMA/CA ................................................................................. ??
4.3.3.1.7. Charakterisierung der Feldbusse............................................................ ??
4.3.3.2. Feldbus-Übersicht............................................................................................... ??
4.3.3.2.1. CAN ....................................................................................................... ??
4.3.3.2.2. PROFIBUS............................................................................................. ??
4.3.3.2.2.1. FMS - Fieldbus Message Specification ..................................... ??
4.3.3.2.2.2. DP - Dezentrale Peripherie........................................................ ??
4.3.3.2.2.3. DP/V1........................................................................................ ??
4.3.3.2.2.4. PA - Process Automation .......................................................... ??
4.3.3.2.3. Ethernet und TCP/IP im Feldbereich..................................................... ??
4.3.3.3. Function Blocks.................................................................................................. ??
5. Programmierung .................................................................................................................................... ??
5.1. Programmiersprachen.................................................................................................................. ??
5.2. Programmiertechnik .................................................................................................................... ??
5.2.1. Kontrollfluß ..................................................................................................................... ??
5.2.1.1. Semaphore .......................................................................................................... ??
5.2.1.1.1. Critical Section....................................................................................... ??
5.2.1.1.2. Prioritätsinversion .................................................................................. ??
5.2.1.1.3. Deadlock ................................................................................................ ??
5.2.1.1.4. POSIX-Funktionen für Mutexe.............................................................. ??
5.2.1.1.5. Schreib-/Lese Locks............................................................................... ??
5.2.1.2. Weitere Schutzmaßnahmen für kritische Abschnitte.......................................... ??
5.2.1.3. Events ................................................................................................................. ??
5.2.1.4. Signals ................................................................................................................ ??
5.2.2. Datenfluß/Inter-Prozess-Kommunikation ....................................................................... ??
5.2.2.1. Mailbox............................................................................................................... ??
5.2.2.2. Shared-Memory.................................................................................................. ??
5.2.2.3. Sockets................................................................................................................ ??
5.2.3. Time triggered versus Event triggered ............................................................................ ??
5.2.3.1. Busy-Loops......................................................................................................... ??
5.2.3.2. Time-Triggered................................................................................................... ??
5.2.3.3. Event-Triggered.................................................................................................. ??
5.2.4. Programmierstil............................................................................................................... ??
5.3. Schritthaltende Programmierung, Echtzeitprogrammierung....................................................... ??

v
6. Echtzeitsysteme in sicherheitskritischen Anwendungen .................................................................... ??
6.1. Zuverlässigkeit und Sicherheit..................................................................................................... ??
6.1.1. Grundlagen...................................................................................................................... ??
6.1.1.1. Motivation........................................................................................................... ??
6.1.1.2. Begriffsbestimmung ........................................................................................... ??
6.1.1.3. Mathematische Grundlagen................................................................................ ??
6.1.1.4. Redundante Systeme .......................................................................................... ??
6.1.1.5. Zuverlässigkeitssteigerung ................................................................................. ??
6.1.1.5.1. RAID...................................................................................................... ??
6.1.2. Fallbeispiele .................................................................................................................... ??
6.1.2.1. Weiche Realzeitsysteme ..................................................................................... ??
6.1.2.1.1. Ausgangslage ......................................................................................... ??
6.1.2.1.2. Buch.de .................................................................................................. ??
6.1.2.2. Harte Realzeitsysteme: Space-Shuttle................................................................ ??
6.1.2.2.1. Systemstruktur ....................................................................................... ??
7. Realzeit-Algorithmen............................................................................................................................. ??
7.1. Bandbreiten Problematik ............................................................................................................. ??
7.1.1. Datenreduktionsverfahren............................................................................................... ??
7.2. Leistungs Problematik ................................................................................................................. ??
7.2.1. Exakte Algorithmen am Beispiel Hashing...................................................................... ??
7.2.1.1. Die Hash-Funktion ............................................................................................. ??
7.2.1.2. Kollisions-Auflösung.......................................................................................... ??
7.2.2. Näherungsverfahren ........................................................................................................ ??
7.2.2.1. Randomisierte Verfahren .................................................................................... ??
7.2.2.2. Heuristische Verfahren ....................................................................................... ??
7.2.2.2.1. Fuzzy-Logik........................................................................................... ??
7.2.2.2.1.1. Mengenoperationen................................................................... ??
7.2.2.2.1.2. Regeln........................................................................................ ??
7.2.2.2.2. Neuronale Netze..................................................................................... ??
7.2.2.2.3. Evolutionsstrategien und Genetische Algorithmen................................ ??
7.2.2.2.4. Simulated Annealing.............................................................................. ??
7.2.2.2.5. Treshold Accepting ................................................................................ ??
7.2.2.2.6. Great Deluge Algorithm (Sintflut) ......................................................... ??
7.2.2.3. Bewertung........................................................................................................... ??
8. Verteilte Systeme .................................................................................................................................... ??
8.1. Mehrprozessorsysteme ................................................................................................................ ??
8.2. Mehrrechnersysteme.................................................................................................................... ??
8.2.1. Rechner-Cluster............................................................................................................... ??
8.2.2. Funktionsorientierte Mehrrechnersystemen.................................................................... ??
8.3. Petrinetze ..................................................................................................................................... ??
8.3.1. Netzwerk Analyse ........................................................................................................... ??
9. Systementwurf ........................................................................................................................................ ??
9.1. Die ganzheitliche Betrachtung..................................................................................................... ??
9.2. Host-Target Entwicklung............................................................................................................. ??
Literatur...................................................................................................................................................... ??
Stichwortverzeichnis .................................................................................................................................. ??

vi
Tabellenverzeichnis
3-1. Interrupt Vektor Tabelle des 80386....................................................................................................... ??
3-2. Vergleich Task und Thread.................................................................................................................... ??
3-3. Standard-Betriebssystem versus Realzeit-Betriebssystem.................................................................... ??
4-1. Einteilung von Peripherie gemäß Zugriffsgeschwindigkeit.................................................................. ??
4-2. CAN: Technische Daten........................................................................................................................ ??
4-3. PROFIBUS: Technische Daten ............................................................................................................. ??
5-1. Exemplarische Zeiten der Mars-Pathfinder Tasks................................................................................. ??
5-2. Einsatzmöglichkeiten unterschiedlicher Synchronisationsmethoden................................................... ??
5-3. Unterschiede zwischen Events und Signals .......................................................................................... ??
7-1. Hashfunktion am Telefonbuch-Beispiel................................................................................................ ??
7-2. Vergleich von Simmulated Annealing (SA) mit Treshold Accepting (TA) [Otto 1994] ...................... ??
9-1. Anfoderungen und Lösungsraum.......................................................................................................... ??

Abbildungsverzeichnis
1-1. Steuerung versus Regelung................................................................................................................... ??
1-2. Zusammenhang zwischen unterschiedlichen Prozessformen ............................................................... ??
1-3. Struktur eines Echtzeitsystem ............................................................................................................... ??
1-4. Realzeitsysteme und ihre Zeitanforderungen [TimMon97].................................................................. ??
1-5. Architektur einer Echtzeitsteuerung ..................................................................................................... ??
1-6. Abbildung technischer Prozesse auf Rechenprozesse .......................................................................... ??
1-7. Elemente der Datenflußdiagramme....................................................................................................... ??
1-8. Einfaches DFD einer Carrerabahnsteuerung......................................................................................... ??
1-9. DFD Audiostreaming............................................................................................................................ ??
2-1. Anforderungsfunktion........................................................................................................................... ??
2-2. Auslastung............................................................................................................................................. ??
2-3. Reaktionsbereich................................................................................................................................... ??
2-4. Maximal zulässige Reaktionszeit bei einer Rohrpost ........................................................................... ??
2-5. Rechnerkernbelegung durch 4 Rechenprozesse.................................................................................... ??
2-6. Harte und weiche Echtzeit als Kostenfunktion ..................................................................................... ??
2-7. Benefit-Function ................................................................................................................................... ??
2-8. Datenflußdiagramm Meßwertaufnahme ............................................................................................... ??
2-9. Struktogramm Meßwerterfassung sequentiell ...................................................................................... ??
2-10. Zeitdiagramm Meßwert sequentiell .................................................................................................... ??
2-11. Struktogramm Meßwerterfassung parallel.......................................................................................... ??
2-12. Zeitdiagramm Meßwert parallel ......................................................................................................... ??
2-13. Parameterauswahl für den Worst Case Fall......................................................................................... ??
2-14. Verteilung der Rechenzeit bei minimalen Reaktionszeiten ................................................................ ??
2-15. Abhängige Ereignisse mit variabler Prozesszeit................................................................................. ??
2-16. Beispiel Variable Prozesszeiten: Rechnerkernbelegung ..................................................................... ??
2-17. Meßprinzip zur Bestimmung der WCET............................................................................................ ??
2-18. Grafische Berechnung der maximalen Reaktionszeit ......................................................................... ??
2-19. Maximale Reaktionszeit im Beispiel Variable Prozesszeiten ............................................................. ??
2-20. Bestimmung der maximalen Reaktionszeit ........................................................................................ ??
2-21. Verifikation der Rechtzeitigkeitsbedingung (die Zahlen stammen aus dem Beispiel [Echtzeitnachweis bei prioritätsgeste
??
2-22. Ereignisstrom-Modell ......................................................................................................................... ??
2-23. Ereignisstrom ...................................................................................................................................... ??

vii
2-24. Inhomogener Ereignisstrom................................................................................................................ ??
2-25. Homogener Ereignisstrom .................................................................................................................. ??
2-26. Ereignisdichtefunktion des inhomogenen Ereignisstroms.................................................................. ??
2-27. Ereignisstrom-Modell ......................................................................................................................... ??
2-28. Echtzeitnachweis mit Hilfe des Ereignisstrom-Modells..................................................................... ??
2-29. Prozessbeschreibung und Ereignisdichtefunktion .............................................................................. ??
2-30. Rechenzeitanforderungsfunktion C(I) ................................................................................................ ??
2-31. Rechenzeitanforderungsfunktion C(I) bei verschärften Bedingungen............................................... ??
2-32. Auflösung der Abhängigkeiten ........................................................................................................... ??
2-33. Rechenzeitanforderungsfunktion C(I) ................................................................................................ ??
3-1. Betriebssystem-Architektur .................................................................................................................. ??
3-2. Unterbrechungsebenen.......................................................................................................................... ??
3-3. Interruptverarbeitung ............................................................................................................................ ??
3-4. Interrupt-Service-Routine in einem Realzeitbetriebssystem ................................................................ ??
3-5. ISR mit Scheduler ................................................................................................................................. ??
3-6. Process-Kontrollblock (TCB) ............................................................................................................... ??
3-7. Task-Zustände [Färber94]..................................................................................................................... ??
3-8. Speicherbereiche einer Task.................................................................................................................. ??
3-9. Programm zum Erzeugen einer Task .................................................................................................... ??
3-10. Programm zum Erzeugen eines Threads............................................................................................. ??
3-11. Adreßumsetzung mittels MMU .......................................................................................................... ??
3-12. Segmentierung beim 8086 [Färber94] ................................................................................................ ??
3-13. Beispiel zum Normalisieren................................................................................................................ ??
3-14. Strukturierung der logischen Adresse................................................................................................. ??
3-15. Aufbau eines Seitendeskriptors........................................................................................................... ??
3-16. MMU auf Basis von Seitenadressierung............................................................................................. ??
3-17. Geräteschnittstelle............................................................................................................................... ??
3-18. Expliziter Warteaufruf mit Win32 Interface ....................................................................................... ??
3-19. Asynchroner Zugriff über Threads ..................................................................................................... ??
3-20. Öffnen eines Gerätes im Non-Blocking Mode ................................................................................... ??
3-21. Gleichzeitige Überwachung mehrerer Ein-/Ausgabequellen.............................................................. ??
3-22. Treiberauswahl.................................................................................................................................... ??
3-23. Einbindung des Gerätetreibers in das System..................................................................................... ??
3-24. Datenfluß im System beim Aufruf von fread ..................................................................................... ??
3-25. Gerüst eines Gerätetreibers ................................................................................................................. ??
3-26. Verzögerungszeiten............................................................................................................................. ??
3-27. Lesen über den Buffercache................................................................................................................ ??
3-28. Codebeispiel Systemcall ..................................................................................................................... ??
3-29. Codebeispiel Library-Call................................................................................................................... ??
3-30. Verschiedene Bibliotheksarten............................................................................................................ ??
3-31. Dynamisches Laden von Funktionen während der Laufzeit............................................................... ??
3-32. Zeitanforderungen (Beispiel) .............................................................................................................. ??
3-33. Prinzip des Schedulings ...................................................................................................................... ??
3-34. Prinzip des FCFS Schedulings............................................................................................................ ??
3-35. First Come First Serve Scheduling ..................................................................................................... ??
3-36. Round Robin Schedulings................................................................................................................... ??
3-37. Prioritätengesteuertes Schedulings ..................................................................................................... ??
3-38. Prinzip des Deadline Scheduling ........................................................................................................ ??
3-39. Beispiel für Deadline Scheduling ....................................................................................................... ??
3-40. Realzeiteigenschaften beim Deadline Scheduling .............................................................................. ??
3-41. Posix Scheduling................................................................................................................................. ??
3-42. Beispiel für Wind Scheduling ............................................................................................................. ??

viii
3-43. O(1) Scheduler im Linux-Kernel ........................................................................................................ ??
3-44. RT-Linux Systemarchitektur [Yod99]................................................................................................. ??
4-1. Peripheriekoppelmodule ....................................................................................................................... ??
4-2. Komponenten der Ein-/Ausgabemodule............................................................................................... ??
4-3. Systembus ............................................................................................................................................. ??
4-4. Lesezyklus............................................................................................................................................. ??
4-5. Digitales Eingabemodul........................................................................................................................ ??
4-6. Kontroll- und Statusregister einer seriellen Schnittstelle...................................................................... ??
4-7. Control-Status-Register eines ADC ...................................................................................................... ??
4-8. AD-Wandler Signalverlauf.................................................................................................................... ??
4-9. Ankopplung eines schnellen A/D-Wandlers ......................................................................................... ??
4-10. Ankopplung eines mittelschnellen A/D-Wandlers.............................................................................. ??
4-11. Datenübertragung unter Kontrolle der CPU ....................................................................................... ??
4-12. HW-Struktur eines typischen DMA-Controllers................................................................................. ??
4-13. DMA-Betriebsmodi ............................................................................................................................ ??
4-14. Multiplexer.......................................................................................................................................... ??
4-15. Analogmultiplexer .............................................................................................................................. ??
4-16. Datenmultiplex.................................................................................................................................... ??
4-17. Ansteuerung einer Anzeige im Zeitmultiplex..................................................................................... ??
4-18. Unterschiedliche Adreßlagen beim DP-Ram...................................................................................... ??
4-19. Vereinfachtes Protokoll zum Telefonieren.......................................................................................... ??
4-20. ISO-Schichtenmodell der Kommunikation......................................................................................... ??
4-21. Pakete werden in Pakete verpackt....................................................................................................... ??
4-22. Ausbreitung von Multicastnachrichten ............................................................................................... ??
4-23. Physikalische Verbindungsstrukturen................................................................................................. ??
4-24. Zugriffsverfahren [Färber87] .............................................................................................................. ??
4-25. Kommunikationsprimitive .................................................................................................................. ??
4-26. Buszugriffsverfahren beim Controller Area Network......................................................................... ??
4-27. Aufbau eine CAN-Telegramms .......................................................................................................... ??
4-28. FMS-Kommunikationsmodell beim PROFIBUS................................................................................ ??
4-29. Mehrere logische DP-Netze an einem Strang ..................................................................................... ??
4-30. Abbildung der DP-Kommunikation.................................................................................................... ??
4-31. Realzeitfähige Ethernetstruktur .......................................................................................................... ??
5-1. Elemente eines Zustandsautomaten ...................................................................................................... ??
5-2. Zustandsautomat und Automatentafel .................................................................................................. ??
5-3. DFD des Mars-Pathfinder ..................................................................................................................... ??
5-4. Mars-Pathfinder: Unsynchronisierter Datenaustausch.......................................................................... ??
5-5. Mars-Pathfinder: Rechnerkernbelegung bei Verwendung eines Semaphor .......................................... ??
5-6. Deadlineverletzung beim Mars-Pathfinder ........................................................................................... ??
5-7. Prioritäten und Synchronisation............................................................................................................ ??
5-8. Prioritätsinversion ................................................................................................................................. ??
5-9. Prioritätsvererbung beim Mars-Pathfinder............................................................................................ ??
5-10. Deadlock ............................................................................................................................................. ??
5-11. Meßwerterfassung: Synchronisation ohne Events .............................................................................. ??
5-12. Task A,B und C: Synchronisation durch ein Semaphor...................................................................... ??
5-13. Task W: Synchronisation durch ein Semaphor ................................................................................... ??
5-14. Meßwerterfassung: Synchronisation mit Events................................................................................. ??
5-15. Task A, B und C: Synchronisation über Events.................................................................................. ??
5-16. Task W: Synchronisation über Events ................................................................................................ ??
5-17. Race Condition bei Verwendung von Events...................................................................................... ??
5-18. Basisstruktur einer Socket-Serverapplikation..................................................................................... ??
5-19. Socket-Serverprogramm ..................................................................................................................... ??

ix
5-20. Basisstruktur einer Socket-Clientapplikation...................................................................................... ??
5-21. Socket-Clientprogramm...................................................................................................................... ??
5-22. Warten ................................................................................................................................................. ??
5-23. Ereignis- und zeitgesteuerte Systeme ................................................................................................. ??
5-24. Phasen- und Frequenzunterschiede zwischen Soll- und Istwerten ..................................................... ??
5-25. Prozessnachführung bei einer Modellbahn......................................................................................... ??
5-26. DFD einer zeitsynchronen Verarbeitungseinheit ................................................................................ ??
5-27. Systemarchitektur einer zeitsynchronen Ausgabe .............................................................................. ??
6-1. Zeitverlauf des Systemzustands [Färber94].......................................................................................... ??
6-2. Verfügbarkeitsfunktion [Färber 1994] .................................................................................................. ??
6-3. Badewannenkurve [Färber94]............................................................................................................... ??
6-4. Systemzustand bezüglich der Funktionstüchtigkeit [Färber94]............................................................ ??
6-5. Serienschaltung ..................................................................................................................................... ??
6-6. Parallelschaltung ................................................................................................................................... ??
6-7. Parallelschaltung mit Koppelkomponente ............................................................................................ ??
6-8. Power-fail-Interrupt............................................................................................................................... ??
6-9. RAID-Level 0........................................................................................................................................ ??
6-10. Rechnerstruktur des Webshop buch.de ............................................................................................... ??
6-11. Hardwarestruktur Space-Shuttle ......................................................................................................... ??
7-1. Ergebnis bestimmende Faktoren........................................................................................................... ??
7-2. Zeitanforderungen bei der Internet-Telefonie....................................................................................... ??
7-3. Generalisierter Ablauf eines klassichen Suchverfahren........................................................................ ??
7-4. Lösungsraum......................................................................................................................................... ??
7-5. Black Box.............................................................................................................................................. ??
7-6. Fuzzy Variable mittlere Temperatur...................................................................................................... ??
7-7. Fuzzy Und-Operator ............................................................................................................................. ??
7-8. Fuzzy Oder-Operator ............................................................................................................................ ??
7-9. Fuzzy Nicht-Operator ........................................................................................................................... ??
7-10. Fuzzy-Set Temperatur......................................................................................................................... ??
7-11. Fuzzy-Set Druck ................................................................................................................................. ??
7-12. Fuzzy-Set Ventilstellung ..................................................................................................................... ??
7-13. MAX-MIN Inferenz............................................................................................................................ ??
7-14. Dreischichtiges Neuronales Netz........................................................................................................ ??
7-15. Prinzipieller Aufbau eines neuronalen Netz-Elements ....................................................................... ??
7-16. Das Verfahren der Evolutionsstrategie................................................................................................ ??
7-17. Mutation und Crossover...................................................................................................................... ??
7-18. Evoltionsstrategie am Black Box Beispiel.......................................................................................... ??
7-19. Genetischer Algorithmus .................................................................................................................... ??
7-20. Genetischer Algorithmus am Black Box Beispiel .............................................................................. ??
7-21. Globales Maximum............................................................................................................................. ??
7-22. Globales Maximum............................................................................................................................. ??
7-23. Struktogramm Simmulated Annealing ............................................................................................... ??
7-24. Merkmale von Echtzeitalgorithmen.................................................................................................... ??
8-1. Zwei Transtionen direkt hintereinander sind nicht erlaubt. .................................................................. ??
8-2. Unterschiedliche Übergänge bei Petrinetzen ........................................................................................ ??
8-3. Stellen/Transitionsnetz.......................................................................................................................... ??
8-4. Petrinetz einer Fertigungsstraße [Abel1990] ........................................................................................ ??
8-5. Synchronisation durch ein Petrinetz modelliert [Abel1990] ................................................................ ??
8-6. Zugriff auf ein gemeinsames Betriebsmittel [Abel1990] ..................................................................... ??
9-1. Entwicklungszyklus .............................................................................................................................. ??
9-2. Host/Target Entwicklung ...................................................................................................................... ??

x
Beispiele
2-1. Rohrpostsystem..................................................................................................................................... ??
2-2. Unterbrechbarkeit bei der Meßwerterfassung....................................................................................... ??
2-3. Echtzeitnachweis bei prioritätsgesteuertem Scheduling....................................................................... ??
2-4. Echtzeitnachweis bei Deadline-Scheduling.......................................................................................... ??
5-1. Rekursive und Iterative Berechnung der Fibonacci-Zahlen.................................................................. ??
5-2. Visualisierung einer Modellbahn (I) ..................................................................................................... ??
5-3. Zeitsynchronisierung zwischen Rechnern ............................................................................................ ??
5-4. Voice over IP (VoIP) ............................................................................................................................. ??
5-5. Visualisierung einer Modellbahn (II).................................................................................................... ??
7-1. Hashwert und Hashtabelle [Sedg83]..................................................................................................... ??
7-2. Fuzzy-Regelsatz.................................................................................................................................... ??

Gleichungen
2-1. Gesamtauslastung ................................................................................................................................. ??
2-2. Reaktionszeit......................................................................................................................................... ??
2-3. Rechtzeitigkeitsbedingung.................................................................................................................... ??
2-4. C(t) kleiner gleich t ............................................................................................................................... ??
2-5. Berechnung der Rechenzeitanforderung eines periodisch aufgerufenen Jobs...................................... ??
2-6. Ereignisdichtefunktion eines periodischen Ereignisses ........................................................................ ??
2-7. Rechenzeitanforderungsfunktion.......................................................................................................... ??
6-1. MTBF und MTTR................................................................................................................................. ??
6-2. Dauerverfügbarkeit und Dauerunverfügbarkeit .................................................................................... ??
6-3. Ausfallrate............................................................................................................................................. ??
6-4. Verfügbarkeit in Abhängigkeit von der Zeit ......................................................................................... ??
6-5. Verfügbarkeit einer Serienschaltung ..................................................................................................... ??
6-6. Unverfügbarkeit einer Parallelschaltung............................................................................................... ??

xi
xii
Vorwort
Stellen Sie sich vor, Sie fahren in Ihrem PKW und beauftragen gerade Ihren Boardcomputer damit, per Opti-
mierungsverfahren die günstigste Strecke zu Ihrem Ziel zu finden. Keiner weiß genau warum, aber plötzlich
taucht dieser Baum vor Ihrer Windschutzscheibe auf, zum Bremsen ist es zu spät und schon schraubt sich
Ihr Fahrzeug um den Baum. Sie selbst werden in den Gurt gepreßt, schlagen noch einmal - glücklicherweise
nur leicht - mit dem Kopf auf das Lenkrad auf und fallen dann zurück in den Fahrersitz.
Gerade als Sie sich vom ersten Schreck erholt haben und einmal tief durchatmen, bläst sich mit einem
lauten Knall der Airbag Ihres PKW’s in Millisekundenschnelle auf um kurz darauf gleich wieder in sich
zusammenzufallen.
Dieses - zugegebener maßen leicht makabre - Beispiel zeigt, wie wichtig es ist, dass eine Reihe techni-
scher Systeme fristgerecht (hier hätte sich der Airbag natürlich direkt nach dem Aufprall entfalten müssen,
nicht aber Sekunden später) reagieren. Technische Systeme, die Anforderungen zeitlicher Natur besitzen,
bezeichnet man als Echtzeitsysteme bzw. Realzeitsysteme.
Echtzeitsysteme findet man an vielen Stellen. Die Konzipierung und Realisierung derartiger Systeme stellt
dabei besondere Anforderungen und erfordert den Einsatz spezieller Techniken.
Bei dem vorliegenden Arbeitsbuch handelt es sich um das Begleitmaterial zur Vorlesung Echtzeitsysteme I
und II im Studienfach Technische Informatik an der Fachhochschule Niederrhein.
Ziel der Vorlesung ist dabei die Vermittlung notwendigen Wissens und der notwendigen Technologie, um
Realzeitsysteme konzipieren, realisieren und bewerten zu können.
Obwohl das Material zum gegenwärtigen Zeitpunkt nicht vollständig und insbesondere stilistisch nicht
aufbereitet ist, wird demjenigen, der Realzeitsysteme projektiert, konzipiert und realisiert ein Überblick
über das Thema mit starker praktischer Relevanz gegeben.
Damit der Lesende die Möglichkeit hat, angeführte Beispiele selbst zu erproben, sind diese für das Betriebs-
system Linux ausgelegt.
Die Vorlesung wird seit dem Wintersemester 1999/2000 abgehalten.

1. Lernziele
Folgende Fragen werden behandelt:

• Was sind Echtzeitsysteme?


• Wo werden Echtzeitsysteme eingesetzt?
• Wodurch sind Echtzeitsysteme gekennzeichnet?
• Aus welchen Komponenenten bestehen Echtzeitsysteme?
• Und wie wählt man diese Komponenten aus?
• Wie werden Echtzeitsysteme entwickelt?
• Wie werden Echtzeitsysteme getestet (Echtzeitnachweis)?

Es werden die in der “Echtzeitwelt” gebräuchlichen Begriffe erläutert:

• Hard- und Softrealtime


• Scheduling
• Kontextswitch

i
Vorwort

• Rechnerkern
• Task
• Threads
• Critical Sections
• Race Condition
• Latency-Times
• Schritthaltende Verarbeitung
• Laufzeitsystem
• Feld
• Preemption
• Embedded Systems

ii
Kapitel 1. Realzeitsysteme Überblick

1.1. Definitionen
Realzeit-Steuerungssysteme bestehen aus dem technischen Prozess, den Rechenprozessen und kognitiven
Prozessen. Im folgenden sollen diese Begriffe genauer erläutert werden.

1.1.1. Prozesse
Ein Prozess ist nach [DIN66201] eine "Gesamtheit von aufeinander einwirkenden Vorgängen in einem
System, durch die Materie, Energie oder Information umgeformt, transportiert oder gespeichert wird". Man
spricht von technischen Prozessen, wenn Material oder Energie umgeformt, transportiert beziehungsweise
gespeichert wird, und von Rechenprozessen bei der Umformung, beim Transport beziehungsweise bei der
Speicherung von Information.

1.1.1.1. Technischer Prozess


Ein technischer Prozess ist gekennzeichnet durch (physikalische) Zustandsgrößen. Viele dieser Zustands-
größen können durch Sensoren (Meßwertaufnehmer) erfaßt und durch Aktoren (Stellglieder) beeinflußt
werden. Typische Zustandsgrößen sind Temperatur, Druck, Feuchtigkeit oder Position.
Beispiele für Sensoren:

• Endlagenschalter
• Temperaturmesser
• Winkelgeber
• Füllstandsmesser

Beispiele für Aktoren:

• Motoren
• Ventile
• Relais

Technische Prozesse lassen sich weiter nach der Art der vorwiegend verarbeiteten Variablen klassifizieren
[Lauber 76]. Diese Variablen können sein:

1. Physikalische Größen mit kontinuierlichem oder wenigstens stückweise kontinuierlichem Wertebe-


reich.
2. Binäre Informationselemente, die Ereignissen zugeordnet werden können.
3. Informationselemente, die einzeln identifizierbaren Objekten zugeordnet werden können.

Aus diesen drei Grundtypen leiten sich damit drei Klassen von technischen Prozessen ab:

1
Kapitel 1. Realzeitsysteme Überblick

Fließprozess
Beim Fließprozess, der auch als dynamischer Prozess bezeichnet wird, treten vorwiegend physikali-
sche Größen auf. Die ablaufenden Vorgänge sind zeit- und ortsabhängig. Beispiele für Fließprozesse
finden sich im Bereich der Drucküberwachung und der Energieerzeugung in Kraftwerken.

Folgeprozess
Werden vorwiegend binäre diskrete Informationen verarbeitet, die Ereignisse melden oder auslösen,
spricht man vom Folgeprozess. Derartige Informationen werden beispielsweise bei Aufzugsteuerungen
verarbeitet oder bei Prüfvorgängen von Geräten.

Stückprozess
Stückprozesse schließlich zeichnen sich durch einzeln identifzierbare Stücke (Objekte) aus, die sich
in ihrer Position und/oder ihrem Zustand ändern. Den Objekten werden zeitkontinuierliche oder zeit-
diskrete Werte zugeordnet. Stückprozesse findet man zum Beispiel bei Transportvorgängen, Lagervor-
gängen oder Fertigungsvorgängen.

1.1.1.2. Rechenprozess
Ein Rechenprozess ist der Umformung, Verarbeitung und des Transportes von Informationen gewidmet.
Im Regelfall berechnet er aus Eingabewerten Ausgabewerte. Ein Rechenprozess wird durch ein Programm
beschrieben. Ein Programm beschreibt die Abfolge der Befehle und ist damit zunächst statisch. Die Instanz
eines Programmes (die dynamische Abarbeitung des Programms also) ist dann der Rechenprozess. Anstelle
des Begriffes Rechenprozess wird oft auch der Begriff Task verwendet, insbesondere um eine Verwechse-
lung mit dem technischen Prozess begrifflich auszuschließen.
Moderne Rechnersysteme und vor allem auch Realzeitsysteme sind in der Lage, quasi parallel (in der Rea-
lität jedoch nur sequentiell) mehrere Rechenprozesse gleichzeitig zu bearbeiten (Multitasking).

1.1.1.3. Steuerung
Die Summe der Rechenprozesse und deren Ablaufumgebung (Hardware und Software) wird als Steuerung
bezeichnet.
Die Aufgabe der Steuerung ist:

• Erfassung der Zustandsgrößen des technischen Prozesses.


• Beeinflußung des technischen Prozesses.
• Koordination der Prozessabläufe.
• Überwachung der Prozessabläufe.

Nach [DIN 19226] unterscheidet man zwischen einer Steuerung und einer Regelung je nachdem, ob ein
geschlossener Regelkreis vorliegt oder nicht. Vielleicht weil im Englischen nur das Wort control existiert,
wird im deutschen Sprachgebrauch auch dann oftmals der Begriff Steuerung verwendet, wenn es sich im
eigentlichen Sinn um eine Regelung handelt (z.B. Speicherprogrammierbare Steuerung).

2
Kapitel 1. Realzeitsysteme Überblick

Rechen− technischer Rechen− technischer


prozeß Prozeß prozeß Prozeß
Aktor(−en) Aktor(−en)

1 0
Sensor(−en) 1 0

gesteuerter Prozeß geregelter Prozeß

Abbildung 1-1. Steuerung versus Regelung

Man spricht also von einem geregelten - im Gegensatz zum gesteuertem - Prozess, wenn dieser jeweils
mindestens einen Wandler für ein Ein- als auch ein Ausgangssignal (Aktor und Sensor) besitzt (Bild
Steuerung versus Regelung). Dabei wird der Eingangswert (die Stellgröße) durch den über einen Sensor
gewonnenen Zustandswert des Prozesses beeinflußt.

1.1.1.4. Kognitiver Prozess


Als kognitive Prozesse schließlich bezeichnet man die Verarbeitung, Umformung und den Transport von In-
formationen innerhalb des menschlichen Bedieners. Durch entsprechende Mensch-Maschine-Schnittstellen
(HMI, Human-Machine-Interface) nimmt der Bediener Einfluß auf die Rechenprozesse und auch direkt auf
die technischen Prozesse.
Für die Betrachtung der Rechenprozesse ist es jedoch nicht entscheidend, aus welcher Quelle die zu verar-
beitenden Eingaben kommen. Kognitive Prozesse spielen daher bei den weiteren Betrachtungen eine unter-
geordnete Rolle (und werden wie Eingaben aus dem technischen Prozess behandelt).
Ein Beispiel für einen derartigen kognitiven Prozess ist die Steuerungssoftware des Rangierbahnhofs Nord
in München. Am Rangierbahnhof werden Güterzüge zusammengestellt. Da Güterzüge eine maximale Län-
ge haben, kann es schon einmal passieren, dass nicht alle Waggons mitkommen können. Die Steuerungs-
software ist bewußt so geschrieben worden, dass in diesem Falle ein Mitarbeiter der Deutschen Bahn AG
entscheidet, welche Waggons bevorzugt behandelt werden.

Technischer Kognitiver
Prozeß Prozeß

Sensoren Userinput

Aktoren Visualisierung

Rechen
Prozeß

Abbildung 1-2. Zusammenhang zwischen unterschiedlichen Prozessformen

3
Kapitel 1. Realzeitsysteme Überblick

1.2. Kennzeichen von Realzeitsystemen


Bei einem Echtzeitsystem handelt es sich um ein System, das in der Lage ist, eine Aufgabe innerhalb ei-
nes spezifizierten Zeitfensters abzuarbeiten. Kennzeichen eines Echtzeitsystems ist daher die sogenannte
Pünktlichkeit oder Rechtzeitigkeit und damit insbesondere verbunden die Eigenschaft, zeitlich determini-
stisch (also berechenbar oder zumindest vorhersehbar und vorhersagbar) zu sein. Eine oftmals notwendige
Eigenschaft, aber auf keinen Fall ein Kennzeichen eines Echtzeitsystems ist die Schnelligkeit.

Umwelt
(z.B. technischer Prozeß)

1 0

Echtzeitsteuerung
Wandler (z.B. Aktoren)
(z.B. Sensoren)

Abbildung 1-3. Struktur eines Echtzeitsystem

Echtzeitsysteme (Bild Struktur eines Echtzeitsystem) kann man in allen Bereichen und beinahe überall fin-
den. Prinzipiell verarbeiten sie Eingangswerte (z.B. Zustandsgrößen technischer Prozesse) und berechnen -
zeitgerecht - Ausgangsgrößen (Werte für Stellglieder). Ein- und Ausgangsgrößen werden dem Echtzeitsy-
stem über Wandler (z.B. Aktoren und Sensoren eines technischen Prozesses) zugeführt.
Steuert bzw. regelt das Echtzeitsystem (Realzeitsystem) einen technischen Prozess, ohne dass der Benutzer
direkt damit in Berührung kommt (eingebettete mikroelektronische Steuerung), spricht man von einem
eingebetteten Realzeitsystem. Im Automobil beispielsweise finden sich eingebettete Realzeitsysteme, die
zur Steuerung des Motors (Motormanagement), zur Steuerung des Anti-Blockier-Systems (ABS) oder zur
Überwachung der Airbags zuständig sind.
Weitere Beispiele für Echtzeitsysteme sind die vielfältigen Multimediaanwendungen bis hin zu den schnel-
len Computerspielen, die durch diverse Tricks versuchen, auf nicht echtzeitfähigen Plattformen, wie dem
Windows-PC, Realzeitverhalten zu erreichen.
In vielen Fällen werden Realzeitsysteme im sicherheitskritischen Umfeld (z.B. ABS) eingesetzt. Zu der An-
forderung nach Rechtzeitigkeit gesellen sich damit noch die Forderungen nach Sicherheit (das System muß
auch wirklich das richtige Ergebnis liefern) und Verfügbarkeit (das System darf unter keinen Umständen
ausfallen).

Elektronik Programm RTOS Standard−OS Mechanik Handbetrieb


+ ISR

1 ns 1 us 1 ms 1s 10 s 100 s 1000 s

Abbildung 1-4. Realzeitsysteme und ihre Zeitanforderungen [TimMon97]

4
Kapitel 1. Realzeitsysteme Überblick

Gemäß der obigen Definition sind also alle Systeme mit zeitlichen Anforderungen Echtzeitsysteme. Bild
Realzeitsysteme und ihre Zeitanforderungen [TimMon97] spiegelt entsprechend der Zeitanforderungen
sinnvolle Realisierungstechnologien wider. Dabei erkennt man, dass Echtzeitsysteme sogar von
Hand betrieben werden können, wenn Reaktionszeiten im Stundenbereich gefordert werden.
Muß auf eine zeitliche Anforderung im Minutenbereich reagiert werden, kann man mechanische
Steuerelemente einsetzen. Mit Standard-Betriebssystemen ist es bereits möglich, Realzeitanforderungen
im Sekundenbereich zu bedienen. Sind die Zeitanforderungen jedoch noch strenger, wird man ein
Realzeitbetriebssystem einsetzen, zumindest, solange die Anforderungen nicht im Mikrosekunden-Bereich
(usec) liegen. In diesem Zeitbereich lassen sich die Probleme zwar noch mit Software lösen, entsprechende
Reaktionen müssen aber innerhalb der sogenannten Interrupt-Service-Routine erfolgen. Um noch stärkere
Anforderungen zeitlicher Natur zu befriedigen, muß man schließlich eine Hardware-Realisierung wählen.
Im folgenden wird der Schwerpunkt auf Realzeitsysteme liegen, deren Zeitanforderungen im
Millisekunden-Bereich liegen, zu deren Realisierung im Normalfall ein Echtzeitbetriebssystem eingesetzt
wird. Während aber auch das Spektrum der Echtzeitsysteme mit noch höheren Anforderungen betrachtet
wird, werden Systeme auf mechanischer Basis bzw. Systeme mit Handsteuerung außer acht gelassen.

• Zusammenfassend lauten die wichtigsten Anforderungen an Echtzeitsysteme:

• Pünktlichkeit
• Rechtzeitigkeit
• Deterministisch
• Sicherheit
• Verfügbarkeit

1.2.1. Ausprägungen von Realzeitsystemen


Wie bereits im vorhergehenden Abschnitt deutlich wurde, gibt es unterschiedliche Ausprägungen von Echt-
zeitsystemen. Diese Ausprägungen lassen sich vor allem bezüglich ihrer Hardware klassifizieren.

• (Speicherprogrammierbare-) Steuerungen
• Eingebettete Systeme (embedded systems)
• RZ-Applikationen auf Standardarchitekturen
• Realzeitkommunikationssysteme

Speicherprogrammierbare Steuerungen (SPS)


Speicherprogrammierbare Steuerungen sind klassische Realzeitsysteme, die insbesondere auch als
harte Realzeitsysteme eingesetzt werden. SPS’n werden im Regelfall über spezielle Programmier-
sprachen und -Werkzeuge programmiert und arbeiten in einem festen Zeitraster (Zykluszeit).

Eingebettete Systeme
Als ein eingebettetes System bezeichnet man die Steuerung eines technischen Prozesses, mit der der
Benutzer nur indirekt in Verbindung kommt:
• Bei einem eingebetteten System handelt es sich um eine integrierte, mikroelektronische Steuerung.
• Die Steuerung ist Teil eines Gesamtsystems (in das Gesamtsystem eingebettet).
• Das System besteht aus Hard- und aus Software.
• Das System wurde für eine spezifische Aufgabe entwickelt.
• Das Mensch-Maschine-Interface ist im Regelfall eingeschränkt.

5
Kapitel 1. Realzeitsysteme Überblick

• Eingebettete Systeme weisen keine (kaum) bewegten Teile auf (diskless, fanless).
• Sie decken ein breites Einsatzspektrum ab.

So stellt ein Handy ebenso ein eingebettetes System dar, wie das Modem, das ABS, die Waschmaschi-
nensteuerung und der Gameboy.
Echtzeitsysteme - oder Realzeitsysteme - werden im amerikanischen vielfach gleichgesetzt mit den
eingebetteten Systemen (embedded systems). Diese Sichtweise ist jedoch zu einfach. Wenn auch die
meisten eingebetteten Systeme Realzeitsysteme sind, so doch nicht ausschließlich alle. Nicht jedes
eingebettete System ist ein Realzeitsystem, und nicht jedes Realzeitsystem ist ein eingebettetes System.
Eingebettete Systeme - mit ihren zusätzlichen Anforderungen - spielen auch in dem vorliegenden Buch
eine besondere Rolle.

RZ-Applikationen auf Standardarchitekturen (auch Soft-SPS)


Zwar für harte Realzeitsysteme nicht geeignet, werden Standardarchitekturen, wie beispielsweise eine
PC-Architektur, zur Lösung von weichen Echtzeitproblemen eingesetzt. Typische Beispiele dafür sind
Multimediaanwendungen und "Telefonieren über das Internet" (Voice over IP).
Vorteile:
• Preiswerte Hardware
• Verfügbarkeit von Zusatz-Hardware
• Verfügbarkeit von Standard-Software zur Weiterverarbeitung aufgenommener Zustandsgrößen

Nachteile:

• Preiswerte Hardware ist im rauhen Umfeld, in dem Echtzeitsysteme betrieben werden, nur einge-
schränkt einsatzfähig.
• Standard-Betriebssysteme bieten kein kalkulierbares Realzeit-Verhalten.

Realzeitkommunikationssysteme
Realzeitkommunikationssysteme stellen eine Komponente eines verteilten Realzeitsystems dar.
Einzelne Realzeitprozesse tauschen über diese Komponente mit deterministischem Verhalten
Informationen aus.

1.2.2. Einsatzbeispiele

• Consumer

• Waschmaschine
• Fotoapparat
• Luft- und Raumfahrt
• Satellitensteuerung

6
Kapitel 1. Realzeitsysteme Überblick

• Autopilot
• GPS
• Automatisierungstechnik
• Fertigungsstraße
• CNC-Maschine

• SOHO (Small Office Home Office)


• Scanner
• Drucker
• Telefon/Handy

• Automotive
• Anti-Blockier-System
• Airbag
• Motorsteuerung

• Sonstiges
• Barcode-Leser
• Speicheroszilloskop
• Voice over IP
• Multimedia
• Computerspiele

1.3. Realzeitsystem-Komponenten
Realzeitsysteme bestehen aus unterschiedlichen Komponenten. Je nach Ausprägung des Realzeitsystems
sind dabei nicht alle Komponenten notwendig. So wird beispielsweise bei einem Computerspiel in den
seltensten Fällen eine Prozessperipherie benötigt.

Applikation

Regel− und Visualisierung


Steuerprogramm

Realtime Operating System

Hardware

Prozeßankopplung

direkte Kopplung Prozeßperipherie


oder Feldbus (Sensoren, Aktoren)

Abbildung 1-5. Architektur einer Echtzeitsteuerung

7
Kapitel 1. Realzeitsysteme Überblick

Die Komponenten eines Realzeitsystems sind:

• Applikation
• Verarbeitungs- bzw. Steuerungsalgorithmen
• Visualisierung (HMI=Human-Man-Interface)

• Echtzeitbetriebssystem
• Rechnerhardware
• Prozessankopplung (entweder direkt oder über Realzeit-Kommunikationssysteme/Feldbusse)
• Prozessperipherie

Ein Realzeitsystem verarbeitet fristgerecht Eingangssignale zu Ausgangssignalen. Dazu werden auf lo-
gischer Ebene externe Prozesse 1 (z.B. ein technischer Prozess) auf sogenannte Rechenprozesse (siehe
Abschnitt Rechenprozess) abgebildet, die auf einer Hardware (Rechner, Mikrokontroller) ablaufen. Die
Eingangswerte der Rechenprozesse korrespondieren mit Signalen des externen Prozesses. Wandler (Meß-
wertaufnehmer, Sensoren) transformieren dabei diese (physikalischen) Signale und Werte in maschinell
verarbeitbare Digitalwerte. Entsprechend werden die von den Rechenprozessen erzeugten Ausgangs- bzw.
Ausgabewerte über Wandler (Stellglieder, Aktoren) in (physikalische) Größen transformiert, mit denen sich
der externe Prozess beeinflussßen (regeln, steuern) läßt.
Die Wandlung der Werte, sowohl der Eingangs- als auch der Ausgangswerte, kann entweder am exter-
nen Prozess vollzogen werden oder aber direkt in der Realzeitrechnerhardware. Im ersten Fall werden die
externen Prozesssignale direkt an ihrer Entstehungsquelle gewandelt und als digitale Information an den
Realzeitrechner übertragen, bzw. vom Realzeitrechner als digitale Information an den externen Prozess
gebracht. Für die Übertragung dieser digitalen Information wird oft ein (realzeitfähiges) Kommunikations-
system (z.B. Feldbus) eingesetzt. Werden nur wenige Prozesssignale ausgetauscht, kann der externe Prozess
auch direkt angekoppelt werden. In diesem Fall ist jedes Ein- und Ausgangssignal des externen Prozesses
direkt mit der Hardware des Realzeitsystems verbunden.
Eine direkte Kopplung verwendet man aber vor allem auch beim zweiten Fall, bei dem die Ein- und Aus-
gangswerte im Realzeitrechner selbst gewandelt werden. Hier müssen die Prozesssignale in ihrer ursprüng-
lichen Form bis zu den entsprechenden Wandlern transportiert werden.
Die Rechnerhardware selbst besteht aus einem oder mehreren Prozessoren, dem Speicher und der soge-
nannten Glue-Logik (Bausteinen, die das Zusammenspiel der übrigen Komponenten ermöglichen). Darüber
hinaus gehören die bereits erwähnten Wandler dazu. Bei Systemen, die hohe zeitliche Anforderungen er-
füllen, wird man auch oft spezielle Hardwarebausteine finden, die die Funktionalität, die normalerweise
in Software realisiert worden wäre, in Hardware realisiert (Asics, FPGA’s, LCA’s usw.). Daneben gehören
auch Sekundärspeicher (z.B. Festplatten, Flashkarten) zur Rechnerhardware.
Die Rechnerhardware wird über ein Realzeitbetriebssystem oder ein Laufzeitsystem (Executive, einfaches
Betriebssystem) angesteuert. Dieses Betriebssystem stellt die Ablaufumgebung für die Rechenprozesse zur
Verfügung. Die Hardware wird dabei über Gerätetreiber abgebildet.
In Realzeitsystemen laufen mehrere Rechenprozesse scheinbar gleichzeitig ab (quasi parallel). Neben den
Rechenprozessen, die applikationsspezifisch sind, gibt es in einem Realzeitsystem oftmals auch Rechen-
prozesse, die zum Betriebssystem gehören (Dienstprogramme). Bei solch einem Dienstprogramm kann es
sich beispielsweise um einen RechenProzess handeln, der Netzwerkdienste (z.B. HTTP-Server) bedient.
Eine andere Gruppe von Rechenprozessen könnte sich bei einem Realzeitsystem um die Visualisierung des
Zustandes des externen Prozesses kümmern.

8
Kapitel 1. Realzeitsysteme Überblick

1.3.1. Abbildung des technischen Prozesses auf Rechenprozesse

Temp.
Regelung

Druck
Regeleung

Technischer Realzeit−Steuerung
Prozeß
Rechenprozesse

Abbildung 1-6. Abbildung technischer Prozesse auf Rechenprozesse

Bei der Abbildung technischer Prozesse auf Rechenprozesse (Bild


Abbildung technischer Prozesse auf Rechenprozesse) werden zusammengehörige
Zustandsgrößen und Stellwerte der technischen Prozesse (z.B. der Temperaturwert und die Stellgröße für
die Heizung) auf logische Einheiten, eben den Rechenprozess, abgebildet.

Prozesse

Datenspeicher

Datenfluß
Datenquelle oder Datensenke

Kontrollfluß

Abbildung 1-7. Elemente der Datenflußdiagramme

Zur Darstellung der Rechenprozess-Architektur werden Datenflußdiagramme (Bild


Elemente der Datenflußdiagramme) eingesetzt. Bei dieser Diagrammform werden Prozesse
(Rechenprozesse, Verarbeitungseinheiten) als Kreise dargestellt. Pfeile kennzeichnen Daten und die
Flußrichtung der Daten, die zwischen Rechenprozessen und von und zu Datenspeichern ausgetauscht
werden. Datenspeicher werden als zwei übereinanderliegende waagerechte Striche dargestellt. Über das
Fassungsvermögen der Datenspeicher wird keine Aussage getätigt. Die Darstellung der Datenquellen
und der Datensenken unterbleibt oftmals. Die Pfeile sollten bezüglich der ausgetauschten Daten
gekennzeichnet werden. Dabei ist darauf zu achten, wirklich die Daten als solche, und nicht die
Operationen auf die Daten anzugeben.
Die ursprünglichen Datenflußdiagramme sind für die Darstellung von Echtzeitsystemen noch um weitere
Elemente, die den Kontrollfluß definieren, erweitert worden. So deutet ein gestrichelter Pfeil an, dass zwi-
schen zwei Tasks eine Kontroll-Information (Events) ausgetauscht wird. Eine derartige Information kann

9
Kapitel 1. Realzeitsysteme Überblick

beispielsweise das Starten oder Beenden eines Prozesses, das Senden eines Events oder eines Signals, das
Schlafenlegen und das Aufwecken eines Rechenprozesses oder schließlich das Betreten und Verlassen eines
kritischen Abschnittes sein.

Zustandsinfo
Rennbahn Auto
/dev/Carrera
Speed Streckentyp,
Länge

Position Strecke

Streckentyp,

Rennbahn Position
Fremd−
/dev/Carrera.other Auto

Abbildung 1-8. Einfaches DFD einer Carrerabahnsteuerung

Abbildung Einfaches DFD einer Carrerabahnsteuerung stellt das Datenflußdiagramm einer Carrerabahn-
steuerung dar. Die Verarbeitungseinheit Auto bekommt von der Rennbahn Zustandsinformationen und be-
rechnet daraus Geschwindigkeitswerte (Speed). Aufgrund der Zustandsinformationen werden Streckentyp
und Länge eines Streckensegments berechnet und in einem Datenspeicher abgelegt.
Die Position des gegnerischen Fahrzeugs erhält der Rechenprozess Auto über den Rechenprozess Frem-
dauto. Dieser bekommt Positionsangaben in Form von Segmenttypen ebenfalls von der Rennbahn, aller-
dings über das Interface /dev/Carrera.other. Zur genauen Bestimmung des gegnerischen Fahrzeugs auf
der Strecke wird diese Information mit der Streckeninformation abgeglichen.

digitalisiertes
Ko−
Audio Audiosignal Erfas− Rohdaten
dierung Pakete Versand
Pakete
Netz
Hardware sung

Audiodaten Sendepuffer

Konfiguration

Abbildung 1-9. DFD Audiostreaming

Abbildung DFD Audiostreaming stellt das vereinfachte DFD eines Audiostreaming-Systems dar. Hier ist
der Rechenprozess Erfassung für die zeitgenaue Aufnahme der digitalisierten Audiosignale zuständig. Für
die zeitgenaue Aufnahme der Daten ist eine Entkopplung dieser Aufgabe von der Weiterverarbeitung not-
wendig. Aus diesem Grunde werden die Daten in einem Datenspeicher abgelegt und nicht direkt dem Re-
chenprozess Kodierung übergeben. Diese Verarbeitungseinheit liest zu Beginn eine Konfigurationsdatei, in
der das zu verwendende Kodierungsverfahren samt seiner Parameter beschrieben ist. Entsprechend dieser
Informationen werden die Daten, die sich im Datenspeicher Audiodaten befinden, kodiert, paketiert und in
den Sendepuffer abgelegt. Auch das Senden muß aus Gründen der Echtzeitfähigkeit über einen Datenspei-
cher entkoppelt werden.

10
Kapitel 1. Realzeitsysteme Überblick

Anhand eines reinen Datenflußdiagramms sind keinerlei dynamischen Abläufe sichtbar. Das DFD gibt eine
statische Sicht der Dinge wieder. Dynamik kann partiell über die Erweiterung der Kontrollflüsse ausge-
drückt werden. Kontrollflüsse drücken aus, welche Verarbeitungseinheit welche Verarbeitung auslöst.
Einzelne Rechenprozesse (Verarbeitungseinheiten) lassen sich hierarchisch verfeinern. Dazu wird ein Re-
chenprozess mit einem Buchstaben (z.B. A) markiert und dann für A ein neues Gebilde von Rechenprozes-
sen, Datenflüssen und Datenspeichern gezeichnet.

Fußnoten
1. Mit externer Prozess wird hier der Prozess bezeichnet, der durch das Realzeitsystem gesteuert wird,
ohne dass er direkt Teil des Realzeitsystems ist. Nach dieser Definition besteht das Gesamtsystem aus
dem externen (technischen) Prozess und dem Realzeitsystem.

11
Kapitel 1. Realzeitsysteme Überblick

12
Kapitel 2. Schritthaltende Verarbeitung und
Echtzeitbetrieb
Unter schritthaltender Verarbeitung bzw. Echtzeitbetrieb versteht man die fristgerechte Bearbeitung von
Anforderungen aus einem technischen Prozess. Was aus Sicht des technischen Prozesses „Anforderungen“
sind, sind aus Sicht der Steuerung Ereignisse. Die Steuerung muss also Ereignisse fristgerecht bearbeiten.
Können die Ereignisse durch die Steuerung nicht innerhalb der durch den technischen Prozess gestellten
Zeitschranken bearbeitet werden, sind die Folgen möglicherweise katastrophal. Daher ist es notwendig, die
zeitlichen Anforderungen und die zeitlichen Kenndaten bezüglich der Steuerung (der Rechenprozesse und
deren Ablaufumgebung) zu kennen.
Daher werden in diesem Kapitel die Zeitschranken des technischen Prozesses formal eingeführt. Außerdem
werden Methoden vorgestellt, den sogenannten Echtzeitnachweis durchzuführen.
Dabei sind folgende Aspekte von Bedeutung:

• Zur Bearbeitung von Aufgaben wird Zeit (Verarbeitungszeit) benötigt.


• Beim Anliegen mehrerer Aufgaben muss die Reihenfolge, in der die Arbeiten erledigt werden, geplant
werden.
• Die richtige Reihenfolge der Aufgaben ist entscheidend, um die zeitgerechte Bearbeitung der Aufgaben
gewährleisten zu können.
• Als Planungsgrundlage bekommen die einzelnen Aufgaben Prioritäten gemäß ihrer Wichtigkeit.
• Die Bearbeitung einer Aufgabe (durch einen Prozess) muss unterbrechbar sein, damit kurzfristige höher-
priore Aufgaben erledigt werden können.

2.1. Echtzeitbedingungen
Der technische Prozess stellt Anforderungen unterschiedlicher Art an die Echtzeitsteuerung. Alle Anfor-
derungen müssen aber von der Steuerung bearbeitet werden können, auch wenn sämtliche Ereignisse zu
einem Zeitpunkt auftreten (erste Echtzeitforderung).
Der zeitliche Abstand zwischen zwei Anforderungen gleichen Typs wird Prozesszeit (tP) genannt. Ist der
zeitliche Abstand zweier Ereignisse konstant, spricht man von einem periodischen Ereignis. Vielfach
schwankt jedoch der zeitliche Abstand, so dass es einen minimalen zeitlichen Abstand tPmin und einen
maximalen zeitlichen Abstand tPmax gibt.
Der Auftrittszeitpunkt eines zu einem Rechenprozess gehörenden Ereignisses wird mit tA (im englischen
auch mit Releasetime bezeichnet. Im Regelfall wird dieser nicht absolut, sondern relativ zu einem Bezugs-
zeitpunkt angegeben. So tritt für uns bei periodischen Zeitpunkten das erste Ereignis vielfach zum Zeitpunkt
»tA=0« auf.
Das zeitliche Auftreten der Ereignisse wird in einer Anforderungsfunktion dargestellt. Dazu werden die
Anforderungen (sichtweise des Steuerungs- bzw. Betriebssystems) bzw. Ereignisse (Sichtweise des techni-
schen Prozess) in Form von Pfeilen über der Zeit aufgetragen (siehe Abbildung [Anforderungsfunktion]).

13
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Eintritt des Ereignisses E

E E E E E E

t[T]
t t
Pmin Pmax

t = 2T
Pmin
tPmax= 6T tP = 2T+6T = 4T
2

Abbildung 2-1. Anforderungsfunktion

Für die eigentliche Bearbeitung des Ereignisses werden vom Rechner Anweisungen abgearbeitet. Die zum
Ereignis gehörende Folge von Anweisungen wird hier als Codesequenz oder auch als Job bezeichnet. Jobs
sind innerhalb des Rechners als Rechenprozesse realisiert, die sich selbst wiederum in Tasks und Threads
unterscheiden lassen (siehe Kapitel [Prozess-Management]). Manchmal bilden auch mehrere Codesequen-
zen zusammen einen solchen Rechenprozess. Für die Abarbeitung des Jobs »i« benötigt der Rechner die
sogenannte Verarbeitungszeit tV,i. Die Verarbeitungszeit - im Englischen auch Execution-Time - ergibt sich
aus der zu leistenden Rechenarbeit RA und der Leistung P des eingesetzten Prozessors (Rechnerkern).
tV=RA/P
Die Angabe der Verarbeitungszeit ist in der Praxis problematisch, da zum einen - abhängig von der Auf-
gabenstellung oder/und den Eingabewerten - selbige meistens nicht konstant ist und zum anderen auch die
Leistung des Prozessor schwankt (bedingt durch Caches und DMA). Zur Berechnung bei Echtzeitsystemen
muss daher RAmax und Pmin angesetzt werden.
Die für den Worst-Case anzunehmende Verarbeitungszeit wird in der Literatur auch Worst-Case-Execution
Time (WCET) genannt (siehe Kapitel [Abschätzung der Worst Case Execution Time (WCET)]).

2.1.1. Auslastung
Abhängig von der Auftrittshäufigkeit eines Ereignisses und der damit anfallenden Verarbeitungszeit ist
der Rechnerkern (Prozessor) ausgelastet. Die Auslastung (ρ) durch eine Anforderung ergibt sich damit als
Quotient aus notwendiger Verarbeitungszeit und Prozesszeit:
ρ=tV/tP
Ein Realzeitsystem muss in der Lage sein, die auftretenden Anforderungen in der Summe bearbeiten zu
können (oft auch als Forderung nach Gleichzeitigkeit bezeichnet). Mathematisch bedeutet dieses, dass die
Gesamtauslastung ρges kleiner als 100% sein muss.
Die Gesamtauslastung ergibt sich aus der Summe der Auslastungen der einzelnen Jobs.

Gleichung 2-1. Gesamtauslastung

n
ρ = Σ ttvp ≤ 1 i

i=0 i

14
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Prozessor− tVA
belegung
tVA
Rechenprozess A ρ =
A
tP
tVB A
tVB
Rechenprozess B ρ =
B tP
B
tVA tVB
Rechenprozess A + B ρA+B= +
tP tP
A B
t
tPB tPA

Abbildung 2-2. Auslastung

Abbildung [Auslastung] zeigt noch einmal die Abläufe. Ein Echtzeitrechner bearbeitet zwei Rechenprozesse
(Jobs): Rechenprozess A und Rechenprozess B. Sei die Verarbeitungszeit des Rechenprozesses A tV,A=0.8ms
und die Prozesszeit tP,A=2ms ergibt sich eine Auslastung des Rechners durch den Rechenprozess A von 40%.
Ist die Verarbeitungszeit des Rechenprozesses B ebenfalls tV,B=0.8ms und hat dieser auch eine Prozesszeit
von tP,B=2ms ergibt sich die gleiche Auslastung wie die des Rechenprozesses A von ρB=40%.
Die Gesamtauslastung des Rechners - er bearbeitet ja beide Rechenprozesse - beträgt nun ρGes.=ρA +
ρB=80%.

Erste Echtzeitbedingung: Die Auslastung ρges eines Rechensystems muss kleiner oder gleich 100% sein.
Die Auslastungsbedingung ist eine notwendige, aber keine hinreichende Bedingung.

2.1.2. Pünktlichkeit
Aus dem technischen Prozess kommen immer wieder Anforderungen an die Echtzeitsteuerung. Aufgabe
der Steuerung ist es, alle Anforderungen zeitgerecht zu bearbeiten. Alle bedeutet in diesem Falle, dass der
Rechner leistungsfähig sein muss, um mit der vorgegebenen Last fertig zu werden. Zeitgerecht bedeutet,
dass der Rechner die Anforderungen rechtzeitig bzw. pünktlich bearbeitet.
Das wesentliche Kriterium für ein Realzeitsystem ist Pünktlichkeit in Abgrenzung zu Schnelligkeit.
Allerdings lassen sich Anforderungen an Pünktlichkeit mit schnellen Systemen leichter erfüllen als mit
langsamen. Prinzipiell muss ein Realzeitsystem eine Aufgabe in einem vorgegebenen Zeitfenster erfüllt
haben, wie es das tut, ist dabei unwesentlich.

15
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

tatsächlich erlaubt
Reaktions−
Bereich
des
Rechners
t0 tZmin tRmax tZmax t
Ereignis
tritt ein

Abbildung 2-3. Reaktionsbereich

Unter Pünktlichkeit wird hier also verstanden, dass die Aufgabe

1. nicht vor einem weiteren spezifizierten Zeitpunkt tZmin erledigt ist und
2. bis zu einem spezifizierten Zeitpunkt tZmax erledigt wird (Rechtzeitigkeit).

Die Forderung, dass eine Ausgabe nicht vor einem bestimmten Zeitpunkt durchgeführt wird, fehlt oft
(tZmin=t0) und ist in den übrigen Fällen vielfach trivial zu erfüllen. Die Forderung nach Rechtzeitigkeit stellt
dagegen hohe Anforderungen an das System und damit letzlich auch an den Ingenieur bzw. Informatiker,
der das System konzipiert und realisiert.
Formal wird die Forderung nach Rechtzeitigkeit als sogenannte maximal zulässige Reaktionszeit tZmax aus-
gedrückt. Bei der maximal zulässigen Reaktionszeit handelt es sich um eine Relativzeit beginnend mit dem
Eintreten eines Ereignisses. Die maximal zulässige Reaktionszeit, wie sie hier gebraucht wird, beinhaltet
nur die Zeiten, die für die Rechenprozesse relevant sind. Unter maximaler zulässiger Reaktionszeit wird
also der Zeitpunkt verstanden, bis zu dem der Rechenprozess seine Ausgabe gemacht haben muss. Es wird
nicht der Zeitpunkt verstanden, bis zu dem der technische Prozess einen definierten Zustand eingenom-
men haben muss. Sind daher die Randbedingungen des technischen Prozesses bekannt, muss die maximal
zulässige Reaktionszeit des Rechenprozesses daraus abgeleitet werden.
Mit maximaler Reaktionszeit tRmax wird der Zeitpunkt bezeichnet, bis zu dem durch den Rechner eine
Reaktion in jedem Fall erfolgt ist. Es handelt sich um eine Worst Case Zeit. Die maximale Reaktionszeit
muss also immer kleiner sein als die maximal zulässige Reaktionszeit.

Weiche

m
v=1
To You s

Barcodeleser 300 mm
Umschaltzeit=200ms

s 0.3 m
t300= v = 1 m s = 300 ms

tZmax= t300 tU = 100 ms

Abbildung 2-4. Maximal zulässige Reaktionszeit bei einer Rohrpost

Beispiel 2-1. Rohrpostsystem

In einem Rohrpostsystem bewegen sich Postbehälter, die durch einen Strichcode gekennzeichnet sind. Je-
weils 30 cm vor einer Rohrpostweiche identifiziert ein Realzeitrechner mittels Barcodeleser den Postbehäl-

16
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

ter und stellt daraufhin die Weiche. Die Postbehälter haben eine Geschwindigkeit von v=1m/s. Die Weiche
hat eine Stellzeit von 200 ms.
Aus diesen Daten ergibt sich, dass der Postbehälter ab dem Barcodeleser bis zur Weiche 300 ms benötigt.
Da die Weiche jedoch noch eine Stellzeit von 200 ms hat, muss der Realzeitrechner spätestens nach 100ms
der Weiche die Anweisung übermitteln, in welches Rohr der Postbehälter weitergeleitet werden muss. Die
maximal zulässige Reaktionszeit beträgt damit tZmax=100ms. Die maximale Reaktionszeit tRmax kann auf-
grund fehlender Informationen nicht angegeben werden. Diese Zeit basiert nämlich auf der Leistung des
verwendeten Realzeitsystems und der dort ablaufenden Applikation.
Das Ereignis, das den Bezugspunkt für die Reaktionszeit darstellt, kann beispielweise durch eine Zustands-
änderung im technischen Prozess charakterisiert sein (Postbehälter angekommen, Temperaturwert über-
schritten).

Trägt man das Auftreten der Ereignisse über der Zeit auf, erhält man die sogenannte Anforderungsfunktion
(Abb. Anforderungsfunktion).
Der Zeitabstand zwischen zwei Ereignissen gleichen Typs wird als Prozesszeit tP bezeichnet. Oftmals ist die
maximal zulässige Reaktionszeit tZmax durch die Anforderung definiert, dass ein Ereignis vor dem Eintreffen
eines nachfolgenden Ereignisses gleichen Typs bearbeitet sein muss (tZmax≤tPmin).
Die Prozesszeit tPist nicht immer konstant. Daher wird man im Regelfall bei Berechnungen, ob die Real-
zeitbedingungen erfüllt sind oder nicht, die minimale Prozesszeit tPmin einsetzen.
Zur Berechnung der durchschnittlichen Auslastung ist eine Mittelwertbildung (bei einer Gleichverteilung
zum Beispiel der statistische Mittelwert) durchzuführen.
Nachdem ein Ereignis eingetreten ist, kann in den meisten Fällen der zugehörige Rechenprozess nicht di-
rekt die Bearbeitung des Ereignisses beginnen, da beispielsweise die Bearbeitung eines anderen Ereignisses
noch nicht abgeschlossen ist. Der Rechenprozess muss warten. Diese Zeit wird als Wartezeit tW beschrie-
ben.
Damit ergibt sich die Reaktionszeit tR aus der Summe der Wartezeit tW und der Verarbeitungszeit tV.

Gleichung 2-2. Reaktionszeit

tR = tV + tW

      
 

RK
10 20 30 40 50 60 70 80 90 100 110 120 t
Abbildung 2-5. Rechnerkernbelegung durch 4 Rechenprozesse

Trägt man die Verarbeitungszeit tV über die Zeit auf, erhält man die sogenannte Rechnerkernbelegung (Abb.
Rechnerkernbelegung durch 4 Rechenprozesse). Sie gibt Auskunft darüber, zu welchen Zeiten die Verar-
beitungseinheit mit welcher Aufgabe betraut ist. Oftmals trägt man die Anforderungsfunktion zusammen
mit der Rechnerkernbelegung in ein Diagramm ein.

Merke: Um eine Aufgabe rechtzeitig (in Echtzeit) zu erledigen, muss die Reaktionszeit größer oder
gleich der minimal zulässige Reaktionszeit, aber kleiner oder gleich der maximal zulässigen Reaktions-
zeit sein (für alle tR).

17
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

tZmin≤tR ≤tZmax

Gleichung 2-3. Rechtzeitigkeitsbedingung

tZmin ≤ tRmin ≤ tRmax ≤ tZmax

2.1.3. Harte und weiche Echtzeit

Kosten

harte Echtzeit
Deadline

weiche Echtzeit

tZmin tZmax Zeit

Abbildung 2-6. Harte und weiche Echtzeit als Kostenfunktion

Die Forderung nach Rechtzeitigkeit ist nicht bei jedem System gleich stark. Während das nicht rechtzeitige
Absprengen der Zusatztanks bei einem Raumschiff zum Verlust desselbigen führen kann, entstehen durch
Verletzung der Rechtzeitigkeitsbedingung bei einem Multimediasystem allenfalls Komfortverluste. Viel-
fach findet man den Begriff harte Echtzeit, wenn die Verletzung der Realzeitanforderungen katatrophale
Folgen hat und daher nicht toleriert werden kann. Man findet den Begriff der weichen Echtzeit, wenn die
Verletzung der Realzeitanforderungen verkraftet werden kann. Allerdings kann man nicht ausschließlich
zwischen „harter“ und „weicher“ Echtzeit unterscheiden, sondern jegliche Abstufung zwischen den beiden
Extremen (weich und hart, soft und hard) ist möglich. Die Graduation hängt von der Aufgabenstellung ab.
Die Unterschiede bei der Forderung nach Pünktlichkeit werden oft anhand einer Kostenfunktion verdeut-
licht. Bei den sogenannten weichen Echtzeitsystemen bedeutet das Verletzen der Realzeitbedingung einen
leichten Anstieg der Kosten. Bei den sogenannten harten Echtzeitsystemen steigen jedoch die Kosten durch
die Verletzung der Realzeitbedingung massiv an.

18
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Benefit
no realtime requirements
100 %

soft realtime requirements

hard realtime requirements


t0 t t Zmax t
Zmin
t Zmin minimal zulässige Reaktionszeit
t Zmax maximal zulässige Reaktionszeit

Abbildung 2-7. Benefit-Function

Eine andere Art der Darstellung ist die sogenannte Benefitfunction (Nutzenfunktion). Hier wird der Nutzen
der Reaktion des Realzeitrechners auf das Ereignis über die Zeit aufgetragen. Bei Systemen ohne Echt-
zeitanforderungen ist der Nutzen unabhängig von dem Zeitpunkt der erfolgten Reaktion, bei einem absolut
harten Echtzeitsystem ist nur dann ein Nutzen vorhanden, wenn die Reaktion innerhalb des durch tZmin und
tZmax aufgestellten Zeitfensters erfolgt. Dazwischen ist jegliche Abstufung an Realzeitanforderungen mög-
lich. Hier kann man (je nach Graduation) von weichen Realzeitanforderungen sprechen.

2.2. Unterbrechbarkeit und Prioritäten


Ist die Auslastungsbedingung (siehe [Auslastung]) erfüllt, die Rechtzeitigkeitsbedingung aber nicht, kann
das Problem unter Umständen dennoch mit der vorhandenen Hardware gelöst werden. Hierzu sind dann
allerdings weitere Maßnahmen, insbesondere bezüglich der Systemsoftware und der Architektur der Real-
zeitapplikation notwendig: Die gestellte Aufgabe muss ich in (unabhängige, parallel ablaufende) Teilaufga-
ben zerlegen lassen. Die einzelnen Teilaufgaben (Jobs) müssen unterbrechbar sein und müssen priorisiert
werden.

100 Meßwerte
erfaßt

Meßwerte
Aufnehmen Meßwerte Sichern

Abbildung 2-8. Datenflußdiagramm Meßwertaufnahme

19
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Beispiel 2-2. Unterbrechbarkeit bei der Meßwerterfassung

Ein Meßwerterfassungssystem soll im Abstand von 1 ms (tP1=1ms) kontinuierlich Meßwerte aufnehmen.


Dazu benötigt der zugehörige Rechenprozess eine Rechenzeit von tV1=500 µs. Jeweils 100 Meßwerte
(tP2=100tP1=100ms) ergeben einen Datensatz, der vorverarbeitet und zur Archivierung weitergeleitet wird.
Dazu ist eine Rechenzeit von tV2=40ms notwendig.

Überprüft man an diesem Beispiel die 1. Echtzeitbedingung, so ist diese bei einer Auslastung von
ρ=tV1/tP1 + tV2/tP2 = 0.5 + 0.4 = 0.9 = 90%
erfüllt. Dennoch läßt sich die Aufgabe ohne weitere Maßnahmen nicht in Echtzeit erfüllen.

while( 1 )

for( i=0; i<100; i++ )

Sende Timer−Event in 1 ms

Nimm Meßwert auf

Warte auf Timer−Event

Verarbeite Datensatz

Archiviere Ergebnis

Abbildung 2-9. Struktogramm Meßwerterfassung sequentiell

Anforderung

97 98 99 100 101 102 103 140 t[ms]

Meßwertaufnahme Verarbeitung und Archivierung

Abbildung 2-10. Zeitdiagramm Meßwert sequentiell

Abbildung [Struktogramm Meßwerterfassung sequentiell] visualisiert eine Lösung der Aufgabenstellung,


bei der die Aufgabenstellung in einem Rechenprozess abgearbeitet wird. Zunächst werden die 100 Meß-
werte aufgenommen, dann verarbeitet. Wie in Abbildung [Zeitdiagramm Meßwert sequentiell] ersichtlich,
startet gemäß Struktogramm nach 100ms die Codesequenz Verarbeitung, welche den Prozessor für 40ms
belegt. Allerdings müssen natürlich auch während dieser Zeit weiterhin Meßwerte aufgenommen werden,
das ist aber bei der gewählten Struktur nicht möglich.
Um das Problem dennoch zu lösen, wird die Aufgabe auf zwei unabhängige Rechenprozesse aufgeteilt. Re-
chenprozess »Erfassung« ist für die Meßwertaufnahme verantwortlich, Rechenprozess »Verarbeitung« für

20
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

die Verarbeitung der Werte und Sicherung der Ergebnisse. Über sogenannte Inter-Prozess-Kommunikation
(IPC, siehe [Datenfluß/Inter-Prozess-Kommunikation]) informiert Rechenprozess »Erfassung« den Rechen-
prozess »Verarbeitung«, dass 100 Meßwerte erfaßt wurden. Aus Systemsicht stellt »Erfassung« eine An-
forderung respektive bekommt »Verarbeitung« ein Ereignis zugestellt. Dadurch wird Rechenprozess »Ver-
arbeitung« aktiv. Er verarbeitet die Daten und sichert das Ergebnis. Damit keine Meßwerte verloren gehen,
muss jetzt noch Rechenprozess »Verarbeitung« unterbrechbar gemacht werden, das bedeutet, dass jedes-
mal, wenn der Timer-Event auftritt, Rechenprozess »Verarbeitung« kurz unterbrochen wird (man spricht
von Preemption) und der Rechenprozess »Erfassung« den neuen Meßwert erfassen kann.
Dass Aufgrund der Ereignisse ein Rechenprozess aktiv wird, besorgt die Systemsoftware (Betriebssystem).
Den Wechsel zwischen den beiden Rechenprozessen bezeichnet man als Kontextswitch1. Ein Kontextswitch
benötigt Zeit, die jetzt auch noch in die Berechnung der Auslastung (1. Echtzeitbedingung) mit einfließen
muss. Wir werden jedoch in unseren Betrachtungen davon ausgehen, dass die Kontextwechselzeit so gering
ist, dass sie vernachlässigt werden kann.

Merke: Die im Beispiel angesprochenen Dienste wie IPC und Unterbrechbarkeit von Rechenprozessen
stellt das Echtzeitbetriebssystem zur Verfügung.

Rechenprozess "Erfassung" Rechenprozess "Verarbeitung"

while( 1 ) while( 1 )

RcvMsg von "Erfassung"


for( i=0; i<100; i++ )
Verarbeitung der Daten
Sende Timer−Event in 1 ms
Archiviere Ergebnis
Nimm Meßwert auf

Warte auf Timer−Event


SendMsg an "Verarbeitung"

Abbildung 2-11. Struktogramm Meßwerterfassung parallel

Anforderung

97 98 99 100 101 102 103 140 t[ms]

Meßwertaufnahme Verarbeitung

Abbildung 2-12. Zeitdiagramm Meßwert parallel

Die dargestellte Lösung, basierend auf der Parallelisierbarkeit der Aufgaben und der Möglichkeit, einzelne
Rechenprozesse während der Abarbeitung kurz zu unterbrechen, funktioniert nur dann, wenn festlegbar ist,
welcher Rechenprozess unter welchen Umständen andere Rechenprozesse unterbrechen darf. Im einfach-
sten Fall geschieht dies über die Vergabe von Prioritäten.

21
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Damit im angegebenen Beispiel die Echtzeitanforderungen erfüllt werden, muss daher der Rechenprozess
»Erfassung« höhere Priorität haben als der Rechenprozess »Verarbeitung«.
Es gibt keine einheitliche Definition darüber, wie eine höhe Priorität repräsentiert wird. In manchen Syste-
men stehen niedrige Zahlen für eine hohe Priorität, in anderen dagegen ist es genau umgekehrt.
Nicht immer ist die Prioritätenvergabe so einfach und eindeutig wie im Beispiel der Meßwerterfassung.
Oft sind im System eine Vielzahl unterschiedlicher Rechenprozesse aktiv. Um hier Prioritäten vergeben zu
können, kann man initial nach folgender Regel verfahren:

Merke: Prozesse mit kurzen Rechenzeiten tV haben in der Regel auch kurze Prozesszeiten tP und
bekommen hohe Prioritäten.
Prozesse mit langen Rechenzeiten tV haben in der Regel auch lange Prozesszeiten tP und bekommen
niedrige Prioritäten.

Variable Prozesszeiten. Das Problem der Prioritätenvergabe und Auslastungsberechnung wird auch
dadurch erschwert, dass in der Realität nicht alle Prozesssignale - wie in den Beispielen angenommen
- mit konstanter Periode anliegen. Vielmehr variieren Prozesszeiten abhängig von der zu lösenden
Aufgabenstellung (zum Beispiel vom physikalischen Prozess).
Sind sichere Informationen, über die Auftrittshäufigkeit der Ereignisse des technischen Prozesses verfügbar,
läßt sich zwar die Auslastung berechnen (und damit die Anforderungen bezüglich der 1. Echtzeitbedingung
überprüfen), damit läßt sich aber nur sehr schwer das Einhalten der 2. Echtzeitbedingung überwachen (zu-
mindest solange keine Informationen über die Mindestabstände zwischen den Ereignissen vorliegen).

2.3. Worst Case Betrachtungen


Für die Berechnung, ob alle Echtzeitanforderungen erfüllt sind, ist immer der sogenannte Worst Case
(schlimmste Fall) heranzuziehen. Der Worst Case ist der Fall, an dem die Prozessereignisse am dichtesten
aufeinander folgen (oder besser, die höchste Belastung mit sich bringen). Da meistens mehrere Prozesssi-
gnale unterschiedlichen Typs (und damit mit unterschiedlichen Ankunftszeiten) vorhanden sind, ist das bei
der Bestimmung des Worst Case mit zu berücksichtigen.

Für die Worst Case Betrachtung ist eine möglichst


große Belastungssituation für das Rechensystem
anzusetzen:
− tPmin
− tVmax
− alle (sonstigen) Ereignisse treten zum Zeitpunkt t 0
ein (alle Ereignisse kommen gleichzeitig).

Abbildung 2-13. Parameterauswahl für den Worst Case Fall

Der Worst Case bei der 2. Echtzeitbedingung (Pünklichkeit, tZmin ≤ tRmin ≤ tRmax ≤ tZmax) ist der Fall, dass die
Prozesszeiten möglichst kurz sind und im Gegenzug die Verarbeitungszeiten möglichst lang. Außerdem ist

22
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

in diesem Fall zu berücksichtigen, dass alle sonstigen Ereignisse im System - soweit sie im gegenwärtigen
Prozesszustand möglich sind - auch auftreten.

E tZmax
tRmin

1 2
t
E tZmax
tRmin

1 2
t
1=Berechnung
2=Ausgabe

Abbildung 2-14. Verteilung der Rechenzeit bei minimalen Reaktionszeiten

Schwierig wird die Worst Case Betrachtung auch dann, wenn die minimale Reaktionszeit tZmin 6= t0
ist. Hier ist die Einhaltung der Realzeitbedingung stark abhängig von der gewählten Architektur
des Systems. Löst beispielsweise das Ereignis aus dem technischen Prozess zum Zeitpunkt
»tA=0« einen Interrupt aus und die zugehörige Interrupt Service Routine (ISR) wiederum erteilt
dem Betriebssystem den Auftrag, einen Rechenprozess zum Zeitpunkt tZmin zu starten (Abbildung
[Verteilung der Rechenzeit bei minimalen Reaktionszeiten], unten), so führt dies zu einem anderen
Echtzeitverhalten, als wenn der Rechenprozess direkt nach Eintritt des Ereignisses gestartet wird,
diese aber nur die Ausgabe des Ergebnisses an den technischen Prozess zum Zeitpunkt tZmin beauftragt
(Abbildung [Verteilung der Rechenzeit bei minimalen Reaktionszeiten], oben).
Bezüglich der 1. Echtzeitbedingung (Auslastungsbedingung) muss die Summe aller Auslastungen, zu dem
Zeitpunkt, an dem sich das Maximum dieser Summe ergibt, gebildet werden.
Es ist also zu beachten:

1. Bei von einander unabhängigen Ereignissen ist anzusetzen, dass die unabhängigen Ereignisse gleich-
zeitig (zum Zeitpunkt tA=0) auftreten.
2. Bei voneinander abhängigen Ereignissen darf die zeitliche Abhängigkeit der Ereignisse mit berück-
sichtigt werden. Das führt zu einer geringeren Auslastung als bei der Berechnung mit unabhängigen
Ereignissen.

Die Abhängigkeiten der Ereignisse untereinander machen die Worst Case Bestimmung in der Praxis schwie-
rig. Oftmals wird man daher davon ausgehen, dass Abhängigkeiten nicht bestehen. Damit gelten dann - ei-
gentlich abhängige - Ereignisse als unabhängig voneinander und man muss zur Berechnung der Auslastung
(1. Echtzeitbedingung) ansetzen, dass die Ereignisse gleichzeitig auftreten. Das führt im Ergebnis zu einer
höheren Auslastung, als sie in der Realität gegeben sein wird.

23
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

max. 10

1 ms E E 25 ms E E E E

t[ms]

Abbildung 2-15. Abhängige Ereignisse mit variabler Prozesszeit

Ein Beispiel zur Bestimmung des Worst Case: Ein technischer Prozess erzeugt einen Ereignisschwall
von 2 bis 10 Signalen, die einen minimalen Abstand von 1 ms voneinander haben (Abbildung
[Abhängige Ereignisse mit variabler Prozesszeit]). Ein derartiger Ereignisschwall kann im Mittel alle
100 ms auftreten. Der minimale Abstand zwischen zwei Ereignisschwällen beträgt 25 ms. Jedes Signal
des technischen Prozesses muss bearbeitet sein, bevor das nächste Signal des gleichen Typs eintrifft.
Damit ergibt sich tZmax=1ms für die Ereignisse des Ereignisschwalles. Die Aufgabe wird durch einen
Rechenprozess 1 bearbeitet.
Aus diesen Daten muss die Auslastung im Worst Case wie folgt berechnet werden:
Im Worst Case besteht der Ereignisschwall aus der maximalen Anzahl von Ereignissen, nämlich 10, mit
minimalen Abstand, hier 1 ms. Im Worst Case folgen die Ereignisschwälle im kürzest möglichen Abstand,
hier 25 ms. Damit ergibt sich, bei einer Verarbeitungszeit tV1 die Auslastung:
ρMax=10 * tV1 /(9 * 1ms + 25ms);
Der technische Prozess erzeugt jetzt noch eine zweite Gruppe von Signalen. Diese Signale kommen pe-
riodisch mit einem Abstand von jeweils 5 ms. Zur Verarbeitung fällt eine Verarbeitungszeit tV2 an. Diese
Signale werden durch den Rechenprozess 2 bearbeitet.
Dadurch ergibt sich die maximale Auslastung jetzt zu:
ρ2=tV2/ tP2;
ρGesamt = ρMax + ρ2 = 10tV1/34ms + tV2/5ms
Jetzt soll für das angegebene Beispiel die 2. Echtzeitbedingung überprüft werden. Dazu ist zunächst die
Vergabe von Prioritäten notwendig. Nach Regel Prioritätenvergabe bekommt der Rechenprozess mit der
kürzeren Prozesszeit die höhere Priorität. Dazu wird der Worst Case angenommen, so dass der Rechenpro-
zess 1 eine höhere Priorität als Rechenprozess 2 bekommt.
Für Rechenprozess 1 ist durch die hohe Priorität die Wartezeit tW=0 und damit wird tRMax=tV1.
Für Rechenprozess 2 fällt Wartezeit an. Ist im Beispiel tv2=2 ms und tv1=0.5ms, wird tv2 durch tv1 unterbro-
chen. Dadurch wird die Berechnung der Reaktionszeit schwieriger, da Wartezeiten anfallen.
Es gilt wieder, den Worst Case zu bestimmen. Er liegt vor, wenn sowohl die Ereignisse
des Ereignisschwalles als auch die periodisch ankommenden Signale auftreten (Abbildung
[Beispiel Variable Prozesszeiten: Rechnerkernbelegung]). Bei den gegebenen Zahlen führt das zu einer
Wartezeit tW=2ms und damit einer Reaktionszeit tR=4ms für den Rechenprozess 2.
Da zum Zeitpunkt des Auftretens eines Bursts durch Rechenprozess 1 mit maximaler Frequenz (10 Ereig-
nisse mit minimalen Abstand hintereinander) die Auslastung des Rechners 50% beträgt, bleibt zu diesem
Zeitpunkt nur 50% Rechenleistung für Rechenprozess 2 übrig. Für den Rechenprozess 2 bedeutet dies, dass
die Verarbeitungszeit tV2 2.5ms nicht überschreiten darf (1. Echtzeitbedingung).

24
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

1 2a 1 2b 1 2c 1 2d 1 1 2a 1 2b 1 2c 1 2d 1 2a2b
0 1 2 3 4 5 6 7 8 9 10 t[ms]
Abbildung 2-16. Beispiel Variable Prozesszeiten: Rechnerkernbelegung

2.4. Echtzeitnachweis
Der Nachweis, dass alle zeitlichen Anforderungen der Aufgabenstellung unter allen Umständen eingehalten
werden, ist sehr schwierig. Insbesondere sind für unterschiedliche Schedulingalgorithmen (siehe [Kapitel
Scheduling]) auch unterschiedliche Nachweisverfahren zu verwenden. Prinzipiell beruht der Echtzeitnach-
weis darauf,

1. die relevanten Kenndaten des technischen Prozesses zu evaluieren,

a. Anzahl der unterschiedlichen Anforderungen


b. Minimale Prozesszeit für jede Anforderung
c. Minimal zulässige Reaktionszeit tZmin für jede Anforderung
d. Maximal zulässige Reaktionszeit tZmax für jede Anforderung
e. Abhängigkeiten zwischen den Ereignissen

2. die maximale Verarbeitungszeit tVmax (WCET) für jede Anforderung zu identifizieren,


3. die Auslastungsbedingung zu überprüfen und
4. die Rechtzeitigkeitsbedingung zu verifizieren (Bestimmung von tRmin und tRmax).

Zur Überprüfung insbesondere der Rechtzeitigkeitsbedingung ist die Kenntnis der minimalen und der maxi-
malen Reaktionszeit erforderlich. Während die Bestimmung der minimalen Reaktionszeit oft kein Problem
darstellt, ist die Bestimmung der maximalen Reaktionszeit nicht trivial.

2.4.1. Abschätzung der Worst Case Execution Time (WCET)


Die maximale Verarbeitungszeit tVmax - auch Worst Case Execution Time (WCET) genannt - einer Anforde-
rung ist sehr schwer zu bestimmen. Die WCET hängt insbesondere vom Algorithmus, von der Implemen-
tierung des Algorithmus, von der verwendeten Hardware und von den sonstigen Aktivitäten des Systems
(andere Rechenprozesse) ab. Daher kann die WCET allenfalls abgeschätzt werden.
Prinzipiell werden zwei Methoden zur Bestimmung der WCET unterschieden:

1. das Ausmessen der WCET und


2. die statische Analyse inklusive der daraus erfolgenden Ableitung der WCET.

25
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Ausmessen der WCET. Die WCET wird dadurch bestimmt, dass die zugehörige Codesequenz (im
Regelfall auf der Zielplattform) abgearbeitet wird. Dabei wird die Zeit zwischen Eintreten des Ereignisses
und Ausgabe bestimmt.

while( TRUE ) Für die Messung


der WCET
Warte auf Ereignis modifiziert.
t 1 = Zeitstempel

Eigentliche Verarbeitung
t 2 = Zeitstempel

Abbildung 2-17. Meßprinzip zur Bestimmung der WCET

Zur Messung dieser Zeit lassen sich prinzipiell zwei Verfahren unterscheiden:

1. Messung durch das auszumessende Codestück selbst (siehe [Meßprinzip zur Bestimmung der WCET]).
Das Codstück wird so ergänzt, dass jedesmal, wenn ein Ereignis ankommt und wenn die Reaktion
erfolgt ist, ein Zeitstempel abgelegt wird. Die Differenz ergibt die aktuelle Ausführungszeit tVmax.
Beim ersten Durchlauf wird diese als WCET abgelegt, bei den nachfolgenden Durchläufen wird die
neu berechnete Zeit mit der abgelegten Zeit verglichen. Ist die neu berechnete Zeit größer als die bisher
gemessene WCET überschreibt der neue Wert die bisherige WCET.
Eventuell kann anstelle der Modifikation des Codestücks auch ein Profiler eingesetzt werden.

2. Externe Messung von Ereignis und Reaktion (Ausgabe) zum Beispiel mit Hilfe eines Oszilloskops.

Damit eine WCET gemessen werden kann, muss die Codesequenz mit entsprechenden Input-Werten ver-
sorgt werden. Außerdem muss das gesamte System unter Last gesetzt werden.
Vorteile dieser Methode:

• Unabhängig von einer Programmiersprache.


• Eventuell einfach realisierbar.

Nachteile der Meßmethode:

• Die WCET einer Codesequenz kann nicht garantiert werden, schließlich hängt sie von zu vielen Einfluß-
faktoren (Vorgeschichte, Schleifendurchläufe, Caches, Verzweigungen usw.) ab.
• Das Messen ist WCET ist zeitaufwendig und damit letztlich teuer. Das auszumessende Codestück muss
theoretisch mit sämtlichen Inputdaten (in jeglicher Kombination) beschickt werden.
• Diese Methode kann korrekt nur mit dem produktivem Code auf der Zielplattform durchgeführt werden.
Damit ist eine Abschätzung zu einem frühen Zeitpunkt nur bedingt möglich.
• Für die Durchführung der Messung muss eine Messumgebung (die die Inputdaten zur Verfügung stellt)
geschaffen werden.
• Die auszumessende Codesequenz ist unter Umständen zu modifizieren (zum Ablegen von Zeitstempeln).

26
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

• Es ist oftmals schwierig, das System unter die notwendige Last zu setzen.

Statische Analyse. Hierbei wird der Code selbst analysiert. Dazu ist ein Analyseprogramm notwendig,
welches meist mit dem C-Quellcode, manchmal aber auch mit dem Objektcode gefüttert wird. Außerdem
ist noch eine Hardwarebeschreibung notwendig. Die Analysewerkzeuge arbeiten so, dass aus dem Code
zunächst ein Kontroll-Graf erstellt wird. Die Laufzeit der einzelnen Codesequenzen des Kontroll-Grafen
können abgeschätzt werden. Danach muss noch die Anzahl der Schleifendurchläufe berücksichtigt werden.
Komplex wird die Analyse durch die notwendige Abschätzung von Cache-Hits und Cache-Misses und des
Prozessor-Pipelinings.
Unabhängig vom Verfahren gilt prinzipiell, den ausgemessenen Code nicht nachträglich zu verändern und
außerdem noch mit einem Sicherheitsaufschlag zu versehen. Als Sicherheitsaufschlag arbeitet der Ingenieur
gern mit der Zahl π.
tVmax=tWCET·π

2.4.2. Abschätzung der Best Case Execution Time (BCET)


Die Best Case Execution Time eines Jobs muss bestimmt werden, falls eine Codesequenz nicht vor einer
minimal zulässigen Reaktionszeit tZmin abgearbeit worden sein darf.
Die Bestimmung der BCET ist jedoch einfacher als die Bestimmung der WCET. Hier kann der Code recht
einfach analysiert werden. Ansonsten kann die Bestimmung der BCET erfolgen, wie bei der WCET, wobei
allerdings möglichst wenig Last auf dem System vorhanden sein soll.

2.4.3. Echtzeitnachweis bei prioritätengesteuertem Scheduling


Der Echtzeitnachweis bei prioritätengesteuertem Scheduling beruht im Wesentlichen auf der Verifikation,
dass die Rechtzeitigkeitsbedingung für jedes Ereignis eingehalten wird.
Hierzu müssen folgende Kenndaten bekannt sein bzw. bestimmt werden:

1. Die minimalen und die maximalen Verarbeitungszeiten (tV, also die BCET und die WCET) der einzel-
nen Jobs.
2. Die minimalen und die maximalen Reaktionszeiten (tRmin und tRmax).
3. Die minimal und die maximal zulässigen Reaktionszeiten für die den Jobs zugeordneten, einzelnen
Ereignisse.

Die BCET und WCET werden für die Berechnung der minimalen respektive maximalen Reaktionszeiten
benötigt. Mit Hilfe der Reaktionszeiten wird dann der eigentliche Nachweis durchgeführt.
Während die minimale Reaktionszeit in den meisten Fällen unkritisch ist, bereitet die Bestimmtung der
maximalen Reaktionszeit Schwierigkeiten. Hierzu soll im folgenden zunächst ein grafisches Verfahren und
danach ein mathematischer Ansatz vorgestellt werden.

27
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

2.4.3.1. Grafische Bestimmung der maximalen Reaktionszeit


Die maximale Reaktionszeit tRmax läßt sich unter zwei Voraussetzungen auf grafischem Wege ermitteln:

1. zur Lösung der Aufgabe wird ein prioritätengesteuertes Scheduling eingesetzt und
2. alle Ereignisse sind unabhängig voneinander.

Die maximale Reaktionszeit tRmax (und damit die Einhaltung der 2. Echtzeitbedingung) läßt sich auch gra-
fisch bestimmen. Dazu wird in einem Koordinatensystem auf der Ordinate die vom Rechnerkern noch zu
erbringende Rechenzeit S(t) über der Zeit (Abszisse) aufgetragen2. Das impliziert, dass S(t) nicht ab-
nimmt, solange keine neue Anforderung kommt.

S(t)
3
2
1

1 2 3 4 t

Abbildung 2-18. Grafische Berechnung der maximalen Reaktionszeit

Die Dimension von S(t) wird so gewählt, dass 1S in einer Zeiteinheit abgearbeitet werden kann. Bei un-
gestörter Abarbeitung ergibt sich damit eine mit der Steigung -1 fallende Gerade [Bayer 1990] (Abbildung
[Grafische Berechnung der maximalen Reaktionszeit]). Der Schnittpunkt dieser Geraden mit der Abszisse
entspricht der maximalen Reaktionszeit (im Bild also 1). Zu jedem Zeitpunkt läßt sich anhand der Geraden
ablesen, wieviel Rechenarbeit noch zu leisten ist.
Die Einheit der Rechenzeitanforderung entspricht der Einheit der Abszisse (z.B. Millisekunden).
Die Rechenzeitanforderungen, denen die grafische Auswertung zu Grunde liegen,
müssen die Anforderungen des Worst Cases sein. Daher ergibt sich in Abbildung
[Maximale Reaktionszeit im Beispiel Variable Prozesszeiten] eine initiale Rechenzeitanforderung von
R=tv1 + tv2 = 2.5ms für das Beispiel mit variablen Prozesszeiten.

28
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

S(t)[ms]
1 Job 1

1 2 3 4 5 6 7 8 9 10 t[ms]
S(t)[ms]
2
Job 2

1 2 3 4 5 6 7 8 9 10 t[ms]
S(t)[ms]

3
Job 1 + 2
2

1 2 3 4 5 6 7 8 9 10 t[ms]
t
Rmax

Abbildung 2-19. Maximale Reaktionszeit im Beispiel Variable Prozesszeiten

Beispiel 2-3. Echtzeitnachweis bei prioritätsgesteuertem Scheduling

Anhand eines Beispiels soll der Echtzeitnachweis durchgeführt werden. Gegeben seien die zur Durchfüh-
rung notwendigen Kenndaten dreier unterschiedlicher Anforderungen gegeben:

Anforderung tV tP tZmax tZmin


1 10 ms 30 ms 30 ms 0 ms
2 15 ms 45 ms 45 ms 0 ms
3 15 ms 60 ms 60 ms 0 ms

Die Ereignisse zu den Rechenprozessen treten alle erstmalig zum Zeitpunkt tA=0 auf.
Zunächst wird die Auslastung bestimmt:
ρges = 10/30 + 15/45 + 15/60 = 0.91
Die minimale Reaktionszeit wird hier für alle Anforderungen mit »0« angesetzt. Das ist der Fall, wenn eine
der Anforderungen kommt, ohne dass der Rechnerkern mit der Bearbeitung einer anderen Anforderung
beschäftigt ist.
Danach wird die maximale Reaktionszeit des niedrigpriorsten Rechenprozesses, in diesem
Fall der Rechenprozess 3, mit Hilfe des grafischen Verfahrens bestimmt. Aus Abbildung
[Bestimmung der maximalen Reaktionszeit] ergibt sich, dass die Reaktionszeit des Rechenprozesses 3 im
ungünstigsten Fall 90ms beträgt, mehr als zulässig ist. Damit läßt sich dieser Prozess nicht in Echtzeit
steuern, obwohl die Auslastung unterhalb von 100 Prozent liegt.

29
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

S(t) 1 1 1 1
2 2 2
3 3
40
ohne
Job 2
30

20 ohne
Job 3

10

5 10 20 30 40 50 60 70 80 90 100 t
Abbildung 2-20. Bestimmung der maximalen Reaktionszeit

Verschiebt man die Zeitachse um die Rechenzeit des niedrigpriorsten Rechenprozesses nach oben, erhält
man mit dem neuen Schnittpunkt der Zeitachse die maximale Reaktionszeit des nächstniederpriorsten Re-
chenprozesses, im Beispiel der Rechenprozess 2. Ein nochmaliges Verschieben um die Verarbeitungszeit,
in diesem Fall des Rechenprozess 2, erhält man die maximale Reaktionszeit des Rechenprozess 1.

2.4.3.2. Mathematischer Ansatz


Mit diesem mathematischen Ansatz kann überprüft werden, ob die Bedingung tRmax≤tZmax erfüllt ist. Vor-
aussetzung ist, dass die Ereignisse periodisch sind, den einzelnen Jobs Prioritäten vergeben wurden und ein

30
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

prioritäten gesteuertes Scheduling vorliegt. Das Verfahren soll zunächst anschaulich hergeleitet werden.

C
90 Rechenprozess 1+2+3
niedrigste Priorität
80

70
3
2
60
Rechenprozess 1+2
mittlere Priorität
50 1

3
40
2
1
30
2 Rechenprozess 1
höchste Priorität
1
20

1
10
verbrauchte Rechenzeit

10 20 30 40 50 60 70 80 90 100 t

Abbildung 2-21. Verifikation der Rechtzeitigkeitsbedingung (die Zahlen stammen aus dem Beispiel
[Echtzeitnachweis bei prioritätsgesteuertem Scheduling])

In einem Koordinatensystem wird die von den Jobs (Rechenprozessen) angeforderte Rechenzeit »C(t)« über
der Zeit »t« aufgetragen. »C(t)« nimmt mit jeder Anforderung zu (Funktion wächst).
Außerdem wird in das gleiche Koordinatensystem die vom Rechner bis Zeitpunkt »t« zur Verfügung gestell-
te Rechenzeit »A(t)« eingezeichnet. Diese entspricht im Normalfall der bis dato vergangenen Zeit t: A(t)=t.
In Abbildung [Verifikation der Rechtzeitigkeitsbedingung (die Zahlen stammen aus dem Beispiel [])] ist die
verbrauchte Rechenzeit grau hinterlegt. Falls X- und Y-Achse gleich skaliert sind, handelt es sich um den
Teil unterhalb der Winkelhalbierenden.
Der Zeitpunkt t, zu dem sich C(t) und A(t) schneiden, ist die maximale Reaktionszeit des niedrigpriorsten
Prozesses:
C(t)=A(t); C(tRmax)=A(tRmax);
C(tRmax)=tRmax;
Zwischen S(t) und C(t) besteht damit der folgende Zusammenhang:
S(t) = C(t) - A(t) = C(t) - t;
In das Koordinatensystem werden die Rechenzeitanforderungen gemäß ihrer Priorität
aufsummiert. Zuerst werden die Anforderungen der höchstprioren Rechenprozesse eingetragen.
Der Schnittpunkt mit der Winkelhalbierenden gibt die maximale Reaktionszeit dieser
Jobs an. Danach werden die Anforderung der höchstprioren Rechenprozesse zusammen
mit den Anforderung der nächst prioren Rechenprozesse aufgetragen (in Abbildung
[Verifikation der Rechtzeitigkeitsbedingung (die Zahlen stammen aus dem Beispiel [])] die Linie

31
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

»Rechenprozess 1+2«). In diesem Fall entspricht der Schnittpunkt mit der Winkelhalbierenden der
maximalen Reaktionszeit der nächst prioren Rechenprozesse. Prozesse gleicher Priorität haben damit auch
die gleiche maximale Reaktionszeit.
Aus der Zeichnung [Verifikation der Rechtzeitigkeitsbedingung (die Zahlen stammen aus dem Beispiel [])]
läßt sich demnach ablesen, dass tRmax,1=10ms, tRmax,2=25ms und tRmax,3=90ms ist. Die Rechtzeitigkeitsbedin-
gung [Rechtzeitigkeitsbedingung] ist damit verletzt.
Mathematisch umgesetzt bedeutet dies, dass die Lösung der Gleichung »C(t)-t = 0« die maximale Reakti-
onszeit tRmax ergibt.

Gleichung 2-4. C(t) kleiner gleich t

C(t) ≤ t; f r 0 ≤ t ≤ KGV (tP i )

In der Praxis reicht es aus, »t« zwischen »0« und der Hyperperiode zu überprüfen. Als Hyperperiode be-
zeichnet man das gemeinsame Vielfache der Prozesszeiten tP aller Jobs.
Die Rechenzeitanforderung C(t) läßt sich für periodische Codesequenzen mit der in
[Berechnung der Rechenzeitanforderung eines periodisch aufgerufenen Jobs.] dargestellten Formel
bestimmen. Dabei wird die eigene Rechenzeitanforderung zum Zeitpunkt t und die Anforderungen aller
übrigen höher- oder gleichprioren Rechenprozesse (Jobs) aufsummiert. Die Gaußklammer entspricht
im übrigen der Funktion ceil, die im Fall von Nachkommastellen den nächst höheren Integerwert
zurückliefert (ceil(2,2)=3).

Gleichung 2-5. Berechnung der Rechenzeitanforderung eines periodisch aufgerufenen Jobs.

t X t
Ci (t) = d e · tv,i + d e · tv,j ; mit j f r alle gleich − oder hherprioren Jobs
tp,i j
tp,j

Für Rechenprozess 1 ergibt sich damit:


t
C1 (t) = d e · 10ms
30ms
Die Funktion gibt 10ms für 0<t≤30ms zurück, 20ms für 30ms<t≤60ms usw. Für diesen Rechenprozess
ist die Bedingung [C(t) kleiner gleich t] erfüllt, er kann in „Echtzeit“ bearbeitet werden.
Für Rechenprozess 2 ergibt sich:
t t
C2 (t) = d e · 15ms + d e · 10ms
45ms 30ms
Die Funktion gibt 25ms für 0<t≤30ms zurück, 35ms für 30ms<t≤45ms, 50ms für 45ms<t≤60ms usw.
Für diesen Rechenprozess ist die Bedingung [C(t) kleiner gleich t] ebenfalls erfüllt, er kann in „Echtzeit“
bearbeitet werden.
Für Rechenprozess 3 ergibt sich:
t t t
C3 (t) = d e · 15ms + d e · 10ms + d e · 15ms
60ms 30ms 45ms

32
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Die Funktion gibt 40ms für 0<t≤30ms zurück, 50ms für 30ms<t≤45ms, 65 für 45ms<t≤60ms usw. Für
diesen Rechenprozess ist die Bedingung [C(t) kleiner gleich t] nicht erfüllt (C(60)=65ms), er kann nicht in
„Echtzeit“ bearbeitet werden.

2.4.4. Echtzeitnachweis bei Deadline-Scheduling

2.4.4.1. Ereignisstrom-Modell
Beim Ereignisstrom-Modell handelt es sich um eine formale Methode zur Beschreibung des Auftretens
von Ereignissen (Zeitpunkt, Häufigkeit und Abhängigkeiten zwischen Ereignissen). Mit Hilfe des Modells
können Worst-Case Situationen ermittelt und ein Echtzeitnachweis durchgeführt werden [Gresser93].
Das Verfahren setzt als Schedulingverfahren ein Deadlinescheduling voraus, welches im Abschnitt
Scheduling vorgestellt wird.
Das Modell besteht aus den Komponenten:

1. Ereignisstrom
2. Ereignisdichtefunktion und
3. Rechenzeitanforderungsfunktion.

I=1
I=2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 t
E(I)
5 Im Intervall der Länge 1
treten max. 2 Ereignisse
auf.
4
3
2 Im Intervall der Länge 8
1 treten max. 4 Ereignisse
auf

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 I

Abbildung 2-22. Ereignisstrom-Modell

Um die Ereignisdichtefunktion (Ereignisfunktion) zu bestimmen, muss bekannt sein, zu welchen Zeitpunk-


ten die Ereignisse im Prozess auftreten. Für jede Intervallgröße I von 0 bis ∞ bestimmt man die im Intervall
I maximale auftretende Anzahl Ereignisse. In Abbildung [Ereignisstrom-Modell] beispielsweise würde man
bei einer Intervallgröße nahe 0 genau ein Ereignis erfassen. Bei einem Intervall der Größe 1 könnte man
bereits zwei Ereignisse (wenn das Intervall zum Zeitpunkt t=7 beginnt) erfassen. Man schiebt also gedank-
lich die Intervalle unterschiedlicher Größe über die Ereignisse und erfaßt die im Intervall maximal sichtbare
Anzahl. Dieser Wert wird an die entsprechende Stelle der Ereignisdichtefunktion E(I) eingetragen.
Die auf die anschauliche Art gewonnene Ereignisdichtefunktion wird mathematisch als Ereignisstrom dar-
gestellt. Ein Ereignisstrom ist eine Anzahl Ereignistupel. Jedes Ereignistupel besteht aus der Angabe eines
Zyklus zi und eines Intervalls ai:

33
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Ereignis Tupel: () zi
ai

Da jedes Ereignis mehrfach auftreten kann, wird jedes Ereignistupel i noch mit einem Faktor ki multipli-
ziert. Für einmalig (also nicht periodisch) auftretende Ereignisse findet der Wert unendlich “∞” als Zyklus
Anwendung.

ES: { ( )}
ki
zi
ai i

Ein Ereignisstrom enthält also zu jeder Änderung in der Ereignisdichtefunktion ein Ereignistupel. In Abbil-
dung [Ereignisstrom] ist der Ereignisstrom der Ereignisdichtefunktion aus Abbildung Ereignisstrom-Modell
dargestellt. Bei einer Periode von 16 findet sich im Intervall der Größe (nahe) 0 genau 1 Ereignis. Bei einem
Intervall der Länge 4 finden sich 2 Ereignisse, bei einem Intervall der Länge 6 finden sich 3 und bei einem
Intervall der Länge 9 finden sich 4 Ereignisse.

ES:
{( )( )( )( ) ( )}
16 16 16 16 16
0 , 1 , 4 , 6 , 9

1 2 3 4 5
Ereignisse

Abbildung 2-23. Ereignisstrom

Die bisher nur grafisch vorgestellte Ereignisdichtefunktion läßt sich in mathematische Gleichungen um-
setzen. Gleichung Ereignisdichtefunktion eines periodischen Ereignisses stellt die allgemeine Form eines
periodischen Ereignisses dar.

Gleichung 2-6. Ereignisdichtefunktion eines periodischen Ereignisses

(
E(I) = int I + zz i − ai
i
)

Die soeben gegebene Interpretation entspricht der eines sogenannten homogenen Ereignisstromes. Beim
homogenen Ereignisstrom sind die endlichen (unendliche Zyklen dürfen damit weiterhin noch vorkom-
men) Zykluswerte einheitlich, beim inhomogenen Ereignisstrom sind die Zykluswerte unheitlich (siehe
Abbildung [Inhomogener Ereignisstrom]).

ES: {( )( )( )}
∞ 2 3
0 , 0 , 0

Abbildung 2-24. Inhomogener Ereignisstrom

Inhomogene Ereignisströme lassen sich durch Vervielfachung von Ereignistupeln auf das kleinste gemein-
same Vielfache vereinheitlichen (Abbildung [Homogener Ereignisstrom]).

34
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

ES:
{( ) ( )( )( )( )}
∞ 2
0 ,
6
0
6
, 2
6 6
, 3 , 4

Abbildung 2-25. Homogener Ereignisstrom

E(I)
9
8
7
6
5
2
0 ()
4
3

∞ 1
2 3
0 ()
() 0
0 1 2 3 4 5 6 7 8 9 10 I

Abbildung 2-26. Ereignisdichtefunktion des inhomogenen Ereignisstroms

Für den Realzeitnachweis ist neben dem Ereignisstrom noch die Kenntnis über Rechenzeit tV und Deadline
tZmax notwendig.

tZmax
E tV

Abbildung 2-27. Ereignisstrom-Modell

Im Ereignisstrom-Modell wird ein einfacher Rechenprozess durch seine Deadline tZmax und seine Rechenzeit
tV beschrieben (siehe Abbildung [Ereignisstrom-Modell]).

Aus der Ereignisdichtefunktion, der Deadline und der Rechenzeit läßt sich die Rechenzeitanforderungsfunk-
tion C(I) bestimmen, vorausgesetzt, der nächste aktive Rechenprozess wird über das Deadlinescheduling
bestimmt:

Gleichung 2-7. Rechenzeitanforderungsfunktion

n
C(I)= ΣE
i=1
i (I−tZmax,i) t v,i

Die Rechenzeitanforderungsfunktion des Rechenprozesses wird bestimmt, indem für jedes Ereignistupel
i die Ereignisdichtefunktion mit der Rechenzeit tV,i multipliziert und um die zum Ereignistupel gehörige
Deadline tZmax,i nach rechts verschoben wird (siehe Gleichung Rechenzeitanforderungsfunktion).
Die Echtzeitbedingung des Rechenprozess ist erfüllt, wenn jetzt: C(I)≤I ist. Graphisch veranschaulicht
bedeutet dies, dass die Rechenzeitanforderungsfunktion die Winkelhalbierende nicht überschreiten darf.

35
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

Umgekehrt gibt der Abstand von der Winkelhalbierenden an, welche Auslastung der Rechner durch Bear-
beitung des Rechenprozesses erfährt.
Bearbeitet ein Rechner mehrere Rechenprozesse, so sind die Rechenzeitanforderungsfunktionen der einzel-
nen Rechenprozesse aufzusummieren. Auch hier gilt wieder, dass C(I)ges ≤I ist.

Beispiel 2-4. Echtzeitnachweis bei Deadline-Scheduling

Es soll noch einmal das Beispiel Echtzeitnachweis bei prioritätsgesteuertem Scheduling aufgegriffen und
die Frage geklärt werden, ob die fristgerechte Bearbeitung der Aufgabe mit einem Deadlinescheduling-
Verfahren möglich ist.

ES= {( 300) ( 450) ( 600)}


C(I)
60

50

40

30

20

10

5 10 20 30 40 50 60 70 80 90 100 I
Abbildung 2-28. Echtzeitnachweis mit Hilfe des Ereignisstrom-Modells

Als erstes wird der Ereignisstrom erstellt. Dieser wird zur Rechenzeitanforderungsfunktion, wenn man den
Ereignisstrom mit der Verarbeitungszeit multipliziert und um die Deadline nach rechts verschiebt. Wie aus
Abbildung [Echtzeitnachweis mit Hilfe des Ereignisstrom-Modells] ersichtlich, wird die Winkelhalbierende
nicht übertroffen, die Aufgabe ist also bei Verwendung eines Deadline-Schedulings fristgerecht zu bearbei-
ten.

2.4.4.2. Behandlung abhängiger Ereignisse


Das Ereignisstrom-Modell ermöglicht den Nachweis über die Einhaltung der Zeitanforderungen auch von
abhängigen Ereignissen. Die Kenntnis über Abhängigkeiten zwischen Ereignissen entschärft die zeitlichen
Anforderungen, der bisherige Ansatz, zeitlich abhängige Ereignisse wie zeitlich unabhängige Ereignisse zu
betrachten, führt in den meisten Fällen zu ungünstigeren Ergebnissen.
Der einfachste Weg, zeitlich abhängige Ereignisse zu verarbeiten besteht darin, die abhängigen Ereignisse
in einem einzigen Ereignisstrom zusammenzufassen. Bei dem auf diese Art neu gewonnenen Ereignisstrom
ist für die Berechnung der Ereignisdichtefunktion darauf zu achten, dass für die Berechnung die entspre-
chenden Werte für tV,i und tZmax,i eingesetzt werden.

36
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

6T
2T
tP =6T
6T
3T
tP =6T
ES: 2 { ( )} 6
0

1 2 3 4 5 6 7 8 9 10 11 t
E(I)
4
3
RP1
2 RP2
1

1 2 3 4 5 6 I

Abbildung 2-29. Prozessbeschreibung und Ereignisdichtefunktion

Betrachten wir zunächst zwei unabhängige Prozesse, die beide eine Prozesszeit von tP=6T besitzen. Re-
chenprozess RP1 besitze eine Verarbeitungszeit von tV,1=2T und Prozess RP2 besitze eine Verarbeitungszeit
von tV,2=3T. Falls die maximal zulässige Reaktionszeit tZmax beider Rechenprozesse identisch mit der Prozes-
szeit tP ist, ergeben sich die in Abbildung [Prozessbeschreibung und Ereignisdichtefunktion] dargestellten
Ereignisdichtefunktionen.

C(I)
6
5
4
3 RP2
2 RP1
1
1 2 3 4 5 6 I

Abbildung 2-30. Rechenzeitanforderungsfunktion C(I)

Mit Kenntnis der Prozessparameter läßt sich daraus die Rechenzeitanforderungsfunktion C(I) erstellen (Ab-
bildung [Rechenzeitanforderungsfunktion C(I)]). Beide Rechenprozesse sind - so das Ergebnis - innerhalb
der gestellten Zeitanforderungen bearbeitbar.
C(I)=int((I-tZmax,1+6T-0T)/6T) · 2T + int((I-Zmax,2+6T-0T)/6T) · 3T
C(0)=int(0/6) · 2T + int(0/6) · 3T = 0
C(6)=int(6/6) · 2T + int(6/6) · 3T = 5T
C(7)=int(7/6) · 2T + int(7/6) · 3T = 5T
Werden allerdings die Anforderungen derart vergrößert, dass bei gleichgebliebener Prozesszeit tP=6T die
maximal zulässige Reaktionszeit (Deadline) von RP1 auf tZmax,1 =3T und die maximal zulässige Reaktionszeit
von RP2 auf tZmax,2=4T festgelegt wird,

37
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

3T
2T
tP =6T
4T
3T
tP =6T

ist bei unabhängigen Rechenprozessen eine fristgerechte Bearbeitung nicht mehr möglich (Abbildung
[Rechenzeitanforderungsfunktion C(I) bei verschärften Bedingungen]).
C(I)=int((I-tZmax,1+6T-0T)/6T) · 2T + int((I-Zmax,2+6T-0T)/6T) · 3T
C(0)=int(3/6) · 2T + int(2/6) · 3T = 0
C(3)=int(6/6) · 2T + int(5/6) · 3T = 2T
C(4)=int(7/6) · 2T + int(6/6) · 3T = 5T

C(I)
7
6
5
4
3
2
1
1 2 3 4 5 6 I
Abbildung 2-31. Rechenzeitanforderungsfunktion C(I) bei verschärften Bedingungen

Würde aber eine Abhängigkeit zwischen dem Auftreten der beiden Rechenprozesse bestehen, beispiels-
weise derart, dass das Ereignis 2 grundsätzlich zwei Zeiteinheiten (2T) nach Ereignis 1 auftritt, könnte die
Bearbeitung zeitgerecht erfolgen.

ES:{( )( )}
6 6
0 , 2

1 2 3 4 5 6 7 8 9 10 11 t
Abbildung 2-32. Auflösung der Abhängigkeiten

Um dieses nachzuweisen wird aus den beiden Ereignisfolgen (Ereignisströmen) ein einzelner Ereignisstrom
gebildet und die Ereignisdichtefunktion erstellt (Abbildung [Auflösung der Abhängigkeiten]).
Die Rechenzeitanforderungsfunktion wird gemäß Gleichung Rechenzeitanforderungsfunktion berechnet.
Die Ereignisdichtefunktionen für die beiden Ereignistupel sind im negativen Bereich 0. Die Ereignisdichte-
funktionen sind desweiteren im Bereich 0 bis 6 respektive 2 bis 8 stetig und haben dort den Wert 1.
C(I)=E1(I-tZmax,1) tV,1 + E2(I-tZmax,2) tV,2 = 0
C(I)=int((I-tZmax,1+6T-0T)/6T) · 2T + int((I-Zmax,2+6T-2T)/6T) · 3T
C(I)=int((I-3T+6T-0T)/6T) · 2T + int((I-4T+6T-2T)/6T) · 3T

38
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

C(I)=int((I+3T)/6T) · 2T + int((I)/6T) · 3T
C(0T)=int(3/6) · 2T + int(0/6) · 3T = 0
C(3T)=int(6/6) · 2T + int(3/6) · 3T = 2T
C(4T)=int(7/6) · 2T + int(4/6) · 3T = 2T
C(5T)=int(8/6) · 2T + int(5/6) · 3T = 2T
C(6T)=int(9/6) · 2T + int(6/6) · 3T = 5T
C(7T)=int(10/6) · 2T + int(7/6) · 3T = 5T
C(8T)=int(11/6) · 2T + int(8/6) · 3T = 5T
C(9T)=int(12/6) · 2T + int(9/6) · 3T = 7T
C(10T)=int(13/6) · 2T + int(10/6) · 3T = 7T

C(I)
7
6
5
4
3
2
1
1 2 3 4 5 6 I
Abbildung 2-33. Rechenzeitanforderungsfunktion C(I)

Fußnoten
1. Die Einheit, die den Kontextswitch durchführt, wird Scheduler genannt.
2. Damit entspricht der Wert S(t) (S=Supplied Computation Time) zu einem Zeitpunkt ti in etwa dem
Load des Rechensystems. Da allerdings in einem Rechner im Regelfall nicht im vorhinein bekannt
ist, wieviel Rechenzeit ein rechenbereiter Rechenprozess benötigt, wird die Anzahl der rechenbereiten
Rechenprozesse als Load genommen.

39
Kapitel 2. Schritthaltende Verarbeitung und Echtzeitbetrieb

40
Kapitel 3. Realzeitbetriebssysteme

3.1. Lernziele

• Aufbau und Anforderungen des Betriebssystems.


• Philosophien und Konzepte in Betriebssystemen.
• Prinzipielles Verständnis für die Funktionsweise eines Betriebssystems bekommen.
• Wichtige Komponenten des Betriebssystems beschreiben und erklären können (Aufgabe und
Arbeitsweise).
• Datenfluß durch das Betriebssystem.
• Was ist ein Systemcall?
• Unterschied Systemcall - Funktionsaufruf.
• Schedulingverfahren.
• Aufgaben und Aufbau einer Memory-Management-Unit.

3.2. Überblick

3.2.1. Aufgaben und Anforderungen


Aus Systemsicht ist ein Betriebssystem die Bezeichnung für alle Softwarekomponenten, die

• die Ausführung der Benutzerprogramme,


• die Verteilung der Betriebsmittel (z.B. Speicher, Prozessor, Dateien),
ermöglichen, steuern und überwachen.
Das Betriebssystem stellt dem Benutzer die Sicht einer virtuellen Maschine zur Verfügung, die einfacher zu
benutzen ist als die reale Hardware, z.B.:

• Aus Sicht eines Benutzers steht der Rechner ihm allein zur Verfügung.
• Einfacher Zugriff auf Ressourcen wie Speicher, Geräte, Dateien (das wird erreicht durch Speichermana-
gement, Gerätetreiber und das Dateisystem).

Das Betriebssystem besteht aus einem Betriebssystemkern und aus sonstigen Systemkomponenten wie bei-
spielsweise den Dienstprogrammen (z.B. die Shell).
An das Betriebssystem werden die folgenden Anforderungen gestellt:

• Zeitverhalten

• Schnelligkeit
• Bei einem RTOS insbesondere die Realisierung kurzer Antwortzeiten.
• Zeitlicher Determinismus

• Geringer Ressourcenverbrauch

41
Kapitel 3. Realzeitbetriebssysteme

• Hauptspeicher
• Prozessorzeit

• Zuverlässigkeit und Stabilität


• Programmfehler dürfen das Betriebssystem und andere Programme nicht beeinflussen.

• Sicherheit
• Dateischutz, Zugangsschutz

• Flexibilität und Kompatiblität


• Erweiterbarkeit
• Einhalten von Standards (z.B. POSIX)
• Möglichkeit, für andere BS geschriebene Programme auszuführen

• Portabilität
• Skalierbarkeit

Ein Realzeitbetriebssystem hat insbesondere die Aufgabe:

• die Ressourcenverteilung sicherzustellen,


• den deterministischen Ablauf (insbesondere Scheduling) zu garantieren und
• die Angabe und das Einhalten von Zeitbedingungen zu ermöglichen.

Bild Realzeitsysteme und ihre Zeitanforderungen [TimMon97] spiegelt die Größenordnung wider, unter de-
nen Realzeitbetriebssysteme Verwendung finden. Hat man Zeitanforderungen im Minutenbereich, läßt sich
ein System durchaus noch von Hand steuern, unterhalb dieser Marke (etwa 1 Minute) reicht eine Auto-
matisierung auf Basis von Mechanik aus. Zeitanforderungen im Sekunden-Bereich lassen sich durchaus
mit einem Standardbetriebssystem erfüllen, im Millisekunden-Bereich jedoch benötigt man ein Realzeit-
betriebssystem. Gilt es Anforderungen im Mikrosekunden-Bereich zu erfüllen, müssen die notwendigen
Aktionen innerhalb einer ISR durchgeführt werden. Unterhalb dieser Grenze hilft nur noch eine Realisie-
rung in Hardware.

42
Kapitel 3. Realzeitbetriebssysteme

3.3. Aufbau und Struktur

Applications

Services Libraries Sonstige BS−Komponenten

Syscall Interface

I/O Subsystem Process Memory


Management Management Kernel

Device−Driver−Layer

Hardware

Abbildung 3-1. Betriebssystem-Architektur

Bild Betriebssystem-Architektur stellt den prinzipiellen Aufbau eines Betriebssystems dar. Die Treiber-
schicht abstrahiert Zugriffe auf die Hardware und stellt eine betriebssysteminterne, standardisierte Schnitt-
stelle zur Verfügung, um in das System neue Hardwarekomponenten systemkonform zu integrieren. Gerade
in Realzeitsystemen ist die Treiberschicht von zentraler Bedeutung. Denn nur wenn zusätzliche (proprie-
täre) Hardware systemkonform in das System integriert wird, kann der versprochene Determinismus des
Betriebssystems auch gewährleistet werden.
Die Integration von Hardware in das System über die Treiberschicht ermöglicht darüber hinaus auch den
systemkonformen und standardisierten Zugriff auf Hardware aus der Applikation heraus. Hierfür sorgt das
I/O Subsystem eines Betriebssystems. Bestimmte Gruppen von Hardware (z.B. Netzwerkkarten, SCSI, Fi-
lesysteme, PCI) benötigen ähnliche Funktionalitäten. Diese zur Verfügung zu stellen ist ebenfalls Aufgabe
des I/O Subsystems.
Eine wichtige Aufgabe für Betriebssysteme ist die Verteilung der Ressource CPU (Rechnerkern) auf meh-
rere Tasks, das sogenannte Scheduling. Diese Aufgabe wird durch den Block Process-Management darge-
stellt.
Speichermanagement (Adreßumsetzung und Speicherschutz) ist eine weitere wesentliche Aufgabe. Es darf
nicht möglich sein, dass eine normale Applikation ein komplettes Rechnersystem zum Absturz bringt. Da-
zu müssen aber die Speicherräume der unterschiedlichen Applikationen gegeneinander abgeschottet sein,
ein Speicherschutzmanagement ist notwendig. Die Komponente dazu heißt Memory-Management-Unit
(MMU) . Speicherschutz wird heutzutage massiv durch Hardware unterstützt.
Über sogenannte Softwareinterrupts können Applikationen Dienste des Betriebssystems in Anspruch neh-
men. Man spricht hier von sogenannten Systemcalls. Die Schnittstelle innerhalb des Betriebssytems, die
gemäß des ausgelösten Systemcalls den richtigen Dienst ausführt, wird als Systemcall-Interface bezeich-
net.
Die bisher genannten Blöcke gehören alle zum sogenannten Betriebssystemkern. Auf der dem Kern gegen-
überstehenden User-Ebene befinden sich die Applikationen, Dienstprogramme und Libraries. Dienstpro-
gramme sind zum Betrieb des Rechnersystems notwendig. Beispielsweise werden für die Konfiguration des
Systems (Zuteilung von Netzwerkadressen u.ä.) und auch zum Betrieb der Netzwerkdienste Dienstprogram-
me benötigt. Die Programme selbst greifen in den seltensten Fällen direkt über die Systemcall-Schnittstelle
auf die Dienste des Betriebssystems zu. Im Regelfall sind diese in einer Bibliothek gekapselt, die Standard-

43
Kapitel 3. Realzeitbetriebssysteme

funktionen (beispielsweise open, close, read und write) zur Verfügung stellt. Innerhalb der Library ist dann
der Systemcall selbst auscodiert.
Natürlich sind die Dienstprogramme des Betriebssystems im strengen Sinne auch Applikationen. Es wer-
den hier nur deshalb zwei Begriffe verwendet, um die zum Betriebssystem gehörigen Applikationen - eben
die Daemonen, Services oder einfach Dienstprogramme - von den selbstgeschriebenen Applikationen un-
terscheiden zu können.
Beim Aufbau eines Realzeitsystems erweitert der Ingenieur/Informatiker eventuell an zwei Stellen das Be-
triebssystem:

1. bei der Integration neuer Hardware (Treiber),


2. bei der Integration zusätzlicher Kernelmodule.

3.4. Betriebssystemkern
Arbeitet die CPU eine Task auf der User-Ebene ab, kann diese unterbrochen werden. Innerhalb des Be-
triebssystemkerns jedoch werden die dort rechnenden Betriebssystemeinheiten nur nach einem dedizierten
Schema unterbrochen.

User Level
2 5 unterbrechbar
1 Kernel Level
nicht 3 4
unterbrechabar Hardware Level

1 HW−Interrupt

2 SW−Interrupt (Systemcall)

3 HW−Interrupt (während eines Systemcalls)

4 HW−Interrupt beendet (Scheduler wird aufgerufen)

5 Scheduler übergibt CPU einer Task auf User−Ebene

Abbildung 3-2. Unterbrechungsebenen

Innerhalb des Betriebssystems kann man zwei Unterbrechungsebenen unterscheiden, einen Hardware- und
einen Kernellevel. Innerhalb der Hardwareebene können Unterbrechungen nur von höher priorisierten Hard-
wareinterrupts erfolgen. Einen Übergang von der Hardwareebene direkt in die Userebene gibt es nicht. Von
der Hardwareebene gibt es einen Übergang in den Kernellevel (also eine Anforderung von Seiten der Hard-
ware wird immer im Kernellevel beendet).

3.4.1. Prozess-Management
Die Fähigkeit der CPU, den normalen Programmablauf zu unterbrechen, wenn ein Interrupt auftritt, wird
genutzt, um die quasi parallele Bearbeitung mehrere Programme (Tasks) zu ermöglichen.

44
Kapitel 3. Realzeitbetriebssysteme

Tritt nämlich ein Interrupt auf, legt die CPU den Programmcounter auf den Stack (automatische Rettung
des Befehlszählers) und eventuell den Inhalt des (internen) Flagregisters, sperrt weitere Interrupts und ruft
die sogenannte Interrupt-Service-Routine (ISR) auf. Die Adressen der ISR’s befinden sich dabei in einer
Tabelle, wobei es für jede mögliche Unterbrechungsursache (z.B. externern Hardwareinterrupt auf Le-
vel 0, Softwareinterrupt oder unerlaubter Speicherzugriff) einen Tabelleneintrag (Vektortabelle) gibt (Bild
Interrupt Vektor Tabelle des 80386).

Tabelle 3-1. Interrupt Vektor Tabelle des 80386

Function Interrupt Instruction Which Can Cause Return Address Type


Number Exception Points to Faulting
Instruction
Dived Error 0 DIV, IDIV YES FAULT

Debug Exception 1 any instruction YES TRAP


NMI Interrupt 2 INT 2 or NMI NO NMI
One Byte Interrupt 3 INT NO TRAP
Interrupt on 4 INTO NO TRAP
Overflow
Array Bounds 5 BOUND YES FAULT
Check
Invalid OP-Code 6 Any Illegal Instruction YES FAULT

Device Not 7 ESC, WAIT YES FAULT


Available
Double Fault 8 Any Instruction That Can ABORT
Generate an Exception
Coprocessor 9 Coprocessor Tries to Access NO TRAP
Segment Overrun Data Past the End of a Segment
Invalid TSS 10 JMP, CALL, IRET, INT YES FAULT

Segment Not 11 Segment Register Instructions YES FAULT


Present
Stack Fault 12 Stack References YES FAULT

General Protection 13 Any Memory Reference YES FAULT


Fault
Page Fault 14 Any Memory Access or Code YES FAULT
Fetch
Coprocessor Error 16 ESC, WAIT YES FAULT

Intel Reserved 17-32


Two Byte Interrupt 0-255 INT n NO TRAP

Am Ende der ISR steht der Befehl "Return Interrupt" (iret, reti). Dieser Befehl restauriert wieder das
Prozessor-Flag-Register und lädt den zuvor auf den Stack befindlichen Wert des Programmcounters in den
Programmcounter, wodurch die Abarbeitung der ursprünglichen Aufgabe fortgesetzt wird.

45
Kapitel 3. Realzeitbetriebssysteme

Address
Stack
0x1000
PC 0x1002 1
0x1004 Normal
2 registers
0x1006 Program−Execution
0x1008 7 0x1006
0x100a ...

ISR 0xa000 save registers 3


0xa002
interrupt
0xa004 treatment 4

restore registers 5
return interrupt 6

Code Memory

PC = Program Counter

Abbildung 3-3. Interruptverarbeitung

Bild Interruptverarbeitung verdeutlicht die Vorgänge noch einmal:

1. Die CPU arbeitet ein Programm ab.


2. Während der Programmabarbeitung wird (z.B. von der Systemuhr) ein Interrupt ausgelöst. Die Abar-
beitung des gerade begonnenen Befehls wird zuende geführt1. Dann wird der Inhalt des Befehlszählers
(0x1006) auf den Stack abgelegt, abhängig vom Prozessor ebenfalls Registerinhalte (beispielsweise das
Flagregister). Aufgrund der Interruptursache wird von der CPU der Befehlszähler (PC) auf die Start-
adresse der Interrupt-Bearbeitungsroutine (hier 0xa000) gesetzt, und die CPU arbeitet die Befehle ab
dieser Adresse ab.
3. Die ISR wird zunächst die sonstigen CPU-Register retten.
4. Daran schließt sich die eigentliche Interrupt-Behandlung an.
5. Am Ende der ISR werden die vorher gesicherten CPU-Register wieder zurückgeholt
6. und der Befehl “Return Interrupt” ausgeführt. Der Befehl bewirkt, dass vom Stack die dort eventu-
ell abgelegten Flagregister zurückgespeichert werden und der PC wieder mit der Rücksprungadresse
(0x1006) geladen wird.
7. Der normale Programmablauf wird damit fortgesetzt.

46
Kapitel 3. Realzeitbetriebssysteme

Interrupt
zum
Kontextwechsel

Retten des Kontextes des


unterbrochenen Rechenprozesses j

eventuelle Auftragsbearbeitung

Scheduler:
Auswahl des nächsten
Rechenprozesses i

Lade Kontext
des Rechenprozesses i

Return zu PCi

Abbildung 3-4. Interrupt-Service-Routine in einem Realzeitbetriebssystem

In einem Multitasking Betriebssystem wird dieser Mechanismus der Programmunterbrechung


genutzt, um die quasi parallele Abarbeitung mehrerer Aufgaben zu ermöglichen. Dazu wird
bei jedem Interrupt zunächst eine vom Betriebssystem zur Verfügung gestellte ISR (Bild
Interrupt-Service-Routine in einem Realzeitbetriebssystem) aufgerufen. In dieser ISR werden die
Prozessorregister und die auf dem Stack abgelegten Werte (PC und Flags) in eine zum gerade aktiven
Programm gehörigen Datenstruktur (Process Control Block, Bild Process-Kontrollblock (TCB)) abgelegt.
Danach kann die eigentliche Ursache des Interrupts bearbeitet werden. Am Ende der Interruptbearbeitung
wird - das ist im einfachen Fall noch während der ISR - ein nächstes Programm ausgewählt, das die CPU,
den Rechnerkern, zugeteilt bekommt. Dazu werden die Prozessorregister mit den Kopien der Register zum
Zeitpunkt der letzten Unterbrechung der Task geladen, Flags und insbesondere der Programmcounter
werden so auf dem Stack abgelegt, dass die vom Prozessor bei Eintritt des Interrupts abgelegten Werte
überschrieben werden, und es wird schließlich der Befehl “Return Interrupt” ausgeführt. Dadurch wird der
Befehlszähler mit dem “neuen” Wert geladen, und die Bearbeitung der “neuen” Task wird fortgesetzt.

47
Kapitel 3. Realzeitbetriebssysteme

Address RETI
0x1000 Stack
PC 0x1002 1
0x1004 Normal
2
0x1006 Program−Execution
0x1008 0x1006 0x2000
0x100a
...
7
0x2000 Task 3
current 0xf020
ISR 0xa000 save registers 3
0xa002
0xa004 interrupt
4 Tasklist
treatment
complete 0xf000
schedule 5 Task
Information
contextswitch
6
0xf020
return interrupt complete
Task
Information
Code Memory
complete 0xf040
0x2000
Task
Information

Abbildung 3-5. ISR mit Scheduler

Unterschied zu einer gewöhnlichen ISR ist damit (Bild ISR mit Scheduler), dass

1. die Register nicht auf den Stack gerettet werden, sondern in die Speicherzellen des Process Control
Blocks (PCB) der gerade aktiven Task. Die Adresse des PCB des gerade aktiven Rechenprozesses ist
im Regelfall in einer globalen Variable (“current”) abgespeichert.
2. beim Contextswitch die Register des Prozessors nicht zwangsläufig mit den Werten geladen werden,
die vor der Unterbrechung geladen waren. Stattdessen werden die Register aus dem PCB genommen,
den der Scheduler ausgewählt hat.
3. die Rücksprungadresse auf dem Stack manipuliert wird, d.h. der durch den Prozessor dort bei der
Unterbrechung abgelegte Wert wird mit dem Wert für den PC überschrieben, der sich in dem PCB der
neuen aktiven Task befindet.

48
Kapitel 3. Realzeitbetriebssysteme

Prozeß−Kontrollblock/
Virtuelle Maschine

Prozeß Priorität

Quantum

Prozeß−Zustand

Exitcode

Maschinen−Zustand
(Register, Stack usw.)

Abbildung 3-6. Process-Kontrollblock (TCB)

Damit ist ersichtlich, dass insbesondere das sogenannte Prozessmanagement, aber eigentlich auch alle an-
deren Dienste des Betriebssystemkerns über Interrupts angefordert werden.
Zwei Arten von Interrupts werden unterschieden: Softwareinterrupts von Hardwareinterrupts.

• Über Softwareinterrupts (Systemcalls) fordern Benutzerprogramme Dienste des Betriebssystems an2.


• Über Hardwareinterrupts fordern Hardwarekomponenten (Systemuhr, Platten, Modem usw.) Dienste des
Betriebssystems an.
Mit jedem Interrupt findet damit ein Übergang in den Kernel-Mode (Supervisor-Mode) statt. In der ISR
(Interrupt-Service-Routine) wird zunächst die dem Interrupt zugehörige Aufgabe durchgeführt und danach
die Kontrolle dem Scheduler übergeben, der den nächsten RechenProzess auswählt.

Merke: Dienste des Betriebssystems werden immer über Interrupts angestoßen.

Die den Zustand einer Task (also des im System instanziierten Programms) genau beschreibende Daten-
struktur Prozess-Control-Block speichert die folgenden Informationen:

• Speicherplätze, in denen jeweils alle Prozessorzustände (Registerinhalte) gespeichert werden, mit wel-
chen dieser Rechenprozess zum letzten Mal unterbrochen wurde.
• Angaben über den Zustand des Rechenprozesses, gegebenenfalls über die Bedingungen, auf die der Re-
chenprozess gerade wartet.
• Angaben über die Priorität des Rechenprozesses.
Der Prozess-Control-Block spezifiziert damit einen Rechenprozess eindeutig.
Anhand der Informationen im PCB entscheidet der Scheduler, ob eine Task die CPU zugeteilt bekommt
oder nicht.

49
Kapitel 3. Realzeitbetriebssysteme

Start Task lauffähig Ende der


Wartebedingung

"nicht mehr
"höchste höchste
ruhend Priorität" Priorität" schlafend

aktiv
StoppTask Warten, z.B. auf
− Betriebsmittel
− E/A−Aufruf−Ende
− Zeit

Abbildung 3-7. Task-Zustände [Färber94]

Die wichtigste Information im PCB zur Auswahl des nächsten Rechenprozesses ist der Zustand der Task.
Jede Task hat dabei im wesentlichen 4 mögliche Zustände, wie im Bild Task-Zustände [Färber94] ersicht-
lich.

Ruhend
Bevor ein Rechenprozess überhaupt bearbeitet wird, befindet er sich im Zustand ruhend. Aus diesem
Zustand kommt der Prozess nur, wenn er durch das Betriebssystem (welches im Regelfall durch einen
anderen Rechenprozess dazu aufgefordert wurde) gestartet wird. Im Zustand ruhend existiert im Ker-
nel noch kein PCB für die Task. Der Zustand ruhend wird oft auch als Zustand terminiert bezeichnet.

Lauffähig
Der Scheduler wählt aus der Liste der Prozesse denjenigen lauffähigen Prozess als nächstes zur Bear-
beitung aus, der die höchste Priorität hat. Mehrere Tasks im System können sich im Zustand lauffähig
befinden.

Aktiv
Immer nur ein Rechenprozess im System kann sich im Zustand aktiv befinden. Der aktive Prozess
bekommt die CPU zugeteilt und wird ausgeführt, bis er entweder
• sich selbst beendet (in den Zustand ruhend) versetzt, oder
• auf ein Betriebsmittel warten muß (z.B. auf das Ende eine I/O-Aufrufes), oder
• nicht mehr die höchste Priorität hat, da beispielsweise die Wartebedingung eines höherprioren
Prozesses erfüllt wurde.

Wartend
Ein Prozess wird in den Zustand wartend versetzt, wenn nicht mehr alle Bedingungen zur direkten Aus-
führung erfüllt sind. Eine Task kann dabei auf unterschiedliche Bedingungen warten, beispielsweise
auf das Ende von I/O-Aufrufen, auf den Ablauf einer definierten Zeitspanne oder auf das Freiwerden
sonstiger Betriebsmittel.

50
Kapitel 3. Realzeitbetriebssysteme

TCB

TCB

Task Thread

Code Segment Data Segment Stack Segment Stack Segment

Abbildung 3-8. Speicherbereiche einer Task

Bisher wurde immer davon ausgegangen, dass die kleinste Einheit im Prozessmanagement der Rechenpro-
zess bzw. die Task ist. Vielfach werden aber vom Scheduler auch Threads gescheduled.
Bei Threads handelt es sich um sogenannte leichtgewichtige Prozesse. Sowohl Tasks als auch
Threads bestehen prinzipiell aus einem Speichersegment für Code, Daten und für den Stack (Bild
Speicherbereiche einer Task). Der Unterschied zur Task ist, dass zu einer Task gehörige Threads alle ein
und denselben Adreßraum teilen. Das bedeutet also, dass Threads auf dasselbe Daten und Codesegment
zugreifen, nur ein eigenes Stacksegment besitzen.
Aufgrund dieses Unterschiedes lassen sich Threads

• schneller erzeugen (beim Erzeugen von Tasks werden im Regelfall Datensegmente kopiert, das fällt bei
der Erzeugung von Threads weg).
• Darüber hinaus kann - abhängig von der Applikation - eine vereinfachte Inter-Prozess-Kommunikation
(beispielsweise wird kein Shared-Memory benötigt) verwendet werden.

Tabelle 3-2. Vergleich Task und Thread

Task Thread
Eigener PCB Eigener PCB
Eigenes Codesegment Codesegment der zugehörigen Task
Eigenes Datensegment Datensegment der zugehörigen Task
Eigenes Stacksegment Eigenes Stacksegment

Für das Erzeugen von Tasks und das Erzeugen von Prozessen stellt das Betriebssystem Systemcalls zur
Verfügung. Diese Systemcalls legen einen neuen PCB an und kopieren - falls notwendig - die zugehörigen
Speicherbereiche (bei Tasks wird das Datensegment kopiert und nur ein neues Stacksegment angelegt, bei
Threads wird nur ein neues Stacksegment angelegt).
Ein Beispiel für die Erzeugung einer Task und eines Threads ist in Bild Programm zum Erzeugen einer Task
und in Bild Programm zum Erzeugen eines Threads zu finden.

#include <stdio.h>

51
Kapitel 3. Realzeitbetriebssysteme

void parent()
{
printf(”The parent process has ID %d\n”, getpid() );
}

void child()
{
printf(”The child process has ID %d\n”, getpid() );
return;
}

int main( int argc, char **argv )


{
if( fork()!=0 ) {
parent();
wait();
} else {
child();
}
printf(”Exit process %d\n”, getpid() );
exit( 0 );
}

Abbildung 3-9. Programm zum Erzeugen einer Task

#include <stdio.h>
#include <pthread.h>

void *ThreadFunction( void *args )


{
printf( "%s - I am fine!\n", (char *)args );
pthread_exit( NULL );
}

main( int argc, char **argv )


{
pthread_t MyThread;
char *Hello="How are you, Thread?";

if( pthread_create( &MyThread, NULL, ThreadFunction, Hello )!= 0 ) {


fprintf(stderr,"creation of thread failed\n");
exit( -1 );
}
/* Now the thread is running concurrent to the main task */
printf("Here is the main task!\n");
/* waiting for the termination of MyThread */
pthread_join( MyThread, NULL );
}

Abbildung 3-10. Programm zum Erzeugen eines Threads

Posix-Funktionen zur Verwaltung von Threads:

int pthread_create( pthread_t * thread, pthread_attr_t * attr, void * (*start_routine)(void


*) , void * arg);

pthread_create creates a new thread of control that executes concurrently with the calling thread.
The new thread applies the function start_routine passing it arg as first argument. The new
thread terminates either explicitly, by calling pthread_exit(3), or implicitly, by returning from the

52
Kapitel 3. Realzeitbetriebssysteme

start_routine function. The latter case is equivalent to calling pthread_exit(3) with the result returned
by start_routine as exit code. The attr argument specifies thread attributes to be applied to the new
thread. See pthread_attr_init(3) for a complete list of thread attributes. The attr argument can also be
NULL, in which case default attributes are used: the created thread is joinable (not detached) and has
default (non real-time) scheduling policy.

void pthread_exit( void *retval );

pthread_exit terminates the execution of the calling thread. All cleanup handlers that have been set for
the calling thread with pthread_cleanup_push(3) are executed in reverse order (the most recently pu-
shed handler is exe cuted first). Finalization functions for thread-specific data are then called for all keys
that have non- NULL val ues associated with them in the calling thread (see pthread_key_create(3)).
Finally, execution of the calling thread is stopped.
The retval argument is the return value of the thread. It can be consulted from another thread using
pthread_join(3).

int pthread_join( pthread_t thread , void ** thread_return );

pthread_join suspends the execution of the calling thread until the thread identified by th terminates,
either by calling pthread_exit(3) or by being cancelled.
If thread_return is not NULL, the return value of th is stored in the location pointed to by thread_return.
The return value of th is either the argument it gave to pthread_exit(3), or PTHREAD_CANCELED if
th was cancelled.
The joined thread th must be in the joinable state: it must not have been detached using
pthread_detach(3) or the PTHREAD_CREATE_DETACHED attribute to pthread_create(3).
When a joinable thread terminates, its memory resources (thread descriptor and stack) are not deallo-
cated until another thread performs pthread_join on it. Therefore, pthread_join must be called once for
each joinable thread created to avoid memory leaks.
At most one thread can wait for the termination of a given thread. Calling pthread_join on a thread th
on which another thread is already waiting for termination returns an error.

int pthread_detach( pthread_t th );

pthread_detach put the thread th in the detached state. This guarantees that the memory resources
consumed by th will be freed immediately when th terminates. However, this prevents other threads
from synchronizing on the ter mination of th using pthread_join.
A thread can be created initially in the detached state, using the detachstate attribute to
pthread_create(3). In contrast, pthread_detach applies to threads created in the joinable state, and
which need to be put in the detached state later.
After pthread_detach completes, subsequent attempts to perform pthread_join on th will fail. If another
thread is already joining the thread th at the time pthread_detach is called, pthread_detach does nothing
and leaves th in the joinable state.

53
Kapitel 3. Realzeitbetriebssysteme

3.4.2. Memory-Management
Aufgaben der Memory-Management-Unit ist

• der Speicherschutz und


• die Adreßumsetzung.

Speicherschutz

• Applikationen (Prozesse, aber nicht Threads) werden voreinander geschützt, indem jeder Prozess
seinen eigenen Adreßraum bekommt. Zugriff ist damit nur möglich auf eigene Daten-, Stack- und
Codesegmente.
• Daten bzw. Teile der Applikation werden vor Fehlzugriffen geschützt. Greift eine Applikation auf
Speicherbereiche zu, die nicht zur Applikation gehören, oder versucht die Applikation aus einem
Codesegment Daten zu lesen, führt dies - dank MMU - zu einer Ausnahmebehandlung.

Adreßumsetzung

• Programme sollen einen einheitlichen Adreßraum bekommen, um das Laden von Programmen zu
beschleunigen und Shared-Libraries zu ermöglichen. War in früheren Zeiten der Loader des Betrieb-
ssystems, der Applikationen in den Speicher geladen und danach gestartet hat, dafür verantwortlich,
dem Programm die richtigen (freien) Adressen zuzuweisen, kann mit MMU der Linker bereits die
Adressen vergeben. Aus Sicht jeder Applikation beginnt der eigene Adreßraum ab der Adresse 0.
• Mehrere Tasks können sich ein (Code-) Segment teilen. Durch die Trennung von Code- und
Datensegmenten und mit Hilfe der MMU können mehrere Tasks, die auf dem gleichen Programm
beruhen, ein oder mehrere Codesegmente teilen. Dadurch wird der Hauptspeicherbedarf reduziert.
• Durch die MMU kann virtueller Speicher zur Verfügung gestellt werden. Ist der physikalische Spe-
icher kleiner als der logische Adreßraum (vorgegeben im Regelfall durch die Breite der Adreßregis-
ter), kann Hintergrundspeicher wie Hauptspeicher verwendet werden. Dazu wird der Hauptspeicher
in Seiten (oder sogenannte Kacheln) eingeteilt, und - wenn keine freien Kacheln mehr zur Verfü-
gung stehen - auf den Hintergrundspeicher (Festplatte) ausgelagert (Paging und Swapping). Dieser
Mechanismus hat jedoch für Realzeitsysteme keine besondere Bedeutung, da er zu Undeterminis-
men führt.

54
Kapitel 3. Realzeitbetriebssysteme

Physik.

CPU Speicher
CB CB
(Prozessorkern) MMU
AB AB

Logische Physikalische
Adresse Adresse

MMU = Memory Management Unit


AB=Adreßbus
CB=Controlbus

Abbildung 3-11. Adreßumsetzung mittels MMU

MMU’s bestehen aus Hardware, die durch entsprechende Software initialisiert werden muß. Heutige Mi-
kroprozessoren haben im Regelfall eine MMU integriert. Prinzipiell funktioniert der Vorgang so, dass der
Prozessorkern eine logische Adresse erzeugt. Diese logische Adresse wird durch die MMU in eine physi-
kalische Adresse umgesetzt. Die Umsetzungsregeln selbst werden dazu in die MMU geladen. Eine MMU
muß also durch das Betriebssystem initialisiert werden.
Prinzipiell kann eine MMU den physikalischen Speicher auf zwei Arten aufteilen: in Segmente und in
Seiten. Während Speicher-Seiten feste (physikalische) Größen haben und einander auch nicht überlappen,
ist die Größe der Segmente ebenso dynamisch, wie ihre wirkliche Lage im Hauptspeicher.

3.4.2.1. Segmentierung
Insbesondere mit den Intel 8086 Prozessoren sind Speicherverwaltungseinheiten, die auf Segmenten basie-
ren, eingeführt worden. Die Segmentierung diente hierbei vor allem der Erweiterung des logischen (man
merke, nicht des physikalischen!) Adreßraums (der physikalische Speicher war/ist größer als der logische
Adreßraum). Man findet diese Methode auch heute noch häufig bei einfachen (8 oder 16 bit) Mikropro-
zessoren vor und - in Kombination mit Paging - auch bei den modernen Prozessoren. Damit spielt die
Segmentierung immer noch - insbesondere bei der Realisierung eingebetteter Systeme - eine große Rolle.
Ein Segmentregister kennzeichnet die Anfangsadresse (Basisadresse) eines Segmentes. Diese Anfangs-
adresse wird zu jeder vom Prozessor erzeugten logischen Adresse hinzuaddiert. Um eine Erweiterung des
Adreßraumes zu erhalten, ist es natürlich notwendig, dass die Basisadresse breiter ist als die vom Prozessor
erzeugte logische Adresse. Beim 8086 beispielsweise werden 16bit logische Adressen erzeugt. Die Seg-
mentregister sind jedoch 20bit breit, wobei die letzten 4bit grundsätzlich auf 0 gesetzt sind. Damit können
Segmente immer nur auf Adressen beginnen, die durch 16 teilbar sind. Da von den 20bit der Basisadresse
nur 16bit variabel sind, können diese 16bit durch einen entsprechenden Maschinenbefehl belegt werden.
Im System werden meistens mehrere Segmentregister vorgehalten. Beim 8086 sind dies beispielsweise:

• ein Segmentregister für Code,


• zwei für Daten und
• eines für den Stack.

Zu Beginn einer Applikation werden die Segmentregister belegt, danach kann die Applikation mit einem
Maschinenbefehl auf Speicherzellen zugreifen, solange sie innerhalb des logischen Adreßraums (beim 8086

55
Kapitel 3. Realzeitbetriebssysteme

64kByte) bleibt. Benötigt die Applikation jedoch mehr als 64KByte Hauptspeicher, muß vor dem Zugriff
das Segmentregister wieder umgeladen werden; ein zeitaufwendiger Vorgang3.

16bit 20bit
Logische Physikalische
Adresse
+ Adresse

Basis 20bit
Adresse
0000 Code Segment
0000 Stack Segment
0000 Data Segment
0000 Extra Data Segment
15 . . . ...0
4 Basis−Adreß−Register

Abbildung 3-12. Segmentierung beim 8086 [Färber94]

Segment Offset Segment Offset Segment Offset


0200 : 0004 0000 : 2004 0100 : 1004

0200 0000 0100


0004 2004 1004
Phys.Adresse 0x02004 0x02004 0x02004

Normalisieren:
SegmentRegister = SegmentRegister + (Offset >> 4);
Offset = Offset & 0x000F;

Abbildung 3-13. Beispiel zum Normalisieren

Problem: eine physikalische Adresse kann über mehrere logische Adressen ausgedrückt werden. Das er-
schwert einen Pointer-Vergleich. Pointer müssen erst normalisiert werden. Dieser Vorgang ist zeitaufwen-
dig und fehleranfällig.
Die Segmentierung bietet keinen besonderen Speicherschutz, abgesehen davon, dass zunächst einmal - ei-
ne richtige Belegung der Segmentregister vorausgesetzt - ein Zugriff auf das Codesegment mit normalen
Datenlesebefehlen nicht möglich ist.

3.4.2.2. Seitenorganisation
Bei der Seitenorganisation wird der Hauptspeicher in gleich große (beispielsweise 4KByte) Seiten bzw.
Kacheln eingeteilt. Die vom Prozessor erzeugte logische Adresse selbst besteht aus zwei semantischen
Einheiten, einem Teil, der innerhalb der MMU den sogenannten Seitendeskriptor (Kachelbeschreibung)
auswählt, und einem Teil, der eine Speicherzelle innerhalb der Kachel auswählt.

56
Kapitel 3. Realzeitbetriebssysteme

Seitendeskriptoradresse Seitenoffset

31 28 27 23 15 12 11 9 8 7 6 5 4 3 2 1 0

Abbildung 3-14. Strukturierung der logischen Adresse

Zugriffsrechte Kachel−Nummer
15 12 11 0

Schreib−Zugriff erlaubt
Daten−Zugriff erlaubt
Code−Zugriff erlaubt
Valid (Kachel im Speicher vorhanden)

Abbildung 3-15. Aufbau eines Seitendeskriptors

Der Seitendeskriptor besteht ebenfalls aus zwei semantischen Teilen. Der erste Teil enthält Flags, die die
Zugriffsrechte kontrollieren, der zweite Teil enthält die eigentliche physikalische Seitenadresse.
Im Regelfall existieren vier Flags:

Schreibflag
Ist dieses Flag gesetzt, darf auf die Seite schreibend zugegriffen werden. Versucht der Prozessor auf
die Seite zu schreiben, obwohl das Flag zurückgesetzt ist, wird ein Fehler (Bus-Error) ausgelöst.

Daten-Zugriff
Dieses Flag gibt an, ob die Seite Daten enthält oder nicht. Ist das Flag gültig gesetzt, darf der Prozessor
aus dem Segment Daten lesen. Ist das Flag ungültig gesetzt, löst ein Lesezugriff einen Fehler (Bus-
Error) aus.

Code-Zugriff
Dieses Flag gibt an, ob die Seite Code enthält oder nicht. Ist das Flag gültig gesetzt, darf der Prozessor
die Daten in seinen Programmspeicher laden. Ist das Flag ungültig gesetzt und der Prozessor versucht
aus der Kachel Code zu lesen, wird ein Fehler (Bus-Error) ausgelöst.

Kachel im Speicher
Dieses Flag gibt an, ob sich die Seite im Speicher befindet oder (auf den Hintergrundspeicher) aus-
gelagert wurde. Befindet sich die Seite nicht im Hauptspeicher, muß ein Fehler-Signal (Bus-Error)
ausgelöst werden, so dass das Betriebssystem für das Nachladen der Seite sorgen kann.

57
Kapitel 3. Realzeitbetriebssysteme

Adressumsetzspeicher

Zugriffsrechte Kacheladresse

31
    
   

Auswahl/  

23
Adressierung Auswahl/
des
 

Seiten−Deskriptors Adressierung
der
 

Kachel (Seite)  

 

 

     
   

12
 

12
11
     
   

11  

     
   

 

     
   

Adresse/Offset innerhalb der Kachel (Seite)


 

     
   

 

     
   

 

     
   

 

     
   

0 0
 

logische Adresse (32bit) physikalische Adresse (24bit)

Abbildung 3-16. MMU auf Basis von Seitenadressierung

Die MMU ist entweder im Prozessor integriert und über eigene Befehle ansprechbar, oder sie befindet sich
als eigener Baustein im Adreßraum des Prozessors. In diesem Fall ist sichergestellt, dass beim Startup des
Systems die MMU einen definierten Zustand hat, so dass auch ohne Vorbelegung das Betriebssystem die
Möglichkeit hat, die MMU zu initialisieren.
Wie aus der Zeichnung ersichtlich, wird der Zugriff auf den Hauptspeicher durch die MMU verzögert, da die
MMU selbst auch eine Zugriffszeit besitzt. Moderne Mikroprozessoren verwenden als MMU-Speicher den
Hauptspeicher, so dass im ungünstigen Fall mehrere Hauptspeicherzugriffe notwendig sind, um schließlich
das gewünschte Datum zu bekommen.
Eine MMU, die auf Basis der Aufteilung des Speichers in Seiten funktioniert, kann leicht mit Hilfe von
Speicherbausteinen aufgebaut werden. Der Speicher beinhaltet die Seitendeskriptoren. Mit den oberen Bits
der logischen Adresse wird der Speicher adressiert. Die Daten, die daraufhin am Datenausgang (Datenbus)
des Speicherbausteins sichtbar werden, werden teils als Adresse der Kachel, teils als Kontrollsignale zur
Verifikation der Zugriffsrechte, verwendet. Konkret wird also ein Teil des Datenbusses auf den Adreßbus
gemappt. Der Datenbus selbst muß gemultiplext sein, d.h. damit der MMU-Speicher auch belegt werden
kann, muß der Datenbus auch mit dem Datenbus des Prozessorkerns verbunden werden.
Ein Teil der Datenbits eines Seitendeskriptors wird mit den Zugriffs-Kontrollsignalen des Prozessorkerns
(R/W, C/D) verknüpft. Diese Verknüpfung erzeugt dann entweder die Zugriffskontrollsignale für den phy-
sikalischen Teil des Adreßbusses oder aber das Bus-Error-Signal.

3.4.3. I/O Subsystem


Das I/O Subsystem hat vielfältige Aufgaben. Aus Applikationssicht schafft es eine Schnittstelle für den
einheitlichen Zugriff auf unterschiedlichste Hardware, aus Hardwaresicht stellt es eine Umgebung zur Ver-
fügung, um mit relativ wenig Aufwand Hardware systemkonform in den Kernel zu integrieren. Daneben ist
das I/O Subsystem aber auch noch für die Organisationsstrukturen auf Hintergrundspeicher, den sogenann-
ten Filesystemen, zuständig.

58
Kapitel 3. Realzeitbetriebssysteme

3.4.3.1. Gerätezugriff auf Applikationsebene


Das Betriebssystem stellt auf Applikationsebene ein Systemcallintferface zur Verfügung, um auf Geräte zu-
zugreifen. Dazu gehören im wesentlichen Funktionen um Geräte zu initialisieren, um Daten zu den Geräten
zu transferieren und Daten von den Geräten zu lesen. Die Applikationsschnittstelle zum I/O-Subsystem ist
so gestaltet, dass sie für beinahe jegliche Art von Geräten nutzbar ist.

3.4.3.1.1. Schnittstellenfunktionen
Ähnlich wie in der Hardware werden für die Applikation Zugriffe auf Peripherie auf ein einfaches Lesen
und Schreiben (read und write) abgebildet. Bevor jedoch auf ein Gerät geschrieben bzw. von einem Gerät
gelesen werden kann, muß dazu die Ressource beim Betriebssystem angefordert werden. Bei der Anforde-
rung entscheidet das System, ob die Task den Zugriff bekommt oder ob der Zugriff abgelehnt wird. Gründe
für eine Ablehnung können sein:

• fehlende Zugriffsrechte
• die Ressource ist bereits belegt.

#define ZUMACHEN 0x00


#define AUFMACHEN 0x01

...
char Tuere;

...
fd=open( “Aufzugtuer”, O_RDWR );
Tuere = AUFMACHEN;
write( fd, &Tuere, sizeof(Tuere) ); // Tuere auf
...
close( fd );

Abbildung 3-17. Geräteschnittstelle

Die klassischen Zugriffsfunktionen (ANSI-C) für den Zugriff auf Geräte sind die gleichen wie für den
Zugriff auf Dateien (Geräte werden also an dieser Schnittstelle wie Dateien gehandhabt!):

open

Mit open wird der spätere Zugriffswunsch auf ein Gerät beim Betriebssystem angemeldet. Das Gerät
selbst wird in symbolischer Form spezifiziert. Außerdem muß angegeben werden, in welcher Form
(lesend/schreibend) auf das Gerät zugegriffen werden soll, und in welcher Art (z.B. blockierend oder
nicht blockierend). open liefert als Ergebnis einen sogenannten Descriptor zurück, wenn das Betriebs-
system die Ressource der Task zuteilt. Dieser Descriptor wird von den folgenden Diensten als Ken-
nung verwendet, so dass die produktiven Dienste (read/write) effizient bearbeitet werden können (Bild
Geräteschnittstelle).

close

Dieser Systemcall gibt die angeforderte Ressource wieder frei.

read

Zum lesenden Zugriff wird der Systemcall read verwendet.

59
Kapitel 3. Realzeitbetriebssysteme

write

Mit dieser Funktion können Daten an die Peripherie übermittelt werden.

ioctl

Läßt sich eine bestimmte Funktionalität, die ein Peripheriegerät besitzt, nicht auf Schreib-/Leseaufrufe
abbilden, steht der IO-Control-Aufruf zur Verfügung. Dieser Aufruf ist gerätespezifisch. Über IO-
Controls werden beispielsweise die verschiedenen Betriebsparameter und Betriebsarten einer seriellen
Schnittstelle konfiguriert oder auch ein atomares Lesen und Schreiben ermöglicht.

3.4.3.1.2. Zugriffsarten
Da man bei Echtzeitbetriebssystemen darauf achten muß, dass das Warten auf Ereignisse das System selbst
nicht blockiert, lassen sich Aufrufe, die zum Warten führen können, unterschiedlich parametrieren. Insge-
samt lassen sich drei Aufrufarten unterscheiden:

1. Aufruf mit implizitem Warten (blockierender Aufruf)


2. nicht blockierender Aufruf
3. Aufruf mit explizitem Warten

Normalerweise wird die Task, die auf ein Gerät zugreift, solange “schlafen” gelegt, bis das Gerät geant-
wortet hat, oder eine Fehlersituation (das Gerät antwortet innerhalb einer definierten Zeitspanne nicht) ein-
getreten ist. Man spricht von einem Warteaufruf mit implizitem Warten oder auch von einem synchronen
Zugriff.
Demgegenüber spricht man von einem Warteaufruf mit explizitem Warten, wenn der Warteaufruf (Zugriff
auf das Gerät) direkt zurückkehrt. Die Task, die den Aufruf durchgeführt hat, kann - unabhängig von der
Bearbeitung des Warteaufrufs innerhalb des Betriebssystems - zurückkehren und weiterrechnen. Ist der Zu-
griff auf das Gerät durch das I/O-Subsystem abgeschlossen, wird die Task darüber entweder per Ereignis
(auf das an anderer Stelle entweder explizit gewartet wird, oder welches durch die Task gepollt wird) infor-
miert, oder das Betriebssystem ruft eine vorher übergebene Callback-Funktion auf. Bei Warteaufrufen mit
explizitem Warten spricht man auch von einem asynchronen Zugriff.
Ein Beispiel für eine derartige Funktion mit explizitem Warten ist unter Win32 die Funktion ReadFile mit
sogenannter overlap-structure (Bild Expliziter Warteaufruf mit Win32 Interface).
Aus Sicht des Betriebssystems sind Warteaufrufe mit explizitem Warten nicht trivial zu realisieren. Das liegt
an der Schwierigkeit, dass von der Applikation mehrere explizite Warteaufrufe gestartet werden können.
Das Betriebssystem muß sich darüber die Informationen innerhalb des Betriebssystems aber merken (daher
auch die overlap-structure, die die notwendigen Informationen bezüglich des Aufrufes enthält und deren
Inhalt im Betriebssystem abgelegt ist). Darüberhinaus muß das I/O-Susbsystem darauf eingerichtet sein,
dass zwischen Start des Zugriffs und Ende des Zugriffs die zugehörige Applikation beendet wird.
Einige Betriebssysteme (z.B. Unix) stellen Warteaufrufe mit explizitem Warten nicht direkt (native) zur Ver-
fügung (auch wenn sich diese leicht implementieren lassen). Hier kann man sich aber an der Applikations-
schnittstelle anderer Möglichkeiten bedienen, um die gleiche Funktionalität zu bekommen. Dazu wird der
eigentliche Zugriff auf das Gerät auf einen zweiten Thread verteilt (Bild Asynchroner Zugriff über Threads).
Der zweite Thread schläft im eigentliche Leseaufruf (Funktion read) solange, bis die Daten vorhanden sind.
Der Hauptthread wartet schließlich, bis sich der zweite Thread beendet.

60
Kapitel 3. Realzeitbetriebssysteme

...

char *OverlappedAccess()
{
char buf[100];
DWORD dwBytesRead;
DWORD dwCurBytesRead;
OVERLAPPED ol;

ol.Offset = 10;
ol.OffsetHigh = 0;
ol.hEvent = NULL;

HANDLE hFile = CreateFile("overlap.test", GENERIC_READ,


FILE_SHARE_WRITE, 0, OPEN_EXISTING,
FILE_FLAG_OVERLAPPED, 0);

ReadFile(hFile, buf, 100, &dwBytesRead, &ol);

// perform other tasks in this thread


/ ...

// Synchronise with file I/O


WaitForSingleObject(hFile, INFINITE);

GetOverlappedResult(hFile, &ol, &dwCurBytesRead, TRUE);


CloseHandle(hFile);

return(result_buffer);
}

...

Abbildung 3-18. Expliziter Warteaufruf mit Win32 Interface

#include <stdio.h>
#include <pthread.h>

static char buf[100]; // global or as argument to pthread_create

void *AsyncThread( void *fp )


{
fread( buf, sizeof(buf), 1, (FILE *)fp );
pthread_exit( NULL );
}

main( int argc, char **argv )


{
pthread_t MyThread;
FILE *fp;

fp = fopen( "overlap.test", "r" );


if( fp==NULL ) {
perror( "overlap.test" );
return;
}
if( pthread_create( &MyThread, NULL, AsyncThread, fp )!= 0 ) {
fprintf(stderr,"creation of thread failed\n");
exit( -1 );
}

// perform other tasks


// ...

// Synchronise with file I/O


pthread_join( AsyncThread, NULL );
}

61
Kapitel 3. Realzeitbetriebssysteme

Abbildung 3-19. Asynchroner Zugriff über Threads

Neben diesen beiden prinzipiellen Zugriffsmöglichkeiten gibt es die Variation des nicht blockierenden Zu-
griffs (non blocking mode).
Beim nicht blockierenden Zugriff wartet die aufrufende Task (der Thread) nicht, wenn die angeforder-
ten Daten nicht zur Verfügung stehen. Stattdessen kehrt der Funktionsaufruf (Systemcall) direkt mit einer
entsprechenden Benachrichtigung zurück. Blockierenden oder nicht blockierenden Zugriff kann man bei
Unix-Betriebssystemvarianten entweder beim Öffnen/Initialisieren (Geräte werden über die Funktion open
geöffnet bzw. initialisiert) einstellen, oder nachträglich über die Funktion fcntl.

int fd;

fd = open( "/dev/modem", O_RDWR | O_NONBLOCK );


if( fd < 0 ) {
perror( "/dev/modem" );
return( -1 );
}

Abbildung 3-20. Öffnen eines Gerätes im Non-Blocking Mode

Weitere Möglichkeiten warten zu vermeiden bietet das I/O-Subsystem an der


Applikationsschnittstelle mit dem sogenannten select Aufruf respektive poll Funktion (Bild
Gleichzeitige Überwachung mehrerer Ein-/Ausgabequellen). Ein weiteres wichtiges Merkmal ist, dass
diese Funktionen (Systemcalls) gleich mehrere Ein- bzw. Ausgabequellen (z.B. Geräte, Netzverbindungen
u.ä.) darauf überprüfen, ob von diesen ohne zu warten Daten gelesen werden können oder ob auf diese
ohne warten zu müssen Daten geschrieben werden können.

#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

int main(void)
{
fd_set rfds;
struct timeval tv;
int retval;

/* Watch stdin (fd 0) to see when it has input. */


FD_ZERO(&rfds);
FD_SET(0, &rfds);
/* Wait up to five seconds. */
tv.tv_sec = 5;
tv.tv_usec = 0;

retval = select(1, &rfds, NULL, NULL, &tv);


/* Don’t rely on the value of tv now! */

if (retval)
printf("Data is available now.\n");
/* FD_ISSET(0, &rfds) will be true. */
else
printf("No data within five seconds.\n");

exit(0);
}

Abbildung 3-21. Gleichzeitige Überwachung mehrerer Ein-/Ausgabequellen

Select und auch poll können zeitüberwacht aufgerufen werden. Das bedeutet, dass entweder nur nach-
gesehen werden kann, ob eine Veränderung stattgefunden hat, oder es kann gleichzeitig implizit eine zu

62
Kapitel 3. Realzeitbetriebssysteme

definierende Zeit gewartet werden. Sind innerhalb dieser angegebenen Zeitspanne keine Daten auf den
spezfizierten Ein-/Ausgabequellen angekommen oder lassen sich keine Daten darauf schreiben, bricht die
Funktion mit einer entsprechenden Nachricht ab.
Die Funktionen select und poll werden auch genutzt, um eine Task/Thread (ähnlich der Funktion sleep)
im Millisekundenbereich warten (schlafen) zu lassen. Der Unterschied zwischen select und poll besteht
darin, dass man mittels select nur den Zustand von Ein-/Ausgabequellen überprüfen kann, bei poll jedoch
noch zusätzlich den Zustand von Ereignissen (events).

3.4.3.2. Gerätezugriff innerhalb des Betriebssystemkerns


Um an der Applikationsschnittstelle ein einheitliches Interface anbieten zu können, muß ein Peripheriemo-
dul gemäß bestimmter Konventionen (Schnittstellen) in den Betriebssystemkern eingebunden werden. Dazu
existiert innerhalb des Betriebssystemkerns die Gerätetreiberschnittstelle. Diese Schnittstelle verwendend,
erstellt der Informatiker oder Ingenieur einen sogenannten Gerätetreiber (Device-Driver), der - oftmals dy-
namisch während der Laufzeit - in den Betriebssystemkern integriert wird. Verwendet dann eine Applikation
eine der Zugriffsfunktionen open, close, read, write oder ioctl, wird im Gerätetreiber eine entsprechen-
de Funktion aufgerufen, die das Peripheriemodul so ansteuert, dass dieses die spezifizierte Funktionalität
erbringt.
Ein Gerätetreiber ist also:

• ein Satz von Funktionen, die den Zugriff auf eine spezifische Hardware (Gerät) steuern.
• die gerätespezifische Implementierung der allgemeinen Schnittstellenfunktionen.

Die Aufgabe des Betriebssystems (I/O Subsystem) im Kontext der Gerätetreiber ist:

• eine eindeutige Schnittstelle zur Verfügung zu stellen,


• die Verwaltung der Ressourcen,
• Mechanismen für die Realisierung von Zugriffsarten und Zugriffsschutz bereit zu stellen,
• die Zuordnung der allgemeinen Schnittstellenfunktionen (Systemcalls) zu den gerätespezifischen Funk-
tionen durchzuführen.
• Der Treiber registriert sich beim I/O-Subsystem mit seinen Funktionen und der Majornumber.
• Über die Zuordnung symbolischer Name und Majornumber oder Filedeskriptor wird das Mapping
zwischen I/O-Systemcall und Treiberfunktion durchgeführt.
• Das Betriebssystem ruft die mit der Majornumber korrespondierende Treiberfunktion auf.

Auch heute findet man noch sehr häufig Ingenieure, die Peripheriemodule nicht über einen Treiber, sondern
direkt aus der Applikation heraus ansteuern. Jedoch ist ein Treiber notwendig:

• Um benötigte Ressourcen vom Betriebssystem zugeteilt zu bekommen. Schließlich ist das Betriebssy-
stem für die Verwaltung der Ressourcen zuständig. Wird ein Gerät nicht systemkonform eingebunden,
kann das Betriebssystem die zugesicherten Eigenschaften nicht mehr garantieren. Es hat beispielsweise
keinerlei Kontrolle darüber, ob eine Ressource (ein Interrupt, ein I/O-Bereich oder ein sonstiger Speicher-
bereich) bereits vergeben ist oder nicht. Das Sperren von Interrupts in ungeeigneten Systemzuständen
kann außerdem zu erhöhten Latenz-Zeiten (siehe Abschnitt Task-Latency) führen.

63
Kapitel 3. Realzeitbetriebssysteme

• Um systemkritische Teile zu kapseln. Zugriffe auf Hardware sind sicherheitskritische Aktionen, die nur
innerhalb eines Treibers durchgeführt werden dürfen. Wird aber beispielsweise die Hardware aus der Ap-
plikation heraus angesteuert (indem die Register bzw. Speicherbereiche der Hardware in den Adreßraum
der Applikation gemapped werden), muß die Applikation erweiterte Zugriffsrechte bekommen. Damit
wiederum gefährdet sie die Sicherheit des gesamten Systems. Programmierfehler können nicht nur zum
Absturz der Task, sondern sogar zum Absturz des gesamten Systems führen.
• Um bei Applikationsfehlern das Gerät in den sicheren Zustand überführen zu können. Durch die ein-
deutige Trennung zwischen Applikation und Gerätetreiber ist es für das Betriebssystem möglich, bei
Applikationsfehlern das Gerät in den sicheren Zustand zu überführen. Stürzt die Applikation durch einen
Fehler ab, erkennt dies das Betriebssystem. Da es außerdem weiß, dass diese (bzw. welche) Applika-
tion auf das Gerät zugegriffen hat, kann es die im Gerätetreiber befindliche Funktionalität aktivieren,
einen sicheren Gerätezustand herzustellen. Insbesondere dieser dritte Grund ist für sicherheitskritische
Echtzeitsysteme wesentlich!

Die meisten Betriebssysteme haben das durch Unix eingeführte Konzept übernommen, Geräte auf Applika-
tionsebene auf Dateien abzubilden und mit den bereits vorgestellten Systemcalls (open, close, read, write,
ioctl, select und poll) anzusprechen.

Diese Aufrufe werden innerhalb des Betriebssystems an den Gerätetreiber weitergereicht. Verwendet also
eine Applikation den open-Aufruf, um eine Ressource (in diesem Falle also ein Gerät) zu reservieren, stellt
das Betriebssystem fest, um welches Gerät es sich handelt und ruft dann die zugehörige open-Funktion
innerhalb des Treibers auf (Bild Treiberauswahl). Jeder Treiber muß also eine treiberspezifische open-
Funktion zur Verfügung stellen. Es gibt damit im Betriebssystem so viele open-Funktionen wie es Treiber
gibt, während an der Applikationsschnittstelle genau eine open-Funktion existiert.
Damit die richtige Treiberfunktion ausgewählt werden kann, benötigt das Betriebssystem natürlich einen
Anhaltspunkt. Dieser Anhaltspunkt ist beim Systemcall (also an der Applikationsschnittstelle) open ein
symbolischer Name, über den die Zuordnung durchgeführt wird, bei den anderen Funktionen ein Deskriptor,
den das Betriebssystem der Applikation als Ergebnis des open-Systemcalls zurückgibt.

Open−
Systemcall

Applikation
Kernel Open−Funktion des
Gerätetreibers wird aufgrund
der Systemcallparameter ausgewählt

serielle parallele Analog Open−Funktionen


Schnittstelle Schnittstelle Festplatte CD−ROM Input der Gerätetreiber

Hardware

Abbildung 3-22. Treiberauswahl

64
Kapitel 3. Realzeitbetriebssysteme

Die Zuordnung eines symbolischen Gerätenamens zum zugehörigen Gerätetreiber wird in Unix beispiels-
weise über die sogenannten Majornumber durchgeführt. Im Dateisystem wird eine Datei erzeugt, die einen
symbolischen Namen wie zum Beispiel mydevice besitzt. Diese Datei bekommt als Attribute eine Major-
number, zum Beispiel 122 zugeteilt (der Aufruf dazu lautet mknod mydevice c 122 0). Diese Majornumber
ist im Regelfall eindeutig festgelegt und im Treiber eincodiert. Wird der Treiber schließlich vom Betriebs-
system geladen (unter Linux dynamisch mit dem insmod Kommando), meldet sich dieser beim Betriebs-
systemkern mit der eincompilierten Majornumber an. Bei diesem Vorgang wird außerdem eine Liste der
Treiberfunktionen mit übergeben, die aufgerufen werden sollen, wenn die Applikation die entsprechenden
Zugriffsfunktionen (open, close, read, write, ioctl, select oder poll) aufruft. Damit sind im System alle
notwendigen Informationen vorhanden, um bei Zugriffen durch die Applikation die entsprechenden Trei-
berfunktionen zu starten.
Bild Einbindung des Gerätetreibers in das System zeigt dieses noch einmal anhand eines
Linux-Gerätetreibers. Wird der Treiber per insmod geladen, so wird beim Laden die Funktion init_module
aufgerufen. Diese Funktion registriert den Treiber, wobei die Majornumber und die Tabelle mit
den Treiberfunktionen dem Kernel übergeben werden (register_chrdev(MY_MAJOR_NUMBER, ...,
&mydevice_table);, wobei MY_MAJOR_NUMBER zum Beispiel 122 sein kann).

Ist der Treiber geladen, kann die Applikation diesen nutzen. Dazu muß im Filesystem eine Spezialdatei
existieren, die die Zuordnung des symbolischen Gerätenamens zur Majornumber MY_MAJOR_NUMBER (also
z.B. 122) durchführt. Führt die Applikation dann den Systemcall open mit dem Gerätetreibernamen als
Parameter durch, ruft der Kernel die gerätetreiberspezifische Funktion mydevice_open auf. Das gleiche gilt
für die übrigen Schnittstellenfunktionen wie read oder write.

65
Kapitel 3. Realzeitbetriebssysteme

Kernelmodul: carrera.c
mknod /dev/carrera 240 0
struct file_operations carrera_table {
&carrera_open; insmod carrera.o
&carrera_close;
&carrera_write; Applikation:
&carrera_read;
main()
&carrera_ioctl;
... {
}; int fd=open("/dev/Carrera", O_RDWR);

int init_module() char buf[512];


{
register_chrdev(240, ..., write( fd, "0x50", 5 );
&carrera_table); close( fd );
... }
}
void cleanup_module()
{
unregister_chrdev(...); /dev/Carrera
...
}
rmmod carrera

int carrera_open(...)
{
...
}

int carrera_close(...)
{
....
}

int carrera_write(...)
{
...
// copy data from I/O to user space
...
speed = atoi( buf );
parport_epp_write_data( port,speed);
...
}
...

KERNEL USER

Abbildung 3-23. Einbindung des Gerätetreibers in das System

Bei der Treibererstellung sind damit im wesentlichen diese internen Funktionen zu kodieren:

init_device/init_module

Die Funktion, die beim Laden des Treibers aufgerufen wird, hat die folgenden Aufgaben:
• Anmelden des Treibers beim Betriebssystem.
• Eventuell automatisches Suchen und Erkennen der Hardware und des Hardwaretyps (z.B. serielle
Schnittstelle und diese in der Ausprägung mit 16550 Chip).
• Initialisierung der Hardware.
• Anforderung von System-Ressourcen (Interrupt, I/O-Bereich, Speicherbereich).

exit_treiber/cleanup_module

Diese Funktion führt folgende Aktivitäten durch:


• Freigabe der vom Treiber reservierten Systemressourcen.
• Abmelden des Treibers beim Betriebssystem.

66
Kapitel 3. Realzeitbetriebssysteme

open (treiberspezifisch)
Diese Funktion hat die folgenden Aufgaben:
• Überprüfen der Schreib-/Leserechte auf das Gerät.
• Überprüfen, ob der Zugriff zu einem Zeitpunkt für eine oder für mehrere Applikationen erlaubt ist
und ob bereits eine Applikation die Ressource nutzt.
• Zuteilung von Hardware-Ressourcen (z.B. einem Prozess wird einer von vier DMA-Kanälen zuge-
teilt).

close (treiberspezifisch)
Die Funktion close hat die Aufgaben:
• Freigabe der (durch open) belegten Ressourcen.
• Überführen des Gerätes (der Hardware) in einen definierten und sicheren Zustand (deinitialisieren).
Hat eine Applikation das Device (Gerät) geöffnet, bricht dann aber ab, ohne das Gerät wieder zu
schließen (z.B. weil die Applikation abgestürzt ist), ruft das Betriebssystem anstelle der Applikation
die close-Funktion auf und gewährleistet damit einen sicheren Betrieb.

read (treiberspezifisch)
Aufgabe von read ist:
• Realisierung der Zugriffsarten (blockierend, nicht blockierend, siehe Abschnitt Zugriffsarten)
• Anpassung des Taskzustandes (Versetzen der Task im blocking-Mode in den Zustand “wartend”
bzw. in den Zustand “lauffähig”).
• Kopieren der Daten aus dem Kernelspace in den Userspace (Speicherbereich der aufrufenden Ap-
plikation). Das Kopieren der Daten wird über Systemfunktionen durchgeführt, da aus Sicherheits-
gründen ein direkter Zugriff auf die Speicherbereiche nicht möglich ist.

write (treiberspezifisch)
Für diese Funktion gilt das gleiche wie bei der read-Funktion:
• Realisierung der Zugriffsarten (blockierend, nicht blockierend, siehe Abschnitt Zugriffsarten)
• Anpassung des Taskzustandes (Versetzen der Task im blocking-Mode in den Zustand “wartend”
bzw. in den Zustand “lauffähig”).
• Kopieren der Daten aus dem Userspace in den Kernelspace.

ioctl (treiberspezifisch)
Mittels ioctl (I/O-Control) werden die folgenden Aufgaben durchgeführt:
• Realisierung gerätespezifischer Funktionalität, die sich nicht sinnvoll auf das read/write Interface
abbilden lassen.
• Einstellung von Treiberparametern (z.B. Baudrate bei einer seriellen Schnittstelle).

IO-Controlls sollten so sparsam wie möglich verwendet werden! Diese Funktion stellt ein über Platt-
formen hinweg nur sehr schwer zu portierende Eigenschaft des Treibers dar. Die ioctl-Funktion be-
kommt als Parameter ein Kommando und einen Zeiger auf eine Datenstruktur mit. Entsprechend dem
Kommando beinhaltet die Datenstruktur Datenbereiche im Userspace, aus denen Daten abgeholt (ko-
piert) werden können bzw. in die Daten geschrieben (kopiert) werden können.

67
Kapitel 3. Realzeitbetriebssysteme

select

Die treiberspezifische select-Funktion hat nur die Aufgabe zu überprüfen:


• ob Daten, ohne warten zu müssen (also direkt), vom Gerät gelesen werden können,
• ob Daten, ohne warten zu müssen (also direkt), auf das Gerät geschrieben werden können.

Die an der Applikationsschnittstelle übrigen Funktionalitäten (insbesondere die Überwachung mehre-


rer Ein-/Ausgabekanäle und die Zeitüberwachung) sind innerhalb des I/O-Subsystems realisiert.

poll

Die Funktion poll wird im Treiber wie die Funktion select behandelt. Auch hier wird die eigentliche
Funktionalität innerhalb des Kernels realisiert.

3.4.3.2.1. Vorgehen bei der Treibererstellung


Über eine parallele Schnittstelle sollen Zustände eines technischen Prozesses eingelesen werden. Die par-
allele Schnittstelle wird über Ein-/Ausgabebefehle angesprochen (in C über die Funktionen outb( char
value, char base ) für die Ausgabe eines Bytes und inb( char base ) für das Einlesen eines Bytes). Die
Schnittstelle hat die Basisadresse 0x378 und hat einen Adreßraum von 4 Bytes. Der lesende Zugriff erfolgt
über die Adresse 0x379.
Um den aktuell an der Schnittstelle anliegenden Wert an den Benutzer auszugeben, würde man folgende
Zeilen Code verwenden können:
...
printf( “Pegel der Eingangsleitungen: 0x%x\n”, inb(0x379) );
...

Da verhindert werden soll, dass zwei oder mehr Programme auf die Schnittstelle zugreifen, soll ein Geräte-
treiber entwickelt werden.
Der Gerätetreiber soll zunächst nur den lesenden Zugriff auf die Schnittstelle ermöglichen.
Hier die Vorgehensweise:

1. Festlegen des Treibernamens und der Majornumber zur Identifikation des Treibers:
hier z.B. ParIF mit der Majornumber 121.

2. Welche Ressourcen werden vom Betriebssystem benötigt (Interrupts, IO-Ports, spezifische Speicher-
bereiche)?
Interrupts: keine
IO-Ports: von 0x378 bis 0x37b
Speicherbereiche: keine

3. Schreiben der Funktionen init_module und cleanup_module, die beim Laden bzw. Entladen des Treibers
aufgerufen werden. Die Funktionen haben die Aufgabe, den Treiber beim Betriebssystem anzumelden
und notwendige Ressourcen anzufordern.

68
Kapitel 3. Realzeitbetriebssysteme

// bei Erfolgreicher Initialisierung wird 0 zurückgegeben, sonst


// -EIO.
int init_module()
{
// anmelden des Treibers
result=register_chrdev( 121, “parallel interface”,
&FunktionsTabelle );
if( result == 0 ) {
// Die Anmeldung war erfolgreich, jetzt holen wir uns die
// Ressourcen
// Mit request_irq kann man Interrupts anfordern,
// mit request_region IO-Ports und
// mit request_memory spezifische Memory-Bereiche.
request_region( 0x378, 4, "parallel interface" );
return( 0 );
} else {
return( -EIO );
}
}

void cleanup_module()
{
// Zurückgabe der Ressourcen
release_region( 0x378, 4 );
// Abmelden des Treibers
unregister_chrdev( 121, “parallel interface” );
}

4. Welche Aufgaben kommt der Open Funktion zu?


• Überprüfung der Schreib/Leserechte.
• Zugriffsüberwachung

Hier: Nur Zugriffsüberwachung: Das Gerät darf nur 1x geöffnet werden.

5. Schreiben Sie die open und die close Funktionen:


static int DeviceIsOpen;

int ParIF_open( struct inode *inode, struct file *file )


{
if( DeviceIsOpen ) {
return( -EBUSY );
} else {
DeviceIsOpen = 1;
return( 0 );
}
}

int ParIF_close( struct inode *inode, struct file *file )


{
DeviceIsOpen = 0;
return( 0 );
}

6. Schreiben Sie die eigentlichen Zugriffsfunktionen:


Hier nur read:
ssize_t ParIF_read( struct inode *inode, struct file *file,
const char *buf, int count )
{
char InterfaceValue;

InterfaceValue = inb( 0x379 );


// Wir lesen immer genau 1 Byte, auch wenn die Applikation

69
Kapitel 3. Realzeitbetriebssysteme

// mehr anfordert.
copy_to_user( buf, &InterfaceValue, 1 );
return( 1 );
}

7. Stellen Sie die Funktionstabelle zusammen:


// Die Reihenfolge der Eintraege ist fest vorgegeben!
struct file_operations FunktionsTabelle = {
NULL, /* seek */
&ParIF_read, /* read */
NULL, /* write */
NULL, /* readdir */
NULL, /* poll */
NULL, /* ioctl */
NULL, /* mmap */
&ParIF_open, /* open */
NULL, /* flush */
&ParIF_close, /* release */
NULL, /* fsync */
NULL, /* fasync */
NULL, /* check_media_change */
//NULL, /* revalidate */
//NULL, /* lock */
};

8. Compilierung
Damit ist der eigentliche Treiber fertig. Der Treiber wird compiliert und kann dann ins System integriert
werden (z.B. unter Linux einfach mit dem Superuserkommando insmod geladen werden). Damit auf den
Treiber zugegriffen werden kann, muß noch ein Treiberfile angelegt werden: mknod /dev/ParIF c 121
0

9. Testprogramm erstellen
// Das Programm öffnet das Geraet und liest im Sekundenabstand
// (sleep) Werte von der parallelen Schnittstelle ein und
// gibt diese auf den Bildschirm aus.
// Danach wird versucht das Geraet ein zweitesmal zu oeffnen.
// Der zweite Versuch muss fehlschlagen!

int main( int argc, char **argv )


{
int fd, fd1, i;
char value;

fd = open( “/dev/ParIF”, O_RDONLY );


if( fd<0 ) {
perror( “/dev/ParIF” );
return( -1 );
}

for( i=0; i<10; i++ ) {


read( fd, &value, 1 );
printf( “%d: value=0x%x\n”, i, value );
sleep( 1 );
}

// Test der Open-Funktionalitaet im Treiber:


// Das Geraet darf _kein_ zweitesmal geoeffnet werden koennen!
// Erwartetes Ergebnis: fd1 < 0
fd1 = open( “/dev/ParIF”, O_RDONLY );
if( fd1 > 0 ) {

70
Kapitel 3. Realzeitbetriebssysteme

printf(“FEHLER: /dev/ParIF konnte”


“mehrfach geoeffnet werden!\n”);
close( fd1 );
}

close( fd );
return( 0 );
}

Die bisher dargestellten Funktion (DriverOpen, DriverClose DriverRead DriverWrite ...) werden aufgeru-
fen, wenn in der Applikation die korrespondierende Funktion aufgerufen wird. Daneben gibt es aber noch
Funktionen im Treiber, die durch den Betriebssystemkern selbst getriggert (aufgerufen) werden. Das sind
insbesondere

• Interrupt Service Routinen (ISRs)


• Funktionen in einer Kernel-Queue und
• Funktionen in einer Timer-Queue.

71
Kapitel 3. Realzeitbetriebssysteme

3.4.3.2.2. Interruptbetrieb

Application fread

ruft auf 1 11 returniert


USER

Library read

löst 2 10 Scheduler:
SW−IR aus höchste Priorität
I/O I/O
Subsystem read

ruft 9
3 returniert IR gesperrt
Treiber auf
KERNEL

Geraet_ 8 7
Device Driver read IST
weckt ISR

startet
4 6
HW−Zugriff
ISR
legt Appl. system
schlafen ISR

Hardware wenn
Daten vorhanden

Abbildung 3-24. Datenfluß im System beim Aufruf von fread

Der Betriebssystemkern bietet bereits eine komfortable Umgebung an, um Hardware interruptgesteuert zu
betreiben. Dazu muß der Treiber eine Interruptroutine zur Verfügung stellen und beim Laden des Trei-
bers beim Kern anmelden (registrieren). Versetzt beispielsweise die Treiberfunktion read eine Task in den
Zustand wartend, so kann diese Task (bzw. der Treiberaufruf read, denn die Task „wartet in der Treiber-
funktion“) durch die ISR wieder in den Zustand lauffähig versetzt werden.
Die Programmierung einer Interrupt Service Routine innerhalb des Betriebssystems verlangt viel Sorgfalt.
Während der Abarbeitung der ISR sind sämtliche Interrupts gesperrt. Damit bedeutet eine lange Ausfüh-
rungsdauer der ISR eine hohe Latenzzeit des Betriebssystems durch den Treiber. Es ist daher darauf zu
achten, ISR’s möglichst kurz zu halten. Die von den meisten Betriebssystemen dazu zur Verfügung gestell-
te Technologie beruht auf Interrupt-Service-Threads (IST). Unter einem Interrupt-Service-Thread wird hier
eine Funktion verstanden, die direkt nach Abarbeitung des bzw. der Interrupts aufgerufen wird, noch bevor
sonst eine Funktion des Treibers abgearbeitet wird. Sind die Interrupts während einer Interrupt-Service-
Routine gesperrt, sind diese zum Zeitpunkt der Bearbeitung der IST’s freigegeben. Damit besteht der Code
der ISR nur noch darin, eine Funktion (IST, unter Linux als Bottom Halve bezeichnet) in die Liste (Queue)
der Funktionen einzutragen, die direkt nach Beendigung aller anliegenden Interrupts aufgerufen werden.

72
Kapitel 3. Realzeitbetriebssysteme

Bild Datenfluß im System beim Aufruf von fread zeigt den gesamten Datenfluß eines Leseauftrags. Die Ap-
plikation möchte über die Funktion fread Daten von einem Gerät lesen (1). Bei der Funktion fread handelt
es sich zunächst um eine Library-Funktion (Buffered-I/O), die vom Systemhersteller zur Verfügung ge-
stellt wird. fread muß jedoch in jedem Fall, wenn wirklich ein Zugriff auf die Hardware notwendig ist, den
Systemcall read verwenden (2). Der Systemcall löst einen Interrupt aus, wodurch die Bearbeitung inner-
halb des Kernels beginnen kann. Im Kernel wird anhand des übergebenen Filedeskriptors (erster Parameter
der Funktion read) die zugehörige Treiberfunktion Geraet_read aufgerufen (3). Diese Funktion startet den
eigentlichen Hardwarezugriff (4) und versetzt dann die aufrufende Task in den Zustand „wartend“.
Hat die Hardware den Auftrag abgearbeitet, löst sie einen Interrupt aus (5). Interrupts werden zunächst
vom Kernel selbst bedient. Die system ISR startet jedoch die Geräte-ISR ISR (6). Während die ISR (sowohl
die des Kernels als auch die des Gerätetreibers) aktiv sind, sind alle Interrupts gesperrt. Die Geräte-ISR
macht im Beispiel nichts anderes, als einen vom Treiber zur Verfügung gestellten Interrupt-Service-Thread
IST zu starten (7). Dieser IST wiederum weckt die Applikation (versetzt die Applikation wieder in den
Zustand “lauffähig”) (8). Die Gerätetreiberfunktion Geraet_read liest die Daten vom Gerät (Hardware) und
kopiert sie in den von der Applikation übergebenen Speicherbereich (im User-Space). Danach übergibt sie
die Kontrolle wieder an die Funktion I/O read (9). Der Systemcall ist damit abgearbeitet, und sollte die
Applikation höchste Priorität haben, wird der Scheduler die CPU wieder an diese Task übergeben. Die über
den Systemcall read gelesenen Daten werden noch in der Library-Funktion fread verarbeitet und schließlich
der Applikation selbst übergeben.

3.4.3.2.3. Kernel-Queues
Als Kernel-Queue-Funktionen bezeichnet man Routinen, die in bestimmten „Zuständen“ des Kernels aufge-
rufen werden. Derartige Funktionslisten (Queues) werden von allen modernen Betriebssystemen offeriert.
Ein Treiber kann eine Funktion beim Kernel für die Abarbeitung zum entsprechenden Zustand registrieren
lassen (einhängen). Folgende Arten von Queues existieren beispielsweise im Linux-Kernel:

• Die eingehängte Funktion wird direkt nach Abarbeitung aller anliegenden Interrupts abgearbeitet (IST).
• Die eingehängte Funktion wird abgearbeitet, bevor der Scheduler aufgerufen wird.
• Die eingehängte Funktion wird jedesmal dann aufgerufen, wenn der Zeitgeber einen Interrupt auslöst
(also mit jedem Timer-Tick).

Mittels dieser Schnittstelle lassen sich also beispielsweise auch periodische Vorgänge innerhalb des Treibers
(um beispielsweise ein Peripheriemodul im Pollingmode zu betreiben) realisieren. Dazu hängt der Treiber
- meistens bei der Initialisierung (Funktion open) - eine entsprechende Funktion in die vom System zur
Verfügung gestellte Timerqueue ein.

3.4.3.2.4. Timer-Queues
Bei einer Timer-Queue handelt es sich um eine Funktionsliste im Betriebssystemkern, in die ein Treiber die
Adresse einer Funktion und den Zeitpunkt eintragen kann, zu dem die Funktion durch den Kernel aufgerufen
werden soll.

3.4.3.2.5. Code-Beispiel

#include <linux/module.h> /* generic module infos */


#include <linux/pci.h> /* pci-bios functions */
#include <linux/fs.h> /* definitions for ioctl*/

73
Kapitel 3. Realzeitbetriebssysteme

#include <linux/delay.h> /* udelay() */


#include <asm/io.h> /* inb(), outb() etc. */

#define MYDEVICE_MAJOR 122

#define MYDEVICE_OUTPUT 1
#define MYDEVICE_INPUT 2

static int mydevice_open(struct inode *inode, struct file *file)


{
unsigned int minor = MINOR(inode->i_rdev);

// your code comes here


MOD_INC_USE_COUNT;
return 0;
}

static int mydevice_release(struct inode *inode, struct file *file)


{
unsigned int minor = MINOR(inode->i_rdev);

// your code comes here


MOD_DEC_USE_COUNT;
return 0;
}

static ssize_t mydevice_read( struct inode *Inode, struct file *file,


char *buf, int count)
{
// read data from hardware and copy it into user space
return( 0 );
}

static ssize_t mydevice_write(struct inode *Inode, struct file *file,


const char *buf, int count)
{
// copy data from user space and write it into the hardware
return( 0 );
}

static int mydevice_ioctl(struct inode *inode, struct file *file,


unsigned int cmd, unsigned long arg)
{
unsigned int minor = MINOR(inode->i_rdev);

/* process ioctl-command */
switch(cmd) {
case MYDEVICE_OUTPUT:
// your code comes here
return 0;

case MYDEVICE_INPUT:
// your code comes here
return 0;
};

/* invalid ioctl-command */
return -EIO;
}

static struct file_operations mydevice_fops = {


NULL, /* seek */
mydevice_read, /* read */
mydevice_write, /* write */
NULL, /* readdir */
NULL, /* poll */
&mydevice_ioctl, /* ioctl */
NULL, /* mmap */

74
Kapitel 3. Realzeitbetriebssysteme

&mydevice_open, /* open */
NULL, /* flush */
&mydevice_release,/* release */
NULL, /* fsync */
NULL, /* fasync */
NULL, /* check_media_change */
//NULL, /* revalidate */
//NULL, /* lock */
};

void cleanup_module(void);

/* initialisize module, called at ’insmod’ */


int init_module(void)
{
/* try to register major number for device access */
if(register_chrdev(MYDEVICE_MAJOR, "sample driver",
&mydevice_fops) == 0) {

/* inform user */
printk("sample driver registered\n" );
return 0;
};

printk("mydevice: unable to get major %d\n",MYDEVICE_MAJOR);


return -EIO;
}

/* deinitialisize module, called at ’rmmod’ */


void cleanup_module(void)
{
int index;

/* unregister character device from defined major number */


unregister_chrdev(MYDEVICE_MAJOR,"sample driver");
}

Abbildung 3-25. Gerüst eines Gerätetreibers

3.4.3.3. Task-Latency

Ereignis tritt ein


Task Latency, tw
IR ausgelöst 




   
      
 


Hardware ISR ISR2  

Latency
   
       

Preemption (IR Latency) Context Switch


Latency
(IR disabled) System Call Delay
Scheduler

Abbildung 3-26. Verzögerungszeiten

75
Kapitel 3. Realzeitbetriebssysteme

Kritisch für ein Betriebssystem sind die Warte- bzw. Verzögerungszeiten, also die Zeit, die zwischen dem
Auftreten des Ereignisses und dem Start der zugehörigen Task vergeht (Task-Latency). Dabei müssen eine
Reihe von Zeiten berücksichtigt werden [TimMon97]:

1. Hardware-Latency: Zeit, die die Hardware benötigt, um das Ereignis in Form eines Interrupts dem
Prozessor zu melden (einige wenige Gatterlaufzeiten).
2. Preemption-Delay: Verzögerungszeit, die entsteht, wenn sich das Betriebssystem in einem kritischen
Abschnitt befindet, der nicht unterbrochen werden darf (Interrupts sind gesperrt).
3. Verarbeitungszeit der ISR: Verarbeitungszeit innerhalb der Interrupt-Service-Routine.
4. Interrupt Latency: Verzögerungszeit, die entsteht, wenn das Betriebssystem andere Interrupts bearbei-
ten muß.
5. System Call: Tritt der Interrupt gerade zu einem Zeitpunkt auf, an dem ein Systemcall bearbeitet wurde,
muß zunächst dieser Systemcall zuende bearbeitet (oder abgebrochen) werden.
6. Scheduling: Zeit, die vergeht, um den nächsten lauffähigen Prozess auszuwählen (der Scheduler wird
im Regelfall mit jedem Interrupt aufgerufen).
7. Context-Switch: Zeit, die benötigt wird, um die (neue) Task starten zu können (also die Zeit, um die
Register der CPU mit den Daten der zu bearbeitenden Task zu laden).
8. Hat die Task, für die das Ereignis gilt, nicht höchste Priorität, werden erst die höher prioren Tasks
bearbeitet.

Die Zeiten treten weder in der angegebenen Reihenfolge auf, noch müssen sie grundsätzlich alle berück-
sichtigt werden. Hinzu kommt, dass die Zeiten auch mehrfach auftreten, wenn beispielsweise mehr als zwei
unterschiedliche Interrupts auftreten.
Die Hardwarelatenzzeit muß in jedem Fall berücksichtigt werden, fällt aber bei ihrer Größenordnung (ns)
im Vergleich zu den anderen Zeiten kaum ins Gewicht. Diese Zeit fällt maximal einmal an.
Da Interrupts die höchste Priorität haben, fallen - abgesehen von dem Fall, dass Interrupts gesperrt sind -
die Interrupt-Latenzzeiten an. Interrupt-Latenzzeiten treten für jeden Interrupt genau einmal auf, bei unter-
schiedlicher Priorisierung der Interrupts möglicherweise auch mehrfach. Die Zeiten, die durch Abarbeitung
von Interrupt Service Threads anfallen, werden hier als den Interrupts zugehörig betrachtet.
Nach den Interrupts bearbeitet der Prozessor zunächst einen aktiven Systemcall zuende. Danach folgt der
Scheduler und schließlich der Kontextswitch. Diese Zeiten fallen durchaus mehrfach an, insbesondere dann,
wenn es noch höherpriore Tasks im System gibt.
Diese Verzögerungszeiten kennzeichnen die Realzeiteigenschaften eines Betriebssystems. Echtzeitbetriebs-
systeme weisen auf PC-Plattformen (Pentium) beispielsweise Wartezeiten in der Größenordnung von 100
bis 300 µs auf.
Bei der Wahl eines Echtzeitbetriebssystems werden häufig die Interrupt-Latenzzeiten verglichen. Die
Interrupt-Latenzzeit wird aber im wesentlichen durch die ISR’s der Treiber bestimmt. Der Hersteller eines
Betriebssystem kennt aber nur die Treiber, die integrativer Bestandteil sind. Beim Vergleich ist daher auf
die eigentliche Systemkonfiguration zu achten. Sperrt ein einzelner
Untersuchungen haben gezeigt, dass Latenzzeiten nicht unbedingt konstant sein müssen. Vielmehr gibt es
auch den Fall, dass die Zeiten von der sogenannten Uptime des Systems abhängen (z.B. dadurch, dass intern
Listen verarbeitet werden, die it längerer Laufzeit des Systems ebenfalls länger werden) [Mächtel].

Merke: Um Verzögerungszeiten (Latency-Times) so gering wie möglich zu halten, ist es beim System-
design wichtig, Interrupts nicht länger als notwendig zu sperren und critical sections kurz zu halten.

76
Kapitel 3. Realzeitbetriebssysteme

3.4.3.4. Filesystem
Filesysteme dienen zum Abspeichern bzw. Sichern von:

• Programmen (Betriebssystemkern, Dienstprogrammen und Applikationen)


• Konfigurationsinformationen
• Daten (z.B. HTML-Seiten)
auf sogenanntem Hintergrundspeicher.
Werden in der Desktop- und Serverwelt klassischerweise Festplatten als Hintergrundspeicher verwendet,
benutzt man im Bereich eingebetteter Systeme EEPROMs oder Flashspeicher.
Damit auf einen Hintergrundspeicher mehrere Dateien/Daten abgelegt werden können, ist eine Organisati-
onsstruktur (Filesystem, z.B. FAT, VFAT, NTFS, Linux Ext2 Filesystem) notwendig. Diese Organisations-
struktur sollte:

• einen schnellen Zugriff ermöglichen und


• wenig Overhead (bezüglich Speicherplatz) für die Verwaltungsinformation benötigen.

...
read( fd, buf, 128 )
...

Applikation
Hintergrundspeicher
Buffercache

Abbildung 3-27. Lesen über den Buffercache

Um schnellen Zugriff zu ermöglichen, arbeiten einige Systeme mit einem dazwischengeschalteten Cache,
dem sogenannten Buffercache (in der Windows-Welt auch unter dem Produktnamen “Smartdrive” bekannt).
Möchte eine Applikation eine Datei, die auf dem Filesystem abgelegt ist, lesen, schaut der Betriebssystem-
kern im Buffercache nach, ob die gewünschte Information dort vorhanden ist oder nicht. Ist dies nicht der
Fall, wird die Information in den Cache geladen und dann weiter an die Applikation gereicht. Wird ein
Schreibauftrag erteilt, gehen die Daten zunächst an den Buffercache. Erst einige Zeit später werden die
Daten auf dem Hintergrundspeicher mit den Daten aus dem Cache abgeglichen.
Dieses Verfahren ist oftmals nicht tolerabel:

• Das Filesystem kann dann Inkonsistenzen enthalten, wenn das System abstürzt, der Hintergrundspeicher
aber nicht mit dem Cache rechtzeitig abgeglichen worden ist.

77
Kapitel 3. Realzeitbetriebssysteme

• Zugriffe auf das Filesystem sind nicht deterministisch, da nicht vorhergesagt werden kann, ob angefor-
derte Daten im Cache gefunden werden oder zu einem Leseauftrag an den Hintergrundspeicher führen.
Um dennoch das Verfahren im Umfeld von Echtzeitsystemen einsetzen zu können, wird der sync-Mode
verwendet. Beim sync-Mode werden Dateien direkt (also unter Umgehung des Buffercaches) geschrieben,
ein Lesezugriff kann aber über den deutlich schnelleren Buffercache stattfinden.

3.4.4. Systemcall-Interface
Über die Systemcall-Schnittstelle lassen sich aus der Applikation heraus die Dienste des Betriebssystems
nutzen. Diese Schnittstelle ist absolut unabhängig von jeglicher Programmiersprache. In den seltensten
Fällen greift eine Applikation direkt auf das Systemcall-Interface zu, sondern nutzt zu diesem Zwecke
Bibliotheksfunktionen. So lautet beispielsweise der Systemcall für die Ausgabe von Daten in eine Datei
oder in ein Gerät write, wobei sich hinter dem Namen eine Nummer (bei Linux beispielsweise der Code 4)
verbirgt.
Systemcalls erwarten ihre Argumente entweder in Registern oder auf dem Stack. Ein Systemcall wird dann
über den Assemblerbefehl INT bzw. TRAP mit einer Exceptionnummer (bei Linux beispielsweise 0x80) auf-
gerufen (Softwareinterrupt). Dieser Befehl führt zu einer Exception, wobei die Exceptionnummer innerhalb
des Betriebssystems die Dienstaufrufsschnittstelle aktiviert. Hier wird anhand der Registerinhalte (System-
callcode) in die entsprechenden Funktionen verzweigt.
Bild Codebeispiel Systemcall macht dieses deutlich. Der Code für den Systemcall (hier 4) wird in das Regi-
ster eax geschrieben. Die Register ebx, ecx und edx werden mit den Parametern des Funktionsaufrufes belegt
(in diesem Fall der Dateideskriptor 1 für stdout, die Adresse der auszugebenden Daten "Hello World"
und die Länge 12 des auszugebenden Strings). Danach wird der Softwareinterrupt für die Systemcall-
Schnittstelle (0x80) aufgerufen.

.text
.globl write_hello_world
write_hello_world:
movl $4,%eax ; //code fuer "write" systemcall
movl $1,%ebx ; //file descriptor fd (1=stdout)
movl $message,%ecx ; //Adresse des Textes (buffer)
movl $12,%edx ; //Laenge des auszugebenden Textes
int $0x80 ; //SW-Interrupt, Auftrag an das BS
ret
.data
message:
.ascii "Hallo World\n"

Abbildung 3-28. Codebeispiel Systemcall

Der angegebene Assemblercode realisiert einen Unterprogrammaufruf (ohne Rückgabewert, also vom Typ
void), der in eine Bibliothek abgelegt werden könnte. Danach würde eine Applikation nur noch diese Bi-
bliotheksfunktion (Library-Call) aufrufen, um den String auszugeben (Bild Codebeispiel Library-Call).

main( int argc, char **argv )


{
write_hello_world();
}

Abbildung 3-29. Codebeispiel Library-Call

78
Kapitel 3. Realzeitbetriebssysteme

Im Regelfall erweitern Bibliotheksfunktionen aber noch den Funktionsumfang von Systemcalls. Die wenig-
sten Applikationen verwenden beispielsweise den write-Aufruf zur einfachen Ausgabe von Informationen,
stattdessen verwenden sie eine Funktion wie printf, um die Ausgabeinformation noch zu formatieren. Die
Funktion printf wiederum führt die Formatierung und den anschließenden Systemaufruf write durch.

3.4.5. Services
Ein Betriebssystem besteht aus dem Betriebssystemkern, ebenso aber auch aus Diensten, die auf der User-
Ebene ablaufen (Services oder Daemonen genannt).
Das Vorhandensein und die Aufgaben dieser Dienste hängen stark vom Einatz des Realzeitbetriebsystems
ab. Es lassen sich die folgenden Gruppen unterscheiden:

Dienste zur Konfiguration


Insbesondere in der Hochlaufphase des Systems müssen diverse Konfigurationen durchgeführt werden.
Hier sind also Dienste aktiv, die die Hardware initialisieren, die das Netzwerk konfigurieren (z.B. IP-
Adresse) oder auch Treiber laden.

Protokolldienste
Entgegen der sehr verbreiteten Art und Weise, dass die einzelnen (Realzeit-) Tasks Informationen auf
proprietäre Weise protokollieren und sichern, sollten die vom Betriebssystem zu diesem Zweck ein-
gerichteten Dienste in Anspruch genommen werden. Protokolliert wird dann nicht nur auf einheitliche
Weise der Zustand des Betriebssystems, sondern auch der Zustand der Applikation.

Netzwerkdienste
Ist das Realzeitsystem vernetzt, müssen verschiedene Dienste aktiv sein, um Anfragen, die vom Netz
kommen, zu beantworten. Typische Dienste hier sind der HTTP-Server (WWW) oder der FTP-Server.
Hierzu zählen aber auch Dienste zur Zeitsynchronisation in einem verteilten Echtzeitsystem.

Dienste der Zeitsteuerung


Betriebssysteme bieten die Möglichkeit, Tasks zyklisch oder zu vorgegebenen Zeiten zu starten. Wür-
den die Tasks diese Zeitsteuerung selber dadurch realisieren, dass sie sich für einen entsprechenden
Zeitraum “schlafen” legten, würden im System mehr Ressourcen benötigt, da die Tasks Speicher im
System (und in den Systemtabellen des Betriebssystemkerns) belegten.

79
Kapitel 3. Realzeitbetriebssysteme

3.4.6. Bibliotheken

statisch dynamic

Prgm. 1 Prgm. 2 Prgm. 1 Prgm. 2 Prgm.

Platte printf printf printf printf

Hauptspeicher RP 1 RP 2 RP 1 RP 2 RP

printf printf printf printf

shared dynamic loaded

Abbildung 3-30. Verschiedene Bibliotheksarten

Wie bereits in Abschnitt Systemcall-Interface beschrieben, abstrahieren zum Betriebssystem gehörige Bi-
bliotheken (Libraries) den Zugriff auf die Systemcalls/Dienste (nicht zu verwechseln mit den Dienstpro-
grammen, Services oder Daemonen). Libraries werden sowohl zu den eigenen Applikationen als auch
zu den Dienstprogrammen hinzugebunden. Man unterscheidet statische von dynamischen Bibliotheken.
Während statische Libraries zu dem eigentlichen Programm beim Linken hinzugebunden werden, werden
dynamische Bibliotheken (auch shared libs genannt) erst dann an das Programm gebunden, wenn dieses
ausgeführt werden soll. Das ergibt folgende Vorteile:

• Das eigentliche Programm wird kleiner (der Code für die Libraries muß ja nicht abgelegt werden).
• Programme können sich eine “shared lib” teilen, wodurch Hauptspeicherplatz gespart wird. dass mehrere
Programme Code verwenden, der nur einmal im Speicher ist, wird durch die Trennung von Code- und
Datensegment ermöglicht (Bild Verschiedene Bibliotheksarten).

Nachteilig bei diesem Verfahren ist es, dass zum Ausführen einer Applikation nicht nur selbige,
sondern zusätzlich auch alle zugehörigen Bibliotheken in der richtigen Version notwendig sind. Gerade
bei komplexen Applikationen können diese Wechselwirkungen derart groß werden, dass Im übrigen
unterstützen moderne Betriebssysteme das Laden dynamische Libraries unter Programmkontrolle (Bild
Dynamisches Laden von Funktionen während der Laufzeit).
Dynamisch ladbare Bibliotheken werden im Regelfall vom System zur Applikation dazugebunden (gelinkt),
wenn die Applikation gestartet wird. Daneben gibt es auch die Variante, dass eine Applikation selbst eine
Bibliothek lädt (siehe Bild Dynamisches Laden von Funktionen während der Laufzeit). Dieses bietet für ei-
nige Anwendungen den Vorteil der möglichen Modularisierung.

#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char **argv)


{
void *handle;
int (*function)(int);
char *error;

80
Kapitel 3. Realzeitbetriebssysteme

handle = dlopen ("myshlib.so", RTLD_LAZY);


if( (error=dlerror()) ) {
fprintf(stderr,"%s\n", error );
return( -1 );
}
function = dlsym(handle, "DoubleMinusOne");
printf ("%d\n", function(5) );
dlclose(handle);
}

Abbildung 3-31. Dynamisches Laden von Funktionen während der Laufzeit

Während früher beim Linken statischer Libraries die komplette Bibliothek hinzugebunden wurde, werden
heute aus einer Bibliothek nur die Funktionen extrahiert, die ein Programm auch wirklich einsetzt. Damit
wird ebenfalls verhindert, dass der Programmcode auf der einen Seite zu stark anwächst oder auf der an-
deren Seite Funktionen auf mehrere Libraries verteilt werden. (Die Verwendung vieler kleiner Libraries
anstelle einer großen Library spart Speicherplatz.)
Insbesondere in eingebetteten Systemen bzw. wenn einfache Laufzeitsysteme verwendet werden, entfällt
die Notwendigkeit von Bibliotheksfunktionen.

3.4.7. Zeitgeber
Zeiten spielen in einem Echtzeitsytem eine wesentliche Rolle. Für Zeitbestimmungen gibt es in einem
Echtzeitsystem sogenannte Realzeituhren und Timer. Diese haben die folgenden Aufgaben:

Zyklische Interruptgenerierung
Ein Timer ist im System dafür verantwortlich, zyklisch (z.B. alle 10 ms) einen Interrupt zu generieren.
In der zugehörigen Interrupt Service Routine wird der Scheduler aufgerufen, es werden zeitabhängige
Systemdienste (Weckaufrufe) bearbeitet und Softwaretimer realisiert. Damit hängt die Genauigkeit der
zeitabhängigen Systemdienste von dieser Zeitbasis ab.

Zeitmessung
Das Messen von Zeiten ist eine oft vorkommende Aufgabe in der Automatisierungstechnik. Geschwin-
digkeiten lassen sich beispielsweise über eine Differenzzeitmessung berechnen.

Watchdog (Zeitüberwachung)
Neben der Zeitmessung spielt die Zeitüberwachung eine sicherheitsrelevante Rolle in Echtzeitsyste-
men. Zum einen werden einfache Dienste (z.B. die Ausgabe von Daten an eine Prozessperipherie)
zeitüberwacht, zum anderen aber auch das gesamte System (Watchdog). Dazu muß das System im
regelmäßigen Abstand einen Rückwärtszähler (Timer) zurücksetzen. Ist das System in einem unde-
finierten Zustand und kommt nicht mehr dazu, den Zähler zurückzusetzen, zählt dieser bis Null und
bringt das System in den sicheren Zustand (löst beispielsweise an der CPU ein Reset aus).

Zeitsteuerung für Dienste


Spezifische Aufgaben in einem System müssen in regelmäßigen Abständen durchgeführt werden. Zu
diesen Aufgaben gehören Backups ebenso, wie Aufgaben, die der User dem System überträgt (z.B. zu
bestimmten Zeitpunkten Meßwerte erfassen).

Zwei Varianten von Zeitgebern lassen sich unterscheiden:

81
Kapitel 3. Realzeitbetriebssysteme

• Absolut-Zeitgeber (also Uhren)


• Relativ-Zeitgeber (sogenannte Timer)

Uhren und Timer lassen sich auf zwei Arten realisieren:

1. in Hardware und
2. in Software

in Form von

• Vorwärts- und
• Rückwärtszählern.

Bei Rückwärtszählern unterscheidet man repetitive Zähler von den single shot Zählern. Die repetitiven
Zähler laden sich mit einem Zählwert selbständig nach Ablauf (wenn der Zählerstand 0 erreicht wird),
während der single shot Zähler explizit neu gestartet werden muß.
In den Ebenen eines Realzeitsystems (Hardware, Kernel, User) gibt es unterschiedliche Arten und Weisen,
um auf Zeiten zuzugreifen:

Hardwarelevel
Auf Hardwareebene werden Timer in Form von Echtzeituhren (Absolutzeitgeber), Frequenzteilern,
Rückwärtszählern und Watchdogtimern zur Verfügung gestellt.
Absolutzeitgeber halten die Absolutzeit (Tag, Monat, Jahr, Stunde, Minute, Sekunde, Millisekunde)
vor. Diese Uhren sind batteriegepuffert, so dass auch nach Abschalten des Stroms die Uhrzeit weiter-
gezählt wird.
Absolutzeiten sind vor allem bei eingebetteten Systemen oftmals nicht notwendig. Jedoch insbeson-
dere für verteilte Realzeitsysteme ist eine genaue Absolutzeit erforderlich. Dabei ist es wichtig darauf
zu achten, dass alle Teilsysteme die gleiche Zeitzone verwenden (zu einem Zeitpunkt ist die Uhrzeit
unterschiedlich an den verschiedenen Orten der Erde). Um hier Probleme von vornherein zu vermei-
den, wird im Regelfall die Hardwareuhr auf die Zeitzone UTC (Universal Time) eingestellt. Die
Betriebssysteme rechnen dann auf die lokale Zeit (mit Sommer/Winterzeit usw.) um. Die eigentlichen
Applikationen selbst jedoch holen sich die Zeit über Systemdienste (siehe unten) und sollten Zeiten
nicht umrechnen müssen.
Über Frequenzteiler werden für die unterschiedlichen (Hardware-) Komponenten des Systems korrekte
Frequenzen von einer Standardfrequenz abgeleitet (z.B. für die Baudrate einer seriellen Schnittstelle).
Bei den Frequenzteilern handelt es sich um Dualzähler, an deren Zähleingang die Standardfrequenz ge-
legt ist. Über einen Multiplexer kann man einen der Ausgänge des Zählers auswählen. Dieser Ausgang
liefert jetzt die entsprechend dem Ausgang geteilte Standardfrequenz.
Ein Rückwärtszähler dient zur Messung von Relativ-Zeiten (Zeitdifferenzen). Die Zähler werden mit
einem Wert belegt, und zählen dann mit einer Eingangsfrequenz (die über einen Frequenzteiler mit
Multiplexer eingestellt werden kann) auf 0. Ist der Zähler abgelaufen, wird ein Interrupt ausgelöst.

82
Kapitel 3. Realzeitbetriebssysteme

Kernellevel
Im Betriebssystemkern (Betriebssystemebene, Kernel, Supervisor Mode) werden Zeiten insbesondere
auf Basis eines zyklischen Timerinterrupts verarbeitet. Dabei zählt das Betriebssystem diese Interrupts
(in Linux sind dies die sogenannten Jiffies) und bietet eine Reihe auf diesen Timerticks basierenden
zeitgesteuerten Diensten an:
• Gerätetreiber können Tasks für eine wählbare Zeitdauer in den Zustand “wartend” versetzen (schla-
fen legen).
• Module können zyklisch Funktionen (Threads) aufrufen lassen.
• Module können einmalig (zu einem Relativzeitpunkt) Funktionen aufrufen lassen.

Vorsicht ist geboten, wenn innerhalb eines (Betriebssystem-) Moduls Absolutzeiten benötigt werden.
Der Abstand zwischen zwei Timerticks muß nicht zwangsläufig von System zu System der gleiche
sein, sondern der Abstand kann variieren.
Weiterhin kritisch ist der Umstand, dass Zähler eine endliche Breite haben und damit nach endlicher
Zeit ein Zählerüberlauf stattfindet (in Linux beispielsweise nach 417 Tagen). Dieser Zeitpunkt kann
für ein System kritisch sein, wenn nicht an allen Stellen (sowohl im eigentlichen Kern als auch in den
Treibern und Modulen) auf Zählerüberlauf geprüft wird.

Userlevel
An der Programmierschnittstelle lassen sich über die Funktion gettimeofday die Absolutzeit bestim-
men. Um einen Prozess oder einen Thread für eine definierte Zeit in den Zustand “wartend” zu verset-
zen, gibt es die Funktionen sleep und select.
An der Dienstschnittstelle stellt das Betriebssystem für periodische Aufgaben cron zur Verfügung. Um
eine Task zu einem bestimmten (Absolut-) Zeitpunkt zu starten, gibt es at.
In Realzeitsystemen stehen oftmals noch zusätzliche Hardwaretimer zur Verfügung. Diese ermögli-
chen eine zeitgenauere Steuerung von Prozessen, als dies über das System bzw. über Softwaretimer
möglich ist.
Während auf der Kernelebene Relativzeiten wegen der möglichen Zählerüberläufe kritisch sind, sind
auf der Applikations- bzw. Userebene die Absolutzeiten kritisch. Überläufe bzw. nicht korrekt berech-
nete Zeitangaben ergeben sich beispielsweise:

• Jahr 2000 Problem, wenn eine Jahresangabe nicht in 4, sondern in nur 2 Stellen abgelegt wird.
Auch bei Software, die im Jahre 1999 geschrieben wird, findet man immer wieder, dass für die
Jahresangabe nur zwei Stellen verwendet werden.
• Die Umschaltung zwischen Winter- und Sommerzeit zum falschen Zeitpunkt.
• Die falsche Berechnung von Schalttagen (29. Februrar).

Weitere Probleme im Umgang mit Zeiten innerhalb des Echtzeitbetriebssystems ergeben sich durch eine
eventuell notwendige Zeitsynchronisation zwischen Rechnern bzw. der Korrektur von Absolutzeiten.
Zur Zeitsynchronisation gibt es unterschiedliche (proprietäre) Konzepte:

83
Kapitel 3. Realzeitbetriebssysteme

• Ein Zeitserver versendet über das Kommunikationssystem Broadcastmessages. Eine Verarbeitung dieser
Messages in Hardware ermöglicht eine Zeitsynchronisation im Mikrosekundenbereich.
• Standardisiert ist die Zeitsynchronisation über das NTP (Network Time Protocol). Hier stellen ebenfalls
Zeitserver die Zeit zur Verfügung, wobei die Zeitserver klassifiziert werden. Der Zeitserver, der die Uhr-
zeit selbst bestimmt (z.B. durch eine DCF77 Funkuhr), ist ein sogenannter Stratus 1 Server. Der Server,
der die Uhrzeit von einem Stratus 1 Server bezieht ist der Stratus 2 Server usw. Bei der Verteilung der
Uhrzeit werden Berechnungen über die Laufzeit der Pakete zwischen den Rechnern durchgeführt, und
die Uhrzeit wird entsprechend korrigiert.

Die sprunghafte Korrektur von Absolutzeiten innerhalb des Rechnersystems kann zu schwerwiegenden
Fehlern führen. Werden Zeitungenauigkeiten erkannt, werden diese nicht sofort korrigiert. Stattdessen wird
die Systemuhr vorsichtig langsamer oder schneller gestellt, so dass sich die Zeit nicht an einem Zeitpunkt
korrigiert, sondern über einen Zeitraum hinweg angepasst wird (Systemcall adjtimex).
Ähnliche Probleme gibt es, falls Rechner für einige Zeit zum Beispiel zum Zwecke der Wartung ausge-
schaltet werden. Sind innerhalb der Ausfallzeit Aktionen, beispielsweise ein Backup geplant gewesen, fällt
dieses aus. Um wirklich alle geplanten Aktionen durchgeführt zu haben, protokollieren einige System mit,
ob die geplanten Dienste gelaufen sind oder nicht. Ist das nicht der Fall, werden die Dienste „nachgeholt“.

3.5. Scheduling
Unter Scheduling versteht man die Strategie zur Festlegung des nächsten zu bearbeitenden Rechenprozes-
ses. Das Scheduling ermöglicht die parallele Bearbietung mehrerer Tasks.
Anhand eines konstruierten Beispiels soll die Aufgabe des Schedulers und die Wirkung bzw. Auswirkung
unterschiedlicher Schedulingvarianten vorgestellt werden.
Ein Realzeitsystem wird eingesetzt, um ein Experiment an Bord eines Satelliten zu steuern. Dazu sind
folgende Anforderungen spezifiziert:

• Alle 1500ms (Zeitpunkt t0) Meßdaten aufnehmen (tp=1500 ms).


• Die Meßwertaufnahme muß nach 400 ms abgeschlossen sein (tZmax=400 ms).
• Alle 200 ms nach Start der Meßdatenaufnahme t0: Experiment anstossen.
• Die Vorbereitungen müssen 500 ms später abgeschlossen sein (also 700 ms nach dem Start der Meßwert-
aufnahme t0, tP=1500 ms, tZmax=500 ms).
• Meßergebnisse müssen innerhalb von 1100 ms (tZmax=1100 ms) zur Erde weitergeleitet werden (alle 60s,
tP=60000 ms).
• Zur Steuerung des Experiments steht ein Mikroprozessor zur Verfügung.
• Die Verarbeitungszeiten für die drei Aufgaben betragen:
• Task 1 - Meßdatenaufnahme: tV=250 ms
• Task 2 - Datenübertragung: tV=500 ms
• Task 3 - Experiment: tV=300 ms

84
Kapitel 3. Realzeitbetriebssysteme

Daten müssen Experiment muß Übertragung muß


aufgenommen vorbereitet sein abgeschlossen sein
sein

Experiment 300ms t V
Meßdatenübertragung 500ms t V
Parameter aufnehmen 250ms t V
100 200 300 400 500 600 700 800 900 1000 1100 t[ms]

Abbildung 3-32. Zeitanforderungen (Beispiel)

Aufgrund des Beispieles ergeben sich für die Konzeption des Realzeitsystems folgende Folgerungen:

• Der Prozessor muß mehrere Aufgaben (Tasks) bearbeiten.


• Dazu muß jeder Prozess unterbrechbar (preemptiv) sein.
• Der Prozessor bearbeitet abwechselnd jeweils einen Teil einer der zu bearbeitenden Tasks.
• Der Rechner muß von seiner Leistung her in der Lage sein, die Aufgabenstellung zeitgerecht zu bearbei-
ten (Auslastung, 1. Echtzeitbedingung).
• Das Betriebssystem muß sicherstellen, dass die maximal zulässigen Reaktionszeiten eingehalten werden
(2. Echtzeitbedingung).

Die Einheit im Betriebssystem (oder Laufzeitsystem), die dieses sicherstellt, ist der Scheduler.

Unter Scheduling versteht man die Strategien in einem Betriebssystem zur Festlegung desjenigen Rechen-
prozesses, der als nächstes bearbeitet werden soll. Das Scheduling ermöglicht damit die quasi-parallele
Bearbeitung mehrerer Aufgaben (Tasks).
Sowohl für die Auswahl des nächsten Rechenprozesses als auch für den eigentlichen Wechsel
(Kontexswitch) wird ebenfalls Rechenzeit benötigt.



  
 



  
 

T3
 
   

           
        

T2 
 
 
 

 
 
 


T1 






 

100 200 300 400 500 600 700 800 900 1000 1100 t[ms]
!  !   ) ) + ) + - + - -
" " $# $# $# &% &% (' (' (' * , * , . , . .

CPU
Zeit, die der Scheduler (incl. Kontextswitch) benötigt.

Abbildung 3-33. Prinzip des Schedulings

Die Zeit, in denen eine Task den Rechnerkern (CPU) zur Verfügung hat (also rechnen darf), muß in einem
vernünftigen Verhältnis zu der Zeit stehen, die für die Auswahl des nächsten Rechenprozesses (Scheduling)
und das eigentliche Wechseln zu diesem Rechenprozess (Kontextswitch) verwendet wird. Die Zeiten für
das Scheduling bewegen sich im µ-Sekundenbereich.
Man unterscheidet statisches und dynamisches Scheduling.

85
Kapitel 3. Realzeitbetriebssysteme

Statisches Scheduling
Festlegung eines „Fahrplans“ (im vorhinein), nach dem die einzelnen Rechenprozesse in einem festen
Schema abzuarbeiten sind. Einsatz: sicherheitskritische Anwendungen (z.B. Flugzeug-Steuerungen),
da die Einhaltung von Realzeitbedingungen formal nachgewiesen werden kann; außerdem in Speicher-
Programmierbaren-Steuerungen.

Dynamisches Scheduling
Zuteilung des Prozessors an Rechenprozesse durch den im Betriebssystem enthaltenen Scheduler auf-
grund der jeweils aktuellen Bedarfssituation. Rechenprozesse müssen damit preemptiv (unterbrechbar)
sein.
Als Scheduler bezeichnet man die Einheit, die für die Zuteilung von Rechenzeit (CPU-Zeit) an Prozes-
se/Threads zuständig ist. Bei Multi-Prozessor-Systemen verteilt der Scheduler die Prozesse/Threads zu-
sätzlich auch auf Prozessoren.

3.5.1. Scheduling Points


In folgenden Situationen muß der Scheduler überprüfen, ob ein anderer Prozess die CPU erhalten sollte und
gegebenenfalls einen Kontextwechsel veranlassen:

• Ende einer Systemfunktion (Übergang Kernel/User Mode):

• Die Systemfunktion hat den aktiven Prozess blockiert (z.B. Warten auf Ende von I/O)
• In der Systemfunktion sind die Scheduling-Prioritäten geändert worden.
• Interrupts
• Timer-Interrupt: der aktive Prozess hat sein Quantum verbraucht (Round Robin).
• I/O signalisiert das Ende einer Wartebedingung (höher priorer Prozess wird „Bereit“).

3.5.2. Bewertungskritierien

Gerechtigkeit
Jeder Prozess soll einen fairen Anteil der CPU-Zeit erhalten.

Effizienz
Die CPU soll möglichst gut ausgelastet werden.

Durchlaufzeit
Ein Prozess soll so schnell wir möglich abgeschlossen sein.

Durchsatz
Es sollen so viele Jobs wie möglich pro Zeiteinheit ausgeführt werden.

Antwortzeit
Die Reaktion auf Ereignisse soll möglichst schnell erfolgen.

86
Kapitel 3. Realzeitbetriebssysteme

Determinismus
Das Scheduling als solches soll berechenbar sein.

Anmerkung: Während für Standard-Betriebssysteme Gerechtigkeit, Effizienz, Durchlaufzeit und


Durchsatz eine wesentliche Rolle spielen, sind für Realzeitbetriebssysteme insbesondere die Kriterien
Antwortzeit und Determinismus entscheidend.

3.5.3. First Come First Serve (FCFS)


Prinzip

• Die bereiten Prozesse sind in einer Warteschlange nach ihrem Erzeugungszeitpunkt geordnet.
• Jeder Prozess darf bis zu seinem Ende laufen, außer er geht in den Zustand „Blockiert“ über.
• Geht ein Prozess vom Zustand „Blockiert“ in den Zustand „Bereit“ über, wird er entsprechend seinem
Erzeugungszeitpunkt wieder in die Warteschlange eingereiht, unterbricht aber den laufenden Prozess
nicht.

Anwendungen

• Batch-Systeme
• um gleiche mittlere Wartezeiten für alle Prozesse zu erreichen.

D C B A Prozeß A ist aktiv

Prozeß A blockiert,
D C B A Prozeß B ist aktiv
Prozeß A ist wieder bereit,
D C A B wird eingereiht
Zeit

Abbildung 3-34. Prinzip des FCFS Schedulings

87
Kapitel 3. Realzeitbetriebssysteme

Deadline T1 Deadline T3 Deadline T2

T3

T2

T1
100 200 300 400 500 600 700 800 900 1000 1100

bereit

aktiv

Abbildung 3-35. First Come First Serve Scheduling

Realzeiteigenschaften: nicht für Realzeitsysteme geeignet, da ein Prozess alle anderen blockieren kann!

3.5.4. Round Robin Scheduling


Prinzip

• Alle Prozesse werden in eine Warteschlange eingereiht.


• Jedem Prozess wird eine Zeitscheibe (time slice, quantum) zugeteilt
• Ist ein Prozess nach Ablauf seines Quantums noch im Zustand „Aktiv“,
• wird der Prozess verdrängt (preempted), d.h. in den Zustand „lauffähig“ versetzt;
• wird der Prozess am Ende der Warteschlange eingereiht;
• wird dem ersten Prozess in der Warteschlange die CPU zugeteilt.

• Geht ein Prozess vom Zustand „wartend“ in den Zustand „lauffähig“ über, so wird er am Ende der War-
teschlange eingereiht.

Kriterien für die Wahl des Quantums

• Das Verhältnis zwischen Quantum und Kontextwechselzeit muß vernünftig sein.


• Großes Quantum: effizient, aber lange Verzögerungszeiten und Wartezeiten möglich.
• Kleines Quantum: kurze Antwortzeiten, aber großer Overhead durch häufige Prozessumschaltung.

88
Kapitel 3. Realzeitbetriebssysteme

Deadline T1 Deadline T3 Deadline T2


Round Robin

RP3
RP2
RP1
100 200 300 400 500 600 700 800 900 1000 1100 t[ms]
Rechenprozess aktiv
Rechenprozess bereit

Abbildung 3-36. Round Robin Schedulings

Realzeiteigenschaften:

Dynamisches Scheduling
Da die Anzahl der bereiten Rechenprozesse nicht bekannt ist, dann der Abarbeitungszeitpunkt
eines Prozesses nicht vorhergesagt werden (nicht deterministisch). Asynchrone Anforderungen
werden nicht direkt bedient. Daher ist das Verfahren für Realzeitsysteme nicht geeignet.

Statisches Scheduling
In einer Abwandlung des Verfahrens (TDMA=Time Division Multiple Access) sind die Zeitscheiben
starr und fest. Sind die Prozesse im System im vornherein bekannt, kann sich das Verfahren,
abhängig von der Aufgabenstellung (z.B. SPS) für Realzeitsysteme eignen.

3.5.5. Prioritätengesteuertes Scheduling


Prinzip

• Für jeden Prozess wird eine Priorität vergeben.


• Der Prozess mit der höchsten Priorität bekommt die CPU.

Realzeiteigenschaften: Für Realzeitsysteme geeignet, insbesondere wenn keinerlei Informationen be-


züglich der maximal zulässigen Reaktionszeiten zur Verfügung stehen.
Allerdings gibt es die Schwierigkeit, die Prioritäten richtig zu verteilen (siehe dazu auch Schritthaltende
Verarbeitung).

89
Kapitel 3. Realzeitbetriebssysteme

Deadline T1 Deadline T3 Deadline T2

T3
T2
T1
100 200 300 400 500 600 700 800 900 1000 1100 t[ms]
Task aktiv Prioritäten:
Task bereit
T1 = 5 (höchste)
T2 = 2 (niedrigste)
T3 = 4 (mittlere)

Abbildung 3-37. Prioritätengesteuertes Schedulings

3.5.6. Deadline-Scheduling
Prinzip

• Der Rechenprozess mit der dem Momentanzeitpunkt am nächsten gelegenen Deadline (maximal zulässi-
ge Reaktionszeit) bekommt die CPU zugeteilt.

Ist−Zeit tZmax =Deadline


t
ts tv

tZmax zu diesem Zeitpunkt muß die Task bearbeitet sein


tv Verarbeitungszeit (ohne Wartezeit)
ts Zeit−Spielraum bis zum spätestmöglichen Start der Verarbeitung (laxity)

Abbildung 3-38. Prinzip des Deadline Scheduling

D1 D2 D3 D4
  

  
        

t
 

  

T1 T2 T3 T4

Abbildung 3-39. Beispiel für Deadline Scheduling

90
Kapitel 3. Realzeitbetriebssysteme

Deadline T1 Deadline T3 Deadline T2

T3
T2
T1
100 200 300 400 500 600 700 800 900 1000 1100 t[ms]
Task aktiv
Task bereit

Abbildung 3-40. Realzeiteigenschaften beim Deadline Scheduling

Realzeiteigenschaften: Das Verfahren führt zur Einhaltung der maximalen Reaktionszeiten, wenn dies
überhaupt möglich ist (optimales Verfahren)!

Nachteil: Deadlines (sprich die maximal zulässigen Reaktionszeiten) sind nicht immer bekannt.

3.5.7. POSIX 1003.1b


Prinzip

• Prioritätengesteuertes Scheduling
• Auf jeder Prioritätsebene können sich mehrere Prozesse befinden.
• Innerhalb einer Prioritätsebene werden Prozesse gescheduled nach:
• First In First Out (First Come First Serve)
• Round Robin

• Prioritätsebene 0 besitzt die niedrigste Priorität.

Scheduling Strategie (Policy) Queue Prioritätsebene

SCHED_RR 103 41 Max Prio

SCHED_FIFO 24 111 42 53 2
SCHED_RR 11 1
SCHED_RR 22 13 12 10 0
42 Prozeß mit der PID 42

Abbildung 3-41. Posix Scheduling

91
Kapitel 3. Realzeitbetriebssysteme

3.5.8. Schedulingverfahren in der Anwendung


Der Ingenieur/Informatiker ist mit Scheduling konfrontiert bei:

• Projektierung eines Realzeitsystems (Auswahl des Verfahrens)


• Zerlegung einer Aufgabe (Applikation) in Rechenprozesse/Threads
• Festlegung von Prioritäten
• Evaluierung von Scheduling-Parameters (z.B. Deadlines)
• Implementierung der Rechenprozesse

3.5.8.1. Zuteilung von Prioritäten

• Faustregel: Je kürzer die Prozesszeit tp, desto kleiner im Regelfall die Verarbeitungszeit tv und desto höher
die Priorität.
• Nach Prozessart: interaktiv, Batch, Netzwerk etc.
• Nach Prozessaktivität
• CPU intensive Prozesse bekommen niedrige Priorität,
• I/O intensive Prozesse bekommen hohe Priorität.

• Benutzerdefiniert

3.5.9. Scheduling in VxWorks

3.5.9.1. Verfahren

• Wind-Task Scheduling
• POSIX-Scheduling

3.5.9.2. Wind Scheduling

• Preemptives Prioritäten Scheduling

• 256 Prioritätsebenen (0=höchste, 255=niedrigste Priorität)


• Round Robin Scheduling
• Innerhalb einer Prioritätsebene wird Round Robin Scheduling verwendet.

92
Kapitel 3. Realzeitbetriebssysteme

Priorität
time slice
hoch T4

niedrig T1 T2 T3 T1 T2 T2 T3
t1 t

Abbildung 3-42. Beispiel für Wind Scheduling

3.5.9.3. Unterschiede

• Der POSIX-Scheduler in VxWorks scheduled Prozesse, der Wind-Scheduler Threads.


• Die Prioritätenbezeichnungen (hoch, niedrig) sind einander invers. In POSIX bedeutet eine hohe Zahl
(z.B. 255) eine hohe Priorität, in Wind-Scheduling eine niedrige.
• Unter Wind-Scheduling ist das Schedulingverfahren innerhalb einer Priorität immer gleich.

3.5.10. Systemfunktionen zur Scheduler-Parametrierung

3.5.10.1. Wind-Scheduling-Funktionen

kernelTimeSlice

Einstellung der RR-Parameter

taskPrioritySet

Modifikation der Taskpriorität

taskLock

Scheduling ausschalten

taskUnlock

Scheduling einschalten

3.5.10.2. POSIX-Scheduling-Funktionen

sched_setparam

Setzt die Task-Priorität

sched_getparam

Liest die Schedulingparameter einer Task

sched_setscheduler

Setzt die Schedulingparameter für eine Task

93
Kapitel 3. Realzeitbetriebssysteme

sched_yield

Gibt die CPU frei (erzwingt Scheduling)

sched_getscheduler

Liest die aktuelle Schedulingstrategie

sched_get_priority_max

Liest die maximal mögliche Priorität

sched_get_priority_min

Liest die minimale Priorität

sched_rr_get_interval

Ergibt die Dauer des Zeitintervalls bei Round Robin Scheduling

3.5.11. Codefragment zum Setzen einer Priorität


#include <stdio.h>
#include <sched.h>

#define PRIORITY_OF_THIS_TASK 5

char *Policies[] = {
"SCHED_OTHER",
"SCHED_FIFO",
"SCHED_RR"
};

static void PrintSchedulingParameter()


{
struct sched_param SchedulingParameter;
struct timespec Time;

printf("Priority-Range SCHED_FF: %d - %d\n",


sched_get_priority_min(SCHED_FIFO),
sched_get_priority_max( SCHED_FIFO ) );
printf("Priority-Range SCHED_RR: %d - %d\n",
sched_get_priority_min(SCHED_RR),
sched_get_priority_max( SCHED_RR));
printf("Current Scheduling Policy: %s\n", Policies[sched_getscheduler(0)] );
sched_rr_get_interval( 0, &Time );
printf("Intervall for Policy RR: %d [s] %d [nanosec]\n",Time.tv_sec,
Time.tv_nsec );
}

int main( int argc, char **argv )


{
struct sched_param SchedulingParameter;

PrintSchedulingParameter();
sched_getparam( 0, &SchedulingParameter );
printf("Priority: %d\n", SchedulingParameter.sched_priority );

// change scheduling policy and priority to realtime priority


SchedulingParameter.sched_priority = PRIORITY_OF_THIS_TASK;
if( sched_setscheduler( 0, SCHED_RR, &SchedulingParameter )!= 0 ) {
perror( "Set Scheduling Priority" );
exit( -1 );
}

94
Kapitel 3. Realzeitbetriebssysteme

sched_getparam( 0, &SchedulingParameter );
printf("Priority: %d\n", SchedulingParameter.sched_priority );
PrintSchedulingParameter();
}

3.5.12. Der O(1) Scheduler im Linux-Kernel 2.5.xx


Weiche Echtzeitsysteme, wie sie beispielsweise Multimediasysteme darstellen, erfordern als zusätzliche
Eigenschaft von einem Scheduler Interaktivität. Interaktivität bedeutet, dass man die Zeitscheibe, die man
einzelnen Tasks zur Verfügung stellt, gemäß der Anforderungen an Interaktivität variiert. Sehr interaktive
Tasks bekommen eine kurze Zeitscheibe und kommen damit häufiger dran. Rechenintensiven Tasks wird
dagegen eine lange Zeitscheibe zugeteilt, falls diese gescheduled werden, dürfen diese auch länger rechnen.
Bei den immer größer werdenden Caches kommt dieses insbesondere der Verarbeitungsgeschwindigkeit zu
gute, schließlich müssen die Caches nicht so häufig gefüllt werden.
Da man im Fall des dynamischen Schedulings im vorhinein nicht die Verarbeitungszeiten und die An-
forderungzeitpunkte der einzelnen Rechenprozesse kennt, muß man auf statistische Informationen aus der
Vergangenheit zurückgreifen.
Der O(1) Scheduler von Ingo Molnar wird folgendermassen beschrieben:
hybrid priority-list and round-robin design with
an array-switch method of distributing timeslices
and per-CPU runqueues.

Der Scheduler basiert prinzipiell auf einem Round Robin Verfahren. Alle rechenbereiten Prozesse sind in
einer Warteschlange (hier als array implementiert) gemäß ihrer Priorität eingehängt. Im System existie-
ren pro CPU jeweils zwei Warteschlangen: eine für die aktiven und eine für die Tasks, deren Zeitscheibe
abgelaufen ist (expired).

acitve

expired switch − sobald das active−Array abgearbeitet ist

Priorität

Abbildung 3-43. O(1) Scheduler im Linux-Kernel

Sobald die Zeitscheibe des aktiven Rechenprozesses abgelaufen ist, wird dieser in das zweite Array (ex-
pired) gemäß seiner Priorität eingetragen. Ist das erste Array abgearbeitet (sprich leer), werden die beiden
Arrays umgeschaltet. Das ehemals expired-Array wird zum active-Array und das ehemals active-Array zum
expired-Array.
Die Priorität innerhalb des Arrays ergibt sich aus dem Nice-Wert, den eine Task besitzt und einem
Interaktivitäts-Bonus bzw. -Malus. Tasks die viel Rechenzeit verbrauchen bekommen eine größere
Zeitscheibe, allerdings bei geringerer Priorität. Die verbrauchte Rechenzeit wird über den Load-Wert
innerhalb der letzten 4 Sekunden bestimmt.

95
Kapitel 3. Realzeitbetriebssysteme

Auch wenn das vorgestellte Verfahren sehr effizient ist, happert es doch mit der Bewertung von rechenin-
tensiven, interaktiven Tasks, wie Tasks zum Video- oder Audiostreaming bzw. Tasks zur Oberflächendar-
stellung. Diese Tasks (X-Windows beispielsweise) mußten zunächst durch den Administrator als interaktiv
gekennzeichnet werden.
Eine erweiterte Heuristik hat dieses überflüssig gemacht. So bekommen ebenfalls die Tasks einen Interak-
tivitätsbonus, die sehr interaktive Tasks aufwecken. Damit ist nach bisherigen Erfahrungen eine ausgespro-
chen gute Erkennungsrate für interaktive Rechenprozesse zu erreichen.
Die typische Zeitscheibe des Schedulers beträgt 200ms. Alle 250ms ist ein Loadbalancer aktiv, der dafür
sorgt, dass die Last im Fall eines Mehrprozessorsystems gleichmässig auf die Prozessoren verteilt wird.

3.6. Realzeitbetriebssystem versus Standardbetriebssysteme

3.6.1. Unterschiede zwischen Realzeit- und Standardbetriebssystemen


Aktuell ist der Trend zu beobachten, in technischen Bereichen zunehmend Standardbetriebssysteme einzu-
setzen. Standardbetriebssysteme weisen nämlich eine Reihe von Vorteilen auf:

• Applikationsvielfalt
• Einarbeitungsaufwand
• gute Entwicklungswerkzeuge
• grafische Benutzeroberfläche mit gewohnter Benutzerführung
• lauffähig auf preiswerter Hardware
• Einbettung von Paramtern aus dem technischen Prozess in Office-Produkte (DCOM/OLE)

Aber für den Einsatz im technischen Umfeld gibt es auch Nachteile:

• Die preiswerte Hardware ist nicht industrietauglich.


• Die Lizenzkosten von Standardbetriebssystemen sind für den Einsatz in eingebetteten Systemen zu hoch
(Lizenzgebühren für Echtzeitbetriebssysteme schwanken abhängig von der abgenommenen Anzahl zwi-
schen 1 und 50$).
• Die Hardwareanforderungen eines Standardbetriebssystems liegen über denen, eines Realzeitbetriebssy-
stems (oftmals mehr als Faktor 10).
• Einarbeitungsaufwand in ein Realzeitbetriebssystem fällt bei der Entwicklung an. In dem Fall, dass das
Betriebssystem in einem eingebetteten System eingesetzt wird, ist für die Bedienung der Einarbeitungs-
aufwand unrelevant. Auch die Applikationsvielfalt spielt in diesem Falle keine Rolle.
• Das Standardbetriebssystem ist nicht realzeitfähig, sprich, es ist nicht deterministisch:
• Paging
• Swapping
• Caching
• File I/O
• Headless und Diskless-Betrieb nicht möglich

96
Kapitel 3. Realzeitbetriebssysteme

• Schedulingstrategien
• die Abhängigkeit von Dienstprogrammen (Services oder Daemonen)
• Anforderungen an Ressourcen (Hauptspeicher, Verarbeitungsleistung, Hintergrundspeicher)

Dazu im einzelnen:

Paging und Swapping


Moderne Betriebssysteme ermöglichen es Applikationen, mehr Hauptspeicher zu verwenden, als über-
haupt physikalisch im System vorhanden ist. Die hierzu verwendeten Techniken heißen Paging und
Swapping. Hierbei werden im Bedarfsfall Teile des Hauptspeichers (Pages) auf eine Festplatte transfe-
riert (geswapped) und bei Zugriff einer Applikation wieder zurückgeschrieben. Paging und Swapping
ist dabei aber nicht berechenbar, das System wird undeterministisch.

Caches
Moderne Prozessoren haben Caches4 eingebaut, durch die die Performance des Systems erheblich
gesteigert wird. Caches sind aber leider nicht deterministisch. Es läßt sich nicht vorhersagen, ob der
nächste Programmbefehl oder das nächste benötigte Datum sich im Cache befindet oder nicht. Im
schlimmsten Fall (Worst Case) gibt es einen sogenannten Cache-Miss und ein realer Speicherzugriff
wird nötig. Das Abschalten von Caches führt allerdings zu drastischen Performanceverlusten.

File I/O
File I/O ist deshalb problematisch, weil der Zugriff auf Datenträger zunächst selbst undeterministisch
ist, zum anderen aber auch (durch die ISR’s) zu Undeterminismen im sonstigen System führt. Hinzu
kommt, dass viele Realzeitsysteme in Umgebungen eingesetzt werden, in denen aus Sicherheitsgrün-
den bewegte Komponenten nicht zulässig sind. Damit scheiden ohnehin klassische Hintergrundspei-
chermedien (Festplatten, Diskettenlaufwerke) aus, allerdings besteht hier technisch die Möglichkeit,
sogenannte Flash-Speicher einzusetzen.

Schedulingsstrategien
Die in Standardbetriebssystemen eingebauten Verfahren zur Auswahl des nächsten Rechenprozesses
(das sogenannte Scheduling), sind für den Realzeitbetrieb nicht geeignet, da dort Verfahren eingesetzt
werden, deren Hauptaugenmerk auf Gerechtigkeit und nicht auf Rechtzeitigkeit liegt. Die Auswahl der
nächsten Task (beim Multitasking) läßt sich nur schwach beeinflußen.

Headless- und Diskless-Betrieb


Standardbetriebssysteme erfordern vielfach das Vorhandensein von Tastatur und Monitor (z.B. zum
Einloggen des Benutzers). Realzeitsysteme werden aber oftmals Headless (also ohne Tastatur und
Monitor) eingesetzt. Ähnliches gilt gänzlich für bewegte Teile, die in den rauhen Umgebungen, in de-
nen die Realzeitbetriebssysteme verwendet werden, nicht verwendet werden dürfen (keine rotierenden
Teile wie Festplatten und Lüfter).

Dienstprogramme
Bei einem Standardbetriebssystem gehören zum eigentlichen Betriebssystemkern (Kernel) eine Reihe
von Dienstprogrammen (Services bzw. Daemonen) und Bibliotheken. Ohne diese Dienstprogramme
ist das System nicht funktionsfähig. Realzeitsysteme dagegen sollen so einfach und übersichtlich wie
möglich gehalten werden. Daher werden nur die wirklich benötigten Dienste implementiert und diese
dann oftmals direkt im Kernel.

97
Kapitel 3. Realzeitbetriebssysteme

Ressourcen-Verbrauch
Prinzipiell benötigen Standardbetriebssysteme ein Vielfaches der Ressourcen, die überhaupt zur Ver-
fügung stehen. Das beginnt bei der zur Verfügung stehenden Rechenleistung (oftmals werden noch
8-Bit Controller eingesetzt), umfaßt die Anforderungen an Hauptspeicher, und schließt den Umstand
ein, dass keinerlei Hintergrundspeicher zur Verfügung steht. Das komplette Betriebssystem muß in
Realzeitumgebungen oftmals in ein Eprom oder in einen Flashspeicher passen.

Standard-Betriebssysteme bieten in der Zwischenzeit aber oftmals Systemerweiterungen an, die das System
in die Lage versetzen, weiche Echtzeitanforderungen zu erfüllen. Diese Eigenschaften sind:

• Memory-Locking
• Disablen von Caches (bedeutet aber gleichzeitig einen erheblichen Performanceverlust)
• Realzeit-Scheduling-Strategien (POSIX-Scheduling)

Einsatz von Standardbetriebssystemen:

Windows 95/98/XP
Diese Betriebssysteme werden nur vereinzelt und dann als Visualisierungsplatform eingesetzt (z.B.
HP-Logicanalyzer). Realzeitaufgaben hat das Visualisierungssystem dabei nicht. Nachteilig bei Win-
dows 95/98/XP ist
• der Ressourcenverbrauch (Rechenzeit, Speicherplatz ...),
• mangelnde Realzeitfähigkeit und
• die Instabilität.

Windows NT, Windows 2000


Windows NT findet in Bankautomaten Verwendung. Für kleinere Systeme ist es - ebenso wie Windows
95/98/XP nicht zu gebrauchen, da die Anforderungen an Ressourcen zu groß sind. Auch wenn NT eini-
ge Realzeiteigenschaften (Memory-Locking, Realzeit-Scheduling) besitzt, ist es nicht deterministisch.
Windows NT besitzt Latenzzeiten von im ungünstigsten Fall 500 ms.
Mehrere Firmen haben Erweiterungen erstellt, mit denen Windows NT realzeitfähig gemacht wird.

Embedded NT
Da die Anforderungen von Windows NT an die Hardware für die meisten Aufgaben im technischen
Umfeld zu groß sind, hat Microsoft eine speziell für den eingebetteten Bereich abgespeckte Version
von Windows NT erstellt (Embedded NT). Embedded NT benötigt nur noch 14-24 MByte. Embedded
NT ist nicht realzeitfähig. Vorteil von Embedded NT ist, dass es das Win32s Interface unterstützt.
Embedded NT läuft nur auf Intel-Prozessoren.

Windows CE/Pocket PC
Windows CE ist jüngst in Windows powered umbenannt worden. Windows CE besitzt nur ein sehr
eingeschränktes Win32s Interface. Dagegen läuft es auch auf Nicht-Intel-Prozessoren (z.B. Hitachi).
Windows CE benötigt 400KByte bis 2.5 Mbyte Hauptspeicher. Im Gegensatz zu den eigentlichen
Windows Varianten und auch Embedded NT kann Windows CE direkt aus dem ROM gestartet werden.

98
Kapitel 3. Realzeitbetriebssysteme

Linux
Linux ist nicht nur auf verschiedensten Prozessoren (mit und ohne MMU) verfügbar, sondern dar-
überhinaus auch skalierbar. Es ist lauffähig auf Systemen mit 256 KByte ROM und 1 MByte RAM.
Es fallen keinerlei Lizenzkosten an. Allerdings - wie auch sämtliche Windowsvarianten - ist Linux
nicht realzeitfähig, auch wenn einige Realzeiterweiterungen (Memory-Locking, POSIX-Scheduling)
eingebaut sind.
Für Linux gibt es Erweiterungen, die den Echtzeitbetrieb ermöglichen. Es ist geplant, dass diese Er-
weiterungen in den Standardkernel mit übernommen werden.

Tabelle 3-3. Standard-Betriebssystem versus Realzeit-Betriebssystem

Standard-Betriebssystem Realzeit-Betriebssystem
Optimiert für Effizienz und Durchsatz. Optimiert auf Determinismus.
Sammeln von Systemaufträgen (effizienter Aufträge werden direkt abgearbeitet.
Plattenzugriff).
Abschnitte werden längere Zeit gelockt. Kurzes Locking.
Kein deterministisches Schedulingverfahren. Deterministisches Scheduling.
Beim Scheduling wird jede Task berücksichtigt. Solange hochpriore Tasks lauffähig sind,
bleiben andere Tasks unberücksichtigt.
Headless und Diskless-Betrieb nicht möglich. OS ist für den eingebetteten Betrieb geeignet.
Paging und Swapping. Paging und Swapping wird nicht unterstützt.

3.6.2. Realzeiteigenschaften von Standard-Betriebssystemen


Wie bereits bei der Diskussion des Schedulers bemerkt, versucht ein Realzeitsystem andere Anforderun-
gen als ein Standard-Betriebssystem zu erfüllen. Insbesondere sind dies Anforderungen an Durchsatz und
Gerechtigkeit. Determinismus dagegen - das Hauptaugenmerk eines Realzeitbetriebssystems - spielt keine
Rolle.
Um effizienter zu sein, werden in Standardbetriebssystemen Datenstrukturen über einen längeren Zeitraum
exklusive gelockt. In Echtzeitbetriebssystemen wird eine Datenstruktur nur für den aktuellen Zugriff ge-
lockt, danach sofort wieder freigegeben, auch wenn ein locken kurze Zeit später wieder notwendig wird.
In Standardbetriebssystemen werden alle lauffähigen Tasks bedient. In einem Echtzeitsystem dagegen kann
es vorkommen, dass eine nieder-priore Task niemals Rechenzeit bekommt, da im System höher-priore Tasks
rechenbereit sind. In Realzeitsystemen wartet eine rechenbereit hoch-priore Task nicht auf eine rechenbe-
reite nieder-priore Task.
Standardbetriebssystem sammeln oftmals Aufträge, um sie dann effizienter gemeinsam zu bearbeiten. Spei-
cherseiten beispielsweise werden nicht einzeln freigegeben, sondern zumeist mehrere gleichzeitig.
In Standardbetriebssystemen sind Systemcalls selbst nicht unterbrechbar. Das führt zu hohen Latency-
Zeiten, die in Realzeitumgebungen nicht zumutbar sind.
High-priority Tasks müssen in Standardbetriebssystemen oftmals auf low-priority Tasks warten, bis diese
eine benötigte Ressource freigeben.
Trotz dieser Gründe hat man Standardbetriebssysteme um Realzeiteigenschaften erweitert. Damit sind al-
lerdings nur Soft-Realtime-Systems möglich.

99
Kapitel 3. Realzeitbetriebssysteme

In Windows NT findet man die folgenden Realzeiteigenschaften verwirklicht:

• Memory-Locking
• POSIX-Scheduling

In Linux findet man die folgenden Realzeiteigenschaften verwirklicht:

• Memory-Locking
• POSIX-Scheduling
• POSIX-Threads

In Linux findet man Wartezeiten (Zeitpunkt vom Eintritt des Interrupts bis zum Start der Bearbeitung,
Latency-Times) von 600 usec und Periodische Tasks werden schon mal um 20 msec auf einem PC mit
Pentium Prozessor verzögert [Yod99].

3.7. Standard-Betriebssysteme in Realzeitanwendungen


Auf Applikationsebene lassen sich unmodifizierte Standardbetriebssysteme dann in Realzeitanwendungen
einsetzen, falls Zeitanforderungen im Sekundenbereich bedient werden müssen.
Doch auch bei Anforderungen im Milliskunden- oder unter Umständen sogar im Mikrosekundenbereich
lassen sich Echtzeitaufgaben mit Hilfe von Standardbetriebssystemen bewältigen. Dazu müssen die Echt-
zeitanforderungen im Betriebssystemkern, z.B. innerhalb eines Gerätetreibers, bearbeitet werden.
Anforderungen im Millisekundenbereich: Treiberfunktionen (z.B. Timer)
Anforderungen im Mikrosekundenbereich: ISR
- keine langwierigen Berechnungen
- meist kein bzw. nur erschwerter Floating Point Zugriff möglich
- keine komplizierte Programmstrukturen möglich
Erreichbare Reaktionszeiten ergeben sich jetzt im wesentlichen aufgrund
der Zeiten, in denen Interrupts (durch Kernelfunktionen oder schlimmer
durch andere Treiber) gesperrt sind.

Vorteil:
- Standardbetriebssystem!!!
Nachteil:
- Lösung der Echtzeitaufgabe verteilt sich auf unterschiedliche
Komponenten und wird auf das Betriebssystem angepasst.

3.8. Realzeiterweiterungen der Standard-Betriebssysteme


Um die Skalierbarkeit und Flexibilität eines Standard-Betriebssystems auch im Realzeitbereich zu bekom-
men, gibt es die folgenden beiden Möglichkeiten:

1. Erweiterung des Standardbetriebssystems um Eigenschaften für harte Echtzeit und


2. Parallelbetrieb des Standardbetriebssystems mit dem Realzeitsystem.

100
Kapitel 3. Realzeitbetriebssysteme

Ein Standardbetriebssystem echtzeitfähig zu machen, ist ausgesprochen aufwendig. Eingriffe sind an allen
Stellen notwendig: Synchronisationspunkte für Datenstrukturen, Scheduling, Interruptverarbeitung, Geräte-
treiber, critical sections, memory management und und und. Für die Modifikationen muß man zudem noch
den Preis einer verminderten Effizienz zahlen.
Die Methode, unter einem Echtzeitkern ein Standardbetriebssystem laufen zu lassen, ist gegenwärtig weit
verbreitet. Sowohl mit Windows NT als auch mit Linux findet man entsprechende Realisierungen. Bei die-
sem Verfahren ist das Standardbetriebssystem quasi eine Task des Echtzeitkerns. Interrupts, insbesondere
auch das Sperren und Freigeben von Interrupts wird durch den Echtzeitkern durchgeführt. Das Verfah-
ren ist zwar vergleichsweise aufwandsarm, nachteilig dabei ist aber, dass sämtliche Tasks, die unter dem
Standardbetriebssystem laufen, nicht echtzeitfähig sind. Insbesondere ist es also nicht möglich, dass eine
Task des Echtzeitkerns eine Komponente des Standardbetriebssystems nutzt (z.B. tcp/ip), ohne dass diese
Echtzeittask ihre Echtzeitfähigkeit (ihren Determinismus) verliert.

3.8.1. RT-Linux
RT-Linux ist am Department of Computer Science der Universität New Mexico entwickelt worden. RT-
Linux selbst ist zunächst ein kleiner Echtzeitkern, der Linux in einer eigenen Task ablaufen läßt. Linux ist
dabei die Idletask, die nur dann aufgerufen wird, wenn keine andere Echtzeittask lauffähig ist.
Jeder Versuch der Linux-Task Interrupts zu sperren (um selbst nicht unterbrochen zu werden) wird vom
Echtzeitkern abgefangen. Dazu emuliert der Echtzeitkern die komplette Interrupt-Hardware. Versucht Linux
einen Interrupt zu sperren, so merkt sich der Echtzeitkern selbiges, ohne den Interrupt wirklich zu sperren.
Tritt nun ein realer Interrupt auf, wird vom Realzeitkern entweder ein Realzeit-Interrupt-Handler (realtime
handler) aufgerufen. Andernfalls wird der Interrupt als pending markiert. Gibt die Linux-Task Interrupts
wieder frei, emuliert RT-Linux den als pending markierten Interrupt für die Linux-Task.
Damit können Interrupts die Linux-Task in jedem Zustand unterbrechen und Linux als solches ist nicht in
der Lage, irgendwelche Latency-Times zu verursachen.

Linux Processes

RT−
Fifos
Real−Time Linux
Tasks

Real−Time Kernel
Interrupt control hardware

Abbildung 3-44. RT-Linux Systemarchitektur [Yod99]

Interessant ist das Konzept Standard- und Echtzeitbetriebssystem parallel zu fahren, nur dann, wenn zwi-
schen beiden auch ein Informationsaustausch möglich ist. RT-Linux bietet dazu zwei Möglichkeiten an:

1. Real-Time-Fifos und
2. Shared-Memory

101
Kapitel 3. Realzeitbetriebssysteme

Die Wartezeit unter RT-Linux beträgt weniger als 15 usec und periodische Tasks werden nicht mehr als 35
usec verzögert.

Fußnoten
1. Moderne Prozessoren können bei Auftreten des Interrupts sogar die Abarbeitung des gerade aktuellen
Befehls unterbrechen und müssen nicht erst auf das Ende der Befehlsabarbeitung warten.
2. Man spricht auch von synchroner Unterbrechung, da die Unterbrechung synchron zum Programmablauf
(also im Programmcode verankert) erfolgt.
3. Das Umladen der Segmentregister ist die Ursache für die Einführung der Memory-Modelle bei Prozes-
soren, die ihren physikalischen Speicherbereich durch Segmentierung erweitern. Die Memory-Modelle
(Small, Medium, Large und Huge) bestimmen, welche Segmente größer als 64 KByte sein dürfen und
welche nicht. Die Modelle Large und Huge allerdings unterscheiden sich nur darin, ob im C-Programm
verwendete Pointer normalisiert und damit vergleichbar gemacht werden oder nicht.
4. Mit Caches bezeichnet man Zwischenspeicher um Zugriffe auf den Hauptspeicher als auch um Zugriffe
auf Hintergrundspeicher (Platte) zu beschleunigen.

102
Kapitel 4. Prozessankopplung

4.1. Übersicht

digitalisierte physikalische
Prozeßsignale Zustandsgrößen

PKM
Echtzeit− technischer
rechner Prozeß

PKM

Aufbereitung bzw.
Ankopplung der Signale

PKM: Peripheriekoppelmodul

Abbildung 4-1. Peripheriekoppelmodule

Werden Realzeitsysteme zur Überwachung und/oder Steuerung eines technischen Prozesses eingesetzt,
müssen die physikalischen Zustandsgrößen des Prozesses eingelesen und beeinflußt werden. Dazu wird
der Echtzeitrechner über Peripheriekoppelmodule (PKM’s), auch einfach als Gerät bezeichnet, mit dem
technischen Prozess verbunden (siehe Bild Peripheriekoppelmodule). Zur Erfassung der physikalischen Zu-
standgrößen gibt es Meßwertaufnehmer, die Sensoren (z.B. Temperatursensor), und zur Beeinflußung der
Zustandsgrößen Stellglieder, die Aktoren (z.B. ein Motor).
Die Peripheriekoppelmodule sind mit dem Echtzeitrechner physikalisch über den Systembus verbunden.
Das Modul belegt dabei im Echtzeitrechner Hardware-Ressourcen: Speicheradressen, I/O-Adressen und
Interrupts.

Galvanische A/D Signalanpassung


PIO Sensor
Entkopplung Wandler (Treiber...)

Galvanische D/A Signalanpassung


PIO Aktor
Entkopplung Wandler (Treiber...)

Abbildung 4-2. Komponenten der Ein-/Ausgabemodule

103
Kapitel 4. Prozessankopplung

Auf logischer Ebene kann man einfache von intelligenten Peripheriekoppelmodule unterscheiden. Über ein
einfaches PMK kann ein einzelner Sensor gelesen werden, bzw. ein einzelner Aktor angesprochen werden.
Intelligente Module belegen nicht nur mehrere Adressen, sondern führen oftmals noch eine Vorverarbeitung
der einzulesenden bzw. auszugebenden Daten durch.
Im folgenden soll zunächst die physikalische Anbindung der Geräte angesprochen werden, bevor eine Dis-
kussion der logischen Ankopplung erfolgt.

4.2. Physikalische Ankopplung

4.2.1. Übersicht Systembus

Netzwerk− Festplatten−
Grafik− controller
controller controller DMA

Systembus

DMA−
CPU RAM ROM
controller

Abbildung 4-3. Systembus

Zur Ankopplung peripherer Bausteine (Speicher, Interrupt-Controller usw.) besitzen Prozessoren Leitungen,
die man als Bus bezeichnet (Bild Systembus). Der Prozessor-Bus ist ein paralleles Hardware-Interface, das
in drei logische Einheiten geteilt werden kann:

1. Adreßbus (AB)
2. Datenbus (DB)
3. Kontrollbus (CB)

104
Kapitel 4. Prozessankopplung

Über den Adreßbus wählt der Prozessor eine Speicherzelle (eben die Zelle eines Speicherbausteins oder die
Speicherzelle eines Hardwaremoduls) aus. Über den Datenbus werden zwischen den Prozessorregistern und
der Speicherzelle Daten transportiert (gelesen oder geschrieben). Der Kontrollbus besteht aus Signalen, die
die Gültigkeit der Adressen auf dem Adreßbus oder der Daten auf dem Datenbus anzeigen (Strobesignale).
Es gehören aber auch die Leitungen dazu, die die Schreib/Leserichtung oder das Vorhandensein einer Un-
terbrechungsaufforderung (Interrupt) anzeigen. Ebenfalls Teil des Kontrollbusses sind die Signale für den
sogenannten Busmastertransfer (siehe Abschnitt DMA).
Bei den Signalen werden Active High Signale von Active Low Signalen unterschieden. Letztere sind da-
durch gekennzeichnet, dass über dem Signalnamen ein Strich gezeichnet wird. Active Low Signale sind
dann gültig, wenn der Signalpegel 0 anzeigt.

Beachte: Die hier angeführten Signalnamen sind frei gewählt, entsprechen aber semantisch den in der
Praxis vorkommenden Signalen.

Bei einem Systembus handelt es sich um einen Master/Slave Bus. Ein am Bus angeschlossenes Gerät ist der
Busmaster. Im Regelfall ist dies der Prozessor. Der Busmaster kontrolliert den Adreßbus, das Signal für die
Schreib/Leserichtung und das Adreß-Strobe-Signal, welches die Gültigkeit der auf dem Adreßbus anliegen-
den Adresse anzeigt. Hat der Busmaster bei einem Schreibzyklus gültige Daten auf den Datenbus angelegt,
oder - bei einem Lesezyklus - ist der Master bereit, über den Datenbus Daten zu empfangen, legt er das Da-
tastrobesignal an. Der Slave (z.B. das Speichermodul) reagiert, wenn er die Daten übernommen (Schreibzy-
klus) hat, bzw. gültige Daten auf den Datenbus gelegt hat (Lesezyklus), mit dem Data-Acknowledge-Signal.

1
Adressen

AS

R/W 2 7

Daten
3 4
DS 6
5
DTACK

Die Signale "Daten" und "DTACK" werden vom Slave als Reaktion auf die Signale
"AS" und "DS" gesetzt.

Abbildung 4-4. Lesezyklus

Die Schritte eines derartigen Buszyklus im einzelnen:

• Der Busmaster wählt die Speicherzelle aus. Dazu legt er die Adresse der Speicherzelle auf den Adreßbus.
• Der Busmaster legt durch Belegung des R/W-Signals die Schreib/Leserichtung fest. Eine 1 auf der Lei-
tung bedeutet Lesen, eine 0 Schreiben.
• Im Falle eines Schreibvorgangs werden die zugehörigen Daten auf den Datenbus gelegt.

105
Kapitel 4. Prozessankopplung

• Sind die Signale auf den Leitungen eingeschwungen, wird das Adreßstrobe und das Datastrobe Signal
gesetzt. Das zeigt den angeschlossenen Modulen an, die Signale auf den Leitungen auswerten zu müssen.
• Das über die Adresse ausgewälte Modul übernimmt bei einem Schreibauftrag die Daten vom Datenbus
und bearbeitet diese. Bei einer Speicherzelle werden die Daten in die Speicherzelle geschrieben. Handelt
es sich bei der ausgewählten Speicherzelle um ein Register bzw. Bits, die eine Peripherie-Komponente
steuern, werden die zu den Signalen gehörenden Funktionen durchgeführt. Nach der Übernahme der
Daten setzt das ausgewählte Modul das Data-Acknowledge-Signal und zeigt damit die Übernahme der
Daten an. Bei einem Leseauftrag legt das ausgewählte Modul die angeforderten Daten auf den Datenbus
und zeigt die Gültigkeit der Daten mit dem Data-Acknowledge-Signal an (beim Lesen also wird der
Datenbus durch das Modul kontrolliert).
Das Data-Acknowledge-Signal zeigt das Ende des Buszyklus an.

• Der Busmaster nimmt die Strobesignale zurück.


• Der Slave nimmt das Data-Acknowledge zurück.

Ein derartiger Buszyklus wird vom Busmaster zeitüberwacht. Dies ist notwendig, da ansonsten das System
bei einem Zugriff auf eine nichtexistente (und damit ungültige) Adresse zum Stillstand kommen würde.
Setzt der Busmaster das Adreßstrobesignal und kann innerhalb einer definierten Anzahl von Taktzyklen kein
Data-Acknowledge- oder beim Leseauftrag Datastrobe-Signal empfangen werden, wird dem Busmaster ein
Bus-Error angezeigt.
Neben den Systembussen, die sich direkt (eins zu eins) aus den Signalen des Mikroprozessors ableiten (dem
sogenannten Prozessorbus), gibt es weitere standardisierte und verbreitete Systembusse:

• der ISA Bus (Intel-Systembus im PC)


• der VMEbus (abgeleitet von Motorola Prozessoren)
• der PCI-Bus (ursprünglich als Ersatz des betagten ISA-Busses für die Intel-PC-Architektur auserkoren,
zwischenzeitlich etabliert als Standard auch im Workstation-Bereich)

4.2.2. Peripherieanbindung über den Systembus


Auf Ebene des Systembusses kann I/O auf zwei Arten angekoppelt werden:

1. Spezielle Ein/Ausgabebefehle
2. Memory-Mapped-IO

Einige Mikroprozessoren (z.B. 80x86) verfügen über spezielle Ein/Ausgabefehle. Eigene


Ein/Ausgabebefehle definieren letztendlich einen eigenen Speicherbereich für Peripheriekomponenten.
Peripherie wird dadurch mit anderen Befehlen angesprochen als normale Speichermodule. Vorteil
dieser Technologie war, dass der in früheren Zeiten vorhandene eingeschränkte Adreßbereich nicht
durch Peripherie belegt wurde. Dieses Argument für eigene Ein/Ausgabebefehle verliert bei den
modernen Prozessoren mit großen Adreßbereichen an Aktualität. Vorteil ist aber weiterhin, dass der
Hardwareaufwand zur Dekodierung eines Peripheriegerätes durch den eingeschränkten I/O-Adreßbereich
geringer ist.

106
Kapitel 4. Prozessankopplung

Kein Unterschied zwischen Speicherbausteinen und Peripherie ergibt sich (eventuell abgesehen vom Zeit-
verhalten), wenn I/O-Module im normalen Adreßraum des Prozessors untergebracht werden. Die Register
der Module werden mit den normalen Move-, Load- oder Store-Befehlen des Prozessors angesprochen.

Moduladdress
Interrupt Interrupt
Logik
Address− AdressEqual
AB
Decoder
PROZESSORBUS

AS
DS &
R/W
EN

0
DTACK

Eingabe 8
binäre
DB Eingänge

15

Digitaler Eingabekanal

Abbildung 4-5. Digitales Eingabemodul

Ein Beispiel für die prinzipielle Ankopplung eines Peripheriemoduls gibt Bild Digitales Eingabemodul wie-
der. Der Adreßdecoder vergleicht die auf dem Adreßbus anliegenden Signale mit der eingestellten Modul-
adresse. Bei Gleichheit wird das Signal AdressEqual gesetzt, welches noch mit den Strobesignalen (Adreß-
strobe und Datastrobe) verundet wird. Sind alle Signale gültig, wird sowohl das En (Enable) Signal erzeugt,
welches den Treiberbaustein aktiviert und die Daten von der Peripherie auf den Datenbus durchschaltet,
als auch gleichzeitig das Data Acknowledge. Das Data Acknowledge Signal ist ein Active Low Signal und
muß daher noch über einen Treiber invertiert an den Bus geführt werden. Das Data Acknowledge Signal
(DTACK) darf nur dann direkt (wie hier gezeigt) erzeugt werden, wenn der Treiber ohne Zeitverzögerung
die Eingangswerte auf den Datenbus durchschaltet. Anderfalls müßte das Signal zeitverzögert werden, in-
dem es beispielsweise einige zusätzliche Gatter durchlaufen muß, eben solange, bis die Signale stabil am
Datenbus anliegen.
Die digitale Ausgabe sieht ähnlich wie das Eingabemodul aus. Das R/W-Signal wird bei der Ausgabe auf
“Write” abgeprüft (Eingang am Und-Gatter invertiert) und die Daten vom Datenbus müssen von der Schal-
tung übernommen werden (z.B. eintakten der Daten in ein Flipflop).
Besitzt ein Interface nicht nur eine sondern gleich mehrere Adressen (z.B. PIO-Baustein, serieller Schnitt-
stellenbaustein), müssen weniger Adreßleitungen ausdekodiert werden. Dazu werden entsprechend dem
zu decodierenden Adreßbereich, die niederwertigen Adreßleitungen nicht verglichen. Diese niederwerti-
gen Leitungen (beispielsweise A0-A2 für einen 8 Byte großen Adreßbereich) können oft direkt an den PIO
Baustein angelegt werden.

4.2.2.1. Erfassung serieller Prozesssignale


Signale des technischen Prozesses müssen oft seriell angekoppelt werden. Da der Rechenaufwand für den

107
Kapitel 4. Prozessankopplung

Prozessor sehr hoch wäre, die serielle Leitung direkt zu bedienen (also im richtigen Zeitraster die zur Über-
tragung notwendige Folge von Nullen und Einsen auszugeben), wird im Regelfall eine Serialisierung (par-
allel/seriell Wandlung) der Signale auf der Senderseite und eine Parallelisierung (seriell/parallel Wandlung)
auf der Empfängerseite durchgeführt.
Technisch wird die Serialisierung und Parallelisierung über ein Schieberegister realisiert. Die Daten werden
in ein Register geschrieben, welches wie im Abschnitt Peripherieanbindung über den Systembus dargestellt,
angeschlossen ist. Danach wird der Vorgang der Serialisierung (und damit auch die Übertragung der Daten)
gestartet.
Module, die eine derartige Umwandlung paralleler Signale in serielle Signale durchführt, heißen “serielle
Schnittstelle”.

7 6 5 4 3 2 1 0
Kontrollregister

Receive−Interrupt Enable
Send−Interrupt Enable

7 6 5 4 3 2 1 0
Statusregister

Data Received
Overrun Error
Parity Error
Framing Error
Shiftregister Empty
Dataregister Empty

Abbildung 4-6. Kontroll- und Statusregister einer seriellen Schnittstelle

Eine serielle Schnittstelle besitzt nicht nur das erwähnte Senderegister (Bild
Kontroll- und Statusregister einer seriellen Schnittstelle):

1. Ein Senderegister zur Parallel-Serienwandlung.


2. Ein Empfangsregister zur Serien-Parallelwandlung.
3. Ein Kontrollregister zur Festlegung der Betriebsart.
4. Ein Statusregister zur Anzeige des Betriebszustandes.
5. Ein Bitratenregister zur Einstellung der Übrtragungsrate.

Wird das Senderegister beschrieben, löst dies eine Übertragung der Daten aus. Damit keine Daten verloren
gehen, muß vor dem Schreiben auf das Sendregister überprüft werden, ob dieses auch leer ist. Das wird
angezeigt über Bit 6 im Statusregister.
Dass ein Byte empfangen wurde, ist ebenfalls im Statusregister (Bit 0) abzulesen. Das Byte kann über
das Empfangsregister ausgelesen werden. Empfängt die serielle Schnittstelle jedoch vor dem Auslesen des
Bytes bereits das nächste Byte, wird im Statusregister (Bit 1) ein sogenannter Overrun (Überlauf) angezeigt.
Ebenfalls angezeigt wird ein Parity-Fehler. Bei asynchronen Übertragungen wird als Übertragungssicherung
ein Paritätsbit hinzugefügt. Die Parität kann dabei “gerade” oder “ungerade” sein. Bei gerader Parität wird

108
Kapitel 4. Prozessankopplung

eine 1 gesendet, falls die Anzahl der Datenbits eine ungerade Summe (nicht ohne Rest durch 2 teilbar)
ergibt, so dass durch das Paritätsbit doch eine durch 2 teilbare Summe von Einsen herauskommt.
Ein Framingerror liegt vor, wenn das letzte empfangene Bit kein Stopbit ist. Empfängt eine Station einen
Framingerror, deutet das auf Timing-Probleme zwischen Sender und Empfänger hin.
Damit die Daten vom Empfänger richtig empfangen werden können, werden nicht nur die Datenbits übertra-
gen, sondern es sind noch zusätzliche Bits notwendig. Ein Startbit wird erzeugt, damit sich ein Empfänger
bei asynchroner Übertragung aufsynchronisieren kann. Um Übertragungsfehler zu erkennen, wird den Da-
tenbits ein Paritybit hinzugefügt. Und schließlich wird das ganze Paket noch durch ein oder zwei Stopbits
abgeschlossen.
Über das Kontrollregister läßt sich der Interrupt-Betrieb der seriellen Schnittstelle konfigurieren. Wird der
Empfangs-Interrupt enabled (eingeschaltet), löst das serielle Interface nach dem Empfang eines Zeichens
einen Interrupt aus. Wird der Sende-Interrupt eingeschaltet, wird jedesmal dann ein Interrupt ausgelöst,
wenn das letzte Bit aus dem Schieberegister geschoben worden ist.

4.2.2.2. Erfassung analoger Prozesssignale


Eine parallele Ein-/Ausgabeeinheit (PIO) eignet sich zur Erfassung digitaler Zustandsgrößen und zur Aus-
gabe digitaler Informationen (z.B. zum Schalten von Relais) an den technischen Prozess. Zur Erfassung
bzw. Ausgabe analoger Größen müssen noch Digital Analog Wandler (DA Wandler, Digital Analog Con-
verter, DAC) bzw. Analog Digital Wandler (AD Wandler, Analog Digital Converter, ADC) angeschlossen
werden.
Um ein Analogwert auszugeben, wird in den Adreßraum der CPU ein Register (eine Reihe von Flipflops)
eingeblendet, hinter das der eigentliche Digital/Analog Wandler angeschlossen wird. Da das Register den
Digitalwert speichert, kann der DAC zeitunkritisch die Wandlung durchführen.
Eine Analogeingabe ist dedizierter zu betrachten. Je nach verwendetem Typ haben haben ADCs Wand-
lungszeiten im Nano- bishin in den Millisekundenbereich. Eine Schaltung zum Anschluß eines schnellen
AD-Wandlers findet sich in Abbildung Ankopplung eines schnellen A/D-Wandlers, eine Schaltung zum An-
schluß eines mittelschnellen AD-Wandlers in Abbildung Ankopplung eines mittelschnellen A/D-Wandlers.
Bei Verwendung eines mittelschnellen oder langsamen AD-Wandlers wird der Zugriff auf den Wandler über
ein Control-Status Register gesteuert (Abbildung Control-Status-Register eines ADC).

15 8 1 0

Start conversion (write)


don’t care in progress/done (read)
Interrupt enable (read/write)

Abbildung 4-7. Control-Status-Register eines ADC

Das vorgestellte Control-Status-Register eines langsamen Peripheriegerätes verhält sich anders als eine nor-
male Speicherzelle, auch wenn das Register softwareseitig in gleicher Art und Weise wie eine Speicherzelle
angesteuert wird. Zwei lesende Zugriffe können durchaus unterschiedliche Ergebnisse liefern, auch wenn
kein Schreibzugriff zwischenzeitlich durchgeführt wurde. Dies liegt daran, dass ja die Hardware die einzel-
nen Bits des Registers setzt. Damit wird auch deutlich, dass ebenso der lesende Zugriff, der einem schreiben-

109
Kapitel 4. Prozessankopplung

den folgt, ein komplett anderes Ergebnis liefern kann, abhängig beispielsweise davon, ob die geschriebenen
Daten (zum Rücklesen) im Modul gespeichert werden oder nicht.

4.2.3. Ankopplung der Signale aus dem technischen Prozess


Tabelle Einteilung von Peripherie gemäß Zugriffsgeschwindigkeit gibt ein mögliches Klassifikationssche-
ma der Peripherie gemäß ihres Zeitverhaltens und der zugehörigen Zugriffstechnologie wieder.

Tabelle 4-1. Einteilung von Peripherie gemäß Zugriffsgeschwindigkeit

Geschwindigkeit Zeitkonstante Technologie

schnell ns direkter Speicherzugriff, DMA


mittel µs programmgesteuerter Kanal
langsam ms Interrupt

4.2.3.1. Direkter Speicherzugriff

Wandlungsstart Wandlungsende
SOC
1 3
Data
2 4
EOC

Abbildung 4-8. AD-Wandler Signalverlauf

Man spricht von schneller Peripherie, wenn diese Zugriffszeiten im Nanosekundenbereich aufweist. Schnel-
le Peripherie wird wie ein normaler Speicherbaustein angeschlossen, wie es beispielsweise in Abbildung
Digitales Eingabemodul dargestellt ist. Das bedeutet, dass Daten vom technischen Prozess in einem Buszy-
klus gelesen werden können bzw. an den technischen Prozess ausgegeben werden können.

110
Kapitel 4. Prozessankopplung

A1 COMP

P
A23
P=Q

0xfffa00 Q

AS

&
SYSTEMBUS

DS
R/W

DTACK
SOC
EN EOC
DO
A/D

D11

Abbildung 4-9. Ankopplung eines schnellen A/D-Wandlers

Abbildung Ankopplung eines schnellen A/D-Wandlers zeigt, wie auf diese Art ein schneller Analog/Digital-
Wandler angeschlossen werden könnte. Der A/D-Wandler hat einen Eingang für das Analogsignal und einen
Eingang für das Starten der Wandlung (Start Of Conversion, SOC). Das Ende des Wandlungvorgangs wird
durch das Signal End Of Conversion (EOC) angezeigt. Hat dieses Signal einen High-Pegel, können die
Daten vom Datenbus des Wandlers abgegriffen werden. Sobald das SOC-Signal wieder einen Low-Pegel
annimmt, nimmt der A/D-Wandler auch das EOC-Signal zurück und die Datenausgänge haben wieder einen
unbestimmten Wert.
Softwaretechnisch wird auf diese Schaltung genauso zugegriffen, wie auf eine sonstige Speicherzelle im
Adreßraum des Prozessors auch:
int DigitalWert;
int *Wandler; // Der Wandler liefert 12 Bit zurueck, ein char reicht nicht

...
Wandler=0xFFFA00;
...
DigitalWert=*Wandler;
DigitalWert=DigitalWert&0x0FFF; // nur die unteren 12 Bit sind gueltig
...

111
Kapitel 4. Prozessankopplung

A1 COMP A1 COMP
Lesen
Controlwort
P P
A23 A23
P=Q P=Q
AS
0xFFFA00 Q 0xFFFA02 Q DS
R/W
&
Schreiben
Statuswort EN
AS DO D1
D EOC

&
SYSTEMBUS

DS
Reset DTACK
R/W

DTACK
SOC
EOC
EOC
A1 COMP
EN
P DO A/D
A23
P=Q

0xFFFA04 Q

D11

AS Lesen
Daten
DS
&
R/W DTACK

Abbildung 4-10. Ankopplung eines mittelschnellen A/D-Wandlers

4.2.3.2. Programmgesteuerter Kanal


Auf mittelschnelle Geräte, deren Zugriffsgeschwindigkeit etwa im Mikrosekundenbereich liegt, wird über
den sogenannten programmgesteuerten Kanal zugegriffen. Würde der Wandler wie oben beschrieben ange-
schlossen, wäre der Prozessor für mehrere µ-Sekunden ausgebremst (entsprechend der Länge eines Wand-
lungszyklus). Es ist sinnvoller, in einem ersten Schritt den Wandlungsprozess zu starten und zu einem späte-
ren Zeitpunkt abzufragen, ob das Wandlungsende erreicht ist. Ist dies der Fall, können die Daten eingelesen
werden.
Die drei unterschiedlichen Zugriffe (Starten der Wandlung, Überprüfen des Wandlungsendes und Einle-
sen der Daten) werden beispielsweise, wie in Abbildung Ankopplung eines mittelschnellen A/D-Wandlers
dargestellt, über den Zugriff auf drei Adressen abgebildet. Über die Adresse 0xFFFA00 kann man auf ein
sogenanntes Controlwort schreiben. Dieses aus theoretisch 16 Bit bestehende Register ist für das Starten
der Wandlung zuständig. Aus der Schaltung ist ersichtlich, dass das Schreiben des least significant bits (Bit
0) die Wandlung gestartet wird.

112
Kapitel 4. Prozessankopplung

Über die Adresse 0xFFFA02 kann der Zustand der Wandlung (Signal EOC) ausgelesen werden. EOC ist hier
auf Bit 1 abgebildet. Die eigentlichen Daten schließlich werden bei einem Lesezugriff auf die Speicherstelle
0xFFFA04 in ein internes Prozessorregisgter übernommen.

Die Schaltung belegt damit insgesamt 6 Byte im Adreßraum der CPU. Eine Codefragment zum Auslesen
eines gewandelten Analogwertes könnte folgendermassen aussehen:
volatile int *ControlWort, *StatusWort, *DatenWort;
int DigitalWert;

...
// Initialisierung
ControlWort=0xFFFA00;
StatusWort =0xFFFA02;
DatenWort =0xFFFA04;

...
// Starten einer Wandlung
*ControlWort=0x0001; // Setzen von Bit 0 startet die Wandlung
// Warten auf das Wandlungsende
while( *StatusWort!=0x0002 ) // EOC ist gleich Bit 1
;
// Auslesen der Daten
DigitalWert=*DatenWort;
DigitalWert&=0x0fff; // nur die unteren 12 Bit sind gueltig
...

Sind zur Bedienung eines Gerätes mehrere Zugriffe auf die Peripherie notwendig, spricht man vom pro-
grammgesteuerten Kanal.
Bei der Realisierung der Hardwareschaltung würde man im Regelfall nicht 3 Adreßvergleicher (Kompara-
toren), sondern nur einen einsetzen. Dieser Adreßvergleicher würde nur die Adreßleitungen A3-A23 deco-
dieren. Die UND-Gatter, welche schließlich die Gültigkeit der Adresse und des Zugriffes (R/W) überprüfen,
würden zusätzlich mit den Adreßleitungen A1 und A2 belegt werden. Damit gäbe es dann für jeden unter-
schiedlichen Zugriff ein UND-Gatter (hier also drei).
Da auf das Controlwort nur schreibend, auf das Statuswort nur lesend zugegriffen wird, könnten diese
beiden Zugriffe über eine Adresse realisiert werden. Damit würde das Interface insgesamt nur 4 Byte im
Adreßraum belegen und die Adreßleitung A2 bräuchte nicht mehr ausdekodiert zu werden.
Das Schlüsselwort volatile im C-Code ist notwendig, da der Compiler den Schleifenzugriff while(
*StatusWort!=0x0002) derart optimieren würde, dass er den Inhalt des Statuswortes einmal in ein internes
Prozessorregister kopieren würde, und dieses dann immer wieder auf Ungleichheit mit 0x0002 überprüfen
würde. Das interne Prozessorregister ändert sich natürlich nie, daher würde das Programm in einer
Endlosschleife hängen bleiben. Das Schlüsselwort volatile verhindert diese Art der Optimierung. Bei
jedem Zugriff auf den Zeiger wird der Wert real aus dem Speicher (hier Peripherie) gelesen.

4.2.3.3. Interruptbetrieb
Langsame Peripherie, die Zeitkonstanten im Bereich von Millisekunden und mehr besitzt, benötigt eben-
falls eine Ablaufsteuerung, die durch ein Control- und ein Statusregister (bzw. ein Control/Statusregsiter)
repräsentiert wird. Der pollende Zugriff mit letztendlich aktivem Warten (Busy-Loop) kann nur in beson-
deren Fällen toleriert werden. Im Regelfall informiert das Ein-/Ausgabemodul die Steuerung per Interrupt
über Zustandsänderungen, so dass das Interface um eine Interruptlogik erweitert werden muß (interruptge-
steuerter Kanal).
Schaltungstechnisch wird dazu das EOC-Signal zusätzlich auf den Interrupteingang des Systembusses ge-
legt.

113
Kapitel 4. Prozessankopplung

4.2.3.4. DMA
Über den Prozessor- bzw. Systembus können Prozessor und Peripherie miteinander verbunden werden. Im
Falle von hochfrequent anfallenden Daten, kann der Prozessor die Daten jedoch nicht von der Peripherie
abholen und direkt verarbeiten, sondern wird die Daten zunächst blockweise entgegennehmen. Dies ist
beispielsweise bei Plattenzugriffen der Fall.
Ein entsprechender blockweiser Datentransfer läßt sich softwareseitig wie in Bild
Datenübertragung unter Kontrolle der CPU gezeigt, realisieren. In einer Schleife werden die Daten von
der Peripherie eingelesen und im Speicher abgelegt bzw. umgekehrt.
Die Transferrate ergibt sich dabei aufgrund der Programmlaufzeit und der Buszugriffszeit. Angenommen
der Zugriff über den Systembus dauere tB=100ns, die Zugriffszeit, die der Speicher selbst benötigt, wird
vernachlässigt (tM=0), die Zugriffszeit, die die Peripherie benötigt wird ebenfalls vernachlässigt (tIO=0) und
die Programmlaufzeit sei tV=1µs, so ergibt sich die Transferrate zu:
r = 1/(tV + 2 tB + tM + tIO)=0.833MWorte/s

Ist ein Wort 32 Bit breit (wie beim PC), so ergibt sich damit eine maximale Transferrate von gut 3 MByte/s.
Festplatten erreichen aber bereits heute standardmäßig Transferraten von 20MByte/s und moderne Platten
von 40-50MByte/s.
Sieht man sich die Formel an, so ist zu erkennen, dass höhere Transferraten nur durch Minimierung von
tV bzw. tB zu erreichen sind. Aus diesem Grunde wird in der Tat auf der einen Seite der Zugriff über den
Systembus beschleunigt (mittlerweile liegen die Taktraten hier bei 133MHz) und auf der anderen Seite wird
die Aufgabe des Datentransfers von der Software in die Hardware verlagert.

Anmerkung: Unter DMA versteht man ein Verfahren zum Austausch/Transfer von zusammenhängenden
Datenbereichen (Blöcken) zwischen Speicher (RAM) und Peripherie (z.B. Festplatte). Es handelt sich
um eine Art der Hardwarerealisierung des Datentransports unter Programmkontrolle (programmgesteu-
erter Kanal, Bild Datenübertragung unter Kontrolle der CPU). Die Hardware, die für den Datentransport
zuständig ist, bezeichnet man als DMA-Controller (Direct Memory Access).

DMA wird dadurch ermöglicht, weil die CPU die Kontrolle über den Bus abtreten kann. Dafür existieren
(als Teil des Control-Bus) die Bus-Arbitrierungssignale. Der Slave, der Busmaster werden möchte, teilt
dies der CPU über ein Signal mit (z.B. Bus Request oder Hold). Die CPU signalisiert, dass die Kontrolle
über den Bus übernommen werden kann (Bus Grant). Der Slave übernimmt den Bus und ist damit neuer
Busmaster (Bus Grant Acknowledge). Nach Beendigung der Übertragung gibt der DMA-Busmaster den
Bus wieder an die CPU zurück (Zurücknahme der Signale Bus Grant Acknowledge bzw. Hold).

114
Kapitel 4. Prozessankopplung

MemoryPointer = Start−Adresse des Blocks im Hauptspeicher


BlockCount = Größe des Speicherblocks
1
TransferDirection = Vom Hauptspeicher zur Peripherie oder umgekhert

Port = Kennung (Adresse) des Peripheriegeräts


Solange BlockCount>0

Wenn TransferDirection
Mem nach I/O I/O nach Mem

Wert = Inhalt von MemoryPointer Wert = ReadPeripherie(Port) 2


WritePeripherie( Port ) = Wert Inhalt von MemoryPointer = Wert

Decrementiere BlockCount / Incrementiere MemoryPointer

WakeUp( Alle Prozesse, die auf das Ende des Datentransfers warten ) 3

Abbildung 4-11. Datenübertragung unter Kontrolle der CPU

Während sich unter Kontrolle eines Programms bei 100%iger Auslastung beispielsweise (abhängig von den
verwendeten Speicherbausteinen) nur rund 1.500.000 Worte/sec übertragen lassen, kommt man bei gleichen
Voraussetzungen mittels DMA auf das vierfache.
DMA wird eingesetzt um

• Die Übertragungsrate zu erhöhen.


• Die CPU zu entlasten.

Memory READ/WRITE Data−chain


registers
I/O READ/WRITE

Channel 0
To I/O port
Bus−Arbitration

HOLD Address TRANSFER ACK


Control

HOLD ACKNOWLEDGE Bus Command


TRANSFER REQUEST
Processorbus Interface Count
IRQ
Port
Busarbitrierungssignale:
Intel:
Internal bus

− Hold
Channel 3
Sequenzer − Hold Acknowledge

Motorola
− Bus Request
− Bus Grant
− Bus Grant Acknowledge

Abbildung 4-12. HW-Struktur eines typischen DMA-Controllers

115
Kapitel 4. Prozessankopplung

Beim DMA-Betrieb werden 3 Phasen unterschieden:

1. Initialisierungsphase/Aufsetzen des Kanals:


Die CPU ist Bus-Master und beschreibt die DMA-Register, der DMA-Controller ist aus Sicht des
Prozessorbusses Slave.

2. DMA-Betrieb
Der DMA-Controller wird Busmaster. Er überträgt Daten zwischen Peripherie und Speicher. Zwischen-
durch gibt er den Bus immer wieder frei. Diese zweite Phase wird zyklisch solange durchlaufen, bis
alle Daten übertragen wurden. Diese Phase wird oft auch als “cycle stealing” bezeichnet.

3. Ende des DMA-Betriebs


Der DMA-Controller informiert die CPU über das Ende per Interrupt.

Beim DMA-Betrieb lassen sich zwei Modi unterscheiden:

1. Beim sogenannten Normalbetrieb wird bei jedesmal, wenn ein Datum zur Übertragung anliegt, der
CPU ein Speicherzyklus gestohlen.
2. Beim Burstbetrieb wird der Umstand ausgenutzt, dass der Zugriff auf aufeinanderfolgende Speicherzel-
len bei dynamischen Speicherbausteinen (DRAMs) für die Folgezugriffe schneller erfolgt1. Daher wird
nicht bei jedem Datum, das es zu übertragen gilt, ein Zyklus gestohlen, sondern es wird eine Anzahl
Daten aufgesammelt, es wird die Busmasterschaft übernommen und die gesammelten Werte werden
hintereinander übertragen. Erst dann wird die Kontrolle über den Bus wieder an die CPU abgetreten.

116
Kapitel 4. Prozessankopplung

Normalbetrieb
5 µs
DMA
Anforderung

0.4µs
"gestohlene"
Zyklen

Prozessor−
Zyklen

Burstmode 1 µs

Datenanfall

5 µs
DMA
Anforderung

"gestohlene"
Zyklen

Prozessor−
Zyklen

Abbildung 4-13. DMA-Betriebsmodi

Eine weitere Zugriffssteigerung läßt sich erreichen, indem der DMA-Controller direkt mit dem Periphe-
riegerät verbunden wird (bei Festplatten spricht man von sogenannten UDMA-Platten). Dadurch muß der
DMA-Controller nicht erst von der Peripherie über den Systembus die Daten einlesen, sondern er kann sie
direkt (ohne zu Hilfenahme des Systembusses) übernehmen und im Speicher ablegen (bzw. beim Schreiben
direkt aus dem Speicher übernehmen). Damit ergibt sich die Transferrate zu
r=1/tB

Bewertend läßt sich zusammenfassen:

• DMA ist ein Verfahren zur effizienten und schnellen Übertragung von Datenblöcken zwischen Peripherie
und Hauptspeicher.
• DMA eignet sich nicht für die Übertragung von einzelnen Werten.
• Es handelt sich um die Hardwarerealisierung des programmgesteuerten Kanals.
• DMA-Bausteine verfügen über mehrere DMA-Kanäle (typischerweise 4). Jeder Kanal besteht im we-
sentlichen aus 4 Registern:
• Hauptspeicheradreßregister
• Byte-Count-Register
• Commandregister (enthält z.B. die Übertragungsrichtung)
• I/O Port

• Während des DMA-Zugriffs kann der Prozessor nicht auf den Bus zugreifen.
• Der DMA-Baustein ist abhängig von der Betriebsphase mal Bus-Master und mal Slave.

117
Kapitel 4. Prozessankopplung

4.2.4. Sonstige Varianten

4.2.4.1. Gemultiplexte Ein-/Ausgabe

a0
a1 1−aus−4−Decoder

d0 EN y

EN
d1
EN
d2

EN
d3

Abbildung 4-14. Multiplexer

Mithilfe eines Multiplexers kann einer von mehreren Ein-/Ausgabekanälen ausgewählt und damit durchge-
schaltet werden. Bild Multiplexer zeigt eine prinzipielle Realisierungsform. Über Adreßleitungen (im Bild
a0 und a1) wird einer der vier Datenleitungen (im Bild d0 bis d3) durchgeschaltet.
Zwei Anwendungsformen der gemultiplexten Daten Ein-/Ausgabe lassen sich unterscheiden: der Daten-
multiplex und der Zeitmultiplex.

4.2.4.1.1. Datenmultiplex

(schneller)
Sample
Analog and A/D−
Hold Wandler
Multiplexer
S/H

SOC EOC

A0 A1

Abbildung 4-15. Analogmultiplexer

Weite Verbreitung haben Analogmultiplexer (siehe Bild Analogmultiplexer) gefunden: Um teure A/D-
Wandler zu sparen, setzt man vor einen A/D-Wandler einen Analogmultiplexer, mittels dem einer von
mehreren Analogkanälen ausgewählt und an den A/D-Wandler durchgeschaltet werden kann.
Eine andere Anwendung des Datenmultiplexing ist die Aufweitung des (I/O-) Adreßraums. Steht beispiels-
weise nur eine (Byte-) Adresse zur Ein- oder Ausgabe zur Verfügung, lassen sich per Multiplexing bis zu

118
Kapitel 4. Prozessankopplung

128 einzelne Bits steuern. Allerdings sind dazu auch bis zu 128 Zugriffe notwendig. Eine Schaltung, die
die Ansteuerung von 16 mal 4 Bit ermöglicht, zeigt Bild Datenmultiplex. Die oberen 4 Bit des 8 Bit brei-
ten Datenwortes wählen eines von 16 möglichen 4 Bit Registern aus. Hierin werden die unteren 4 Bit des
Datenwortes gespeichert.

Adressen

d7
d6 1 aus 16
d5 Decoder
d4

VZ VZ VZ

C1 C1 C1 Stellsignale

1D Q 1D Q 1D Q
1D Q 1D Q 1D Q
1D Q 1D Q 1D Q
1D Q 1D Q 1D Q
d3
d2
d1
d0

VZ = Verzögerung

Abbildung 4-16. Datenmultiplex

4.2.4.1.2. Zeitmultiplex

C/S
Port A
A0−A2
En En En En

PIO

D0−D7 D0−D7 D0−D7 D0−D7 D0−D7

Port B

Abbildung 4-17. Ansteuerung einer Anzeige im Zeitmultiplex

119
Kapitel 4. Prozessankopplung

Zeitmultiplex wird oft im Kontext von Anzeigen (Anzeigetafeln) eingesetzt (Bild


Ansteuerung einer Anzeige im Zeitmultiplex). Man nutzt den Umstand, dass das menschliche Auge Bilder,
die ab einer Frequenz von ca. 20 Herz auftreten, als Film auffaßt und nicht mehr in Form von Einzelbilder
erkennt. Man schaltet daher die einzelnen Anzeigeelemente nicht alle gleichzeitig, sondern nacheinander
an - und das mit einer Frequenz höher als 20 Herz. Dafür braucht man dann nicht einen Ausgabeport für
jede Stelle der Anzeige, sondern begnügt sich mit einem Ausgabeport, der die Segmente einer Stelle
ausgibt, und einem Port, der das Anzeigenelement auswählt, auf welches die Ausgabe durchgeführt
werden soll.

4.3. Softwaretechnische Ankopplung

4.3.1. Einfache Peripherie


Auf “unterer” Ebene wird Sensorik und Aktorik (also die Peripherie, die Geräte) direkt über Register an-
gesprochen. Die Bits in den Registern besitzen spezifische, aufgrund der Hardware-Verschaltung gegebene
Funktionen.

4.3.2. Intelligente Peripherie


Unter einem intelligenten Sensor oder Aktor versteht man ein Peripheriegerät, das mit eigener Rechenlei-
stung ausgestattet ist und eine Vorverarbeitung des Meß- oder Stellwertes durchführt. Vorverarbeitung kann
in diesem Falle

• Skalierung,
• Meßbereichsumschaltung,
• Konvertierung
und ähnliches sein.
Die Datenschnittstelle (Datenfluß) zu einem derartigen Sensor oder Aktor besteht im Regelfall aus einem
Satz von Registern (Speicherbereich), der oft als Service Description Block (SDB) bezeichnet wird.
So derartiger Service Description Block besteht im Regelfall aus drei Register (ähnlich wie ein Funktions-
aufruf 3 semantische Einheiten hat), die geschrieben bzw. gelesen werden:

• Kommandoregister (in Analogie zum Funktionsnamen, die Funktion ist durch Software auf dem Periphe-
rieboard bestimmt)
• Argumentenregister (der bzw. die Parameter)
• Status- bzw. Ergebnisregister (Ergebnis des Funktionsaufrufes)

Für den Kontrollfluß enthalten diese Register (z. B. das Statusregister) Flags, über die der Datenaustausch
synchronisiert wird. Intelligente Sensoren und Aktoren nutzen darüberhinaus sehr häufig auch Interrupts,
um dem Hostsystem (dem Steuerrechner) mitzuteilen, dass Informationen vorliegen, bzw. der Hostrechner
löst beim Sensor bzw. Aktor einen Interrupt aus, um diesem ebenfalls das Vorliegen von Daten (z.B. ein
Auftrag an die Peripeherie) mitzuteilen.

120
Kapitel 4. Prozessankopplung

Größere Datenmengen werden zwischen Peripherie und Steuerrechner (Hostsystem) über einen gemeinsa-
men Speicherbereich (Dual Ported Ram, DP-RAM) ausgetauscht.

0x1000 0x0009 0xf000

0x1009 0xf009

Mem−Basis aus Sicht des Prozessors:0x1000


Mem−Basis aus Sicht des Moduls: 0xf000

Adresse = Basis + Offset


Prozessor 0x1000 + 0x0009 = 0x1009
Modul 0xf000 + 0x0009 = 0xf009

Abbildung 4-18. Unterschiedliche Adreßlagen beim DP-Ram

Merke: Da im Regelfall der gemeinsame Speicher aus Sicht des Steuerrechners eine andere Adreßlage
(andere Adressen) hat, als aus Sicht des Sensors/Aktors, sollten in der Software vereinbarte gemein-
same Zeiger auf spezifische Bereiche des DP-Rams nur als Relativ-Adressen (relativ en (siehe Bild
Unterschiedliche Adreßlagen beim DP-Ram).

Merke: Je nach technischer Realisierung des DP-Ram’s ist der Zugriff auf eine oder mehrere (eventuell
des gesamten DP-Ram’s) Speicherzellen zu einem Zeitpunkt nur von einer Seite möglich. Greift daher
ein schneller Prozessor (beispielsweise pollend) ständig auf den Speicher zu, kann die andere Seite
blockiert werden. Der Zugriff auf das DP-Ram muß daher streng organisiert sein!

4.3.3. Kommunikationsmodule/Feldbusse

4.3.3.1. Grundlagen

4.3.3.1.1. Protokolle
Wollen zwei oder mehr Kommunikationspartner (Rechner) Informationen austauschen, muß es zunächst
eine physikalische Verbindung zwischen beiden geben (Kabel, Lichtwellenleiter, Funk, Diskette oder ähnli-
ches). Über dieses Medium können dann die Informationen gesendet werden. Abhängig vom physikalischen
Medium können mehrere Kommunikationspartner unabhängig voneinander kommunizieren. Eine Funk-
strecke beispielsweise bietet unterschiedliche Frequenzen, die genutzt werden können. Sobald jedoch die
Kommunikations bidirektional möglich sein soll bzw. mehr als zwei Partner miteinander kommunizieren,
benötigt man ein Protokoll.

121
Kapitel 4. Prozessankopplung

Hörer abheben

Nummer wählen

LAYER LAYER Ertönt das Besetztzeichen?


Nein Ja
Wird abgehoben? Auflegen
Ja Nein
Meldet sich gewünschter
Ja Partner? Nein Abbruch
Eigenen Namen durchgeben
Abbruch
Informationsaustausch

Abbildung 4-19. Vereinfachtes Protokoll zum Telefonieren

Mit Protokoll bezeichnet man die (Ablauf-) Vorschrift für die Kommunikation. Im täglichen Leben ver-
wenden wir auch Protokolle, ohne dass uns das oftmals bewußt ist. Ein Beispiel dazu ist das Telefonieren
(Bild Vereinfachtes Protokoll zum Telefonieren). Bevor wir mit unserem Gesprächspartner reden können,
müssen wir erst einmal eine Verbindung zu diesem aufbauen. Dazu identifizieren wir den Partner über ei-
ne (Telefon-) Nummer, die wir wählen. Nach dem Wählen hören wir entweder ein Besetztzeichen oder
ein Freizeichen. Das Besetztzeichen ist ein Ton unterbrochen mit kurzen Pausen, das Freizeichen ein Ton
mit langen Pausen. Hören wir das Besetztzeichen, brechen wir den Verbindungsaufbau ab (legen auf) und
versuchen es zu einem späteren Zeitpunkt erneut. Beim Freizeichen warten wir noch, ob unser Partner das
Gespräch annimmt oder nicht. Im letzteren Falle brechen wir auch den Verbindungsaufbau ab und versu-
chen es zu einem (eventuell viel) späteren Zeitpunkt erneut. Nimmt der Gesprächspartner das Gespräch
an, meldet er sich zunächst einmal mit seinem Namen (schließlich wollen wir ja nicht mit der Nummer,
sondern mit einem bestimmten Menschen, der über diese Nummer erreichbar ist, sprechen). Meldet sich
jemand vielleicht Unerwarteter, erklären wir, dass wir eigentlich mit einem anderen (und wir definieren, mit
welchem) Kommunikationspartner reden wollen. Haben wir unseren Gesprächspartner an der Strippe, dann
geben wir unsererseits unseren Namen preis, damit der Partner weiß, mit wem er spricht, und beginnen
unser Anliegen mitzuteilen. Sprechen wir jetzt noch die gleiche Sprache (z.B. Deutsch oder Englisch), dann
versteht uns im Normalfall auch der Gegenüber.
Ähnlich wie der Verbindungsaufbau funktioniert auch der Verbindungsabbau. Wir fragen noch nach, ob die
Information richtig angekommen ist, wiederholen sie eventuell noch einmal und verabschieden uns dann.
Danach beenden beide das Gespräch (früher sprach man vom “Hörer auflegen”).

4.3.3.1.2. Schichtenmodell der Kommunikation


Betrachtet man das soeben vorgestellte Beispiel genauer, erkennt man, dass es genaugenommen einen Ver-
bindungsaufbau auf zwei Ebenen gibt. Auf der unteren Ebene wird zunächst eine Verbindung bis zum
Anschluß des Kommunikationspartners hergestellt. Dieser Vorgang ist beendet, wenn dort das Gespräch
entgegengenommen wird (der Hörer wird abgenommen). Danach erfolgt der Verbindungsaufbau mit dem
eigentlichen Kommunikationspartner, bei dem die Identifikationen festgestellt werden (beide nennen ihren
Namen).
Ohne Einhaltung dieser Regeln wäre ein vernünftiges Telefonieren nicht möglich.
Zum besseren Verständnis der Kommunikation gibt es ein Modell, anhand dessen unterschiedliche Kom-
munikationssysteme beschrieben werden können: das ISO/OSI Schichtenmodell der Kommunikation.
Das Schichtenmodell beschreibt verschiedene Ebenen der Kommunikation.

122
Kapitel 4. Prozessankopplung

Application Layer Application Layer

Presentation Layer Presentation Layer

Session Layer Session Layer

Transport Layer Transport Layer

Network Layer Network Layer

Data Link Layer Data Link Layer

Physical Layer Physical Layer

Abbildung 4-20. ISO-Schichtenmodell der Kommunikation

Physikalische Ebene
Die physikalische Ebene beschreibt die Art und Weise, wie die Kommunikationsteilnehmer
physikalisch miteinander verbunden sind. Es beantwortet die Frage, ob eine Zweidrahtleitung
verwendet wird, oder ob drahtlos kommuniziert wird. Es werden auch physikalische
Übertragungsparameter festgelegt, wie beispielsweise die Übertragungsgeschwindigkeit.

Data Link Layer (Sicherungsschicht)


Diese Ebene regelt den Zugriff auf das physikalische Medium. Das physikalische Medium ist eine
Ressource, die sich alle Kommunikationspartner teilen müssen. Im Beispiel des Telefonierens ver-
steht man in dem Falle nichts, wenn alle Partner gleichzeitig reden. Verschiedene sogenannte Buszu-
griffsverfahren werden unten vorgestellt.

Network Layer
Der Network Layer (Vermittlungsschicht) ist für den Verbindungsaufbau zuständig. Dazu gehört auch
das Routing, sprich die Suche nach dem richtigen Datenweg hin zum Kommunikationspartner (über
die Adressierung).

Transport Layer
Die Transportschicht ist für die Übertragung der Pakete zuständig. Dazu gehört die Aufgabe, große
Datenmengen in kleinere Einheiten zu verpacken bzw. auf der Gegenseite wieder zusammenzusetzen.
Das ist in dem Fall notwendig, dass die unterliegenden Schichten nur Pakete mit einer begrenzten
Länge (z.B. 256 Byte) versenden können.

Session Layer
Die Steuerungsschicht ist für die Datenflußsteuerung und für die Dialogkontrolle zuständig. Innerhalb
dieser Schicht wird realisiert, dass unterschiedliche Tasks, die auf einem Rechner laufen, mit Tasks auf
anderen Rechnern kommunizieren können. Es besteht damit auf dieser Ebene nicht nur eine Rechner-
zu Rechner-Kommunikation, sondern eine Task- zu Task-Kommunikation. Dazu muß ein entsprechen-
der zusätzlicher Adreßteil (z.B. Portadresse, Service Access Point) angefügt werden.

Presentation Layer
Die Darstellungsschicht ist für die Datenkonvertierung und für die Verschlüsselung der Daten verant-
wortlich. Werden beispielsweise die Daten auf dem physikalischen Medium im Big Endian Datenfor-
mat übertragen, konvertiert diese Schicht die Daten in das jeweilige Hostformat.

123
Kapitel 4. Prozessankopplung

Application Layer
Die oberste Schicht ist schließlich durch die Anwendung selbst definiert.

4.3.3.1.3. Paketaufbau
Jede Ebene definiert ein Datenpaket, welches logisch aus drei Teilen besteht: dem Header, dem Datenteil
und dem Trailer. Für jede Schicht ist das komplette Paket der darüberliegenden Schicht der Datenteil. Das
Paket wird also mit jeder Schicht größer.

Header Trailer
Applikationsdaten
Layer 6 Layer 6

Header Trailer
Daten der Schicht 6
Layer 5 Layer 5

Header Trailer
Daten der Schicht 5
Layer 4 Layer 4

Header Trailer
Daten der Schicht 4
Layer 3 Layer 3

... und so weiter

Abbildung 4-21. Pakete werden in Pakete verpackt

Der Header enthält statische Informationen zum Paket. Diese Informationen helfen dem Empfänger, bereits
beim Empfang der ersten Bytes des Pakets zu entscheiden, ob dieses für ihn relevant ist, oder ob er den
Empfang abbrechen kann. Zu diesen Informationen gehören klassischerweise Adreßangaben (Absender
und Empfänger) und Längeninformationen.
Der Trailer enthält Informationen, die beim Empfang des Paketes gebildet werden können. Typischerweise
sind dies Sicherungsinformationen (Checksum), die anzeigen, ob das Paket korrekt übertragen wurde oder
nicht.

4.3.3.1.4. Adressierung
Prinzipiell kann man zwei Adressierungsarten voneinander unterscheiden:

1. die Quellenadressierung und


2. die Zieladressierung.

Außerdem gibt es neben der klassischen 1:1 Kommunikation noch die 1:n (Multicast) und die 1:any (Broad-
cast) Kommunikation.

124
Kapitel 4. Prozessankopplung





Empfänger kann die Nachricht





nicht empfangen, da das Gateway


die Nachricht nicht in das Subnetz
 
 

Netz C routet (Hop Count = 0).


 
 

 
 

Hop Count=0
 
 

 
 

Netz B
  

Hop Count=1
  

  

Netz A Empfänger der


Nachricht
 
 

 
 

 
 

Sender der
Nachricht
Hop Count=2

Abbildung 4-22. Ausbreitung von Multicastnachrichten

Zieladressierung
Bei der Zieladressierung wird eine Nachricht (Paket, Telegramm) an genau einen - nämlich dem
angegebenen - Empfänger geschickt. Eine Adresse besteht im Regelfall aus zwei Teilen, zum einen der
Stationsadresse des Rechners ( Data Link Layer, z.B. der IP-Adresse bei tcp/ip) und zum anderen aus
einer Dienst-Adresse (Session Layer), die einen Dienst (eine Applikation) auf dem Rechner auswählt.
Diese Dienstadresse heißt Service Access Point oder auch Port- bzw. Socketadresse.

Quellenadressierung
Bei der Quellenadressierung ist der Empfänger dafür verantwortlich, die richtigen Nachrichten zu
empfangen. Der Absender verschickt seine Nachricht einfach über das Kommunikationssystem. Zur
Identifizierung der Nachricht wird im Regelfall eine ID vergeben, die der bzw. die Empfänger der
Nachricht kennen.
Lesedienste (Read-Services) sind im Regelfall unconfirmed, also unbestätigt. Der bzw. die Empfänger
quittieren (mit einer neuen Nachricht) den Empfang nicht. Schließlich kann der Absender der Nach-
richt nicht wissen, wieviele bzw. welche Stationen die Nachricht empfangen sollen. Und damit kennt
er auch nicht die Anzahl der zu erwartenden Quittungen.
Schreibaufträge (Write-Services) auf eine ID werden von der Station, die für die ID verantwortlich ist,
erkannt und ausgeführt. Write-Services können confirmed oder unconfirmed sein.
Da bei der Quellenadressierung nicht Stationen, sondern Objekte zur Identifikation dienen, entspricht
der Adreßraum der Breite der ID. Kommunikationssysteme mit Quellenadressierung eignen sich -
bedingt durch den Broadcast-Charakter - nur für kleine Netze (mit Subnetzen).

1:1 Kommunikation
Klassischer Weise hat eine Nachricht genau einen Absender und genau einen Empfänger. Man spricht
von 1:1 oder auch Punkt zu Punkt Kommunikation. Bei der Zieladressierung gibt der Absender die
Adresse des Empfängers an, bei der Quellenadressierung braucht sich der Absender nicht um die
Adressierung zu kümmern.

125
Kapitel 4. Prozessankopplung

Bei der Quellenadressierung handelt es sich meistens um einen bestätigten Dienst (confirmed service),
d.h. der Absender der Nachricht bekommt vom Empfänger der Nachricht eine Empfangsbestätigung.

Multicast
Beim Multicast wird eine Nachricht an eine Empfängergruppe übermittelt. Technisch einfach ist die
Realisierung von Multicasts bei der Quellenadressierung, hier hat ohnehin der Absender keinerlei Ein-
flußmöglichkeiten darauf, wer die Nachricht empfängt. Für den Absender gibt es daher keinen Unter-
schied zwischen 1:1 Kommunikation und Multicast.
Da Multicasts zu hohen Belastungen in einem Netz, das aus mehreren Subnetzen besteht
(Internet), führen kann, läßt sich in diesem Fall die Ausbreitung kontrollieren (Bild
Ausbreitung von Multicastnachrichten). Die Netzübergangspunkte (Gateways, Router) werden
konfiguriert, um einen Multicast weiterzuleiten oder eben nicht. Außerdem läßt sich der Nachricht
eine Anzahl Hops mitgeben. Diese Anzahl spezifiziert die Anzahl der Gateways, die die Nachricht
weiterleiten dürfen. Jedes Gateway reduziert den Hops-Count um 1. Ist dieser gleich Null, wird die
Nachricht nicht ins folgende Subnetz transportiert.
Bei der Zieladressierung abonniert sich der Empfänger auf die Adresse (er abonniert sich in eine
Multicast-Gruppe). Damit besitzt sein Rechner logisch betrachtet mindestens zwei Adressen, nämlich
eine eindeutige Adresse für die 1:1 Kommunikation und eine im gesamten Netz mehrfach vorhandene
Multicastadresse.

Broadcast
Beim Broadcast wird eine Nachricht an alle (betriebsbereiten und erreichbaren) Teilnehmer des Kom-
munikationssystems übermittelt, Handelt es sich um ein Kommunikationssystem, welches die Quel-
lenadressierung nutzt, ist die Realisierung von Broadcasts relativ simpel. Ähnlich wie bei Multicasts
müssen die Teilnehmer auf die Broadcast-Absender-Adresse horchen. Ebenfalls wie bei Multicasts
ist das Verschicken eines Broadcasts unconfirmed, also ein unbestätigter Dienst (es gibt von den
Empfängern keine Rückmeldung, dass die Daten empfangen wurden).
Bei Kommunikationssystemen, die aus mehreren Subnetzen bestehen können (beispielsweise Ether-
net), werden sicher nur die Teilnehmer erreicht, die an dem Subnetz angekoppelt sind, an dem auch
der Absender der Nachricht angekoppelt ist. Andernfalls würden Broadcasts eine Ausbreitung über
sämtliche Subnetze haben, was in einem großen Netz zu ungewollten Auslastungen führt. Im Regelfall
läßt sich die Ausbreitung von Broadcasts konfigurieren (Stichwort Anzahl der Hops - Gateways -, über
die eine Nachricht hinweg transportiert werden soll).

4.3.3.1.5. Physikalische Verbindungsstrukturen


Prinzipiell finden drei Arten, die Rechner über ein Kommunikationssystem miteinander zu verkoppeln,
Verwendung:

• Busstruktur
• Sternstruktur
• Ringstruktur

126
Kapitel 4. Prozessankopplung

Bus

Busabschluß

Stern Ring

Stern−
koppler

Abbildung 4-23. Physikalische Verbindungsstrukturen

Busstruktur
Die Kommunikationspartner (Teilnehmer) werden über einen Übertragungsweg (Bus) miteinander ver-
bunden. Der Bus wird an seinen beiden (nicht miteinander verbundenen) Enden abhängig von der
physikalischen Ausprägung (durch Abschlußwiderstände) abgeschlossen (bei der Koaxialverkabelung
des Cheapernets sind das jeweils 50 Ohm Widerstände).
Diese Variante ist insbesondere für die gleichberechtigte Kommunikation zwischen den Teilnehmern
geeignet. Zumindest von der physikalischen Struktur her ist keine Station ausgezeichnet. Nachteilig
ist, dass alle Nachrichten über den Bus gehen. Damit ergibt sich eventuell eine hohe Buslast (alle
Teilnehmer müssen sich die eine Leitung teilen). In modernen Kommunikationsnetzen versucht man
diese Last durch intelligente Switches 2 zu verringern.

Sternstruktur
Bei der Sternstruktur sind alle Kommunikationspartner über eine eigene Leitung an eine zentrale Sta-
tion (Sternkoppler) angeschlossen. Diese Variante wird gern im harten Realzeitbereich eingesetzt, da
eine derartige Kommunikationsstruktur leichter auf Einhaltung von Echtzeitanforderungen zu über-
prüfen ist. Je nach Ausprägung erteilt der Sternkoppler den einzelnen Stationen eine Sendeberech-
tigung zu, oder er ist in der Lage, mit den eventuell gleichzeitig ankommenden Anfragen mehrerer
Teilnehmer zurecht zu kommen. Die Last auf den Übertragungsleitungen ist relativ gering, da nur der
Datenverkehr zwischen dem Sternkoppler und der an der jeweiligen Leitung angeschlossenen Station
transportiert wird; die Last innerhalb des Sternkopplers ist allerdings entsprechend hoch.
Dem Sternkoppler kommt eine Vermittlungsaufgabe zu, wenn ein Teilnehmer einem anderen Teilneh-
mer (nicht dem Sternkoppler) eine Nachricht zukommen lassen will (ähnlich dem oben erwähnten
Switch).

Ringstruktur
Jeder Kommunikationsteilnehmer in einem Ring unterhält genau zwei Verbindungen, nämlich zu einer
vorhergehenden und einer nachfolgenden Station. Nachrichten, die eine Station bekommt, die aber

127
Kapitel 4. Prozessankopplung

nicht für diese bestimmt sind, werden einfach am gegenüberliegenden Port (aus Sicht der Nachricht
die nachfolgende Station) weitergereicht.
Vorteil der Ringstruktur ist die Möglichkeit, den Ausfall einer Verbindung zu tolerieren, da jede Stati-
on theoretisch über zwei Wege (vorwärts und rückwärts) zu erreichen ist. Auch kann sich ein höherer
Durchsatz ergeben, da auf sämtlichen Abschnitten gleichzeitig übertragen werden kann. Auf der an-
deren Seite ergeben sich bei Ringstrukturen insgesamt höhere Verzögerungszeiten, bis ein Paket den
Adressaten erreicht.

4.3.3.1.6. Buszugriffsverfahren

Serielle Busse

Zeitmultiplex Frequenzmultiplex

Synchrone Übertragung Ein Teilnehmer Mehrere Teilnehmer


Asynchrone Übertragung
mit zentraler Kontrolle pro Kanal pro Kanal

Kontrollierter Zufälliger
Buszugriff Buszugriff

Zentrale Dezentrale
CSMA/CA CSMA/CD
Buszuteilung Buszuteilung

Abbildung 4-24. Zugriffsverfahren [Färber87]

4.3.3.1.6.1. Zentraler Master


Beim Zugriffsverfahren mit einem zentralen Master koordiniert eine einzelne Station (der Master) die Kom-
munikation. Sie ist damit zuständig für die Busarbitrierung und die Steuerung des lesenden bzw. schreiben-
den Zugriffs über das Kommunikationsmedium. Man kann dieses Zugriffsverfahren auch als einen “logi-
schen” Sternkoppler umschreiben.
Für die Aufgabe der Busarbitrierung bei einem zentralen Master gibt es verschiedenste Lösungsvarianten.
Zum einen kann der zentrale Master die angeschlossenen Teilnehmer pollen (er sendet den Teilnehmern
zyklisch ein Paket, welches die Teilnehmer beantworten), oder aber auch jedem Teilnehmer ein festes Zeit-
fenster geben (TDMA=Time Division Multiple Access).
Unter Sicherheitsaspekten betrachtet fällt auf, dass bei Ausfall des Masters das gesamte Kommunikations-
system ausgefallen ist.

128
Kapitel 4. Prozessankopplung

Realzeiteigenschaften: Durch den mit zentralem Master möglichen synchronen Ablauf ergibt sich ein
berechenbares Verhalten. Damit ist ein derartiges Verfahren auch für Systeme mit harten Realzeitan-
forderungen geeignet.

4.3.3.1.6.2. Token Protokoll


Beim Token Protokoll handelt es sich um ein Verfahren der dezentralen Buszugriffskontrolle. Die Stationen
am Kommunikationsmedium können prinzipiell alle auf das Kommunikationssystem zugreifen, jedoch darf
nur der Teilnehmer, der den sogenannten Token hat, den Bus nutzen. In dieser Zeit kann er Nachrichten an
andere Stationen verschicken. Die angesprochenen Stationen quitieren im Regelfall den Nachrichtenemp-
fang.
Der Token selbst ist eine spezielle Nachricht, die über das Kommunikationssystem verschickt wird. Die
Station, die den Token hat, darf diesen nur eine endliche (konfigurierte) Zeit behalten. Danach muß sie
den Token an ihren Nachfolger weitergeben. Der Token bzw. die Tokenweitergabe erzeugt zwischen den
Kommunikationsteilnehmern einen logischen Ring.
Dieses Verfahren kann den Ausfall einer oder mehrerer Stationen verkraften, ohne dass das gesamte Kom-
munikationssystem als ausgefallen betrachtet werden muß.

Realzeiteigenschaften: Tokenprotokolle scheinen zwar auf den ersten Blick echtzeitfähig zu sein, treten
jedoch Fehler auf, weisen sie zumeist kein deterministisches Verhalten mehr auf. Als Fehler bei der
Kommunikation können beispielsweise der Token-Verlust oder auch der doppelte Token vorkommen.

4.3.3.1.6.3. CSMA/CD
Das Buszugriffsverfahren Carrier Sense Multiple Access/Collision Detection (CSMA/CD) ist vor allem als
Buszugriffsverfahren bei Ethernet bekannt geworden. Liegt bei einer Station ein Sendewunsch vor, hört die
Station zunächst das Kommunikationsmedium ab, ob es frei ist, oder ob gerade eine Übertragung läuft. Ist
das Medium frei, wird das Paket übertragen. Da es vorkommen kann, dass gleichzeitig zwei Stationen ein
Paket auf den Bus legen, muß die Station den Bus abhören, ob es zu einer Kollision gekommen ist oder
nicht. Wird eine Kollision entdeckt, zieht sich die sendende Station vom Bus zurück und versucht zu einem
späteren Zeitpunkt die Nachricht erneut zu versenden. Die Wartezeit bis zum erneuten Versuch ist dabei
von Teilnehmer zu Teilnehmer unterschiedlich lang und wird zufällig bestimmt.

Realzeiteigenschaften: Das Argument, das lange Zeit gegen Ethernet in der Automatisierungstechnik
vorgebracht wurde, lautet, dass CSMA/CD nicht realzeitfähig ist. Der große Erfolg der Technologie
aber in der Bürokommunikation, verbunden mit niedrigen Preisen für die Anschaltung sorgt dafür, dass
immer mehr darüber nachgedacht wird, Ethernet mit CSMA/CD auch in der Automatisierungstechnik
zu verwenden. Methoden, Ethernet echtzeitfähig zu machen, werden weiter unten beschrieben.

4.3.3.1.6.4. CSMA/CA
Wie bei CSMA/CD hört auch beim Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) die
sendewillige Station, ob der Bus frei oder belegt ist. Ist der Bus frei, sendet die Station und hört gleichzeitig
auf dem Bus mit. Von den beiden möglichen Pegelzuständen auf dem Bus (0 und 1) ist die 0 dominant
und die 1 rezessiv. Das bedeutet: wenn eine Station eine 0 sendet und gleichzeitig eine andere Station

129
Kapitel 4. Prozessankopplung

eine 1, setzt sich die 0 durch und die Stationen empfangen eine 0. Empfängt eine sendende Station ein
anderes Bitmuster, als sie aussendet, zieht sie sich vom Bus zurück. Damit hat es zwar eine Kollision auf
dem Bus gegeben, die Station aber, die das dominante Bitmuster sendet, bricht nicht ab, sondern kann das
gesamte Paket verschicken. Wichtig für CSMA/CA sind also die bitweise Arbitrierung des Busses und
kurze Leitungen. Bei langen Leitungen werden die Leitungslaufzeiten so lang, dass die gesendeten Bits
nicht synchron bei den einzelnen Stationen ankommen.
CSMA/CA wird insbesondere beim CAN-Bus (siehe Abschnitt CAN) eingesetzt. Die ersten übertragenen
Bits stellen dabei den sogenannten Identifier (Quellenadressierung) dar. Damit ergibt sich eine Priorisierung
der Identifier. Je kleiner ein Identifier ist, desto sicherer wird er übertragen.

Realzeiteigenschaften: CSMA/CA ist realzeitfähig. Die höchstprioren Daten werden ohne zeitliche
Verzögerung übertragen. Allerdings gibt es keinerlei Garantie, dass auch niedrigpriore Daten
übertragen werden. Werden also hochpriore Daten (z.B. bedingt durch ein fehlerhaftes Programm)
ständig gesendet, gibt es keinerlei Übertragung der niederprioren Nachrichten.

4.3.3.1.7. Charakterisierung der Feldbusse


Bei Feldbussen, die man auch als Peripheriebusse bezeichnen kann, handelt es sich um serielle Kommuni-
kationsysteme, die besondere Eigenschaften im Bereich des Echtzeitverhaltens (Realzeitkommunikations-
systeme) aufweisen.
Vorteile:

• Entfernung Steuerung - technischer Prozess


Bussysteme ermöglichen die räumliche Trennung von technischen Prozess und Steuerung. Welche Ent-
fernungen überbrückt werden können, hängt dabei auf der einen Seite von den Anforderungen und auf
der anderen Seite von dem ausgewählten Kommunikationssystem ab.

• hardwaretechnisch einfache Prozessankopplung


Durch die Verwendung standardisierter I/O-Module ergibt sich eine hardwaretechnisch einfache Pro-
zessankopplung. In der Steuerung selbst wird ein Feldbus-Kommunikationsmodul benötigt, welches mit
dem Bus gekoppelt ist. Am technischen Prozess werden die Ein-/Ausgabemodule auf der einen Seite mit
dem technischen Prozess und auf der anderen Seite mit dem Bus verbunden.
Die Aufwandseinsparungen auf der Hardwareseite werden bei vielen Bussystemen auf der Softwareseite
wieder wettgemacht. Erhöhter Aufwand entsteht nämlich in der Software durch eine komplizierte Konfi-
guration der Standardmodule.

• Einsparungen im Bereich Verkabelung


Aufwendige Verkabelung zwischen Steuerung und technischem Prozess kann zugunsten der Busleitun-
gen entfallen.

130
Kapitel 4. Prozessankopplung

Client Server

Request

Indication

Response

Confirmation

Abbildung 4-25. Kommunikationsprimitive

Bei Feldbussystemen findet man insbesondere die folgenden Kommunikationsmodelle:

Client Server Kommunikation


Bei diesem Modell fordert (Request) ein Client einen Dienst bei einem Server an. Dienste können
dabei sowohl Lesen und Schreiben, als auch Dienste zur Konfiguration und Parametrierung sein.
Beim Client/Server Modell unterscheidet man vier Dienstprimitive:
1. Request
2. Indication
3. Response
4. Confirmation

Die Primitive Request und Confirmation findet man auf der Seite des Clients, während die Primitiven
Indication und Response auf der Seite des Servers zu finden sind. Der Client startet einen Request.
Dazu wird dem Server ein Datenpaket (Telegramm) geschickt. Innerhalb des Servers führt dies zu
einer Indication: der Server hat einen Auftrag zu bearbeiten. Hat der Server den Auftrag bearbeitet,
bereitet er eine Response auf. Diese Response übergibt er dem Kommunikationsstack (der Kommuni-
kationsstack ist die Implementierung des Kommunikationsprotokolls). Ein Telegramm wird generiert
und dem Client übermittelt. Der Client wird über den Eingang der Antwort mittels einer Confirmation
informiert.
Leider wird in den Protokollspezifikationen das vorgestellte Modell nicht immer sauber eingehalten.
Das führt dazu, dass auch der Client Indications empfangen kann. Beim Feldbusprotokoll PROFIBUS
FMS beispielsweise lösen sowohl Ereignisse auf dem Kommunikationsmedium (z.B. Fehlerzustände)
Indications aus, ebenso kann der Server mittels eines sogenannten Information Report von sich aus
(ohne Aufforderung) Daten an den Client schicken.

Publisher Subscriber Modell


Bei diesem mehr im Aktor/Sensor-Bereich vorkommenden Kommunikationsmodell gibt es bezüglich
einer Variablen (eines Objektes) einen Publisher und keinen, einen oder mehrere Subscriber. Der Pu-
blisher besitzt quasi das Orginal des Objektes und er übermittelt eine Kopie des aktuellen Wertes

131
Kapitel 4. Prozessankopplung

entweder periodisch an seine Subscriber oder bei jeder Objektänderung. Die Aktivität geht dabei vom
Publisher aus.
Ein Publisher/Subscriber Modell bietet sich für Kommunikationssysteme an, die die Quellenadressie-
rung benutzen. Dabei kann entfallen, dass sich ein Subscriber beim Publisher anmelden muß, um einen
Wert übermittelt zu bekommen.

Master Slave Kommunikation


Die Master/Slave Kommunikation ist quasi die Umkehrung der Publisher/Subscriber Kommunikation,
da hier die Aktivität vom Master ausgeht. Der Master fordert nämlich (polling) von seinen Slaves die
notwendigen Daten an.

Werden Daten periodisch an einen Master oder einen Subscriber übermittelt, gibt es zwei zu unterscheiden-
de Prinzipien des Datenmanagements: Ein Übertragung kann queued oder buffered sein:

queued
Die ankommenden Daten werden in eine Warteschlange nach dem FIFO-Prinzip eingereiht. Das be-
deutet, dass kein Wert verloren geht.

buffered
Die ankommenden Daten werden in eine Warteschlange der Tiefe 1 (also ein Puffer, der genau ein Da-
tum aufnehmen kann) eingetragen. Trifft ein neues Datum ein, überschreibt dieses den vorhandenen
Wert. Damit gehen “ältere” Werte verloren, unabhängig davon, ob die Werte bereits gelesen (konsu-
miert) wurden oder nicht.

Oftmals werden Daten (insbesondere ist dies bei der zyklischen Übertragung von Daten im Buffered-Betrieb
notwendig) mit einem Qualitätsmerkmal versehen:

• Alter und/oder
• Gültigkeit.

4.3.3.2. Feldbus-Übersicht
Feldbussysteme werden heute weniger aus technischen, als vielmehr aus politischen Gründen ausgewählt.
Eine kleine Auswahl unterschiedlicher Feldbussysteme

• PROFIBUS (in den Ausprägungen FMS, DP, DP/V1, DP/V2 und PA)
• CAN (stark in der Automobilindustrie)
• Interbus-S
• ASI
• LON

Im folgenden werden stellvertretend CAN und PROFIBUS DP etwas genauer vorgestellt.

132
Kapitel 4. Prozessankopplung

4.3.3.2.1. CAN

Station
1

Station
2
Station bricht ab

Abbildung 4-26. Buszugriffsverfahren beim Controller Area Network

1981 von Bosch und Intel entwickelt hat sich CAN in weiten Bereichen des Automobilbaus durchgesetzt.
Durch die sehr preiswerten Anschaltungen findet man CAN zunehmend auch in der Prozessautomatisie-
rung. CAN bietet Übertragungsraten von bis zu 1 Mbit/s. In den geringen Datenblocklängen von bis zu 8
Byte können nur kurze Nachrichten übermittelt werden, die jedoch geringe Datenübertragungszeiten benöti-
gen. CAN verwendet die Bus-Topologie, entweder als Zweidrahtleitung oder in Form von Lichtwellenleiter.
Für die Busanschaltungen existieren preiswerte integrierte Schaltungen.

Startfeld Arbitrierungsfeld Kontrollfeld Datenfeld CRC−Feld ACK−Feld Endefeld Ruhe


1bit 11+1bit 6bit 0..64bit 15+1bit 1+1bit 7bit 3bit

Abbildung 4-27. Aufbau eine CAN-Telegramms

Das bitorientierte Rahmenformat einer CAN-Nachricht ähnelt dem Format des HDLC-Protokolls. Für den
CAN-Bus sind folgende Frames definiert:

• Data Frame: Datenübertragung


• Remote Frame: Anforderung von Daten
• Overload Frame: Flußregelung
• Error Frame: Fehlererkennung

Außerdem wird bei CAN ein sogenanntes Bitstuffing durchgeführt. Auf 5 gleichwertige Bits folgt ein so-
genanntes Stuffing Bit. Damit ist die Telegrammlänge abhängig von den übertragenen Daten.
Die empfangenen Stationen müssen ein Telegramm quittieren. Wurde beim Empfang des Telegramms ein
Fehler festgestellt, tragen die Stationen, die den Fehler diagnostiziert haben, im ACK-Feld eine 0 ein. Da
die sendende Station das eigene Paket mithört, erkennt sie die fehlerhafte Übertragung. Sie versucht das
Paket erneut zu versenden.
Damit hängt zum einen die Anzahl der gesendeten Bits vom Telegramminhalte ab (Bitstuffing) und das Bit
des ACK-Feldes hängt davon ab, ob das Telegramm von allen Stationen korrekt empfangen werden konnte
oder nicht.
Auf Applikationsebene des OSI-Schichtenmodells sind zwei Protokolle spezifiziert:

133
Kapitel 4. Prozessankopplung

1. CAN Open (Europa)


2. DeviceNet (Nord-Amerika)

Tabelle 4-2. CAN: Technische Daten

Topologie Bus
Übertragungsrate (Brutto) theoretisch 1 Mbit/s (effektiv 500 kBit/s) bei 40 m,
125 kBit/s bei 500 m, 50 kBit/s bei 1000m
Übertragungsrate (Netto) Reaktionszeit abhängig von Priorität, max. 134 µs.
Teilnehmeranzahl physikalisch (Knoten): ca. 30, logische
(Komm.partner): Standard CAN 2032, Extended
CAN 500 Millionen. Bemerkungen: 2032
Datenobjekte, die auf ca. 30 Teilnehmer zu je ca. 60
Objekten zusammengefaßt werden
Buslänge Ohne Repeater: 1000 m
Kommunikationsstruktur Multimaster
Max. Datenfeldlänge 8 Byte
Buszugriffsverfahren (MAC) CSMA/CA
Dienste zyklisch : nein, azyklisch : ja
Protokollebenen 1,2,7
Sonstiges Prioritätsgesteuerte, bitweise Busarbitrierung
Zeitverhalten deterministisch
Restfehlerwahrscheinlichkeit Hammingdistanz 6, Restfehlerwahrscheinlichkeit
10-13

4.3.3.2.2. PROFIBUS
PROFIBUS als Feldbus gibt es in gegenwärtig fünf unterschiedlichen Ausprägungen:

1. FMS
2. DP
3. DP/V1
4. DP/V2
5. PA

Die Varianten verwenden die gleiche Schicht 2, ein Token-Protokoll.

Tabelle 4-3. PROFIBUS: Technische Daten

Ausprägungen FMS, DP, DP/V1, DP/V2, PA


Topologie Bus
Übertragungsrate (Brutto) bis 12 Mbit/s

134
Kapitel 4. Prozessankopplung

Teilnehmeranzahl physikalisch (Knoten): 32 (ohne Repeater),


logische (Komm.partner): 125
Kommunikationsstruktur Multimaster, Master/Slave
Max. Datenfeldlänge 246 Byte
Buszugriffsverfahren (MAC) Token Protokoll
Protokollebenen 1,2,7
Zeitverhalten bedingt deterministisch

4.3.3.2.2.1. FMS - Fieldbus Message Specification


Die erste Applikationsschicht, die für PROFIBUS definiert wurde, war die Fieldbus Message Spezifikation.
Abgeleitet von MMS (Manufacturing Message Specification) basiert sie auf einem Client/Server Modell.

Server Client
VFD

Objekt
(z.B. Temperatur)

Gerät
Verbindung zur VFD
Zugriff auf Objekte

Abbildung 4-28. FMS-Kommunikationsmodell beim PROFIBUS

Der Client kann dabei auf Objekte (z.B. ein Temperaturwert oder der Meßbereich eines Sensors) in einem
Server zugreifen. Innerhalb des Servers (des Gerätes) sind die Objekte gruppiert. Eine derartige Objekt-
gruppe wird VFD, virtual field device genannt.
Damit ein Client auf die Objekte in einer VFD zugreifen kann, muß er eine Verbindung aufbauen (eine
Verbindung endet damit nicht in einem Gerät, sondern in einer VFD). Beim Aufbau der Verbindung über-
prüft der Server die Verbindungsparameter (z.B., ob der Server für die angesprochene VFD auch genau die
Dienste zur Verfügung stellt, die der Client später verwenden möchte, oder ob der Client überhaupt auf die
VFD zugreifen darf).
Zum Zugriff auf die Objekte stehen diverse, vom Objekt-Typ abhängige Dienste zur Verfügung. Sogenannte
“Simple Variables” (z.B. Integer-Variablen) können gelesen und beschrieben werden. Domains kann man
down- und uploaden, PI’s kann man starten und stoppen. Das “reine” Client/Server Modell, bei dem jegliche
Aktion vom Client ausgeht, wird mit dem Dienst “Information Report” durchbrochen. Hier bekommt der
Server die Möglichkeit, unaufgefordert dem Client eine Nachricht zu senden.
Betrachtet man einen Server bzw. ein Gerät genauer, erkennt man, dass neben dem Kommunikationssy-
stem im Gerät auch eine Applikation abläuft. Die Objekte selber, auf die zugegriffen wird, müssen in der
Applikation instanziiert werden, in der Kommunikation aber parametriert (angemeldet) werden.
Damit muß vom System-Integrator bzw. Programmierer folgende Konfiguration durchgeführt werden:

135
Kapitel 4. Prozessankopplung

1. Layer 2 Parametriertung
Hier werden die Schicht 2 Parameter wie beispielsweise Baudrate, Token Umlaufzeit oder Token Hal-
tezeit parametriert. Die diversen (ca. 20) Schicht 2 Parameter sind dabei untereinander abhängig. Wird
beispielsweise als Baudrate 500 kBit gewählt, wird eine andere Target-Rotation-Time definiert, als bei
9.6 kBit.

2. Verbindungskonfiguration
Die Verbindungsparameter zwischen einem Server und den Clients müssen exakt stimmen. Dies betrifft
insbesondere auch die Leistungsparameter, die beispielsweise spezifizieren, wieviele Dienste parallel
über die Verbindung bearbeitet werden dürfen.

3. Objekte
Objekte müssen in der Applikation mit ihrem Typ und ihrer Adresse angelegt werden. Außerdem kön-
nen Objekte Attribute, wie beispielsweise ein Passwort, bekommen. Da auf Server Seite Passwörter mit
den Objekten assoziiert sind, auf Client Seite aber mit der Verbindung, müssen bei unterschiedlichen
Passwörtern für Objekte innerhalb einer VFD entsprechend viele Verbindungen aufgemacht werden,
wie unterschiedliche Passwörter existieren.

4.3.3.2.2.2. DP - Dezentrale Peripherie


Bei PROFIBUS-DP handelt es sich um ein Master/Slave Bussystem. Auf Schicht 2 Ebene des
OSI-Referenzmodells pollt der Master ständig seine Slaves. Ein Slave ist genau einem Master
zugeordnet, ein Master aber kann mehrere Slaves haben. An einem derartigen PROFIBUS-Netz
können mehrere logische DP-Netze (bei gleichzeitigem Betrieb von PROFIBUS FMS) betrieben
werden. Das heißt, es gibt mehrere Master und die ihnen jeweils zugeordneten Slaves (Bild
Mehrere logische DP-Netze an einem Strang).

Master 1 Master 2

PROFIBUS

Slave 2
Slave 1
Slave 3 Slave 4

Abbildung 4-29. Mehrere logische DP-Netze an einem Strang

136
Kapitel 4. Prozessankopplung

Speicher im DP−Master

Input Output Input Output Input Output

Slave 1 Slave 2 Slave 3

Input Output Input Output Input Output

Prozeßperipherie Prozeßperipherie Prozeßperipherie

Abbildung 4-30. Abbildung der DP-Kommunikation

Die Applikation selbst sieht vom Kommunikationssystem nur einen Speicherbereich, der logisch in mehre-
re Bereiche geteilt ist (Bild Abbildung der DP-Kommunikation). Jeder konfigurierte Slave wird dabei durch
einen solchen Speicherbereich repräsentiert. Ein Slave-Speicherbereich selbst ist logisch nochmals in einen
Eingabe- und einen Ausgabeteil unterteilt. Das Kommunikationssystem sorgt dafür, dass vom Slave alle
Eingangs-Zustandsgrößen ständig gelesen werden und in den Speicherbereich im Master für die entspre-
chenden Slaves geschrieben werden. Umgekehrt wird zyklisch der Ausgabebereich für einen Slave auf dem
Master zum Slave hin kopiert, der entsprechend diesen Daten seine Ausgabekanäle setzt.
Die Applikation sieht damit die Kommunikation nicht mehr, sondern greift einfach lesend (buffered, nicht
queued) und schreibend auf die entsprechenden Speicherbereiche zu. Da die Applikation auf eine Kopie
zugreift und dabei zunächst nichts über die Qualität der Daten (z.B. Alter) weiß, sind zusätzlich noch Dia-
gnosen definiert, die der Master der Applikation (auf dem Master) zur Verfügung stellt (z.B. in Form eines
Interrupts). Inhalt einer derartigen Diagnose könnte sein, dass ein spezifischer Slave nicht mehr erreichbar
ist oder dass ein Slave Parametrierdaten erwartet, bevor auf seine Daten zugegriffen werden kann.
Zur Parametrierung eines Slaves gibt es einen Konfigurationsdatensatz und einen Parametrierdatensatz.
Während der Konfigurationsdatensatz standardisiert ist, handelt es sich bei den Parametriertdaten um
einen herstellerspezifischen Datensatz. Die Konfigurationsdaten informieren über Art und Anzahl der
Ein-/Ausgabekanäle eines Slaves. Die Parametrierdaten stellen beim Slave spezifische Variablen (z.B.
Meßbereich) ein.
Während der vergleichsweise einfache Zugriff auf die Variablen der Ein-/Ausgabebaugruppen positiv zu
bewerten ist, ist es auf der anderen Seite negativ, dass nur der Master - und damit als Steuerung - Zugriff
auf die Informationen im Netz hat. Ist eine Visualisierung in der Steuerung nicht realisiert (oder nicht
realisierbar, da es sich um eine einfache SPS handelt), kann diese auch nicht mit endlichem Aufwand zur
Verfügung gestellt werden.

4.3.3.2.2.3. DP/V1
Aufgrund der eingeschränkten Möglichkeiten, die sich durch den prinzipiell rein zyklisch ausgerichteten
Datenaustausch ergeben, erweitert DP/V1 die DP-Funktionalität noch um einen azyklischen Datenverkehr.
Dabei können die azyklischen Dienste auch von einem zweiten Master genutzt werden, der bereits bei DP
(als Konfigurationsstation) spezifiziert war.

137
Kapitel 4. Prozessankopplung

4.3.3.2.2.4. PA - Process Automation


PA basiert auf DP/V1 und ist darüberhinaus für den Ex-Bereich (Explosionsgeschützten Bereich) geeinget
(dank IEC-Physik). Über sogenannte Profile werden Geräteklassen standardisiert:

• Innerhalb des Gerätes kann ein Directory ausgelesen werden, dass sämtliche Objekte des Gerätes enthält.
• Es sind die Function Blocks definiert, die sich im Gerät befinden können.
• Es sind die Function Block Parameter spezifiziert.

Über das Direktory lassen sich die erwähnten Informationen aus dem Gerät auslesen. Notwendig ist diese
Spezifikation für die Erstellung verteilter Applikationen.

• Ein Gerät läßt sich identifizieren und automatisch konfigurieren (eventuell ist eine GSD - Geräte Stamm-
daten Datei dazu notwendig, die aus einer externen Datenbank zu holen ist).
• Geräteklassen sind definiert, die Attribute der Geräte im Profil festgelegt.

4.3.3.2.3. Ethernet und TCP/IP im Feldbereich


Ethernet ist nicht deterministisch und damit im Bereich der Echtzeitsysteme nicht einsetzbar. Die weite Ver-
breitung jedoch im Bereich der Bürokommunikation erzwingt gegenwärtig ein Umdenken, da der Einsatz
von Ethernet erhebliche Vorteile mit sich bringen würde:

• Preiswerte Busanschaltungen.
• Hohe Übertragungsraten (100Mbit und Gigabit-Ethernet).
• Rasche Weiterentwicklung der Anschaltungen.
• Durchgängige Übertragungsprotokolle von der Betriebsebene über die Leit- und Führungsebene bishin
in den Feldbereich.
• Standardisierte und interoperable Übertragungsprotokolle!

Die fehlenden Realzeiteigenschaften des Ethernet-Zugriffsverfahrens (CSMA/CD) rühren daher, dass es


sich um ein asynchrones Zugriffsverfahren handelt, bei dem im Falle einer Kollision Pakete nach einer
zufälligen Zeitspanne neu gesendet werden müssen. Da eine hohe Netzlast zu vielen Kollisionen führt,
kommt es zu hohen, nicht vorhersagbaren Verzögerungszeiten bei der Übertragung der Daten.

138
Kapitel 4. Prozessankopplung

Priorisierung und
Switch
Scheduling der
Sternkoppler
Nachrichten

Ethernet
CSMA/CD

Feldgerät Feldgerät Feldgerät

Abbildung 4-31. Realzeitfähige Ethernetstruktur

Echtzeitverhalten kann man dadurch erreichen, dass man

• für eine niedrige Buslast sorgt (kleiner 30 Prozent) oder


• eine spezielle Hardwarestruktur verwendet.

Bild Realzeitfähige Ethernetstruktur gibt eine derartige Hardwarestruktur wieder. Die einzelnen Feldgeräte
sind sternförmig an einen intelligenten Ethernetswitch angekoppelt. Auf den einzelnen Strängen zwischen
dem Switch und den Feldgeräten kann es nur zu einer Kollision kommen, wenn Switch und Feldgerät
gleichzeitig senden wollen. Schließlich handelt es sich um eine Punkt zu Punkt Verbindung. Der Switch al-
lerdings muß in der Lage sein, mit mehreren Anforderungen (auf jedem Strang eine) gleichzeitig zurecht zu
kommen und außerdem - nach entsprechenden Regeln (Prioritäten) - mehrere Pakete von unterschiedlichen
Absendern, die für ein Zielgerät bestimmt sind, in einer sinnvollen Reihenfolge weiterzuleiten.
Ein auf Fast-Ethernet (100MBit) basierendes Feldbussystem ist der Foundation Fieldbus.
Ethernet im Feldbereich gibt den Durchgriff von einem Rechner am Ethernetstrang hin zum einzelnen
Feldgerät. Ist beispielsweise im Feldgerät ein HTTP-Server integriert, kann der Gerätezustand mit einem
normalen Browser abgefragt und gegebenenfalls auch verändert werden. Ethernet im Feldbereich eröffnet
insbesondere auch ganz neue Möglichkeiten für die Remotewartung der Anlagen. Der Anlagenhersteller
oder eine Wartungsfirma können periodisch oder nach Auftreten eines Fehlers, über den sie über Ethernet
quasi automatisch informiert werden, in die Anlage reinsehen und Wartungsarbeiten durchführen, ohne
wirklich vor Ort sein zu müssen.
Auf der anderen Seite stellt der Anschluß einer Anlage an das Internet die Anlagenbetreiber vor bisher
unbekannte Sicherheitsprobleme. Der Zugriff auf die Anlage darf nur für authorisierte Personen bzw. über
authorisierte Rechner möglich sein. Darüberhinaus sind Firmennetze über Firewalls abgesichert, deren Auf-
gabe es ist, den Datenaustausch zwischen Firmennetz (Intranet, und damit auch Anlage) und Internet zu
kontrollieren.

4.3.3.3. Function Blocks


Moderne Feldbusse ermöglichen jedoch nicht nur die einfache Übertragung von Daten, sie spezifizieren
bzw. definieren auch direkt Verfahren und Mechanismen zur Erstellung verteilter Echtzeitapplikationen
über sogenannte Function Blocks.

139
Kapitel 4. Prozessankopplung

Auf Function Blocks werden standardisierte Anwendungsfunktionen abgebildet, wobei die Function Blocks
direkt die Kommunikationsfähigkeit besitzen.

Fußnoten
1. Dynamische RAM-Bausteine sind zeilenweise organisiert. Bei einem Zugriff wird jeweils eine ganze
Zeile in ein Ausgaberegister geladen und aus dieser Zeile das Bit an der ausgewählten Spalte aus-
gegeben. Bei konsekutiven Zugriffen muß die Zeile nicht erst in das Ausgaberegister geladen werden,
sondern die Spalte kann direkt adressiert werden.
2. Intelligente Switches teilen ein Netz in mehrere Segmente auf und transportieren die Nachrichten zwis-
chen den Segmenten. Dabei lernen sie aber, welche Stationen in welchem Segment sind und übermitteln
nur dann eine Nachricht in ein Segment, wenn sich dort eine am Empfang interessierte Station befindet.

140
Kapitel 5. Programmierung
Der folgende erste Abschnitt des Kapitels führt in Programmiermethoden und Sprachen ein, die bei der Soft-
wareerstellung für die Steuerung technischer Prozesse verwendet werden. Außerdem werden ausgewählte
Programmiertechniken wie beispielsweise die Synchronisation mehrerer Rechenprozesse untereinander be-
handelt.

5.1. Programmiersprachen
Abhängig vom Einsatzbereich und von den Anforderungen werden unterschiedliche Programmiersprachen
verwendet:

Entscheidungstabellen
Besonders gut für harte Realzeitprobleme eignen sich Entscheidungstabellen. Entscheidungstabellen
realisieren letztendlich nichts anderes als die Automatentafel eines Zustandsautomaten.

Ereignis Ausgabe

X/Y

1 2 Mealy−Automat

Zustand Transition

Ausgabe Ereignis
X

1/Y 2/Z Moore−Automat

Zustand Transition

Abbildung 5-1. Elemente eines Zustandsautomaten

Zustandsautomaten bestehen aus einer Anzahl Zuständen, Ereignissen, Transitionen und Ausgaben
(siehe Abbildung Elemente eines Zustandsautomaten). Ein System befindet sich dabei immer in genau
einem Zustand. Das Eintreffen eines Ereignisses löst dann einen Zustandsübergang vom aktuellen in
einen Folgezustand aus, wobei die Transition den Folgezustand definiert.
Bei den Zustandsautomaten mit Ausgaben - im Gegensatz zu den endlichen deterministischen Auto-
maten - unterscheidet man den Mealy vom Moore-Automaten. Beim Mealy-Automaten ist die Aus-
gabe mit der eigentlichen Transition assoziiert, beim Moore-Automaten mit dem Zustand. Ein Mealy-
Automat läßt sich in einen Moore-Automaten konvertieren und vice versa.

141
Kapitel 5. Programmierung

A/g
2 A B C
C/y 1 2/g − −
1
B/u 2 − 3/u 1/y
3 − − 1/a
C/a 3

Abbildung 5-2. Zustandsautomat und Automatentafel

Die Automatentafel des Zustandsautomaten ist die tabellarische Repräsentation desselben. Dazu exi-
stiert im einfachsten Fall für jedes mögliche Ereignis eine Spalte in der Tabelle und für jeden möglichen
Zustand eine Zeile. Die Tabellenfelder schließlich enthalten - im Falle des Mealy-Automaten - den Fol-
gezustand und die beim Übergang von einem in den anderen Zustand durchzuführende Ausgabe.
Zustandsautomaten eignen sich zur Modellierung und Programmierung von Folgeprozessen.
Entscheidungstabellen lassen sich nicht nur in Software, sondern auch in Hardware realisieren (als
sogenanntes ROM-Steuerwerk). Durch die einfache Strukturierung ist ein Realzeitnachweis durch-
führbar, durch die einfachen Verarbeitungsschritte (keine mathematische Operationen) ist eine zügige
Abarbeitung gewährleistet.
Zusammengefaßt ergeben sich die folgenden Kennzeichen:

• In HW oder durch ein einfaches Laufzeitsystem realisierbar.


• Geeignet für digitale Ein-/Ausgänge, aber ungeeignet für analoge Prozessdaten.
• Übersichtlich.
• Ohne dedizierte Programmierkenntnisse programmierbar.
• Sicher, da eine Überprüfung sowohl des Abdeckungsgrades als auch der Laufzeit (deterministisch)
möglich ist.
• Zustandsautomaten können entweder (klassisch) durch die Ereignisse getriggert werden, ebenso
aber auch durch das Scheduling (z.B. jede Millisekunde).
• Entscheidungstabellen eignen sich (nur) für kleine, überschaubare Systeme.

Sequential Function Charts


Als eine in der IEC 6 1131 definierte Sprache zur Programmierung Speicherprogrammierbarer Steue-
rungen (SPS) sind die Sequential Function Charts ebenfalls an die Zustandsautomaten angelehnt. Mit
einem grafischen Editor lassen sich die Elemente
• Step
• Transition
• Action
• Branch

spezifizieren.

142
Kapitel 5. Programmierung

Leiter-Diagramme (Ladder Diagrams)


Ebenfalls in der IEC 6 1131 definiert ist die Programmierung einer SPS mit Hilfe von Ladder Dia-
grams. Es handelt sich um eine grafische Programmiersprache, die sich insbesondere zur Lösung von
Aufgaben, für die sich Boolsche-Logik anbietet, eignet. Die Sprache setzt sich aus Standard-Logik-
Blöcken zusammen, die verschaltet werden können.

Instruction List
Als eine Form der Assembler-Programmierung ermöglichen die Instruction Lists hardwarenahe Pro-
grammierung der SPS. Damit lassen sich schnelle und effiziente Steuerungsprogramme schreiben. Die
Instruction Lists sind ebenfalls in der IEC 6 1131 spezifiziert.

Function Blocks
Eine vor allem in Europa akzeptierte Programmiermethode zur Programmierung einer SPS sind die
Function Blocks. Die Definition der grafischen Programmiersprache findet sich in der IEC 6 1131.
Ein Funktions-Block kann einen oder mehrere Eingänge und einen oder mehrere Ausgänge haben.
Abhängig vom programmierten bzw. parametrisierten Algorithmus werden die Ausgänge aufgrund
der Eingangssignale und interner Zustände berechnet. Function Blocks eignen sich vor allem für die
Steuerung von Prozessen, bei denen analoge Zustandsgrößen verarbeitet werden. Es werden drei Arten
von Funktionsblöcken unterschieden:
• Standard-Funktionsblöcke
• Abgeleitete Funktionsblöcke und
• Programm-Blöcke.

Beispiele für Standard-Funktionsblöcke, bei denen die IEC 6 1131 den Algorithmus normiert hat,
beinhalten mathematische Funktionen, logische Funktionen und Zeitsteuerungen.
Bei den abgeleiteten Funktionsblöcken kann der Entwickler den Algorithmus selber programmieren.
Dieses kann wiederum in einer der fünf Programmiersprachen geschehen. Unter Umständen ist es auch
erlaubt, dass abgeleitete Funktionsblöcke keine Eingänge oder Ausgänge besitzen.
Die letzte Gruppe der Funktionsblöcke, die Programm-Blöcke, dient einzig zur Strukturierung der
Aufgabe.

Structured Text
Structured Text ist eine Pascal-ähnliche Programmiersprache zur Programmierung einer SPS, die als
fünfte Sprache in der IEC 6 1131 definiert ist. Sie enthält Standard-Vergleichselemente und Schleifen.
Damit lassen sich komplexe mathematische Berechnungen durchführen (die beispielswese zu komplex
sind, um dazu mathematische Funktionsblöcke zu verwenden).

Assembler
Durch die Natur der Aufgabenstellung findet insbesondere bei harten Realzeitsystemen oft Assembler
als Programmiersprache Verwendung.

C
Die Programmiersprache allgemein und für Realzeitsysteme im besonderen ist C. C eignet sich beson-
ders aus den folgenden Gründen:
• Effiziente Codeerzeugung
• Weite Verbreitung
• Hardwarenahes Programmieren ist möglich
• Input-/Output-Routinen sind nicht in der Sprache verankert

143
Kapitel 5. Programmierung

• Compiler gibt es für beinahe alle Mikroprozessoren, vom 8-Bit-Controller bis hin zum
64bit-Mikroprozessor.
• Die Programmiersprache ist unabhängig vom Betriebs- bzw. Laufzeitsystem.

C++
C++ findet als Nachfolger von C zwar auch in diesem Bereich Verwendung, ist aber deutlich weniger
häufig anzutreffen als sein Vorläufer. Der Einsatz liegt bei komplexen Themenstellungen, da es für
einfache Mikroprozessoren keine Compiler gibt und außerdem der erzeugte Code umfangreicher ist
als der durch C erzeugte Code.

PEARL
Bei PEARL (process and experiment automation realtime language) handelt es sich um eine Realzeit-
Programmiersprache, die sehr eng mit Pascal verwandt ist. Realzeiteigenschaften sind in der Sprache
bereits verankert. Für die Synchronisation existieren Semaphore und die Möglichkeit, in der Program-
miersprache das Scheduling zu beeinflussen.

JAVA
Zunehmend an Bedeutung gewinnt die Programmiersprache JAVA auch für Realzeitapplikationen. Da-
bei muß man zunächst zwei Varianten der Verwendung unterscheiden:
1. Java als virtuelle machine, die unter einem anderen (Realzeit-) Betriebssystem läuft und
2. Java als ein Laufzeitsystem selbst.

Prinzipiell würde sich Java aus den folgenden Gründen eignen:


• Objekt-Orientiertheit
• eingebautes Thread-Konzept
• Ausnahme-Behandlung
• weniger anfällig für Programmierfehler als C oder C++
• Portabilität

Leider ist Java bisher aber nicht deterministisch, insbesondere wegen des Memory-Managements
(Garbage-Collection). Im übrigen eignet sich das Prioritäten-gesteuerte Scheduling-Modell für
Threads nicht so gut, um selbiges in moderne Scheduling-Algorithmen zu integrieren.
Damit eignet sich Java gegenwärtig allenfalls für Soft-Realtime-Systems.

Die wohl größte Zahl von Realzeitsystemen wird mit Hilfe klassischer Programmiersprachen erstellt. Unter
klassischen Programmiersprachen werden hier Sprachen verstanden, die zunächst unabhängig vom darun-
terliegenden Laufzeitsystem sind.

5.2. Programmiertechnik
Bei der Erstellung von Software zur Steuerung technischer Prozesse ergeben sich Unterschiede zur ein-
fachen klassischen Programmierung. Zum einen existieren aufgrund des Einsatzbereiches erhöhte Quali-
tätsanforderungen, die allerdings durch den Entwurfsprozess (Stichwort ISO 9000) erfüllt werden müssen.

144
Kapitel 5. Programmierung

Zum anderen ist bereits ausgeführt worden, dass die Anforderungen an die Steuerung nur dann erfüllt wer-
den können, wenn

• die Aufgabe auf mehrere (konkurrierende und kooperierende) Tasks verteilt wird, um schritthaltende
Verarbeitung zu garantieren (Multitasking)
• eine Unterbrechung (Preemption) der Tasks möglich ist.

Aus diesen beiden Voraussetzungen ergeben sich die folgenden Folgerungen für die Programmierung:

• Zwischen den einzelnen Tasks muß es einen Kontrollfluß (eine Synchronisierung, beispielsweise durch
Semaphoren und Events) geben.
• Zwischen den Tasks müssen Daten ausgetauscht werden, dazu sind Inter-Prozess-
Kommunikationsmöglichkeiten (IPC) notwendig.
• Die Abfolge der Tasks (Scheduling, Priorisierung) muß durchgeführt (parametriert) werden.

5.2.1. Kontrollfluß

5.2.1.1. Semaphore
Am 4. Juli 1997 landete der Mars-Pathfinder spektakulär auf der Mars-Oberfläche. Der Pathfinder wurde
einfach fallengelassen, wobei Luftsäcke - wie Airbags im Auto - den Aufschlag abfingen. Nach der Landung
setzte der Pathfinder ein Fahrzeug auf dem Marsboden ab, das Sejourner-Fahrzeug, welches die nähere
Umgebung der Landefläche genauer untersuchen sollte.
Nach einer anfänglich (und auch letztendlich) überaus erfolgreichen Mission, stellten sich nach einigen
Tagen Probleme ein. Der Pathfinder war zeitweise nicht erreichbar. Es stellte sich heraus, dass in unregel-
mässigen Abständen auf dem Pathfinder System-Resets ausgelöst wurden. Jeder Reset aber brachte einen
erheblichen Datenverlust mit sich. Da insbesondere das Sejourner-Fahrzeug nur für eine Missionsdauer von
7 Tagen konzipiert war, begann hier auf der Erde eine fieberhafte Suche nach den Ursachen für diesen
Systemreset.
Die ersten Vermutungen gingen dahin, dass der Pathfinder überlastet gewesen sei und dass es zu sogenann-
ten Software-Glitches gekommen sei.
Anhand des Mars-Pathfinder sollen im folgenden Programmiertechniken zur Synchronisation und deren
Fallstricke untersucht werden. Dazu wird zunächst die Theorie der “Software Glitches” untersucht.

145
Kapitel 5. Programmierung

M−Task Z−Task

Informations−Bus

B−Task

nicht disjunkte Tasks


disjunkteTasks

M−Task = Task zur Erfassung meteorologischer Daten


B−Task = Bus−Management−Task
Z−Task = Task zur Zustandserfassung
RK = Rechnerkernbelegung

Abbildung 5-3. DFD des Mars-Pathfinder

Abbildung DFD des Mars-Pathfinder zeigt drei Rechenprozesse des Mars-Pathfinder, die gemeinsam eine
Aufgabe bearbeiten. Die M-Task ist zuständig für die Erfassung meteorologischer Meßwerte. Die Z-Task
führt periodisch eine Zustandsüberwachung des Raumfahrzeugs durch (beispielsweise bezüglich der Ener-
giereserven). Die Bus-Management-Task ist für den Datenaustausch innerhalb des Raumfahrzeugs zustän-
dig. Zwischen der M-Task und der Bus-Management-Task findet ein Datenaustausch statt. Die Prozesse
gehören semantisch gesehen zusammen. In einem solchen Fall spricht man von nicht disjunkten Tasks. Die
Z-Task ist dagegen unabhängig von den beiden anderen Tasks, sie ist damit disjunkt zu den beiden anderen
Rechenprozessen.
Informationen innerhalb des Raumfahrzeugs werden über einen sogenannten Informationsbus ausgetauscht.
Zunächst ist dieser Informationsbus nichts anderes als ein gemeinsamer Speicher. Auf diesen gemeinsamen
Speicher greifen sowohl die M-Task als auch die Bus-Management Task zu. Beide Tasks konkurrieren also
um dieses Betriebsmittel (Systemressource). Man spricht in diesem Falle auch von konkurrierenden Tasks,
im Gegensatz zu kooperierenden Tasks.

M−Task
10 20 30 40 50 60 70 80 90 100 110 120 t
B−Task
10 20 30 40 50 60 70 80 90 100 110 120 t
RK
10 20 30 40 50 60 70 80 90 100 110 120 t

Bufferinhalt
M−Task = Task zur Erfassung meteorologischer Daten inkonsistent
B−Task = Bus−Management−Task
RK = Rechnerkernbelegung

Abbildung 5-4. Mars-Pathfinder: Unsynchronisierter Datenaustausch

146
Kapitel 5. Programmierung

Abbildung Mars-Pathfinder: Unsynchronisierter Datenaustausch stellt die Rechnerkernbelegung bei einem


unsynchronisierten Datenaustausch zwischen der M-Task und der Bus-Management-Task über den gemein-
samen Datenspeicher Informationsbus dar. Die maximal zulässige Reaktionszeiten tZmax der Tasks ist durch
die jeweilige Prozesszeit tP gegeben. Die Verarbeitungszeiten tV und die Prozesszeiten finden sich in der
folgenden Tabelle Exemplarische Zeiten der Mars-Pathfinder Tasks.

Tabelle 5-1. Exemplarische Zeiten der Mars-Pathfinder Tasks

Task tV tP
M-Task 25 ms 85 ms
Z-Task 10 ms 45 ms
Bus-Management 5 ms 30 ms

Die Prioritäten der Tasks werden gemäß der bekannten Faustregel verteilt. Damit bekommt die häufig auf-
tretende und kurz rechnende Bus-Management-Task die höchste Priorität und die selten auftretende, dafür
aber viel Rechenzeit benötigende Task zur Erfassung meteorologischer Meßdaten die niedrigste Priorität.
Zum Zeitpunkt t=90 ms greifen beide Tasks auf den Informationsbus zu. Ein konsistenter Zustand kann hier
nicht mehr gewährleistet werden. Der Zugriff muß daher synchronisiert stattfinden.

Merke: Zur Lösung einer Echtzeitaufgabe werden im Normalfall mehrere Threads oder Prozesse ver-
wendet, die (quasi-)parallel arbeiten. Man unterscheidet dabei

• diskunkte Prozesse, bei denen der Ablauf eines Prozesses (respektive Threads) unabhängig von
den anderen Prozessen, zu denen er disjunkt ist,
• nicht disjunkte Prozesse, die auf gemeinsamen Variablen arbeiten. Diese lassen sich wiederum un-
terscheiden in:
• Konkurrierende Prozesse, die sich um den Zugriff auf Daten konkurrieren und
• Kooperierende Prozesse (meist verkettet), bei denen der eine Prozess Daten für den anderen
Prozess liefert (Hersteller/Verbrauchermodell).

Die Wirkung der gegenseitigen Beeinflussung nicht disjunkter paralleler Prozesse ist ohne Synchroni-
sation nicht vorhersagbar und im Regelfall nicht reproduzierbar.

5.2.1.1.1. Critical Section

• Der Programmteil, in dem auf gemeinsame Daten zugegriffen wird, heißt kritischer Abschnitt (critical
section).
• Greifen zwei oder mehr Threads bzw. Prozesse auf dieselben Daten zu, kann es zu einer sogenannten
race condition kommen. Bei einer race condition hängt das Ergebnis des Zugriffs vom Prozessfortschritt
ab.

Merke: Race conditions lassen sich vermeiden, indem nie mehr als ein Prozess in einen kritischen
Abschnitt eintritt (mutual exclusion, gegenseitiger Ausschluß).

Ein Semaphor wird zur Synchronisation, inbesondere bei gegenseitigem Ausschluß verwendet. Es handelt
sich dabei um ein Integer Variable, die wie folgt verwendet wird:

147
Kapitel 5. Programmierung

• Der Wert des Semaphors wird auf einen Maximalwert N initialisiert.


• Bei einem Zugriff auf das Semaphor (P1-Operation) wird
• dessen Wert um 1 erniedrigt und
• der Prozess schlafend gelegt, wenn der neue Semaphor-Wert negativ ist.

• Bei der Freigabe eines Semaphors (V2-Operation) wird


• dessen Wert um 1 erhöht und
• falls der neue Semaphor-Wert negativ oder gleich Null ist, ein auf das Semaphor wartender (schlafen-
der) Prozess aufgeweckt.

P-Operation
s = s - 1;
if( s < 0 ) {
SleepUntilSemaphorIsFree();
}

V-Operation
s = s + 1;
if( s ≤ 0 ) {
WakeUpOneSleepingProcess();
}

Anmerkung: P- und V-Operationen sind selbst kritische Abschnitte, deren Ausführung nicht unter-
brochen werden darf. Daher sind Semaphor-Operationen im Betriebssystem als System-Calls ver-
ankert, und während ihrer Ausführung (im Kernel) sind Interrupts gesperrt.
Bei einfachen Mikroprozessoren bzw. Laufzeitsystemen werden Semaphoroperationen ansonsten
durch Test-And-Set-Befehle des Mikroprozessors realisiert.

Anmerkung: Ein Mutex ist ein Semaphor mit Maximalwert N=1 (binärer Semaphor).

148
Kapitel 5. Programmierung

M−Task
10 20 30 40 50 60 70 80 90 100 110 120 t
B−Task
10 20 30 40 50 60 70 80 90 100 110 120 t
RK
10 20 30 40 50 60 70 80 90 100 110 120 t
1
S 0
t
−1

B−Task wird lauffähig,


M−Task = Task zur Erfassung meteorologischer Daten blockiert aber direkt an
B−Task = Bus−Management−Task der P−Operation
RK = Rechnerkernbelegung
S = Informationsbus−Semaphor

Abbildung 5-5. Mars-Pathfinder: Rechnerkernbelegung bei Verwendung eines Semaphor

Verwenden die Tasks im Beispiel des Mars-Pathfinder ein Semaphor, um den Zugriff auf den
Informationsbus zu synchronisieren, gibt es keine Zugriffskonflikte mehr (siehe Abbildung
Mars-Pathfinder: Rechnerkernbelegung bei Verwendung eines Semaphor). Der Wert »1« des Semaphor S
bedeutet, dass das geschützte Betriebsmittel „frei“ ist, der Wert »0« bedeutet, dass das Betriebsmittel
gerade verwendet wird. Hat das Semaphor einen Wert kleiner »0«, bedeutet dieses, dass mindestens eine
Task auf das Betriebsmittel wartet. Dank Semaphor und ohne Betrachtung der Z-Task gibt es somit keine
Zugriffskonflikte mehr.
Wie Abbildung Mars-Pathfinder: Rechnerkernbelegung bei Verwendung eines Semaphor verdeutlicht,
gibt es durch diesen Ansatz zunächst keine Probleme und damit keine „Software-Glitches“ beim
Mars-Pathfinder. Es mußte also noch etwas anderes an Board des Raumfahrzeuges aufgetreten sein, das zu
den erwähnten Problemen führte.

5.2.1.1.2. Prioritätsinversion
Die beiden bisher erwähnten Tasks waren nicht die einzigen Rechenprozesse an Board des Pathfinder. Be-
reits erwähnt wurde die Z-Task, die aufgrund ihrer Rechenzeitanforderung und ihrer Wichtigkeit die mittlere

149
Kapitel 5. Programmierung

Priorität bekam.

M−Task
10 20 30 40 50 60 70 80 90 100 110 120 t
Z−Task      
 


10 20 30 40 50 60 70 80 90 100 110 120 t


  

B−Task
t
  
     

10 20 30 40 50 60 70 80 90 100 110 120


  
  

RK
10 20 30 40 50 60 70 80 90 100 110 120 t

Deadline Verletzung
1
S 0
t
−1 M−Task blockiert B−Task blockiert

M−Task = Task zur Erfassung meteorologischer Daten


Z−Task = Task zur Zustandserfassung
B−Task = Bus−Management−Task
RK = Rechnerkernbelegung
S = Informationsbus−Semaphor

Abbildung 5-6. Deadlineverletzung beim Mars-Pathfinder

Abbildung Deadlineverletzung beim Mars-Pathfinder gibt das von Mike Jones beschriebene Problem in
Form der Rechnerkernbelegung beim Mars-Pathfinder wieder.
Abbildung Deadlineverletzung beim Mars-Pathfinder zeigt die Rechnerkernbelgung unter
Berücksichtigung der Z-Task. Die M-Task und die Bus-Management-Task greifen über den
Semaphor (Mutex) auf den Informationsbus zu. Das geht solange gut, solange nicht die Z-Task dann
rechenbereit wird, wenn gerade Task M den Informationsbus belegt hat. Stellt dann die höherpriore
Bus-Management-Task eine Anforderung, gelangt diese nicht in den Zustand lauffähig, da sie auf das
Betriebsmittel Informationsbus warten muß. Task Z kann also zuende rechnen, danach die M-Task und
schließlich die Bus-Management-Task. Deren Deadline ist jetzt jedoch abgelaufen (t=120 ms).
Die Z-Task an Board des Pathfinders wurde mittels eines Watchdog-Timers überwacht. Durch die aufgetre-
tene Deadlineverletzung der Task hat dieser Watchdog „zugeschlagen“ und einen Systemreset durchgeführt.
Diese Situation ist also die wahre Erklärung für die aufgetretenen Probleme auf dem Mars.
Der Fall des Mars-Pathfinders wurde von Mike Jones in einem auf dem Internet veröffentlichten Bericht
(http://catless.ncl.ac.uk/Risks/19.49.html) beschrieben:
Was wirklich mit dem Mars-Raumfahrzeug Pathfinder geschah:

Mike Jones <mbj@MICFROSOFT.com>

Sonntag, Dezember 07, 1997 6:47 PM

Die Mars-Pathfinder-Mission wurde in den ersten Tagen nach der Landung


auf dem Marsboden am 4ten Juli 1997 als weitgehend “problemlos”
eingestuft. Die Erfolge schlossen die unkonventionelle “Landung” ein
-- das Fallenlassen auf dem Marsboden geschützt durch Luftsäcke, Freigabe
des Sojourner Fahrzeugs und die Aufnahme und Übermittlung voluminöser
Daten zurück zur Erde, einschließlich der Panoramabilder, die ein
derartiger Hit auf dem Web waren. Aber ein paar Tage später, kurz nachdem

150
Kapitel 5. Programmierung

der Pathfinder begann, meteorologische Daten zu erfassen, wurden auf dem


Spacecraft richtige System-Resets festgestellt, die jeweils einen
Datenverlust bedeuteten. In der Presse wurden diese Fehler mit den Worten
“Software Glitches” und “der Computer versuchte zu viele Dinge auf
einmal zu tun” wiedergegeben.

Diese Woche hörte ich auf dem IEEE Realzeitsystem-Symposium eine


faszinierende Keynote von David Wilnder, dem Entwicklungsleiter von
Wind River Systems. Wind River macht VxWorks, den Echtzeitkern, der bei
der Mars-Pathfinder-Mission Verwendung gefunden hat. In seiner Rede
erklärte er im Detail die aktuellen Software-Probleme, die die Resets auf
dem Spacecraft auslösten, wie sie diagnostiziert und gelöst wurden. Ich
möchte die Geschichte mit Ihnen allen teilen.

VxWorks benutzt ein preemptives Prioritätenscheduling über Threads. Tasks


auf dem Pathfinder Spacecraft werden als Threads mit Prioritäten
ausgeführt, wobei die Prioritäten in der gewohnten Weise verteilt wurden,
nämlich die jeweilige Wichtigkeit der Task widerspiegelnd.

Pathfinder besitzt einen “Informations-Bus”, den man sich als gemeinsamen


Speicher zum Austausch von Informationen zwischen verschiedenen
Komponenten des Spacecrafts vorstellen kann. Eine Bus-Management-Task
läuft häufig mit hoher Priorität, um bestimmte Arten von Daten in und aus
dem Informations-Bus zu schaufeln. Der Zugriff auf den Bus wird durch
gegenseitigen Ausschluß gesichert (Mutex).

Die Task, mit der meteorologische Daten aufgenommen werden,


läuft als ein seltener,
niederpriorer Thread und verwendet den Informations-Bus um Daten zu
verbreiten. Um die Daten zu verbreiten, setzt die Task den Mutex, schreibt
auf den Bus und gibt den Mutex wieder frei. Wird aufgrund eines
Interrupts der Informations-Bus-Thread gescheduled, und versucht dieser
daraufhin den gleichen Mutex zu setzen, um die
publizierten Daten zu lesen, endet der Versuch damit, dass der
(Informations-Bus-) Thread am
Mutex blockiert wird und solange wartet, bis der Thread zur Aufnahme der
meteorologischen Daten den Mutex wieder freigibt. Das Spacecraft enthält
zusätzlich eine Task mit mittlerer Priorität.

Die meiste Zeit über hat diese Kombination gut funktioniert. Allerdings
war es sehr selten möglich, dass ein Interrupt auftrat, der die
Task mit mittlerer Priorität genau in dem kurzen Zeitintervall aktivierte,
während der der (hochpriore) Informations-Bus-Thread auf den (nieder prioren)
Thread wartete, der die meteorologischen Daten aufnimmt.
In diesem Fall verhindert die rechenzeitintensive Kommunikationstask
- hat sie doch schließlich höhere Priorität als die Meteorologie-Task -
selbige an der Bearbeitung und verhindert folglich damit, dass die blockierte
Informations-Bus-Task die CPU zugeteilt bekommt.
Nachdem eine Weile vergangen ist schlägt ein Watchdog-Timer zu, der
erkennt, dass die Informations-Bus-Task seit geraumer Zeit nicht mehr
aktiviert wurde, bemerkt damit, dass irgendetwas dramatisch falsch geht und
initiiert den System-Reset.

Dies Szenario ist der klassische Fall von Prioritätsinversion.

...

151
Kapitel 5. Programmierung

Task
P(X)
C
B P(X)
A
t1 t2 t3 t4 t5

t1 Task A belegt die Ressource X


t2 Task B (mit höherer Priorität)wird rechenbereit
t3 Task C (mit der höchsten Priorität) wird rechenbereit
t4 Task C versucht die Ressource X zu belegen und wird schlafen gelegt
t5 Task B hat von den rechenbereiten Prozessen die höchste Priorität

Abbildung 5-7. Prioritäten und Synchronisation

Unter Prioritätsinversion versteht man also die Situation, dass eine niedrigpriore Task eine Ressource allo-
ziert hat (über ein Semaphor), die von einer hochprioren Task benötigt wird. Dadurch wird die Bearbeitung
der hochprioren Task solange verzögert, bis die niedrigpriore Task die Ressource freigibt. Das kann aber un-
zumutbar lang dauern, wenn im System eine Reihe Tasks lauffähig sind, die mittlere Priorität haben (siehe
Abbildung Prioritäten und Synchronisation).

Task
P(X) V(X)
C
B P(X) V(X)
A
t1 t2 t3 t4 t5

t1 Task A belegt die Ressource X


t2 Task B (mit höherer Priorität)wird rechenbereit
t3 Task C (mit der höchsten Priorität) wird rechenbereit
t4 Task C versucht die Ressource X zu belegen und wird schlafen gelegt
t4 Task A erbt die Priorität von Task C und wird rechenbereit
t5 Task A gibt X wieder frei und bekommt die ursprüngliche Priorität

Abbildung 5-8. Prioritätsinversion

Das angesprochene Problem wird über die Methode der Prioritätsvererbung (Priority Inheritance) gelöst.
Es gibt unterschiedliche Protokolle zur Prioritätsvererbung, zum Beispiel das

1. Priority Inheritance Protocol (PIP) oder das


2. Priority Ceiling Protocol (PCP).

Priority Inheritance Protocol. Falls ein Job JR ein Mutex (oder auch ein Semaphore) anfordert, das gegen-
wärtig von einem Job JO mit niedrigerer Priorität gehalten wird, dann wird die Priorität von JO auf die
Priorität von Job JR angehoben. Sobald der Job JO das Mutex wieder freigibt, bekommt er seine initiale
Priorität zurück.

152
Kapitel 5. Programmierung

Die Prioritätsvererbung ist transitiv. Falls der Job JO bereits die Priorität von JR geerbt hat und ein weiterer
Job JS, dessen Priorität größer als die von JR ist, ankommt, erbt JO dir Priorität von JS.
Gibt JO die Ressource wieder frei, erhält JO seine ursprüngliche Priorität zurück. Die Ressource selbst wird
dem anfordernden Prozess mit der höchsten Priorität zugeteilt (im Beispiel also JS).
Mit Hilfe dieses Protokolls lassen sich sehr viele Probleme lösen, insbesondere wenn die Jobs nur um eine
Ressource konkurrieren. Es gilt allerdings zu beachten, dass die Transitivität des Protokolls nicht bei allen
Implementierungen gesichert ist, die Implementierungen können sich also bezüglich ihres Verhaltens im
Detail unterscheiden!
Priority Ceiling Protocol. Das Priority Ceiling Protocol ähnelt dem Priority Inheritance Protocol insofern,
dass auch hier der blockierte Job dem Job, der die Ressource belegt hat, die Priorität vererbt. Unterschiede
aber gibt es bei der Freigabe des Mutex. In diesem Fall bekommt der freigebende Job nicht seine ur-
sprüngliche Priorität zurück, sondern erhält die höchste Priorität, die ein anderer Job besitzt, mit dem er
ebenfalls ein anderes Mutex teilt.
Damit das Priority Ceiling Protocol angewendet werden kann, muss also bereits vor dem Start bekannt sein,
welche Ressourcen die Jobs benötigen.
Das Priority Ceiling Protocol ist unter Umständen in der Lage, Deadlock-Situation zu verhindern. Gesichert
ist dies allerdings nicht.
Beim Mars-Pathfinder wurde das Problem durch den Einsatz eines Priority Inheritance Protocols gelöst,
welches in VxWorks implementiert ist, aber von den Entwicklern gezielt abgeschaltet worden war. Nach
der Aktivierung des Protokolls kam es zu keinen unvorgesehenen Systemresets mehr.

M−Task
10 20 30 40 50 60 70 80 90 100 110 120 t
Z−Task      
 


10 20 30 40 50 60 70 80 90 100 110 120 t


B−Task
10 20 30 40 50 60 70 80 90 100 110 120 t
  
     

RK
10 20 30 40 50 60 70 80 90 100 110 120 t
Prioritätsvererbung
1
S 0
t
−1 M−Task blockiert B−Task blockiert

M−Task = Task zur Erfassung meteorologischer Daten


Z−Task = Task zur Zustandserfassung
B−Task = Bus−Management−Task
RK = Rechnerkernbelegung
S = Informationsbus−Semaphor

Abbildung 5-9. Prioritätsvererbung beim Mars-Pathfinder

Merke: Bedingungen zur Vermeidung von race conditions und Deadlocks

• Zwei Threads/Prozesse dürfen sich nicht gleichzeitig in ihren kritischen Abschnitten befinden.
• Befindet sich ein Prozess nicht in einem kritischen Abschnitt, darf er auch einen anderen Prozess
nicht blockieren.
• Kein Prozess sollte beliebig lange auf seinen Eintritt in den kritischen Abschnitten warten müssen.

153
Kapitel 5. Programmierung

5.2.1.1.3. Deadlock

Task A Task B

P(S1) P(S2)

P(S2) P(S1) Deadlock


S1 ist durch Task A
blockiert, S2 durch
Task B

V(S2) V(S1)
V(S1) V(S2)

Abbildung 5-10. Deadlock

Durch critical sections (gegenseitigem Ausschluß) kann es leicht zu Verklemmungen, den sogenannten
Deadlocks kommen. Muß eine Task beispielsweise zwei Datenstrukturen manipulieren, die durch zwei un-
abhängige Semaphore geschützt sind, und eine zweite Task muß das gleiche tun, nur dass sie die Semaphore
in umgekehrter Reihenfolge allokiert, gibt es eine Verklemmung (Deadlock).
Deadlocks lassen sich durch zwei Maßnahmen vermeiden:

1. entweder durch geeignete Systemauslegung und Programmierung oder dadurch, dass


2. nur dann Anforderungen an Betriebsmittel befriedigt werden, wenn sichergestellt ist, dass durch die
Anforderung keine Deadlock-Situation entstehen kann.

Zur Überprüfung, ob es zu einer Deadlock-Situation kommen kann, müssen mehrere Dinge bekannt sein:

1. die im System vorhandenen Ressourcen (Betriebsmittelvektor Rges),


2. die im System davon bereits auf die einzelnen Tasks verteilten Ressourcen (Belegungsmatrix U) und
3. pro Task die maximalen Anforderungen (M).

Man bezeichnet den Zustand des Systems solange als “deadlock-sicher”, solange mindestens eine Task alle
Ressourcenanforderungen erfüllen kann. Es kann zu keinem Deadlock kommen. Das System gerät dagegen
in einen “unsicheren” Zustand bezüglich Verklemmungen, wenn durch die Anforderung der Task nicht
wenigstens eine Task existiert, deren Anforderungen nicht mehr erfüllt werden kann.

154
Kapitel 5. Programmierung

Zur Überprüfung, ob ein System zu einem Zeitpunkt deadlock-sicher ist, kann man folgenden Algorithmus
verwenden:

1. Folgende Informationen müssen vorliegen:

• Betriebsmittel-Vektor (gibt an, wieviele Betriebsmittel vorhanden sind)


• gegenwärtige BM-Belegung (also welche Task belegt welche Betriebsmittel in welcher Anzahl)
• maximale Anforderung an die Betriebsmittel für jede Task.

2. Erstelle eine sogenannte Anforderungsmatrix durch Subtraktion der belegten Betriebsmittel von den
maximalen Anforderungen für jede Task. Die Anforderungsmatrix gibt also an, wieviele Betriebsmittel
eine jede Task zum Zeitpunkt der Untersuchung maximal anfordert.
3. Es werden die noch zur Verfügung stehenden Betriebsmittel berechnet (BM-Rest-Vektor):
• Bestimme die Gesamtzahl der belegten Betriebsmittel (Rused) durch Aufsummieren der belegten Be-
triebsmittel
• Subtrahiere die Gesamtzahl der belegten Betriebsmittel von den insgesamt vorhandenen Betriebs-
mitteln.

4. Wenn es in der Anforderungsmatrix M keine Task Ti gibt, bei der alle Anforderungen erfüllt werden
können, ist das System in einem unsicheren Zustand bezüglich deadlocks und die aktuelle Anforderung
eines Prozesses darf nicht erfüllt werden.
5. Wenn es in der Anforderungsmatrix M eine Task Ti gibt, bei der alle Anforderungen erfüllt werden
können, wird angenommen, dass diese Task zu Ende läuft und alle seine Betriebsmittel wieder freigibt.
Folglich können die zur Task gehörenden Betriebsmittel aus der Tabelle der belegten Betriebsmittel
gelöscht und den freien Betriebsmitteln zugeordnet werden.
6. Die Schritte 3 und 4 werden solange mit den jeweils aktuellen Werten wiederholt, bis entweder alle Pro-
zesse abgearbeitet werden konnten (sicherer Zustand), oder kein Prozess existiert, dessen maximalen
Anforderungen befriedigt werden könnten.

Hierzu ein Beispiel: Gegeben sei ein System mit den drei Betriebsmittelklassen A, B und C. Die Betriebs-
mittel innerhalb der Klassen sind gemäß folgendem Betriebsmittelvektor Rges mehrfach vorhanden:

A B C
10 5 7

Außerdem ist die gegenwärtige Verwendung der Betriebsmittel U bekannt:

Task\BM A B C
T0 0 1 0
T1 2 0 0
T2 3 0 2
T3 2 1 1
T4 0 0 2

155
Kapitel 5. Programmierung

Die einzelnen Tasks stellen maximal die folgenden Anforderungen M:

Task\BM A B C
T0 7 5 3
T1 3 2 2
T2 9 0 2
T3 2 2 2
T4 4 3 3

Um zu überprüfen, ob das System “deadlock-safe” ist, wird der beschriebene Algorithmus angewand:

1. Bestimmung der freien Betriebsmittel. Dazu werden zunächst die belegten Betriebsmittel aufaddiert
und von den insgesamt zur Verfügung stehenden Betriebsmittel subrahiert:

Task\BM A B C
T0 0 1 0
T1 2 0 0
T2 3 0 2
T3 2 1 1
T4 0 0 2
Σ 7 2 5

Die freien Betriebsmittel (Betriebsmittel-Rest-Vektor Ufree) ergeben sich zu:

A B C
3 3 2

2. Es wird die Anforderungsmatrix M aufgestellt. Dazu wird für jede Task von den maximalen Anforde-
rungen die bereits getätigten Anforderungen subtrahiert:

Task\BM A B C
T0 7 4 3
T1 1 2 2
T2 6 0 0
T3 0 1 1
T4 4 3 1

3. In Anforderungsmatrix finden sich zwei Tasks, die mit diesen Betriebsmitteln zu Ende laufen könnten:
T1 und T3. Von diesen wird (willkürlich) T1 ausgewählt. Die von T1 belegten Ressourcen (2, 0, 0)
werden auf den Vektor Ufree aufaddiert. Aus der Belegungsmatrix wird die Task T1 gelöscht.

A B C
5 3 2

156
Kapitel 5. Programmierung

4. Mit dem neuen Belegungsvektor lassen sich entweder die Task T3 oder T4 zuende rechnen (siehe
Anforderungsmatrix). Wieder wird eine Task ausgewählt, hier T4 (0, 0, 2). Damit ergibt sich ein neuer
Betriebsmittel-Rest-Vektor:

A B C
5 3 4

5. Im nächsten Schritt wird Task T3 (2, 1, 1) ausgewählt (von den in der Tabelle noch existierenden
Tasks T0, T2 und T3). Der neue Betriebsmittel-Rest-Vektor ergibt sich damit zu:

A B C
7 4 5

6. In der Tabelle stehen nur noch die Tasks T0 und T2. Als nächstes wird T0 ausgewählt. Der neue
Betriebsmittel-Rest-Vektor ergibt sich zu:

A B C
7 5 5

7. Jetzt ist nur noch T2 verbleibend. Da auch diese Anforderungen (3, 0, 2) erfüllt werden können, ist
das System in einem deadlock-sicheren Zustand.

5.2.1.1.4. POSIX-Funktionen für Mutexe

int pthread_mutex_destroy( pthread_mutex_t * mutex );

Über diese Funktion wird ein Mutex (Semaphor, das genau einem Thread den Zugriff auf den kri-
tischen Abschnitt ermöglicht) gelöscht und die damit zusammenhängenden Ressourcen freigegeben.
Ein Mutex wird nur entfernt, wenn es „frei“ (unlocked) ist.

int pthread_mutex_lock ( pthread_mutex_t * mutex );

Über diese Funktion wird ein kritischer Abschnitt betreten. Sollte der kritische Abschnitt frei sein, wird
das Mutex gesperrt (locked) und dem aufrufenden Thread zugehörig erklärt. In diesem Falle returniert
die Funktion direkt. Sollte der kritische Abschnitt gesperrt sein, wird der aufrufende Thread solange
in den Zustand „warten“ versetzt, bis das Mutex wieder freigegeben wird.
Ist das Mutex durch denselben Thread gesperrt, der den Aufruf durchführt, kann es zu einem Deadlock
kommen. Um dies zu verhindern läßt sich ein Mutex so konfigurieren, dass es entweder in diesem Fall
den Fehlercode EDEADLK returniert (ein „error checking mutex“ oder den Mehrfachzugriff erlaubt (ein
„recursive mutex“).

157
Kapitel 5. Programmierung

int pthread_mutex_trylock( pthread_mutex_t * mutex );

Diese Funktion verhält sich genauso wie die Funktion pthread_mutex_lock mit der Ausnahme, dass sie
nicht blockiert, falls der kritische Abschnitt nicht betreten werden kann. In diesem Fall returniert die
Funktion EBUSY.

int pthread_mutex_init( pthread_mutex_t * mutex , const pthread_mutexattr_t * mutexattr );

Diese Funktion initalisiert ein Mutex mutex gemäß der Angaben im Parameter mutexattr. Ist
mutexattr NULL werden default Werte zur Initialisierung verwendet.

int pthread_mutex_unlock( pthread_mutex_t * mutex );

Über diese Funktion wird ein kritischer Abschnitt wieder verlassen.

5.2.1.1.5. Schreib-/Lese Locks


Wie hier vorgestellt wird ein Job blockiert, sobald er auf einen kritischen Abschnitt zugreifen möchte, der
bereits durch einen anderen Job belegt ist.
Fall der kritische Abschnitt aus dem Zugriff auf globale Daten besteht, kommt es nur dann zu einer Race-
Condition, falls die zugreifenden Rechenprozesse die Daten modifizieren. Das parallele Lesen ist jedoch
unkritisch. Aus dieser Erkenntnis heraus bieten viele Systeme sogenannte Schreib-/Lese-Locks an. Das
sind Semaphore, die parallele Lesezugriffe erlauben, aber einem schreibenden Job einen exklusiven Zugriff
ermöglichen.
Bei der Anforderung des Mutex muss der Rechenprozess mitteilen, ob er den kritischen Abschnitt nur zum
Lesen, oder auch zum Schreiben betreten möchte. Folgende Fälle werden unterschieden:

1. Der kritische Abschnitt ist frei:


Der Zugriff wird gewährt.

2. Der kritische Abschnitt ist von mindestens einem Rechenprozess belegt, der lesend zugreift und es gibt
zur Zeit keinen Rechenprozess, der schreibend zugreifen möchte:
Ein lesend wollender Prozess bekommt Zugriff.
Ein Prozess, der schreiben möchte, wird blockiert.

3. Der kritische Abschnitt ist von mindestens einem Rechenprozess belegt, der lesend zugreift und es gibt
zur Zeit mindestens einen Rechenprozess, der schreibend zugreifen möchte:
Der anfragende Rechenprozess wird blockiert (unabhängig davon, ob er lesen oder schreiben möchte).

4. Der kritische Abschnitt ist von einem Prozess belegt, der schreibend zugreift:
Der anfragende Rechenprozess wird blockiert (unabhängig davon, ob er lesen oder schreiben möchte).

158
Kapitel 5. Programmierung

Auch einen lesen wollenden Prozess zu blockieren, sobald ein Rechenprozess zum Schreiben den kriti-
schen Abschnitt betreten möchte ist notwendig, damit es nicht zum „sterben“ des schreiben wollenden Jobs
kommt.

5.2.1.2. Weitere Schutzmaßnahmen für kritische Abschnitte


Ein Semaphor läßt sich dann zum Schutz kritischer Abschnitte einsetzen, wenn der Abschnitt durch zwei
oder mehr Applikationen (User-Prozesse) betreten werden soll. Kritische Abschnitte aber, die beispiels-
weise innerhalb des Betriebssystemkerns, eines Treibers oder in Interrupt-Service-Routinen vorkommen,
können damit nicht gesichert werden. Hier werden andere Techniken benötigt: Unterbrechungssperren und
Spinlocks.
Unterbrechungssperre. Hierbei werden die Interrupts auf einem System für die Zeit des Zugriffs auf den
kritischen Abschnitt gesperrt. Um die Latenzzeiten kurz zu halten, darf der Zugriff selbst nur kurz dauern.
Bei modernen Betriebssystemen ist diese Methode nur für Zugriffe innerhalb des Betriebssystemkerns, also
beispielsweise bei der Realisierung von Treibern, interessant, denn nur hier lassen sich Interrupts sperren.
Spinlocks. Da bei Multiprozessorsysteme (SMP=Symmetric Multiprocessing) zwei oder mehr Interrupt-
serviceroutinen real parallel bearbeitet werden können, hilft eine lokale Unterbrechungssperre nicht weiter.
Hier arbeitet man im Regelfall mit sogenannten Spinlocks.
Bei Spinlocks entscheidet - wie schon beim Semaphor - eine Variable darüber, ob ein kritischer Abschnitt
betreten werden darf oder nicht. Ist der kritische Abschnitt bereits besetzt, wartet die zugreifende Einheit
aktiv solange, bis der kritische Abschnitt wieder freigegeben worden ist.
Damit ergeben sich für die vorgestellten drei Methoden zum gegenseitigen
Ausschluß bei einem kritischen Abschnitt unterschiedliche Einsatzfelder (Abbildung
Einsatzmöglichkeiten unterschiedlicher Synchronisationsmethoden). Die Unterbrechungssperre steht
normalen Applikationen nicht zur Verfügung. Bei Einprozessorsystemen (UP=Uni-Processor) wird selbige
im Betriebssystemkerns eingesetzt. Bei SMP lassen sich zwar die Interrupts auf allen Prozessoren sperren,
bevor aber auf den kritischen Abschnitt zugegriffen werden kann ist sicherzustellen, dass nicht zufällig
zwei Prozessoren die ISR bearbeiten.
Spinlocks werden ebenfalls im Kernel eingesetzt. Sie realisieren ein aktives Warten und lassen sich aus
diesem Grunde nur in einer SMP-Umgebung verwenden.
Das Semaphor schließlich ist für den gegenseitigen Ausschluß auf Applikationsebene gedacht. Es ist sowohl
für UP- als auch für SMP-Umgebungen verwendbar. Der Einsatz im Betriebssystemkern ist möglich, aber
nur dann, wenn der kritische Abschnitt nicht von einer ISR betreten werden soll. In diesem Fall müsste man
nämlich die ISR schlafen legen, was nicht möglich ist.

Tabelle 5-2. Einsatzmöglichkeiten unterschiedlicher Synchronisationsmethoden

Methode User Level UP: Kernel Level SMP: Kernel Level


Unterbrechungssperre Nein Ja Nein
Spinlocks Nein Nein Ja
Semaphore Ja Ja Ja

159
Kapitel 5. Programmierung

5.2.1.3. Events
Während über ein Semaphor der Zugriff auf ein gemeinsam benutztes Betriebsmittel synchronisiert wur-
de (Synchronisation konkurrierender Tasks), werden zwei oder mehrere kooperierende Tasks über Events
bezüglich ihres Programmablaufs synchronisiert. Dabei kann eine Task auf ein Event (Ereignis) warten,
welches durch eine andere Task gesetzt wird.
Hierzu wieder ein Beispiel. Drei Tasks (Task A, Task B und Task C) erfassen jeweils einen Meßwert,
der durch eine vierte Task (Task W) weiterverarbeitet wird. Hat eine der drei Tasks A, B oder C einen
Meßwert zur Weiterverarbeitung erfaßt, wird dieser in einen einmal vorhandenen Datenspeicher abgelegt
(der Datenspeicher kann also genau einen Meßwert speichern). Task W holt sich dort den Meßwert ab.

read
A

read W
B datenspeicher
P(S)
P(S)
V(S)
read V(S)
C S
P(S) V(S)
P(S)V(S)

Abbildung 5-11. Meßwerterfassung: Synchronisation ohne Events

Da der Datenspeicher nur einmal vorhanden ist, handelt es sich um einen kritischen Abschnitt (critical
section). Dieser ist also mittels eines Semaphors zu schützen (in diesem Abschnitt konkurrieren alle 4 Tasks
miteinander). Der Aufbau der Tasks, wie ihn Bild Task A,B und C: Synchronisation durch ein Semaphor
und Bild Task W: Synchronisation durch ein Semaphor zeigen, berücksichtigt aber nicht, dass nur eine der
Tasks A, B oder C zugreifen darf, wenn der Datenspeicher durch W vorher geleert wurde und berücksichtigt
ebenso wenig, dass Task W nicht mehrfach hintereinander zugreifen darf, ohne dass der Speicher durch eine
der drei neu beschrieben wurde. Wir haben - trotz Verwendung des Semaphor - eine race condition bzw.
eine Deadlock-Situation.

...
while( TRUE ) {
read(kanal_A, buffer, sizeof(buffer) );
P(S); // enter critical section
write( datenspeicher, buffer, sizeof(buffer) );
V(S); // leave critical section
}
...

Abbildung 5-12. Task A,B und C: Synchronisation durch ein Semaphor

...
while( TRUE ) {
P(S); // enter critical section
read( datenspeicher, buffer, sizeof(buffer) );
V(S); // leave critical section
WorkOnData( buffer );
}

160
Kapitel 5. Programmierung

...

Abbildung 5-13. Task W: Synchronisation durch ein Semaphor

Es reicht also nicht aus, nur den eigentlichen Zugriff als solches auf das gemeinsame Betriebsmittel mittels
eines Semaphor zu schützen. Vielmehr ist noch ein weiteres Synchronisationsmittel notwendig: ein Event.

Definition: Ein Event ist ein Synchronisationselement, welches Rechenprozessen erlaubt solange den
Prozessor frei zu geben, bis eine bestimmte Bedingung erfüllt ist. Die Basisoperationen des Events
sind:

• warten auf das Event und

• senden (setzen) des Events.

Da Events nicht zwischengespeichert werden, treten Events im Regelfall nur in Kombination mit einem
Semaphor auf.

Merke: Events werden nicht zwischengespeichert! Daher muß die Applikation selbst Maßnahmen er-
greifen, damit Events nicht “verloren” gehen.

Um also den Tasks A, B oder C erst dann Zugriff auf den Datenspeicher zu gewähren, nachdem Task W
selbigen entleert hat, wird die Operation “kritischen Abschnitt betreten” und “kritischen Abschnitt verlas-
sen” auf unterschiedliche Tasks verteilt. Die Tasks A, B und C betreten (durch Aufruf der P-Operation)
den kritischen Abschnitt, geben aber selber den kritischen Abschnitt niemals frei. Diese Freigabe führt jetzt
Task W durch. Task W muß jetzt nur noch derartig synchronisiert werden, dass sie die Daten dann aus dem
Speicher holt, wenn diese auch vorhanden sind. Dazu sendet Task A, B oder C ein Event, auf welches Task
W wartet (siehe Abbildung Meßwerterfassung: Synchronisation mit Events).

read Event
A
Event

read W
B datenspeicher
P(S)
P(S)
read
C S
V(S)
P(S)
Event

Abbildung 5-14. Meßwerterfassung: Synchronisation mit Events

161
Kapitel 5. Programmierung

...
read(kanal_A, buffer, sizeof(buffer) );
P(S); // enter critical section
write( datenspeicher, buffer, sizeof(buffer) );
SendEvent( Task_W );
...

Abbildung 5-15. Task A, B und C: Synchronisation über Events

...
WaitForEvent( Task_W );
read( datenspeicher, buffer, sizeof(buffer) );
V(S); // leave critical section
WorkOnData( buffer );
...

Abbildung 5-16. Task W: Synchronisation über Events

So wie die drei Erfassungstask den kritischen Abschnitt nicht selbst freigeben, so betritt die Task W im
eigentlichen Sinne den kritischen Abschnitt nicht. Der kritische Abschnitt ist damit definiert vom Zeitpunkt,
zu dem eine der Erfassungstask einen Meßwert in den Datenspeicher schreibt bis zu dem Zeitpunkt, an dem
die Task W diesen Meßwert herausgeholt hat.



A blockiert am Semaphor



A B C A





SendEvent
 
 

 
 

 

       

A W B W C












  

t1











 

Semaphor von W freigegeben











WorkOnData
WaitForEvent

Abbildung 5-17. Race Condition bei Verwendung von Events

Bei der Verwendung von Events ist aber auf eine weitere Möglichkeit der race condition zu achten:
Zwischen der Freigabe des Semaphors und dem Warten auf das Event darf kein weiterer Event erfolgen, der
dabei verloren gehen könnte (siehe Abbildung Race Condition bei Verwendung von Events). Bedingt durch
die Programmlaufzeiten und die Prioritätenverteilung (Task W hat niedrigere Priorität als Task A, B und
C), wird Task A zum Zeitpunkt t1 zunächst am Semaphor blockiert, nachdem Task W noch nicht mit der
Bearbeitung der Daten von Task C fertig ist. Um die critical section (und damit auch die Wartezeiten) kurz
zu halten, gibt Task W den kritischen Abschnitt sofort frei, wenn er nicht mehr benötigt wird. Dadurch
bekommt Task A die CPU (sie wartete ja auf den Semaphor), schreibt die Daten in den Datenspeicher und
schickt das Event. Erst danach kommt Task W wieder an die Reihe, bearbeitet die Daten von Task C zu
Ende und wartet erst jetzt auf das Ereignis, welches schon zu einem früheren Zeitpunkt verschickt wurde.
Die Hinzunahme der Funktion WorkOnData() in den kritischen Abschnitt würde die Situation zwar entschär-
fen, die race condition aber nicht beseitigen. Immer noch kann zwischen Freigabe des Semaphor und dem

162
Kapitel 5. Programmierung

Warten auf das Ereignis die Task, die das Event schickt, gescheduled werden. Damit würde das Ereignis in
seltenen Fällen weiterhin verloren gehen.
Eine Lösung des Problems ist nur zu erreichen, wenn diese beiden Verarbeitungsschritte (also die Semaphor-
Freigabe und das Warten auf das Ereignis) als unteilbare (atomare) Operation durchgeführt würde. Das ist
auch der Grund, warum an der Posix-Schnittstelle Events grundsätzlich mit einem Semaphor verbunden
sind.
Damit ergibt sich folgender Code:
...
P(S); // Da das folgende WaitForEventAndV eine Semaphore
// freigeben will, muss diese erst einmal gelockt werden.
while( TRUE ) {
WaitForEventAndV(S); // Freigabe des Semaphors und Warten
read( datenspeicher, buffer, sizeof(buffer) );
WorkOnData( buffer );
}
...

Da auf ein Event auch mehrere Tasks warten können, gibt es sowohl eine Funktion, die genau eine Task
aufweckt, als auch eine Funktion, die alle Tasks aufweckt.
In der Posix-Norm sind die unten aufgeführten Funktionen für das Eventhandling spezifiziert worden:

int pthread_cond_init( pthread_cond_t * cond , pthread_condaddr_t * cond_attr );

int pthread_cond_signal( pthread_cond_t * cond );

Mit dieser Funktion wird ein Ereignis verschickt. Dazu wird genau eine Task aufgeweckt, die auf das
Ereignis wartet.

int pthread_cond_broadcast( pthread_cond_t * cond );

Mit dieser Funktion wird ein Ereignis an alle Tasks geschickt, die auf das Ereignis warten.

int pthread_cond_wait( pthread_cond_t * cond , pthread_mutex_t * mutex );

Diese Funktion gibt in einer atomaren Operation sowohl die mit dem Event assoziierte Semaphore frei,
als auch versetzt sie die aufrufende Task in den Zustand “wartend”.

int pthread_cond_timedwait( pthread_cond_t * cond , pthread_mutex_t * mutex , const struct


timespec * abstime );

163
Kapitel 5. Programmierung

int pthread_cond_destroy( pthread_cond_t * cond );

5.2.1.4. Signals
Bei Signals handelt es sich um Software-Interrupts auf Applikationsebene, das heißt: Ein Signal führt zu ei-
ner Unterbrechung des Programmablaufs innerhalb der Applikation. Daraufhin wird das Programm entwe-
der abgebrochen oder reagiert mit einem vom Programm zur Verfügung gestellten Signal-Handler (ähnlich
einer Interrupt-Service-Routine).
Realisiert werden Signals als Systemcalls des Betriebssystems. Signals können zum einen durch eine Ap-
plikation ausgelöst werden, zum anderen aber auch durch Ereignisse innerhalb des Betriebssystem selbst.
So führt zum Beispiel der Zugriff auf einen nicht vorhanden Speicherbereich (z.B. der Zugriff auf Adresse
0) innerhalb des Betriebssystems dazu, dem Prozess ein Segmentation-Fault-Signal zu schicken, welches
der Prozess abfangen könnte. In der zugehörigen Segmentation-Fault-ISR würden alle notwendigen Daten
noch gespeichert. Erst danach würde die Applikation beendet werden.
Die Unterschiede zwischen Events und Signals sind in Tabelle Unterschiede zwischen Events und Signals
dargestellt.

Tabelle 5-3. Unterschiede zwischen Events und Signals

Signals Events
Signals kommen asynchron zum Programmablauf Events kommen synchron zum Programmablauf
und werden asynchron verarbeitet. und werden synchron verarbeitet.
Charakter einer Interrupt-Service-Routine Rendezvous-Charakter
(Software-Interrupt).

Warnung
Ein Signal führt - wenn nicht anders konfiguriert - zum sofortigen Abbruch eines gerade
aktiven Systemcalls. Werden im Rahmen einer Applikation Signals verwendet bzw. abge-
fangen, muß jeder Systemcall daraufhin überprüft werden, ob selbiger durch ein Signal
unterbrochen wurde und, falls dieses zutrifft, muß der Systemcall neu aufgesetzt werden!

Systemcalls für die Signal-Services:

int sigaction( int signum , const struct sigaction * act , struct sigaction * oldact );

Mit diesem Systemcall kann das Verhalten (Aktion) parametriert werden, das eine Task bei Erhalt eines
spezifischen Signals durchführt.
Mit dieser Funktion wird auch die Adresse der Interrupt-Service-Routine übergeben, die bei Erhalt des
Signals vom Betriebssystem aufgerufen wird.

164
Kapitel 5. Programmierung

int kill( pid_t pid , int sig );

Dieser Systemcall wird dazu verwendet, einer Task oder einer Task-Gruppe ein beliebiges Signal zu
schicken.

5.2.2. Datenfluß/Inter-Prozess-Kommunikation
Als klassische Inter-Prozess-Kommunikation gibt es:

• Mailbox/Messages
• Shared-Memory
• Sockets

5.2.2.1. Mailbox
Zum Datenaustausch bieten Betriebssysteme einen Mailbox-Mechanismus (send/receive Interface) an. Da-
bei werden - im Regelfall unidirektional - Daten von Task 1 zu Task 2 transportiert und gepuffert (im
Gegensatz zu gequeued).
In den meisten Realzeitbetriebssystemen und in Unix-Systemen ist ein Mailbox-Mechanismus über Pipes
(FIFO) und über die sogenannten Messages implementiert. Pipes haben gegenüber den Messages den Vor-
teil, die für I/O üblichen Systemfunktionen (read, write) zu verwenden.

5.2.2.2. Shared-Memory
Bei einem Shared-Memory handelt es sich um einen gemeinsamen Speicherbereich einer oder mehre-
rer Tasks innerhalb eines Rechners. Die Realisierung eines gemeinsamen Speicherbereichs im Falle von
Threads ist trivial. Wollen mehrere Rechenprozesse jedoch einen gemeinsamen Speicher nutzen, müssen
sie diesen vom Betriebssystem anfordern. Ähnlich wie beim Dual-Port-RAM, bei dem allerdings unter-
schiedliche Prozessoren zugreifen, kann die Speicheradresse des gemeinsamen Speicherbereichs von Task
zu Task unterschiedlich sein. Deshalb ist es auch hier wichtig, Pointer innerhalb von Datenstrukturen relativ
zum Beginn (oder Ende) des Speicherbereichs anzugeben.

5.2.2.3. Sockets
Die wichtigste Schnittstelle für Inter-Prozess-Kommunikation stellt die Socket-Schnittstelle dar. Mittels
Sockets können Daten zwischen Prozessen ausgetauscht werden, die auf unterschiedlichen Rechnern loka-
lisiert sind (verteiltes System).
Die Socketschnittstelle bietet Zugriff zur tcp/ip- und zur udp-Kommunikation. Ist dabei einmal eine Verbin-
dung zwischen zwei Prozessen hergestellt worden, können die Daten mit den bekannten Systemfunktionen
(read, write ...) ausgetauscht werden.

165
Kapitel 5. Programmierung

sd = socket(PF_INET, SOCK_STREAM, 0 );
bind( sd, ... );
listen( sd, Anzahl möglicher paralleler Verbindungen );
while( 1 )
Newsd = accept( sd, ... );
Zugriff auf die Verbindung über read und write
read( Newsd, buffer, sizeof(buffer) );

Abbildung 5-18. Basisstruktur einer Socket-Serverapplikation

Auf tcp/ip-Ebene handelt es sich um eine Server/Client-Kommunikation. Ein Server alloziert per socket-
Funktion einen beliebigen Socket (Ressource) im System, wobei der Socket über eine Nummer identifiziert
wird. Damit ein Client auf einen Socket zugreifen kann, muß er die Socketnummer (Socketadresse) kennen.
Für Standarddienste, wie beispielsweise http, sind diese Nummern reserviert, man spricht von sogenannten
well known sockets.
Hat der Server einen Socket alloziert, muß er ihm eine bekannte Socketnummer zuweisen (z.B. 80 bei http).
Dies geschieht mit der Funktion bind (siehe Bild Basisstruktur einer Socket-Serverapplikation). Über einen
Socket kann der Server gleichzeitig mehrere Clients bedienen. Über die Funktion listen kann er dabei
parametrieren, wieviele derartige Clients er maximal bedienen möchte (Bild Socket-Serverprogramm). Ein
einzelner Port auf einem Rechner kann aus dem Grund mehrere Verbindungen (Clients) bedienen (und
unterscheiden), weil eine Verbindung durch

• Ziel-IP-Adresse,
• Ziel-Port,
• Remote-IP-Adresse und
• Remote-Port
charakterisiert ist.
Ist der Socket geöffnet und ist ihm eine bekannte Socketadresse zugewiesen worden, kann der Server auf
Verbindungswünsche warten. Dieses Warten wird über den accept Aufruf realisiert. Accept liefert, wenn
auf dem bekannten Socket ein Verbindungswunsch kommt, einen neuen Socket zurück. Der ursprüngli-
che, gebundene Socket (bind socket) ist damit wieder frei, um auf weitere Verbindungswünsche zu war-
ten. Klassische Serverprogramme, wie beispielsweise der http-Server, erzeugen für jeden Verbindungs-
wunsch (also nach dem accept) mittels fork einen eigenen Prozess. Der zurückgegebene Socket (im Bild
ConnectionSocket) wird vom Server wie ein Filedeskriptor verwendet. Er kann also auf den Filedeskrip-
tor/Socketdeskriptor schreiben und von ihm lesen (bidirektionale Verbindung).

#include <stdio.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

static int BindSocket, ConnectionSocket;

static void EmergencyClose( int Signal )


{
close( BindSocket );
close( ConnectionSocket );
exit( -1 );

166
Kapitel 5. Programmierung

int main( int argc, char **argv )


{
int count;
struct sockaddr_in MyPort, RemoteSocket;
char buffer[512];

signal( SIGINT, EmergencyClose );


BindSocket = socket( AF_INET, SOCK_STREAM, 0 );
if( BindSocket <= 0 ) {
perror( ”socket” );
exit( -1 );
}
bzero( &MyPort, sizeof(MyPort) );
MyPort.sin_port = htons( 12345 );
printf(”sin_port = %d\n”, MyPort.sin_port );
if( bind(BindSocket,(struct sockaddr *)&MyPort,sizeof(MyPort))<0 ) {
perror( ”bind” );
exit( -1 );
}
listen( BindSocket, 3 );
while( 1 ) {
count = sizeof( RemoteSocket );
ConnectionSocket = accept( BindSocket, &RemoteSocket, &count );
if( ConnectionSocket >= 0 ) {
printf(”connection established ...\n”);
while( count=read(ConnectionSocket,buffer, sizeof(buffer) )) {
if( strncmp( buffer, ”end”, strlen(”end”) )==0 ) {
break;
} else {
write( ConnectionSocket,buffer,count );
}
}
close( ConnectionSocket );
printf( ”connection released ...\n”);
}
}
close( BindSocket );
return( 0 );
}

Abbildung 5-19. Socket-Serverprogramm

sd=socket(PF_INET, SOCK_STREAM, 0 );
inet_aton( "192.168.12.12", &destination.sin_addr ); //Zieladresse spez.
destination.sin_port = htons( Portnummer ); //Zielport spezifizieren
destination.sin_family = PF_INET;
connect( sd, &destination, sizeof(destination) );
Zugriff auf die Verbindung über read und write
write( sd, Nachricht, strlen(Nachricht)+1 );
...

Abbildung 5-20. Basisstruktur einer Socket-Clientapplikation

Der Verbindungsaufbau über Sockets auf der Client-Seite ist nicht so kompliziert (siehe Bild
Basisstruktur einer Socket-Clientapplikation). Der Client alloziert sich - wie der Server auch - per socket

167
Kapitel 5. Programmierung

Funktion die Socket-Ressource. Da der Client ja keine Verbindung entgegennehmen möchte, muß dieser
Socket auch nicht an eine bestimmte Nummer gebunden werden. Der Client tätigt nur noch einen connect
Aufruf, um sich mit dem Remote-Rechner zu verbinden. Er verwendet den vom Socket-Aufruf returnierten
Socketdeskriptor/Filedeskriptor direkt (Bild Socket-Clientprogramm).

#include <stdio.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#define TEXT ”Hallo, hier ist ein Client ;-)”

static int sd;

static void EmergencyClose( int Signal )


{
close( sd );
}

int main( int argc, char **argv )


{
int count;
struct sockaddr_in destination;
char buffer[512];

signal( SIGINT, EmergencyClose );


sd = socket( PF_INET, SOCK_STREAM, 0 );
if( sd <= 0 ) {
perror( ”socket” );
exit( -1 );
}
bzero( &destination, sizeof(destination) );
inet_aton( ”194.94.121.156”, &destination.sin_addr );
destination.sin_port = htons( 25 );
destination.sin_family = PF_INET;
if( connect(sd, (struct sockaddr *) &destination, sizeof(destination))<0) {
perror( ”connect” );
exit( -1 );
}
write( sd, TEXT, strlen(TEXT)+1 );
if( (count=read( sd, buffer, sizeof(buffer))) <=0 ) {
perror( ”read” );
close( sd );
exit( -1 );
};
printf( ”%d: %s\n”, count, buffer );
write( sd, ”end”, 4 );
close( sd );
return( 0 );
}

Abbildung 5-21. Socket-Clientprogramm

Die Kommunikation über Sockets ist - wie in den Abbildungen ersichtlich - relativ unproblematisch. Reale
Serverprogramme werden aber aufgrund notwendiger Flexibilität deutlich komplexer. So programmiert man
im Regelfall weder die IP-Adresse noch die Portadresse fest in die Applikation ein. Stattdessen werden sym-
bolische Namen spezifiziert, die in entsprechenden Konfigurationsdateien abgelegt sind (z.B. /etc/services)
oder über andere Serverdienste (z.B. DNS für die Auflösung von Hostnamen zu IP-Adressen) geholt wer-
den. Für diese Aktionen existiert eine ganze Reihe weiterer Bibliotheksfunktionen.
Die Schnittstelle unterstützt nicht nur die Kommunikation über tcp/ip, sondern auch über udp. Bei udp
handelt es sich um einen verbindungslosen Dienst. Der Server muß also kein accept aufrufen, sondern

168
Kapitel 5. Programmierung

kann direkt vom Socket (Bind-Socket) lesen. Um hier Informationen über den Absender zu erhalten, gibt
es eigene Systemaufrufe, bei denen IP- und Portadresse des Absenders übernommen werden.
Auch die über IP angebotenen Multicast- und Broadcast-Dienste werden über die Socket-Schnittstelle be-
dient und sind letztlich Attribute (Parameter) des Sockets.
Die im IP-Protokoll festgelegten Datenstrukturen gehen von einem „big endian“-Ablageformat der Varia-
blen (z.B. Integer) aus. Das bedeutet, dass eine Applikation, die auf einem Rechner abläuft, der ein „little
endian“-Datenablageformat verwendet, die Inhalte der Datenstrukturen erst konvertieren muß. Dieser Vor-
gang wird durch die Funktioen ntohX (net to host) und htonX (host to net) unterstützt (X steht hier für
short oder long). Auf einem Rechner mit „big endian“-Ablageformat sind die Funktionen (Makros) leer,
auf einem Rechner mit „little endian“-Ablageformat wird dagegen eine Konvertierung durchgeführt.
Schreibt man also eine verteilte Applikation, die unabhängig vom Datenablageformat ist, müssen alle Da-
tenstrukturen in ein einheitliches Format gewandelt werden. Die Daten müssen zum Verschicken konvertiert
und beim Empfang wieder rückkonvertiert werden. Folgende Technologien unterstützen den Programmierer
bei dieser Arbeit:

• Remote Procedure Call (RPC)


• Remote Message Invocation (RMI, für Java)
• OLE (Microsoft)
• Corba (Unix)
RPC, RMI, OLE und Corba kümmern sich dabei nicht nur um die Konvertierung, sondern auch um den
eigentlichen Datentransport.

5.2.3. Time triggered versus Event triggered


Ein technischer Prozess stellt in unregelmässigen Abständen Anforderungen, die von einer Realzeitsteue-
rung bearbeitet werden. Die Bearbeitungszeit sei mit 8ms gegeben. Folgende technische Lösungen sollen
aufgrund ihrer Eignung überprüft werden:

1. Busy-Loop
2. Time-Triggered
3. Event-Triggered

5.2.3.1. Busy-Loops
Bei der Busy-Loop-Lösung ist die Echtzeitsteuerung nur mit der Regelung dieses einen technischen Prozes-
ses beschäftigt. Daher ist ein Kontext-Wechsel nicht notwendig, der zugehörige Rechenprozess pollt ständig
den technischen Prozess, ob dieser die Anforderung stellt oder nicht. Bei der gegebenen Verarbeitungszeit
von tV=8ms dürfen die Ereignisse einen minimalen Abstand von tPmin=8ms haben. Innerhalb einer Sekunde
können dabei also 125 Anforderungen schritthaltend bearbeitet werden.
Wird in einer Schleife ständig der Inhalt eines Peripherieregisters gepollt, ist auf einen Fallstrick des C-
Compilers zu achten. Für den Compiler erscheint der wiederholte Zugriff auf ein und dieselbe Speicherzelle
unnütz und optimierenswert. Er optimiert daher den Code derart, dass der Inhalt der Speicherzelle in ein in-
ternes Prozessorregister eingelesen wird, um danach ständig mit diesem Register zu arbeiten. Ein derartiges

169
Kapitel 5. Programmierung

Verhalten läßt sich abschalten, wenn bei der Variablendeklaration das Schlüsselwort volatile verwendet
wird. Dieses bewirkt, dass der Compiler die Optimierung für diese eine Variable ausschaltet.
Aus dem folgenden Codefragment
CheckStatus( char *RegisterAdr )
{
while( *RegisterAdr==0 ) // Wait for completness (status!=0)
;
}

erzeugt der Compiler folgenden Code:


.L5:
testb %al,%al
je .L5
leave
ret

Deutlich ist zu sehen, dass der Compiler den Inhalt des Peripherieregisters in ein Prozessorregister (al)
geladen hat, und er nun ständig den Inhalt dieses Registers überprüft. Da sich dieser bei dem gegebenen
Code jedoch nie verändern kann, wird das Programm in dieser Schleife hängen bleiben.
Bei Verwendung des Schlüsselwortes volatile aber, optimiert der Compiler die Zugriffe über den Pointer
nicht.
CheckStatus( char volatile *RegisterAdr )
{
while( *RegisterAdr==0 ) // Wait for completness (status!=0)
;
}

.L5:
movb (%edx),%al
testb %al,%al
je .L5
leave
ret

5.2.3.2. Time-Triggered
Kommen in der beschriebenen Aufgabenstellung die Ereignisse nicht mit Maximalfrequenz (im Abstand
von 8ms), könnte die vorhandene Rechenleistung auch für andere Aufgaben genutzt werden. Dazu wird
ein Laufzeit- oder Betriebssystem eingesetzt. Notwendige Voraussetzungen sind wieder Preemption und
Priorisierung. Durch die Verwendung des Laufzeit- oder Betriebssystems müssen folgende Zeiten zusätzlich
betrachtet werden:

• Scheduling tS=900µs
• Kontext Switch tK=100µs

Mit dieser Lösung könnten bei 100%iger Auslastung pro Sekunde 111 Anforderungen bearbeitet werden:
r = 1 / (tV+tS+tK)

170
Kapitel 5. Programmierung

Ist eine Applikation oder Softwarekomponente so aufgebaut, dass sie wie hier beschrieben in regelmässi-
gem Abstand (zyklisch) prüft, ob bestimmte Bedingungen erfüllt sind oder nicht, spricht man von einer
zeitgesteuerten Applikation (time triggered). Die Peripherie agiert beim Time-Triggered-Betrieb also rein
passiv.
Die Periode, mit der die entsprechende Task gestartet wird (Abtastzeit bzw. Prozesszeit tP), muß so kurz
gewählt werden, dass bei der Zustandserfassung kein Zustand verloren geht (Abtasttheorem) und dass au-
ßerdem noch eine Reaktion (1. Echtzeitbedingung) rechtzeitig erfolgen kann.

100 ms


ttot tV


warten verarbeiten

while( True ) while( True )


Lese Wert ein Sende Ereignis in 100 ms
Bearbeite Aufgabe Lese Wert ein
Warte (100 ms) Bearbeite Aufgabe
Warte auf Ereignis

Abbildung 5-22. Warten

Beim zeitgesteuerten Betrieb ist insbesondere auf drei Aspekte zu achten.

1. Die Totzeit bzw. Wartezeit, dass ist die Prozesszeit abzüglich der Verarbeitungszeit (ttot= tP-tV), zwischen
zwei Aufrufen der Task muß hardwareunabhängig realisiert sein. Vor allem in früheren Zeiten wurde
die Totzeit durch Verwendung einer einfachen Schleife realisiert.
for( i=0; i < 100000; i++ )
; // wait 10 milliseconds

Würde derartiger Code auf einem schnelleren Prozessor ablaufen, kommt es zu ungewolltem Verhalten,
da die Zeitbedingungen nicht mehr stimmten.

2. Bei der Parametrierung der Prozesszeit ist die eigene Verarbeitungszeit mit einzuplanen. Dazu wird
beispielsweise die Wartebedingung (Setzen des Timers) gleich zu Beginn festgelegt.
Dazu ein Beispiel (Bild Warten): Angenommen, von einem technischen Prozess soll alle 100 ms ein
Meßwert aufgenommen und verarbeitet werden. Der Ansatz, in einer Schleife den Wert einzulesen, zu
verarbeiten und dann 100 ms zu warten, führt zu größeren Ungenauigkeiten, da hier die Verarbeitungs-
zeit der Task nicht mitberücksichtigt wird. Diese Zeit zu berücksichtigen, fällt auch schwer, da sie von
vielen unterschiedlichen Faktoren abhängt. Daher muß man das “Warten” aufspalten. Zunächst wird
man einen Auftrag an das Betriebssystem absetzen, dass dieses der Task nach den 100 ms ein Ereignis
schicken soll (Aufruf mit explizitem Warten). Danach wird der Meßwert erfaßt und verarbeitet. Zuletzt
legt sich die Task auf das Zeitereignis schlafen.

171
Kapitel 5. Programmierung

3. Bei der Überbrückung von Totzeit sollte keine CPU-Leistung verbraucht werden. Wird ein Warten
über den Verbrauch von CPU-Leistung realisiert, spricht man wiederum von einer Busy Loop bzw.
einer aktiven Warteschleife. Busy Loops sind in jedem Fall zu vermeiden, und wenn dies nicht möglich
ist (wie oben dargestellt), so doch wenigstens hardwareunabhängig zu realisieren. Anstelle von Busy
Loops können die Systemcalls: wait, sleep, select oder poll verwendet werden.

5.2.3.3. Event-Triggered
Eine im Regelfall effizientere, dafür aber umso weniger deterministische Variante zum Aufbau von Steue-
rungssoftware stellt eine ereignisgesteuerte Applikation dar (event-triggered, Interruptbetrieb).
Die ereignisgesteuerte Applikation reagiert auf Ereignisse oder (Software-) Interrupts, die von anderen
Tasks oder vom Betriebssystem (z.B. Gerätetreiber) generiert werden. Ereignisse werden dabei synchron
zum Programmlauf bearbeitet, Interrupts asynchron. Im Falle des skizzierten technischen Prozesses könnte
beispielsweise jedesmal dann ein Interrupt von der Hardware generiert werden, wenn der technische Prozess
eine Anforderung an die Realzeitsteuerung stellt.
Dadurch kommt als weitere zu betrachtende Zeit die Zeit der Interruptanalyse tIntr hinzu. Ist im Beispiel
tIntr=1ms ergibt sich eine maximale Ankunftsrate der Anforderungen von 100 Anforderungen pro Sekunde.
Bei dieser Rate wäre die Realzeitsteuerung unter Verwendung der Interruptlösung zu 100% ausgelastet. Bei
einer zeitgesteuerten Lösung und Verwendung der optimalen Abtastzeit von 10ms wäre dagegen erst eine
Auslastung von 90% erreicht.
Somit ergibt sich also:

Verfahren Charakteristikum
Busy-Loop 100%ige Auslastung, unabhängig vom Bedarfsfall
Time-Triggered Die Auslastung ist abhängig vom gewählten
Abtastintervall und unabhängig vom Bedarfsfall.
Event-Triggered Die Auslastung ist abhängig vom Bedarfsfall.

5.2.4. Programmierstil
Sowohl bei der Konstruktion des Taskgebildes als auch bei der Auskodierung der einzelnen Tasks ist im
Umfeld von Realzeitsystemen auf folgendes zu achten [Färber1999]:
Konstruktion des Taskgebildes:

• Zeitkritische Tasks sollten möglichst keine bzw. wenige Systemaufrufe verwenden.


• Mit “kritischen Abschnitten” sollte möglichst sorgsam umgegangen werden, insbesondere auch bei Tasks
mit niedriger Priorität (Prioritätsinversion).
• Die Kommunikation zwischen Tasks ist sorgfältig zu entwerfen. Für die Kommunikation innerhalb eines
Rechners sollte vorzugsweise ein gemeinsamer Speicher verwendet werden, für die Kommunikation von
Tasks innerhalb verteilter Systeme Sockets.
• Code und Daten sollten für kritische Realzeitprozesse immer im Hauptspeicher stehen (Stichwort
Memory-Locking).

172
Kapitel 5. Programmierung

• Zeitaufwendige Aufgaben sollten in eigene Tasks verlagert werden.


• Ein Amok-laufender Thread kann mehr Schaden anrichten, als ein Amok-laufender Rechenprozess. Da-
her sollten insbesondere in sicherheitskritischen Anwendungen Rechenprozesse den Threads vorgezogen
werden.

Kodierung der Tasks:

• Rekursive Prozeduren sollten vermieden werden.


In Realzeitsystemen sind Rekursionen zu vermeiden, da Rekursionen zu hohem Speicherbedarf auf dem
Stack führen kann. Prinzipiell sind alle rekursiven Algorithmen auf iterative Algorithmen überführ-
bar. In Beispiel Rekursive und Iterative Berechnung der Fibonacci-Zahlen ist die iterative Lösung eines
zunächst rekursiv erscheinenden Problems angegeben. Berechnet werden die sogenannten Fibonacci-
Zahlen. Jede Fibonacci-Zahl ist die Summe ihrer beiden Vorgänger. Sie berechnet sich nach der folgenden
Vorschrift [Wirth 1983]:
fib(n+1) = fib(n) + fib(n-1) für n > 0
fib(1) = 1
fib(0) = 0

Da bei der rekursiven Lösung jeder Aufruf mit n > 1 zu zwei weiteren Aufrufen führt, wächst die Ge-
samtzahl der Aufrufe exponentiell, in einem Realzeitsystem wäre diese Art der Realisierung nicht zu
gebrauchen. Demgegenüber werden für die iterative Lösung n-1 Schleifendurchläufe benötigt, der Re-
chenzeitverbrauch dieser Lösung wächst linear.

Beispiel 5-1. Rekursive und Iterative Berechnung der Fibonacci-Zahlen


#include <stdio.h>

static int fibonacci_rekursiv( int n )


{
if( n == 0 ) return 0;
if( n == 1 ) return 1;
return( fibonacci_rekursiv( n-1 ) + fibonacci_rekursiv( n-2 ) );
}

static int fibonacci_iterativ( int n )


{
int i, fib0, fib1, fib2; // fib2=fib(n-2), fib1=fib(n-1), fib0=fib(n)

if( n==0 ) return 0;


fib2 = 0;
fib1 = 1;
fib0 = fib1 + fib2;
for( i=2; i<=n; i++ ) {
fib0 = fib1 + fib2;
fib2 = fib1;
fib1 = fib0;
}
return fib0;
}

int main( int argc, char **argv )


{
int i;

for( i=0; i<15; i++ )


printf( "%d ", fibonacci_rekursiv(i) );
printf("\n");

173
Kapitel 5. Programmierung

for( i=0; i<15; i++ )


printf( "%d ", fibonacci_iterativ(i) );
printf("\n");
return 0;
}

• Schleifen sollten eine feste Obergrenze aufweisen.


• Müssen doch Abbruch- bzw. Verzweigebedingungen auf Basis von variablen Werten realisiert werden,
sollte dennoch durch eine Zusatzbedingung der Abbruch nach einer maximalen Anzahl von Durchläufen
erfolgen (nmax). Also statt:
for( ; limit < CritPoint(v); limit=lnext(limit) ) {
...
}

sollte man besser:


for( n=0; (limit < CritPoint(v)) && (n < 5000);
limit=lnext(limit), n++) {
...
}
if( n == 5000 ) {
... // Fehlerbehandlung

verwenden. Damit wird die Schleife in jedem Fall nach 5000 Iterationen verlassen, und eine eventuell
notwendige Fehlerbehandlung kann durchgeführt werden.

• Datenstrukturen sollten statisch definiert werden und nicht erst zur Laufzeit dynamisch entstehen (führt
zu undeterministischem Verhalten, außerdem existiert das Risiko, dass der Speicher ausgeht).
• Bei der Verwendung von Bibliotheksfunktionen ist darauf zu achten, dass auch diese realzeitfähig sind.
• Rückgabewerte von Funktionen sind grundsätzlich in ihrem kompletten Definitionsbereich auszuwerten.

5.3. Schritthaltende Programmierung,


Echtzeitprogrammierung
Das Kapitel Schritthaltende Verarbeitung und Echtzeitbetrieb hat die Anforderungen an Echtzeitsysteme
aufgestellt und den Nachweis der Einhaltung behandelt. In diesem Kapitel werden programmiertechnische

174
Kapitel 5. Programmierung

Aspekte für die Realisierung einer Echtzeitsoftware behandelt.

while( 1 )
while( 1 ) while( 1 ) verarbeiten
einlesen einlesen abspeichern while( 1 )
abspeichern Event schicken ausgeben
verarbeiten
Event schicken (warten) (warten)
ausgeben

Eingabe Ausgabe verarbeiten ausgeben


verarbeiten einlesen

Puffer Puffer
Eingabewerte Ausgabewerte

Ereignis− bzw. Eingabegesteuert Ereignis− und zeitgesteuert

Abbildung 5-23. Ereignis- und zeitgesteuerte Systeme

Echtzeitsysteme zeichnen sich dadurch aus, dass sie nicht nur ereignisgesteuert, sondern insbesondere zu-
sätzlich zeitgesteuert sind (Ereignis- und zeitgesteuerte Systeme). Während bei den ereignis- bzw. einga-
begesteuerten Systemen die Verarbeitung durch die Eingabe getriggert wird, sind bei den zeitgesteuerten
Systemen die Vorgänge „Einlesen“, „Verarbeiten“ und „Ausgeben“ zeitlich entkoppelt.
Beispielsweise fallen in einem technischen Prozess Meßwerte mit einer Rate von 1000 Herz an und sollen
mit einer SPS weiterverarbeitet werden, die eine Zykluszeit von 10ms hat. Ausgaben sollen aber beispiels-
weise alle 17ms erfolgen.
Ereignisse bzw. Eingabewerte kommen mit einer (nicht konstanten) Rate rI an, werden mit einer Verarbei-
tungsrate rV verarbeitet und Ausgaben werden mit einer Rate rO ausgegeben. Im Regelfall kann man davon
ausgehen, dass rI ungleich rV und ungleich rO ist. Damit ist die Ausgabe nicht synchron zur Eingabe. Es
unterscheiden sich aber nicht nur die Raten, sondern auch die zugehörigen Phasenlagen. Problematisch ist
dies insbesondere zwischen Ein- und Ausgabe bzw. zwischen Soll- und Istwerten.

Soll
Ist

φ tI
tS
1 1 Phasenverschiebung
fS = t fI = t
S I

Abbildung 5-24. Phasen- und Frequenzunterschiede zwischen Soll- und Istwerten

175
Kapitel 5. Programmierung

Beispiel 5-2. Visualisierung einer Modellbahn (I)

Eine computergesteuerte Carrerabahn liefert vor kritischen Stellen, wie es beispielsweise Kurven darstel-
len, dem Steuerrechner eine Positionsinformation bezüglich des Fahrzeugs. Diese Information soll genutzt
werden, um damit eine kontinuierliche Visualisierung des Fahrzeugs vorzunehmen. Kontinuierliche Visua-
lisierung bedeutet aber, dass mindestens mit 20 Bildern/Sekunde das bewegte Fahrzeug dargestellt wird.

Beispiel 5-3. Zeitsynchronisierung zwischen Rechnern

Vernetzte Rechner benötigen eine einheitliche Zeitbasis. Damit die Uhren in zwei Rechnern gleich laufen,
müssen die Uhren mit der exakt identischen Frequenz betrieben werden. Außerdem müssen die Uhren in
den Rechnern zum gleichen Zeitpunkt schalten.

Beispiel 5-4. Voice over IP (VoIP)

Ein kontinuierlicher Datenstrom wird durch die Datenübertragung in Pakete zerlegt. Diese Pakete werden
unsynchronisiert übertragen und müssen auf der Empfangsseite wieder zu einem kontinuierlichen Aus-
gangssignal zusammengesetzt werden.

Sind Ein- und Ausgaben nicht zeitsynchron, müssen Annahmen über den Prozesszustand zwischen zwei Er-
eignissen getroffen werden. Im Beispiel Visualisierung einer Modellbahn (I) könnte die Annahme getroffen
werden, dass das Fahrzeug sich zwischen den beiden Positionen (der zuletzt gemeldeten und der kommen-
den) mit einer konstanten Geschwindigkeit bewegt. Diese Annahmen werden in ein Prozessmodell (Modell
des technischen Prozesses) implementiert. Im genannten Beispiel ist das zugehörige Prozessmodell durch
die Formel v=s/t charakterisiert.
Ein Modell spiegelt die Wirklichkeit nur mit einer endlichen Genauigkeit wieder. Ziel der Steuerung ist es,
durch ein möglichst genaues Modell zu qualitativ hochwertigen (ausreichend hochwertigen) Ausgaben zu
kommen.
Dazu ist eine dynamische Anpassung des Modells bzw. der Modellparameter an die Realität notwendig.
An Synchronisationspunkten (dort, wo verwertbare Meßwerte des realen technischen Prozesses zur Verfü-
gung stehen) werden Abweichungen (Fehler) zwischen dem Modell und der Realität berechnet.
Fehler=Sollwert-Istwert

Ist der Fehler außerhalb eines Toleranzbereiches muß eine Anpassung sowohl des Modells (Einsynchroni-
sieren) als auch der Ausgaben vorgenommen werden. Diese Anpassung darf dann nicht sprunghaft vollzo-
gen werden, wenn in Zwischenschritten (andere) Ereignisse ausgelöst werden. Eine aktuelle Uhrzeit darf
beispielsweise in einem System nicht einfach eingestellt werden, weil durch den bei der Einstellung stattfin-
denden Zeitsprung möglicherweise Cronjobs (zu bestimmten Zeitpunkten aufzurufende Tasks) übersprun-
gen werden. Wird bei der Visualisierung die Position des Fahrzeugs sprunghaft verändert, ergibt sich für
den Betrachter keine kontinuierliche, natürliche Visualisierung mehr.
Anpassungen erfolgen also in den meisten Fällen in Schritten mit der Rate rO. Die Ausgaben selbst werden
mit einem Korrekturwert modifiziert um den bereits existenten Fehler wieder auszugleichen:
Ausgabewert = Normalwert + Korrekturwert

176
Kapitel 5. Programmierung

Die Größe dieses Korrekturwertes und die Rate, mit der diese Werte ausgegeben werden, ergeben sich
durch:

1. Die Größe der Abweichung.


2. Triggerpunkte für andere Systemteile (Beispiel NTP und Cronjobs).
3. Zur Verfügung stehenden Rechenzeit.

vmodell= 1m vreal= 1.25m


s
s

1 ∆ s = 1m 2 3
t0 t1 t2

Abbildung 5-25. Prozessnachführung bei einer Modellbahn

Beispiel 5-5. Visualisierung einer Modellbahn (II)

Jeweils an den markanten Stellen erkennt die Visualisierungstask die reale Position der Fahrzeuge. Ist die
reale Position ungleich der Position, die gerade angezeigt wird, wird das Fahrzeug nicht auf die neue Posi-
tion „gebeamt“ (sprunghafte Positionsanpassung). Stattdessen wird die Geschwindigkeit, mit der sich das
Fahrzeug im Modell bewegt, angepasst. Der für die weitere Visualisierung verwendete Geschwindigkeits-
wert besteht aus zwei Komponenten:

1. „reale“ Geschwindigkeit des Fahrzeugs aufgrund des angepassten Modells und


2. Korrekturwert um den bisher aufgetretenen Fehler wieder auszugleichen.

Insbesondere der Korrekturwert wird nur zeitlich befristet eingesetzt. Ist der Fehler ausgeglichen, kann mit
dem normalen Wert weitergearbeitet werden.
Das Prozessmodell der Modellbahn sei so parametriert, dass eine Geschwindigkeit von v=1m/s angenom-
men wird. Wird der Visualisierungstask das Überfahren des Sensors 1 zum Zeitpunkt t0=0s gemeldet, be-
rechnet diese aufgrund des Modells, dass der 1m entfernte Sensor 2 zum Zeitpunkt t1=1s überfahren werden
wird.
Hat das Auto jedoch eine reale Geschwindigkeit von v=1.25m/s wird der Sensor 2 bereits zum Zeitpunkt
t1=0.8s überfahren( siehe Bild Prozessnachführung bei einer Modellbahn). Das führt zu den wesentlichen
zwei Erkenntnissen in der Visualisierung:

1. Das Fahrzeug befondet sich 20cm von der realen Position entfernt (Abweichung von Soll und Ist).
2. Das Prozessmodell arbeitet mit einer fehlerhaften Geschwindigkeit.

Maßnahmen:

1. Modellparameterkorrektur:
v=s/t; s=1m; t=0.8s; v=1m/0.8s=1.25m/s

177
Kapitel 5. Programmierung

Die reale Geschwindigkeit des Fahrzeugs beträgt 1.25m/s.

2. Fehlerausgleich:
Das Fahrzeug wird voraussichtlich zum Zeitpunkt t2=1.6s den nächsten Sensor (Synchronisationspunkt)
erreichen. In der Visualisierung muß in dieser Zeit 1.20m zurückgelegt werden. Damit wird für die
Visualisierung bis zum nächsten Sensor mit einer korrigierten Geschwindigkeit gearbeitet:
vkorrigiert =1.2m/0.8s=1.5m/s

Modell

Modellparameter Extra−
polation
Ausgaben

Eingabe Modell− Fehler− Gutwert + Korrekturwert

korrektur ausgleich Ausgabe

Abbildung 5-26. DFD einer zeitsynchronen Verarbeitungseinheit

Die zeitsynchrone Verarbeitung von Eingaben zu Ausgaben besteht damit aus den Blöcken Extrapolation,
Modellkorrektur und Fehlerausgleich (siehe Abbildung DFD einer zeitsynchronen Verarbeitungseinheit).
In der Extrapolation werden in der für die Ausgabe notwendigen Granularität (Rate) Ausgabewerte berech-
net. Aufgrund des an den Synchronisationspunkten durchgeführten Soll-/Istvergleichs wird eine Modell-
korrektur durchgeführt und außerdem findet ein (zeitlich befristeter) Fehlerausgleich statt.

178
Kapitel 5. Programmierung

timer

Zeitpunkt + Ausgabewert

Ausgaben

Eingaben
Berechnung Ausgabe
Gutwert + Korrekturwert

Modell Modellparameter

Abbildung 5-27. Systemarchitektur einer zeitsynchronen Ausgabe

Da - wie bereits eingangs erwähnt - die Raten, mit denen Daten eingelesen, verarbeitet und ausgegeben
werden unterschiedlich sind, muß eine Entkopplung zwischen diesen Aufgaben vorgenommen werden.
Prinzipiell kann die Entkopplung zunächst durch die Ablage der Daten in Puffer vonstatten gehen (siehe
Abbildung Systemarchitektur einer zeitsynchronen Ausgabe). Die in den Puffer abgelegten Werte benötigen
Qualitätsmerkmale wie Gültigkeit und Alter (Zeitstempel bzw. bei der Ausgabe Zeitpunkt für die Ausgabe).
Die Teilaufgaben Einlesen, Verarbeiten und Ausgeben können dann entweder als einzelne Rechenprozesse
(z.B. Threads) oder als ein einzelner Rechenprozess realisiert werden.
Bei einer Realisierung als ein einzelner Rechenprozess muß in einer Schleife auf mehrere Bedingungen
gewaretet werden:

• alle Eingabeereignisse
• alle Verarbeitungsereignisse
• alle Ausgabeereignisse.

Abhängig davon, zu welcher Gruppe ein Ereignis gehört, wird in die entsprechenden Programmteile ver-
zweigt.
Bei einer Realisierung mit Hilfe mehrerer Rechenprozesse muß zwischen den Rechenprozessen ein Kon-
trollfluß (z.B. Synchronisation über Events) installiert werden.
Die Realisierung der einzelnen Rechenprozesse wiederum ist ebenfalls auf unterschiedliche Art und Weise
möglich:

1. Die Daten werden getaktet (zeitsynchron) verarbeitet oder


2. die Daten werden soweit sie vorliegen verarbeitet.

Durch die Entkopplung ist es durchaus möglich, dass beispielsweise nach Überfahren eines Sensors die
Visualisierung bis zum nächsten Synchronisationspunkt alle notwendigen Ausgabewerte berechnet und in

179
Kapitel 5. Programmierung

den Ausgabepuffer ablegt. Ist die Eingabe verarbeitet, wartet dieser Programmteil auf die Benachrichtigung
bezüglich neuer Daten.
Bei der zeitsynchronen Verarbeitung werden mit jedem Takt neue Ausgabewerte berechnet.

Fußnoten
1. Das P der P-Operation stammt aus dem holländischen und steht für passeeren
2. V leitet sich vom holländischen vrijgeven ab

180
Kapitel 6. Echtzeitsysteme in sicherheitskritischen
Anwendungen

6.1. Zuverlässigkeit und Sicherheit

6.1.1. Grundlagen

6.1.1.1. Motivation
Dem Betreiber eines Webschops, bei dem über das Internet Kunden ihre Waren elektronisch aussuchen und
bestellen (eCommerce) ist es wichtig, dass der Webshop ständig verfügbar ist. Welche Maßnahmen kann
er aber ergreifen, um eine möglichst hohe (durchgehende) Verfügbarkeit zu gewährleisten? Im einfachsten
Fall kauft er sich eine zweite Webserver-Hardware. Fällt der erste Webserver - und damit der Webshop -
aus, schaltet er die redundante Hardware ein und der Shop ist wieder verfügbar.
Ähnlich wie beim Webshop existieren auch an Bord moderner Flugzeuge mehrere redundante Rechner.
Dadurch wird verhindert, dass das Flugzeug abstürzt, wenn ein Steuerungsrechner ausfällt. Wie aber handelt
ein Pilot, der gerade in Frankfurt am Main zu einem Atlantikflug mit Ziel JFK in New York gestartet ist,
wenn ein Rechner ausfällt? Da der Pilot für die Sicherheit von Passagieren und Maschine verantwortlich
ist, wird er sofort den nächstgelegenen Flughafen anfliegen. Trotz Ausfall eines Steuerungssystems ist das
Flugzeug zwar noch voll flugfähig, der Ausfall allerdings des zweiten Rechners könnte katastrophale Folgen
haben.
Diese beiden Beispiele zeigen, dass man redundante Systeme sowohl zur Steigerung der Verfügbarkeit, als
auch zur Steigerung der Sicherheit verwenden kann. In vielen Einsatzgebieten, z.B. beim Space-Shuttle,
benötigt man die hohe Verfügbarkeit ebenso wie eine hohe Sicherheit.
Bevor im folgenden auf Verfügbarkeits- und Sicherheitskonzepte eingegangen wird, müssen die grundle-
genden Begriffe geklärt werden.

6.1.1.2. Begriffsbestimmung

Zuverlässigkeit
“Fähigkeit einer Betrachtungseinheit, innerhalb der vorgegebenen Grenzen denjenigen durch den Ver-
wendungszweck bedingten Anforderungen zu genügen, die an das Verhalten ihrer Eigenschaften wäh-
rend der gegebenen Zeitdauer gestellt sind.” [DIN 40041]

Sicherheit
“Sicherheit ist eine Sachlage, bei der das Risiko nicht größer als das Grenzrisiko ist.” [DIN/VDE 31
000 Teil2] Als Grenzrisiko ist dabei das größte, noch vertretbare Risiko zu verstehen [Hal99].

Verfügbarkeit
Die Wahrscheinlichkeit, dass ein System innerhalb eines spezifizierten Zeitraums funktionstüchtig
(verfügbar) ist.

181
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Unverfügbarkeit
Die Wahrscheinlichkeit, dass ein System innerhalb eines spezfizierten Betrachtungszeitraums funkti-
onsuntüchtig (unverfügbar) ist.

6.1.1.3. Mathematische Grundlagen


Ein junger Student erwirbt einen Rechner. Leider zeigen sich gleich nach etwa 4 Betriebsstunden erste
Mängel. Für die Fehlersuche, Ersatzteilbeschaffung und Reparatur benötigt der Student 1 Stunde. Danach
läuft der Rechner weitere 96 Stunden problemlos, um abermals auszufallen. Diesmal dauert die Reparatur
1.5 Stunden. Weitere 96 Stunden später fällt der Rechner erneut aus, ist aber nach bereits einer halben
Stunden wieder einsatzbereit. Die Zeit bis zum nächsten Ausfall (TBF, Time Between Failure) beträgt dann
72 Stunden, die Zeit zur Reparatur (TTR, Time To Repair) beträgt eine halbe Stunde. Insgesamt ergeben
sich über einen Beobachtungszeitraum von 376 Stunden die folgenden Kennzahlen:

TBF TTR
96h 1.5h
96h 0.5h
72h 0.5h
48h 0.5h
44h 1h
16h 1h
4h 1h

Aus diesen Werten berechnet der Student die durchschnittliche Zeit bis zum nächsten Ausfall (MTBF, Mean
Time Between Failure):
MTBF=376h/7=53.7h

Ebenso berechnet er die durchschnittliche Reparaturzeit (MTTR, Mean Time To Repair):


MTTR = 6/7 = 0.857h = 51 Minuten

Der Student berechnet weiterhin die Wahrscheinlichkeit dafür,dass System verfügbar anzutreffen1. Dazu
setzt er die MTBF in Beziehung zur Gesamtbetriebszeit:
p = MTBF/(MTBF+MTTR) = 376/382 = 98.43%

beziehungsweise die Wahrscheinlichkeit, dass System im unverfügbaren Zustand anzutreffen:


q = MTTR/(MTBF+MTTR) = 6/382 = 1.57%

182
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Zyklus 1 Zyklus 2 Zyklus 3

v a v a v a

TBF TBF
TTR

v = verfügbar TBF: Time Between Failure


a = ausgefallen TTR: Time To Repair

Abbildung 6-1. Zeitverlauf des Systemzustands [Färber94]

Eine Komponente kann sich in den Zuständen “verfügbar” (funktionstüchtig) oder “ausgefallen” befinden.
Eine Komponente wird im ausgefallenen Zustand im Regelfall repariert, damit das System wieder verfügbar
wird. Die Zeit, während der das System ausgefallen ist, wird daher auch als “Reparaturzeit” (TTR, Time
To Repair) bezeichnet. Die Zeit, in der das System verfügbar ist, wird als die Zeit zwischen den Ausfällen
(TBF, Time Between Failure) bezeichnet.
Summiert man die Zeiten, in denen die Komponente verfügbar ist, über einen genügend langen Zeitraum auf
und bildet hiervon das arithmetische Mittel, kann man die durchschnittliche Verfügbarkeitsdauer (MTBF,
Mean Time Between Failure) angeben. Das gleiche gilt für die mittlere Dauer der Unverfügbarkeit:

Gleichung 6-1. MTBF und MTTR

n
MTBF = lim
n oo
1
n Σ TBF
i=1
i

n
MTTR = lim
n oo
1
n Σ TTR
i=1
i

Möchte man die Wahrscheinlichkeit angeben, mit der sich die Komponente im Zustand “verfügbar” (p,
Dauerverfügbarkeit) oder “ausgefallen” (q, Dauerunverfügbarkeit) befindet, muß man die Zeiten der Ver-
fügbarkeit (die Summe der Betriebszeiten) in Beziehung zur Gesamtzeit (Beobachtungszeitraum) setzen,
bzw. für die Dauerunverfügbarkeit die Ausfallzeiten in Beziehung zum Beobachtungszeitraum setzen. p
und q lassen sich mathematisch auch über die MTBF und die MTTR darstellen.

Gleichung 6-2. Dauerverfügbarkeit und Dauerunverfügbarkeit

p= MTBF
(Verfügbarkeit)
MTTR + MTBF

q= MTTR
(Unverfügbarkeit)
MTTR + MTBF
mit p + q = 1

Die (im Mittel) erwartete Zahl von Ausfällen wird mit λ (Ausfallrate) beschrieben:

183
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Gleichung 6-3. Ausfallrate

1
λ=
MTBF

Zeitlich betrachtet sind die Ausfälle nicht gleichverteilt. Nach einer Reparatur ist die Wahrscheinlichkeit
sehr groß (nahezu 100%), dass das System wieder funktionstüchtig, sprich verfügbar ist; nach einer genü-
gend langen Zeit ist diese Wahrscheinlichkeit sehr gering (nahe 0%). Die Relation zwischen Verfügbarkeit
und Zeit gibt die Gleichung Verfügbarkeit in Abhängigkeit von der Zeit an:

Gleichung 6-4. Verfügbarkeit in Abhängigkeit von der Zeit

ρ λ −(λ+ρ)t
p(t) = + e
ρ+λ ρ+λ

Bild Verfügbarkeitsfunktion [Färber 1994] stellt die Funktion p(t) für ausgewählte Reparatur- bzw. Aus-
fallraten dar.

p(t)
ρ=

ρ=k λ Dauerverfügbarkeit
ρ 1
=
λ +ρ 1
1+ k

ρ=0

Abbildung 6-2. Verfügbarkeitsfunktion [Färber 1994]

Für eine gegebene Reparatur- und Ausfallrate ungleich Null ergibt sich die Dauerverfügbarkeit nach einem
entsprechend langen Zeitraum. Wird das System nicht reparariert (Reparaturrate=0), sinkt die Verfügbarkeit
auf 0, ist die Reparaturzeit beliebig klein (0), ist das System ständig verfügbar.

184
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

q
Frühausfälle statistische Ausfälle Verschleiß

Abbildung 6-3. Badewannenkurve [Färber94]

Die Gleichung stellt die Verfügbarkeitswahrscheinlichkeit nur in erster Näherung dar. In der Realität gilt
vielmehr die sogenannte Badewannenkurve (Bild Badewannenkurve [Färber94]). Ist ein System neu, gibt
es eine hohe Wahrscheinlichkeit dafür, dass das System ausfällt. Man spricht von den sogenannten Frühaus-
fällen. Danach kommt die Phase der statistischen Ausfälle, die durch die angegebene Gleichung beschrie-
ben wird. Bei einem hohen Alter des Systems kommt es durch Alterung und Verschleiß erneut vermehrt zu
Ausfällen.

funktions−
p(t)
tüchtig

ρ λ

ausgefallen q(t)

Abbildung 6-4. Systemzustand bezüglich der Funktionstüchtigkeit [Färber94]

Die bisherigen Betrachtungen gelten für eine Komponente. Möchte man die Verfügbarkeit eines Systems
angeben, kennt aber nur die Verfügbarkeit der Einzelkomponenten, läßt sich die Gesamtverfügbarkeit nach
folgenden Regeln berechnen.

185
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

K K K

Abbildung 6-5. Serienschaltung

Serienschaltung (Abhängige Komponenten). Ist das System nur dann verfügbar, wenn alle Einzelkom-
ponenten verfügbar sind (beispielsweise sei ein Rechnersystem nur dann verfügbar, wenn die CPU, der
Speicher und das Peripheriemodul verfügbar sind), spricht man von einer Serienschaltung. Bei einer Se-
rienschaltung erhält man die Gesamtverfügbarkeit durch Multiplikation der Einzelverfügbarkeiten. Das Er-
satzschaltbild für eine Serienschaltung ist in Bild Serienschaltung dargestellt. Sind die Unverfügbarkeiten
qi der Komponenten darüber hinaus sehr klein, läßt sich die Gesamtunverfügbarkeit auch als Summe der
Einzelunverfügbarkeiten angeben. Die Ausfallrate des Gesamtsystems ist die Summe aus den Ausfallraten
der Einzelkomponenten.
Bei einer Serienschaltung ist die Gesamtverfügbarkeit kleiner als die kleinste Einzelverfügbarkeit.

Gleichung 6-5. Verfügbarkeit einer Serienschaltung

n
p
gesamt
= Πp
i=1
i

für q << 1:
n n
p
gesamt
= 1−q
gesamt
= Π
i=1 i Σ
(1−q ) ≈1− qi
i=1
n
qgesamt ≈ Σq
i=1
i
mit p = Verfügbarkeit
n

λgesamt = Σλ
i=1
i
q = Unverfügbarkeit
λ = Ausfallrate

Abbildung 6-6. Parallelschaltung

Parallelschaltung (redundante Komponenten). Ist das System verfügbar, sobald eine von mehreren Kom-
ponenten verfügbar ist (redundantes System), spricht man von einer Parallelschaltung. Bei der Parallelschal-
tung ergibt sich die Gesamtunverfügbarkeit aus dem Produkt der Einzelunverfügbarkeiten. Damit wird die
Gesamtunverfügbarkeit deutlich kleiner als die Einzelverfügbarkeiten.

186
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Gleichung 6-6. Unverfügbarkeit einer Parallelschaltung

n
qgesamt = Πq
i=1
i

pgesamt = 1−qgesamt

K
K
K

Abbildung 6-7. Parallelschaltung mit Koppelkomponente

6.1.1.4. Redundante Systeme


Im Regelfall besteht ein System nicht nur aus abhängigen oder redundaten Komponenten, sondern
aus einer Mixtur von beiden. Redundante Systeme benötigen beispielsweise eine Koppeleinrichtung,
über die die Ergebnisse der beiden Komponenten weitergeführt werden. Damit ergibt sich das in Bild
Parallelschaltung mit Koppelkomponente dargestellte Ersatzschaltbild.

Merke: Zur Berechnung von Verfügbarkeiten erstellt man ein Verfügbarkeitsersatzschaltbild nach dem
vorgestellten Schema. Dabei ist zu beachten, welche Anforderungen an die Betriebsart (sichere Be-
triebsart gegenüber einem möglichst verfügbaren System) das System zu erfüllen hat.

Ein redundantes System kann entweder mit hoher Verfügbarkeit betrieben werden, oder als besonders si-
cheres System. Stehen beispielsweise 2 redundante Rechner zur Verfügung, lassen sich diese in einem soge-
nannten 1:2 (sprich 1 aus 2) System oder einem 2:2 (2 aus 2) System betreiben. Bei einem 1:2 System muß
ein Rechner von zweien verfügbar sein, damit das Gesamtsystem verfügbar ist, bei einem zwei aus zwei
System (sicherheitsgerichtet) müssen beide Rechner verfügbar sein, damit das Gesamtsystem verfügbar ist.
Bei einem sicherheitsgerichteten System muß man daher zur Bestimmung der Gesamtverfügbarkeit das
Ersatzschaltbild als Serienschaltung angeben (Rechner 1 und Rechner 2 und Koppelelektronik müssen ver-
fügbar sein).
Wird das 2:2 System nach dem Schema der möglichst hohen Verfügbarkeit betrieben, setzt man eine Par-
allelschaltung der beiden Rechner in Serie mit der Koppelelektronik an (Rechner 1 oder Rechner 2 muß
verfügbar sein und die Koppelelektronik muß verfügbar sein.
Im Verfügbarkeitsbetrieb werden redundante Rechner nach unterschiedlichen Strategien betrieben:

cold standby (statische Redundanz)


Fällt eine Komponente aus, wird die redundante Komponente aktiviert. Da die bis zum Zeitpunkt des
Ausfalls deaktivierte Komponente nicht den aktuellen Betriebszustand (z.B. des technischen Prozes-
ses) kennen kann, wird im Regelfall ein kompletter Neuanlauf durchgeführt.

187
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

hot standby (dynamische Redundanz)


Die redundante Komponente ist aktiviert und kennt den aktuellen Systemzustand des Gesamtsystems.
Ausgaben bzw. Ergebnisse stammen jedoch nur von der Hauptkomponente. Sobald ein Fehler in der
Hauptkomponente identifiziert wird, wird auf die redundante Komponente umgeschaltet.

Doppelsystem
Die redundanten Komponenten bearbeiten jeweils Teilaufgaben (damit gibt es keine Hauptkompo-
nente). Wird bei einem System ein Fehler festgestellt, übernimmt die redundante Komponente die
Aufgaben der defekten Komponente.

6.1.1.5. Zuverlässigkeitssteigerung
Um insbesondere die Verfügbarkeit eines Systems zu erhöhen (man spricht in diesem Kontext von High
Availability) müssen in unterschiedlichen Bereichen Maßnahmen getroffen werden:

• Infrastruktur
• Hardware
• Software
• Management

Wechselspannung

Gleichspannung
Interrupt
wird
ausgelöst
geglättete Spannung Betriebsspannung
Power−fail−Spannung
Minimal−Spannung

z.B. 10 ms

Abbildung 6-8. Power-fail-Interrupt

Infrastruktur
Zu den Maßnahmen bezüglich der Infrastruktur gehören:
• Sicherung der Stromversorgung. Damit ein Ausfall der Stromversorgung nicht zum Ausfall des
Rechnersystems führt, wird dieses entweder durch eine unterbrechungsfreie Stromversorgung
(USV), durch ein Notstromaggregat oder durch beides gesichert.

188
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Muß der Betrieb bei Stromausfall nicht zwangsläufig aufrecht erhalten werden, reicht es oft auch
schon aus, den Stromausfall zu dedektieren und am Rechner einen Interrupt auszulösen (Power-
fail-Interrupt). Der Interrupt selbst wird vom Netzteil ausgelöst. Das Netzteil speichert (meist in
Kondensatoren) Energie. Damit werden die Spannungslücken geglättet, die bei der Gleichrichtung
der Wechselspannung entstehen (siehe Bild Power-fail-Interrupt). Fällt jedoch die Spannung unter
eine kritische Betriebsspannung (Power-fail-Spannung), wird ein Interrupt ausgelöst. Dem Steue-
rungssystem bleibt jetzt noch eine kurze Zeitspanne, innerhalb derer der technische Prozess in einen
sicheren Zustand und die Steuerung in einen konsistenten Zustand gebracht werden müssen.

• Klimatisierung. Eine der wichtigsten Ursachen für Rechnerausfälle stellt die Überhitzung dar. Sie
führt zunächst zu schwer zu dedektierende sporadische Fehler, später schließlich zum Totalausfall.
Ein optimales Betriebsklima wird durch Klimatisierung erreicht. Auch gegen den Ausfall der dazu
notwendigen Klimaanlage sollten Maßnahmen (z.B. mobile Ersatz-Klimageräte) getroffen werden.
• Schutz vor Feuer, Nässe, Blitzschlag und Einbruch. Zum Schutz vor Feuer, Blitzschlag, Näs-
se, Einbruch oder anderen mechanischen Beschädigungen werden Rechner meist in Rechnerräume
untergebracht. Zutritt zu diesen Räumen ist nur in den seltensten Fällen (z.B. Austausch von Rech-
nerkomponenten, Austausch von Datenbändern) notwendig.

Hardware
Die möglichen Hardeware-Maßnahmen finden einmal auf der Systemebene und ein zweites Mal auf
der Komponentenebene statt:
• Redundanz der Systemkomponenten. Durch Vervielfachung (meist Verdoppelung) kann die Ver-
fügbarkeit erhöht werden. Problematisch bei diesem Ansatz ist jedoch, den Ausfall zu dedektieren,
den Systemzustand des ausgefallenen Systems auf die redundante Ersatzukomponente zu übertragen
und diese schließlich zu aktivieren.
Die Überwachung einer redundant ausgelegten Komponente muß auf Systemebene erfolgen. Dazu
kann beispielsweise eine Überwachungs- bzw. Koppeleinrichtung dienen. Diese kann
• aktiv oder
• passiv
die Komponente überwachen. Wird die Komponente passiv überwacht, muß die redundante Kom-
ponente in periodischen Abständen ein Lifesign (Lebenszeichen) übermitteln. Dieses Lifesign setzt
in der Überwachungseinrichtung einen Watchdog zurück. Wird der Watchdog nicht rechtzeitig zu-
rückgesetzt, schaltet die Überwachungseinrichtung auf die redundante Komponente um.
Bei der aktiven Überwachung wird die zu überwachende Komponente periodisch mit einer Anfor-
derung beschickt, die das System im funktionstüchtigen Zustand beantwortet. Beispiel: Eine Netz-
komponente kann dadurch überwacht werden, indem man ihr regelmässig ein “echo request” Paket
sendet.
Da die Komponenten meistens interne Zustände besitzen, müssen diese beim Ausfall bekannt sein
und auf die redundante Ersatzkomponente übertragen werden (Vermeidung von Informationsver-
lust). Dieses stellt die größte Herausforderung dar:

• Bei Systemen im Hot Standby wird der interne Zustand regelmässig mit dem Ersatzsystem abge-
glichen. Dieser Abgleich muß so häufig erfolgen, dass ein Umschalten ohne Informationsverlust
zu jedem beliebigen Zeitpunkt möglich ist.
• Die wohl verbreitetste Technologie ein redundantes System im Hot Standby zu betreiben ist die,
dass das Ersatzsystem parallel mit der aktiven Komponente arbeitet. Es bekommt die gleichen
Eingangsinformationen und berechnet mit den gleichen Applikationen die Ausgabewerte. Die

189
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Überwachungs- bzw. Koppeleinrichtung leitet aber diese Ausgabewerte solange nicht an den
technischen Prozess (bzw. die nachfolgende Komponente) weiter, solange die aktive Komponente
funktionstüchtig ist (Beispiel Space Shuttle).
• Im Cold Standby muß die Komponente ihren Systemzustand ständig (oder zumindest an den re-
levanten Punkten) auf ein Medium sichern, auf das das Ersatzsystem auch beim Ausfall der Kom-
ponente Zugriff hat. Hierbei ist auch der Fall zu berücksichtigen, dass sowohl die Komponente
als auch das Medium, auf das der Zustand gesichert wird, ausfallen kann.

• Redundanz der Einzelkomponenten. Auf Komponentenebene werden:


• CPU
• Speicher
• Festplatten (RAID) und
• Netzteile
redundant ausgelegt.
• Weitere Maßnahmen die nicht auf Redundanz beruhen. Während sich durch Redundanz die
Verfügbarkeit eines Gesamtsystems erhöhen kann, kann die Verfügbarkeit der Einzelkomponenten
durch folgende Maßnahmen gesteigert werden:
• Auswahl zuverlässiger Bauelemente (z.B. Mil-Varianten).
• Steigerung der mechanischen Festigkeit (Vibrationsschutz).
• Fixierung löslicher Elemente (Lackierung von Schrauben).
• Vermeidung von Steckkontakten.
• Wärmeschutz.
• Betriebsdatenüberwachung der Komponente. Bei dieser Maßnahme werden Temperaturen und
Spannungen innerhalb der Komponente überwacht und geregelt. Eine zu hohe Temperatur (Über-
hitzung) bei einem Rechnerkern kann beispielsweise dazu führen, dem Prozessor durch Runter-
takten weniger Leistung abzuverlangen. Eine Betriebsdatenerfassung wird bereits bei handelsüb-
lichen PC-Motherboards angeboten.
• Vorbeugende Wartung.

Software
Um eine hohe Verfügbarkeit gewährleisten zu können sind auch softwareseitig eine Reihe von Maß-
nahmen notwendig:
• Software ermöglicht die Überwachung der Systemkomponenten bzw. auch der Diagnose der Feh-
lerursache.
• Die Umschaltung und der Abgleich zwischen dem aktiven System und dem Ersatzsystem ist/muß
im Regelfall durch Software unterstützt sein.
• Um Informationsverlust bei Ausfall eines Systems vorzubeugen muß eine Backupstrategie für Daten
und Systemzustände existieren.

190
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Management
Managementseitig sind folgende Dinge zu regeln:
• Wartung: Es ist dafür zu sorgen, dass die kritischen Systeme ständig überwacht und gewartet wer-
den. Auch der regelmässige Austausch wichtiger (alternder) Komponenten kann sinnvoll sein. Ein
großes und oft wenig beachtetes Problem beim Austausch von Komponenten besteht - gerade in der
Automatisierungstechnik mit ihren langen Systemlaufzeiten - darin, dass Ersatzkomponenten nicht
mehr verfügbar sind. Gibt es Nachfolgeprodukte muß darauf geachtet werden, dass diese den glei-
chen Hardware- und Softwarestand, wie die im System (in der Anlage) verwendeten Komponenten,
haben.
Da ältere Komponenten oftmals nicht mehr zu kaufen sind, legen sich viele Firmen Ersatzteile ins
Lager. Fällt eine Komponente aus, wird das Ersatzteil aus dem Lager eingesetzt. Aber auch bei
diesem Verfahren muß das Lager gewartet werden. Sind beispielsweise die Softwarestände einer
Komponente im System und der Ersatzkomponente im Lager nicht auf dem gleichen Stand, kann
es Probleme geben, wenn die aktive Komponente ausfällt und das Ersatzteil aus dem Lager ein-
gebaut wird. Um also Lager und System auf dem gleichen Stand zu halten, sind organisatorische
(management) Maßnahmen notwendig.

• Staffing: Fällt das System oder auch nur eine Komponente des Systems aus, sind Eingriffe durch
den Menschen notwendig, um das betrachtete System wieder in den funktionstüchtigen Zustand
zu bringen: Die Fehlerursache muß festgestellt und analysiert werden, redundante Systeme müssen
aktiviert werden und Ersatzteile eingebaut werden. Aus diesem Grunde ist dafür zu sorgen, dass
genügend kompetente Mitarbeiter zumindest erreichbar und in kürzester Zeit vor Ort sind.
• Notfallpläne: Um Stillstands- bzw. Ausfallzeiten zu verkürzen sind insbesondere Notfallpläne un-
umgänglich. Diese beinhalten strukturiert und Punkt für Punkt (Listen) alle Maßnahmen die not-
wendig sind, um in der kürzest möglichen Zeit die Systeme wieder in den Zustand verfügbar zu
überführen. Notfallpläne beinhalten:
• Eine Fehlerklassifizierung: Nicht alle auftretenden Fehler sind gleich kritisch. Insbesondere lassen
sich nicht tolerierbare Fehler von den tolerierbaren Fehlern unterscheiden. Unter tolerierbare
Fehler oder Fehlertoleranz versteht man den Umstand, dass trotz des Fehlers das System dennoch
die geforderte Funktion erbringen kann (weil beispielsweise automatisch auf ein Ersatzsystem
umgeschaltet wird).
• Ausgehend vom Fehlerbild enthalten die Notfallpläne Listen, die zur Identifikation der defekten
Komponente führen (Fehlerlokalisierung, Diagnose).
• Notfallmaßnahmen
• Die Fehlerkritikalität bestimmt auch die notwendige Informationspolitik: Wer (Techniker, Mana-
ger, Kunden) ist bei welchem Fehler zu welchem Zeitpunkt zu informieren.

6.1.1.5.1. RAID
Unter RAID (Redundant Array of Inexpensive Disks) versteht man eine Technologie, um einzelne Festplat-
ten zu einem preiswerten, schnellen und sicheren Platten-Cluster zusammenzubinden. Dabei sind insgesamt
6 sogenannte RAID-Level spezifiziert worden, die unterschiedliche Eigenschaften bezüglich Zuverlässig-
keit und Zugriffsgeschwindigkeit aufweisen. Alle Festplatten bestehen aus logischer Sicht zunächst aus
einer Anzahl von sequentiell hintereinanderliegenden Blöcken. In einem RAID-System wird eine spezi-

191
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

fizierte Anzahl derartiger Blöcke Stripe (Streifen) genannt. Unabhängig von der Anzahl der verwendeten
Festplatten wird dem System eine einzige virtuelle Festplatte zur Verfügung gestellt.

Platte 1




Platte 2








 

 
  



 

  
 

 

        
 

   
 

   
      

Logische RAID−1 Platte

Abbildung 6-9. RAID-Level 0

RAID-Level 0. dient allein zur Erhöhung der Zugriffsgeschwindigkeit. Der RAID-Level 0 basiert auf zwei
oder mehr Festplatten, wobei jedoch dem zugreifendem Rechnersystem eine (virtuelle) einzige Festplatte
vorgespiegelt wird. Ein Performancegewinn beim Zugriff wird dadurch erreicht, dass die dem System zur
Verfügung gestellte Sicht auf das Speichermedium aus abwechselnd einem Stripe der beiden Platten besteht.
Liest das System mehrere sequentielle Blöcke, wird die Last auf die beiden Platten verteilt, die Zugriffe sind
insgesamt schneller (siehe Bild RAID-Level 0).
RAID-Level 1. Bei diesem Level werden die Partitionen einer Platte auf eine zweite Platte gespiegelt. Bei
Ausfall einer der beiden Platten, steht noch die jeweils redundante Platte zur Verfügung. Nachteilig ist, dass
bei der Verwendung von zwei Platten nur der Speicherplatz einer Platte zur Verfügung steht.
RAID-Level 2 und Raid-Level 3. Diese beiden Level spielen heute keine Rolle mehr. Beide sind
Spezialfälle von RAID-Level 4 (RAID-Level 2 speichert anstelle der Parity Information ECC-Information,
RAID-Level 3 benutzt die kleinstmögliche Strip-Größe, so dass jeder Zugriff zu einem Zugriff auf allen
Platten führt).
RAID-Level 4. Mit RAID 4 wird zur Erhöhung der Verfügbarkeit Plattensystems verwendet. Wie bei
RAID-0 werden abwechselnd die Stripes der Platten zu einer virtuellen Platte dem Rechnersystem zur Ver-
fügung gestellt. Darüberhinaus wird aber noch auf einer eigenen Platte Parity-Information abgespeichert,
so dass der Ausfall einer der N-Platten toleriert werden kann. Die Speicherkapazität beträgt damit bei N+1
Platten N. Die Zugriffsgeschwindigkeit auf den Plattenstapel ist insbesondere beim Schreiben sehr niedrig,
da nicht nur die Daten, sondern die Parity-Information sowohl gelesen als auch geschrieben werden muß. Da
diese Information für sämtliche Stripes auf der Parity-Platte liegt, stellt die Parity-Platte einen Flaschenhals
dar.
RAID-Level 5. Bei RAID-Level 5 wird die Paritäts-Information auf sämtliche Platten verteilt. Das verhin-
dert zwar nicht die notwendigen Lesezugriffe auf diese Information, verteilt aber die Last auf alle Platten.

192
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

6.1.2. Fallbeispiele

6.1.2.1. Weiche Realzeitsysteme

6.1.2.1.1. Ausgangslage
Beim eCommerce handelt es sich um ein weiches Echtzeitsystem. Insbesondere kurzfristige Ausfälle kön-
nen toleriert werden, langfristige Ausfälle führen dagegen zu hohen Kosten. Letzlich ist die Verfügbarkeit
für die dahinterstehenden Firmen existentiell und hat hohe Priorität.
Mit eCommerce wird der elektronische Handel im Internet bezeichnet. Für den elektronischen Handel sind
folgende Komponenten notwendig:

• Webshop: Im Webshop werden die Waren angeboten und der Kunde kann seine Bestellung aufgeben.
Die wesentliche Kernkomponente des Webshops ist der HTTP-Server, der über Skripte oder Java in der
Lage ist, dynamisch Webseiten zu erzeugen. Diese Webseiten stellen die Produkte dar und nehmen die
Kundenbestellung entgegen.
• Auftragsabwicklung: Die Bestellung wird vom Waren-Wirtschafts-System der eCommerce-Company be-
arbeitet. Dazu werden - abhängig vom Produkt - eigene Bestellungen aufgegeben bzw. dem Lager die
Bestellung weitergeleitet.
• Logistik/Versand: Die Versandabteilung ist für die Verpackung und den Versand der Bestellung zuständig.
Gleichzeitig muß die elektronische Bezahlung angefordert werden.

Die kritischste Komponente, also die Komponente, die die höchsten Anforderungen an die Verfügbarkeit
stellt, ist der Webshop. Ist der Webshop nicht verfügbar, kann der Kunde weder auswählen noch einkaufen.
Fallen dagegen die Rechner der Auftragsabwicklung aus, können weiterhin die Bestellungen aufgenommen
werden, es gibt allein Verzögerungen bei der Bearbeitung der Aufträge.
Gleiches gilt für den Versand. Auch hier sind Ausfälle in bestimmten Zeitbereichen tolerierbar.
Neben den normalen Komponenten-Ausfällen muß sich ein eCommerce-Unternehmen zusätzlich gegen
Attacken aus dem Internet wappnen.
Als ein Beispiel aus dem Bereich der “Soft-Realtime-Systeme” soll hier die Struktur des Webshops Buch.de
im Hinblick auf die Verfügbarkeit (Availability) skizziert werden (Stand Februar 2000). Buch.de verkauft
über’s Internet nicht nur Bücher, sondern auch Blumen. Täglich verzeichnen die Webserver zwischen 30
und 35 tausend Hits und ca. 1500 bis 2000 Vorgängen.

193
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

6.1.2.1.2. Buch.de

q o
r p


ISP 
q
r
o
p



q o
r p

n l
m
 
 

 

q o
r p

n l
m

Standleitung 2MBit 

n l
m

 
q
r
o
p

Load−Balancer
q o
r p
 
   

Linux
n l  
m

01
Backupleitung 2MBit n l
m


q
r

q
r
o
p

o
p



 
n l  
m

 

n l
m

 

www.buch.de
n l
m

 

Backup−Rechner
} {
|
" " ™
# #

w
x
  
 

} {
|
™
š
j j j
k k k
w
x

y
z
! !
  } { —
  |
™
š
 
 
w
x

u s
v t
  
 
y
z

Linux
! !

Linux
} { — h h
| ˜ i i
d d d ™
e e
š
 
 
w
x

u s
v t

Windows NT
 
 
y
z
} { — h h
| ˜ i i
™
  š

w
x

HTTP−Server1 HTTP−Server2
 
 
u s
v t
 
 
y b b
z c c
} { —
| ˜
™
 

Mailserver
š
 
f f
w
x
 
   
u s  
v t

y b b
z c c

www1.buch.de www2.buch.de
} { —
  | ˜
™
  š
 
f f
w g g
x

 
u s  
v t

y
z
} { —
  | ˜
 
™
  š
 
f f
w g g
x

 
u s  
v t



y
z
—
  ˜
  ™
` `
š
a a
f f
g g

u s
v t



y
z
—
  ˜
 
` `
a a

u s
v t

—
˜
` `
a a

Internet−
‹ ‰ „

 €
‘ 
R R R . . .
S S / / /

‹ ‰ „
Š …
F F : : :
G G ; ; ;

Buchdatenbank
 €
‘ 

ˆ † ‚

‹ ‰ „
Š …

Ž Œ ~
P P , ,
  
L L Q Q ( ( ( - -
 €
M M ) )
‘ 

ˆ † ‚
‡ D D ƒ 8 8
E E 9 9
@ @ ‹ ‰ 4 4 4 „
A A Š 5 5 …

Pflege der Buchdatenbank Windows NT Auftragsdatenbank


Ž Œ P P ~ , ,
  
Q Q - -
 €
‘ 

ˆ † ‚
‡ D D ƒ 8 8
E E 9 9
‹ ‰ „
Š …

J J & &
K K ' '
Ž Œ ~
  
 €
‘ 

Linux
> > 2 2
? ? N N * * 3 3
ˆ † ‚
‡ ƒ
‹ ‰ „
Š …

Windows NT
B B 6 6

J J & &
K K ' '
Ž Œ ~
  
 €
‘ 
> > 2 2
? ? N N * * 3 3
ˆ † O O + + ‚
‡ ƒ
‹ ‰ „
Š …

B B 6 6
C C 7 7

Ž Œ ~
  
 €
‘ 

N N * *
ˆ † O O + + ‚
‡ ƒ
‹ ‰ „
< < Š 0 0 …

B B 6 6
C C 7 7

Ž Œ ~
  
 €
H H $ $
I I ‘ % % 

N N * *
ˆ † O O + + ‚
‡ ƒ
‹ ‰ „
< < Š 0 0 …
= = 1 1
B B 6 6
C C 7 7

Ž Œ ~
  

H H $ $
I I % %

ˆ † ‚
‡ ƒ

< < 0 0
= = 1 1

Generierung
Ž Œ ~
  
H H $ $
I I % %

ˆ † ‚
‡ ƒ

< < 0 0
= = 1 1

der
Internetdatenbank
Windows NT
Standleitung
•
–
^ ^
_ _

•
–

X
Y
”

”
’
“

’
“
X
Y
\
]

\
]
•
–

•
–
\
]

\
]
Logistikabwicklung
V
W

V
W
”

”
’
“

’
V
W

V
W
Z
•
–

Linux
“
•
–

Z Z
[ [

” ’
“
•
–

Z Z
[ [

” ’
“
T T •
U U –

Z Z
[ [

” ’
“

T T
U U

” ’
“

T T
U U

Abbildung 6-10. Rechnerstruktur des Webshop buch.de

Die Anbindung des Webshops zum Internet erfolgt über eine 2MBit Standleitung zum ISP (der Telekom).
Über diese Leitung werden täglich in etwa 5GByte Daten geschleust. Fällt diese Leitung aus, wird auf eine
Backup-Leitung (ebenfalls 2MBit) umgeschaltet. Die Backup-Leitung und die Standleitung erreichen das
Haus auf unterschiedlichen Wegen.
Die Standleitung- und die Backupleitung enden im Rechnerraum des Webshops an einem Linux-Router.
Der Linux-Router hat gleichzeitig die Aufgabe des Load-Balancings. Er verteilt also die Last möglichst
gleichmässig auf die beiden Webserver.
Zum eigentlichen Betrieb des Webshops sind 9 Rechner notwendig. Um die Verfügbarkeit zu erhöhen,
ist jeder Rechner zweifach redundant vorhanden, so dass insgesamt 18 Rechner zur Verfügung stehen.
Zwischen den redundaten Rechnern werden permanent die Daten gespiegelt, so dass beim Ausfall eines
Rechners problemlos umgeschaltet werden kann. Der Ausfall eines Rechners wird automatisch dedektiert,
das Umschalten erfolgt noch von Hand. Die gesamte EDV-Ausrüstung befindet sich in einem klimatisierten
Rechnerraum.
Die Rechner befinden sich in insgesamt 5 Racks (Rechnerschränken). Jedes Rack ist gegen Stromausfall
über eine USV (unterbrechungsfreie Stromversorgung) gesichert. Außerdem ist der gesamte Rechnerraum
über eine USV gesichert. Insgesamt lassen sich damit 36 Stunden Stromausfall überbrücken.
Fällt die Klimaanlage des Rechnerraumes aus, stehen mobile Klimageräte zur Verfügung.
Für die Platten werden RAID-Systeme verwendet, wobei für die wenig kritischen Systeme RAID 0 zur Er-
höhung der Zugriffsgeschwindigkeit verwendet wird, für die wichtigen Systeme wird RAID 5 zur Erhöhung
der Verfügbarkeit eingesetzt.
In der EDV sind beim Webshop Buch.de 7 Personen beschäftigt. Diese arbeiten im Schichtbetrieb zwi-
schen 6 und 21 Uhr. Danach existiert eine Rufbereitschaft. Werden bei der automatischen Überwachung der
Rechner Probleme festgestellt, werden die Mitarbeiter über Pager informiert.

194
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Bei Buch.de gibt es ausgearbeitete Notfall-Pläne. In diesen werden die Störungen in unterschiedlichen
Störungsklassen eingeteilt:

• Klasse 1: Störungen, die für den Kunden sichtbar sind (z.B. Ausfall der Standleitung, Nicht-Verfügbarkeit
des Shops)
• Klasse 2: Störungen, die mittelbar die Betriebsbereitschaft beeinflussen (Ausfall eines Rechners, der
gespiegelt ist, Ausfall einer USV, Ausfall der Klimaanlage)
• Klasse 3: Sonstige Störungen.

Die bisherigen Erfahrungen von buch.de mit dem vorgestellten Konzept sind gut. Bisher gab es einen kriti-
schen Ausfall der Klasse 1, der allerdings nicht im direkten Verantwortungsbereich des Webshops lag. Ein
Bagger hatte die Standleitung der Telekom unbrauchbar gemacht. Der Schaden wurde von den Rechnern
sofort dedektiert und der Telekom mitgeteilt. Diese war in ihrer Reaktion jedoch vergleichsweise langsam.
Insgesamt dauerte der Ausfall vier Stunden. Danach war die Leitung provisorisch repariert. Am folgenden
Tag war der Webshop ein weiteres Mal für eine Stunde nicht erreichbar. Zu dieser Zeit wurde die Reparatur
an der Leitung abgeschlossen. Zum angegebenen Zeitpunkt besaß Buch.de noch keine Backupleitung. Wür-
de das gleiche Problem noch einmal auftreten, ist mit einer deutlich kürzeren Ausfallzeit (durch Umschalten
auf die Backupleitung) zu rechnen.

6.1.2.2. Harte Realzeitsysteme: Space-Shuttle


Als ein Beispiel dafür, wie im harten Realzeitbereich die Sicherheit und Verfügbarkeit von Systemen ge-
währleistet wird, soll das Steuerungssystem des Space-Shuttle beschrieben werden [SpecGif84].
Während die NASA bei früheren Projekten einen fail-operational/fail-operational/fail-safe
Zuverlässigkeit vorschrieben, ist aufgrund der guten Erfahrungen mit den verwendeten Komponenten ein
fail-operational/fail-safe Ansatz verwirklicht.
Fail-operational bedeutet dabei, dass ein Fehler toleriert werden kann, der Betrieb kann ohne funktionale
Einbussen weiter geführt werden. Bei Auftritt eines zweiten Fehlers kann im Falle des Shuttles das Raum-
fahrzeug immer noch sicher zur Erde kommen, auch wenn nicht mehr alle Systeme an Board verwendet
werden können.
Zu Projektbeginn hatte die NASA drei unterschiedliche High-Availability-Strategien untersucht:

1. Unabhängige Systeme
Dieses in der Luftfahrt klassische Verfahren (z.B. Boeing 767) beruht auf einer Anzahl unabhängiger
Sensor, Computer und Aktorkreise. Problem bei diesem Anzatz ist die mangelnde Redundanz. Fällt
beispielsweise ein Computer aus, ist damit auch der Sensor nicht mehr verwendungsfähig.

2. Master/Slave Konzept
Bei diesem Konzept hätte ein Master ständig die Sensorik bedient, während die anderen Rechner im
Mithör-Modus einfach nur Informationen aufgenommen hätten. Wäre der Master ausgefallen, müsste
einer der redundanten Ersatzrechner seine Aufgabe übernehmen. Problematisch bei diesem Ansatz war
für die NASA, dass die NASA einen sicheren automatischen Switch-Over zum Ersatzsystem als eine
sehr komplexe Aufgabe angesehen hat. Dieser automatische Switch-Over ist aber notwendig, da in
kritischen Flugphasen nur 400ms zur Verfügung stehen, um auf das Ersatzsystem umzuschalten.

195
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

3. Verteiltes Kommando
Bei diesem letztendlich gewählten Konzept hören alle Steuerrechner auf alle Sensoren und erzeugen
auch alle die gleichen Ausgaben.

6.1.2.2.1. Systemstruktur
Das Steuerungssystem des Space-Shuttle besteht (Stand 1984) aus insgesamt 5 sogenannten General Purpo-
se Computer (GPC). Jeder Rechner hat einen Hauptspeicher von 106K 32 Bit-Worten mit einer Rechenlei-
stung von jeweils 450.000 Befehlen pro Sekunde. Die MTBF für das Rechnersystem wird mit 6000 Stunden
angegeben.

GPC GPC GPC GPC GPC


CPU CPU CPU CPU CPU
BFS
IOP IOP IOP IOP IOP

Bus

MDM MDM MDM


Keyboard Telemetry Payload−IF Rocket Boosters

Abbildung 6-11. Hardwarestruktur Space-Shuttle

Die einzelnen Sensoren und Aktoren des Raumfahrzeuges sind über 19 bis 20 sogenannte
Multiplexer/Demultiplexer (MDMs) an vier Bussysteme (1MHz) angeschlossen. Kritische Sensoren und
Aktoren (z.B. der Joystick zum Steuern des Shuttles oder Aktuatoren, die für die Landung notwendig sind)
sind dabei über mehrere MDMs an mehrere Busse angeschlossen, andere, unkritische Peripherie, kann nur
über ein Bus erreicht werden. Jeder GPC ist über einen Intelligent Output Processor (IOP) mit jedem Bus
verbunden. Im normalen Betrieb wird von jeweils einem GPC ein Bus gesteuert (schreibender Zugriff),
prinzipiell ist der Bus aber unabhängig vom GPC (d.h. bei Ausfall eines GPCs kann ein anderer GPC die
Kontrolle über den Bus übernehmen).
Zur Steuerung des Shuttles durch den Piloten stehen 4 Bildschirme und drei Tastaturen zur Verfügung.
Drei der Bildschirme und zwei Tastaturen sind im Cockpit angeordnet, der dritte Bildschirm befindet sich
inklusive Tastatur in der Nähe der Ladebucht.
Desweiteren existieren zwei Bandlaufwerke, die die eigentliche Steuersoftware (PASS, Primary Avionics
Software System) enthalten. Auf jedem der zwei Bandlaufwerke befinden sich jeweils drei Bereiche, die
alle eine Kopie der Systemsoftware enthalten. Dadurch sind insgesamt 6 Kopien der Systemsoftware an
Board. Fallen beide Bandlaufwerke aus, ist es darüberhinaus möglich, Software, die zum Wiedereintritt in
die Erdatmosphäre notwendig ist, hochzuladen.

196
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Zur Kommunikation mit der Bodenstation steht ein sogenannter Uplink und ein Downlink zur Verfügung.
Die Datenrate beträgt normalerweise 128 KBit/s, bei schlechter Verbindung 64 KBit/s. Kontakt mit der
Raumfähre gibt es in 80-90% der Flugzeit. Über diese Leitung werden ständig die Zustände des Shuttles
zur Erde gefunkt. Die Daten, die über diese Verbindung zum Raumfahrzeug gesendet werden, sind nicht
verschlüsselt. Allerdings werden diese Daten auch nur übernommen, wenn das Shuttle im Sichtfeld der
NASA-Bodenstationen ist. Sendet die Bodenstation dem Shuttle ein Kommando, muß das Shuttle selbiges
erst zurücksenden und vom Boden das OK bekommen, bevor es aktiviert wird.
Von den 5 GPCs bearbeiten - abhängig von der Flugphase - bis zu 4 exakt die gleiche Aufgabe. Da der
Hauptspeicher zu klein ist, um die gesamte Systemsoftware zu laden, wird ein Shuttle-Flug in 8 Flugphasen
eingeteilt und für jede Flugphase vom Band die entsprechende Software geladen. Der 5. Rechner wird
als BFS (Backup Flight System) bezeichnet. Hardwaremässig ist er identisch zu den anderen 4 Rechnern,
enthält aber eine vom PASS gänzlich unabhängige Software.
Die Software selbst nutzt ein Realzeit-Laufzeitsystem (Executive), das ca. 35 KWorte Speicher belegt. Die-
ses Laufzeitsystem benutzt ein Prioritätengesteuertes Scheduling mit 256 Prioritätsebenen. Das BFS ver-
wendet dagegen ein Laufzeitsystem, das die Applikationen streng im synchronen Zeitscheibenverfahren
aufruft.
Abhängig von der Aufgabe werden GPCs redundant betrieben. Ist das Shuttle im Orbit, werden sogar GPCs
abgeschaltet. Alle redundant betriebenen GPCs arbeiten streng synchron. Eine Synchronisation zwischen
den Rechnern findet etwa alle 350 Mal/Sekunde statt. Dabei wird ein entsprechendes Synchronisationspa-
ket verschickt, auf das spätestens nach 4ms geantwortet worden sein muß. Antwortet ein Rechner nicht
innerhalb dieser Zeitspanne, wird er als “failure to sync” gekennzeichnet und von den funktionierenden
Rechnern als nicht mehr im Verbund vorhanden betrachtet.
Das Redundanzkonzept beim Space-Shuttle wird als “the distributed command approach”, also “verteiltes
Kommando” bezeichnet. Alle 5 Rechner bekommen den gleichen Input und erzeugen auch (hoffentlich) die
gleichen Ausgaben. Bei redundanten Aktoren fällt die Entscheidung, welche der von den Rechnern erzeugte
Ausgabe verwendet wird, aufgrund mechanischer (hydraulischer) oder elektronischer Voter (Entscheider).
Diese Art von Voting ist weit verbreitet. Dabei leistet jede Ausgabeeinheit seinen Beitrag zur Ausgabe. Die
einzelnen Beiträge werden hydraulisch aufsummiert. Erzeugen beispielsweise 3 funktionstüchtige Rechner
eine korrekte Ausgabe, der 4. Rechner aber eine schlechte, so “übertrumpfen” die 3 guten Rechner den
defekten 4. Rechner. Die Ausgabe ist dann zwar nicht so stark, wie eigentlich gewünscht, aber es ist im-
mer noch genug Kraft vorhanden, um das Shuttle zu fliegen. Im hydraulischen Aktor wird außerdem die
Druckdifferenz zwischen den einzelnen Kanälen gemessen. Ist diese Differenz über einen längeren Zeit-
raum vorhanden, wird der Kanal abgeschaltet.
Einige Aktoren werden über elektronische Voter gesteuert. Beispielsweise werden Raketen nur gezündet
oder die Trägerraketen abgeworfen, wenn mindestens zwei oder drei identische Ausgaben vorhanden sind.
Das Abschalten eines Rechners oder auch das Umschalten der Kontrolle auf das BFS wird grundsätz-
lich nicht automatisch, sondern nur manuell durchgeführt. Für letzteres gibt es bei den Piloten einen ro-
ten Knopf . Für das Umschalten haben die Piloten im Regelfall 10 Sekunden Zeit. Diese Zeit ergibt sich
aufgrund physikalischer Gegebenheiten bzw. der Speicherkapazität interner Register (danach kommt es zu
kritischen Überläufen). Im worst case haben die Piloten sogar nur 400 Millisekunden Zeit, das ist, wenn die
GPC alle zu einem Zeitpunkt ausfallen, kurz nachdem sie vollen Schub eingestellt haben.
Fällt ein GPC aus, wird damit das Flugsystem in zwei oder mehr unabhängige Kontrollsysteme eingeteilt.
Der defekte Computer wird die Kommunikation mit den funktionstüchtigen Rechnern abbrechen, aber den-
noch weiterhin die Eingaben aufnehmen und die von ihm berechneten Ausgaben ausgeben. Das gleiche tun
die funktionstüchtigen Computer mit dem defekten Computer. In dieser Situation gibt es also zwei Com-
putersysteme, die beide versuchen das Shuttle zu fliegen. Auch wenn es im praktischen Flugbetrieb keine
Probleme gibt, verbieten die Notfallpläne, dass einen derartige Situation über einen längeren Zeitraum exi-
stiert.

197
Kapitel 6. Echtzeitsysteme in sicherheitskritischen Anwendungen

Fällt ein GPC aus, können die Piloten den zugehörigen Peripherie-Bus einem anderen GPC zuordnen.
Ebenso können natürlich auch Ausfälle in Sensoren oder Aktoren vorkommen. Beim Ende einer Ein-
/Ausgabe synchronisieren sich die redundanten Rechner. Dabei wird überprüft, ob ein Fehler aufgetreten
ist. Dedektiert kein Rechner einen Fehler, ist alles in Ordnung. Dedektiert ein Rechner einen Fehler, zwei
bzw. drei andere aber nicht, wird davon ausgegangen, dass der Rechner defekt ist und der Rechner wird
aus dem Redundanzverbund abgezogen. Dedektiert die Mehrheit der Rechner einen Fehler, wird die zuge-
hörige Ein-/Ausgabekomponente als defekt angenommen und die Daten von dieser Komponente werden
verworfen bzw. es werden der Komponente keinerlei Daten mehr zugestellt.
Normalerweise sind die Rechner zu etwa 75% ausgelastet. Da die Rechner ereignisgesteuert betrieben wer-
den, kann die Last aber auch auf über 100% ansteigen. In diesem Fall bleiben weniger wichtige Aufgaben zu
Gunsten der wichtigen Aufgaben unbearbeitet. Im Extremfall kann die komplette Bedienung der Displays
ausfallen, allerdings ist auch in diesem Fall das Shuttle noch in der Lage, sicher zur Erde zurückzukommen.

Fußnoten
1. Natürlich reicht der kurze Beobachtungszeitraum nicht aus, um eine gesicherte statistische Aussage
über die Wahrscheinlichkeiten durchzuführen.

198
Kapitel 7. Realzeit-Algorithmen
Wie bei anderen Systemen auch werden beim Realzeitsystem Eingaben zu einem Ergebnis (Ausgaben) ver-
arbeitet. Die Brauchbarkeit des Ergebnisses hängt dabei zum einen vom Zeitpunkt ab, an dem das Ergebnis
vorliegt, zum anderen auch von der Korrektheit.

Eingaben Verarbeitung Ausgaben

Leistung Zeit
Algorithmen Korrektheit
Die Brauchbarkeit des Ergebnis hängt ab von:
− Zeitpunkt des Vorliegens
− Korrektheit
Es wird bestimmt durch:
− Leistung der Hardware (Verarbeitungszeit und Speicherplatz)
− Algorithmen (SW, Art und Implementierung)

Abbildung 7-1. Ergebnis bestimmende Faktoren

Diese Anforderungen werden zum einen durch die Leistung der eingesetzten Hardware, zum anderen durch
die verwendeten Algorithmen bestimmt. Bei den Algorithmen kommt es sowohl auf die Art des Algorith-
mus, als auch auf seine Implementierung an.
Ob ein berechnetes Ergebnis brauchbar ist, entscheidet sich anhand des Zeitpunktes, zu dem das Ergebnis
vorliegt und anhand der Korrektheit des Ergebnisses. Beides wird bestimmt durch die Leistung der einge-
setzten Hardware und die Wahl der Algorithmen. Genügt ein Ergebnis nicht den gestellten Anforderungen,
kann man an diesen Faktoren drehen:

1. Können die zeitlichen Anforderungen nicht erfüllt werden, kann versucht werden, eine leistungsstär-
kere Hardware einzusetzen.
2. Die Wahl eines anderen Algorithmus kann sowohl Ergebnissen in kürzerer Zeit führen, als auch zu
besseren Ergebnissen als solches.
3. Man kann aber auch versuchen, die Anforderungen sowohl bezüglich der Zeit, als auch der Korrektheit
des Ergebnisses in Frage zu stellen.

In den vorigen Kapiteln wurden bereits einige Mechanismen vorgestellt, die im Betriebssystem die Forde-
rungen insbesondere nach Determinismus abdecken. Algorithmen als solche, die aber nicht nur im Betriebs-
systemkern, sondern auch auf der Applikationsebene eines Realzeitsystems eine große Rolle spielen, sind
bisher noch nicht behandelt worden. Im folgenden sollen stellvertretend für unterschiedliche Verfahren eini-
ge der gebräuchlichsten Algorithmen kurz vorgestellt werden. Es werden nur die grundlegenden Prinzipien
gezeigt, um die Verwendbarkeit eines Algorithmus für ein spezifisches Problem abschätzen zu können. Für
eine detaillierte Erläuterung und Diskussion der Techniken wird auf die umfangreich vorhandene Fachlite-
ratur verwiesen.
Prinzipiell kann man die Probleme aus der Realzeitwelt in zwei Kategorien packen:

199
Kapitel 7. Realzeit-Algorithmen

• in Bandbreiten Probleme und


• in Leistungs Probleme.

Bei der Bandbreiten Problematik muß der kontinuierliche Informationsfluß zwischen Sender und Empfän-
ger sichergestellt werden. Es muß also eine definierte Menge an Information in einem definierten Zeitfenster
übermittelt werden.
Bei der Leistungs Problematik muß sichergestellt werden, dass eine bestimmte Arbeitsleistung in einem
definierten Zeitintervall erbracht wird. Auf der einen Seite funktioniert dies über die bereits beschriebenen
Maßnahmen. Reicht das nicht aus, muß man zwangsläufig so weit wie möglich versuchen, die Anforderun-
gen an die zur Verfügung stehende Leistung anzupassen.
Im folgenden sollen für beide Problematiken beispielhaft Algorithmen (Technologien) skizziert werden, mit
Hilfe derer gestellte Anforderungen eingehalten werden können.

7.1. Bandbreiten Problematik


Viele der schwer zu lösenden Probleme aus der Realzeitwelt sind Probleme der Kommunikation, insbeson-
dere der Datenübertragung. Die zur Verfügung stehende Kommunikationstechnik ermöglicht zum Zeitpunkt
des Übertgragungswunsches keine genügende Bandbreite. Dazu einige Beispiele:

• Internet-Telefonie. Bei der Internet-Telefonie werden Sprachdaten über das Internet übertragen.
Hierbei ergeben sich strenge zeitliche Anforderungen. Auf der Sprecherseite wird die Sprache kodiert
und in Pakete verpackt, die über das öffentliche Netz übertragen werden. Auf der Empfängerseite
müssen die zu unterschiedlichen und nicht zu äquidistanten Zeitpunkten eintreffenden Pakete wieder
zu einem einzelnen Datenstrom (Sprachstrom) zusammengesetzt werden. Der Zeitversatz zwischen
Sprechen und Empfangen (der sogenannte Jitter) darf beim Telefonieren nicht zu groß werden (Bild
Zeitanforderungen bei der Internet-Telefonie).

Jitter
Absender 1 2 3 4
1 2 3 4 5 6 7 8 9 10 t
Übertragungsweg 4
1 2 3
1 2 3 4 5 6 7 8 9 10

Empfänger
1 2 3 4
1 2 3 4 5 6 7 8 9 10

Abbildung 7-2. Zeitanforderungen bei der Internet-Telefonie

Die zeitsynchrone Übertragung von Sprachdaten über das Internet ist aber noch komplizierter. Die Daten
werden über verschiedene Netze mit unterschiedlichen Übertragungscharakteristiken geleitet. Damit ist
die Reihenfolge, mit der die Pakete beim Empfänger ankommen ungewiss. Außerdem muß man davon
ausgehen, dass die Bandbreite als solches nicht ausreicht, um sämtliche Daten zu übertragen.

200
Kapitel 7. Realzeit-Algorithmen

• Ähnlich gelagert ist das Problem bei der Kommunikation mit Satelliten. Aus diversen technischen Grün-
den ist die Übertragungsbandbreite zwischen Bodenstation und Satellit eingeschränkt. Damit ist auch die
Anzahl der zu übertragenden Daten limitiert.

Als Lösungsansatz für die dargestellten Probleme bieten sich

• Ressourcen-Preallokation und
• Datenreduktionsverfahren
an.
Bei der Ressourcen-Preallokation werden

• Netzwerk-Übertragungsbandbreite
• Sekundärspeicherdurchsatz (Festplattendurchsatz) und
• Rechenleistung
reserviert und durch das System garantiert. Moderne Übertragungsmedien (z.B. ATM) bieten die
Möglichkeit, diese Preallokation durchzuführen, beim Internet als solches, bei dem unterhalb von tcp/ip
verschiedenste Protokolle eingesetzt werden, können Bandbreiten jedoch nicht garantiert werden. Die
Preallokation der Ressourcen muß durch das Betriebssystem unterstützt werden. Im Kontext von Linux
gibt es beispielsweise zwei Systemerweiterungen, die dafür zuständig sind: Linux/RK (Resource Kernel
(http://www.cs.cmu.edu/~rajkumar/resource-kernel.html)) und KURT (http://www.ittc.ukans.edu/kurt).
Bei diesen Ansätzen spezifziert man die pro Zeitintervall zur Verfügung stehende Ressource (z.B. Rechen-
zeit: Eine Task soll alle 1000ms 200ms Rechenzeit bekommen).

7.1.1. Datenreduktionsverfahren
Wird mehr Übertragungsbandbreite benötigt, als vorhanden, kann in vielen Fällen fehlende Übertragungs-
bandbreite durch Rechenzeit eingetauscht werden. Bei dieser Möglichkeit werden die zu verarbeitenden
Daten durch Datenreduktion minimiert.
Man unterscheidet zwei Arten dieser Kodierungsverfahren:

1. Die verlustfreie (Kompression) und


2. die verlustbehaftete Datenreduktion.

Die verlustbehaftete Datenreduktion wird oft im Multimediabereich eingesetzt. Berühmteste Vertreter sind
das Audio-Daten-Format MP3 und das Bilddatenformat jpeg. Bei dieser Art der Datenreduktion wird auf
den Teil der in den Daten vorhandenen Information verzichtet, der für den Empfänger der Daten den ge-
ringsten Wert hat. So werden beispielsweise beim MP3 Format die Schwingungen weggelassen, die für das
menschliche Ohr ohnehin nicht wahrzunehmen sind.
Beim Bildformat GIF beispielsweise werden einfach maximal 256 Farbwerte abgespeichert. Enthält ein Bild
mehr Farbinformation, ist diese verloren. Bei JPEG wird das Bild in den Frequenzbereich transformiert und
hochfrequente Anteile weggelassen.
Bei der verlustfreien Datenreduktion (der Kompression) wird eine günstigere Kodierung für die Daten ver-
wendet. Finden beispielsweise in einem zu kodierendem String sehr oft Wiederholungen statt, kann in einem
einfachen Kodierschema jeweils vor dem Zeichen ein Wiederholungsfaktor mit übertragen werden.

201
Kapitel 7. Realzeit-Algorithmen

Sei beispielsweise der zu kodierende String:


AAABBBBDDDZZZZZZZUILOOOOOONNN

könnte dieser folgendermassen kodiert werden:


3A4B3D7Z1U1I1L6O3N

Gibt es weniger nutzbare Wiederholungen und ist zudem das Auftreten der einzelnen Zeichen nicht gleich-
verteilt, hat die sogenannte Huffman-Kodierung weite Verbreitung gefunden.
Huffman kodiert die Daten nicht wie üblich byteweise, sondern bitweise. Jedes Zeichen des zu kompri-
mierenden Datenstroms wird durch eine unterschiedliche Anzahl von Bits dargestellt. Zeichen, die häufig
vorkommen, werden durch wenige Bits dargestellt, dagegen werden selten vorkommende Zeichen durch
längere Bitfolgen kodiert. Eine entweder bekannte oder vor dem Datenstrom stehender Kodierungsbaum
(Huffman-Tree) gibt die Kodierung an.
Ein Huffman-Tree wird nach folgendem Verfahren aufgebaut [Sedg83]:
Der folgende Text soll nach Huffman komprimiert werden:
“A SIMPLE STRING TO BE ENCODED USING A MINIMAL NUMBER OF BITS”

Wird wieder jeder der 26 möglichen Buchstaben durch eine Ziffer (von 1 bis 26)
repräsentiert, ergibt sich (mit 0 für “Space”) die folgende Häufigkeitsverteilung:
A B C D E F G I L MN O P R S T U
11 3 3 1 2 5 1 2 6 2 4 5 3 1 2 4 3 2

Jeder Häufigkeitswert (z.B. 11 für Space und 3 für A) wird als Knoten aufgefaßt. Ausgehend von diesen
Knoten werden die beiden Knoten mit der geringsten Häufigkeit zu einem neuen Knoten zusammengefaßt.
Dieser neue Knoten bekommt als Häufigkeitswert die Summe der ihn bildenden Knoten. Im Beispiel könn-
ten die Knoten der Zeichen C und F oder F und P zusammengefaßt werden, wobei jede Kombination aus den
zugehörigen Knoten erlaubt ist. Im Beispiel werden F und P zusammengefaßt.
11 3 3 1 2 5 2 2 6 2 4 5 3 2 4 3 2

1 1

Auf diese Art und Weise werden immer wieder in der obersten Ebene die beiden Knoten mit der niedrigsten
Zahl zusammengefaßt. So ergeben sich die folgenden Teilbäume, nachdem alle Knoten mit der Häufigkeit
2 zusammengefaßt wurden:

11 3 3 3 4 5 5 6 4 4 5 4 3

1 2 2 2 2 3 2 2

1 1

Die Knoten in der obersten Ebene mit der niedrigsten Auftrittshäufigkeit besitzen einen Wert von 3. Im
folgenden werden alle diese Knoten zu einem neuen Knoten zusammengefaßt. Das geht so lange weiter, bis
ein einzelner Baum entstanden ist:

202
Kapitel 7. Realzeit-Algorithmen

60

23 37

11 12 16 21

5 6 6 6 8 8 10 11
N I
3 3 3 3 4 4 4 4 5 5
O B A S M E
1 2 2 2 2 2 2 3
F G U L D R T
1 1
C P
Den Huffman-Code bekommt man nun, wenn man im entstandenen Baum alle linken Äste durch eine 0
kennzeichnet und alle rechten Äste durch eine 1. So wird beispielsweise das Zeichen N durch den Huffman-
Code 000 ausgedrückt, der Buchstabe D durch 10110.

0 1

0 1 1
0

0 1 0 1 0 1 1
0
0 1 0 1 0 1 0 1 0 1
N I
0 1 0 1 0 1 0 1
O B A S M E

F G U L D R 0 1 T

C P
Mit diesem Kodierungsbaum wird der Text folgendermassen kodiert:
0110 111 1001 001 1010 110101 10001 1100 111 1001 11011 10111 001 000 01111 111 11011 0100 111 0101 1100 111
A S I M P L E S T R I N G T O B E

1100 000 110100 0100 10110 1100 10110 111 10000 1001 001 000 01111 111 0110 111 1010 001 000 001 1010 10000 1010
E N C O D E D U S I N G A M I N I M U M

111 000 10000 1010 0101 1100 10111 111 0100 01110 111 0101 001 11011 1001
N U M B E R O F B I T S

Würde im obigen Beispiel für jedes der 60 Zeichen ein 8 Bit Wert verwendet, würden 480 Bit benötigt. Die
Huffman-Kodierung belegt dagegen nur 236 Bit, was eine Datenreduktion von mehr als 50% entspricht.

7.2. Leistungs Problematik


In vielen Fällen ist es nur sehr schwer möglich, die zur Lösung einer Problematik notwendige Rechenlei-
stung zur Verfügung zu stellen. Dazu wieder zwei Beispiele:

• Packroboter. Ein Roboter wird dazu eingesetzt, Pakete auf eine Palette zu packen. Die Pakete können
unterschiedliche Formate haben. Der Roboter muß versuchen, eine optimale Packung der Palette zu er-

203
Kapitel 7. Realzeit-Algorithmen

reichen. Unter optimal ist hier kompakt und stabil zu verstehen.


• Wegeplanung eines autonomen mobilen Systems. Optimierungsproblem!

Das Problem mangelnder Rechenleistung läßt sich in zwei Bereichen lösen:

1. Hardware. Gerade im Bereich der eingebetteten Systeme, bei denen die Prozessorleistung im Regelfall
durch diverse Faktoren beschränkt ist, muß immer wieder die Entscheidung gefällt werden, bestimmte
zeitkritische Funktionen von Software in die Hardware zu verlagern. So stellt beispielsweise die EPP-
Schnittstelle beim PC Zeitanforderungen in der Größenordnung von 10 µs. Für einen 8-Bit-Controller,
der eine Verarbeitungsleistung von 1 Befehl/1 µs hat, bedeutet dieses, dass die Schnittstelle innerhalb
von maximal 10 Befehlen bedient sein muß. Da dieses zu schnell für einen derartigen Controller ist,
muß man die Schnittstelle durch Hardware realisieren. Die notwendigen Strobesignale werden dann
durch eine enstprechende Schaltung (z.B. FPGA) erzeugt.
2. Algorithmenwahl. Im Regelfall existiert nicht nur ein Algorithmus, um ein Problem zu lösen. Daher
wird man im Falle von Realzeitsystemen besonders streng auf Verarbeitungszeit und Speicherplatzan-
forderungen einzelner Algorithmen achten.
Bei den in der Echtzeitwelt zur Auswahl stehenden Varianten unterscheidet man
• exakte Verfahren von den sogenannten
• Näherungsverfahren.

7.2.1. Exakte Algorithmen am Beispiel Hashing


Zur Lösung vieler Probleme werden Suchverfahren eingesetzt. Klassische Suchverfahren (z.B. Quicksort)
eignen sich jedoch nicht für Realzeitsysteme, da die Laufzeit nicht deterministisch ist und vom Füllgrad
(Inhalt) des Suchraumes abhängt.
Bei der Lösung realzeitkritischer Aufgaben wird man daher andere, deterministische Verfahren wählen.
Als Alternative zu den klassischen Suchverfahren existiert Hashing. Beim Hashing wird der eigentliche
Suchvorgang auf eine zeitlich leicht abschätzbare Berechnung zurückgeführt. “Bezahlt” wird dieser “Ge-
winn” im Regelfall mit erhöhtem Speicherplatzbedarf (time-space tradeoff), genau entgegengesetzt zu den
im Abschnitt Datenreduktionsverfahren erwähnten Algorithmen.

Datensatz *SucheDatensatz( key_t Schluessel )

für alle Datensätze


Wenn Datensatz.schluessel == Schluessel
Ja Nein
return Datensatz

Abbildung 7-3. Generalisierter Ablauf eines klassichen Suchverfahren

204
Kapitel 7. Realzeit-Algorithmen

Bei den Suchverfahren wird im allgemeinen ein zu einem Schlüssel gehörender Datensatz gesucht. So ist
beispielsweise bei der Telefonnummernsuche der Name des gewünschten Gesprächspartners der Schlüssel,
um im Telefonbuch (Datenbestand) die zugehörige Telefonnummer (Datensatz) zu finden. Bei der klas-
sischen Suche (Abbildung Generalisierter Ablauf eines klassichen Suchverfahren) wird der Schlüssel mit
den im Datenbestand abgespeicherten Schlüsseln solange verglichen, bis eine Übereinstimmung festgestellt
wurde. Beim Hashing wird der Schlüssel dazu verwendet, um den Speicherort über eine mathematische
Funktion - der sogenannten Hash-Funktion - zu bestimmen.
Datensatz *GibDatensatz( key_t Schluessel )
{
return HashFunktion( Schluessel );
}

7.2.1.1. Die Hash-Funktion


Die Hash-Funktion, die die Abbildung des Schlüssels auf den Speicherort durchführt, soll nach Möglichkeit
so gestaltet sein, dass für jeden Schlüssel ein eindeutiger Speicherort berechnet wird. Sei M der zur Verfü-
gung stehende Speicherplatz, wird also eine Abbildung des Schlüssels auf einen Integer-Wertebereich von
0 bis M-1 durchgeführt.

Anforderungen an die Hash-Funktion h(k) sind:

• Dass der gesamte Eingangswertebereich gleichverteilt auf den Ausgangswertebereich abgebildet wird.
• Dass die Hashfunktion einen eindeutigen Speicherort errechnet.
• Eine einfache bzw. schnelle Berechnung.

1. Schritt: Überführung des Schlüssels in einen Integerwert, wobei dieser Integerwert nicht breiter als die
Breite eines CPU-Registers (k(s)) sein soll. Dadurch kann die folgende Berechnung möglichst schnell von
statten gehen. Eine einfache Variante für eine Hashfunktion besteht in der Addition der einzelnen Bytes
des Schlüssels. Im Beispiel der Telefonnummernsuche würden also im ersten Ansatz die Buchstaben des
Namens aufsummiert werden.
int KeyToInt( char *key )
{
int sum=0;

for( ; *key; key++ ) {


sum += *key;
}
return( sum );
}

Abhängig von der Art des Schlüssel kann es sinnvoll sein, noch eine Gewichtung vorzunehmen. Kommen
beispielsweise sehr oft ähnliche Strings vor, die sich weniger durch die vorkommenden Buchstaben selbst
(z.B. “schneider” und “schnieder”), als vielmehr durch die Position der selbigen unterscheiden, wird man
die Position bei der Umsetzung des Schlüssels in einen Integerwert mit berücksichtigen.

Tabelle 7-1. Hashfunktion am Telefonbuch-Beispiel

Name k (Summe) h(k)=k%10

205
Kapitel 7. Realzeit-Algorithmen

Name k (Summe) h(k)=k%10

kunst 565 5
fernholz 872 2
schneider 949 9
schnieder 949 9
schmitz 770 0
lammers 753 3
honsel 649 9
bastert 757 7

2. Schritt: Abbildung des Schlüssel-Wertebereiches auf den Wertebereich der sogenannten Hash-Table.
Hier bietet sich die einfache Funktion:
h(k) = k % M;

an, wobei % der Modulo-Operator und k das Ergebnis aus Schritt 1 ist. Die Tabelle
Hashfunktion am Telefonbuch-Beispiel zeigt beispielhaft die Werte für k und h(k).

7.2.1.2. Kollisions-Auflösung
Dass zwei oder mehr Schlüssel durch die Hashfunktion auf denselben Speicherort (Tabellenplatz) abgebil-
det werden, nennt man Kollision. Die beiden Strings „schnieder“ und „schneider“ werden beispielsweise
durch die Schlüsselberechnung k(s) und die Hashfunktion h(k) auf denselben Tabellenplatz abgebildet.
Kollisionen lassen sich vermeiden, wenn

a. genug Speicherplatz zur Verfügung steht und


b. die Hashfunktion für jeden Key einen eigenen Tabellenplatz errechnet.

Ansonsten gibt es zur Auflösung von Kollisionen (collision resolution) die folgenden Techniken:

• Es wird der nächste freie Tabellenplatz gewählt.


Ergibt also die Hashfunktion für den Wert schneider das Ergebnis 9 und für den Wert schnieder ebenfalls
das Ergebnis 9, dann kann der Wert “schnieder” (wenn er denn zeitlich nach „schneider“ auftritt) nicht
mehr am Tabellenplatz 9 abgelegt werden, da hier bereits „schneider“ (oder sogar ein zeitlich noch frü-
her aufgetretener Wert) eingetragen ist. Stattdessen wird nachgeprüft, ob der folgende Tabellenplatz - im
Beispiel, da nur die Tabellenplätze von 0 bis 9 vorhanden sind - der Tabellenplatz 0 belegt ist oder nicht.
Solange der Tabellenplatz besetzt ist, wird - bis zum Ende der Tabelle - der nächste Tabellenplatz über-
prüft. Sind bis zum Ende der Tabelle alle Plätze belegt, beginnt die Suche am Anfang der Tabelle. Der
erste gefundene freie Tabellenplatz wird genutzt, um schließlich den Schlüssel inklusive Datum abzule-
gen. Entsprechend dem Ablageverfahren ist auch das Zugriffsverfahren. Mit dem Hashwert wird nur der
Ausgangspunkt einer eventuell notwendigen Suche definiert. Es muß also weiterhin der Zugriffsschlüssel
mit dem Schlüssel des Datensatzes verglichen werden.
Außerdem muß bei diesem Verfahren sichergestellt sein, dass nicht weniger Tabellenplätze zur Verfügung
stehen, wie mögliche Elemente eingehängt werden müssen.
Die Konsequenz bei dieser Art der Kollisions-Auflösung ist, die weiterhin bestehende Notwendigkeit der
klassischen Suche. Entspricht die Tabellengröße exakt der Elementanzahl, kann es im ungünstigsten Fall
notwendig sein, sämtliche Tabellenplätze abzusuchen.

206
Kapitel 7. Realzeit-Algorithmen

• Es wird am Tabellenplatz eine Liste eingehängt.


Um unabhängig von der Größe der Hashtabelle zu sein und auch den Einfluß einer Kollision auf die
anderen Tabelleneinträge zu reduzieren, wird über einen Tabelleneintrag eine Liste verwaltet. Diese Liste
enthält die zum Hashwert gehörigen Datenelemente.
Auch bei diesem Verfahren ist im Falle einer Kollision eine Suche notwendig. Diese Suche bringt eine
nur bedingt deterministische Komponente in das Suchverfahren. Um die längst-mögliche Laufzeit ab-
zuschätzen, ist Wissen über die maximale Tiefe der Liste (maximale Anzahl von Elementen mit dem
identischen Hashwert) notwendig.

• Im Falle einer Kollision wird ein neuer Tabellenplatz über eine zusätzliche, andere Hashfunktion be-
stimmt.
Dieses Verfahren bringt wiederum die Einschränkung mit sich, dass nicht mehr Elemente vorkommen
dürfen, als insgesamt Tabellenplätze vorhanden sind. Ist ein zu einem Hashwert gehöriger Tabellenplatz
bereits belegt, wird die zweite Hashfunktion aufgerufen, die mittels eines anderen Algorithmus einen
Hashwert berechnet. Am zum neuen Hashwert gültigen Tabellenplatz wird jetzt wiederum untersucht,
ob der Platz belegt ist oder nicht. Ist der Platz belegt, wird ab der aktuellen Position der nächste freie
Tabellenplatz gesucht und der Wert dort abgelegt.
Auch in diesem dritten Fall ist der Teil der Kollisionsauflösung nicht deterministisch.

Beispiel 7-1. Hashwert und Hashtabelle [Sedg83]

Wenn jeder Buchstabe des Alphabets durch die Zahl i repräsentiert (k(s)=s-’A’;)wird und die Hash-
Funktion h(k)=k%M verwendet wird, bekommt man die folgenden Hashwerte und die angegebene Hash-
tabelle. Kollisionen in der Hashtabelle werden hier über die Verwendung einer Liste an jedem Tabellenplatz
gelöst.

Key: A S E A R C H I N G E X A M P L E
(0) (18) (4) (0) (17) (2) (7) (8) (13) (6) (4) (23) (0) (12) (15) (11) (4)

Hash: 0 8 4 0 7 2 7 9 3 6 4 3 0 2 5 1 4

0 1 2 3 4 5 6 7 8 9
A L C N E P G R S I
A M X E H
A E

207
Kapitel 7. Realzeit-Algorithmen

7.2.2. Näherungsverfahren
Näherungsverfahren werden oft auch als Optimierungsverfahren bezeichnet. Die den Näherungsverfahren
zugrunde liegenden Probleme werden von den Mathematikern als NP-hart bzw. NP-vollständig bezeichnet.
Das bedeutet, dass das Problem nicht mit einem Algorithmus in polynominaler, also letzlich berechenbarer
Zeit, zu lösen ist.
Da eine schlechte Lösung in den meisten Fällen immer noch besser als gar keine Lösung ist, wählt man
Algorithmen, die zwar nicht die optimale, so doch immerhin suboptimale Lösungen bieten.
Es gibt also einen Lösungsraum, in dem jede Lösung durch eine Güte gekennzeichnet werden kann.

Güte
optimale Lösung
brauchbar
unbrauchbar

Lösung

Abbildung 7-4. Lösungsraum

Ziel ist es zwar, die optimale Lösung im Lösungsraum zu finden, ausreichend ist es dagegen, überhaupt eine
brauchbare Lösung zu bekommen. So gibt es beispielsweise für ein autonomes mobiles Handhabungsgerät
(Roboter), der von Punkt A zu Punkt B fahren soll, eine große Anzahl von möglichen Wegen. Aus dieser
Anzahl würde der kürzeste Weg der optimalen Lösung (globales Maximum in Bild Lösungsraum) entspre-
chen. Existiert zusätzlich die Bedingung, dass der Roboter Punkt B spätestens nach 4 Minuten erreichen
muß, sind alle die Lösungen unbrauchbar, für die der Roboter mehr als die vorgegebene Zeit benötigt.
Um diese Verfahren anwenden zu können, muß man

• eine Bewertungsfunktion zur Verfügung stellen und


• eine Abbruchbedingung festlegen. Die Abbruchbedingung spezifiziert entweder
• die Güte einer Lösung oder
• die Zeit, nach deren Ablauf abgebrochen wird.

do {
Loesung = BerechnungEinerLoesung();
} while( Bewertung(Loesung) ≥ BrauchbareLoesung );

oder
do {
Loesung = BerechnungEinerLoesung();
} while( GesamtzeitFuerDieBerechnung < ErlaubteZeit );

208
Kapitel 7. Realzeit-Algorithmen

Es lassen sich folgende prinzipielle Verfahren unterscheiden:

• Randomisierte bzw. probabilitistische Verfahren


• Heuristische Verfahren

Xn
Ym
Eingänge

Ausgänge
X2 BLACK
X1 Y1
X0
BOX Y0

Abbildung 7-5. Black Box

Als Aufgabe soll beispielsweise der Ausgangswert einer Black Box maximiert werden. Die Black Box habe
eine Anzahl von n Eingangsleitungen und m Ausgangsleitungen. Wenn n groß genug ist, ist ein Ausprobieren
sämtlicher Eingangskombination aus Zeitgründen nicht möglich, hier kann nur ein Optimierungsverfahren
eingesetzt werden. Dazu ist zunächst die Bewertungsfunktion festzulegen. Entsprechend der Aufgabenstel-
lung werden die Ausgabeleitungen als Integerwert interpretiert. Damit ergibt sich die zu maximierende
Gütefunktion zu:
Q(x)=20 Y0 + 21 Y1 + 22 Y2 + ... 2m Ym

7.2.2.1. Randomisierte Verfahren


Hat man keine Informationen über die Struktur des Lösungsraumes, setzt man sogenannte randomisierte,
also rein auf Zufall beruhende Verfahren ein. Per Zufallszahl wird eine mögliche Lösung ausgewählt und
die Güte der Lösung wird überprüft.
Zwei Varianten haben sich ausgeprägt:

1. Monte Carlo. Dieses Verfahren garantiert eine Lösung in kurzer Zeit, unabhängig davon, ob die Lö-
sung korrekt ist oder nicht (schnell und eventuell korrekt). Im Beispiel der Block Box werden also die
Eingänge solange mit einer Zufallskombination beschickt, bis eine definierte maximale Zeit verstrichen
ist. Die am Ende beste Lösung wird verwendet (Abbruchkriterium Zeit).
2. Las Vegas. Dieses Verfahren berechnet immer eine korrekte Lösung, in erster Näherung unabhängig
von der dazu notwendigen Zeit (korrekt und eventuell schnell). Im Beispiel der Black Box werden
diesmal die Eingänge solange mit einer Zufallskombination beschickt - unabhängig von der dazu be-
nötigten Zeit -, bis ein brauchbares Ergebnis vorhanden ist (Abbruchkriterium Güte).

7.2.2.2. Heuristische Verfahren


Während bei den Randomisierten Verfahren quasi blind der Lösungsraum durchstochert wird, um per Zu-
fall auf eine Lösung geeignet Qualität zu kommen, versucht man bei den heuristischen Verfahren durch

209
Kapitel 7. Realzeit-Algorithmen

die Hinzunahme von Wissen über den Untersuchungsgegenstand den Algorithmus sowohl bezüglich des
Ergebnisses als auch bezüglich der Laufzeit zu beschleunigen.
Dabei werden Verfahren, wie sie die Natur verwendet, auf die Problemstellung adaptiert. Der
Ingenieur/Informatiker hat die Aufgabe, sein Problem auf das Verfahren aus der Natur abzubilden.
Folgende Verfahren werden bisher eingesetzt:

• Fuzzy-Logik
• Neuronale Netze
• Evolutionsstrategien und Genetische Algorithmen
• Simulated Annealing, in den Varianten
• Simulated Annealing
• Treshold Accepting
• Great Deludge

7.2.2.2.1. Fuzzy-Logik
Unter Fuzzy-Logik versteht man die Verarbeitung von sogenanntem unscharfen Wissen. Dabei werden die
ungenauen Werte linguistischer Variablen (man spricht von sogenannten Fuzzy-Sets) in Form von Fuzzy-
Operatoren und Regeln verarbeitet. Existiert beispielsweise eine linguistische Variable Temperatur, so kann
diese die Werte (niedrig, mittel und hoch annehmen. In Bild Fuzzy Variable mittlere Temperatur ist die
Menge mittlere Temperatur einmal als scharfe und als unscharfe Menge dargestellt. Der Übergang, ob
eine bestimmte Temperatur zu der Menge gehört oder nicht, ist aufgeweicht und wird in Form des Grades
der Zugehörigkeit µ(x) festgelegt. Dieser Grad wird in normalisierter Darstellung mit einer Zahl aus dem
Intervall [0,1] ausgedrückt.

µ
1

0 10 20 30 40 50 60 70 80 90 100
scharfe Menge
unscharfe Menge

Abbildung 7-6. Fuzzy Variable mittlere Temperatur

Der Grad der Zugehörigkeit (Zugehörigkeitsfunktion µ(x)) ist keine Wahrscheinlichkeit! Der Wert µ besagt,
dass die Eigenschaften, die die Zugehörigkeit eines Elementes zu der entsprechenden Gruppe ausmachen,
nicht vollständig vorhanden sind.

210
Kapitel 7. Realzeit-Algorithmen

7.2.2.2.1.1. Mengenoperationen
Auf Fuzzy-Sets sind eine Reihe von Operationen definiert, wovon die zwei wichtigsten kurz vorgestellt
werden sollen.
Minimumoperator. Der Minimumoperator repräsentiert eine Durchschnittsbildung bzw. eine logische Und-
Verknüpfung zweier Fuzzy-Sets.
µ2(x) = min(µ1(x),µ2(x));

Der Grad der Zugehörigkeit zum Durchschnitt zweier Fuzzy-Sets kann höchstens so groß sein, wie der Grad
zu einer dieser Mengen. Die Und-Verknüfung ist in Bild Fuzzy Und-Operator dargestellt.

µ
1

mittlere UND
hohe
 

Temperatur
 

 

 

0 10 20 30 40 50 60 70 80 90 100
hohe Temperatur (heiß)
mittlere Temperatur (warm)

Abbildung 7-7. Fuzzy Und-Operator

Maximumoperator. Der Maximumoperator repräsentiert die Vereinigungsmenge zweier Fuzzy-Sets und


damit die logische Oder-Verknüpfung.
µ2(x) = max(µ1(x),µ2(x));

Der Grad der Zugehörigkeit zur Vereinigung zweier Fuzzy-Sets kann nicht geringer sein, als der Grad zu
einer dieser Mengen.

µ
1
mittlere ODER
       
       


















hohe

















Temperatur
       
       

       
       

       
       

       
       

0 10 20 30 40 50 60 70 80 90 100
hohe Temperatur (heiß)
mittlere Temperatur (warm)

Abbildung 7-8. Fuzzy Oder-Operator

211
Kapitel 7. Realzeit-Algorithmen

Nichtoperator. Der Nichtoperator repräsentiert das Komplement eines Fuzzy-Sets und damit die logische
Nicht-Verknüpfung.
µ2(x) = 1 - µ1(x)

µ
1

0 10 20 30 40 50 60 70 80 90 100
nicht mittlere Temperatur (nicht warm)
mittlere Temperatur (warm)

Abbildung 7-9. Fuzzy Nicht-Operator

7.2.2.2.1.2. Regeln
Über die Fuzzy-Variablen werden Wenn-Dann Regeln gesetzt.

Beispiel 7-2. Fuzzy-Regelsatz


REGEL 1: IF Temperatur == hoch ODER Druck == hoch
THEN
Ventil = zu.

REGEL 2: IF Temperatur == hoch UND Druck == mittel


THEN
Ventil = mittel.

µ
1 niedrig mittel hoch

0 10 20 30 40 50 60 70 80 90 100
Temperatur

Abbildung 7-10. Fuzzy-Set Temperatur

212
Kapitel 7. Realzeit-Algorithmen

µ
niedrig mittel hoch
1

0 10 20 30 40 50
Druck

Abbildung 7-11. Fuzzy-Set Druck

µ
zu mittel auf
1

0 10 20 30 40 50 60 70 80 90 100
Ventilstellung

Abbildung 7-12. Fuzzy-Set Ventilstellung

Im technischen Prozess werden die Werte für Temperatur und Druck gemessen. Die konkreten (scharfen)
Meßwerte werden den entsprechenden Fuzzy-Sets zugeordnet und in die Regeln eingesetzt. Wird beispiels-
weise die Temperatur 65 Grad und ein Druck von 10 Bar gemessen, ergibt die Zuordnung zu den Fuzzy-Sets
folgende Werte:
Temperatur 62: hoch = 0.3
mittel = 0.7
niedrig = 0.0
Druck 31 bar: hoch = 0.4
mittel = 0.6
niedrig = 0.0

In wieweit die Prämissen der Regeln nun erfüllt werden, ergibt sich aufgrund der verwendeten (Fuzzy-)
Operatoren. In diesem Fall muß bei der ersten Regel der ODER-Operator, bei der zweiten Regel der UND-
Operator angesetzt werden:
REGEL 1: max( 0.3, 0.4 ) = 0.4
REGEL 2: min( 0.3, 0.6 ) = 0.3

213
Kapitel 7. Realzeit-Algorithmen

Mit diesem Ergebnis hat man nun zwei unterschiedliche Ergebnisse für die Stellung des einen Ventils be-
rechnet: das Ventil ist mit einem Grad von 0.4 geschlossen und mit einem Grad von 0.3 auf Mittelstellung
zu betreiben.
Aus diesen beiden Werten ist jetzt über die sogenannte Inferenz ein (scharfes) Ergebnis zu liefern. Wie bei
den Operatoren gibt es auch hier unterschiedliche Methoden. Die gängigsten sind

• MAX-MIN Inferenz und


• MAX-PROD Inferenz.

Im folgenden soll die MAX-MIN Inferenz vorgestellt werden.


Bei der MAX-MIN Inferenz werden die unscharfen Mengen der linguistischen Variable jeweils auf den
Grad der Prämisse begrenzt (Minimumfunktion). Die daraus resultierenden Mengen werden zum Inferenz-
Ergebnis zusammengefaßt.

µ
zu mittel auf
1

0.4
       

       

0.3 






















       

       

       

0 10 20 30 40 50 60 70 80 90 100
Ventilstellung

Abbildung 7-13. MAX-MIN Inferenz

Aus dieser neu entstandenen Menge ist schließlich ein konkreter Stellwert für das Ventil abzuleiten. Auch
hierfür gibt es wieder unterschiedliche Methoden. Gängig ist die Methode, eine Schwerpunktberechnung
der Ergebnisfläche durchzuführen und entsprechend dem berechneten Punkt die Zielvariable einzustellen.
Bei der Schwerpunktmethode kann es durchaus vorkommen, dass der berechnete Schwerpunkt außerhalb
der Ergebnismenge liegt. Das ist durchaus legitim.

7.2.2.2.2. Neuronale Netze


Im Gegensatz zu den anderen Verfahren handelt es sich bei einem neuronalen Netz um ein lernendes
Verfahren. Neuronale Netze bestehen aus mehreren miteinander verschalteten Ebenen (Layers, siehe Bild
Dreischichtiges Neuronales Netz). Jede Ebene besteht aus einer Anzahl Elementen, wobei jedes Element
ein Ausgangssignal aus mehreren Eingangssignalen (der übergeordneten Ebene) erzeugt. Dazu wird jedes
einzelne Eingangssignal von dem Element gewichtet und alle gewichteten Eingangssignale verundet. Um
die Gewichtung durchführen zu können, kann prinzipiell an jedes Element das gewünschte Ergebnis an-
gelegt werden, wobei das Element dieses von dem Ausgabesignal abzieht (subtrahiert) und das Ergebnis
als Fehlerwert zurückliefert. Die vorgestellten Elemente eines neuronalen Netzes können natürlich auch
andere mathematische Funktionen als die Summenfunktion benutzen, um das Ausgangssignal zu bilden.

214
Kapitel 7. Realzeit-Algorithmen

Wichtig für die Funktion ist zum einen die Art der Verschaltung der einzelnen Elemente und zum anderen
das verwendete Verfahren, um das Netzwerk zu trainieren (die Gewichtung zu verändern).

Ausgabeschicht

Zwischenschicht

Eingabeschicht

Abbildung 7-14. Dreischichtiges Neuronales Netz

W
0k
+1

W
1k
X
1k
Σ Ausgabe


Wnk Fehler
X
Σ
nk
+

Eingabesignale Gewichtung gewünschte


Antwort

Abbildung 7-15. Prinzipieller Aufbau eines neuronalen Netz-Elements

Einsatzbeispiele für neuronale Netze sind:

• Mustererkennung: Handschriftenerkennung, Objekterkennung


• Vision Chip: Ein neuronales Netz, das der Bewegung eines Objektes folgen kann (Kunstauge).

215
Kapitel 7. Realzeit-Algorithmen

• Einparkender LKW mit Anhänger.

7.2.2.2.3. Evolutionsstrategien und Genetische Algorithmen


Optimierungsverfahren die sich an der natürlichen Evolution orientieren, nennt man “evolutionäre Algorith-
men”. Derartige Algorithmen unterscheiden sich von den rein randomisierten Verfahren durch die folgenden
Aspekte:

• Existierende und mit einer genügenden Güte versehende Lösungen dienen jeweils als Ausgangsbasis für
die iterative Optimierung.
• Es wird nicht nur eine Lösung, sondern es wird eine Vielfalt von Lösungen parallel betrachtet und diese
Vielfalt ist Basis der Optimierung.

Die Parameter, die eine Lösung charakterisieren, werden als Gene bezeichnet. Alle Gene zusammengenom-
men nennt man Genotyp. Ein Genotyp charakterisiert also eine einzelne Lösung, deren Güte man über die
sogenannte Fitneßfunktion (also die Gütefunktion) bestimmen kann.
Bei der Evolutionsstrategie erzeugt man aus einem solchen Genotyp die Nachkommen, indem man den
ursprünglichen Genotyp (Eltern) kopiert und einzelne Parameter quasi per Mutation verändert. Die Güte
(Fitneß) der Nachkommen wird berechnet und es werden die besten Individuen in die aktuelle Generation
aufgenommen.
Diesen Ablauf iteriert man derart lange durch, bis entweder eine brauchbare Güte erreicht wurde, oder die
zur Berechnung zur verfügung stehende Zeit abgelaufen ist.

Erzeuge die aktuelle Generation (z.B. nach Monte Carlo)

While( es existiert kein Individuum entsprechender Güte oder noch Rechenzeit vorhanden)

Erzeuge Nachkommen durch Kopieren der Genotypen und Mutation


(Veränderung einzelner Parameter)

Bestimme die Güte der neuen Individuen.

Wähle aus allen Individuen die mit der besten Güte aus (neue aktuelle Generation)

Wähle aus der aktuellen Generation das Individuum mit der besten Güte aus.

Abbildung 7-16. Das Verfahren der Evolutionsstrategie

216
Kapitel 7. Realzeit-Algorithmen

B B 8
A A 1
Z Z 2
Eltern
F F 4
Q Q 3
E B E B 6
R A R A 8
3 Z
F 4
Q 3
Nachkomme
E 6
R 8

Mutation Crossover

Abbildung 7-17. Mutation und Crossover

Im Beispiel der Black Box könnte eine Generationsbildung so wie in Bild


Evoltionsstrategie am Black Box Beispiel dargestellt stattfinden. Im Beispiel wären beispielsweise
die unteren vier Eingangsleitungen direkt mit den Ausgangsleitungen verbunden. Das dargestellte
höchstwertigste Bit hat also keinen Einfluß auf den Ausgangswert.

Ausgangsindividuen 11011 00000 11111 01010


Fitneß 11 0 15 10
Mutation 10011 01000 10110 10010
Fitneß 3 8 6 2
Neue Generation 11011 01000 11111 01010
Fitneß 13 8 15 10

Abbildung 7-18. Evoltionsstrategie am Black Box Beispiel

Im Gegensatz zu den Evolutionsstrategien sind bei den genetischen Algorithmen jeweils zwei Individuen
an der Nachkommensbildung beteiligt. Hierbei wird auch weniger auf Mutation, als vielmehr auf Crossover
gesetzt (siehe Bild Mutation und Crossover). Beim Crossover werden jeweils Teilstücke der Elternindividu-
en miteinander verbunden. Die Auswahl der Elternindividuen und die Auswahl der Teilstücke erfolgt dabei
zufallsbedingt.

217
Kapitel 7. Realzeit-Algorithmen

Erzeuge die aktuelle Generation (z.B. nach Monte Carlo)

While( es existiert kein Individuum entsprechender Güte oder noch Rechenzeit vorhanden)

Selektiere zwei Elternindividuen mit fitneßproportionaler Wahrscheinlichkeit

Generiere die Nachfolgegeneration durch Crossover in Höhe der Crossover−Rate

Führe Mutation bei der Nachfolgegeneration durch (mit geringer Wahrscheinlichkeit)


Bestimme die Güte der neuen Individuen.

Wähle aus allen Individuen die mit der besten Güte aus (neue aktuelle Generation)

Wähle aus der aktuellen Generation das Individuum mit der besten Güte aus.

Abbildung 7-19. Genetischer Algorithmus

Ausgangsindividuen 11011 00000 11111 01010

Crossover 11000 00011 01110 11011


Fitneß 8 3 13 11
Neue Generation 13 15 14 13

Abbildung 7-20. Genetischer Algorithmus am Black Box Beispiel

Evolutionsstrategien bzw. genetische Algorithmen werden insbesonder im Bereich des Operation


Research eingesetzt. Damit läßt sich beispielsweise das angesprochene Roboter-Packproblem lösen. Auch
Reihenfolge-Probleme bei der Produktion unterschiedlicher Werkstücke. Die Algorithmen lassen sich aber
auch zur Wegeplanung einsetzen.

218
Kapitel 7. Realzeit-Algorithmen

7.2.2.2.4. Simulated Annealing

Abbildung 7-21. Globales Maximum

Einfache (iterative) Suchalgorithmen basieren oft auf der Annahme, dass ein globales Maximum existiert.
Damit führen Änderungen der Funktionsparameter entweder zu einer Verbesserung oder einer Verschlech-
terung. Verschlechtern sich die Ergebnisse aufgrund einer Parameteränderung, wird man den bzw. die Pa-
rameter in diese Richtung nicht weiter verändern.
Die Annahme, dass nur ein Maximum existiert, ist jedoch in den meisten Fällen falsch. Im Regelfall gibt
es neben dem gesuchten globalem Maximum mehrere lokale Maxima. Ein Suchalgorithmus der oben be-
schriebenen Art, wird aber niemals das globale Maximum erreichen, wenn er sich in Richtung auf ein
lokales Maximum hin bewegt.

globales Maximum

lokales Maximum

Abbildung 7-22. Globales Maximum

Abhängig von der Problemstellung muß ein Algorithmus auch in der Lage sein, Parameteränderungen
durchzuführen, die zu einer (kurzfristigen) Verschlechterung des bisherigen Ergebnisses führen.

219
Kapitel 7. Realzeit-Algorithmen

Eine Lösung des Problems bietet Simulated Annealing. Dieses Verfahren simmuliert den Erstarrungspro-
zess von Metallen. Metalle bilden Kristalle, eine in drei Dimensionen völlig regelmäßige Anordnung von
Atomen. Ein derartiger Kristall besitzt von allen möglichen Konfigurationen der Atome im Festkörper die
günstigste Energiebilanz [Otto 1994].
Um perfekte Kristalle zu bekommen, wird eine Metallschmelze sehr langsam, unter ständiger Wäremzufuhr
abgekühlt. Die zugeführte Wärmeenergie erlaubt den in Mulden festsitzenden Atomen, die energetischen
Barrieren zu überwinden und ihre korrekten Gitterplätze zu erreichen. Die Gesamtenergie des Kristalls wird
dadurch geringer und er nimmt die ideale Symmetrie an.
Problematisch bei diesem Verfahren ist die Dosierung der zuzufügenden Energiemenge. Sie muß ausrei-
chend sein, dass die Atome die korrekten Gitterplätze einnehmen können, sie darf jedoch auch nicht zu
groß sein, so dass die Schmelze auch wirklich erstarrt.
In der Analogie zur algorithmischen Problemstellung sitzen die Atome in einem lokalen Maximum fest.
Durch die Energiezufuhr können sie das lokale Maximum verlassen und sich auf das globale Maximum
hinbewegen.
Die Wahrscheinlichkeit, mit der die Atome ihre Fehlposition verlassen, ist durch eine Exponentialfunktion
beschrieben:
P(∆E)=e(-∆E/kT)

wobei k die Boltzmannkonstante, ∆E der Energieunterschied zwischen der Gesamtenergie vorher und der
Gesamtenergie zum aktuellen Zeitpunkt und T schließlich die Temperatur ist.
Ob der neue Systemzustand aber eingenommen wird (die aktuelle Position verlassen wird) oder nicht, wird
schließlich dadurch festgelegt, ob die Wahrscheinlichkeit P(∆E) größer als eine zwischen 0 und 1 bestimmte
Zufallszahl ist.
Zur Abbildung eines konkreten Problems auf diesen Algorithmus muß man nun

1. die Parameter auf den Temperatur-Parameter abbilden.


2. einen Algorithmus zum Positionswechsel zur Verfügung stellen.

Der Algorithmus läuft schließlich folgendermassen ab:


Man diskretisiert den Verlauf der Temperatur. Bei jedem Temperaturschritt wird eine definierte Anzahl von
Optimierungsschritten durchgeführt. Jeder Optimierungsschritt besteht darin, Veränderungen am System-
zustand durchzuführen. Entsprechend der obigen Gleichung wird der neue Systemzustand akzeptiert oder
nicht. Ist ein Optimierungsschritt abgeschlossen, wird die Temperatur erniedrigt. Wenn bei einer Temperatur
überhaupt keine Verbesserung mehr eintritt, ist das Verfahren abgeschlossen. Bei entsprechend vorsichtiger
Temperaturerniedrigung (Anzahl der Diskretisierungsstufen) befindet sich das System nahe der optimalen
Lösung.

220
Kapitel 7. Realzeit-Algorithmen

Wähle eine Anfangskonfiguration


neue Konfiguration = Anfangskonfiguration
Wähle eine Anfangstemperatur T>0
Modifiziere die aktuelle Konfiguration leicht.
Berechne die Güte der aktuellen Konfiguration
∆ E = Q(neu) − Q(alt)
if( ∆ E > 0 )
Ja Nein
− ∆E
neue Konfiguration = if( Zufallszahl < e kT)
aktuelle Konfiguration Ja Nein

neue Konfiguration =
aktuelle Konfiguration
bis lange keine Verbesserung der Güte
verringere T
until( Abbruchbedingung: Zeit oder Güte)

Abbildung 7-23. Struktogramm Simmulated Annealing

7.2.2.2.5. Treshold Accepting


Eine erste Modifikation hat Simulated Annealing mit dem Treshold Accepting Algorithmus erfahren. Ist es
bei Simulated Annealing immer noch notwendig, über die e-Funktion und die Bestimmung einer Zufallszahl
die Akzeptierung auch einer schlechteren Konfiguration zu berechnen, wird dieser aufwendige Vorgang
beim Treshold Accepting vermieden.
Anstelle der aufwendigen Berechnung wird die neue Konfiguration dann übernommen, wenn die Qualitäts-
steigerung unterhalb eines Schwellwertes (Treshold) liegt. Dieser Schwellwert wird wiederum als Tempe-
ratur T bezeichnet.
Spannenderweise führt diese Vereinfachung des Algorithmus in den meisten
Fällen zu genauere Ergebnissen, die in kürzerer Zeit berechnet werden. Tabelle
Vergleich von Simmulated Annealing (SA) mit Treshold Accepting (TA) [Otto 1994] zeigt die Ergebnisse
beider Algorithmen bei der Lösung des sogenannten Traveling Salesman Problems. Bei dieser
Aufgabenstellung gilt es einen möglichst kurzen Rundweg über eine Anzahl von Städten zu finden, wobei
keine Stadt mehrfach bereist werden darf.

Tabelle 7-2. Vergleich von Simmulated Annealing (SA) mit Treshold Accepting (TA) [Otto 1994]

Städte Weglänge (TA) Rechenzeit Weglänge (SA) Rechenzeit


25 18.75 1:18 min 19.87 2:23 min
50 40.7 2:54 min 44.47 4:45 min
75 62.9 4:39 min 70.97 7:16 min

221
Kapitel 7. Realzeit-Algorithmen

7.2.2.2.6. Great Deluge Algorithm (Sintflut)


Auch der Treshold Accepting Algorithmus wurde verfeinert, allerdings auf Kosten der Laufzeit. Beim Tres-
hold Accepting hängt die Qualität des Ergebnisses und die dazu benötigte Zeit stark von der Wahl der
Temperaturen ab, zu denen die Optimierungsschritte durchgeführt werden.
Als Analogie aus der Natur wird ein Wasserstand verwendet, der durch (ständigen) Regen erhöht wird. Die
Qualität einer Konfiguration wird ständig mit dem Wasserstand verglichen. Liegt die Qualität über dem
Wasserstand, wird die neue Konfiguration übernommen, ansonsten wird mit der alten Konfiguration weiter
gerechnet. Mit jeder Runde (Schleifendurchlauf) wird der Wasserstand erhöht.

7.2.2.3. Bewertung

Einsatz heuristisch zufallsbasiert lernend


Fuzzy
Steuerung 1)
Logik

Neuronale
Netze Steuerung 2) X

Genetische
Algorithmen Optimierung 3) X

Simulated Optimierung 4)
Annealing X

Monte Initialisierung
Carlo X
anderer
Las Algorithmen X