ezs_buch

Harte und weiche Echtzeitsysteme

Material zur Vorlesung Echtzeitsysteme I+IIimStudienfachTechnische Informatikan der

Hochschule Niederrhein.

Jürgen Quade

Harte und weiche Echtzeitsysteme: Material zur VorlesungEchtzeitsysteme I+IIim StudienfachTechnischeInformatik 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 undweiterverteilt

werden. Die kommerzielle Nutzung (Weiterverkauf) ist ohneZustimmung des Autorsbislangnicht erlaubt. Da auch die Quellen des Buches

zur Verfügung stehen, ist die Modifikation, Erweiterung undVerbesserung 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 Ex p $$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 qu ade $$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 quad e 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 qu ade $$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 $

InhaltsverzeichnisVorwort........................................................................................................................................................??

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

Tabellenverzeichnis3-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..........................................................................................................??

Abbildungsverzeichnis1-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ätsgesteuertem

??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. RechenzeitanforderungsfunktionC(I) ................................................................................................??2-31. RechenzeitanforderungsfunktionC(I) bei verschärften Bedingungen...............................................??2-32. Auflösung der Abhängigkeiten ...........................................................................................................??2-33. RechenzeitanforderungsfunktionC(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 vonfread .....................................................................................??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 Verwendungeines 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- undIstwerten .....................................................??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

Beispiele2-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....................................................................................................................................??

Gleichungen2-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

VorwortStellen Sie sich vor, Sie fahren in Ihrem PKW und beauftragengerade Ihren Boardcomputer damit, per Opti-mierungsverfahren die günstigste Strecke zu Ihrem Ziel zu finden. Keiner weiß genau warum, aber plötzlichtaucht dieser Baum vor Ihrer Windschutzscheibe auf, zum Bremsen ist es zu spät und schon schraubt sichIhr Fahrzeug um den Baum. Sie selbst werden in den Gurt gepreßt, schlagen noch einmal - glücklicherweisenur 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 einemlauten Knall der Airbag Ihres PKW’s in Millisekundenschnelle auf um kurz darauf gleich wieder in sichzusammenzufallen.

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 stelltdabei besondere Anforderungen und erfordert den Einsatz spezieller Techniken.

Bei dem vorliegenden Arbeitsbuch handelt es sich um das Begleitmaterial zur VorlesungEchtzeitsysteme Iund II im StudienfachTechnische Informatikan der Fachhochschule Niederrhein.

Ziel der Vorlesung ist dabei die Vermittlung notwendigen Wissens und der notwendigen Technologie, umRealzeitsysteme konzipieren, realisieren und bewerten zukönnen.

Obwohl das Material zum gegenwärtigen Zeitpunkt nicht vollständig und insbesondere stilistisch nichtaufbereitet 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. LernzieleFolgende 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. DefinitionenRealzeit-Steuerungssysteme bestehen aus dem technischenProzess, den Rechenprozessen und kognitivenProzessen. Im folgenden sollen diese Begriffe genauer erläutert werden.

1.1.1. ProzesseEin Prozess ist nach [DIN66201] eine "Gesamtheit von aufeinander einwirkenden Vorgängen in einemSystem, durch die Materie, Energie oder Information umgeformt, transportiert oder gespeichert wird". Manspricht von technischen Prozessen, wenn Material oder Energie umgeformt, transportiert beziehungsweisegespeichert wird, und von Rechenprozessen bei der Umformung, beim Transport beziehungsweise bei derSpeicherung 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ßtwerden. 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


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ßprozessefinden 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 Aufzugsteuerungenverarbeitet oder bei Prüfvorgängen von Geräten.

Stückprozess

Stückprozesse schließlich zeichnen sich durch einzeln identifzierbare Stücke (Objekte) aus, die sichin 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 einProgrammbeschrieben. Ein Programm beschreibt die Abfolge der Befehle und ist damit zunächst statisch. Die Instanzeines Programmes (die dynamische Abarbeitung des Programms also) ist dann der Rechenprozess. Anstelledes Begriffes Rechenprozess wird oft auch der BegriffTaskverwendet, insbesondere um eine Verwechse-lung mit dem technischen Prozess begrifflich auszuschließen.

Moderne Rechnersysteme und vor allem auch Realzeitsystemesind 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 Steuerungbezeichnet.

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 eingeschlossener Regelkreis vorliegt oder nicht. Vielleichtweil im Englischen nur das Wortcontrol existiert,wird im deutschen Sprachgebrauch auch dann oftmals der Begriff Steuerungverwendet, wenn es sich imeigentlichen Sinn um eine Regelung handelt (z.B. Speicherprogrammierbare Steuerung).

2


technischerProzeßprozeß

Rechen−

Aktor(−en)

technischerProzeßprozeß

Rechen−

Aktor(−en)

geregelter Prozeß

Sensor(−en)

gesteuerter Prozeß

1 0 1 0

Abbildung 1-1. Steuerung versus Regelung

Man spricht also von einem geregelten - im Gegensatz zum gesteuertem - Prozess, wenn dieser jeweilsmindestens einen Wandler für ein Ein- als auch ein Ausgangssignal (Aktor und Sensor) besitzt (BildSteuerung versus Regelung). Dabei wird der Eingangswert (die Stellgröße) durch den über einen Sensorgewonnenen 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 aufdie 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 Nordin 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 AGentscheidet, welche Waggons bevorzugt behandelt werden.

Technischer Kognitiver

ProzeßProzeß

Rechen

Prozeß

Aktoren

Sensoren Userinput

Visualisierung

Abbildung 1-2. Zusammenhang zwischen unterschiedlichen Prozessformen

3


1.2. Kennzeichen von RealzeitsystemenBei 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 sogenanntePünktlichkeitoderRechtzeitigkeitund damit insbesondere verbunden die Eigenschaft, zeitlich determini-stisch (also berechenbar oder zumindest vorhersehbar und vorhersagbar) zu sein. Eine oftmals notwendigeEigenschaft, aber auf keinen Fall ein Kennzeichen eines Echtzeitsystems ist die Schnelligkeit.

Echtzeitsteuerung

(z.B. technischer Prozeß)Umwelt

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

1 0

Abbildung 1-3. Struktur eines Echtzeitsystem

Echtzeitsysteme (BildStruktur 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 Benutzerdirekt damit in Berührung kommt (eingebettete mikroelektronische Steuerung), spricht man von einemeingebetteten Realzeitsystem. Im Automobil beispielsweise finden sich eingebettete Realzeitsysteme, diezur Steuerung des Motors (Motormanagement), zur Steuerungdes 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 demWindows-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 nachSicherheit(das System mußauch wirklich dasrichtige Ergebnis liefern) undVerfügbarkeit(das System darf unterkeinenUmständenausfallen).

Elektronik RTOS Standard−OS Mechanik Handbetrieb

1 ms 1 s 10 s 100 s 1000 s

Programm+ ISR

1 us1 ns

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

4


Gemäß der obigen Definition sind also alle Systeme mit zeitlichen Anforderungen Echtzeitsysteme. BildRealzeitsysteme und ihre Zeitanforderungen [TimMon97]spiegelt entsprechend der Zeitanforderungensinnvolle Realisierungstechnologien wider. Dabei erkennt man, dass Echtzeitsysteme sogar vonHand betrieben werden können, wenn Reaktionszeiten im Stundenbereich gefordert werden.Muß auf eine zeitliche Anforderung im Minutenbereich reagiert werden, kann man mechanischeSteuerelemente einsetzen. Mit Standard-Betriebssystemen ist es bereits möglich, Realzeitanforderungenim Sekundenbereich zu bedienen. Sind die Zeitanforderungen jedoch noch strenger, wird man einRealzeitbetriebssystem einsetzen, zumindest, solange die Anforderungen nicht im Mikrosekunden-Bereich(usec) liegen. In diesem Zeitbereich lassen sich die Probleme zwar noch mit Software lösen, entsprechendeReaktionen müssen aber innerhalb der sogenannten Interrupt-Service-Routine erfolgen. Um noch stärkereAnforderungen zeitlicher Natur zu befriedigen, muß man schließlich eine Hardware-Realisierung wählen.

Im folgenden wird der Schwerpunkt auf Realzeitsysteme liegen, deren Zeitanforderungen imMillisekunden-Bereich liegen, zu deren Realisierung im Normalfall ein Echtzeitbetriebssystem eingesetztwird. Während aber auch das Spektrum der Echtzeitsysteme mit noch höheren Anforderungen betrachtetwird, 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 RealzeitsystemenWie 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 alsharte Realzeitsysteme eingesetzt werden. SPS’n werden im Regelfall über spezielle Programmier-sprachen und -Werkzeuge programmiert und arbeiten in einemfesten Zeitraster (Zykluszeit).

Eingebettete Systeme

Als ein eingebettetes System bezeichnet man die Steuerung eines technischen Prozesses, mit der derBenutzer 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


• 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, wiedas Modem, das ABS, die Waschmaschi-nensteuerung und der Gameboy.

Echtzeitsysteme - oder Realzeitsysteme - werden im amerikanischen vielfach gleichgesetzt mit deneingebetteten Systemen (embedded systems). Diese Sichtweise ist jedoch zu einfach. Wenn auch diemeisten eingebetteten Systeme Realzeitsysteme sind, so doch nicht ausschließlich alle. Nicht jedeseingebettete System ist ein Realzeitsystem, und nicht jedes Realzeitsystem ist ein eingebettetes System.

Eingebettete Systeme - mit ihren zusätzlichen Anforderungen - spielen auch in dem vorliegenden Bucheine besondere Rolle.

RZ-Applikationen auf Standardarchitekturen (auch Soft-SPS)

Zwar für harte Realzeitsysteme nicht geeignet, werden Standardarchitekturen, wie beispielsweise einePC-Architektur, zur Lösung von weichen Echtzeitproblemeneingesetzt. Typische Beispiele dafür sindMultimediaanwendungen 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 Komponentemit deterministischem VerhaltenInformationen aus.

1.2.2. Einsatzbeispiele

• Consumer

• Waschmaschine• Fotoapparat

• Luft- und Raumfahrt• Satellitensteuerung

6


• 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-KomponentenRealzeitsysteme bestehen aus unterschiedlichen Komponenten. Je nach Ausprägung des Realzeitsystemssind dabei nicht alle Komponenten notwendig. So wird beispielsweise bei einem Computerspiel in denseltensten Fällen eineProzessperipheriebenötigt.

Regel− und

Steuerprogramm

Applikation

Visualisierung

Realtime Operating System

Hardware

Prozeßankopplung

Prozeßperipherie

(Sensoren, Aktoren)

direkte Kopplung

oder Feldbus

Abbildung 1-5. Architektur einer Echtzeitsteuerung

7


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 Prozesse1 (z.B. ein technischer Prozess) auf sogenannte Rechenprozesse (sieheAbschnitt Rechenprozess) abgebildet, die auf einer Hardware (Rechner, Mikrokontroller) ablaufen. DieEingangswerte der Rechenprozesse korrespondieren mit Signalen des externen Prozesses. Wandler (Meß-wertaufnehmer, Sensoren) transformieren dabei diese (physikalischen) Signale und Werte in maschinellverarbeitbare Digitalwerte. Entsprechend werden die von den Rechenprozessen erzeugten Ausgangs- bzw.Ausgabewerte über Wandler (Stellglieder, Aktoren) in (physikalische) Größen transformiert, mit denen sichder 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 dieexternen Prozesssignale direkt an ihrer Entstehungsquelle gewandelt und als digitale Information an denRealzeitrechner übertragen, bzw. vom Realzeitrechner alsdigitale Information an den externen Prozessgebracht. 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 Prozessauch direkt angekoppelt werden. In diesem Fall ist jedes Ein- und Ausgangssignal des externen Prozessesdirekt mit der Hardware des Realzeitsystems verbunden.

Eine direkte Kopplung verwendet man aber vor allem auch beimzweiten 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 mehrerenProzessoren, dem Speicher und der soge-nannten Glue-Logik (Bausteinen, die das Zusammenspiel derübrigen Komponenten ermöglichen). Darüberhinaus 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 normalerweisein Software realisiert worden wäre, in Hardware realisiert(Asics, FPGA’s, LCA’s usw.). Daneben gehörenauch Sekundärspeicher (z.B. Festplatten, Flashkarten) zur Rechnerhardware.

Die Rechnerhardware wird über ein Realzeitbetriebssystemoder ein Laufzeitsystem (Executive, einfachesBetriebssystem) angesteuert. Dieses Betriebssystem stellt die Ablaufumgebung für die Rechenprozesse zurVerfügung. Die Hardware wird dabei über Gerätetreiber abgebildet.

In Realzeitsystemen laufen mehrere Rechenprozesse scheinbar gleichzeitig ab (quasi parallel). Neben denRechenprozessen, die applikationsspezifisch sind, gibt esin einem Realzeitsystem oftmals auch Rechen-prozesse, die zum Betriebssystem gehören (Dienstprogramme). Bei solch einem Dienstprogramm kann essich 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 desZustandes des externen Prozesses kümmern.

8


1.3.1. Abbildung des technischen Prozesses auf Rechenprozesse

Temp.Regelung

DruckRegeleung

RechenprozesseProzeß

Realzeit−SteuerungTechnischer

Abbildung 1-6. Abbildung technischer Prozesse auf Rechenprozesse

Bei der Abbildung technischer Prozesse auf Rechenprozesse(BildAbbildung technischer Prozesse auf Rechenprozesse) werden zusammengehörigeZustandsgrößen und Stellwerte der technischen Prozesse (z.B. der Temperaturwert und die Stellgröße fürdie 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 (BildElemente der Datenflußdiagramme) eingesetzt. Bei dieser Diagrammform werden Prozesse(Rechenprozesse, Verarbeitungseinheiten) als Kreise dargestellt. Pfeile kennzeichnen Daten und dieFlußrichtung der Daten, die zwischen Rechenprozessen und von und zu Datenspeichern ausgetauschtwerden. Datenspeicher werden als zwei übereinanderliegende waagerechte Striche dargestellt. Über dasFassungsvermögen der Datenspeicher wird keine Aussage getätigt. Die Darstellung der Datenquellenund der Datensenken unterbleibt oftmals. Die Pfeile sollten bezüglich der ausgetauschten Datengekennzeichnet werden. Dabei ist darauf zu achten, wirklich die Daten als solche, und nicht dieOperationen auf die Daten anzugeben.

Die ursprünglichen Datenflußdiagramme sind für die Darstellung von Echtzeitsystemen noch um weitereElemente, 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


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

Auto

Strecke

Speed

Zustandsinfo

PositionFremd−

Auto

Rennbahn/dev/Carrera

Rennbahn/dev/Carrera.other

LängeStreckentyp,

Streckentyp,

Position

Abbildung 1-8. Einfaches DFD einer Carrerabahnsteuerung

AbbildungEinfaches DFD einer Carrerabahnsteuerungstellt das Datenflußdiagramm einer Carrerabahn-steuerung dar. Die VerarbeitungseinheitAutobekommt von der Rennbahn Zustandsinformationen und be-rechnet daraus Geschwindigkeitswerte (Speed). Aufgrund der Zustandsinformationen werden Streckentypund Länge eines Streckensegments berechnet und in einem Datenspeicher abgelegt.

Die Position des gegnerischen Fahrzeugs erhält der RechenprozessAuto über den RechenprozessFrem-dauto. Dieser bekommt Positionsangaben in Form von Segmenttypenebenfalls von der Rennbahn, aller-dings über das Interface/dev/Carrera.other . Zur genauen Bestimmung des gegnerischen Fahrzeugs aufder Strecke wird diese Information mit der Streckeninformation abgeglichen.

Erfas−sung dierung

Ko−Versand

Audiodaten Sendepuffer

Audiosignaldigitalisiertes

Konfiguration

RohdatenPakete Netz

PaketeHardware

Audio

Abbildung 1-9. DFD Audiostreaming

AbbildungDFD Audiostreamingstellt das vereinfachte DFD eines Audiostreaming-Systemsdar. Hier istder Rechenprozess Erfassung für die zeitgenaue Aufnahme der digitalisierten Audiosignale zuständig. Fürdie 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-chenprozessKodierungübergeben. Diese Verarbeitungseinheit liest zu Beginn eine Konfigurationsdatei, inder das zu verwendende Kodierungsverfahren samt seiner Parameter beschrieben ist. Entsprechend dieserInformationen werden die Daten, die sich im DatenspeicherAudiodatenbefinden, kodiert, paketiert und inden Sendepuffer abgelegt. Auch das Senden muß aus Gründen der Echtzeitfähigkeit über einen Datenspei-cher entkoppelt werden.

10


Anhand eines reinen Datenflußdiagramms sind keinerlei dynamischen Abläufe sichtbar. Das DFD gibt einestatische 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 dannfür A ein neues Gebilde von Rechenprozes-sen, Datenflüssen und Datenspeichern gezeichnet.

Fußnoten1. 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 ausdem externen (technischen) Prozess und dem Realzeitsystem.

11


12

Kapitel 2. Schritthaltende Verarbeitung undEchtzeitbetrieb

Unter schritthaltender Verarbeitung bzw. Echtzeitbetrieb versteht man die fristgerechte Bearbeitung vonAnforderungen aus einem technischen Prozess. Was aus Sichtdes 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 gestelltenZeitschranken bearbeitet werden, sind die Folgen möglicherweise katastrophal. Daher ist es notwendig, diezeitlichen Anforderungen und die zeitlichen Kenndaten bezüglich der Steuerung (der Rechenprozesse undderen Ablaufumgebung) zu kennen.

Daher werden in diesem Kapitel die Zeitschranken des technischen Prozesses formal eingeführt. Außerdemwerden 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, geplantwerden.

• Die richtige Reihenfolge der Aufgaben ist entscheidend, umdie zeitgerechte Bearbeitung der Aufgabengewä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. EchtzeitbedingungenDer 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 zueinem Zeitpunkt auftreten (erste Echtzeitforderung).

Der zeitliche Abstand zwischen zwei Anforderungen gleichen Typs wird Prozesszeit (tP) genannt. Ist der

zeitliche Abstand zweier Ereignisse konstant, spricht manvon einem periodischen Ereignis. Vielfachschwankt jedoch der zeitliche Abstand, so dass es einen minimalen zeitlichen Abstand t

Pminund einen

maximalen zeitlichen Abstand tPmax

gibt.

Der Auftrittszeitpunkt eines zu einem Rechenprozess gehörenden Ereignisses wird mit tA

(im englischenauch mitReleasetimebezeichnet. 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»t

A=0« auf.

Das zeitliche Auftreten der Ereignisse wird in einer Anforderungsfunktion dargestellt. Dazu werden dieAnforderungen (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

Pmint

Pmaxt

t[T]

E E EE

Eintritt des Ereignisses E

EE

Pmint

Pmaxt

= 2T

= 6TPt =

22T+6T = 4T

Abbildung 2-1. Anforderungsfunktion

Für die eigentliche Bearbeitung des Ereignisses werden vomRechner Anweisungen abgearbeitet. Die zumEreignis gehörende Folge von Anweisungen wird hier als Codesequenz oder auch als Job bezeichnet. Jobssind innerhalb des Rechners als Rechenprozesse realisiert, die sich selbst wiederum in Tasks und Threadsunterscheiden 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 diesogenannte Verarbeitungszeit t

V,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 dieLeistung des Prozessor schwankt (bedingt durch Caches und DMA). Zur Berechnung bei Echtzeitsystemenmuss daher RA

maxund P

minangesetzt werden.

Die für den Worst-Case anzunehmende Verarbeitungszeit wird in der Literatur auch Worst-Case-ExecutionTime (WCET) genannt (siehe Kapitel [Abschätzung der Worst Case Execution Time (WCET)]).

2.1.1. AuslastungAbhängig von der Auftrittshäufigkeit eines Ereignisses undder damit anfallenden Verarbeitungszeit istder Rechnerkern (Prozessor) ausgelastet. Die Auslastung (ρ) durch eine Anforderung ergibt sich damit alsQuotient aus notwendiger Verarbeitungszeit und Prozesszeit:

ρ=tV/t

P

Ein Realzeitsystem muss in der Lage sein, die auftretenden Anforderungen in der Summe bearbeiten zukönnen (oft auch als Forderung nachGleichzeitigkeitbezeichnet). Mathematisch bedeutet dieses, dass dieGesamtauslastungρ

geskleiner als 100% sein muss.

Die Gesamtauslastung ergibt sich aus der Summe der Auslastungen der einzelnen Jobs.

Gleichung 2-1. Gesamtauslastung

Σi=0

n ttv

i

pi

ρ = ≤ 1

14


AtV

BPt A

APtAtV

PtBt

B

V

=Pt

Bt

B

VρB

A

APtAtVρ =

Vt B

Pt

Prozessor−belegung

ρ =A+B +

t

Rechenprozess A

Rechenprozess B

Rechenprozess A + B

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 t

V,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 ebenfallstV,B

=0.8ms und hat dieser auch eine Prozesszeitvon t

P,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ünktlichkeitAus dem technischen Prozess kommen immer wieder Anforderungen an die Echtzeitsteuerung. Aufgabeder Steuerung ist es,alle Anforderungenzeitgerechtzu bearbeiten.Alle bedeutet in diesem Falle, dass derRechner leistungsfähig sein muss, um mit der vorgegebenen Last fertig zu werden.Zeitgerechtbedeutet,dass der Rechner die Anforderungenrechtzeitigbzw.pünktlichbearbeitet.

Das wesentliche Kriterium für ein Realzeitsystem istPünktlichkeitin Abgrenzung zuSchnelligkeit.

Allerdings lassen sich Anforderungen an Pünktlichkeit mitschnellen Systemen leichter erfüllen als mitlangsamen. Prinzipiell muss ein Realzeitsystem eine Aufgabe in einem vorgegebenen Zeitfenster erfüllthaben, wie es das tut, ist dabei unwesentlich.

15


tZmin tRmax0t tZmax t

Ereignistritt ein

Bereichdes

Rechners

erlaubttatsächlich

Reaktions−

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 bestimmtenZeitpunkt durchgeführt wird, fehlt oft(t

Zmin=t

0) 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 letzlichauch 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 demEintreten eines Ereignisses. Die maximal zulässige Reaktionszeit, wie sie hier gebraucht wird, beinhaltetnur die Zeiten, die für die Rechenprozesse relevant sind. Unter maximaler zulässiger Reaktionszeit wirdalso der Zeitpunkt verstanden,biszu dem derRechenprozessseine Ausgabe gemacht haben muss. Es wirdnicht der Zeitpunkt verstanden, bis zu dem der technische Prozesseinen definierten Zustand eingenom-men haben muss. Sind daher die Randbedingungen des technischen Prozesses bekannt, muss die maximalzulässige Reaktionszeit des Rechenprozesses daraus abgeleitet werden.

Mit maximaler Reaktionszeit tRmax

wird der Zeitpunkt bezeichnet, bis zu dem durch den Rechner eineReaktion in jedem Fall erfolgt ist. Es handelt sich um eineWorst CaseZeit. Die maximale Reaktionszeitmuss also immer kleiner sein als die maximal zulässige Reaktionszeit.

Weiche

300 mm

ms

v=1

Umschaltzeit=200ms

t300

= sv = 0.3 m

1 m s = 300 ms

tZmax

= t = 100 ms300

tU

Barcodeleser

To You

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


ter und stellt daraufhin die Weiche. Die Postbehälter habeneine Geschwindigkeit von v=1m/s. Die Weichehat 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 100msder Weiche die Anweisung übermitteln, in welches Rohr der Postbehälter weitergeleitet werden muss. Diemaximal zulässige Reaktionszeit beträgt damit t

Zmax=100ms. Die maximale Reaktionszeit t

Rmaxkann auf-

grund fehlender Informationen nicht angegeben werden. Diese Zeit basiert nämlich auf der Leistung desverwendeten 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 diemaximal zulässige Reaktionszeit t

Zmaxdurch die Anforderung definiert, dass ein Ereignis vor dem Eintreffen

eines nachfolgenden Ereignisses gleichen Typs bearbeitetsein 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 eineMittelwertbildung (bei einer Gleichverteilungzum 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 Ereignissesnoch nicht abgeschlossen ist. Der Rechenprozess muss warten. Diese Zeit wird als Wartezeit t

Wbeschrie-

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 t110 120

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 zusammenmit der Rechnerkernbelegung ineinDiagramm ein.

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

R).

17


tZmin≤t

R≤t

Zmax

Gleichung 2-3. Rechtzeitigkeitsbedingung

tZmin ≤ tRmin ≤ tRmax ≤ tZmax

2.1.3. Harte und weiche Echtzeit

Zeit

harte Echtzeit

weiche Echtzeit

Deadline

Kosten

tZmin

tZmax

Abbildung 2-6. Harte und weiche Echtzeit als Kostenfunktion

Die Forderung nach Rechtzeitigkeit ist nicht bei jedem System gleich stark. Während das nicht rechtzeitigeAbsprengen der Zusatztanks bei einem Raumschiff zum Verlust desselbigen führen kann, entstehen durchVerletzung der Rechtzeitigkeitsbedingung bei einem Multimediasystem allenfalls Komfortverluste. Viel-fach findet man den Begriffharte Echtzeit, wenn die Verletzung der Realzeitanforderungen katatrophaleFolgen hat und daher nicht toleriert werden kann. Man findet den Begriff derweichen Echtzeit, wenn dieVerletzung der Realzeitanforderungen verkraftet werden kann. Allerdings kann man nicht ausschließlichzwischen „harter“ und „weicher“ Echtzeit unterscheiden, sondern jegliche Abstufung zwischen den beidenExtremen (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 sogenanntenweichen Echtzeitsystemenbedeutet das Verletzen der Realzeitbedingung einenleichten Anstieg der Kosten. Bei den sogenanntenharten Echtzeitsystemensteigen jedoch die Kosten durchdie Verletzung der Realzeitbedingung massiv an.

18


tZmin

tZmin

tZmax

tZmax

t0

Benefit

100 %

t

no realtime requirements

soft realtime requirements

hard realtime requirements

minimal zulässige Reaktionszeit

maximal zulässige Reaktionszeit

Abbildung 2-7. Benefit-Function

Eine andere Art der Darstellung ist die sogenannte Benefitfunction (Nutzenfunktion). Hier wird derNutzender Reaktion des Realzeitrechners auf das Ereignis über dieZeit aufgetragen. Bei Systemen ohne Echt-zeitanforderungen ist der Nutzen unabhängig von dem Zeitpunkt der erfolgten Reaktion, bei einem absolutharten Echtzeitsystem ist nur dann ein Nutzen vorhanden, wenn die Reaktion innerhalb des durch t

Zminund

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ätenIst die Auslastungsbedingung (siehe [Auslastung]) erfüllt, die Rechtzeitigkeitsbedingung aber nicht, kanndas Problem unter Umständen dennoch mit der vorhandenen Hardware gelöst werden. Hierzu sind dannallerdings weitere Maßnahmen, insbesondere bezüglich derSystemsoftware und der Architektur der Real-zeitapplikation notwendig: Die gestellte Aufgabe muss ichin (unabhängige, parallel ablaufende) Teilaufga-ben zerlegen lassen. Die einzelnen Teilaufgaben (Jobs) müssen unterbrechbar sein und müssen priorisiertwerden.

Aufnehmen SichernMeßwerteMeßwerte

100 Meßwerteerfaßt

Abbildung 2-8. Datenflußdiagramm Meßwertaufnahme

19


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 t

V1=500 µs. Jeweils 100 Meßwerte

(tP2

=100tP1

=100ms) ergeben einen Datensatz, der vorverarbeitet und zur Archivierung weitergeleitet wird.Dazu ist eine Rechenzeit von t

V2=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

Verarbeite Datensatz

Warte auf Timer−Event

Archiviere Ergebnis

Abbildung 2-9. Struktogramm Meßwerterfassung sequentiell

100 101 102 10397 98 99 140

Anforderung

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 CodesequenzVerarbeitung, welche den Prozessor für 40msbelegt. 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


die Verarbeitung der Werte und Sicherung der Ergebnisse. Über sogenannteInter-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 Ereigniszugestellt. 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«unterbrechbargemacht werden, das bedeutet, dass jedes-mal, wenn der Timer-Event auftritt, Rechenprozess »Verarbeitung« kurz unterbrochen wird (man sprichtvon 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 alsKontextswitch1. Ein Kontextswitchbenötigt Zeit, die jetzt auch noch in die Berechnung der Auslastung (1. Echtzeitbedingung) mit einfließenmuss. Wir werden jedoch in unseren Betrachtungen davon ausgehen, dass die Kontextwechselzeit so geringist, dass sie vernachlässigt werden kann.

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

Sende Timer−Event in 1 ms

Nimm Meßwert auf

Warte auf Timer−Event

SendMsg an "Verarbeitung"

RcvMsg von "Erfassung"

Archiviere Ergebnis

Verarbeitung der Daten

Rechenprozess "Erfassung" Rechenprozess "Verarbeitung"

while( 1 )while( 1 )

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

Abbildung 2-11. Struktogramm Meßwerterfassung parallel

100 101 102 10397 98 99 140

Anforderung

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, einzelneRechenprozesse 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


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öhePrioritä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 zukönnen, kann man initial nach folgender Regel verfahren:

Merke: Prozesse mit kurzen Rechenzeiten tV

haben in der Regel auch kurze Prozesszeiten tP

undbekommen hohe Prioritäten.

Prozesse mit langen Rechenzeiten tV

haben in der Regel auch lange Prozesszeiten tP

und bekommenniedrige Prioritäten.

Variable Prozesszeiten.Das Problem der Prioritätenvergabe und Auslastungsberechnung wird auchdadurch 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ösendenAufgabenstellung (zum Beispiel vom physikalischen Prozess).

SindsichereInformationen, ü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 BetrachtungenFür die Berechnung, ob alle Echtzeitanforderungen erfülltsind, ist immer der sogenannteWorst Case(schlimmste Fall) heranzuziehen. Der Worst Case ist der Fall, an dem die Prozessereignisse am dichtestenaufeinander folgen (oder besser, die höchste Belastung mitsich bringen). Da meistens mehrere Prozesssi-gnale unterschiedlichen Typs (und damit mit unterschiedlichen Ankunftszeiten) vorhanden sind, ist das beider Bestimmung des Worst Case mit zu berücksichtigen.

− t

− tPmin

Vmax

0− alle (sonstigen) Ereignisse treten zum Zeitpunkt t ein (alle Ereignisse kommen gleichzeitig).

Für die Worst Case Betrachtung ist eine möglichstgroße Belastungssituation für das Rechensystemanzusetzen:

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 dieProzesszeiten möglichst kurz sind und im Gegenzug die Verarbeitungszeiten möglichst lang. Außerdem ist

22


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

tRmin

tZmaxE

1 2t

tRmin

tZmaxE

t1 2

1=Berechnung2=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 Architekturdes Systems. Löst beispielsweise das Ereignis aus dem technischen Prozess zum Zeitpunkt»t

A=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 anderenEchtzeitverhalten, als wenn der Rechenprozess direkt nachEintritt des Ereignisses gestartet wird,diese aber nur die Ausgabe des Ergebnisses an den technischen Prozess zum Zeitpunkt t

Zminbeauftragt

(Abbildung [Verteilung der Rechenzeit bei minimalen Reaktionszeiten], oben).

Bezüglich der 1. Echtzeitbedingung (Auslastungsbedingung) muss die Summe aller Auslastungen, zu demZeitpunkt, 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 t

A=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ängigenEreignissen.

Die Abhängigkeiten der Ereignisse untereinander machen die Worst Case Bestimmung in der Praxis schwie-rig. Oftmals wird man daher davon ausgehen, dass Abhängigkeitennicht 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 Ereignissegleichzeitigauftreten. Das führt im Ergebnis zu einerhöheren Auslastung, als sie in der Realität gegeben sein wird.

23


E E E

t[ms]

E EE 25 ms1 ms

max. 10

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

Ein Beispiel zur Bestimmung des Worst Case: Ein technischerProzess erzeugt einen Ereignisschwallvon 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 alle100 ms auftreten. Der minimale Abstand zwischen zwei Ereignisschwällen beträgt 25 ms. Jedes Signaldes technischen Prozesses muss bearbeitet sein, bevor das nächste Signal des gleichen Typs eintrifft.Damit ergibt sich t

Zmax=1ms für die Ereignisse des Ereignisschwalles. Die Aufgabewird 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 maximalenAnzahl von Ereignissen, nämlich 10, mitminimalen 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 t

V1die 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 t

V2an. Diese

Signale werden durch den Rechenprozess 2 bearbeitet.

Dadurch ergibt sich die maximale Auslastung jetzt zu:

ρ2=t

V2/ t

P2;

ρGesamt

= ρMax

+ ρ2= 10t

V1/34ms + t

V2/5ms

Jetzt soll für das angegebene Beispiel die 2. Echtzeitbedingung überprüft werden. Dazu ist zunächst dieVergabe von Prioritäten notwendig. Nach RegelPrioritätenvergabebekommt der Rechenprozess mit derkü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 Ereignissedes Ereignisschwalles als auch die periodisch ankommendenSignale auftreten (Abbildung[Beispiel Variable Prozesszeiten: Rechnerkernbelegung]). Bei den gegebenen Zahlen führt das zu einerWartezeit t

W=2ms und damit einer Reaktionszeit t

R=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 diesemZeitpunkt nur 50% Rechenleistung für Rechenprozess 2 übrig. Für den Rechenprozess 2 bedeutet dies, dassdie Verarbeitungszeit t

V22.5ms nicht überschreiten darf (1. Echtzeitbedingung).

24


1 2a 2b1 1 1 1 1 1 1 1 12a 2b 2a2b0 t[ms]

2c 2d 2c 2d1021 3 4 5 6 7 8 9

Abbildung 2-16. Beispiel Variable Prozesszeiten: Rechnerkernbelegung

2.4. EchtzeitnachweisDer Nachweis, dass alle zeitlichen Anforderungen der Aufgabenstellung unter allen Umständen eingehaltenwerden, ist sehr schwierig. Insbesondere sind für unterschiedliche Schedulingalgorithmen (siehe [KapitelScheduling]) 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 Bestimmungder minimalen Reaktionszeit oft kein Problemdarstellt, ist die Bestimmung der maximalen Reaktionszeitnicht trivial.

2.4.1. Abschätzung der Worst Case Execution Time (WCET)Die maximale Verarbeitungszeit t

Vmax- 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 allenfallsabgeschä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


Ausmessen der WCET.Die WCET wird dadurch bestimmt, dass die zugehörige Codesequenz (imRegelfall auf der Zielplattform) abgearbeitet wird. Dabeiwird die Zeit zwischen Eintreten des Ereignissesund Ausgabe bestimmt.

Für die Messung

der WCET

modifiziert.

1t

t2

while( TRUE )

Warte auf Ereignis

= Zeitstempel

Eigentliche Verarbeitung

= 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 Reaktionerfolgt ist, ein Zeitstempel abgelegt wird. Die Differenz ergibt die aktuelle Ausführungszeit t

Vmax.

Beim ersten Durchlauf wird diese als WCET abgelegt, bei den nachfolgenden Durchläufen wird dieneu berechnete Zeit mit der abgelegten Zeit verglichen. Istdie neu berechnete Zeit größer als die bishergemessene 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 musstheoretisch 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


• 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ßerdemist noch eine Hardwarebeschreibung notwendig. Die Analysewerkzeuge arbeiten so, dass aus dem Codezunächst ein Kontroll-Graf erstellt wird. Die Laufzeit dereinzelnen Codesequenzen des Kontroll-Grafenkö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 desProzessor-Pipelinings.

Unabhängig vom Verfahren gilt prinzipiell, den ausgemessenen Code nicht nachträglich zu verändern undaußerdem noch mit einem Sicherheitsaufschlag zu versehen.Als Sicherheitsaufschlag arbeitet der Ingenieurgern 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 einerminimal zulässigen Reaktionszeit t

Zminabgearbeit worden sein darf.

Die Bestimmung der BCET ist jedoch einfacher als die Bestimmung der WCET. Hier kann der Code rechteinfach analysiert werden. Ansonsten kann die Bestimmung der BCET erfolgen, wie bei der WCET, wobeiallerdings möglichst wenig Last auf dem System vorhanden sein soll.

2.4.3. Echtzeitnachweis bei prioritätengesteuertem SchedulingDer 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, einzelnenEreignisse.

Die BCET und WCET werden für die Berechnung der minimalen respektive maximalen Reaktionszeitenbenö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 dermaximalen Reaktionszeit Schwierigkeiten. Hierzu soll im folgenden zunächst ein grafisches Verfahren unddanach ein mathematischer Ansatz vorgestellt werden.

27


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 Rechnerkernnoch zuerbringendeRechenzeitS(t) über der Zeit (Abszisse) aufgetragen2. Das impliziert, dassS(t) nicht ab-nimmt, solange keine neue Anforderung kommt.

t

2

1 2 3 4

1

S(t)

3

Abbildung 2-18. Grafische Berechnung der maximalen Reaktionszeit

Die Dimension vonS(t) wird so gewählt, dass1S 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 Abszisseentspricht der maximalen Reaktionszeit (im Bild also 1). Zujedem Zeitpunkt läßt sich anhand der Geradenablesen, 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 ergibtsich in Abbildung[Maximale Reaktionszeit im Beispiel Variable Prozesszeiten] eine initiale Rechenzeitanforderung vonR=t

v1+ t

v2= 2.5ms für das Beispiel mit variablen Prozesszeiten.

28


tRmax

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

1

1 2 3 4 5 6 7 8 9 10

3

2

1

1 2 3 4 5 6 7 8 9 10

2

1

t[ms]

t[ms]

S(t)[ms]

S(t)[ms]

S(t)[ms]

Job 1

Job 2

Job 1 + 2

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 eineder Anforderungen kommt, ohne dass der Rechnerkern mit der Bearbeitung einer anderen Anforderungbeschäftigt ist.

Danach wird die maximale Reaktionszeit des niedrigpriorsten Rechenprozesses, in diesemFall der Rechenprozess 3, mit Hilfe des grafischen Verfahrens bestimmt. Aus Abbildung[Bestimmung der maximalen Reaktionszeit] ergibt sich, dass die Reaktionszeit des Rechenprozesses 3imungünstigsten Fall 90ms beträgt, mehr als zulässig ist. Damit läßt sich dieser Prozess nicht in Echtzeitsteuern, obwohl die Auslastung unterhalb von 100 Prozent liegt.

29


5 10 20 30 40 50 60 70 80 90 100

10

20

30

40

123

1 1 1

3

2 2

t

S(t)

ohne

ohne

Job 2

Job 3

Abbildung 2-20. Bestimmung der maximalen Reaktionszeit

Verschiebt man die Zeitachse um die Rechenzeit des niedrigpriorsten Rechenprozesses nach oben, erhältman 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, obdie Bedingung tRmax

≤tZmax

erfüllt ist. Vor-aussetzung ist, dass die Ereignisse periodisch sind, den einzelnen Jobs Prioritäten vergeben wurden und ein

30


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

C

verbrauchte Rechenzeit

3

1

1

2

2

1

3

1

2

100 t908070605040302010

10

20

30

40

50

60

70

80

90

Rechenprozess 1höchste Priorität

mittlere PrioritätRechenprozess 1+2

Rechenprozess 1+2+3niedrigste Prioritä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)« überder 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 dieverbrauchte Rechenzeit grau hinterlegt. Falls X- und Y-Achse gleich skaliert sind, handelt es sich um denTeil unterhalb der Winkelhalbierenden.

Der Zeitpunkt t, zu dem sich C(t) und A(t) schneiden, ist die maximale Reaktionszeit des niedrigpriorstenProzesses:

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ätaufsummiert. Zuerst werden die Anforderungen der höchstprioren Rechenprozesse eingetragen.Der Schnittpunkt mit der Winkelhalbierenden gibt die maximale Reaktionszeit dieserJobs an. Danach werden die Anforderung der höchstprioren Rechenprozesse zusammenmit den Anforderung der nächst prioren Rechenprozesse aufgetragen (in Abbildung[Verifikation der Rechtzeitigkeitsbedingung (die Zahlen stammen aus dem Beispiel [])] die Linie

31


»Rechenprozess 1+2«). In diesem Fall entspricht der Schnittpunkt mit der Winkelhalbierenden dermaximalen Reaktionszeit der nächst prioren Rechenprozesse. Prozesse gleicher Priorität haben damit auchdie gleiche maximale Reaktionszeit.

Aus der Zeichnung [Verifikation der Rechtzeitigkeitsbedingung (die Zahlen stammen aus dem Beispiel [])]läßt sich demnach ablesen, dass t

Rmax,1=10ms, t

Rmax,2=25ms und t

Rmax,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 t

Rmaxergibt.

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

C(t) ≤ t; fr 0 ≤ t ≤ KGV (tPi)

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 t

Paller Jobs.

Die Rechenzeitanforderung C(t) läßt sich für periodische Codesequenzen mit der in[Berechnung der Rechenzeitanforderung eines periodisch aufgerufenen Jobs.] dargestellten Formelbestimmen. Dabei wird die eigene Rechenzeitanforderung zum Zeitpunkt t und die Anforderungen allerübrigen höher- oder gleichprioren Rechenprozesse (Jobs) aufsummiert. Die Gaußklammer entsprichtim übrigen der Funktionceil , die im Fall von Nachkommastellen den nächst höheren Integerwertzurückliefert (ceil(2,2)=3 ).

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

Ci(t) = dt

tp,i

e · tv,i +∑

j

dt

tp,j

e · tv,j ; mit j fr alle gleich− oder hherprioren Jobs

Für Rechenprozess 1 ergibt sich damit:

C1(t) = dt

30mse · 10ms

Die Funktion gibt 10ms für 0<t≤30ms zurück, 20ms für 30ms<t≤60ms usw. Für diesen Rechenprozessist die Bedingung [C(t) kleiner gleich t] erfüllt, er kann in „Echtzeit“ bearbeitet werden.

Für Rechenprozess 2 ergibt sich:

C2(t) = dt

45mse · 15ms + d

t

30mse · 10ms

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:

C3(t) = dt

60mse · 15ms + d

t

30mse · 10ms + d

t

45mse · 15ms

32


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ürdiesen 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 Auftretensvon Ereignissen (Zeitpunkt, Häufigkeit und Abhängigkeitenzwischen Ereignissen). Mit Hilfe des Modellskönnen Worst-Case Situationen ermittelt und ein Echtzeitnachweis durchgeführt werden [Gresser93].

Das Verfahren setzt als Schedulingverfahren ein Deadlinescheduling voraus, welches im AbschnittSchedulingvorgestellt wird.

Das Modell besteht aus den Komponenten:

1. Ereignisstrom

2. Ereignisdichtefunktion und

3. Rechenzeitanforderungsfunktion.

1 2 3 4 5

1 2 3 4 5

6 8 9 10 11 127 13 14 15 16 17 18

6 8 9 10 11 127 13 14 15 16 17 18

2345

1

I=1I=2

Im Intervall der Länge 1treten max. 2 Ereignisseauf.

auftreten max. 4 EreignisseIm Intervall der Länge 8

I

tE(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ößeI von0 bis∞ bestimmt man die im IntervallI maximale auftretende Anzahl Ereignisse. In Abbildung [Ereignisstrom-Modell] beispielsweise würde manbei einer Intervallgröße nahe0 genau ein Ereignis erfassen. Bei einem Intervall der Größe1 könnte manbereits zwei Ereignisse (wenn das Intervall zum Zeitpunktt=7 beginnt) erfassen. Man schiebt also gedank-lich die Intervalle unterschiedlicher Größe über die Ereignisse und erfaßt die im Intervall maximal sichtbareAnzahl. Dieser Wert wird an die entsprechende Stelle der EreignisdichtefunktionE(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 einesZyklus z

iund eines Intervallsa

i:

33


ai

zi( )Ereignis Tupel:

Da jedes Ereignis mehrfach auftreten kann, wird jedes Ereignistupeli noch mit einem Faktorki

multipli-ziert. Für einmalig (also nicht periodisch) auftretende Ereignisse findet der Wert unendlich “∞” als ZyklusAnwendung.

ai

zi( )}{kiES:i

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

(160){ES:

1Ereignisse

432

169(, 16)4 (, , )(16

6) }(16), 1

5

Abbildung 2-23. Ereignisstrom

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

Gleichung 2-6. Ereignisdichtefunktion eines periodischen Ereignisses

E(I) = int ( i − aiz

I + z i

)

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

{ES: ( )0 (, )(,∞0 0

32 )}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


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

626 (, )(, )}6

3 46

Abbildung 2-25. Homogener Ereignisstrom

(03)

10 2 3 4 5

123456

6 7 8 9 10

789

( )02

( )0∞ I

E(I)

Abbildung 2-26. Ereignisdichtefunktion des inhomogenen Ereignisstroms

Für den Realzeitnachweis ist neben dem Ereignisstrom noch die Kenntnis über Rechenzeit tV

und DeadlinetZmax

notwendig.

tV

tZmax

E

Abbildung 2-27. Ereignisstrom-Modell

Im Ereignisstrom-Modell wird ein einfacher Rechenprozessdurch seine DeadlinetZmax

und seine Rechenzeitt

Vbeschrieben (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 Deadlineschedulingbestimmt:

Gleichung 2-7. Rechenzeitanforderungsfunktion

C(I)=Σi=1

n

E (I−t i Zmax,i) t v,i

Die Rechenzeitanforderungsfunktion des Rechenprozesseswird bestimmt, indem für jedes Ereignistupeli die Ereignisdichtefunktion mit der Rechenzeit t

V,imultipliziert und um die zum Ereignistupel gehörige

Deadline tZmax,i

nach rechts verschoben wird (siehe GleichungRechenzeitanforderungsfunktion).

Die Echtzeitbedingung des Rechenprozess ist erfüllt, wennjetzt: C(I) ≤I ist. Graphisch veranschaulichtbedeutet dies, dass die Rechenzeitanforderungsfunktion die Winkelhalbierende nicht überschreiten darf.

35


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 dieRechenzeitanforderungsfunktionen der einzel-nen Rechenprozesse aufzusummieren. Auch hier gilt wieder,dassC(I)

ges≤I ist.

Beispiel 2-4. Echtzeitnachweis bei Deadline-Scheduling

Es soll noch einmal das BeispielEchtzeitnachweis bei prioritätsgesteuertem Schedulingaufgegriffen unddie Frage geklärt werden, ob die fristgerechte Bearbeitungder Aufgabe mit einem Deadlinescheduling-Verfahren möglich ist.

ES={( 300) ( ) (45

0600)}

5 10 20 30 40 50 60 70 80 90 100

10

20

30

40

50

60

C(I)

I

Abbildung 2-28. Echtzeitnachweis mit Hilfe des Ereignisstrom-Modells

Als erstes wird der Ereignisstrom erstellt. Dieser wird zurRechenzeitanforderungsfunktion, wenn man denEreignisstrom mit der Verarbeitungszeit multipliziert und um die Deadline nach rechts verschiebt. Wie ausAbbildung [Echtzeitnachweis mit Hilfe des Ereignisstrom-Modells] ersichtlich, wird die Winkelhalbierendenicht ü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 dieEinhaltung der Zeitanforderungen auch vonabhängigen Ereignissen. Die Kenntnis über Abhängigkeitenzwischen Ereignissen entschärft die zeitlichenAnforderungen, der bisherige Ansatz, zeitlich abhängige Ereignisse wie zeitlich unabhängige Ereignisse zubetrachten, 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 Ereignissein einem einzigen Ereignisstrom zusammenzufassen. Bei demauf diese Art neu gewonnenen Ereignisstromist für die Berechnung der Ereignisdichtefunktion darauf zu achten, dass für die Berechnung die entspre-chenden Werte für t

V,iund t

Zmax,ieingesetzt werden.

36


2Tt =6TP

6T

t =6TP

6T3T

1 2 3 4 5 6 t7 8 9 10 11

( )02 6{ }ES:

1 2 3 4 5 6

1

I

2

432

E(I)

RPRP1

Abbildung 2-29. Prozessbeschreibung und Ereignisdichtefunktion

Betrachten wir zunächst zwei unabhängige Prozesse, die beide eine Prozesszeit vontP=6T besitzen. Re-

chenprozess RP1

besitze eine Verarbeitungszeit vontV,1

=2T und Prozess RP2

besitze eine Verarbeitungszeitvon t

V,2=3T. Falls die maximal zulässige Reaktionszeitt

Zmaxbeider Rechenprozesse identisch mit der Prozes-

szeit tP

ist, ergeben sich die in Abbildung [Prozessbeschreibung und Ereignisdichtefunktion] dargestelltenEreignisdichtefunktionen.

432

5

C(I)6

RP

RP1

1 2 3 4 5 6

1

I

2

Abbildung 2-30. RechenzeitanforderungsfunktionC(I)

Mit Kenntnis der Prozessparameter läßt sich daraus die RechenzeitanforderungsfunktionC(I) erstellen (Ab-bildung [Rechenzeitanforderungsfunktion C(I)]). Beide Rechenprozesse sind - so das Ergebnis - innerhalbder 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 ProzesszeittP=6T die

maximal zulässige Reaktionszeit (Deadline) von RP1auf t

Zmax,1=3T und die maximal zulässige Reaktionszeit

von RP2auf t

Zmax,2=4T festgelegt wird,

37


t =6TP

3T

2Tt =6TP

4T

3T

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

432

I

1

1 2 3 4 5 6

567

C(I)

Abbildung 2-31. RechenzeitanforderungsfunktionC(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 dieBearbeitung zeitgerecht erfolgen.

( )06 },{ES: ( )62

1 2 3 4 5 6 t7 8 9 10 11

Abbildung 2-32. Auflösung der Abhängigkeiten

Um dieses nachzuweisen wird aus den beiden Ereignisfolgen (Ereignisströmen) ein einzelner Ereignisstromgebildet und die Ereignisdichtefunktion erstellt (Abbildung [Auflösung der Abhängigkeiten]).

Die Rechenzeitanforderungsfunktion wird gemäß GleichungRechenzeitanforderungsfunktionberechnet.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-t

Zmax,1) t

V,1+ E

2(I-t

Zmax,2) t

V,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


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

432

I

1

1 2 3 4 5 6

567

C(I)

Abbildung 2-33. RechenzeitanforderungsfunktionC(I)

Fußnoten1. Die Einheit, die den Kontextswitch durchführt, wird Scheduler genannt.

2. Damit entspricht der WertS(t) (S=Supplied Computation Time) zu einem Zeitpunkt tiin etwa dem

Load des Rechensystems. Da allerdings in einem Rechner im Regelfall nicht im vorhinein bekanntist, wieviel Rechenzeit ein rechenbereiter Rechenprozessbenötigt, wird die Anzahl der rechenbereitenRechenprozesse als Load genommen.

39


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 underklä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 AnforderungenAus Systemsicht ist ein Betriebssystem die Bezeichnung füralle 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 einervirtuellen Maschinezur Verfügung, die einfacher zubenutzen 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


• 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 sichein System durchaus noch von Hand steuern, unterhalb dieserMarke (etwa 1 Minute) reicht eine Auto-matisierung auf Basis von Mechanik aus. Zeitanforderungenim Sekunden-Bereich lassen sich durchausmit 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 notwendigenAktionen innerhalb einer ISR durchgeführt werden. Unterhalb dieser Grenze hilft nur noch eine Realisie-rung in Hardware.

42


3.3. Aufbau und Struktur

I/O Subsystem MemoryManagement

ProcessManagement

Hardware

Syscall Interface

Applications

Services Libraries

Device−Driver−Layer

Kernel

Sonstige BS−Komponenten

Abbildung 3-1. Betriebssystem-Architektur

Bild Betriebssystem-Architekturstellt 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. Geradein 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 desBetriebssystems auch gewährleistet werden.

Die Integration von Hardware in das System über die Treiberschicht ermöglicht darüber hinaus auch densystemkonformen und standardisierten Zugriff auf Hardware aus der Applikation heraus. Hierfür sorgt dasI/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 Aufgabedes 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 BlockProcess-Managementdarge-stellt.

Speichermanagement (Adreßumsetzung und Speicherschutz)ist eine weitere wesentliche Aufgabe. Es darfnicht 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 sogenannteSoftwareinterruptskönnen Applikationen Dienste des Betriebssystems in Anspruch neh-men. Man spricht hier von sogenanntenSystemcalls. Die Schnittstelle innerhalb des Betriebssytems, diegemäß 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 desSystems (Zuteilung von Netzwerkadressen u.ä.) und auch zumBetrieb der Netzwerkdienste Dienstprogram-me benötigt. Die Programme selbst greifen in den seltenstenFällen direkt über die Systemcall-Schnittstelleauf die Dienste des Betriebssystems zu. Im Regelfall sind diese in einer Bibliothek gekapselt, die Standard-

43


funktionen (beispielsweise open, close, read und write) zur Verfügung stellt. Innerhalb der Library ist dannder Systemcall selbst auscodiert.

Natürlich sind die Dienstprogramme des Betriebssystems imstrengen Sinne auch Applikationen. Es wer-den hier nur deshalb zwei Begriffe verwendet, um die zum Betriebssystem gehörigen Applikationen - ebendie Daemonen, Services oder einfach Dienstprogramme - von denselbstgeschriebenenApplikationen 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. BetriebssystemkernArbeitet 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 dediziertenSchema unterbrochen.

Kernel Level

User Level

Hardware Level

1

2

3 4

5

nichtunterbrechabar

unterbrechbar

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- undeinen 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. Vonder 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-ManagementDie Fähigkeit der CPU, den normalen Programmablauf zu unterbrechen, wenn ein Interrupt auftritt, wirdgenutzt, um die quasi parallele Bearbeitung mehrere Programme (Tasks) zu ermöglichen.

44


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

Tabelle 3-1. Interrupt Vektor Tabelle des 80386

Function InterruptNumber

Instruction Which Can CauseException

Return AddressPoints to FaultingInstruction

Type

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 onOverflow

4 INTO NO TRAP

Array BoundsCheck

5 BOUND YES FAULT

Invalid OP-Code 6 Any Illegal Instruction YES FAULT

Device NotAvailable

7 ESC, WAIT YES FAULT

Double Fault 8 Any Instruction That CanGenerate an Exception

ABORT

CoprocessorSegment Overrun

9 Coprocessor Tries to AccessData Past the End of a Segment

NO TRAP

Invalid TSS 10 JMP, CALL, IRET, INT YES FAULT

Segment NotPresent

11 Segment Register Instructions YES FAULT

Stack Fault 12 Stack References YES FAULT

General ProtectionFault

13 Any Memory Reference YES FAULT

Page Fault 14 Any Memory Access or CodeFetch

YES FAULT

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 dasProzessor-Flag-Register und lädt den zuvor auf den Stack befindlichen Wert des Programmcounters in denProgrammcounter, wodurch die Abarbeitung der ursprünglichen Aufgabe fortgesetzt wird.

45


0x10000x10020x10040x10060x10080x100a

0xa0000xa0020xa004

1

2

3

4

5

6

7

return interrupt

restore registers

save registers

interrupttreatment

Normal

0x1006

registers

...

Stack

PC

PC = Program Counter

Code Memory

Address

Program−Execution

ISR

Abbildung 3-3. Interruptverarbeitung

Bild Interruptverarbeitungverdeutlicht 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 dasFlagregister). Aufgrund der Interruptursache wird von derCPU der Befehlszähler (PC) auf die Start-adresse der Interrupt-Bearbeitungsroutine (hier0xa000 ) gesetzt, und die CPU arbeitet die Befehle abdieser 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 Befehlbewirkt, dass vom Stack die dort eventu-ell abgelegten Flagregister zurückgespeichert werden undder PC wieder mit der Rücksprungadresse(0x1006 ) geladen wird.

7. Der normale Programmablauf wird damit fortgesetzt.

46


Kontextwechselzum

Interrupt

Retten des Kontextes des

eventuelle Auftragsbearbeitung

Scheduler:Auswahl des nächsten

Rechenprozesses i

des Rechenprozesses i

Lade Kontext

Return zu PCi

unterbrochenen Rechenprozesses j

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

In einem Multitasking Betriebssystem wird dieser Mechanismus der Programmunterbrechunggenutzt, um die quasi parallele Abarbeitung mehrerer Aufgaben zu ermöglichen. Dazu wirdbei jedem Interrupt zunächst eine vom Betriebssystem zur Verfügung gestellte ISR (BildInterrupt-Service-Routine in einem Realzeitbetriebssystem) aufgerufen. In dieser ISR werden dieProzessorregister und die auf dem Stack abgelegten Werte (PC und Flags) in eine zum gerade aktivenProgramm gehörigen Datenstruktur (Process Control Block,Bild Process-Kontrollblock (TCB)) abgelegt.Danach kann die eigentliche Ursache des Interrupts bearbeitet werden. Am Ende der Interruptbearbeitungwird - 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 zumZeitpunkt der letzten Unterbrechung der Task geladen, Flags und insbesondere der Programmcounterwerden 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 derBefehlszähler mit dem “neuen” Wert geladen, und die Bearbeitung der “neuen” Task wird fortgesetzt.

47


0x10000x10020x10040x10060x10080x100a

0xa0000xa0020xa004

1

2

3

4

complete

TaskInformation

complete

TaskInformation

5

6

7

interrupttreatment

Normal

0x1006

...

Stack

PC

Address

Program−Execution

ISR save registers

current

Tasklist

schedule

0xf000

0xf020

0xf040

0xf020

RETI

contextswitch

return interrupt

Code Memory

TaskInformation

complete0x2000

0x2000

Task 30x2000

Abbildung 3-5. ISR mit Scheduler

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

1. die Register nicht auf den Stack gerettet werden, sondernin die Speicherzellen des Process ControlBlocks (PCB) der gerade aktiven Task. Die Adresse des PCB desgerade aktiven Rechenprozesses istim 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 Stackmanipuliert wird, d.h. der durch den Prozessor dort bei derUnterbrechung abgelegte Wert wird mit dem Wert für den PC überschrieben, der sich in dem PCB derneuen aktiven Task befindet.

48


Virtuelle Maschine

Prozeß−Zustand

Quantum

(Register, Stack usw.)

Exitcode

Maschinen−Zustand

Prozeß−Kontrollblock/

Prozeß Priorität

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:SoftwareinterruptsvonHardwareinterrupts.

• Ü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 danachdie 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-strukturProzess-Control-Blockspeichert 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 bekommtoder nicht.

49


− Zeit

lauffähig

aktiv

WartebedingungEnde der

schlafend"höchstePriorität"

"nicht mehrhöchstePriorität"

TaskStopp

TaskStart

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

ruhend

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, wieim Bild Task-Zustände [Färber94]ersicht-lich.

Ruhend

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

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 imSystem können sich im Zustand lauffähigbefinden.

Aktiv

Immer nur ein Rechenprozess im System kann sich im Zustand aktiv befinden. Der aktive Prozessbekommt die CPU zugeteilt und wird ausgeführt, bis er entweder• sich selbst beendet (in den Zustandruhend) 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 dieWartebedingung eines höherprioren

Prozesses erfüllt wurde.

Wartend

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

50


Code Segment Data Segment Stack Segment

Task

TCB

TCB

Stack Segment

Thread

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 leichtgewichtigeProzesse. Sowohl Tasks als auchThreads bestehen prinzipiell aus einem Speichersegment für Code, Daten und für den Stack (BildSpeicherbereiche einer Task). Der Unterschied zur Task ist, dass zu einer Task gehörige Threads alle einund denselben Adreßraum teilen. Das bedeutet also, dass Threads auf dasselbe Daten und Codesegmentzugreifen, 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 beider 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 zurVerfügung. Diese Systemcalls legen einen neuen PCB an und kopieren - falls notwendig - die zugehörigenSpeicherbereiche (bei Tasks wird das Datensegment kopiertund nur ein neues Stacksegment angelegt, beiThreads wird nur ein neues Stacksegment angelegt).

Ein Beispiel für die Erzeugung einer Task und eines Threads ist in Bild Programm zum Erzeugen einer Taskund in BildProgramm zum Erzeugen eines Threadszu finden.

#include <stdio.h>

51


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, Hel lo )!= 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 newthread terminates either explicitly, by calling pthread_exit(3), or implicitly, by returning from the

52


start_routine function. The latter case is equivalent to calling pthread_exit(3) with the result returnedby start_routine as exit code. The attr argument specifies thread attributes to be applied to the newthread. See pthread_attr_init(3) for a complete list of thread attributes. The attr argument can also beNULL, in which case default attributes are used: the createdthread is joinable (not detached) and hasdefault (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 forthe calling thread with pthread_cleanup_push(3) are executed in reverse order (the most recently pu-shed handler is exe cuted first). Finalization functions forthread-specific data are then called for all keysthat 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 usingpthread_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 storedin 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 ifth was cancelled.

The joined thread th must be in the joinable state: it must nothave been detached usingpthread_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 foreach 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 thon 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. Thisguarantees that the memory resourcesconsumed by th will be freed immediately when th terminates.However, this prevents other threadsfrom synchronizing on the ter mination of th using pthread_join.

A thread can be created initially in the detached state, using the detachstate attribute topthread_create(3). In contrast, pthread_detach applies to threads created in the joinable state, andwhich need to be put in the detached state later.

After pthread_detach completes, subsequent attempts to perform pthread_join on th will fail. If anotherthread is already joining the thread th at the time pthread_detach is called, pthread_detach does nothingand leaves th in the joinable state.

53


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

• der Speicherschutz und• die Adreßumsetzung.

Speicherschutz

• Applikationen (Prozesse, aber nicht Threads) werden voreinander geschützt, indem jeder Prozessseinen eigenen Adreßraum bekommt. Zugriff ist damit nur möglich auf eigene Daten-, Stack- undCodesegmente.

• Daten bzw. Teile der Applikation werden vor Fehlzugriffen geschützt. Greift eine Applikation aufSpeicherbereiche zu, die nicht zur Applikation gehören, oder versucht die Applikation aus einemCodesegment 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 zubeschleunigen und Shared-Libraries zu ermöglichen. War infrü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 dieAdressen vergeben. Aus Sicht jeder Applikation beginnt dereigene Adreßraum ab der Adresse 0.

• Mehrere Tasks können sich ein (Code-) Segment teilen. Durchdie Trennung von Code- undDatensegmenten und mit Hilfe der MMU können mehrere Tasks, die auf dem gleichen Programmberuhen, 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 Hauptspeicherin Seiten (oder sogenannte Kacheln) eingeteilt, und - wenn keine freien Kacheln mehr zur Verfü-gung stehen - auf den Hintergrundspeicher (Festplatte) ausgelagert (Paging und Swapping). DieserMechanismus hat jedoch für Realzeitsysteme keine besondere Bedeutung, da er zu Undeterminis-men führt.

54


MMU(Prozessorkern)

CPU

Logische

Adresse

AB

CB CB

AB

PhysikalischeAdresse

Speicher

Physik.

MMU = Memory Management UnitAB=AdreßbusCB=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 derProzessorkern 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 MMUmuß also durch das Betriebssystem initialisiert werden.

Prinzipiell kann eine MMU den physikalischen Speicher auf zwei Arten aufteilen: in Segmente und inSeiten. 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 (manmerke, nicht des physikalischen!) Adreßraums (der physikalische Speicher war/ist größer als der logischeAdreß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 dieSegmentierung 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 desAdreßraumes zu erhalten, ist es natürlich notwendig, dass die Basisadresse breiter ist als die vom Prozessorerzeugte 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önnenSegmente immer nur auf Adressen beginnen, die durch 16 teilbar sind. Da von den 20bit der Basisadressenur 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 einemMaschinenbefehl auf Speicherzellen zugreifen, solange sie innerhalb des logischen Adreßraums (beim 8086

55


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

0000000000000000

15 . . . . . . 0

Code SegmentStack SegmentData SegmentExtra Data Segment

AdresseBasis 20bit

+16bit 20bit

PhysikalischeAdresse

LogischeAdresse

4 Basis−Adreß−Register

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

0200 : 0004

02000004

0x02004

:

0x02004

:

0x02004

0100 1004

01001004

0000 2004

20040000

Segment Offset

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

Segment SegmentOffset Offset

Phys.Adresse

Normalisieren:

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 erstnormalisiertwerden. 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 normalenDatenlesebefehlen 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 semantischenEinheiten, einem Teil, der innerhalb der MMU den sogenannten Seitendeskriptor (Kachelbeschreibung)auswählt, und einem Teil, der eine Speicherzelle innerhalbder Kachel auswählt.

56


235678911121523272831

SeitenoffsetSeitendeskriptoradresse

4 01

Abbildung 3-14. Strukturierung der logischen Adresse

Schreib−Zugriff erlaubtDaten−Zugriff erlaubtCode−Zugriff erlaubtValid (Kachel im Speicher vorhanden)

Kachel−NummerZugriffsrechte

1115 12 0

Abbildung 3-15. Aufbau eines Seitendeskriptors

Der Seitendeskriptor besteht ebenfalls aus zwei semantischen Teilen. Der erste Teil enthält Flags, die dieZugriffsrechte kontrollieren, der zweite Teil enthält dieeigentliche physikalische Seitenadresse.

Im Regelfall existieren vier Flags:

Schreibflag

Ist dieses Flag gesetzt, darf auf die Seite schreibend zugegriffen werden. Versucht der Prozessor aufdie 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 Prozessoraus 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. Istdas Flag gültig gesetzt, darf der Prozessordie Daten in seinen Programmspeicher laden. Ist das Flag ungültig gesetzt und der Prozessor versuchtaus 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


� � ��

� ��

� � � � ��

Kachel (Seite)derAdressierungAuswahl/

� � ��

� ��

� � ��

� ��

Seiten−DeskriptorsdesAdressierungAuswahl/

KacheladresseZugriffsrechte

Adresse/Offset innerhalb der Kachel (Seite)

Adressumsetzspeicher

0

1112

31

0

1112

23

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

Abbildung 3-16. MMU auf Basis von Seitenadressierung

Die MMU ist entweder im Prozessor integriert und über eigeneBefehle ansprechbar, oder sie befindet sichals eigener Baustein im Adreßraum des Prozessors. In diesemFall ist sichergestellt, dass beim Startup desSystems die MMU einen definierten Zustand hat, so dass auch ohne Vorbelegung das Betriebssystem dieMöglichkeit hat, die MMU zu initialisieren.

Wie aus der Zeichnung ersichtlich, wird der Zugriff auf den Hauptspeicher durch die MMU verzögert, da dieMMU selbst auch eine Zugriffszeit besitzt. Moderne Mikroprozessoren verwenden als MMU-Speicher denHauptspeicher, so dass im ungünstigen Fall mehrere Hauptspeicherzugriffe notwendig sind, um schließlichdas gewünschte Datum zu bekommen.

Eine MMU, die auf Basis der Aufteilung des Speichers in Seiten funktioniert, kann leicht mit Hilfe vonSpeicherbausteinen aufgebaut werden. Der Speicher beinhaltet die Seitendeskriptoren. Mit den oberen Bitsder 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 zurVerifikation der Zugriffsrechte, verwendet. Konkret wird also ein Teil des Datenbusses auf den Adreßbusgemappt. Der Datenbus selbst muß gemultiplext sein, d.h. damit der MMU-Speicher auch belegt werdenkann, muß der Datenbus auch mit dem Datenbus des Prozessorkerns verbunden werden.

Ein Teil der Datenbits eines Seitendeskriptors wird mit denZugriffs-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 SubsystemDas I/O Subsystem hat vielfältige Aufgaben. Aus Applikationssicht schafft es eine Schnittstelle für deneinheitlichen 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 istdas I/O Subsystem aber auch noch für die Organisationsstrukturen auf Hintergrundspeicher, den sogenann-ten Filesystemen, zuständig.

58


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ätenzu transferieren und Daten von den Geräten zu lesen. Die Applikationsschnittstelle zum I/O-Subsystem istso 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 Lesenund Schreiben (read und write) abgebildet. Bevor jedoch aufein Gerät geschrieben bzw. von einem Gerätgelesen werden kann, muß dazu die Ressource beim Betriebssystem angefordert werden. Bei der Anforde-rung entscheidet das System, ob die Task den Zugriff bekommtoder ob der Zugriff abgelehnt wird. Gründefü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 klassischenZugriffsfunktionen (ANSI-C) für den Zugriff auf Geräte sind die gleichen wie für denZugriff 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ätselbst 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 odernicht blockierend).open liefert als Ergebnis einen sogenanntenDescriptorzurü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 (BildGeräteschnittstelle).

close

Dieser Systemcall gibt die angeforderte Ressource wieder frei.

read

Zum lesenden Zugriff wird der Systemcallread verwendet.

59


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-/Leseaufrufeabbilden, steht der IO-Control-Aufruf zur Verfügung. Dieser Aufruf ist gerätespezifisch. Über IO-Controls werden beispielsweise die verschiedenen Betriebsparameter und Betriebsarten einer seriellenSchnittstelle konfiguriert oder auch ein atomares Lesen undSchreiben ermöglicht.

3.4.3.1.2. Zugriffsarten

Da man bei Echtzeitbetriebssystemen darauf achten muß, dass das Warten auf Ereignisse das System selbstnicht blockiert, lassen sich Aufrufe, die zum Warten führenkö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 antwortetinnerhalb einer definierten Zeitspanne nicht) ein-getreten ist. Man spricht von einemWarteaufruf mit implizitem Wartenoder auch von einem synchronenZugriff.

Demgegenüber spricht man von einemWarteaufruf mit explizitem Warten, wenn der Warteaufruf (Zugriffauf das Gerät) direkt zurückkehrt. Die Task, die den Aufruf durchgeführt hat, kann - unabhängig von derBearbeitung 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 übergebeneCallback-Funktion auf. Bei Warteaufrufen mitexplizitem Warten spricht man auch von einem asynchronen Zugriff.

Ein Beispiel für eine derartige Funktion mit explizitem Warten ist unter Win32 die FunktionReadFile mitsogenannteroverlap -structure (BildExpliziter Warteaufruf mit Win32 Interface).

Aus Sicht des Betriebssystems sind Warteaufrufe mit explizitem Warten nicht trivial zu realisieren. Das liegtan 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 (daherauch die overlap-structure, die die notwendigen Informationen bezüglich des Aufrufes enthält und derenInhalt 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 dereigentliche 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


...

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/OWaitForSingleObject(hFile, INFINITE);

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

return(result_buffer);}

...

Abbildung 3-18. Expliziter Warteaufruf mit Win32 Interfac e

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

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

void *AsyncThread( void *fp ){

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

}


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/Opthread_join( AsyncThread, NULL );

}

61


Abbildung 3-19. Asynchroner Zugriff über Threads

Neben diesen beiden prinzipiellen Zugriffsmöglichkeitengibt es die Variation desnicht blockierendenZu-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 derFunktionsaufruf (Systemcall) direkt mit einerentsprechenden Benachrichtigung zurück. Blockierenden oder nicht blockierenden Zugriff kann man beiUnix-Betriebssystemvarianten entweder beimÖffnen/Initialisieren (Geräte werden über die Funktionopen

geöffnet bzw. initialisiert) einstellen, oder nachträglich über die Funktionfcntl .

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 derApplikationsschnittstelle mit dem sogenanntenselect Aufruf respektive poll Funktion (BildGleichzeitige Überwachung mehrerer Ein-/Ausgabequellen). Ein weiteres wichtiges Merkmal ist, dassdiese Funktionen (Systemcalls) gleich mehrere Ein- bzw. Ausgabequellen (z.B. Geräte, Netzverbindungenu.ä.) darauf überprüfen, ob von diesen ohne zu warten Daten gelesen werden können oder ob auf dieseohne 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. */

elseprintf("No data within five seconds.\n");

exit(0);}

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

Select und auchpoll 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


definierende Zeit gewartet werden. Sind innerhalb dieser angegebenen Zeitspanne keine Daten auf denspezfizierten Ein-/Ausgabequellen angekommen oder lassensich keine Daten darauf schreiben, bricht dieFunktion mit einer entsprechenden Nachricht ab.

Die Funktionenselect undpoll werden auch genutzt, um eine Task/Thread (ähnlich der Funktion sleep )im Millisekundenbereich warten (schlafen) zu lassen. Der Unterschied zwischenselect und poll bestehtdarin, dass man mittelsselect nur den Zustand von Ein-/Ausgabequellen überprüfen kann, bei poll jedochnoch 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 denBetriebssystemkern eingebunden werden. Dazuexistiert 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 Applikationeine der Zugriffsfunktionenopen , close , read , write oder ioctl , wird im Gerätetreiber eine entsprechen-de Funktion aufgerufen, die das Peripheriemodul so ansteuert, dass dieses die spezifizierte Funktionalitäterbringt.

Ein Gerätetreiber ist also:

• ein Satz von Funktionen, die den Zugriff auf eine spezifischeHardware (Gerät) steuern.

• die gerätespezifische Implementierung der allgemeinen Schnittstellenfunktionen.

Die Aufgabe des Betriebssystems (I/O Subsystem) im Kontextder 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 seinenFunktionen und der Majornumber.

• Über die Zuordnung symbolischer Name und Majornumber oder Filedeskriptor wird das Mappingzwischen 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, sonderndirekt aus der Applikation heraus ansteuern. Jedoch ist einTreiber 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 beispielsweisekeinerlei 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ändenkann außerdem zu erhöhten Latenz-Zeiten (siehe AbschnittTask-Latency) führen.

63


• Um systemkritische Teile zu kapseln. Zugriffe auf Hardwaresind sicherheitskritische Aktionen, die nurinnerhalb eines Treibers durchgeführt werden dürfen. Wirdaber beispielsweise die Hardware aus der Ap-plikation heraus angesteuert (indem die Register bzw. Speicherbereiche der Hardware in den Adreßraumder Applikation gemapped werden), muß die Applikation erweiterte Zugriffsrechte bekommen. Damitwiederum gefährdet sie die Sicherheit des gesamten Systems. Programmierfehler können nicht nur zumAbsturz 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, beiApplikationsfehlern das Gerät in den sicheren Zustand zu überführen. Stürzt die Applikation durch einenFehler 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. Insbesonderedieser dritte Grund ist für sicherheitskritischeEchtzeitsysteme 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 undpoll ) anzusprechen.

Diese Aufrufe werden innerhalb des Betriebssystems an den Gerätetreiber weitergereicht. Verwendet alsoeine Applikation denopen -Aufruf, um eine Ressource (in diesem Falle also ein Gerät) zu reservieren, stelltdas Betriebssystem fest, um welches Gerät es sich handelt und ruft dann die zugehörigeopen -Funktioninnerhalb des Treibers auf (BildTreiberauswahl). Jeder Treiber muß also eine treiberspezifischeopen -Funktion zur Verfügung stellen. Es gibt damit im Betriebssystem so vieleopen -Funktionen wie es Treibergibt, während an der Applikationsschnittstelle genau eineopen -Funktion existiert.

Damit die richtige Treiberfunktion ausgewählt werden kann, benötigt das Betriebssystem natürlich einenAnhaltspunkt. Dieser Anhaltspunkt ist beim Systemcall (also an der Applikationsschnittstelle)open einsymbolischer Name, über den die Zuordnung durchgeführt wird, bei den anderen Funktionen ein Deskriptor,den das Betriebssystem der Applikation als Ergebnis desopen -Systemcalls zurückgibt.

AnalogInputCD−ROMFestplatteSchnittstelle

serielleSchnittstelle

parallele

Open−Systemcall

Open−Funktion desGerätetreibers wird aufgrundder Systemcallparameter ausgewählt

Open−Funktionender Gerätetreiber

Applikation

Kernel

Hardware

Abbildung 3-22. Treiberauswahl

64


Die Zuordnung eines symbolischen Gerätenamens zum zugehörigen Gerätetreiber wird in Unix beispiels-weise über die sogenanntenMajornumberdurchgeführt. Im Dateisystem wird eine Datei erzeugt, die einensymbolischen Namen wie zum Beispielmydevice besitzt. Diese Datei bekommt als Attribute eine Major-number, zum Beispiel122 zugeteilt (der Aufruf dazu lautetmknod mydevice c 122 0 ). Diese Majornumberist im Regelfall eindeutig festgelegt und im Treiber eincodiert. Wird der Treiber schließlich vom Betriebs-system geladen (unter Linux dynamisch mit deminsmod Kommando), meldet sich dieser beim Betriebs-systemkern mit der eincompilierten Majornumber an. Bei diesem Vorgang wird außerdem eine Liste derTreiberfunktionen mit übergeben, die aufgerufen werden sollen, wenn die Applikation die entsprechendenZugriffsfunktionen (open , close , read , write , ioctl , select oderpoll ) aufruft. Damit sind im System allenotwendigen Informationen vorhanden, um bei Zugriffen durch die Applikation die entsprechenden Trei-berfunktionen zu starten.

Bild Einbindung des Gerätetreibers in das Systemzeigt dieses noch einmal anhand einesLinux-Gerätetreibers. Wird der Treiber perinsmod geladen, so wird beim Laden die Funktioninit_module

aufgerufen. Diese Funktionregistriert den Treiber, wobei die Majornumber und die Tabelle mitden Treiberfunktionen dem Kernel übergeben werden (register_chrdev(MY_MAJOR_NUMBER, ...,

&mydevice_table); , wobeiMY_MAJOR_NUMBERzum Beispiel 122 sein kann).

Ist der Treiber geladen, kann die Applikation diesen nutzen. Dazu muß im Filesystem eine Spezialdateiexistieren, die die Zuordnung des symbolischen Gerätenamens zur MajornumberMY_MAJOR_NUMBER(alsoz.B. 122) durchführt. Führt die Applikation dann den Systemcall open mit dem Gerätetreibernamen alsParameter durch, ruft der Kernel die gerätetreiberspezifische Funktionmydevice_open auf. Das gleiche giltfür die übrigen Schnittstellenfunktionen wieread oderwrite .

65


{ ...}

{ ....}

{

...};

int init_module(){

void cleanup_module(){ unregister_chrdev(...); ...}

} ...

KERNEL USER

Applikation:

main(){

char buf[512];

close( fd );}

int fd=open("/dev/Carrera", O_RDWR);

write( fd, "0x50", 5 );

insmod carrera.o

/dev/Carrera

struct file_operations carrera_table { &carrera_open; &carrera_close; &carrera_write; &carrera_read; &carrera_ioctl;

&carrera_table);

int carrera_open(...)

int carrera_close(...)

int carrera_write(...)

speed = atoi( buf );

...} ...

rmmod carrera

Kernelmodul: carrera.c

... // copy data from I/O to user space ...

register_chrdev(240, ...,

parport_epp_write_data( port,speed);

mknod /dev/carrera 240 0

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

Bei der Treibererstellung sind damit im wesentlichen dieseinternen 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. serielleSchnittstelle 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


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 istund 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 Funktionclose hat die Aufgaben:

• Freigabe der (durchopen ) 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 zuschließen (z.B. weil die Applikation abgestürzt ist), ruftdas Betriebssystem anstelle der Applikationdie close -Funktion auf und gewährleistet damit einen sicheren Betrieb.

read (treiberspezifisch)

Aufgabe vonread ist:

• Realisierung der Zugriffsarten (blockierend, nicht blockierend, siehe AbschnittZugriffsarten)

• Anpassung des Taskzustandes (Versetzen der Task imblocking -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 derread -Funktion:

• Realisierung der Zugriffsarten (blockierend, nicht blockierend, siehe AbschnittZugriffsarten)

• Anpassung des Taskzustandes (Versetzen der Task imblocking -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 sichnicht sinnvoll auf das read/write Interfaceabbilden 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. Dieioctl -Funktion be-kommt als Parameter ein Kommando und einen Zeiger auf eine Datenstruktur mit. Entsprechend demKommando 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


select

Die treiberspezifischeselect -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 Funktionpoll wird im Treiber wie die Funktionselect behandelt. Auch hier wird die eigentlicheFunktionalitä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 Funktionenoutb( char

value, char base ) für die Ausgabe eines Bytes undinb( char base ) für das Einlesen eines Bytes). DieSchnittstelle 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 folgendeZeilen Code verwenden können:

...printf( “Pegel der Eingangsleitungen: 0x%x\n”, inb(0x379 ) );...

Da verhindert werden soll, dass zwei oder mehr Programme aufdie 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 Majornumber121 .

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 Funktioneninit_module undcleanup_module , die beim Laden bzw. Entladen des Treibersaufgerufen werden. Die Funktionen haben die Aufgabe, den Treiber beim Betriebssystem anzumeldenund notwendige Ressourcen anzufordern.

68


// bei Erfolgreicher Initialisierung wird 0 zurückgegeben , sonst// -EIO.int init_module(){

// anmelden des Treibersresult=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 Ressourcenrelease_region( 0x378, 4 );// Abmelden des Treibersunregister_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 nurread :

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


// 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 integriertwerden (z.B. unter Linux einfach mit dem Superuserkommandoinsmod geladen werden). Damit auf denTreiber 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 Sekundenabsta nd// (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 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 koenn en!// Erwartetes Ergebnis: fd1 < 0fd1 = open( “/dev/ParIF”, O_RDONLY );if( fd1 > 0 ) {

70


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 nochFunktionen im Treiber, die durch den Betriebssystemkern selbst getriggert (aufgerufen) werden. Das sindinsbesondere

• Interrupt Service Routinen (ISRs)

• Funktionen in einer Kernel-Queue und

• Funktionen in einer Timer-Queue.

71


3.4.3.2.2. Interruptbetrieb

3

1

2

4

5

6

78

11

10

9

Application

Library

I/OSubsystem

ISR

Hardware

fread

read

I/Oread

Geraet_read

startet

Treiber auf

SW−IR aus

ruft auf

IST ISR

wennDaten vorhanden

system

ISR

weckt

IR gesperrt

US

ER

KE

RN

EL

returniert

returniert

löst

ruft

HW−Zugriff

Device Driver

höchste PrioritätScheduler:

legt Appl.schlafen

Abbildung 3-24. Datenfluß im System beim Aufruf vonfread

Der Betriebssystemkern bietet bereits eine komfortable Umgebung an, um Hardware interruptgesteuert zubetreiben. Dazu muß der Treiber eine Interruptroutine zur Verfügung stellen und beim Laden des Trei-bers beim Kern anmelden (registrieren). Versetzt beispielsweise die Treiberfunktionread eine Task in denZustandwartend , so kann diese Task (bzw. der Treiberaufrufread , denn die Task „wartet in der Treiber-funktion“) durch die ISR wieder in den Zustandlauffä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 zuachten, 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 hiereine Funktion verstanden, die direkt nach Abarbeitung des bzw. der Interrupts aufgerufen wird, noch bevorsonst eine Funktion des Treibers abgearbeitet wird. Sind die Interrupts während einer Interrupt-Service-Routine gesperrt, sind diese zum Zeitpunkt der Bearbeitungder IST’s freigegeben. Damit besteht der Codeder ISR nur noch darin, eine Funktion (IST, unter Linux alsBottom Halvebezeichnet) in die Liste (Queue)der Funktionen einzutragen, die direkt nach Beendigung aller anliegenden Interrupts aufgerufen werden.

72


Bild Datenfluß im System beim Aufruf von freadzeigt den gesamten Datenfluß eines Leseauftrags. Die Ap-plikation möchte über die Funktionfread Daten von einem Gerät lesen (1). Bei der Funktionfread handeltes 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, denSystemcallread 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 Parameterder Funktionread ) die zugehörige TreiberfunktionGeraet_read aufgerufen (3). Diese Funktion startet deneigentlichen 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ächstvom Kernel selbst bedient. Diesystem ISR startet jedoch die Geräte-ISRISR (6). Während die ISR (sowohldie des Kernels als auch die des Gerätetreibers) aktiv sind,sind alle Interrupts gesperrt. Die Geräte-ISRmacht im Beispiel nichts anderes, als einen vom Treiber zur Verfügung gestellten Interrupt-Service-ThreadIST zu starten (7). Dieser IST wiederum weckt die Applikation (versetzt die Applikation wieder in denZustand “lauffähig”) (8). Die GerätetreiberfunktionGeraet_read liest die Daten vom Gerät (Hardware) undkopiert sie in den von der Applikation übergebenen Speicherbereich (im User-Space). Danach übergibt siedie Kontrolle wieder an die FunktionI/O read (9). Der Systemcall ist damit abgearbeitet, und sollte dieApplikation höchste Priorität haben, wird der Scheduler die CPU wieder an diese Task übergeben. Die überden Systemcallread gelesenen Daten werden noch in der Library-Funktionfread verarbeitet und schließlichder Applikation selbst übergeben.

3.4.3.2.3. Kernel-Queues

Als Kernel-Queue-Funktionenbezeichnet man Routinen, diein 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 registrierenlassen (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 (Funktionopen ) - eine entsprechende Funktion in die vom System zurVerfü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 dieAdresse einer Funktion und den Zeitpunkt eintragen kann, zudem die Funktion durch den Kernel aufgerufenwerden 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


#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 hereMOD_INC_USE_COUNT;return 0;

}

static int mydevice_release(struct inode *inode, struct f ile *file){

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

// your code comes hereMOD_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 spacereturn( 0 );

}

static ssize_t mydevice_write(struct inode *Inode, struc t file *file,const char *buf, int count)

{// copy data from user space and write it into the hardwarereturn( 0 );

}

static int mydevice_ioctl(struct inode *inode, struct fil e *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 herereturn 0;

case MYDEVICE_INPUT:// your code comes herereturn 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


&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_MAJ OR);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

� ��

� ��

Hardware

PreemptionLatency(IR disabled)

ISR ISR2

(IR Latency)

System Call Delay

Scheduler

Context Switch

Task Latency, twIR ausgelöst

Ereignis tritt ein

Latency

Abbildung 3-26. Verzögerungszeiten

75


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

1. Hardware-Latency: Zeit, die die Hardware benötigt, um das Ereignis in Form eines Interrupts demProzessor zu melden (einige wenige Gatterlaufzeiten).

2. Preemption-Delay: Verzögerungszeit, die entsteht, wenn sich das Betriebssystem in einem kritischenAbschnitt 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 mehrfachauftreten, wenn beispielsweise mehr als zweiunterschiedliche 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 Abarbeitungvon Interrupt Service Threads anfallen, werden hier als denInterrupts zugehörig betrachtet.

Nach den Interrupts bearbeitet der Prozessor zunächst einen aktiven Systemcall zuende. Danach folgt derScheduler und schließlich der Kontextswitch. Diese Zeitenfallen 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 100bis 300µs auf.

Bei der Wahl eines Echtzeitbetriebssystems werden häufig die Interrupt-Latenzzeiten verglichen. DieInterrupt-Latenzzeit wird aber im wesentlichen durch die ISR’s der Treiber bestimmt. Der Hersteller einesBetriebssystem kennt aber nur die Treiber, die integrativer Bestandteil sind. Beim Vergleich ist daher aufdie eigentliche Systemkonfiguration zu achten. Sperrt ein einzelner

Untersuchungen haben gezeigt, dass Latenzzeiten nicht unbedingt konstant sein müssen. Vielmehr gibt esauch den Fall, dass die Zeiten von der sogenannten Uptime desSystems abhängen (z.B. dadurch, dass internListen 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


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.

HintergrundspeicherBuffercache

read( fd, buf, 128 )...

...

Applikation

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 derFall, wird die Information in den Cache geladen und dann weiter an die Applikation gereicht. Wird einSchreibauftrag erteilt, gehen die Daten zunächst an den Buffercache. Erst einige Zeit später werden dieDaten 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 Hintergrundspeicheraber nicht mit dem Cache rechtzeitig abgeglichen worden ist.

77


• Zugriffe auf das Filesystem sind nicht deterministisch, danicht 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 dersync -Modeverwendet. Beimsync -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 Betriebssystemsnutzen. Diese Schnittstelle ist absolut unabhängig von jeglicher Programmiersprache. In den seltenstenFällen greift eine Applikation direkt auf das Systemcall-Interface zu, sondern nutzt zu diesem ZweckeBibliotheksfunktionen. So lautet beispielsweise der Systemcall für die Ausgabe von Daten in eine Dateioder in ein Gerätwrite , wobei sich hinter dem Namen eine Nummer (bei Linux beispielsweise der Code4)verbirgt.

Systemcalls erwarten ihre Argumente entweder in Registernoder auf dem Stack. Ein Systemcall wird dannüber den AssemblerbefehlINT bzw.TRAPmit einer Exceptionnummer (bei Linux beispielsweise 0x80)auf-gerufen (Softwareinterrupt). Dieser Befehl führt zu einerException, wobei die Exceptionnummer innerhalbdes Betriebssystems die Dienstaufrufsschnittstelle aktiviert. Hier wird anhand der Registerinhalte (System-callcode) in die entsprechenden Funktionen verzweigt.

Bild Codebeispiel Systemcallmacht dieses deutlich. Der Code für den Systemcall (hier4) wird in das Regi-stereax geschrieben. Die Registerebx , ecx undedx werden mit den Parametern des Funktionsaufrufes belegt(in diesem Fall der Dateideskriptor 1 fürstdout , die Adresse der auszugebenden Daten"Hello World"

und die Länge 12 des auszugebenden Strings). Danach wird derSoftwareinterrupt für die Systemcall-Schnittstelle (0x80 ) aufgerufen.

.text

.globl write_hello_worldwrite_hello_world:

movl $4,%eax ; //code fuer "write" systemcallmovl $1,%ebx ; //file descriptor fd (1=stdout)movl $message,%ecx ; //Adresse des Textes (buffer)movl $12,%edx ; //Laenge des auszugebenden Textesint $0x80 ; //SW-Interrupt, Auftrag an das BSret

.datamessage:

.ascii "Hallo World\n"

Abbildung 3-28. Codebeispiel Systemcall

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


write_hello_world();}

Abbildung 3-29. Codebeispiel Library-Call

78


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

3.4.5. ServicesEin 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 Realzeitbetriebsystemsab. 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 aufproprietäre Weise protokollieren und sichern, sollten dievom Betriebssystem zu diesem Zweck ein-gerichteten Dienste in Anspruch genommen werden. Protokolliert wird dann nicht nur auf einheitlicheWeise 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 Netzkommen, zu beantworten. Typische Dienste hier sind der HTTP-Server (WWW) oder der FTP-Server.Hierzu zählen aber auch Dienste zur Zeitsynchronisation ineinem 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 entsprechendenZeitraum “schlafen” legten, würden im System mehr Ressourcen benötigt, da die Tasks Speicher imSystem (und in den Systemtabellen des Betriebssystemkerns) belegten.

79


3.4.6. Bibliotheken

printf

Prgm. 2

printfprintf

Hauptspeicher

printfprintf

RP 1 RP 2

printf

Prgm. 1

RP 2RP 1

printf printf

Prgm.

RP

statisch

Platte

Prgm. 2Prgm. 1

shared dynamic loaded

dynamic

Abbildung 3-30. Verschiedene Bibliotheksarten

Wie bereits in AbschnittSystemcall-Interfacebeschrieben, 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 sowohlzu den eigenen Applikationen als auchzu den Dienstprogrammen hinzugebunden. Man unterscheidetstatische von dynamischen Bibliotheken.Während statische Libraries zu dem eigentlichen Programm beim Linken hinzugebunden werden, werdendynamische Bibliotheken (auch shared libs genannt) erst dann an das Programm gebunden, wenn diesesausgefü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 mehrereProgramme Code verwenden, der nur einmal im Speicher ist, wird durch die Trennung von Code- undDatensegment ermöglicht (BildVerschiedene 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. Geradebei komplexen Applikationen können diese Wechselwirkungen derart groß werden, dass Im übrigenunterstützen moderne Betriebssysteme das Laden dynamische Libraries unter Programmkontrolle (BildDynamisches 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 eineBibliothek lädt (siehe BildDynamisches 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


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, werdenheute aus einer Bibliothek nur die Funktionen extrahiert, die ein Programm auch wirklich einsetzt. Damitwird 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 Librariesanstelle einer großen Library spart Speicherplatz.)

Insbesondere in eingebetteten Systemen bzw. wenn einfacheLaufzeitsysteme verwendet werden, entfälltdie Notwendigkeit von Bibliotheksfunktionen.

3.4.7. ZeitgeberZeiten spielen in einem Echtzeitsytem eine wesentliche Rolle. Für Zeitbestimmungen gibt es in einemEchtzeitsystem sogenannte Realzeituhren und Timer. Diesehaben 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ängigeSystemdienste (Weckaufrufe) bearbeitet und Softwaretimer realisiert. Damit hängt dieGenauigkeit derzeitabhängigen Systemdienste von dieser Zeitbasis ab.

Zeitmessung

Das Messen von Zeiten ist eine oft vorkommende Aufgabe in derAutomatisierungstechnik. 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 vonDaten an eine Prozessperipherie)zeitüberwacht, zum anderen aber auch das gesamte System (Watchdog). Dazu muß das System imregelmäß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 undbringt 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äßigenAbständen durchgeführt werden. Zudiesen Aufgaben gehören Backups ebenso, wie Aufgaben, die der User dem System überträgt (z.B. zubestimmten Zeitpunkten Meßwerte erfassen).

Zwei Varianten von Zeitgebern lassen sich unterscheiden:

81


• 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ählervon den single shot Zählern. Die repetitivenZä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 daraufzu achten, dass alle Teilsysteme die gleiche Zeitzone verwenden (zu einem Zeitpunkt ist die Uhrzeitunterschiedlich 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. DieBetriebssysteme rechnen dann auf die lokale Zeit (mit Sommer/Winterzeit usw.) um. Die eigentlichenApplikationen selbst jedoch holen sich die Zeit über Systemdienste (siehe unten) und sollten Zeitennicht umrechnen müssen.

Über Frequenzteiler werden für die unterschiedlichen (Hardware-) Komponenten des Systems korrekteFrequenzen 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ängedes Zählers auswählen. Dieser Ausgangliefert jetzt die entsprechend dem Ausgang geteilte Standardfrequenz.

Ein Rückwärtszähler dient zur Messung von Relativ-Zeiten (Zeitdifferenzen). Die Zähler werden miteinem Wert belegt, und zählen dann mit einer Eingangsfrequenz (die über einen Frequenzteiler mitMultiplexer eingestellt werden kann) auf 0. Ist der Zähler abgelaufen, wird ein Interrupt ausgelöst.

82


Kernellevel

Im Betriebssystemkern (Betriebssystemebene, Kernel, Supervisor Mode) werden Zeiten insbesondereauf 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 basierendenzeitgesteuerten 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äufigvon System zu System der gleichesein, sondern der Abstand kann variieren.

Weiterhin kritisch ist der Umstand, dass Zähler eine endliche Breite haben und damit nach endlicherZeit ein Zählerüberlauf stattfindet (in Linux beispielsweise nach 417 Tagen). Dieser Zeitpunkt kannfür ein System kritisch sein, wenn nicht an allen Stellen (sowohl im eigentlichen Kern als auch in denTreibern 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 Funktionensleep undselect .

An der Dienstschnittstelle stellt das Betriebssystem für periodische Aufgabencron zur Verfügung. Umeine Task zu einem bestimmten (Absolut-) Zeitpunkt zu starten, gibt esat .

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 Softwaretimermöglich ist.

Während auf der Kernelebene Relativzeiten wegen der möglichen Zählerüberläufe kritisch sind, sindauf 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, findetman immer wieder, dass für dieJahresangabe 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 eineeventuell notwendige Zeitsynchronisation zwischen Rechnern bzw. der Korrektur von Absolutzeiten.

Zur Zeitsynchronisation gibt es unterschiedliche (proprietäre) Konzepte:

83


• Ein Zeitserver versendet über das Kommunikationssystem Broadcastmessages. Eine Verarbeitung dieserMessages in Hardware ermöglicht eine Zeitsynchronisationim Mikrosekundenbereich.

• Standardisiert ist die Zeitsynchronisation über das NTP (Network Time Protocol). Hier stellen ebenfallsZeitserver 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 derUhrzeit werden Berechnungen über die Laufzeit der Pakete zwischen den Rechnern durchgeführt, unddie Uhrzeit wird entsprechend korrigiert.

Die sprunghafte Korrektur von Absolutzeiten innerhalb desRechnersystems kann zu schwerwiegendenFehlern führen. Werden Zeitungenauigkeiten erkannt, werden diese nicht sofort korrigiert. Stattdessen wirddie Systemuhr vorsichtig langsamer oder schneller gestellt, so dass sich die Zeit nicht an einem Zeitpunktkorrigiert, sondern über einen Zeitraum hinweg angepasst wird (Systemcalladjtimex ).

Ähnliche Probleme gibt es, falls Rechner für einige Zeit zumBeispiel zum Zwecke der Wartung ausge-schaltet werden. Sind innerhalb der Ausfallzeit Aktionen,beispielsweise ein Backup geplant gewesen, fälltdieses 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. SchedulingUnter Scheduling versteht man die Strategie zur Festlegungdes nächsten zu bearbeitenden Rechenprozes-ses. Das Scheduling ermöglicht die parallele Bearbietung mehrerer Tasks.

Anhand eineskonstruiertenBeispiels soll die Aufgabe des Schedulers und die Wirkung bzw. Auswirkungunterschiedlicher Schedulingvarianten vorgestellt werden.

Ein Realzeitsystem wird eingesetzt, um ein Experiment an Bord eines Satelliten zu steuern. Dazu sindfolgende Anforderungen spezifiziert:

• Alle 1500ms (Zeitpunkt t0) Meßdaten aufnehmen (t

p=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 t

0, t

P=1500 ms, t

Zmax=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 zurVerfü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


250ms t V

500ms t V

300ms t V

100 200 300 400 500 600 700 800 900 1000 1100 t[ms]

ExperimentMeßdatenübertragungParameter aufnehmen

aufgenommensein

Daten müssenvorbereitet seinExperiment muß

abgeschlossen seinÜbertragung muß

Abbildung 3-32. Zeitanforderungen (Beispiel)

Aufgrund des Beispieles ergeben sich für die Konzeption desRealzeitsystems 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-paralleleBearbeitung 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.

� ��

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

T3T2T1

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 einemvernü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ürdas Scheduling bewegen sich imµ-Sekundenbereich.

Man unterscheidet statisches und dynamisches Scheduling.

85


Statisches Scheduling

Festlegung eines „Fahrplans“ (im vorhinein), nach dem die einzelnen Rechenprozesse in einem festenSchema abzuarbeiten sind. Einsatz: sicherheitskritischeAnwendungen (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 damitpreemptiv(unterbrechbar)sein.

Als Schedulerbezeichnet 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 PointsIn folgenden Situationen muß der Scheduler überprüfen, ob ein anderer Prozess die CPU erhalten sollte undgegebenenfalls 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


Determinismus

Das Scheduling als solches soll berechenbar sein.

Anmerkung: Während für Standard-Betriebssysteme Gerechtigkeit, Effizienz, Durchlaufzeit undDurchsatz eine wesentliche Rolle spielen, sind für Realzeitbetriebssysteme insbesondere die KriterienAntwortzeit 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 inden 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 Prozessnicht.

Anwendungen

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

CD

ABCD

ABCD

Zeit

Prozeß A ist aktiv

Prozeß A blockiert,

Prozeß A ist wieder bereit,wird eingereiht

Prozeß B ist aktiv

A B

Abbildung 3-34. Prinzip des FCFS Schedulings

87


200100 300 400 500 600 700 800 900 1000 1100

bereit

aktiv

T3

T2

T1

Deadline T3Deadline T1 Deadline T2

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 SchedulingPrinzip

• 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


100 200 300 400 500 600 700 800 900 1000 1100

RP3RP2RP1

Round Robin

t[ms]

Deadline T1

Rechenprozess bereit

Rechenprozess aktiv

Deadline T3 Deadline T2

Abbildung 3-36. Round Robin Schedulings

Realzeiteigenschaften:

Dynamisches Scheduling

Da die Anzahl der bereiten Rechenprozesse nicht bekannt ist, dann der Abarbeitungszeitpunkteines Prozesses nicht vorhergesagt werden (nicht deterministisch). Asynchrone Anforderungenwerden 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 Zeitscheibenstarr 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 SchedulingPrinzip

• 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 SchritthaltendeVerarbeitung).

89


100 200 300 400 500 600 700 800 900 1000 1100

T3T2T1

t[ms]

Deadline T1

Task bereit

Task aktiv


Prioritäten:T1 = 5 (höchste)T2 = 2 (niedrigste)T3 = 4 (mittlere)

Abbildung 3-37. Prioritätengesteuertes Schedulings

3.5.6. Deadline-SchedulingPrinzip

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

tZmax =Deadline

tvts

tZmax

tvts

Ist−Zeit

t

zu diesem Zeitpunkt muß die Task bearbeitet seinVerarbeitungszeit (ohne Wartezeit)Zeit−Spielraum bis zum spätestmöglichen Start der Verarbeitung (laxity)

Abbildung 3-38. Prinzip des Deadline Scheduling

� � �� D1 D2 D3 D4

tT1 T2 T3 T4

Abbildung 3-39. Beispiel für Deadline Scheduling

90


100 200 300 400 500 600 700 800 900 1000 1100

T3T2T1

t[ms]

Deadline T1

Task bereit

Task aktiv


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.1bPrinzip

• 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.

103 41

24 111 42 53

11

22 13 12 10

SCHED_FIFO

SCHED_RR

SCHED_RR

SCHED_RR

Scheduling Strategie (Policy) Queue Prioritätsebene

0

1

2

Max Prio

42 Prozeß mit der PID 42

Abbildung 3-41. Posix Scheduling

91


3.5.8. Schedulingverfahren in der AnwendungDer 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 t

vund 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


t1

Priorität

hoch

niedrig T1 T2 T3

T4

T1 T2 T2 T3t

time slice

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


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[sche d_getscheduler(0)] );sched_rr_get_interval( 0, &Time );printf("Intervall for Policy RR: %d [s] %d [nanosec]\n",Ti me.tv_sec,

Time.tv_nsec );}


struct sched_param SchedulingParameter;

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

// change scheduling policy and priority to realtime priori tySchedulingParameter.sched_priority = PRIORITY_OF_THIS _TASK;if( sched_setscheduler( 0, SCHED_RR, &SchedulingParamet er )!= 0 ) {

perror( "Set Scheduling Priority" );exit( -1 );

}

94


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

}

3.5.12. Der O(1) Scheduler im Linux-Kernel 2.5.xxWeiche Echtzeitsysteme, wie sie beispielsweise Multimediasysteme darstellen, erfordern als zusätzlicheEigenschaft von einem SchedulerInteraktivität. Interaktivität bedeutet, dass man die Zeitscheibe, die maneinzelnen Tasks zur Verfügung stellt, gemäß der Anforderungen an Interaktivität variiert. Sehr interaktiveTasks bekommen eine kurze Zeitscheibe und kommen damit häufiger dran. Rechenintensiven Tasks wirddagegen 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 zugute, 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 derVergangenheit zurückgreifen.

Der O(1) Scheduler von Ingo Molnar wird folgendermassen beschrieben:

hybrid priority-list and round-robin design withan array-switch method of distributing timeslicesand per-CPU runqueues.

Der Scheduler basiert prinzipiell auf einem Round Robin Verfahren. Alle rechenbereiten Prozesse sind ineiner 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 Zeitscheibeabgelaufen ist (expired).

acitve

expired

Priorität

switch − sobald das active−Array abgearbeitet ist

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 beidenArrays umgeschaltet. Das ehemals expired-Array wird zum active-Array und das ehemals active-Array zumexpired-Array.

Die Priorität innerhalb des Arrays ergibt sich aus dem Nice-Wert, den eine Task besitzt und einemInteraktivitäts-Bonus bzw. -Malus. Tasks die viel Rechenzeit verbrauchen bekommen eine größereZeitscheibe, allerdings bei geringerer Priorität. Die verbrauchte Rechenzeit wird über den Load-Wertinnerhalb der letzten 4 Sekunden bestimmt.

95


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 interaktivgekennzeichnet 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ürsorgt, 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 StandardbetriebssystemenAktuell 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 dasBetriebssystem in einem eingebetteten System eingesetzt wird, ist für die Bedienung der Einarbeitungs-aufwand unrelevant. Auch die Applikationsvielfalt spieltin 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


• 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 undSwapping. Hierbei werden im Bedarfsfall Teile des Hauptspeichers (Pages) auf eine Festplatte transfe-riert (geswapped) und bei Zugriff einer Applikation wiederzurückgeschrieben. Paging und Swappingist dabei aber nicht berechenbar, das System wird undeterministisch.

Caches

Moderne Prozessoren haben Caches4 eingebaut, durch die die Performance des Systems erheblichgesteigert wird. Caches sind aber leider nicht deterministisch. Es läßt sich nicht vorhersagen, ob dernächste Programmbefehl oder das nächste benötigte Datum sich im Cache befindet oder nicht. Imschlimmsten Fall (Worst Case) gibt es einen sogenannten Cache-Miss und ein realer Speicherzugriffwird 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 undeterministischist, zum anderen aber auch (durch die ISR’s) zu Undeterminismen im sonstigen System führt. Hinzukommt, 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 Realzeitbetriebnicht geeignet, da dort Verfahren eingesetztwerden, deren Hauptaugenmerk auf Gerechtigkeit und nicht auf Rechtzeitigkeit liegt. Die Auswahl dernä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. zumEinloggen des Benutzers). Realzeitsysteme werden aber oftmals Headless(also ohne Tastatur undMonitor) 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 rotierendenTeile wie Festplatten und Lüfter).

Dienstprogramme

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

97


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 noch8-Bit Controller eingesetzt), umfaßt die Anforderungen anHauptspeicher, und schließt den Umstandein, dass keinerlei Hintergrundspeicher zur Verfügung steht. Das komplette Betriebssystem muß inRealzeitumgebungen oftmals in ein Eprom oder in einen Flashspeicher passen.

Standard-Betriebssysteme bieten in der Zwischenzeit aberoftmals Systemerweiterungen an, die das Systemin 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 kleinereSysteme ist es - ebenso wie Windows95/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 technischenUmfeld zu groß sind, hat Microsoft eine speziell für den eingebetteten Bereich abgespeckte Versionvon Windows NT erstellt (Embedded NT). Embedded NT benötigtnur noch 14-24 MByte. EmbeddedNT 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 sehreingeschrä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 eigentlichenWindows Varianten und auch Embedded NT kann Windows CE direkt aus dem ROM gestartet werden.

98


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 Linuxnicht 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 (effizienterPlattenzugriff).

Aufträge werden direkt abgearbeitet.

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-BetriebssystemenWie 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 undGerechtigkeit. Determinismus dagegen - das Hauptaugenmerk eines Realzeitbetriebssystems - spielt keineRolle.

Um effizienter zu sein, werden in StandardbetriebssystemenDatenstrukturen über einen längeren Zeitraumexklusive gelockt. In Echtzeitbetriebssystemen wird eineDatenstruktur 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 kannes vorkommen, dass eine nieder-priore Task niemals Rechenzeit bekommt, da im System höher-priore Tasksrechenbereit sind. In Realzeitsystemen wartet eine rechenbereit hoch-priore Task nicht auf eine rechenbe-reite nieder-priore Task.

Standardbetriebssystemsammelnoftmals 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 dieseeine benötigte Ressource freigeben.

Trotz dieser Gründe hat man Standardbetriebssysteme um Realzeiteigenschaften erweitert. Damit sind al-lerdings nurSoft-Realtime-Systemsmöglich.

99


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 mitPentium Prozessor verzögert [Yod99].

3.7. Standard-Betriebssysteme in RealzeitanwendungenAuf Applikationsebene lassen sich unmodifizierte Standardbetriebssysteme dann in Realzeitanwendungeneinsetzen, falls Zeitanforderungen im Sekundenbereich bedient werden müssen.

Doch auch bei Anforderungen im Milliskunden- oder unter Umständen sogar im Mikrosekundenbereichlassen sich Echtzeitaufgaben mit Hilfe von Standardbetriebssystemen bewältigen. Dazu müssen die Echt-zeitanforderungen im Betriebssystemkern, z.B. innerhalbeines Gerätetreibers, bearbeitet werden.

Anforderungen im Millisekundenbereich: Treiberfunktion en (z.B. Timer)Anforderungen im Mikrosekundenbereich: ISR

- keine langwierigen Berechnungen- meist kein bzw. nur erschwerter Floating Point Zugriff mög lich- keine komplizierte Programmstrukturen möglich

Erreichbare Reaktionszeiten ergeben sich jetzt im wesentl ichen aufgrundder Zeiten, in denen Interrupts (durch Kernelfunktionen od er schlimmerdurch andere Treiber) gesperrt sind.

Vorteil:- Standardbetriebssystem!!!

Nachteil:- Lösung der Echtzeitaufgabe verteilt sich auf unterschied liche

Komponenten und wird auf das Betriebssystem angepasst.

3.8. Realzeiterweiterungen der Standard-BetriebssystemeUm 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


Ein Standardbetriebssystem echtzeitfähig zu machen, ist ausgesprochen aufwendig. Eingriffe sind an allenStellen notwendig: Synchronisationspunkte für Datenstrukturen, Scheduling, Interruptverarbeitung,Geräte-treiber, critical sections, memory management und und und.Für die Modifikationen muß man zudem nochden Preis einer verminderten Effizienz zahlen.

Die Methode, unter einem Echtzeitkern ein Standardbetriebssystem laufen zu lassen, ist gegenwärtig weitverbreitet. 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, insbesondereauch das Sperren und Freigeben von Interrupts wird durch denEchtzeitkern durchgeführt. Das Verfah-ren ist zwar vergleichsweise aufwandsarm, nachteilig dabei ist aber, dass sämtliche Tasks, die unter demStandardbetriebssystem laufen, nicht echtzeitfähig sind. Insbesondere ist es also nicht möglich, dass eineTask des Echtzeitkerns eine Komponente des Standardbetriebssystems nutzt (z.B. tcp/ip), ohne dass dieseEchtzeittask ihre Echtzeitfähigkeit (ihren Determinismus) verliert.

3.8.1. RT-LinuxRT-Linux ist amDepartment of Computer Scienceder 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 istdabei dieIdletask, 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 vomEchtzeitkern abgefangen. Dazu emuliert der Echtzeitkern die komplette Interrupt-Hardware.Versucht Linuxeinen 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 (realtimehandler) aufgerufen. Andernfalls wird der Interrupt alspendingmarkiert. Gibt die Linux-Task Interruptswieder frei, emuliert RT-Linux den alspendingmarkierten Interrupt für die Linux-Task.

Damit können Interrupts die Linux-Task in jedem Zustand unterbrechen und Linux als solches ist nicht inder Lage, irgendwelche Latency-Times zu verursachen.

Real−Time Kernel

Interrupt control hardware

Tasks

Real−Time Linux

RT−Fifos

Linux Processes

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


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

Fußnoten1. Moderne Prozessoren können bei Auftreten des Interruptssogar die Abarbeitung des gerade aktuellen

Befehls unterbrechen und müssen nicht erst auf das Ende der Befehlsabarbeitung warten.

2. Man spricht auch vonsynchronerUnterbrechung, 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 Segmentegrößer als 64 KByte sein dürfen undwelche nicht. Die Modelle Large und Huge allerdings unterscheiden sich nur darin, ob im C-Programmverwendete Pointer normalisiert und damit vergleichbar gemacht werden oder nicht.

4. Mit Caches bezeichnet man Zwischenspeicher um Zugriffe auf den Hauptspeicher als auch um Zugriffeauf Hintergrundspeicher (Platte) zu beschleunigen.

102

Kapitel 4. Prozessankopplung

4.1. Übersicht

Echtzeit−rechner

technischerProzeß

Zustandsgrößenphysikalische

Prozeßsignaledigitalisierte

Aufbereitung bzw.Ankopplung der Signale

PKM

PKM

PeripheriekoppelmodulPKM:

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 wirdder Echtzeitrechner über Peripheriekoppelmodule (PKM’s), auch einfach alsGerät bezeichnet, mit demtechnischen Prozess verbunden (siehe BildPeripheriekoppelmodule). Zur Erfassung der physikalischen Zu-standgrößen gibt es Meßwertaufnehmer, die Sensoren (z.B. Temperatursensor), und zur Beeinflußung derZustandsgröß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 undInterrupts.

Signalanpassung(Treiber...)

Signalanpassung(Treiber...)

AktorPIOGalvanische

Entkopplung WandlerD/A

SensorPIOGalvanische

Entkopplung WandlerA/D

Abbildung 4-2. Komponenten der Ein-/Ausgabemodule

103


Auf logischer Ebene kann maneinfachevon intelligentenPeripheriekoppelmodule unterscheiden. Über eineinfaches 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 Vorverarbeitungder einzulesenden bzw. auszugebenden Daten durch.

Im folgenden soll zunächst die physikalische Anbindung derGeräte angesprochen werden, bevor eine Dis-kussion der logischen Ankopplung erfolgt.

4.2. Physikalische Ankopplung

4.2.1. Übersicht Systembus

Systembus

DMA

Festplatten−controller

controller

Netzwerk−

controller

Grafik−

CPU RAM ROMDMA−

controller

Abbildung 4-3. Systembus

Zur Ankopplung peripherer Bausteine (Speicher, Interrupt-Controller usw.) besitzen Prozessoren Leitungen,die man alsBusbezeichnet (BildSystembus). Der Prozessor-Bus ist ein paralleles Hardware-Interface, dasin drei logische Einheiten geteilt werden kann:

1. Adreßbus (AB)

2. Datenbus (DB)

3. Kontrollbus (CB)

104


Über den Adreßbus wählt der Prozessor eine Speicherzelle (eben die Zelle eines Speicherbausteins oder dieSpeicherzelle eines Hardwaremoduls) aus. Über den Datenbus werden zwischen den Prozessorregistern undder Speicherzelle Daten transportiert (gelesen oder geschrieben). Der Kontrollbus besteht aus Signalen, diedie 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 densogenannten Busmastertransfer (siehe AbschnittDMA).

Bei den Signalen werden Active High Signale von Active Low Signalen unterschieden. Letztere sind da-durch gekennzeichnet, dass über dem Signalnamen ein Strichgezeichnet wird. Active Low Signale sinddann gültig, wenn der Signalpegel 0 anzeigt.

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

Bei einem Systembus handelt es sich um einen Master/Slave Bus. Ein am Bus angeschlossenes Gerät ist derBusmaster. Im Regelfall ist dies der Prozessor. Der Busmaster kontrolliert den Adreßbus, das Signal für dieSchreib/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.

Adressen

R/W

AS

DS

DTACK

Daten

1

2

3 4

5

6

7

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

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. Eine1 auf der Lei-tung bedeutet Lesen, eine0 Schreiben.

• Im Falle eines Schreibvorgangs werden die zugehörigen Daten auf den Datenbus gelegt.

105

MT Nguyen

Unterstreichen

MT Nguyen

Unterstreichen

MT Nguyen

Hervorheben


• Sind die Signale auf den Leitungen eingeschwungen, wird dasAdreßstrobe und das Datastrobe Signalgesetzt. 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 Datenbusund bearbeitet diese. Bei einer Speicherzelle werden die Daten in die Speicherzelle geschrieben. Handeltes sich bei der ausgewählten Speicherzelle um ein Register bzw. Bits, die eine Peripherie-Komponentesteuern, werden die zu den Signalen gehörenden Funktionen durchgeführt. Nach der Übernahme derDaten setzt das ausgewählte Modul das Data-Acknowledge-Signal und zeigt damit die Übernahme derDaten an. Bei einem Leseauftrag legt das ausgewählte Modul die angeforderten Daten auf den Datenbusund zeigt die Gültigkeit der Daten mit dem Data-Acknowledge-Signal an (beim Lesen also wird derDatenbus 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 Systembei 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 keinData-Acknowledge- oder beim Leseauftrag Datastrobe-Signal empfangen werden, wird dem Busmaster einBus-Error angezeigt.

Neben den Systembussen, die sich direkt (eins zu eins) aus den Signalen des Mikroprozessors ableiten (demsogenannten 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 SystembusAuf 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. EigeneEin/Ausgabebefehle definieren letztendlich einen eigenenSpeicherbereich für Peripheriekomponenten.Peripherie wird dadurch mit anderen Befehlen angesprochenals normale Speichermodule. Vorteildieser Technologie war, dass der in früheren Zeiten vorhandene eingeschränkte Adreßbereich nichtdurch Peripherie belegt wurde. Dieses Argument für eigene Ein/Ausgabebefehle verliert bei denmodernen Prozessoren mit großen Adreßbereichen an Aktualität. Vorteil ist aber weiterhin, dass derHardwareaufwand zur Dekodierung eines Peripheriegerätesdurch den eingeschränkten I/O-Adreßbereichgeringer ist.

106

MT Nguyen

Hervorheben

MT Nguyen

Hervorheben

MT Nguyen

Hervorheben


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 Registerder Module werden mit den normalen Move-, Load- oder Store-Befehlen des Prozessors angesprochen.

PR

OZ

ES

SO

RB

US

8

DecoderAddress−

Moduladdress

AS&

AdressEqualAB

Interrupt

LogikInterrupt

R/WDS

DTACK

DB

15

0

Eingabe

Digitaler Eingabekanal

EN

Eingängebinäre

Abbildung 4-5. Digitales Eingabemodul

Ein Beispiel für die prinzipielle Ankopplung eines Peripheriemoduls gibt BildDigitales Eingabemodulwie-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 derPeripherie auf den Datenbus durchschaltet,als auch gleichzeitig das Data Acknowledge. Das Data Acknowledge Signal ist ein Active Low Signal undmuß 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ögerungdie 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 amDatenbus 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 mehrereAdressen (z.B. PIO-Baustein, serieller Schnitt-stellenbaustein), müssen weniger Adreßleitungen ausdekodiert werden. Dazu werden entsprechend demzu decodierenden Adreßbereich, die niederwertigen Adreßleitungennicht verglichen. Diese niederwerti-gen Leitungen (beispielsweise A

0-A

2fü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

MT Nguyen

Unterstreichen

MT Nguyen

Hervorheben


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 werdenin ein Register geschrieben, welches wie im AbschnittPeripherieanbindung über den Systembusdargestellt,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 “serielleSchnittstelle”.

Dataregister EmptyShiftregister EmptyFraming ErrorParity ErrorOverrun ErrorData Received

07 6 5 4 3 2 1Statusregister

Receive−Interrupt EnableSend−Interrupt Enable

Kontrollregister07 6 5 4 3 2 1

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

Eine serielle Schnittstelle besitzt nicht nur das erwähnteSenderegister (BildKontroll- 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 verlorengehen, muß vor dem Schreiben auf das Sendregister überprüftwerden, ob dieses auch leer ist. Das wirdangezeigt über Bit 6 im Statusregister.

Dass ein Byte empfangen wurde, ist ebenfalls im Statusregister (Bit 0) abzulesen. Das Byte kann überdas Empfangsregister ausgelesen werden. Empfängt die serielle Schnittstelle jedoch vor dem Auslesen desBytes bereits das nächste Byte, wird im Statusregister (Bit1) ein sogenannter Overrun (Überlauf) angezeigt.Ebenfalls angezeigt wird ein Parity-Fehler. Bei asynchronen Übertragungen wird als Übertragungssicherungein Paritätsbit hinzugefügt. Die Parität kann dabei “gerade” oder “ungerade” sein. Bei gerader Parität wird

108


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 einenFramingerror, 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ängerbei 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 Stopbitsabgeschlossen.

Über das Kontrollregister läßt sich der Interrupt-Betriebder seriellen Schnittstelle konfigurieren. Wird derEmpfangs-Interrupt enabled (eingeschaltet), löst das serielle Interface nach dem Empfang eines Zeichenseinen 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 Erfassungbzw. 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) angeschlossenwerden.

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 denDigitalwert 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 schnellenAD-Wandlers findet sich in AbbildungAnkopplung eines schnellen A/D-Wandlers, eine Schaltung zum An-schluß eines mittelschnellen AD-Wandlers in AbbildungAnkopplung eines mittelschnellen A/D-Wandlers.

Bei Verwendung eines mittelschnellen oder langsamen AD-Wandlers wird der Zugriff auf den Wandler überein Control-Status Register gesteuert (AbbildungControl-Status-Register eines ADC).

018

Start conversion (write)

Interrupt enable (read/write)

15

in progress/done (read)don’t care

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 softwareseitigin gleicher Art und Weise wie eine Speicherzelleangesteuert wird. Zwei lesende Zugriffe können durchaus unterschiedliche Ergebnisse liefern, auch wennkein Schreibzugriff zwischenzeitlich durchgeführt wurde. Dies liegt daran, dass ja die Hardware die einzel-nen Bits des Registers setzt. Damit wird auch deutlich, dassebenso der lesende Zugriff, der einem schreiben-

109


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

4.2.3. Ankopplung der Signale aus dem technischen ProzessTabelleEinteilung von Peripherie gemäß Zugriffsgeschwindigkeitgibt 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 ZeitkonstanteTechnologie

schnell ns direkter Speicherzugriff, DMA

mittel µs programmgesteuerter Kanal

langsam ms Interrupt

4.2.3.1. Direkter Speicherzugriff

1

2 4

3

SOC

Data

EOC

Wandlungsstart Wandlungsende

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 AbbildungDigitales Eingabemoduldargestellt 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


A1

A23

COMP

P

Q

P=Q

R/W&DS

AS

EN

DO

D11

SY

ST

EM

BU

S

DTACKSOC

EOC

A/D

0xfffa00

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

AbbildungAnkopplung eines schnellen A/D-Wandlerszeigt, 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 einenEingang für das Starten der Wandlung (Start Of Conversion, SOC). Das Ende des Wandlungvorgangs wirddurch das Signal End Of Conversion (EOC) angezeigt. Hat dieses Signal einen High-Pegel, können dieDaten vom Datenbus des Wandlers abgegriffen werden. Sobalddas SOC-Signal wieder einen Low-Pegelannimmt, nimmt der A/D-Wandler auch das EOC-Signal zurück und die Datenausgänge haben wieder einenunbestimmten Wert.

Softwaretechnisch wird auf diese Schaltung genauso zugegriffen, wie auf eine sonstige Speicherzelle imAdreß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


COMP

P

Q

P=Q

COMP

P

Q

P=Q

A1

A23

R/W&DS

AS

SOC

EOC

A/D

COMP

P

Q

P=Q

R/W&DS

AS

SY

ST

EM

BU

S

A1

A23

R/W&DS

AS DO

0xFFFA00 0xFFFA02

END1

DTACK

DTACK

EN

DO

D11

A1

A23

0xFFFA04

DTACK

SchreibenStatuswort

LesenControlwort

LesenDaten

D

Reset

EOC

EOC

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 überden 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 eingelesenwerden.

Die drei unterschiedlichen Zugriffe (Starten der Wandlung, Überprüfen des Wandlungsendes und Einle-sen der Daten) werden beispielsweise, wie in AbbildungAnkopplung eines mittelschnellen A/D-Wandlersdargestellt, über den Zugriff auf drei Adressen abgebildet. Über die Adresse0xFFFA00 kann man auf einsogenanntes Controlwort schreiben. Dieses aus theoretisch 16 Bit bestehende Register ist für das Startender Wandlung zuständig. Aus der Schaltung ist ersichtlich,dass das Schreiben des least significant bits (Bit0) die Wandlung gestartet wird.

112


Über die Adresse0xFFFA02 kann der Zustand der Wandlung (Signal EOC) ausgelesen werden. EOC ist hierauf Bit 1 abgebildet. Die eigentlichen Daten schließlich werden bei einem Lesezugriff auf die Speicherstelle0xFFFA04 in ein internes Prozessorregisgter übernommen.

Die Schaltung belegt damit insgesamt 6 Byte im Adreßraum derCPU. Eine Codefragment zum Ausleseneines gewandelten Analogwertes könnte folgendermassen aussehen:

volatile int *ControlWort, *StatusWort, *DatenWort;int DigitalWert;

...// InitialisierungControlWort=0xFFFA00;StatusWort =0xFFFA02;DatenWort =0xFFFA04;

...// Starten einer Wandlung*ControlWort=0x0001; // Setzen von Bit 0 startet die Wandlu ng// Warten auf das Wandlungsendewhile( *StatusWort!=0x0002 ) // EOC ist gleich Bit 1

;// Auslesen der DatenDigitalWert=*DatenWort;DigitalWert&=0x0fff; // nur die unteren 12 Bit sind gueltig...

Sind zur Bedienung eines Gerätes mehrere Zugriffe auf die Peripherie notwendig, spricht man vompro-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ültigkeitder 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 diesebeiden Zugriffe über eine Adresse realisiert werden. Damitwürde das Interface insgesamt nur 4 Byte imAdreßraum belegen und die Adreßleitung A2 bräuchte nicht mehr ausdekodiert zu werden.

Das Schlüsselwortvolatile 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 internesProzessorregister kopieren würde, und dieses dann immer wieder auf Ungleichheit mit0x0002 überprüfenwürde. Das interne Prozessorregister ändert sich natürlich nie, daher würde das Programm in einerEndlosschleife hängen bleiben. Das Schlüsselwortvolatile verhindert diese Art der Optimierung. Beijedem 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 letztendlichaktivem Warten (Busy-Loop) kann nur in beson-deren Fällen toleriert werden. Im Regelfall informiert dasEin-/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


4.2.3.4. DMA

Über den Prozessor- bzw. Systembus können Prozessor und Peripherie miteinander verbunden werden. ImFalle von hochfrequent anfallenden Daten, kann der Prozessor die Daten jedoch nicht von der Peripherieabholen und direkt verarbeiten, sondern wird die Daten zunächst blockweise entgegennehmen. Dies istbeispielsweise bei Plattenzugriffen der Fall.

Ein entsprechender blockweiser Datentransfer läßt sich softwareseitig wie in BildDatenübertragung unter Kontrolle der CPUgezeigt, realisieren. In einer Schleife werden die Daten vonder Peripherie eingelesen und im Speicher abgelegt bzw. umgekehrt.

Die Transferrate ergibt sich dabei aufgrund der Programmlaufzeit und der Buszugriffszeit. Angenommender Zugriff über den Systembus daueret

B=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 (t

IO=0) und

die Programmlaufzeit seitV=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 Plattenvon 40-50MByte/s.

Sieht man sich die Formel an, so ist zu erkennen, dass höhere Transferraten nur durch Minimierung vont

Vbzw. t

Bzu 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 wirddie Aufgabe des Datentransfers von der Software in die Hardware verlagert.

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

DMA wird dadurch ermöglicht, weil die CPU die Kontrolle überden Bus abtreten kann. Dafür existieren(als Teil des Control-Bus) die Bus-Arbitrierungssignale.Der Slave, der Busmaster werden möchte, teiltdies 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 neuerBusmaster (Bus Grant Acknowledge). Nach Beendigung der Übertragung gibt der DMA-Busmaster denBus wieder an die CPU zurück (Zurücknahme der Signale Bus Grant Acknowledge bzw. Hold).

114


Solange BlockCount>0

Port = Kennung (Adresse) des Peripheriegeräts

TransferDirection = Vom Hauptspeicher zur Peripherie oder umgekhert

BlockCount = Größe des Speicherblocks

Wenn TransferDirection

Decrementiere BlockCount / Incrementiere MemoryPointer

Mem nach I/O I/O nach Mem

Inhalt von MemoryPointer = Wert

Wert = ReadPeripherie(Port)Wert = Inhalt von MemoryPointer

WritePeripherie( Port ) = Wert

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

2

1

3

MemoryPointer = Start−Adresse des Blocks im Hauptspeicher

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

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

DMA wird eingesetzt um

• Die Übertragungsrate zu erhöhen.

• Die CPU zu entlasten.

− Bus Grant Acknowledge

− Bus Grant

− Bus Request

Motorola

− Hold Acknowledge

− Hold

Intel:

Port

Count

Command

Address

Channel 0

Channel 3

To I/O

port

TRANSFER REQUEST

TRANSFER ACK

Data−chain

registers

Inte

rnal

bus

Sequenzer

BusInterface

I/O READ/WRITE

Memory READ/WRITE

IRQProcessorbus

HOLD ACKNOWLEDGE

HOLD

Busarbitrierungssignale:

Con

trol

Bus

−A

rbit

rati

on

Abbildung 4-12. HW-Struktur eines typischen DMA-Controll ers

115


Beim DMA-Betrieb werden 3 Phasen unterschieden:

1. Initialisierungsphase/Aufsetzen des Kanals:

Die CPU ist Bus-Master und beschreibt die DMA-Register, derDMA-Controller ist aus Sicht desProzessorbusses 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, bisalle 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, derCPU ein Speicherzyklus gestohlen.

2. Beim Burstbetrieb wird der Umstand ausgenutzt, dass der Zugriff auf aufeinanderfolgendeSpeicherzel-len bei dynamischen Speicherbausteinen (DRAMs) für die Folgezugriffe schneller erfolgt1. Daher wirdnicht bei jedem Datum, das es zu übertragen gilt, ein Zyklus gestohlen, sondern es wird eine AnzahlDaten aufgesammelt, es wird die Busmasterschaft übernommen und die gesammelten Werte werdenhintereinander übertragen. Erst dann wird die Kontrolle über den Bus wieder an die CPU abgetreten.

116


ZyklenProzessor−

Zyklen"gestohlene"

DMAAnforderung

Datenanfall

ZyklenProzessor−

Zyklen"gestohlene"

AnforderungDMA

Normalbetrieb

Burstmode 1

0.4

5

5µs

µs

µs

µs

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ß derDMA-Controller nicht erst von der Peripherie über den Systembus die Daten einlesen, sondern er kann siedirekt (ohne zu Hilfenahme des Systembusses) übernehmen und im Speicher ablegen (bzw. beim Schreibendirekt 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 Peripherieund 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


4.2.4. Sonstige Varianten

4.2.4.1. Gemultiplexte Ein-/Ausgabe

a0

a1

d0EN

EN

EN

EN

d1

d2

d3

1−aus−4−Decoder

y

Abbildung 4-14. Multiplexer

Mithilfe eines Multiplexers kann einer von mehreren Ein-/Ausgabekanälen ausgewählt und damit durchge-schaltet werden. BildMultiplexerzeigt eine prinzipielle Realisierungsform. Über Adreßleitungen (im Bilda

0und a

1) wird einer der vier Datenleitungen (im Bild d

0bis d

3) durchgeschaltet.

Zwei Anwendungsformen der gemultiplexten Daten Ein-/Ausgabe lassen sich unterscheiden: der Daten-multiplex und der Zeitmultiplex.

4.2.4.1.1. Datenmultiplex

A 0 A 1

Multiplexer

Analog

Wandler

A/D−

(schneller)

SOC EOC

S/H

Sampleand

Hold

Abbildung 4-15. Analogmultiplexer

Weite Verbreitung haben Analogmultiplexer (siehe BildAnalogmultiplexer) gefunden: Um teure A/D-Wandler zu sparen, setzt man vor einen A/D-Wandler einen Analogmultiplexer, mittels dem einer vonmehreren 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


128 einzelne Bits steuern. Allerdings sind dazu auch bis zu 128 Zugriffe notwendig. Eine Schaltung, diedie Ansteuerung von 16 mal 4 Bit ermöglicht, zeigt BildDatenmultiplex. 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 desDatenwortes gespeichert.

1DQQQ

1D1D1D

Q

C1

1DQQQ

1D1D1D

Q

C1

1DQQQ

1D1D1D

Q

C1

d7

d6

d5

d4

d3d2d1d0

VZ = Verzögerung

Decoder

1 aus 16

Stellsignale

Adressen

VZ VZ VZ

Abbildung 4-16. Datenmultiplex

4.2.4.1.2. Zeitmultiplex

EnEn EnEn

D0−D7 D0−D7 D0−D7D0−D7

Port A

Port B

PIO

C/S

A0−A2

D0−D7

Abbildung 4-17. Ansteuerung einer Anzeige im Zeitmultiplex

119


Zeitmultiplex wird oft im Kontext von Anzeigen (Anzeigetafeln) eingesetzt (BildAnsteuerung einer Anzeige im Zeitmultiplex). Man nutzt den Umstand, dass das menschliche Auge Bilder,die ab einer Frequenz von ca. 20 Herz auftreten, alsFilm auffaßt und nicht mehr in Form von Einzelbildererkennt. Man schaltet daher die einzelnen Anzeigeelementenicht alle gleichzeitig, sondern nacheinanderan - und das mit einer Frequenz höher als 20 Herz. Dafür braucht man dann nicht einen Ausgabeport fürjede Stelle der Anzeige, sondern begnügt sich mit einem Ausgabeport, der die Segmente einer Stelleausgibt, und einem Port, der das Anzeigenelement auswählt,auf welches die Ausgabe durchgeführtwerden soll.

4.3. Softwaretechnische Ankopplung

4.3.1. Einfache PeripherieAuf “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 derHardware-VerschaltunggegebeneFunktionen.

4.3.2. Intelligente PeripherieUnter 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 kannin diesem Falle

• Skalierung,

• Meßbereichsumschaltung,

• Konvertierung

und ähnliches sein.

Die Datenschnittstelle (Datenfluß) zu einem derartigen Sensor oder Aktor besteht im Regelfall aus einemSatz 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 denKontrollflußenthalten diese Register (z. B. das Statusregister) Flags,über die der Datenaustauschsynchronisiert wird. Intelligente Sensoren und Aktoren nutzen darüberhinaus sehr häufig auch Interrupts,um dem Hostsystem (dem Steuerrechner) mitzuteilen, dass Informationen vorliegen, bzw. der Hostrechnerlöst beim Sensor bzw. Aktor einen Interrupt aus, um diesem ebenfalls das Vorliegen von Daten (z.B. einAuftrag an die Peripeherie) mitzuteilen.

120


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

0x1000 0xf000

0x1009 0xf009

0x0009

Mem−Basis aus Sicht des Prozessors:0x1000Mem−Basis aus Sicht des Moduls: 0xf000

Adresse = Basis + Offset

0x1000 + 0x0009 = 0x1009ProzessorModul 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 BildUnterschiedliche Adreßlagen beim DP-Ram).

Merke: Je nach technischer Realisierung des DP-Ram’s ist der Zugriff auf eine oder mehrere (eventuelldes gesamten DP-Ram’s) Speicherzellen zu einem Zeitpunkt nur von einer Seite möglich. Greift daherein schneller Prozessor (beispielsweise pollend) ständig auf den Speicher zu, kann die andere Seiteblockiert 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ächsteine 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 physikalischenMedium können mehrere Kommunikationspartnerunabhängigvoneinander kommunizieren. Eine Funk-strecke beispielsweise bietet unterschiedliche Frequenzen, die genutzt werden können. Sobald jedoch dieKommunikations bidirektional möglich sein soll bzw. mehr als zwei Partner miteinander kommunizieren,benötigt man ein Protokoll.

121


Hörer abheben

Auflegen

Ertönt das Besetztzeichen?JaNein

Wird abgehoben?

Abbruch

Nummer wählen

Abbruch

Eigenen Namen durchgeben

Nein

NeinJa

JaMeldet sich gewünschter

Partner?

LA

YE

RL

AY

ER

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ßtist. Ein Beispiel dazu ist das Telefonieren(Bild Vereinfachtes Protokoll zum Telefonieren). Bevor wir mit unserem Gesprächspartner reden können,müssen wir erst einmaleine 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 oderein Freizeichen. Das Besetztzeichen ist ein Ton unterbrochen mit kurzen Pausen, das Freizeichen ein Tonmit langen Pausen. Hören wir das Besetztzeichen, brechen wir den Verbindungsaufbau ab (legen auf) undversuchen es zu einem späteren Zeitpunkt erneut. Beim Freizeichen warten wir noch, ob unser Partner dasGespräch annimmt oder nicht. Im letzteren Falle brechen wirauch den Verbindungsaufbau ab und versu-chen es zu einem (eventuell viel) späteren Zeitpunkt erneut. Nimmt der Gesprächspartner das Gesprächan, 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 sichjemand vielleicht Unerwarteter, erklären wir, dass wir eigentlich mit einem anderen (und wir definieren, mitwelchem) Kommunikationspartner reden wollen. Haben wir unseren Gesprächspartner an derStrippe, danngeben wir unsererseits unseren Namen preis, damit der Partner weiß, mit wem er spricht, und beginnenunser Anliegen mitzuteilen. Sprechen wir jetzt noch die gleiche Sprache (z.B. Deutsch oder Englisch), dannversteht uns im Normalfall auch der Gegenüber.

Ähnlich wie der Verbindungsaufbau funktioniert auch der Verbindungsabbau. Wir fragen noch nach, ob dieInformation 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 zumAnschluß des Kommunikationspartners hergestellt. DieserVorgang ist beendet, wenn dort das Gesprächentgegengenommen wird (der Hörer wird abgenommen). Danacherfolgt der Verbindungsaufbau mit demeigentlichen Kommunikationspartner, bei dem die Identifikationen festgestellt werden (beide nennen ihrenNamen).

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


Physical Layer

Data Link Layer

Transport Layer

Network Layer

Session Layer

Presentation Layer

Application Layer

Physical Layer

Data Link Layer

Transport Layer

Network Layer

Session Layer

Presentation Layer

Application Layer

Abbildung 4-20. ISO-Schichtenmodell der Kommunikation

Physikalische Ebene

Die physikalische Ebene beschreibt die Art und Weise, wie die Kommunikationsteilnehmerphysikalisch miteinander verbunden sind. Es beantwortet die Frage, ob eine Zweidrahtleitungverwendet 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 eineRessource, 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 auchdas Routing, sprich die Suche nach dem richtigen Datenweg hin zum Kommunikationspartner (überdie Adressierung).

Transport Layer

Die Transportschicht ist für die Übertragung der Pakete zuständig. Dazu gehört die Aufgabe, großeDatenmengen in kleinere Einheiten zu verpacken bzw. auf derGegenseite wieder zusammenzusetzen.Das ist in dem Fall notwendig, dass die unterliegenden Schichten nur Pakete mit einer begrenztenLä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. Innerhalbdieser Schicht wird realisiert, dass unterschiedliche Tasks, die auf einem Rechner laufen, mit Tasks aufanderen 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


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 Datenteilund dem Trailer. Für jede Schicht ist das komplette Paket derdarüberliegenden Schicht der Datenteil. DasPaket wird also mit jeder Schicht größer.

HeaderApplikationsdaten

Trailer

Layer 6

Header

Layer 5

Layer 6

Trailer

Layer 5

Header

Layer 4

Trailer

Layer 4

Trailer

Layer 3

Header

Layer 3

... und so weiter

Daten der Schicht 4

Daten der Schicht 5

Daten der Schicht 6

Abbildung 4-21. Pakete werden in Pakete verpackt

Der Header enthält statische Informationen zum Paket. Diese Informationen helfen dem Empfänger, bereitsbeim Empfang der ersten Bytes des Pakets zu entscheiden, ob dieses für ihn relevant ist, oder ob er denEmpfang abbrechen kann. Zu diesen Informationen gehören klassischerweise Adreßangaben (Absenderund Empfänger) und Längeninformationen.

Der Trailer enthält Informationen, die beim Empfang des Paketes gebildet werden können. Typischerweisesind dies Sicherungsinformationen (Checksum), die anzeigen, ob das Paket korrekt übertragen wurde odernicht.

4.3.3.1.4. Adressierung

Prinzipiell kann man zwei Adressierungsarten voneinanderunterscheiden:

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


� � ��

� � ��

� ��

� ��

� ��

� ��

� ��

� ��

Netz C

Netz B

Netz A

Sender derNachricht

Empfänger derNachricht

Hop Count=0

Hop Count=1

Hop Count=2

Empfänger kann die Nachrichtnicht empfangen, da das Gatewaydie Nachricht nicht in das Subnetzroutet (Hop Count = 0).

Abbildung 4-22. Ausbreitung von Multicastnachrichten

Zieladressierung

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

Quellenadressierung

Bei der Quellenadressierung ist der Empfänger dafür verantwortlich, die richtigen Nachrichten zuempfangen. Der Absender verschickt seine Nachricht einfach über das Kommunikationssystem. ZurIdentifizierung der Nachricht wird im Regelfall eine ID vergeben, die der bzw. die Empfänger derNachricht kennen.

Lesedienste (Read-Services) sind im Regelfallunconfirmed, also unbestätigt. Der bzw. die Empfängerquittieren (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 kennter 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, entsprichtder Adreßraum derBreite 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 sprichtvon 1:1 oder auch Punkt zu Punkt Kommunikation. Bei der Zieladressierung gibt der Absender dieAdresse des Empfängers an, bei der Quellenadressierung braucht sich der Absender nicht um dieAdressierung zu kümmern.

125


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 dieRealisierung 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 (BildAusbreitung von Multicastnachrichten). Die Netzübergangspunkte (Gateways, Router) werdenkonfiguriert, um einen Multicast weiterzuleiten oder eben nicht. Außerdem läßt sich der Nachrichteine AnzahlHopsmitgeben. Diese Anzahl spezifiziert die Anzahl der Gateways, die die Nachrichtweiterleiten dürfen. Jedes Gateway reduziert den Hops-Count um 1. Ist dieser gleich Null, wird dieNachricht nicht ins folgende Subnetz transportiert.

Bei der Zieladressierung abonniert sich der Empfänger auf die Adresse (er abonniert sich in eineMulticast-Gruppe). Damit besitzt sein Rechner logisch betrachtet mindestens zwei Adressen, nämlicheine eindeutige Adresse für die 1:1 Kommunikation und eine im gesamten Netz mehrfach vorhandeneMulticastadresse.

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 Multicastsmüssen die Teilnehmer auf die Broadcast-Absender-Adressehorchen. Ebenfalls wie bei Multicastsist das Verschicken eines Broadcastsunconfirmed, also ein unbestätigter Dienst (es gibt von denEmpfängern keine Rückmeldung, dass die Daten empfangen wurden).

Bei Kommunikationssystemen, die aus mehreren Subnetzen bestehen können (beispielsweise Ether-net), werdensichernur die Teilnehmer erreicht, die an dem Subnetz angekoppeltsind, an dem auchder Absender der Nachricht angekoppelt ist. Andernfalls würden Broadcasts eine Ausbreitung übersämtliche Subnetze haben, was in einem großen Netz zu ungewollten Auslastungen führt. Im Regelfallläßt sich die Ausbreitung von Broadcasts konfigurieren (Stichwort Anzahl der Hops - Gateways -, überdie 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


Bus

Busabschluß

Ring

Stern−koppler

Stern

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 derphysikalischen Ausprägung (durch Abschlußwiderstände) abgeschlossen (bei der Koaxialverkabelungdes Cheapernets sind das jeweils 50 Ohm Widerstände).

Diese Variante ist insbesondere für die gleichberechtigteKommunikation zwischen den Teilnehmerngeeignet. Zumindest von der physikalischen Struktur her ist keine Station ausgezeichnet. Nachteiligist, dass alle Nachrichten über den Bus gehen. Damit ergibt sich eventuell eine hohe Buslast (alleTeilnehmer müssen sich die eine Leitung teilen). In modernen Kommunikationsnetzen versucht mandiese Last durchintelligente Switches2 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, daeine derartige Kommunikationsstruktur leichter auf Einhaltung von Echtzeitanforderungen zu über-prüfen ist. Je nach Ausprägung erteilt der Sternkoppler deneinzelnen Stationen eine Sendeberech-tigung zu, oder er ist in der Lage, mit den eventuell gleichzeitig ankommenden Anfragen mehrererTeilnehmer zurecht zu kommen. Die Last auf den Übertragungsleitungen ist relativ gering, da nur derDatenverkehr zwischen dem Sternkoppler und der an der jeweiligen Leitung angeschlossenen Stationtransportiert 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ähntenSwitch).

Ringstruktur

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

127


nicht für diese bestimmt sind, werden einfach am gegenüberliegenden Port (aus Sicht der Nachrichtdie 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öhererDurchsatz 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 denAdressaten erreicht.

4.3.3.1.6. Buszugriffsverfahren

Asynchrone ÜbertragungSynchrone Übertragung

mit zentraler Kontrolle

Serielle Busse

Zentrale

BuszuteilungCSMA/CA CSMA/CD

Zufälliger

Buszugriff

Kontrollierter

Buszugriff

Dezentrale

Buszuteilung

Ein Teilnehmer

pro Kanal

Mehrere Teilnehmerpro Kanal

Zeitmultiplex Frequenzmultiplex

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 Teilnehmernzyklisch 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


Realzeiteigenschaften:Durch den mit zentralem Master möglichen synchronen Ablauf ergibt sich einberechenbares 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 Stationenam Kommunikationsmedium können prinzipiell alle auf das Kommunikationssystem zugreifen, jedoch darfnur der Teilnehmer, der den sogenannten Token hat, den Bus nutzen. In dieser Zeit kann er Nachrichten anandere Stationen verschicken. Die angesprochenen Stationen quitieren im Regelfall den Nachrichtenemp-fang.

Der Token selbst ist eine spezielle Nachricht, die über das Kommunikationssystem verschickt wird. DieStation, die den Token hat, darf diesen nur eine endliche (konfigurierte) Zeit behalten. Danach muß sieden Token an ihren Nachfolger weitergeben. Der Token bzw. die Tokenweitergabe erzeugt zwischen denKommunikationsteilnehmern 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, tretenjedoch Fehler auf, weisen sie zumeist kein deterministisches Verhalten mehr auf. Als Fehler bei derKommunikation 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 alsBuszugriffsverfahren bei Ethernet bekannt geworden. Liegt bei einer Station ein Sendewunsch vor, hört dieStation zunächst das Kommunikationsmedium ab, ob es frei ist, oder ob gerade eine Übertragung läuft. Istdas Medium frei, wird das Paket übertragen. Da es vorkommen kann, dass gleichzeitig zwei Stationen einPaket auf den Bus legen, muß die Station den Bus abhören, ob eszu einerKollision gekommen ist odernicht. Wird eine Kollision entdeckt, zieht sich die sendende Station vom Bus zurück und versucht zu einemspäteren Zeitpunkt die Nachricht erneut zu versenden. Die Wartezeit bis zum erneuten Versuch ist dabeivon Teilnehmer zu Teilnehmer unterschiedlich lang und wirdzufällig bestimmt.

Realzeiteigenschaften:Das Argument, das lange Zeit gegen Ethernet in der Automatisierungstechnikvorgebracht wurde, lautet, dass CSMA/CD nicht realzeitfähig ist. Der große Erfolg der Technologieaber in der Bürokommunikation, verbunden mit niedrigen Preisen für die Anschaltung sorgt dafür, dassimmer mehr darüber nachgedacht wird, Ethernet mit CSMA/CD auch in der Automatisierungstechnikzu 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) diesendewillige Station, ob der Bus frei oder belegt ist. Ist der Bus frei, sendet die Station und hört gleichzeitigauf dem Bus mit. Von den beiden möglichen Pegelzuständen aufdem Bus (0 und 1) ist die 0 dominantund die 1 rezessiv. Das bedeutet: wenn eine Station eine 0 sendet und gleichzeitig eine andere Station

129


eine 1, setzt sich die 0 durch und die Stationen empfangen eine 0. Empfängt eine sendende Station einanderes Bitmuster, als sie aussendet, zieht sie sich vom Buszurück. Damit hat es zwar eine Kollision aufdem Bus gegeben, die Station aber, die das dominante Bitmuster sendet, bricht nicht ab, sondern kann dasgesamte Paket verschicken. Wichtig für CSMA/CA sind also die bitweise Arbitrierung des Busses undkurze Leitungen. Bei langen Leitungen werden die Leitungslaufzeiten so lang, dass die gesendeten Bitsnicht synchron bei den einzelnen Stationen ankommen.

CSMA/CA wird insbesondere beim CAN-Bus (siehe AbschnittCAN) eingesetzt. Die ersten übertragenenBits stellen dabei den sogenannten Identifier (Quellenadressierung) dar. Damit ergibt sich eine Priorisierungder Identifier. Je kleiner ein Identifier ist, desto sichererwird er übertragen.

Realzeiteigenschaften:CSMA/CA ist realzeitfähig. Die höchstprioren Daten werden ohne zeitlicheVerzö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 desEchtzeitverhaltens (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 aufder 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 mitdem Bus gekoppelt ist. Am technischen Prozess werden die Ein-/Ausgabemodule auf der einen Seite mitdem technischen Prozess und auf der anderen Seite mit dem Busverbunden.

Die Aufwandseinsparungen auf der Hardwareseite werden beivielen Bussystemen auf der Softwareseitewieder 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


Request

Indication

Response

Confirmation

Client Server

Abbildung 4-25. Kommunikationsprimitive

Bei Feldbussystemen findet man insbesondere die folgenden Kommunikationsmodelle:

Client Server Kommunikation

Bei diesem Modell fordert (Request) ein Client einen Dienstbei einem Server an. Dienste könnendabei 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 PrimitiveRequest undConfirmation findet man auf der Seite des Clients, während die PrimitivenIndication 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 zueiner 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 generiertund dem Client übermittelt. Der Client wird über den Eingangder Antwort mittels einerConfirmation

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 PROFIBUSFMS beispielsweise lösen sowohl Ereignisse auf dem Kommunikationsmedium (z.B. Fehlerzustände)Indications aus, ebenso kann der Server mittels eines sogenanntenInformation 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üglicheiner 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


entweder periodisch an seine Subscriber oder bei jeder Objektänderung. Die Aktivität geht dabei vomPublisher 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 einenWert übermittelt zu bekommen.

Master Slave Kommunikation

Die Master/Slave Kommunikation ist quasi die Umkehrung derPublisher/Subscriber Kommunikation,da hier die Aktivität vom Master ausgeht. Der Master fordertnämlich (polling) von seinen Slaves dienotwendigen Daten an.

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

queued

Die ankommenden Daten werden in eine Warteschlange nach demFIFO-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 vorhandenenWert. 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-Betriebnotwendig) 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


4.3.3.2.1. CAN

Station bricht ab

Station

Station

2

1

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 8Byte können nur kurze Nachrichten übermittelt werden, die jedoch geringe Datenübertragungszeitenbenö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 Endefeld0..64bit 15+1bit 1+1bit 7bit11+1bit 6bit1bit 3bit

Ruhe

Abbildung 4-27. Aufbau eine CAN-Telegramms

Das bitorientierte Rahmenformat einer CAN-Nachricht ähnelt dem Format des HDLC-Protokolls. Für denCAN-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 einFehler festgestellt, tragen die Stationen, die den Fehler diagnostiziert haben, im ACK-Feld eine 0 ein. Dadie sendende Station das eigene Paket mithört, erkennt sie die fehlerhafte Übertragung. Sie versucht dasPaket erneut zu versenden.

Damit hängt zum einen die Anzahl der gesendeten Bits vom Telegramminhalte ab (Bitstuffing) und das Bitdes ACK-Feldes hängt davon ab, ob das Telegramm von allen Stationen korrekt empfangen werden konnteoder nicht.

Auf Applikationsebene des OSI-Schichtenmodells sind zweiProtokolle spezifiziert:

133


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, ExtendedCAN 500 Millionen. Bemerkungen: 2032Datenobjekte, die auf ca. 30 Teilnehmer zu je ca. 60Objekten 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, Restfehlerwahrscheinlichkeit10-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


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.

VFD

Server

Gerät

Client

Objekt(z.B. Temperatur)

Verbindung zur VFDZugriff 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 einemServer zugreifen. Innerhalb des Servers (des Gerätes) sinddie 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 (eineVerbindung 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 dieDienste zur Verfügung stellt, die der Client später verwenden möchte, oder ob der Client überhaupt auf dieVFD 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 mandown- und uploaden, PI’s kann man starten und stoppen. Das “reine” Client/Server Modell, bei dem jeglicheAktion vom Client ausgeht, wird mit dem Dienst “InformationReport” durchbrochen. Hier bekommt derServer die Möglichkeit, unaufgefordert dem Client eine Nachricht zu senden.

Betrachtet man einen Server bzw. ein Gerät genauer, erkenntman, dass neben dem Kommunikationssy-stem im Gerät auch eine Applikation abläuft. Die Objekte selber, auf die zugegriffen wird, müssen in derApplikation instanziiert werden, in der Kommunikation aber parametriert (angemeldet) werden.

Damit muß vom System-Integrator bzw. Programmierer folgende Konfiguration durchgeführt werden:

135


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. Wirdbeispielsweise als Baudrate 500 kBit gewählt, wird eine andere Target-Rotation-Time definiert, als bei9.6 kBit.

2. Verbindungskonfiguration

Die Verbindungsparameter zwischen einem Server und den Clients müssen exakt stimmen. Dies betrifftinsbesondere 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 mitden Objekten assoziiert sind, auf Client Seite aber mit der Verbindung, müssen bei unterschiedlichenPasswö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 desOSI-Referenzmodells pollt der Master ständig seine Slaves. Ein Slave ist genau einem Masterzugeordnet, ein Master aber kann mehrere Slaves haben. An einem derartigen PROFIBUS-Netzkönnen mehrere logische DP-Netze (bei gleichzeitigem Betrieb von PROFIBUS FMS) betriebenwerden. Das heißt, es gibt mehrere Master und die ihnen jeweils zugeordneten Slaves (BildMehrere logische DP-Netze an einem Strang).

PROFIBUS

Slave 1

Slave 3 Slave 4

Slave 2

Master 1 Master 2

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

136


Input Output Input OutputInput Output

Input OutputInput Output

Slave 1

Prozeßperipherie

Input Output

Speicher im DP−Master

Prozeßperipherie

Slave 2

Prozeßperipherie

Slave 3

Abbildung 4-30. Abbildung der DP-Kommunikation

Die Applikation selbst sieht vom Kommunikationssystem nureinen Speicherbereich, der logisch in mehre-re Bereiche geteilt ist (BildAbbildung der DP-Kommunikation). Jeder konfigurierte Slave wird dabei durcheinen solchen Speicherbereich repräsentiert. Ein Slave-Speicherbereich selbst ist logisch nochmals in einenEingabe- und einen Ausgabeteil unterteilt. Das Kommunikationssystem sorgt dafür, dass vom Slave alleEingangs-Zustandsgrößen ständig gelesen werden und in denSpeicherbereich im Master für die entspre-chenden Slaves geschrieben werden. Umgekehrt wird zyklisch der Ausgabebereich für einen Slave auf demMaster zum Slave hin kopiert, der entsprechend diesen Datenseine Ausgabekanäle setzt.

Die Applikation sieht damit die Kommunikation nicht mehr, sondern greift einfach lesend (buffered, nichtqueued) und schreibend auf die entsprechenden Speicherbereiche zu. Da die Applikation auf eine Kopiezugreift und dabei zunächst nichts über dieQualitä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 einesInterrupts). Inhalt einer derartigen Diagnose könnte sein, dass ein spezifischer Slave nicht mehr erreichbarist 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 umeinen herstellerspezifischen Datensatz. Die Konfigurationsdaten informieren über Art und Anzahl derEin-/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 zubewerten ist, ist es auf der anderen Seite negativ, dass nur der Master - und damit als Steuerung - Zugriffauf die Informationen im Netz hat. Ist eine Visualisierung in der Steuerung nicht realisiert (oder nichtrealisierbar, da es sich um eine einfache SPS handelt), kanndiese auch nicht mit endlichem Aufwand zurVerfügung gestellt werden.

4.3.3.2.2.3. DP/V1

Aufgrund der eingeschränkten Möglichkeiten, die sich durch den prinzipiell rein zyklisch ausgerichtetenDatenaustausch ergeben, erweitert DP/V1 die DP-Funktionalität noch um einen azyklischen Datenverkehr.

Dabei können die azyklischen Dienste auch von einem zweitenMaster genutzt werden, der bereits bei DP(als Konfigurationsstation) spezifiziert war.

137


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 Informationenaus dem Gerät auslesen. Notwendig ist dieseSpezifikation 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 derEchtzeitsysteme nicht einsetzbar. Die weite Ver-breitung jedoch im Bereich der Bürokommunikation erzwingtgegenwärtig ein Umdenken, da der Einsatzvon 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 bishinin den Feldbereich.

• Standardisierte und interoperable Übertragungsprotokolle!

Die fehlenden Realzeiteigenschaften des Ethernet-Zugriffsverfahrens (CSMA/CD) rühren daher, dass essich um ein asynchrones Zugriffsverfahren handelt, bei demim Falle einer Kollision Pakete nach einerzufä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


Feldgerät Feldgerät Feldgerät

SternkopplerSwitch

EthernetCSMA/CD

Priorisierung und

NachrichtenScheduling der

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 Ethernetstrukturgibt eine derartige Hardwarestruktur wieder. Die einzelnen Feldgerätesind sternförmig an einen intelligenten Ethernetswitch angekoppelt. Auf den einzelnen Strängen zwischendem Switch und den Feldgeräten kann es nur zu einer Kollisionkommen, wenn Switch und Feldgerätgleichzeitig senden wollen. Schließlich handelt es sich umeine Punkt zu Punkt Verbindung. Der Switch al-lerdings muß in der Lage sein, mit mehreren Anforderungen (auf jedem Strang eine) gleichzeitig zurecht zukommen und außerdem - nach entsprechenden Regeln (Prioritäten) - mehrere Pakete von unterschiedlichenAbsendern, 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 einzelnenFeldgerät. Ist beispielsweise im Feldgerät ein HTTP-Server integriert, kann der Gerätezustand mit einemnormalen Browser abgefragt und gegebenenfalls auch verändert werden. Ethernet im Feldbereich eröffnetinsbesondere auch ganz neue Möglichkeiten für die Remotewartung der Anlagen. Der Anlagenherstelleroder eine Wartungsfirma können periodisch oder nach Auftreten eines Fehlers, über den sie über Ethernetquasi automatisch informiert werden, in die Anlagereinsehenund Wartungsarbeiten durchführen, ohnewirklich vor Ort sein zu müssen.

Auf der anderen Seite stellt der Anschluß einer Anlage an dasInternet die Anlagenbetreiber vor bisherunbekannte Sicherheitsprobleme. Der Zugriff auf die Anlage darf nur für authorisierte Personen bzw. überauthorisierte 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 zukontrollieren.

4.3.3.3. Function Blocks

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

139


Auf Function Blocks werden standardisierte Anwendungsfunktionenabgebildet, wobei die Function Blocksdirekt die Kommunikationsfähigkeit besitzen.

Fußnoten1. 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. Dabeilernensie aber, welche Stationen in welchem Segment sind und übermittelnnur dann eine Nachricht in ein Segment, wenn sich dort eine amEmpfang interessierte Station befindet.

140

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

5.1. ProgrammiersprachenAbhängig vom Einsatzbereich und von den Anforderungen werden unterschiedliche Programmiersprachenverwendet:

Entscheidungstabellen

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

1

X/Y

2

Zustand Transition

Ereignis Ausgabe

Zustand Transition

1/Y 2/Z

X

Ausgabe Ereignis

Mealy−Automat

Moore−Automat

Abbildung 5-1. Elemente eines Zustandsautomaten

Zustandsautomaten bestehen aus einer Anzahl Zuständen, Ereignissen, Transitionen und Ausgaben(siehe AbbildungElemente eines Zustandsautomaten). Ein System befindet sich dabei immer in genaueinem Zustand. Das Eintreffen eines Ereignisses löst dann einen Zustandsübergang vom aktuellen ineinen Folgezustand aus, wobei die Transition den Folgezustand definiert.

Bei den Zustandsautomaten mit Ausgaben - im Gegensatz zu denendlichen 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

1

3

2A/g

C/y

B/u

C/a

123

A B C2/g − −− 3/u 1/y− 1/a−

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 eineSpalte in der Tabelle und für jeden möglichenZustand 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 (alssogenanntes ROM-Steuerwerk). Durch die einfache Strukturierung ist ein Realzeitnachweis durch-führbar, durch die einfachen Verarbeitungsschritte (keine mathematische Operationen) ist eine zügigeAbarbeitung 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 ebenfallsan die Zustandsautomaten angelehnt. Miteinem grafischen Editor lassen sich die Elemente

• Step

• Transition

• Action

• Branch

spezifizieren.

142


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 vonAufgaben, 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. DieInstruction Lists sind ebenfalls in der IEC 6 1131 spezifiziert.

Function Blocks

Eine vor allem in Europa akzeptierte Programmiermethode zur Programmierung einer SPS sind dieFunction 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 aufgrundder Eingangssignale und interner Zustände berechnet. Function Blocks eignen sich vor allem für dieSteuerung von Prozessen, bei denen analoge Zustandsgrößenverarbeitet werden. Es werden drei Artenvon Funktionsblöcken unterschieden:• Standard-Funktionsblöcke• Abgeleitete Funktionsblöcke und• Programm-Blöcke.

Beispiele für Standard-Funktionsblöcke, bei denen die IEC6 1131 den Algorithmus normiert hat,beinhalten mathematische Funktionen, logische Funktionen und Zeitsteuerungen.

Bei den abgeleiteten Funktionsblöcken kann der Entwicklerden Algorithmus selber programmieren.Dieses kann wiederum in einer der fünf Programmiersprachengeschehen. Unter Umständen ist es aucherlaubt, dass abgeleitete Funktionsblöcke keine Eingängeoder Ausgänge besitzen.

Die letzte Gruppe der Funktionsblöcke, die Programm-Blöcke, dient einzig zur Strukturierung derAufgabe.

Structured Text

Structured Text ist eine Pascal-ähnliche Programmiersprache zur Programmierung einer SPS, die alsfü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 komplexsind, um dazu mathematische Funktionsblöcke zu verwenden).

Assembler

Durch die Natur der Aufgabenstellung findet insbesondere bei harten Realzeitsystemen oft Assemblerals 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 sindnicht in der Sprache verankert

143


• Compiler gibt es für beinahe alle Mikroprozessoren, vom 8-Bit-Controller bis hin zum64bit-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 wenigerhäufig anzutreffen als sein Vorläufer. Der Einsatz liegt beikomplexen Themenstellungen, da es füreinfache Mikroprozessoren keine Compiler gibt und außerdem der erzeugte Code umfangreicher istals 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 Sprachebereits 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ürThreads 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. UnterklassischenProgrammiersprachen werden hier Sprachen verstanden, diezunächst unabhängig vom darun-terliegenden Laufzeitsystem sind.

5.2. ProgrammiertechnikBei 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


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 schritthaltendeVerarbeitung 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ß (eineSynchronisierung, beispielsweise durchSemaphoren 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 wurdeeinfach fallengelassen, wobei Luftsäcke - wie Airbags im Auto - den Aufschlag abfingen. Nach der Landungsetzte der Pathfinder ein Fahrzeug auf dem Marsboden ab, das Sejourner-Fahrzeug, welches die nähereUmgebung der Landefläche genauer untersuchen sollte.

Nach einer anfänglich (und auch letztendlich) überaus erfolgreichen Mission, stellten sich nach einigenTagen 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 einenerheblichen Datenverlust mit sich. Da insbesondere das Sejourner-Fahrzeug nur für eine Missionsdauer von7 Tagen konzipiert war, begann hier auf der Erde eine fieberhafte Suche nach den Ursachen für diesenSystemreset.

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 derenFallstricke untersucht werden. Dazu wird zunächst die Theorie der “Software Glitches” untersucht.

145


Informations−Bus

M−Task = Task zur Erfassung meteorologischer DatenB−Task = Bus−Management−TaskZ−Task = Task zur Zustandserfassung

RK = Rechnerkernbelegung

M−Task

B−Task

Z−Task

disjunkteTasks

nicht disjunkte Tasks

Abbildung 5-3. DFD des Mars-Pathfinder

AbbildungDFD des Mars-Pathfinderzeigt drei Rechenprozesse des Mars-Pathfinder, die gemeinsam eineAufgabe bearbeiten. Die M-Task ist zuständig für die Erfassung meteorologischer Meßwerte. Die Z-Taskfü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 findetein Datenaustausch statt. Die Prozessegehören semantisch gesehen zusammen. In einem solchen Fallspricht man vonnicht disjunkten Tasks. DieZ-Task ist dagegen unabhängig von den beiden anderen Tasks,sie ist damitdisjunktzu den beiden anderenRechenprozessen.

Informationen innerhalb des Raumfahrzeugs werden über einen sogenannten Informationsbus ausgetauscht.Zunächst ist dieser Informationsbus nichts anderes als eingemeinsamer Speicher. Auf diesen gemeinsamenSpeicher greifen sowohl die M-Task als auch die Bus-Management Task zu. Beide Tasks konkurrieren alsoum dieses Betriebsmittel (Systemressource). Man spricht in diesem Falle auch von konkurrierenden Tasks,im Gegensatz zu kooperierenden Tasks.

10 20 30 40 50 60 70 80 90 100 t110 120

10 20 30 40 50 60 70 80 90 100 t110 120

10 20 30 40 50 60 70 80 90 100 t110 120

M−Task = Task zur Erfassung meteorologischer DatenB−Task = Bus−Management−Task

RK = Rechnerkernbelegung

RK

B−Task

M−Task

Bufferinhaltinkonsistent

Abbildung 5-4. Mars-Pathfinder: Unsynchronisierter Datenaustausch

146


AbbildungMars-Pathfinder: Unsynchronisierter Datenaustauschstellt die Rechnerkernbelegung bei einemunsynchronisierten Datenaustausch zwischen der M-Task und der Bus-Management-Task über den gemein-samen DatenspeicherInformationsbusdar. Die maximal zulässige Reaktionszeiten t

Zmaxder Tasks ist durch

die jeweilige Prozesszeit tP

gegeben. Die Verarbeitungszeiten tV

und die Prozesszeiten finden sich in derfolgenden TabelleExemplarische 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üraber viel Rechenzeit benötigende Task zur Erfassung meteorologischer Meßdaten die niedrigste Priorität.Zum Zeitpunktt=90 ms greifen beide Tasks auf den Informationsbus zu. Ein konsistenter Zustand kann hiernicht 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 vonden 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ßtkritischer Abschnitt (criticalsection).

• Greifen zwei oder mehr Threads bzw. Prozesse auf dieselben Daten zu, kann es zu einer sogenanntenrace conditionkommen. Bei einer race condition hängt das Ergebnis des Zugriffs vom Prozessfortschrittab.

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

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

147


• 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 Prozessschlafendgelegt, 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 ansonstendurch Test-And-Set-Befehle des Mikroprozessors realisiert.

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

148


10 20 30 40 50 60 70 80 90 100 t110 120

10 20 30 40 50 60 70 80 90 100 t110 120

10 20 30 40 50 60 70 80 90 100 t110 120

t

1

0

−1

M−Task = Task zur Erfassung meteorologischer DatenB−Task = Bus−Management−Task

RK = RechnerkernbelegungS = Informationsbus−Semaphor

RK

B−Task

M−Task

S

der P−Operationblockiert aber direkt anB−Task wird lauffähig,

Abbildung 5-5. Mars-Pathfinder: Rechnerkernbelegung bei Verwendung eines Semaphor

Verwenden die Tasks im Beispiel des Mars-Pathfinder ein Semaphor, um den Zugriff auf denInformationsbus zu synchronisieren, gibt es keine Zugriffskonflikte mehr (siehe AbbildungMars-Pathfinder: Rechnerkernbelegung bei Verwendung eines Semaphor). Der Wert »1« des SemaphorS

bedeutet, dass das geschützte Betriebsmittel „frei“ ist, der Wert »0« bedeutet, dass das Betriebsmittelgerade verwendet wird. Hat das Semaphor einen Wert kleiner »0«, bedeutet dieses, dass mindestens eineTask auf das Betriebsmittel wartet. Dank Semaphor und ohne Betrachtung der Z-Task gibt es somit keineZugriffskonflikte 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“ beimMars-Pathfinder. Es mußte also noch etwas anderes an Board des Raumfahrzeuges aufgetreten sein, das zuden 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 Rechenzeitanforderungund ihrer Wichtigkeit die mittlere

149


Priorität bekam.

10 20 30 40 50 60 70 80 90 100 t110 120

10 20 30 40 50 60 70 80 90 100 t110 120

B−Task

10 20 30 40 50 60 70 80 90 100 t110 120

10 20 30 40 50 60 70 80 90 100 t110 120

t

1

0

−1

� ��

� � ��

� ��

M−Task

Z−Task

RK

Deadline Verletzung

S

B−Task blockiertM−Task blockiert

M−Task = Task zur Erfassung meteorologischer DatenZ−Task = Task zur ZustandserfassungB−Task = Bus−Management−Task


Abbildung 5-6. Deadlineverletzung beim Mars-Pathfinder

Abbildung Deadlineverletzung beim Mars-Pathfindergibt das von Mike Jones beschriebene Problem inForm der Rechnerkernbelegung beim Mars-Pathfinder wieder.

Abbildung Deadlineverletzung beim Mars-Pathfinder zeigt die Rechnerkernbelgung unterBerücksichtigung der Z-Task. Die M-Task und die Bus-Management-Task greifen über denSemaphor (Mutex) auf den Informationsbus zu. Das geht solange gut, solange nicht die Z-Task dannrechenbereit wird, wenn gerade Task M den Informationsbus belegt hat. Stellt dann die höherprioreBus-Management-Task eine Anforderung, gelangt diese nicht in den Zustandlauffähig , da sie auf dasBetriebsmittel Informationsbus warten muß. Task Z kann also zuende rechnen, danach die M-Task undschließ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 <[email protected]>

Sonntag, Dezember 07, 1997 6:47 PM

Die Mars-Pathfinder-Mission wurde in den ersten Tagen nach der Landungauf dem Marsboden am 4ten Juli 1997 als weitgehend “probleml os”eingestuft. Die Erfolge schlossen die unkonventionelle “L andung” ein-- das Fallenlassen auf dem Marsboden geschützt durch Lufts äcke, Freigabedes Sojourner Fahrzeugs und die Aufnahme und Übermittlung v oluminöserDaten zurück zur Erde, einschließlich der Panoramabilder, die einderartiger Hit auf dem Web waren. Aber ein paar Tage später, k urz nachdem

150


der Pathfinder begann, meteorologische Daten zu erfassen, wurden auf demSpacecraft richtige System-Resets festgestellt, die jewe ils einenDatenverlust bedeuteten. In der Presse wurden diese Fehler mit den Worten“Software Glitches” und “der Computer versuchte zu viele Di nge aufeinmal zu tun” wiedergegeben.

Diese Woche hörte ich auf dem IEEE Realzeitsystem-Symposiu m einefaszinierende Keynote von David Wilnder, dem Entwicklungs leiter vonWind River Systems. Wind River macht VxWorks, den Echtzeitk ern, der beider Mars-Pathfinder-Mission Verwendung gefunden hat. In s einer Redeerklärte er im Detail die aktuellen Software-Probleme, die die Resets aufdem Spacecraft auslösten, wie sie diagnostiziert und gelös t wurden. Ichmöchte die Geschichte mit Ihnen allen teilen.

VxWorks benutzt ein preemptives Prioritätenscheduling üb er Threads. Tasksauf dem Pathfinder Spacecraft werden als Threads mit Priori tätenausgeführt, wobei die Prioritäten in der gewohnten Weise ve rteilt wurden,nämlich die jeweilige Wichtigkeit der Task widerspiegelnd .

Pathfinder besitzt einen “Informations-Bus”, den man sich als gemeinsamenSpeicher zum Austausch von Informationen zwischen verschi edenenKomponenten des Spacecrafts vorstellen kann. Eine Bus-Man agement-Taskläuft häufig mit hoher Priorität, um bestimmte Arten von Dat en in und ausdem Informations-Bus zu schaufeln. Der Zugriff auf den Bus w ird durchgegenseitigen Ausschluß gesichert (Mutex).

Die Task, mit der meteorologische Daten aufgenommen werden ,läuft als ein seltener,niederpriorer Thread und verwendet den Informations-Bus u m Daten zuverbreiten. Um die Daten zu verbreiten, setzt die Task den Mu tex, schreibtauf den Bus und gibt den Mutex wieder frei. Wird aufgrund eine sInterrupts der Informations-Bus-Thread gescheduled, und versucht dieserdaraufhin den gleichen Mutex zu setzen, um diepublizierten Daten zu lesen, endet der Versuch damit, dass d er(Informations-Bus-) Thread amMutex blockiert wird und solange wartet, bis der Thread zur A ufnahme dermeteorologischen Daten den Mutex wieder freigibt. Das Spac ecraft enthältzusätzlich eine Task mit mittlerer Priorität.

Die meiste Zeit über hat diese Kombination gut funktioniert . Allerdingswar es sehr selten möglich, dass ein Interrupt auftrat, der d ieTask mit mittlerer Priorität genau in dem kurzen Zeitinterv all 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 Kommuni kationstask- hat sie doch schließlich höhere Priorität als die Meteorol ogie-Task -selbige an der Bearbeitung und verhindert folglich damit, d ass die blockierteInformations-Bus-Task die CPU zugeteilt bekommt.Nachdem eine Weile vergangen ist schlägt ein Watchdog-Time r zu, dererkennt, dass die Informations-Bus-Task seit geraumer Zei t nicht mehraktiviert wurde, bemerkt damit, dass irgendetwas dramatis ch falsch geht undinitiiert den System-Reset.

Dies Szenario ist der klassische Fall von Prioritätsinvers ion.

...

151


t1 t2 t3 t4 t5

t1

t2

t3

t5

t4

TaskC

B

A

Task B (mit höherer Priorität)wird rechenbereitTask C (mit der höchsten Priorität) wird rechenbereit

Task B hat von den rechenbereiten Prozessen die höchste Priorität

P(X)

P(X)

Task A belegt die Ressource X

Task C versucht die Ressource X zu belegen und wird schlafen gelegt

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 Bearbeitungder 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 (sieheAbbildungPrioritäten und Synchronisation).

t1 t2 t3 t4

t1

t2

t3

t4

t5

t5

t4

TaskC

B

A

Task B (mit höherer Priorität)wird rechenbereitTask C (mit der höchsten Priorität) wird rechenbereit

P(X)

V(X)P(X)

V(X)

Task A erbt die Priorität von Task C und wird rechenbereitTask A gibt X wieder frei und bekommt die ursprüngliche Priorität

Task A belegt die Ressource X

Task C versucht die Ressource X zu belegen und wird schlafen gelegt

Abbildung 5-8. Prioritätsinversion

Das angesprochene Problem wird über die Methode derPrioritä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 J

Omit niedrigerer Priorität gehalten wird, dann wird die Priorität von J

Oauf die

Priorität von Job JR

angehoben. Sobald der Job JO

das Mutex wieder freigibt, bekommt er seine initialePriorität zurück.

152


Die Prioritätsvererbung ist transitiv. Falls der Job JO

bereits die Priorität von JR

geerbt hat und ein weitererJob J

S, dessen Priorität größer als die von J

Rist, ankommt, erbt J

Odir Priorität von J

S.

Gibt JO

die Ressource wieder frei, erhält JO

seine ursprüngliche Priorität zurück. Die Ressource selbst wirddem anfordernden Prozess mit der höchsten Priorität zugeteilt (im Beispiel also J

S).

Mit Hilfe dieses Protokolls lassen sich sehr viele Problemelösen, insbesondere wenn die Jobs nur um eineRessource konkurrieren. Es gilt allerdings zu beachten, dass die Transitivität des Protokolls nicht bei allenImplementierungen gesichert ist, die Implementierungen können sich also bezüglich ihres Verhaltens imDetail 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. Unterschiedeaber 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 erebenfalls 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. Gesichertist 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. Nachder Aktivierung des Protokolls kam es zu keinen unvorgesehenen Systemresets mehr.

10 20 30 40 50 60 70 80 90 100 t110 120

10 20 30 40 50 60 70 80 90 100 t110 120

B−Task

10 20 30 40 50 60 70 80 90 100 t110 120

10 20 30 40 50 60 70 80 90 100 t110 120

t

1

0

−1

� ��

� � ��

M−Task

Z−Task

RK

Prioritätsvererbung

M−Task = Task zur Erfassung meteorologischer DatenZ−Task = Task zur ZustandserfassungB−Task = Bus−Management−Task


S

B−Task blockiertM−Task blockiert

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


5.2.1.1.3. Deadlock

V(S1)V(S2)

P(S2)

P(S1)

V(S2)V(S1)

P(S2)

P(S1)

Task A Task B

Deadlock

S1 ist durch Task Ablockiert, S2 durchTask B

Abbildung 5-10. Deadlock

Durch critical sections (gegenseitigem Ausschluß) kann esleicht zu Verklemmungen, den sogenanntenDeadlockskommen. Muß eine Task beispielsweise zwei Datenstrukturenmanipulieren, die durch zwei un-abhängige Semaphore geschützt sind, und eine zweite Task muß das gleiche tun, nur dass sie die Semaphorein 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 dieAnforderung 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 alleRessourcenanforderungen erfüllen kann. Es kann zu keinem Deadlock kommen. Das System gerät dagegenin einen “unsicheren” Zustand bezüglich Verklemmungen, wenn durch die Anforderung der Task nichtwenigstens eine Task existiert, deren Anforderungen nichtmehr erfüllt werden kann.

154


Zur Überprüfung, ob ein System zu einem Zeitpunkt deadlock-sicher ist, kann man folgenden Algorithmusverwenden:

1. Folgende Informationen müssen vorliegen:

• Betriebsmittel-Vektor (gibt an, wieviele Betriebsmittelvorhanden 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 denmaximalen Anforderungen für jede Task. Die Anforderungsmatrix gibt also an, wieviele Betriebsmitteleine 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 AnforderungsmatrixM keine Task Tigibt, bei der alle Anforderungen erfüllt werden

können, ist das System in einem unsicheren Zustand bezüglich deadlocks und die aktuelle Anforderungeines Prozesses darf nicht erfüllt werden.

5. Wenn es in der AnforderungsmatrixM eine Task Tigibt, 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 ausder Tabelle der belegten Betriebsmittelgelö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 maximalenAnforderungen 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 R

gesmehrfach 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


Die einzelnen Tasks stellen maximal die folgenden AnforderungenM:

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 aufaddiertund 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 AnforderungsmatrixM 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 U

freeaufaddiert. Aus der Belegungsmatrix wird die Task T1 gelöscht.

A B C

5 3 2

156


4. Mit dem neuen Belegungsvektor lassen sich entweder die Task T3 oder T4 zuende rechnen (sieheAnforderungsmatrix).Wieder wird eine Task ausgewählt, hier T4 (0, 0, 2 ). Damit ergibt sich ein neuerBetriebsmittel-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 existierendenTasks 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 neueBetriebsmittel-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, istdas 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, wirddas Mutex gesperrt (locked) und dem aufrufenden Thread zugehörig erklärt. In diesem Falle returniertdie Funktion direkt. Sollte der kritische Abschnitt gesperrt sein, wird der aufrufende Thread solangein 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 Deadlockkommen. Um dies zu verhindern läßt sich ein Mutex so konfigurieren, dass es entweder in diesem Fallden FehlercodeEDEADLKreturniert (ein „error checking mutex“ oder den Mehrfachzugriff erlaubt (ein„recursive mutex“).

157


int pthread_mutex_trylock( pthread_mutex_t * mutex );

Diese Funktion verhält sich genauso wie die Funktionpthread_mutex_lockmit der Ausnahme, dass sienicht blockiert, falls der kritische Abschnitt nicht betreten werden kann. In diesem Fall returniert dieFunktionEBUSY.

int pthread_mutex_init( pthread_mutex_t * mutex , const pthread_mutexattr_t * mutexattr );

Diese Funktion initalisiert ein Mutexmutex gemäß der Angaben im Parametermutexattr. Istmutexattr 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, derbereits 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 jedochunkritisch. Aus dieser Erkenntnis heraus bieten viele Systeme sogenannte Schreib-/Lese-Locks an. Dassind Semaphore, die parallele Lesezugriffe erlauben, abereinem schreibenden Job einen exklusiven Zugriffermöglichen.

Bei der Anforderung des Mutex muss der Rechenprozess mitteilen, ob er den kritischen Abschnitt nur zumLesen, 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 gibtzur 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 gibtzur 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, derschreibend zugreift:

Der anfragende Rechenprozess wird blockiert (unabhängig davon, ob er lesen oder schreiben möchte).

158


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 Jobskommt.

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 zweioder 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 undSpinlocks.

Unterbrechungssperre.Hierbei werden die Interrupts auf einem System für die Zeit des Zugriffs auf denkritischen Abschnitt gesperrt. Um die Latenzzeiten kurz zuhalten, darf der Zugriff selbst nur kurz dauern.Bei modernen Betriebssystemen ist diese Methode nur für Zugriffe innerhalb des Betriebssystemkerns, alsobeispielsweise 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 Abschnittbetreten werden darf oder nicht. Ist der kritische Abschnitt bereits besetzt, wartet die zugreifende Einheitaktiv solange, bis der kritische Abschnitt wieder freigegeben worden ist.

Damit ergeben sich für die vorgestellten drei Methoden zum gegenseitigenAusschluß bei einem kritischen Abschnitt unterschiedliche Einsatzfelder (AbbildungEinsatzmöglichkeiten unterschiedlicher Synchronisationsmethoden). Die Unterbrechungssperre stehtnormalen Applikationen nicht zur Verfügung. Bei Einprozessorsystemen (UP=Uni-Processor) wird selbigeim Betriebssystemkerns eingesetzt. Bei SMP lassen sich zwar die Interrupts auf allen Prozessoren sperren,bevor aber auf den kritischen Abschnitt zugegriffen werdenkann ist sicherzustellen, dass nicht zufälligzwei Prozessoren die ISR bearbeiten.

Spinlocks werden ebenfalls im Kernel eingesetzt. Sie realisieren ein aktives Warten und lassen sich ausdiesem Grunde nur in einer SMP-Umgebung verwenden.

Das Semaphor schließlich ist für den gegenseitigen Ausschluß auf Applikationsebene gedacht. Es ist sowohlfür UP- als auch für SMP-Umgebungen verwendbar. Der Einsatzim Betriebssystemkern ist möglich, abernur dann, wenn der kritische Abschnitt nicht von einer ISR betreten werden soll. In diesem Fall müsste mannä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


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 Eventsbezü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 einenMeß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.

datenspeicher

A

B

C

W

S

P(S)

P(S)V(S)

read

read

read

P(S)

P(S)

V(S)V(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 (criticalsection). Dieser ist also mittels eines Semaphors zu schützen (in diesem Abschnitt konkurrieren alle 4 Tasksmiteinander). Der Aufbau der Tasks, wie ihn BildTask A,B und C: Synchronisation durch ein Semaphorund Bild Task W: Synchronisation durch ein Semaphorzeigen, berücksichtigt aber nicht, dass nur eine derTasks A, B oder C zugreifen darf, wenn der Datenspeicher durch W vorher geleert wurde und berücksichtigtebenso wenig, dass Task W nicht mehrfach hintereinander zugreifen darf, ohne dass der Speicher durch eineder drei neu beschrieben wurde. Wir haben - trotz Verwendungdes Semaphor - eine race condition bzw.eine Deadlock-Situation.

...while( TRUE ) {

read(kanal_A, buffer, sizeof(buffer) );P(S); // enter critical sectionwrite( 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 sectionread( datenspeicher, buffer, sizeof(buffer) );V(S); // leave critical sectionWorkOnData( buffer );

}

160


...

Abbildung 5-13. Task W: Synchronisation durch ein Semaphor

Es reicht also nicht aus, nur den eigentlichen Zugriff als solches auf das gemeinsame Betriebsmittel mittelseines Semaphor zu schützen. Vielmehr ist noch ein weiteres Synchronisationsmittel notwendig: ein Event.

Definition: Ein Event ist ein Synchronisationselement, welches Rechenprozessen erlaubt solange denProzessor frei zu geben, bis eine bestimmte Bedingung erfüllt ist. Die Basisoperationen des Eventssind:

• warten auf das Event und

• senden (setzen) des Events.

Da Events nicht zwischengespeichert werden, treten Events im Regelfall nur in Kombination mit einemSemaphor 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 Wselbigen entleert hat, wird die Operation “kritischen Abschnitt betreten” und “kritischen Abschnitt verlas-sen” auf unterschiedliche Tasks verteilt. Die Tasks A, B undC betreten (durch Aufruf der P-Operation)den kritischen Abschnitt, geben aber selber den kritischenAbschnitt niemals frei. Diese Freigabe führt jetztTask W durch. Task W muß jetzt nur noch derartig synchronisiert werden, dass sie die Daten dann aus demSpeicher holt, wenn diese auch vorhanden sind. Dazu sendet Task A, B oder C ein Event, auf welches TaskW wartet (siehe AbbildungMeßwerterfassung: Synchronisation mit Events).

datenspeicher

A

B

C

W

S

P(S)

P(S)V(S)

read

read

read

P(S)

Event

Event

Event

Abbildung 5-14. Meßwerterfassung: Synchronisation mit Events

161


...read(kanal_A, buffer, sizeof(buffer) );P(S); // enter critical sectionwrite( 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 sectionWorkOnData( 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 imeigentlichen 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 demdie Task W diesen Meßwert herausgeholt hat.

t1

� ��

��

� � ��

� ��

� � � ��

� ��

A

A

B

B

C

C

A

W W

SendEvent

WorkOnDataWaitForEvent

A blockiert am Semaphor

Semaphor von W freigegeben

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, derdabei verloren gehen könnte (siehe AbbildungRace Condition bei Verwendung von Events). Bedingt durchdie Programmlaufzeiten und die Prioritätenverteilung (Task W hat niedrigere Priorität als Task A, B undC), wird Task A zum Zeitpunkt t

1zunä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) kurzzu halten, gibt Task W den kritischen Abschnitt sofort frei,wenn er nicht mehr benötigt wird. Dadurchbekommt Task A die CPU (sie wartete ja auf den Semaphor), schreibt die Daten in den Datenspeicher undschickt das Event. Erst danach kommt Task W wieder an die Reihe, bearbeitet die Daten von Task C zuEnde und wartet erst jetzt auf das Ereignis, welches schon zueinem früheren Zeitpunkt verschickt wurde.

Die Hinzunahme der FunktionWorkOnData() 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


Warten auf das Ereignis die Task, die das Event schickt, gescheduled werden. Damit würde das Ereignis inseltenen 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 istauch der Grund, warum an der Posix-Schnittstelle Events grundsätzlich mit einem Semaphor verbundensind.

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 Wartenread( datenspeicher, buffer, sizeof(buffer) );WorkOnData( buffer );

}...

Da auf ein Event auch mehrere Tasks warten können, gibt es sowohl eine Funktion, die genau eine Taskaufweckt, 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 wirdgenau eine Task aufgeweckt, die auf dasEreignis 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 structtimespec * abstime );

163


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 (ähnlicheiner 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 Adresse0) innerhalb des Betriebssystems dazu, dem Prozess ein Segmentation-Fault-Signal zu schicken, welchesder Prozess abfangen könnte. In der zugehörigen Segmentation-Fault-ISR würden alle notwendigen Datennoch gespeichert. Erst danach würde die Applikation beendet werden.

Die Unterschiede zwischen Events und Signals sind in Tabelle Unterschiede zwischen Events und Signalsdargestellt.

Tabelle 5-3. Unterschiede zwischen Events und Signals

Signals Events

Signals kommen asynchron zum Programmablaufund werden asynchron verarbeitet.

Events kommen synchron zum Programmablaufund werden synchron verarbeitet.

Charakter einer Interrupt-Service-Routine(Software-Interrupt).

Rendezvous-Charakter

WarnungEin Signal führt - wenn nicht anders konfiguriert - zum sofortigen Abbruch eines geradeaktiven Systemcalls. Werden im Rahmen einer Applikation Signals verwendet bzw. abge-fangen, muß jeder Systemcall daraufhin überprüft werden, ob selbiger durch ein Signalunterbrochen 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 einesspezifischen Signals durchführt.

Mit dieser Funktion wird auch die Adresse der Interrupt-Service-Routine übergeben, die bei Erhalt desSignals vom Betriebssystem aufgerufen wird.

164


int kill( pid_t pid , int sig );

Dieser Systemcall wird dazu verwendet, einer Task oder einer Task-Gruppe ein beliebiges Signal zuschicken.

5.2.2. Datenfluß/Inter-Prozess-KommunikationAls 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 zuTask 2 transportiert und gepuffert (imGegensatz 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 einesgemeinsamen Speicherbereichs im Falle vonThreads ist trivial. Wollen mehrere Rechenprozesse jedocheinen gemeinsamen Speicher nutzen, müssensie diesen vom Betriebssystem anfordern. Ähnlich wie beim Dual-Port-RAM, bei dem allerdings unter-schiedliche Prozessoren zugreifen, kann die Speicheradresse des gemeinsamen Speicherbereichs von Taskzu Task unterschiedlich sein. Deshalb ist es auch hier wichtig, Pointer innerhalb von Datenstrukturen relativzum Beginn (oder Ende) des Speicherbereichs anzugeben.

5.2.2.3. Sockets

Die wichtigste Schnittstelle für Inter-Prozess-Kommunikation stellt die Socket-Schnittstelle dar. MittelsSockets können Daten zwischen Prozessen ausgetauscht werden, die auf unterschiedlichen Rechnern loka-lisiert sind (verteiltes System).

Die Socketschnittstelle bietet Zugriff zur tcp/ip- und zurudp-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


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 writeread( 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 persocket -Funktion einen beliebigen Socket (Ressource) im System, wobei der Socket über eine Nummer identifiziertwird. 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 sogenanntenwell known sockets.

Hat der Server einen Socket alloziert, muß er ihm eine bekannte Socketnummer zuweisen (z.B. 80 bei http).Dies geschieht mit der Funktionbind (siehe BildBasisstruktur einer Socket-Serverapplikation). Über einenSocket kann der Server gleichzeitig mehrere Clients bedienen. Über die Funktionlisten kann er dabeiparametrieren, wieviele derartige Clients er maximal bedienen möchte (BildSocket-Serverprogramm). Eineinzelner Port auf einem Rechner kann aus dem Grund mehrere Verbindungen (Clients) bedienen (undunterscheiden), 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 aufVerbindungswünsche warten. Dieses Warten wird über denaccept Aufruf realisiert. Accept liefert, wennauf dem bekannten Socket ein Verbindungswunsch kommt, einen neuenSocket 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 demaccept ) mittels fork einen eigenen Prozess. Der zurückgegebene Socket (im BildConnectionSocket ) 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


}


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, &c ount );if( ConnectionSocket >= 0 ) {

printf(”connection established ...\n”);while( count=read(ConnectionSocket,buffer, sizeof(buf fer) )) {

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 );

...

Zugriff auf die Verbindung über read und write

write( sd, Nachricht, strlen(Nachricht)+1 );

connect( sd, &destination, sizeof(destination) );

destination.sin_family = PF_INET;

destination.sin_port = htons( Portnummer ); //Zielport spezifizieren

inet_aton( "192.168.12.12", &destination.sin_addr ); //Zieladresse spez.

Abbildung 5-20. Basisstruktur einer Socket-Clientapplikation

Der Verbindungsaufbau über Sockets auf der Client-Seite ist nicht so kompliziert (siehe BildBasisstruktur einer Socket-Clientapplikation). Der Client alloziert sich - wie der Server auch - persocket

167


Funktion die Socket-Ressource. Da der Client ja keine Verbindung entgegennehmen möchte, muß dieserSocket auch nicht an eine bestimmte Nummer gebunden werden.Der Client tätigt nur noch einenconnect

Aufruf, um sich mit dem Remote-Rechner zu verbinden. Er verwendet den vom Socket-Aufruf returniertenSocketdeskriptor/Filedeskriptor direkt (BildSocket-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 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. RealeServerprogrammewerden aber aufgrund notwendiger Flexibilität deutlich komplexer. So programmiert manim Regelfall weder die IP-Adresse noch die Portadresse festin 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 weitererBibliotheksfunktionen.

Die Schnittstelle unterstützt nicht nur die Kommunikationüber tcp/ip, sondern auch über udp. Bei udphandelt es sich um einen verbindungslosen Dienst. Der Server muß also keinaccept aufrufen, sondern

168


kann direkt vom Socket (Bind-Socket) lesen. Um hier Informationen über den Absender zu erhalten, gibtes 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 „littleendian“-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ürshort 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 konvertiertund beim Empfang wieder rückkonvertiert werden. Folgende Technologien unterstützen den Programmiererbei 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 deneigentlichen Datentransport.

5.2.3. Time triggered versus Event triggeredEin 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 sollenaufgrund 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 mitder Regelung dieses einen technischen Prozes-ses beschäftigt. Daher ist ein Kontext-Wechsel nicht notwendig, der zugehörige Rechenprozesspollt ständigden technischen Prozess, ob dieser die Anforderung stellt oder nicht. Bei der gegebenen Verarbeitungszeitvon t

V=8ms dürfen die Ereignisse einen minimalen Abstand vont

Pmin=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 Speicherzelleunnü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


Verhalten läßt sich abschalten, wenn bei der Variablendeklaration das Schlüsselwortvolatile verwendetwird. Dieses bewirkt, dass der Compiler die Optimierung fürdiese 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,%alje .L5leaveret

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 gegebenenCode jedoch nie verändern kann, wird das Programm in dieser Schleife hängen bleiben.

Bei Verwendung des Schlüsselwortesvolatile aber, optimiert der Compiler die Zugriffe über den Pointernicht.

CheckStatus( char volatile *RegisterAdr ){

while( *RegisterAdr==0 ) // Wait for completness (status!= 0);

}

.L5:movb (%edx),%altestb %al,%alje .L5leaveret

5.2.3.2. Time-Triggered

Kommen in der beschriebenen Aufgabenstellung die Ereignisse nicht mit Maximalfrequenz (im Abstandvon 8ms), könnte die vorhandene Rechenleistung auch für andere Aufgaben genutzt werden. Dazu wirdein Laufzeit- oder Betriebssystem eingesetzt. NotwendigeVoraussetzungen sind wieder Preemption undPriorisierung. Durch die Verwendung des Laufzeit- oder Betriebssystems müssen folgende Zeiten zusätzlichbetrachtet werden:

• SchedulingtS=900µs

• Kontext SwitchtK=100µs

Mit dieser Lösung könnten bei 100%iger Auslastung pro Sekunde 111 Anforderungen bearbeitet werden:

r = 1 / (tV+t

S+t

K)

170


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 einerzeitgesteuerten Applikation (time triggered). Die Peripherie agiert beim Time-Triggered-Betrieb also reinpassiv.

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.

ttot tV��

��

Sende Ereignis in 100 ms

while( True )while( True )

Bearbeite Aufgabe

Lese Wert einBearbeite Aufgabe

Lese Wert ein

100 ms

warten verarbeiten

Warte (100 ms)

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-t

V), zwischen

zwei Aufrufen der Task muß hardwareunabhängig realisiert sein. Vor allem in früheren Zeiten wurdedie 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 wirdbeispielsweise die Wartebedingung (Setzen des Timers) gleich zu Beginn festgelegt.

Dazu ein Beispiel (BildWarten): Angenommen, von einem technischen Prozess soll alle 100 ms einMeßwert aufgenommen und verarbeitet werden. Der Ansatz, ineiner Schleife den Wert einzulesen, zuverarbeiten 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 vonvielen unterschiedlichen Faktoren abhängt. Daher muß man das “Warten” aufspalten. Zunächst wirdman einen Auftrag an das Betriebssystem absetzen, dass dieses der Task nach den 100 ms ein Ereignisschicken soll (Aufruf mit explizitem Warten). Danach wird der Meßwert erfaßt und verarbeitet. Zuletztlegt sich die Task auf das Zeitereignis schlafen.

171


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 einerBusy Loopbzw.einer aktiven Warteschleife. Busy Loops sind in jedem Fall zu vermeiden, und wenn dies nicht möglichist (wie oben dargestellt), so doch wenigstens hardwareunabhängig zu realisieren. Anstelle von BusyLoops können die Systemcalls:wait , sleep , select oderpoll 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 anderenTasks oder vom Betriebssystem (z.B. Gerätetreiber) generiert werden. Ereignisse werden dabei synchronzum Programmlauf bearbeitet, Interrupts asynchron. Im Falle des skizzierten technischen Prozesses könntebeispielsweise jedesmal dann ein Interrupt von der Hardware generiert werden, wenn der technische Prozesseine Anforderung an die Realzeitsteuerung stellt.

Dadurch kommt als weitere zu betrachtende Zeit die Zeit der Interruptanalyse tIntr

hinzu. Ist im BeispieltIntr

=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. Beieiner zeitgesteuerten Lösung und Verwendung der optimalenAbtastzeit von 10ms wäre dagegen erst eineAuslastung 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ähltenAbtastintervall und unabhängig vom Bedarfsfall.

Event-Triggered Die Auslastung ist abhängig vom Bedarfsfall.

5.2.4. ProgrammierstilSowohl bei der Konstruktion des Taskgebildes als auch bei der Auskodierung der einzelnen Tasks ist imUmfeld 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 Tasksmit niedriger Priorität (Prioritätsinversion).

• Die Kommunikation zwischen Tasks ist sorgfältig zu entwerfen. Für die Kommunikation innerhalb einesRechners sollte vorzugsweise ein gemeinsamer Speicher verwendet werden, für die Kommunikation vonTasks innerhalb verteilter Systeme Sockets.

• Code und Daten sollten für kritische Realzeitprozesse immer im Hauptspeicher stehen (StichwortMemory-Locking).

172


• Zeitaufwendige Aufgaben sollten in eigene Tasks verlagertwerden.

• Ein Amok-laufender Thread kann mehr Schaden anrichten, alsein Amok-laufender Rechenprozess. Da-her sollten insbesondere in sicherheitskritischen Anwendungen Rechenprozesse den Threads vorgezogenwerden.

Kodierung der Tasks:

• Rekursive Prozeduren sollten vermieden werden.

In Realzeitsystemen sind Rekursionen zu vermeiden, da Rekursionen zu hohem Speicherbedarf auf demStack führen kann. Prinzipiell sind alle rekursiven Algorithmen auf iterative Algorithmen überführ-bar. In BeispielRekursive und Iterative Berechnung der Fibonacci-Zahlenist die iterative Lösung eineszunä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 folgendenVorschrift [Wirth 1983]:

fib(n+1) = fib(n) + fib(n-1) für n > 0fib(1) = 1fib(0) = 0

Da bei der rekursiven Lösung jeder Aufruf mitn > 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 zugebrauchen. Demgegenüber werden für die iterative Lösungn-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), f ib0=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 i;

for( i=0; i <15; i++ )printf( "%d ", fibonacci_rekursiv(i) );

printf("\n");

173


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 nacheiner maximalen Anzahl von Durchläufenerfolgen (n

max). 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 eventuellnotwendige Fehlerbehandlung kann durchgeführt werden.

• Datenstrukturen sollten statisch definiert werden und nicht erst zur Laufzeit dynamisch entstehen (führtzu undeterministischem Verhalten, außerdem existiert dasRisiko, dass der Speicher ausgeht).

• Bei der Verwendung von Bibliotheksfunktionen ist darauf zuachten, dass auch diese realzeitfähig sind.

• Rückgabewerte von Funktionen sind grundsätzlich in ihrem kompletten Definitionsbereich auszuwerten.

5.3. Schritthaltende Programmierung,Echtzeitprogrammierung

Das KapitelSchritthaltende Verarbeitung und Echtzeitbetriebhat die Anforderungen an Echtzeitsystemeaufgestellt und den Nachweis der Einhaltung behandelt. In diesem Kapitel werden programmiertechnische

174


Aspekte für die Realisierung einer Echtzeitsoftware behandelt.

PufferEingabewerte

verarbeiten

ausgeben

einlesen

while( 1 )

(warten)

while( 1 )

verarbeiten

abspeichern

Event schicken

while( 1 )

ausgeben

(warten)

while( 1 )

einlesen

abspeichern

Event schicken

PufferAusgabewerte

einlesen verarbeiten ausgebenverarbeiten

Eingabe Ausgabe

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 Eingabegetriggert wird, sind bei den zeitgesteuertenSystemen 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 sollenmit 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 rIan, werden mit einer Verarbei-

tungsrate rV

verarbeitet und Ausgaben werden mit einer Rate rO

ausgegeben. Im Regelfall kann man davonausgehen, dass r

Iungleich r

Vund ungleich r

Oist. Damit ist die Ausgabe nicht synchron zur Eingabe. Es

unterscheiden sich aber nicht nur die Raten, sondern auch die zugehörigen Phasenlagen. Problematisch istdies insbesondere zwischen Ein- und Ausgabe bzw. zwischen Soll- und Istwerten.

tS

tSfS= 1 f = 1

I tI

tI

SollIst

φ

Phasenverschiebung

Abbildung 5-24. Phasen- und Frequenzunterschiede zwischen Soll- und Istwerten

175


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 genutztwerden, 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 inden 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 werdenunsynchronisiert übertragen und müssen auf der Empfangsseite wieder zu einem kontinuierlichen Aus-gangssignal zusammengesetzt werden.

Sind Ein- und Ausgaben nicht zeitsynchron, müssenAnnahmenüber den Prozesszustand zwischen zwei Er-eignissen getroffen werden. Im BeispielVisualisierung einer Modellbahn (I)könnte die Annahme getroffenwerden, dass das Fahrzeug sich zwischen den beiden Positionen (der zuletzt gemeldeten und der kommen-den) mit einer konstanten Geschwindigkeit bewegt. Diese Annahmen werden in einProzessmodell(Modelldes technischen Prozesses) implementiert. Im genannten Beispiel ist das zugehörige Prozessmodell durchdie Formelv=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 zukommen.

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 derFehler 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) Ereignisseausgelöst werden. Eine aktuelle Uhrzeit darfbeispielsweise in einem System nicht einfach eingestellt werden, weil durch den bei der Einstellung stattfin-denden Zeitsprung möglicherweise Cronjobs (zu bestimmtenZeitpunkten aufzurufende Tasks) übersprun-gen werden. Wird bei der Visualisierung die Position des Fahrzeugs sprunghaft verändert, ergibt sich fürden 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


Die Größe dieses Korrekturwertes und die Rate, mit der dieseWerte ausgegeben werden, ergeben sichdurch:

1. Die Größe der Abweichung.

2. Triggerpunkte für andere Systemteile (Beispiel NTP und Cronjobs).

3. Zur Verfügung stehenden Rechenzeit.

∆s = 1mt0 t1 t2

1 2 3

1.25msv =real

1msv =modell

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 diereale Position ungleich der Position, die gerade angezeigtwird, wird das Fahrzeug nicht auf die neue Posi-tion „gebeamt“ (sprunghafte Positionsanpassung). Stattdessen wird die Geschwindigkeit, mit der sich dasFahrzeug 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 wiederauszugleichen.

Insbesondere der Korrekturwert wird nur zeitlich befristet eingesetzt. Ist der Fehler ausgeglichen, kann mitdem normalen Wert weitergearbeitet werden.

Das Prozessmodell der Modellbahn sei so parametriert, dasseine Geschwindigkeit von v=1m/s angenom-men wird. Wird der Visualisierungstask das Überfahren des Sensors 1 zum Zeitpunkt t

0=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 Zeitpunktt1=0.8s überfahren( siehe BildProzessnachfü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


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 dieVisualisierung bis zum nächsten Sensor mit einer korrigierten Geschwindigkeit gearbeitet:

vkorrigiert

=1.2m/0.8s=1.5m/s

Gutwert + Korrekturwert

Modellparameter

Ausgaben

Extra−

polation

Modell

Ausgabe

Fehler−ausgleich

Eingabe

korrekturModell−

Abbildung 5-26. DFD einer zeitsynchronen Verarbeitungseinheit

Die zeitsynchrone Verarbeitung von Eingaben zu Ausgaben besteht damit aus den BlöckenExtrapolation,Modellkorrekturund Fehlerausgleich(siehe AbbildungDFD 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


Gutwert + Korrekturwert

ModellparameterModell

Eingaben

timer

Berechnung Ausgabe

Zeitpunkt + Ausgabewert

Ausgaben

Abbildung 5-27. Systemarchitektur einer zeitsynchronen Ausgabe

Da - wie bereits eingangs erwähnt - die Raten, mit denen Dateneingelesen, verarbeitet und ausgegebenwerden unterschiedlich sind, muß eine Entkopplung zwischen diesen Aufgaben vorgenommen werden.

Prinzipiell kann die Entkopplung zunächst durch die Ablageder Daten in Puffer vonstatten gehen (sieheAbbildungSystemarchitektur einer zeitsynchronen Ausgabe). Die in den Puffer abgelegten Werte benötigenQualitätsmerkmale wieGültigkeitundAlter (Zeitstempel bzw. bei der Ausgabe Zeitpunkt für die Ausgabe).

Die TeilaufgabenEinlesen, VerarbeitenundAusgebenkö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 Bedingungengewaretet werden:

• alle Eingabeereignisse

• alle Verarbeitungsereignisse

• alle Ausgabeereignisse.

Abhängig davon, zu welcher Gruppe ein Ereignis gehört, wirdin 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 Weisemö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 dieVisualisierung bis zum nächsten Synchronisationspunkt alle notwendigen Ausgabewerte berechnet und in

179


den Ausgabepuffer ablegt. Ist die Eingabe verarbeitet, wartet dieser Programmteil auf die Benachrichtigungbezüglich neuer Daten.

Bei der zeitsynchronen Verarbeitung werden mit jedem Takt neue Ausgabewerte berechnet.

Fußnoten1. Das P der P-Operation stammt aus dem holländischen und steht für passeeren

2. V leitet sich vom holländischenvrijgevenab

180

Kapitel 6. Echtzeitsysteme in sicherheitskritischenAnwendungen

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 undbestellen (eCommerce) ist es wichtig, dass der Webshop ständig verfügbar ist. Welche Maßnahmen kanner aber ergreifen, um eine möglichst hohe (durchgehende) Verfügbarkeit zu gewährleisten? Im einfachstenFall 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 istwieder 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 handeltein 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 verantwortlichist, wird er sofort den nächstgelegenen Flughafen anfliegen. Trotz Ausfall eines Steuerungssystems ist dasFlugzeug zwar noch voll flugfähig, der Ausfall allerdings des zweiten Rechners könnte katastrophale Folgenhaben.

Diese beiden Beispiele zeigen, dass man redundante Systemesowohl zur Steigerung der Verfügbarkeit, alsauch 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 31000 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 ersteMängel. Für die Fehlersuche, Ersatzteilbeschaffung und Reparatur benötigt der Student 1 Stunde. Danachläuft der Rechner weitere 96 Stunden problemlos, um abermals auszufallen. Diesmal dauert die Reparatur1.5 Stunden. Weitere 96 Stunden später fällt der Rechner erneut aus, ist aber nach bereits einer halbenStunden wieder einsatzbereit. Die Zeit bis zum nächsten Ausfall (TBF, Time Between Failure) beträgt dann72 Stunden, die Zeit zur Reparatur (TTR, Time To Repair) beträgt eine halbe Stunde. Insgesamt ergebensich ü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, MeanTime 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. Dazusetzt 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


v a a vv a

TBF

TTR

TBF

Zyklus 1 Zyklus 2 Zyklus 3

v = verfügbar TBF: Time Between FailureTTR: Time To Repaira = ausgefallen

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 Regelfallrepariert, damit das System wieder verfügbarwird. Die Zeit, während der das System ausgefallen ist, wirddaher auch als “Reparaturzeit” (TTR, TimeTo Repair) bezeichnet. Die Zeit, in der das System verfügbarist, 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 aufund bildet hiervon das arithmetische Mittel, kann man die durchschnittliche Verfügbarkeitsdauer (MTBF,Mean Time Between Failure) angeben. Das gleiche gilt für diemittlere Dauer der Unverfügbarkeit:

Gleichung 6-1. MTBF und MTTR

oo n1

nlim

oo n1

nlim

i=1Σn

TTRiMTTR =

i=1Σn

TBFiMTBF =

Möchte man die Wahrscheinlichkeit angeben, mit der sich dieKomponente 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 zurGesamtzeit (Beobachtungszeitraum) setzen,bzw. für die Dauerunverfügbarkeit die Ausfallzeiten in Beziehung zum Beobachtungszeitraum setzen. pund q lassen sich mathematisch auch über die MTBF und die MTTRdarstellen.

Gleichung 6-2. Dauerverfügbarkeit und Dauerunverfügbarkeit

p = MTTR + MTBF

MTBF

q = MTTRMTTR + MTBF

mit p + q = 1

(Verfügbarkeit)

(Unverfügbarkeit)

Die (im Mittel) erwartete Zahl von Ausfällen wird mitλ (Ausfallrate) beschrieben:

183


Gleichung 6-3. Ausfallrate

=MTBF

1λ

Zeitlich betrachtet sind die Ausfälle nicht gleichverteilt. Nach einer Reparatur ist die Wahrscheinlichkeitsehr 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ügbarkeitund Zeit gibt die GleichungVerfügbarkeit in Abhängigkeit von der Zeitan:

Gleichung 6-4. Verfügbarkeit in Abhängigkeit von der Zeit

p(t) = ρ

ρ + λ + λρ +e

−(λ+ρ)tλ

Bild Verfügbarkeitsfunktion [Färber 1994]stellt die Funktionp(t) für ausgewählte Reparatur- bzw. Aus-fallraten dar.

ρ=

λ+ρρ

=1

+11k

Dauerverfügbarkeit

ρ=0

ρ = k λ

t

p(t)

Abbildung 6-2. Verfügbarkeitsfunktion [Färber 1994]

Für eine gegebene Reparatur- und Ausfallrate ungleich Nullergibt sich die Dauerverfügbarkeit nach einementsprechend langen Zeitraum. Wird das System nicht reparariert (Reparaturrate=0), sinkt die Verfügbarkeitauf 0, ist die Reparaturzeit beliebig klein (0), ist das System ständig verfügbar.

184


t

qFrü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 giltvielmehr die sogenannte Badewannenkurve (BildBadewannenkurve [Färber94]). Ist ein System neu, gibtes 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 zuAusfällen.

ausgefallen

funktions−tüchtig

p(t)

q(t)

ρ λ

Abbildung 6-4. Systemzustand bezüglich der Funktionstüchtigkeit [Färber94]

Die bisherigen Betrachtungen gelten füreineKomponente. Möchte man die Verfügbarkeit eines Systemsangeben, kennt aber nur die Verfügbarkeit der Einzelkomponenten, läßt sich die Gesamtverfügbarkeit nachfolgenden Regeln berechnen.

185


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, derSpeicher und das Peripheriemodul verfügbar sind), sprichtman 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 BildSerienschaltungdargestellt. Sind die Unverfügbarkeitenq

ider 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 Ausfallratender Einzelkomponenten.

Bei einer Serienschaltung ist die Gesamtverfügbarkeit kleiner als die kleinste Einzelverfügbarkeit.

Gleichung 6-5. Verfügbarkeit einer Serienschaltung

pgesamt

= Σi=1

n

qi

Σi=1

n

qi

piΠ

n

pgesamt

=i=1

=Σi=1

n

λ i

mit p = Verfügbarkeit

q = Unverfügbarkeit

= Ausfallrateλ

1−q (1−qgesamt

= ) ≈1−Πi=1

n

i

≈gesamt

q

für q << 1:

λgesamt

K

K

K

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 Produktder Einzelunverfügbarkeiten. Damit wird dieGesamtunverfügbarkeit deutlich kleiner als die Einzelverfügbarkeiten.

186


Gleichung 6-6. Unverfügbarkeit einer Parallelschaltung

pgesamt

= 1−qgesamt

gesamtq

i=1Π i

q=n

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, sondernaus 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 BildParallelschaltung mit Koppelkomponentedargestellte Ersatzschaltbild.

Merke: Zur Berechnung von Verfügbarkeiten erstellt man ein Verfügbarkeitsersatzschaltbild nach demvorgestellten 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 Rechnerzur 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 zweiSystem (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 dasErsatzschaltbild als Serienschaltung angeben (Rechner 1undRechner 2undKoppelelektronik 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 1oder Rechner 2 mußverfügbar seinunddie 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 desAusfalls deaktivierte Komponente nicht den aktuellen Betriebszustand (z.B. des technischen Prozes-ses) kennen kann, wird im Regelfall ein kompletter Neuanlauf durchgeführt.

187


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 derHauptkomponente 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 dieAufgaben 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 HighAvailability) müssen in unterschiedlichen Bereichen Maßnahmen getroffen werden:

• Infrastruktur

• Hardware

• Software

• Management

Interruptwirdausgelöst

Wechselspannung

Gleichspannung

geglättete Spannung BetriebsspannungPower−fail−SpannungMinimal−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 desRechnersystems führt, wird dieses entweder durch eineunterbrechungsfreie Stromversorgung(USV), durch ein Notstromaggregat oder durch beides gesichert.

188


Muß der Betrieb bei Stromausfall nicht zwangsläufig aufrecht erhalten werden, reicht es oft auchschon 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 inKondensatoren) Energie. Damit werden die Spannungslückengeglättet, die bei der Gleichrichtungder Wechselspannung entstehen (siehe BildPower-fail-Interrupt). Fällt jedoch die Spannung untereine 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 einensicheren 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. Siefü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 dazunotwendigen 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äumeuntergebracht. 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 aufder Komponentenebene statt:

• Redundanz der Systemkomponenten.Durch Vervielfachung (meist Verdoppelung) kann die Ver-fügbarkeit erhöht werden. Problematisch bei diesem Ansatzist jedoch, den Ausfall zu dedektieren,den Systemzustand des ausgefallenen Systems auf die redundante Ersatzukomponente zu übertragenund diese schließlich zu aktivieren.

Die Überwachung einer redundant ausgelegten Komponente muß auf Systemebene erfolgen. Dazukann 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 einLifesign(Lebenszeichen) übermitteln. Dieses Lifesign setztin 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” Paketsendet.

Da die Komponenten meistens interne Zustände besitzen, müssen diese beim Ausfall bekannt seinund 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 Informationsverlustzu jedem beliebigen Zeitpunkt möglich ist.

• Die wohl verbreitetste Technologie ein redundantes Systemim Hot Standby zu betreiben ist die,dass das Ersatzsystem parallel mit der aktiven Komponente arbeitet. Es bekommt die gleichenEingangsinformationen und berechnet mit den gleichen Applikationen die Ausgabewerte. Die

189


Überwachungs- bzw. Koppeleinrichtung leitet aber diese Ausgabewerte solange nicht an dentechnischen Prozess (bzw. die nachfolgende Komponente) weiter, solange die aktive Komponentefunktionstü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 Komponenteals 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 dieVerfügbarkeit eines Gesamtsystems erhöhen kann, kann die Verfügbarkeit der Einzelkomponentendurch 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 undSpannungen 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 Datenund Systemzustände existieren.

190


Management

Managementseitig sind folgende Dinge zu regeln:

• Wartung: Es ist dafür zu sorgen, dass die kritischen Systemeständig überwacht und gewartet wer-den. Auch der regelmässige Austausch wichtiger (alternder) Komponenten kann sinnvoll sein. Eingroßes und oft wenig beachtetes Problem beim Austausch von Komponenten besteht - gerade in derAutomatisierungstechnik mit ihren langen Systemlaufzeiten - darin, dass Ersatzkomponenten nichtmehr 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 insLager. Fällt eine Komponente aus, wird das Ersatzteil aus dem Lager eingesetzt. Aber auch beidiesem Verfahren muß das Lager gewartet werden. Sind beispielsweise die Softwarestände einerKomponente im System und der Ersatzkomponente im Lager nicht auf dem gleichen Stand, kannes 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 durchden Menschen notwendig, um das betrachtete System wieder inden funktionstüchtigen Zustandzu bringen: Die Fehlerursache muß festgestellt und analysiert werden, redundante Systeme müssenaktiviert werden und Ersatzteile eingebaut werden. Aus diesem Grunde ist dafür zu sorgen, dassgenügend kompetente Mitarbeiter zumindest erreichbar undin 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 lassensich nicht tolerierbareFehler von dentolerierbarenFehlern unterscheiden. Unter tolerierbareFehler oder Fehlertoleranz versteht man den Umstand, dass trotz des Fehlers das System dennochdie geforderte Funktion erbringen kann (weil beispielsweise automatisch auf ein Ersatzsystemumgeschaltet wird).

• Ausgehend vom Fehlerbild enthalten die Notfallpläne Listen, die zur Identifikation der defektenKomponente 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 insgesamt6 sogenannte RAID-Level spezifiziert worden, die unterschiedliche Eigenschaften bezüglich Zuverlässig-keit und Zugriffsgeschwindigkeit aufweisen. Alle Festplatten bestehen aus logischer Sicht zunächst auseiner Anzahl von sequentiell hintereinanderliegenden Blöcken. In einem RAID-System wird eine spezi-

191


fizierte Anzahl derartiger Blöcke Stripe (Streifen) genannt. Unabhängig von der Anzahl der verwendetenFestplatten 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 zweioder mehr Festplatten, wobei jedoch dem zugreifendem Rechnersystem eine (virtuelle) einzige Festplattevorgespiegelt wird. Ein Performancegewinn beim Zugriff wird dadurch erreicht, dass die dem System zurVerfügung gestellte Sicht auf das Speichermedium aus abwechselnd einem Stripe der beiden Platten besteht.Liest das System mehrere sequentielle Blöcke, wird die Lastauf die beiden Platten verteilt, die Zugriffe sindinsgesamt schneller (siehe BildRAID-Level 0).

RAID-Level 1. Bei diesem Level werden die Partitionen einer Platte auf eine zweite Platte gespiegelt. BeiAusfall einer der beiden Platten, steht noch die jeweils redundante Platte zur Verfügung. Nachteilig ist, dassbei 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 sindSpezialfä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 allenPlatten führt).

RAID-Level 4. Mit RAID 4 wird zur Erhöhung der Verfügbarkeit Plattensystems verwendet. Wie beiRAID-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+1Platten 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ß. Dadiese Information für sämtliche Stripes auf der Parity-Platte liegt, stellt die Parity-Platte einen Flaschenhalsdar.

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


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ügbarkeitfür die dahinterstehenden Firmen existentiell und hat hohePriorität.

Mit eCommerce wird der elektronische Handel im Internet bezeichnet. Für den elektronischen Handel sindfolgende Komponenten notwendig:

• Webshop: Im Webshop werden die Waren angeboten und der Kundekann seine Bestellung aufgeben.Die wesentliche Kernkomponente des Webshops ist der HTTP-Server, der über Skripte oder Java in derLage ist, dynamisch Webseiten zu erzeugen. Diese Webseitenstellen die Produkte dar und nehmen dieKundenbestellung 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 dieBestellung weitergeleitet.

• Logistik/Versand: Die Versandabteilung ist für die Verpackung und den Versand der Bestellung zuständig.Gleichzeitig muß die elektronische Bezahlung angefordertwerden.

Die kritischste Komponente, also die Komponente, die die höchsten Anforderungen an die Verfügbarkeitstellt, 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 aufgenommenwerden, 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 gegenAttacken aus dem Internet wappnen.

Als ein Beispiel aus dem Bereich der “Soft-Realtime-Systeme” soll hier die Struktur des Webshops Buch.deim 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 30und 35 tausend Hits und ca. 1500 bis 2000 Vorgängen.

193


6.1.2.1.2. Buch.de

LinuxHTTP−Server2

www.buch.de

Backupleitung 2MBit

Standleitung 2MBit

ISP

Load−Balancer

Linux

Backup−Rechner

HTTP−Server1Linux

Windows NTPflege der Buchdatenbank

Windows NT

Windows NT

AuftragsdatenbankLinux

Logistikabwicklung

Linux

www1.buch.de www2.buch.de

GenerierungderInternetdatenbank

BuchdatenbankInternet−

Standleitung

Windows NTMailserver

� ��

� ��

� ��

� ��

� ��

� ��

� ��

� �

� ��

� ��

� � ��

� ��

� ��

� ��

� � ��

10

� ��

� ��

� ��

� ��

� ��

� ��

! !! !

" "# #

$ $$ $$ $

% %% %% %

& && &' '' '

( ( () )

* ** ** ** *

+ ++ ++ +

, ,, ,- -- -

. . ./ / /

0 00 00 00 0

1 11 11 1

2 22 23 33 3

4 4 45 5

6 66 66 66 6

7 77 77 7

8 88 89 99 9

: : :; ; ;

< << << << <

= == == =

> >> >? ?? ?

@ @A A

B BB BB BB B

C CC CC C

D DD DE EE E

F FG G

H HH HH H

I II II I

J JJ JK KK K

L LM M

N NN NN NN N

O OO OO O

P PP PQ QQ Q

R R RS S

T TT TT T

U UU UU U

V VV VW WW W

X XY Y

Z ZZ ZZ ZZ Z

[ [[ [[ [

\ \\ \] ]] ]

^ ^_ _

` `` `` `

a aa aa a

b bb bc cc c

d d de e

f ff ff ff f

g gg gg g

h hh hi ii i

j j jk k k

llllllll

mmmmmmmm

nnnnnnnn

oooooooo

pppppppp

qqqqqqqq

rrrrrrrr

ssssssss

tttttttt

uuuuuuuu

vvvvvvvv

wwwwwwww

xxxxxxxx

yyyyyyyyy

zzzzzzzz

{{{{{{{{

||||||||

}}}}}}}}

~~~~~~~~

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

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 eineBackup-Leitung (ebenfalls 2MBit) umgeschaltet. Die Backup-Leitung und die Standleitung erreichen dasHaus 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öglichstgleichmä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 einesRechners problemlos umgeschaltet werden kann. Der Ausfalleines Rechners wird automatisch dedektiert,das Umschalten erfolgt noch von Hand. Die gesamte EDV-Ausrüstung befindet sich in einem klimatisiertenRechnerraum.

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 mobileKlimagerä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öhungder 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 derRechner Probleme festgestellt, werden die Mitarbeiter über Pager informiert.

194


Bei Buch.de gibt es ausgearbeitete Notfall-Pläne. In diesen werden die Störungen in unterschiedlichenStörungsklassen eingeteilt:

• Klasse 1: Störungen, die für den Kunden sichtbar sind (z.B. Ausfall der Standleitung, Nicht-Verfügbarkeitdes Shops)

• Klasse 2: Störungen, die mittelbar die Betriebsbereitschaft beeinflussen (Ausfall eines Rechners, dergespiegelt 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 direktenVerantwortungsbereich des Webshops lag. EinBagger hatte die Standleitung der Telekom unbrauchbar gemacht. Der Schaden wurde von den Rechnernsofort 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 folgendenTag war der Webshop ein weiteres Mal für eine Stunde nicht erreichbar. Zu dieser Zeit wurde die Reparaturan 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 Umschaltenauf 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 einenfail-operational/fail-operational/fail-safeZuverlässigkeit vorschrieben, ist aufgrund der guten Erfahrungen mit den verwendeten Komponenten einfail-operational/fail-safeAnsatz verwirklicht.

Fail-operational bedeutet dabei, dass ein Fehler toleriert werden kann, der Betrieb kann ohne funktionaleEinbussen 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 verwendetwerden 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ängigerSensor, Computer und Aktorkreise. Problem bei diesem Anzatz ist die mangelnde Redundanz. Fälltbeispielsweise 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 imMithör-Modus einfach nur Informationen aufgenommen hätten. Wäre der Master ausgefallen, müssteeiner der redundanten Ersatzrechner seine Aufgabe übernehmen. Problematisch bei diesem Ansatz warfür die NASA, dass die NASA einen sicheren automatischen Switch-Over zum Ersatzsystem als einesehr komplexe Aufgabe angesehen hat. Dieser automatische Switch-Over ist aber notwendig, da inkritischen Flugphasen nur 400ms zur Verfügung stehen, um auf das Ersatzsystem umzuschalten.

195


3. Verteiltes Kommando

Bei diesem letztendlich gewählten Konzept hören alle Steuerrechner auf alle Sensoren und erzeugenauch 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ürdas Rechnersystem wird mit 6000 Stundenangegeben.

MDM MDM MDM

GPC

CPU

IOP

GPC

CPU

IOP

GPC

CPU

IOP

GPC

CPU

IOP

GPC

CPU

IOP

Bus

Keyboard Telemetry Payload−IF Rocket Boosters

BFS

Abbildung 6-11. Hardwarestruktur Space-Shuttle

Die einzelnen Sensoren und Aktoren des Raumfahrzeuges sindüber 19 bis 20 sogenannteMultiplexer/Demultiplexer (MDMs) an vier Bussysteme (1MHz) angeschlossen. Kritische Sensoren undAktoren (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 Busverbunden. 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 dieKontrolle ü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 sichinklusive Tastatur in der Nähe der Ladebucht.

Desweiteren existieren zwei Bandlaufwerke, die die eigentliche Steuersoftware (PASS, Primary AvionicsSoftware System) enthalten. Auf jedem der zwei Bandlaufwerke befinden sich jeweils drei Bereiche, diealle eine Kopie der Systemsoftware enthalten. Dadurch sindinsgesamt 6 Kopien der Systemsoftware anBoard. Fallen beide Bandlaufwerke aus, ist es darüberhinaus möglich, Software, die zum Wiedereintritt indie Erdatmosphäre notwendig ist, hochzuladen.

196


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 derRaumfähre gibt es in 80-90% der Flugzeit. Über diese Leitungwerden ständig die Zustände des Shuttleszur Erde gefunkt. Die Daten, die über diese Verbindung zum Raumfahrzeug gesendet werden, sind nichtverschlüsselt. Allerdings werden diese Daten auch nur übernommen, wenn das Shuttle im Sichtfeld derNASA-Bodenstationen ist. Sendet die Bodenstation dem Shuttle ein Kommando, muß das Shuttle selbigeserst zurücksenden und vom Boden das OK bekommen, bevor es aktiviert wird.

Von den 5 GPCs bearbeiten - abhängig von der Flugphase - bis zu4 exakt die gleiche Aufgabe. Da derHauptspeicher zu klein ist, um die gesamte Systemsoftware zu laden, wird ein Shuttle-Flug in 8 Flugphaseneingeteilt und für jede Flugphase vom Band die entsprechende Software geladen. Der 5. Rechner wirdals BFS (Backup Flight System) bezeichnet. Hardwaremässigist 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 Zeitscheibenverfahrenaufruft.

Abhängig von der Aufgabe werden GPCs redundant betrieben. Ist das Shuttle im Orbit, werden sogar GPCsabgeschaltet. Alle redundant betriebenen GPCs arbeiten streng synchron. Eine Synchronisation zwischenden 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 nichtinnerhalb dieser Zeitspanne, wird er als “failure to sync” gekennzeichnet und von den funktionierendenRechnern als nicht mehr im Verbund vorhanden betrachtet.

Das Redundanzkonzept beim Space-Shuttle wird als “the distributed command approach”, also “verteiltesKommando” bezeichnet. Alle 5 Rechner bekommen den gleichenInput und erzeugen auch (hoffentlich) diegleichen Ausgaben. Bei redundanten Aktoren fällt die Entscheidung, welche der von den Rechnern erzeugteAusgabe verwendet wird, aufgrund mechanischer (hydraulischer) oder elektronischer Voter (Entscheider).

Diese Art von Voting ist weit verbreitet. Dabei leistet jedeAusgabeeinheit seinen Beitrag zur Ausgabe. Dieeinzelnen Beiträge werden hydraulisch aufsummiert. Erzeugen beispielsweise 3 funktionstüchtige Rechnereine korrekte Ausgabe, der 4. Rechner aber eine schlechte, so “übertrumpfen” die 3 guten Rechner dendefekten 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 dieDruckdifferenz 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ündetoder 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 einenro-ten Knopf. Für das Umschalten haben die Piloten im Regelfall 10 Sekunden Zeit. Diese Zeit ergibt sichaufgrund physikalischer Gegebenheiten bzw. der Speicherkapazität interner Register (danach kommt es zukritischen Überläufen). Im worst case haben die Piloten sogar nur 400 Millisekunden Zeit, das ist, wenn dieGPC alle zu einem Zeitpunkt ausfallen, kurz nachdem sie vollen Schub eingestellt haben.

Fällt ein GPC aus, wird damit das Flugsystem in zwei oder mehrunabhä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 tundie 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 keineProbleme gibt, verbieten die Notfallpläne, dass einen derartige Situation über einen längeren Zeitraum exi-stiert.

197


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 aufgetretenist. Dedektiert kein Rechner einen Fehler, ist alles in Ordnung. Dedektiert ein Rechner einen Fehler, zweibzw. drei andere aber nicht, wird davon ausgegangen, dass der Rechner defekt ist und der Rechner wirdaus 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 werdenverworfen 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 zuGunsten der wichtigen Aufgaben unbearbeitet. Im Extremfall kann die komplette Bedienung der Displaysausfallen, allerdings ist auch in diesem Fall das Shuttle noch in der Lage, sicher zur Erde zurückzukommen.

Fußnoten1. Natürlich reicht der kurze Beobachtungszeitraum nicht aus, um eine gesicherte statistische Aussage

über die Wahrscheinlichkeiten durchzuführen.

198

Kapitel 7. Realzeit-AlgorithmenWie 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 Ergebnisvorliegt, zum anderen auch von der Korrektheit.

Die Brauchbarkeit des Ergebnis hängt ab von:− Zeitpunkt des Vorliegens− KorrektheitEs wird bestimmt durch:

− Algorithmen (SW, Art und Implementierung)− Leistung der Hardware (Verarbeitungszeit und Speicherplatz)

VerarbeitungEingaben Ausgaben

Leistung ZeitKorrektheitAlgorithmen

Abbildung 7-1. Ergebnis bestimmende Faktoren

Diese Anforderungen werden zum einen durch die Leistung dereingesetzten Hardware, zum anderen durchdie verwendeten Algorithmen bestimmt. Bei den Algorithmenkommt 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 Ergebnisvorliegt 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 zubesseren Ergebnissen als solches.

3. Man kann aber auch versuchen, die Anforderungen sowohl bezüglich der Zeit, als auch der Korrektheitdes 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, sindbisher noch nicht behandelt worden. Im folgenden sollen stellvertretend für unterschiedliche Verfahren eini-ge der gebräuchlichsten Algorithmenkurzvorgestellt werden. Es werden nur die grundlegenden Prinzipiengezeigt, um die Verwendbarkeit eines Algorithmus für ein spezifisches Problem abschätzen zu können. Füreine 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 Mengean Information in einem definierten Zeitfensterübermittelt werden.

Bei der Leistungs Problematik muß sichergestellt werden, dass eine bestimmte Arbeitsleistung in einemdefinierten Zeitintervall erbracht wird. Auf der einen Seite funktioniert dies über die bereits beschriebenenMaßnahmen. Reicht das nicht aus, muß man zwangsläufig so weitwie 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, mitHilfe derer gestellte Anforderungen eingehalten werden können.

7.1. Bandbreiten ProblematikViele 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 Zeitpunktdes Ü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. Aufder Sprecherseite wird die Sprache kodiertund in Pakete verpackt, die über das öffentliche Netz übertragen werden. Auf der Empfängerseitemüssen die zu unterschiedlichen und nicht zu äquidistantenZeitpunkten eintreffenden Pakete wiederzu einem einzelnen Datenstrom (Sprachstrom) zusammengesetzt werden. Der Zeitversatz zwischenSprechen und Empfangen (der sogenannte Jitter) darf beim Telefonieren nicht zu groß werden (BildZeitanforderungen bei der Internet-Telefonie).

1 2 4 5 83 6 7 9 10

1 2 4 5 83 6 7 9 10

1 2 3 4

1 2 4 5 83 6 7 9 10

1 2 3 4

Übertragungsweg

Absender

Empfänger

t

4321

Jitter

Abbildung 7-2. Zeitanforderungen bei der Internet-Telefonie

Die zeitsynchrone Übertragung von Sprachdaten über das Internet ist aber noch komplizierter. Die Datenwerden über verschiedene Netze mit unterschiedlichen Übertragungscharakteristiken geleitet. Damit istdie Reihenfolge, mit der die Pakete beim Empfänger ankommenungewiss. Außerdem muß man davonausgehen, dass die Bandbreite als solches nicht ausreicht,um sämtliche Daten zu übertragen.

200


• Ähnlich gelagert ist das Problem bei der Kommunikation mit Satelliten. Aus diversen technischen Grün-den ist die Übertragungsbandbreite zwischen Bodenstationund Satellit eingeschränkt. Damit ist auch dieAnzahl 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 dieMöglichkeit, diese Preallokation durchzuführen, beim Internet als solches, bei dem unterhalb von tcp/ipverschiedenste Protokolle eingesetzt werden, können Bandbreiten jedoch nicht garantiert werden. DiePreallokation der Ressourcen muß durch das Betriebssystemunterstützt werden. Im Kontext von Linuxgibt 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. DatenreduktionsverfahrenWird 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 verarbeitendenDaten 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 sinddas Audio-Daten-Format MP3 und das Bilddatenformat jpeg. Bei dieser Art der Datenreduktion wird aufden 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 Formatdie Schwingungen weggelassen, die für dasmenschliche Ohr ohnehin nicht wahrzunehmen sind.

Beim Bildformat GIF beispielsweise werden einfach maximal256 Farbwerte abgespeichert. Enthält ein Bildmehr Farbinformation, ist diese verloren. Bei JPEG wird dasBild in den Frequenzbereich transformiert undhochfrequente 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 einemeinfachen Kodierschema jeweils vor dem Zeichen ein Wiederholungsfaktor mit übertragen werden.

201


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äufigvorkommen, werden durch wenige Bits dargestellt, dagegen werden selten vorkommende Zeichen durchlängere Bitfolgen kodiert. Eine entweder bekannte oder vordem 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 folgendeHäufigkeitsverteilung:

A B C D E F G I L M N O P R S T U3 3 1 2 5 1 2 6 2 4 5 3 1 2 4 3 211

Jeder Häufigkeitswert (z.B. 11 für Space und 3 für A) wird als Knoten aufgefaßt. Ausgehend von diesenKnoten werden die beiden Knoten mit der geringsten Häufigkeit zu einem neuen Knoten zusammengefaßt.Dieser neue Knoten bekommt als Häufigkeitswert die Summe derihn bildenden Knoten. Im Beispiel könn-ten die Knoten der ZeichenC undF oderF undP zusammengefaßt werden, wobei jede Kombination aus denzugehörigen Knoten erlaubt ist. Im Beispiel werdenF undP zusammengefaßt.

1 1

3 3 1 2 5 2 2 6 2 4 5 3 2 4 3 211

Auf diese Art und Weise werden immer wieder in der obersten Ebene die beiden Knoten mit der niedrigstenZahl zusammengefaßt. So ergeben sich die folgenden Teilbäume, nachdem alle Knoten mit der Häufigkeit2 zusammengefaßt wurden:

11 3 3

1 2

3

2 2

4 5

1 1

2

5 6

3 2 2

4 4 5 4 3

Die Knoten in der obersten Ebene mit der niedrigsten Auftrittshäufigkeit besitzen einen Wert von 3. Imfolgenden werden alle diese Knoten zu einem neuen Knoten zusammengefaßt. Das geht so lange weiter, bisein einzelner Baum entstanden ist:

202


4

6

3 33

6

3

21 2 2

44 5

1 1

2 3

5

21

88

1612

23 37

60

11

5IN

6

22

4

10 11

F

BO A

G U L

S

D

E

T

M

R

C P

Den Huffman-Code bekommt man nun, wenn man im entstandenen Baum alle linken Äste durch eine 0kennzeichnet und alle rechten Äste durch eine 1. So wird beispielsweise das ZeichenN durch den Huffman-Code000 ausgedrückt, der BuchstabeD durch10110 .

IN

F

BO A

G U L

S

D

E

T

M

R

C P

0 1

0

0 0

0 0

0 0

0

0

0

0

0

0

0

0

0

11

1 1

1 1

1

1

1

1

1

1

1

1

1

1

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 SE T R I N G T O B E

E N C O D E D U S I N G A M I N I M U M

1100 000 110100 0100 10110 1100 10110 111 10000 1001 001 000 01111 111 0110 111 1010 001 000 001 1010 10000 1010

N U M B E R FO B

111 000 10000 1010 0101 1100 10111 111 0100 01110 111 0101 001 11011 1001

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. DieHuffman-Kodierung belegt dagegen nur 236 Bit, was eine Datenreduktion von mehr als 50% entspricht.

7.2. Leistungs ProblematikIn 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önnenunterschiedliche Formate haben. Der Roboter muß versuchen, eine optimale Packung der Palette zu er-

203


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 Regelfalldurch diverse Faktoren beschränkt ist, muß immer wieder dieEntscheidung gefällt werden, bestimmtezeitkritische 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 innerhalbvon 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 danndurch eine enstprechende Schaltung (z.B. FPGA) erzeugt.

2. Algorithmenwahl. Im Regelfall existiert nicht nur ein Algorithmus, um ein Problem zu lösen. Daherwird man im Falle von Realzeitsystemen besonders streng aufVerarbeitungszeit und Speicherplatzan-forderungen einzelner Algorithmen achten.

Bei den in der Echtzeitwelt zur Auswahl stehenden Variantenunterscheidet man

• exakte Verfahren von den sogenannten

• Näherungsverfahren.

7.2.1. Exakte Algorithmen am Beispiel HashingZur 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 eigentlicheSuchvorgang 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 denim AbschnittDatenreduktionsverfahrenerwähnten Algorithmen.

Wenn Datensatz.schluessel == Schluessel

Ja Nein

return Datensatz

für alle Datensätze

Datensatz *SucheDatensatz( key_t Schluessel )

Abbildung 7-3. Generalisierter Ablauf eines klassichen Suchverfahren

204


Bei den Suchverfahren wird im allgemeinen ein zu einem Schlüssel gehörender Datensatz gesucht. So istbeispielsweise 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 (AbbildungGeneralisierter Ablauf eines klassichen Suchverfahren) wird der Schlüssel mitden im Datenbestand abgespeicherten Schlüsseln solange verglichen, bis eine Übereinstimmung festgestelltwurde. Beim Hashing wird der Schlüssel dazu verwendet, um den Speicherort über eine mathematischeFunktion - 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 dieAbbildung des Schlüssels auf den Speicherortdurchführt, soll nach Möglichkeitso gestaltet sein, dass für jeden Schlüssel ein eindeutigerSpeicherort berechnet wird. SeiM der zur Verfü-gung stehende Speicherplatz, wird also eine Abbildung des Schlüssels auf einen Integer-Wertebereich von0 bis M-1 durchgeführt.

Anforderungen an die Hash-Funktionh(k) sind:

• Dass der gesamte Eingangswertebereich gleichverteilt aufden 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 dieBreite eines CPU-Registers (k(s) ) sein soll. Dadurch kann die folgende Berechnung möglichstschnell vonstatten gehen. Eine einfache Variante für eine Hashfunktion besteht in der Addition der einzelnen Bytesdes Schlüssels. Im Beispiel der Telefonnummernsuche würden also im ersten Ansatz die Buchstaben desNamens 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. Kommenbeispielsweise sehr oft ähnliche Strings vor, die sich weniger durch die vorkommenden Buchstaben selbst(z.B. “schneider” und “schnieder”), als vielmehr durch diePosition der selbigen unterscheiden, wird mandie 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


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 TabelleHashfunktion am Telefonbuch-Beispielzeigt beispielhaft die Werte fürk undh(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 manKollision. Die beiden Strings „schnieder“ und „schneider“ werden beispielsweisedurch die Schlüsselberechnungk(s) und die Hashfunktionh(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 Wertschneider das Ergebnis9 und für den Wertschnieder ebenfallsdas Ergebnis9, dann kann der Wert “schnieder” (wenn er denn zeitlich nach „schneider“ auftritt) nichtmehr am Tabellenplatz9 abgelegt werden, da hier bereits „schneider“ (oder sogar ein zeitlich noch frü-her aufgetretener Wert) eingetragen ist. Stattdessen wirdnachgeprüft, ob der folgende Tabellenplatz - imBeispiel, da nur die Tabellenplätze von0 bis 9 vorhanden sind - der Tabellenplatz0 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. Dererste 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 derAusgangspunkt einer eventuell notwendigen Suche definiert. Es muß also weiterhin der Zugriffsschlüsselmit dem Schlüssel des Datensatzes verglichen werden.

Außerdem muß bei diesem Verfahren sichergestellt sein, dass nicht weniger Tabellenplätze zur Verfügungstehen, wie mögliche Elemente eingehängt werden müssen.

Die Konsequenz bei dieser Art der Kollisions-Auflösung ist,die weiterhin bestehende Notwendigkeit derklassischen Suche. Entspricht die Tabellengröße exakt derElementanzahl, kann es im ungünstigsten Fallnotwendig sein, sämtliche Tabellenplätze abzusuchen.

206


• 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 dieanderen Tabelleneinträge zu reduzieren, wird über einen Tabelleneintrag eine Liste verwaltet. Diese Listeenthält die zum Hashwert gehörigen Datenelemente.

Auch bei diesem Verfahren ist im Falle einer Kollision eine Suche notwendig. Diese Suche bringt einenur 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 demidentischen 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 vorkommendürfen, als insgesamt Tabellenplätze vorhanden sind. Ist ein zu einem Hashwert gehöriger Tabellenplatzbereits belegt, wird die zweite Hashfunktion aufgerufen, die mittels eines anderen Algorithmus einenHashwert berechnet. Am zum neuen Hashwert gültigen Tabellenplatz wird jetzt wiederum untersucht,ob der Platz belegt ist oder nicht. Ist der Platz belegt, wirdab der aktuellen Position der nächste freieTabellenplatz 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 Zahli repräsentiert (k(s)=s-’A’; )wird und die Hash-Funktion h(k)=k%M verwendet wird, bekommt man die folgenden Hashwerte und dieangegebene Hash-tabelle. Kollisionen in der Hashtabelle werden hier über die Verwendung einer Liste an jedem Tabellenplatzgelöst.

Key: A(0)

S(18)

E(4)

A(0)

R(17)

C(2)

H(7)

I(8)

N(13)

G(6)

E(4)

X(23)

A(0)

M(12)

P(15)

L(11)

E(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


7.2.2. NäherungsverfahrenNäherungsverfahren werden oft auch als Optimierungsverfahren bezeichnet. Die den Näherungsverfahrenzugrunde 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 berechenbarerZeit, 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 manAlgorithmen, die zwar nicht die optimale, so doch immerhin suboptimale Lösungen bieten.

Es gibt also einen Lösungsraum, in dem jede Lösung durch eineGüte gekennzeichnet werden kann.

Lösung

optimale Lösung

Güte

unbr

auch

bar

brau

chba

r

Abbildung 7-4. Lösungsraum

Ziel ist es zwar, die optimale Lösung im Lösungsraum zu finden, ausreichend ist es dagegen, überhaupt einebrauchbare 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 dieserAnzahl würde der kürzeste Weg der optimalen Lösung (globales Maximum in BildLösungsraum) entspre-chen. Existiert zusätzlich die Bedingung, dass der RoboterPunkt B spätestens nach 4 Minuten erreichenmuß, sind alle die Lösungen unbrauchbar, für die der Robotermehr 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


Es lassen sich folgende prinzipielle Verfahren unterscheiden:

• Randomisierte bzw. probabilitistische Verfahren

• Heuristische Verfahren

Aus

gäng

e

Ein

gäng

e

X0

X1

nX

Y

X2

Y

0

1

mY

BOX

BLACK

Abbildung 7-5. Black Box

Als Aufgabe soll beispielsweise der Ausgangswert einerBlack Boxmaximiert werden. Die Black Box habeeine Anzahl vonn Eingangsleitungen undmAusgangsleitungen. Wennn groß genug ist, ist ein Ausprobierensämtlicher Eingangskombination aus Zeitgründen nicht möglich, hier kann nur ein Optimierungsverfahreneingesetzt werden. Dazu ist zunächst die Bewertungsfunktion festzulegen. Entsprechend der Aufgabenstel-lung werden die Ausgabeleitungen als Integerwert interpretiert. Damit ergibt sich die zu maximierendeGütefunktion zu:

Q(x)=2 0 Y0

+ 21 Y1

+ 22 Y2

+ ... 2 m 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 unddie 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 dieEingänge solange mit einer Zufallskombination beschickt,bis eine definierte maximale Zeit verstrichenist. 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ängigvon der dazu notwendigen Zeit (korrekt und eventuell schnell). Im Beispiel der Black Box werdendiesmal die Eingänge solange mit einer Zufallskombinationbeschickt - 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


die Hinzunahme von Wissen über den Untersuchungsgegenstand den Algorithmus sowohl bezüglich desErgebnisses als auch bezüglich der Laufzeit zu beschleunigen.

Dabei werden Verfahren, wie sie die Natur verwendet, auf dieProblemstellung adaptiert. DerIngenieur/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 dieungenauen Werte linguistischer Variablen (man spricht vonsogenannten Fuzzy-Sets) in Form von Fuzzy-Operatoren und Regeln verarbeitet. Existiert beispielsweise eine linguistische VariableTemperatur , so kanndiese die Werte (niedrig , mittel und hoch annehmen. In BildFuzzy Variable mittlere Temperaturist dieMengemittlere Temperatur einmal alsscharfeund alsunscharfeMenge dargestellt. Der Übergang, obeine bestimmte Temperatur zu der Menge gehört oder nicht, ist aufgeweicht und wird in Form desGradesder Zugehörigkeitµ(x) festgelegt. Dieser Grad wird in normalisierter Darstellung mit einer Zahl aus demIntervall [0,1] ausgedrückt.

0 10 20 30 40 50 60 70 80 90 100

1µ

unscharfe Mengescharfe 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


7.2.2.2.1.1. Mengenoperationen

Auf Fuzzy-Sets sind eine Reihe von Operationen definiert, wovon die zwei wichtigsten kurz vorgestelltwerden 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 Gradzu einer dieser Mengen. Die Und-Verknüfung ist in BildFuzzy Und-Operatordargestellt.

� ��

� ��

0 10 20 30 40 50 60 70 80 90 100

1µ

mittlere UND

Temperaturhohe

hohe Temperatur (heiß)mittlere Temperatur (warm)

Abbildung 7-7. Fuzzy Und-Operator

Maximumoperator. Der Maximumoperator repräsentiert die Vereinigungsmenge zweier Fuzzy-Sets unddamit 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 zueiner dieser Mengen.

� � � � � � � ��

� � � � � � � ��

0 10 20 30 40 50 60 70 80 90 100

1µ

Temperatur

mittlere ODERhohe

hohe Temperatur (heiß)mittlere Temperatur (warm)

Abbildung 7-8. Fuzzy Oder-Operator

211


Nichtoperator. Der Nichtoperator repräsentiert das Komplement eines Fuzzy-Sets und damit die logischeNicht-Verknüpfung.

µ2(x) = 1 - µ

1(x)

0 10 20 30 40 50 60 70 80 90 100

1µ

mittlere Temperatur (warm)nicht mittlere Temperatur (nicht warm)

Abbildung 7-9. Fuzzy Nicht-Operator

7.2.2.2.1.2. Regeln

Über die Fuzzy-Variablen werdenWenn-DannRegeln gesetzt.

Beispiel 7-2. Fuzzy-Regelsatz

REGEL 1: IF Temperatur == hoch ODER Druck == hochTHEN

Ventil = zu.

REGEL 2: IF Temperatur == hoch UND Druck == mittelTHEN

Ventil = mittel.

0 10 20 30 40 50 60 70 80 90 100

1 niedrig mittel hochµ

Temperatur

Abbildung 7-10. Fuzzy-Set Temperatur

212


0

1 niedrig mittel hoch

5040302010

µ

Druck

Abbildung 7-11. Fuzzy-Set Druck

0 10 20 30 40 50 60 70 80 90 100

1 mittelzu aufµ

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 zugeordnetund in die Regeln eingesetzt. Wird beispiels-weise die Temperatur 65 Grad und ein Druck von 10 Bar gemessen, ergibt die Zuordnung zu den Fuzzy-Setsfolgende Werte:

Temperatur 62: hoch = 0.3mittel = 0.7niedrig = 0.0

Druck 31 bar: hoch = 0.4mittel = 0.6niedrig = 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.4REGEL 2: min( 0.3, 0.6 ) = 0.3

213


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 Mittelstellungzu betreiben.

Aus diesen beiden Werten ist jetzt über die sogenannte Inferenz ein (scharfes) Ergebnis zu liefern. Wie beiden 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 denGrad der Prämisse begrenzt (Minimumfunktion). Die daraus resultierenden Mengen werden zum Inferenz-Ergebnis zusammengefaßt.

� � � � � � � ��

� � � � � � � ��

0 10 20 30 40 50 60 70 80 90 100

1 mittelzu auf

0.40.3

µ

Ventilstellung

Abbildung 7-13. MAX-MIN Inferenz

Aus dieser neu entstandenen Menge ist schließlich ein konkreter Stellwert für das Ventil abzuleiten. Auchhierfür gibt es wieder unterschiedliche Methoden. Gängig ist die Methode, eine Schwerpunktberechnungder Ergebnisfläche durchzuführen und entsprechend dem berechneten Punkt die Zielvariable einzustellen.Bei der Schwerpunktmethode kann es durchaus vorkommen, dass der berechnete Schwerpunkt außerhalbder 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 lernendesVerfahren. Neuronale Netze bestehen aus mehreren miteinander verschalteten Ebenen (Layers, siehe BildDreischichtiges Neuronales Netz). Jede Ebene besteht aus einer Anzahl Elementen, wobei jedes Elementein Ausgangssignal aus mehreren Eingangssignalen (der übergeordneten Ebene) erzeugt. Dazu wird jedeseinzelne Eingangssignal von dem Element gewichtet und allegewichteten Eingangssignale verundet. Umdie 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 Ergebnisals Fehlerwert zurückliefert. Die vorgestellten Elementeeines neuronalen Netzes können natürlich auchandere mathematische Funktionen als die Summenfunktion benutzen, um das Ausgangssignal zu bilden.

214


Wichtig für die Funktion ist zum einen die Art der Verschaltung der einzelnen Elemente und zum anderendas verwendete Verfahren, um das Netzwerk zu trainieren (die Gewichtung zu verändern).

Eingabeschicht

Zwischenschicht

Ausgabeschicht

Abbildung 7-14. Dreischichtiges Neuronales Netz

Σ

+1W

W

W

0k

1k

nk

Ausgabe

Fehler

+

−

Σ

gewünschteAntwort

GewichtungEingabesignale

X

Xnk

1k

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


• 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 folgendenAspekte:

• Existierende und mit einer genügenden Güte versehende Lösungen dienen jeweils als Ausgangsbasis fürdie iterative Optimierung.

• Es wird nicht nur eine Lösung, sondern es wird eine Vielfalt von Lösungen parallel betrachtet und dieseVielfalt 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 diesogenannte Fitneßfunktion (also die Gütefunktion) bestimmen kann.

Bei der Evolutionsstrategie erzeugt man aus einem solchen Genotyp die Nachkommen, indem man denursprü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 Generationaufgenommen.

Diesen Ablauf iteriert man derart lange durch, bis entwedereine brauchbare Güte erreicht wurde, oder diezur 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


8

1

2

4

3

6

8

Eltern

4

3

6

8

Nachkomme

Mutation Crossover

Z

A

B

F

Q

E

R

Z

A

B

F

Q

E

R

B

A

Z

A

B

F

Q

E

R

3

Abbildung 7-17. Mutation und Crossover

Im Beispiel der Black Box könnte eine Generationsbildung sowie in BildEvoltionsstrategie am Black Box Beispieldargestellt stattfinden. Im Beispiel wären beispielsweisedie unteren vier Eingangsleitungen direkt mit den Ausgangsleitungen verbunden. Das dargestelltehöchstwertigste Bit hat also keinen Einfluß auf den Ausgangswert.

Ausgangsindividuen 11011 00000 11111 010100 15 10

10011 01000 10110 100103 8 6 211011 01000 11111 01010

FitneßMutation

FitneßNeue Generation

Fitneß 13 8 1015

11

Abbildung 7-18. Evoltionsstrategie am Black Box Beispiel

Im Gegensatz zu den Evolutionsstrategien sind bei den genetischen Algorithmen jeweils zwei Individuenan der Nachkommensbildung beteiligt. Hierbei wird auch weniger auf Mutation, als vielmehr auf Crossovergesetzt (siehe BildMutation und Crossover). Beim Crossover werden jeweils Teilstücke der Elternindividu-en miteinander verbunden. Die Auswahl der Elternindividuen und die Auswahl der Teilstücke erfolgt dabeizufallsbedingt.

217


Führe Mutation bei der Nachfolgegeneration durch (mit geringer Wahrscheinlichkeit)

Generiere die Nachfolgegeneration durch Crossover in Höhe der Crossover−Rate

Selektiere zwei Elternindividuen mit fitneßproportionaler Wahrscheinlichkeit

Erzeuge die aktuelle Generation (z.B. nach Monte Carlo)

While( es existiert kein Individuum entsprechender Güte oder noch Rechenzeit vorhanden)

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

11000 00011

Ausgangsindividuen 11011 00000 11111 01010

Crossover 01110 11011

FitneßNeue Generation

8 3 13 1113 1315 14

Abbildung 7-20. Genetischer Algorithmus am Black Box Beispiel

Evolutionsstrategien bzw. genetische Algorithmen werdeninsbesonder im Bereich des OperationResearch eingesetzt. Damit läßt sich beispielsweise das angesprochene Roboter-Packproblem lösen. AuchReihenfolge-Probleme bei der Produktion unterschiedlicher Werkstücke. Die Algorithmen lassen sich aberauch zur Wegeplanung einsetzen.

218


7.2.2.2.4. Simulated Annealing

Abbildung 7-21. Globales Maximum

Einfache (iterative) Suchalgorithmen basieren oft auf derAnnahme, dass ein globales Maximum existiert.Damit führen Änderungen der Funktionsparameter entweder zu einer Verbesserung oder einer Verschlech-terung. Verschlechtern sich die Ergebnisse aufgrund einerParameterä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 gibtes 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 einlokales 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änderungendurchzuführen, die zu einer (kurzfristigen) Verschlechterung des bisherigen Ergebnisses führen.

219


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 vonAtomen. Ein derartiger Kristall besitzt von allen möglichen Konfigurationen der Atome im Festkörper diegünstigste Energiebilanz [Otto 1994].

Um perfekte Kristalle zu bekommen, wird eine Metallschmelze sehr langsam, unter ständiger Wäremzufuhrabgekühlt. Die zugeführte Wärmeenergie erlaubt den in Mulden festsitzenden Atomen, die energetischenBarrieren zu überwinden und ihre korrekten Gitterplätze zuerreichen. Die Gesamtenergie des Kristalls wirddadurch 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 zugroß 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 Maximumhinbewegen.

Die Wahrscheinlichkeit, mit der die Atome ihre Fehlposition verlassen, ist durch eine Exponentialfunktionbeschrieben:

P( ∆E)=e (- ∆E/kT)

wobei k die Boltzmannkonstante,∆E der Energieunterschied zwischen der Gesamtenergie vorher und derGesamtenergie zum aktuellen Zeitpunkt und T schließlich die Temperatur ist.

Ob der neue Systemzustand aber eingenommen wird (die aktuelle Position verlassen wird) oder nicht, wirdschließlich dadurch festgelegt, ob die Wahrscheinlichkeit P(∆E) größer als eine zwischen 0 und 1 bestimmteZufallszahl 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 vonOptimierungsschritten durchgeführt. Jeder Optimierungsschritt besteht darin, Veränderungen am System-zustand durchzuführen. Entsprechend der obigen Gleichungwird der neue Systemzustand akzeptiert odernicht. Ist ein Optimierungsschritt abgeschlossen, wird die Temperatur erniedrigt. Wenn bei einer Temperaturüberhaupt keine Verbesserung mehr eintritt, ist das Verfahren abgeschlossen. Bei entsprechend vorsichtigerTemperaturerniedrigung (Anzahl der Diskretisierungsstufen) befindet sich das System nahe der optimalenLösung.

220


neue Konfiguration =aktuelle Konfiguration

neue Konfiguration =aktuelle Konfiguration

∆ E−e kTif( Zufallszahl < )

∆ E = Q(neu) − Q(alt)

Wähle eine Anfangskonfiguration

neue Konfiguration = Anfangskonfiguration

Wähle eine Anfangstemperatur T>0

bis lange keine Verbesserung der Güteverringere T

until( Abbruchbedingung: Zeit oder Güte)

Berechne die Güte der aktuellen Konfiguration

Modifiziere die aktuelle Konfiguration leicht.

if( E > 0 )∆

NeinJa

Ja Nein

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 esbei Simulated Annealing immer noch notwendig, über diee-Funktion und die Bestimmung einer Zufallszahldie Akzeptierung auch einer schlechteren Konfiguration zu berechnen, wird dieser aufwendige Vorgangbeim 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-raturT bezeichnet.

Spannenderweise führt diese Vereinfachung des Algorithmus in den meistenFällen zu genauere Ergebnissen, die in kürzerer Zeit berechnet werden. TabelleVergleich von Simmulated Annealing (SA) mit Treshold Accepting (TA) [Otto 1994] zeigt die Ergebnissebeider Algorithmen bei der Lösung des sogenanntenTraveling Salesman Problems. Bei dieserAufgabenstellung gilt es einen möglichst kurzen Rundweg über eine Anzahl von Städten zu finden, wobeikeine 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


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 derTemperaturen 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. DieQualität einer Konfiguration wird ständig mit dem Wasserstand verglichen. Liegt die Qualität über demWasserstand, wird die neue Konfiguration übernommen, ansonsten wird mit der alten Konfiguration weitergerechnet. Mit jeder Runde (Schleifendurchlauf) wird der Wasserstand erhöht.

7.2.2.3. Bewertung

1) in Form der Operatoren und der Regeln

2) in Form der Verschaltung (Netzstruktur)

4) Parameterauswahl, Abkühlungskonstante

3) Abbildung auf Gene, Blockbildung beim Crossover

Einsatz

Steuerung

Steuerung X

FuzzyLogik

NeuronaleNetze

GenetischeOptimierungAlgorithmen

SimulatedAnnealing

Optimierung

MonteCarlo

1)

2)

3)

4)

X

X

X

X

Initialisierung

anderer

AlgorithmenLasVegas

heuristisch zufallsbasiert lernend

Abbildung 7-24. Merkmale von Echtzeitalgorithmen

Bild Merkmale von Echtzeitalgorithmengibt die unterschiedlichen Merkmale der vorgestellten Algorith-men wieder. Fuzzy-Logik wird angewendet, wenn zwar Wissen über das System zur Verfügung steht, sichdieses aber nicht auf klassische Art und Weise in mathematische Formeln setzen läßt. Fuzzy wird im Kontexttechnischer Systeme unter dem Stichwort Fuzzy-Control zurSteuerung technischer Prozesse eingesetzt.

Bei den neuronalen Netzwerken wird zunächst nur sehr wenig Vorwissen mit eingebracht. Das einzubrin-gende Vorwissen spiegelt sich vornehmlich an der Wahl der Größe des Netzes und der Netzstruktur wieder.Neuronale Netze können eingesetzt werden, wenn eine Teaching-Phase möglich ist. Hier extrahiert das Netzselbst das notwendige Wissen zur Steuerung des technischenProzesses.

Ist gar kein Wissen verfügbar, können nur noch die probabilistischen Verfahren wie Monte Carlo und LasVegas eingesetzt werden. Da bei beiden Verfahren Vorsicht geboten ist, werden sie vornehmlich im Kontextmit anderen Verfahren (z.B. Simulated Annealing oder Genetische Algorithmen) eingesetzt.

Genetische Algorithmen versuchen, im Lösungsraum die Parameter zu extrahieren, die den günstigstenBeitrag zur Lösung liefern. Hier steckt das Vorwissen sowohl in der Abbildung der einzelnen Parameter

222


auf die Gene, als auch in der Abbildung der Mutation, sprich der Modifikation des Lösungsraumes, beiden Evolutionsstrategien und des Crossover (Stichwort Blockbildung) bei den eigentlichen GenetischenAlgorithmen. Genetische Algorithmen werden zur Optimierung eingesetzt (z.B. Wegeplanung).

Zu der Gruppe der Optimierungsalgorithmen gehört auch Simulated Annealing in den verschiedenen Aus-prägungen. Der Lösungsraum wird bei Simultated Annealing in Suchfenster unterteilt, die mit jedem Ab-kühlungsschritt kleiner werden. Das eventuell vorhandeneVorwissen steckt auch hier in der Abbildung derParameter im Lösungsraum und der Verringerung der Temperatur.

223


224

Kapitel 8. Verteilte SystemeRealzeitsysteme sind heute vorwiegend Komponenten in einem verteilten System oder sie stellen selbst einverteiltes System dar. Systeme werden aus unterschiedlichen Gründen verteilt aufgebaut:

• Um durch Parallelverarbeitung eine höhere Systemleistungzu erzielen.

• Um durch Redundanz die Zuverlässigkeit zu steigern.

• Um die Komplexität durch überschaubare Teilsysteme zu verringern.

• Um durch Austauschbarkeit der Komponenten die Wartungsfreundlichkeit zu erhöhen.

• Um durch Verwendung preiswerter Hardware mit weniger Geldmitteln ein leistungsfähiges System zuerhalten.

Zunächst werden die sogenanntenMehrprozessorsystemevon denMehrrechnersystemenunterschieden.

8.1. MehrprozessorsystemeMehrprozessorsysteme werden vorwiegend zur Leistungssteigerung eingesetzt. Die Verarbeitungseinheiten- sprich die Prozessoren - sind räumlich konzentriert. Diese Systeme zeichnen sich durch kurze Kommu-nikationswege und die gemeinsame Nutzung der lokalen Ressourcen (z.B. Speicher aus). Prinzipiell unter-scheidet man zwei Arten:

• AMP: Asymmetrisches Multiprocessing (Master/Slave-Prinzip, auf dem Master läuft das Betriebssystem,verteilt die Prozesse/Threads auf die Slave-Prozessoren und führt sämtliche I/O-Aufgaben durch)

• SMP: Symmetrisches Multiprocessing (alle CPU’s sind gleichberechtigt)

Insbesondere SMP-Maschinen sind heutzutage für vergleichsweise geringe Kosten zu bekommen.

Das Scheduling bei SMP-Maschinen unterscheidet sich kaum vom Scheduling eines Einprozessorrech-ners. Alle Prozessoren (z.B. 4, 8 oder 16) bearbeiten den gleichen OS-Kernel, auf jedem Rechner läuft derScheduler. Dieser sucht sich den nächsten zu bearbeitendenThread aus. Bei der Auswahl des nächsten zubearbeitenden Thread wird alszusätzlichesAttribut noch berücksichtigt, ob der Thread bereits auf einemProzessor abgearbeitet wurde oder nicht. In diesem Fall würde ein derartiger Prozess bevorzugt, da sich vondiesem Prozess eventuell noch Daten im Cache des Prozessor befinden können. Wird ein Prozess währendder Bearbeitung von einer auf eine andere CPU verschoben, spricht man von Prozess-Migration. Eines dergrößten Probleme im Kontext von Prozessmigration ist die Übergabe existierender Kommunikationsbezie-hungen.

Der Zugriff auf die vom Scheduler benötigten Daten (Liste der Rechenprozesse) stellt einen kritischenAbschnitt dar, der durch entsprechende Mechanismen (Semaphore, Spinlock) gesichert werden muß.

Bei eng gekoppelten Systemen findet der Nachrichtenaustausch über ein gemeinsamen Speicher (SharedMemory) statt.

225

Kapitel 8. Verteilte Systeme

8.2. MehrrechnersystemeBei den Mehrrechnersystemen sind nicht nur die Verarbeitungseinheiten (Prozessoren) mehrfach ausgelegt,sondern ebenso die komplette sonstige Peripherie. Auch beidieser Art verteilter Systeme lassen sich zweiVarianten unterscheiden:

1. funktionsorientierte Mehrrechnersysteme und

2. leistungsorientierte Mehrrechnersysteme.

Bei funktionsorientierten Mehrrechnersystemen hat jederder der beteiligten Rechnern seine spezielle Funk-tion/Aufgabe. Die einzelnen Rechner sind oft unterschiedlich ausgeprägt. Bei leistungsorientierten Mehr-rechnersystemen hat man vielfach eine identische Ausprägung der Komponenten (Rechner-Cluster). JederRechner bearbeitet nach demgleichen Schema an einer Aufgabe.

8.2.1. Rechner-ClusterRechner Cluster zeichnen sich durch eine symmetrische Struktur aus. Die verwendeten Komponenten sindmehr oder minder identisch aufgebaut und die Aufgabe kann durch jeden der im Verbund befindlichenRechner bearbeitet werden. Leistungsorientierte Mehrrechnersysteme werden eingesetzt, um eine preiswer-te Leistungssteigerung zu erzielen (da besonders preiswerte Mainstream-Komponenten verwendet werdenkönnen).

Rechner-Cluster haben starke Verbreitung gefunden:

1. Application Service Provider setzen sogenannte Server Farmen ein, um über das Internet für KundenApplikationen, wie beispielsweise Webserver, Betriebsverwaltungssoftware oder Webshops zu betrei-ben (Data-Center). Die Kunden brauchen sich dabei weder um Hardware, Software, Installation, War-tung, Mitarbeiter, Sicherheit noch Verfügbarkeit zu kümmern.

2. Cluster erreichen dank entsprechender Software (z.B. Beowulf (http://www.beowulf.org)) und im Fal-le einer stark parallelisierbaren Aufgabe unglaubliche Leistungswerte. So gibt es diverse auf PC-Hardware basierende Systeme, die zu den Top 500 Supercomputer gehören. Mit derartigen (Beowulf-)Clustern werden heute Wetterberechnungen durchgeführt oder Verschlüsselungsalgorithmen geknackt.

3. Webshop-Betreiber setzen Cluster nicht nur zur Erhöhungder Rechenleistung, sondern insbesondereauch zur Erhöhung der Verfügbarkeit (Redundanz) ein.

Ein wichtiges Thema im Kontext Cluster ist das sogenannte Load-Balancing. Die durch den Cluster zu bear-beitenden Aufgaben sollen derart auf das System verteilt werden, dass alle Rechner möglichst gleichmässigausgelastet sind. Im einfachsten Falle werden die Aufträgean zentraler Stelle entgegengenommen und dannan die Rechner reihum verteilt. Eine andere Variante, die zudem die Auslastung der einzelnen Rechnerberücksichtigt, läßt die einzelnen Rechner, sobald diese Idle geworden sind, sich die Aufträge (Threads,Tasks) von zentraler Stelle abholen.

Die Verbindung einzelner Rechner zu einem Cluster wird heute im Regelfall über Fast-Ethernet durchge-führt. Die einzelnen Rechnerknoten verwenden zur Kommunikation untereinander (über Ethernet) ein nach-richtenorientiertes Kommunikationsprotokoll. Es existieren auch Implementierungen für ein sogenanntesDistributed Shared Memory. Hier greifen die Applikationenscheinbar auf einen gemeinsamen Speicherbe-reich zu, dieser ist aber nur virtuell. Real liegen die Datenauf den unterschiedlichen Rechnern.

226


Nicht immer - wie sonst bei Ethernet üblich - sind Multiprozessorsysteme über einen Bus miteinanderverbunden. Um möglichst hohe Leistung zu bekommen, wäre eine vollständige Vernetzung (jeder Rechnerist direkt mit jedem Rechner verbunden) am günstigsten. Daneben gibt es noch die Ring-, Stern-, Baum-,Ketten- und Cube-Struktur.

Hauptnachteil der Clustertechnologie ist der mit der hohenAnzahl von Knoten verbundene hohe Wartungs-aufwand.

8.2.2. Funktionsorientierte MehrrechnersystemenIm Kontext der Steuerung technischer Prozesse kommen vor allem funktionsorientierte Mehrrechnersyste-me zum Einsatz. Den einzelnen Knoten des verteilten Systemskommen ganz spezifische Aufgaben zu,die einzelnen Rechenprozesse sind damit ortsgebunden (funktionale Spezialisierung). Das Scheduling zwi-schen den Rechnerknoten ist statisch. Die Hardware der einzelnen Rechnerknoten divergiert, ist also nichthomogen.

In einem typischerweise automatisierten System werden Sensoren und Aktoren einzelnen Knoten zugeord-net. Diese Knoten kommunizieren über ein Feldbus mit einer Steuerung. Die Steuerung wiederum ist überEthernet mit einem Zellen- oder Leitrechner verbunden.

Ein wichtiger Punkt bei Mehrrechnersystemen ist die Identifikation von Ressourcen (Rechner und Objek-te). Jedes Objekt besitzt einen Namen. Im Falle des PROFIBUSbeispielsweise ist ein Objekt durch eineKommunikationsbeziehung (Verbindung) und durch ein Indexgekennzeichnet. Bei tcp/ip findet man aufunterster Ebene ein Objekt über die IP-Adresse (Rechneradress) und den Port (Applikationsadresse). Dar-überhinaus existiert aber noch ein symbolischer Namensraum. Zur Auflösung eines symbolischen Namensin die physikalischen Elemente existieren im System sogenannte Nameserver.

8.3. PetrinetzeEin Petrinetz ist ein Modell zur Beschreibung nebenläufiger(paralleler) Prozessen. Eng verwandt mit denZustandsautomaten ermöglichen sie die Analyse der modellierten Systeme auf:

• Erreichbarkeit von Systemzuständen (wie kann bei einem gegebenem Zustand ein zweiter Systemzustanderreicht werden?).

• Lebendigkeit bzw. Terminierung (werden die im System vorhandenen Ressourcen aufgebraucht?).• Totale Verklemmung (Stillstand des Systems).• Partielle Verklemmung (Stillstand von Systemteilen).

Transition

Übergang

Übergang

Stelle

Nachbereich

Vorbereich

Ein Petrinetz ist ein gerichteter Graph, der aus Knoten und Übergängen besteht. Bei Petrinetzen unterschei-det man zwei Knotenarten: die Stellen und die Transitionen.Stellen - üblicherweise als Kreise dargestellt

227


- entsprechen Zuständen, Transitionen, die als Balken oderRechtecke visualisiert werden, entsprechen denAktionen bzw. Ereignissen. Die Knoten (Stellen und Transitionen) des Netzes werden durch Übergänge(Kanten) miteinander verbunden, wobei eine Kante jeweils nur von einer Stelle zu einer Transition führendarf, bzw. von einer Transition zu einer Stelle. Kanten zwischen gleichartigen Knoten (z.B. von Stelle zuStelle) sind nicht erlaubt (siehe BildZwei Transtionen direkt hintereinander sind nicht erlaubt.).

Transition Transition

Stelle

Abbildung 8-1. Zwei Transtionen direkt hintereinander sind nicht erlaubt.

Formal betrachtet ist ein Petrinetz ein Tripel PN=(S,T,F),wobei S die nicht leere Menge der Stellen, T dienicht leere Menge der Transitionen und F die Flußrelation (Übergänge) ist.

Markenfluß. Anders als reine Zustandsautomaten läßt sich bei Petrinetzen das dynamische Verhalten mod-ellieren. Dazu existiert eine oder mehrere Marken (Markierung)M, die gemäß der Schaltbedingungen überdie Transitionen von Stelle zu Stelle in Nullzeit “fließen”.Die Anzahl der Marken im Netz ist nicht kon-stant, so fließen aus einer Transition soviele Marken, wie esÜbergänge zu den nachfolenden Stellen gibt.Werden die Marken in einem System so lange reduziert, bis keine schaltfähige Transition mehr existiert, istdas Petrinetz terminiert.

Schaltbedingungen.Wechselt eine oder mehrere Markierungen die Stelle, spricht man davon, dass diezwischen den Stellen befindliche Transition schaltet. EineTransition schaltet dann, wennalle sogenanntenVorbedingungen erfüllt sind. Unter Vorbedingung wird dabei das Vorhandensein einer Markierung in derStelle bezeichnet, die vor der Transition plaziert ist (Vorbereich). Damit eine Transition schaltet müssen allezur Transition führenden Stellen (Vorbedingungen) mit mindestens einer Marke versehen sein.

228


Transition

Stelle

Transition

Stelle

Transition

Stelle

vorher

nachher

a) b) c)

Transition

Stelle

Abbildung 8-2. Unterschiedliche Übergänge bei Petrinetzen

In Bild Unterschiedliche Übergänge bei Petrinetzensind die unterschiedlichen Übergangsmöglichkeitenverdeutlicht. Im Teilbild a) wird ein einfacher Übergang dargestellt. Über die Transition fließt von den dreiim Vorbereich existenten Marken eine einzelne. Da die Transition jedoch zwei Nachbedingungen (zweinachfolgende Stellen) besitzt, wird die Marke verdoppelt.Im Teilbild b) kann die Transition schalten, weilsich in den Vorbedingungen jeweils eine Marke befindet. Da esnur eine Nachbedingung gibt, besitzt dasNetz am Ende des Schaltvorganges auch nur noch eine Marke. InTeilbild c) schließlich ist ein nicht deter-ministischer Übergang dargestellt. Für die beiden angegebenen Stellen ist die Vorbedingung erfüllt. Es istaber nicht geklärt, welche der beiden Transitionen schalten wird.

2

3

t1

2

3

t1

a) b)

nachhervorher

Abbildung 8-3. Stellen/Transitionsnetz

Petrinetze, bei denen immer genau eine Marke über einen Übergang fließt, heißen Bedingungs/EreignisNetz. Demgegenüber bieten die sogenannten Stellen/Transitionsnetze die Möglichkeit, Kanten zu gewich-ten. Dazu wird jedem Übergang eine Zahl zugeordnet, der die Anzahl der Marken angibt, die über diesenÜbergang bei Schalten der Transtion (bzw. zum Schalten der Transition) transferiert werden. Wird in einem

229


Stellen/Transitionsnetz für eine Kante keine Gewichtung angegeben, hat die Kante das Gewicht 1. Im BildStellen/Transitionsnetzschaltet die Transition t

1mit der Gewichtung zwei nur dann, wenn im Vorbereich

mindestens zwei Markierungen vorhanden sind. In diesem Fall werden dem Vorbereich zwei Marken ent-nommen und im Nachbereich bekommt die linke Stelle eine Marke, die rechte Stelle jedoch drei Marken,da die Gewichtung der rechten Kante mit drei angegeben ist.

Modellbildung. Eine Modellbildung wird vereinfacht, wenn man zunächst diefolgenden drei Schrittendurchführt:

1. Im System auftretende Ereignisse sind zu identifizieren.Sie bilden die späteren Transitionen.

2. Die Vorbedingungen bzw. Vorzustände zu den Ereignissen sind aufzustellen. Dies sind die späterenStellen im Vorbereich.

3. Die Nachbedingungen bzw. Folgezustände sind aufzustellen. Dies sind die späteren Stellen im Nach-bereich.

Im folgenden soll beispielhaft ein technischer Prozess in Form eines Petrinetzes modelliert werden.

Auf den beiden FertigungsstraßenA undB kommen Werkstücke an, die durch zwei Handhabungssysteme (Y

undZ, Roboter) bearbeitet werden. Zur Bearbeitung eines Werkstücks auf der FertigungsstraßeA sind beideHandhabungssysteme notwendig, zur Bearbeitung eines Werkstückes auf der Fertigungsstraße B jedoch nurder RoboterZ.

Aus der Beschreibung lassen sich die folgenden 4 Ereignisseableiten:

• I: Start der Bearbeitung von Werkstück auf Band A• II: Ende der Bearbeitung von Werkstück auf Band A• III: Start der Bearbeitung von Werkstück auf Band B• IV: Ende der Bearbeitung von Werkstück auf Band B

Außerdem gibt es die folgenden 8 Bedingungen (Zustände):

1. Werkstück auf Band A vor der Bearbeitung

2. Werkstück auf Band A in der Bearbeitung

3. Werkstück auf Band A ist bearbeitet

4. Werkstück auf Band B vor der Bearbeitung

5. Werkstück auf Band B in der Bearbeitung

6. Werkstück auf Band B ist bearbeitet

7. Handhabungsgerät Y frei

8. Handhabungsgerät Z frei

Damit ergibt sich das in BildPetrinetz einer Fertigungsstraße [Abel1990]dargestellte Petrinetz.

230


1

2

3

4

5

6

7 8

I

II

III

IV

BA

Y Z

Abbildung 8-4. Petrinetz einer Fertigungsstraße [Abel1990]

8.3.1. Netzwerk AnalyseMechanismen der Netzwerk Analyse ermöglichen die Identifikation von Verklemmungen. Dazu wird auf-grund des Petrinetzes ein sogenannter Erreichbarkeitsgraph aufgestellt.

Ein Erreichbarkeitsgraph ist ein gerichteter Graph, dessen Knoten erreichbare MarkierungenMdes zugeord-neten PetrinetzesPNsind.

Konstruktion des Erreichbarkeitsgraphen. Ausgehend von der Anfangsmarkierung werden allemöglichen schaltfähigen Transitionen betrachtet. Die beim Schalten der Transition möglichen erreichbarenMarkierungen werden als Knoten des Graphen übernommen. Dieses Vorgehen wird ebenfalls bei denneu entstandenen Knoten durchgeführt, und zwar solange, bis keine Transtion mehr gefunden wird,die noch nicht durch entsprechende Kanten im Graphen abgebildet wurde. Ein Kennzeichnen desErreichbarkeitsgraphen besteht darin, dass die Knoten desGraphen unterschiedliche Markierungenbesitzen.

Die Knoten im Erreichbarkeitsgraphen, die nur eingehende aber keine ausgehenden Kanten haben, stellenmögliche Verklemmungen dar.

231


Petrinetz Erreichbarkeitsgraph

t 3

2tt 1

1010

0110

0101

t 1

2t1001

t 3

t 1

2t

4

3

2

1

Abbildung 8-5. Synchronisation durch ein Petrinetz modelliert [Abel1990]

Im folgenden soll die Erstellung des Erreichbarkeitsgraphen exemplarisch vorgestellt werden (BildSynchronisation durch ein Petrinetz modelliert [Abel1990]).

Das Petrinetz besteht aus vier Stellen, die initial folgendermassen markiert sind:

• Stelle 1 besitzt eine Markierung• Stelle 2 besitzt keine Markierung• Stelle 3 besitzt eine Markierung• Stelle 4 besitzt keine Markierung

Damit ergibt sich der erste Knoten zuM0={1,0,1,0} . Von M

0sind sowohl die Transition t

1als auch t

2möglich.

Schaltet die Transition t1, wäre der nächste Knoten im Erreichbarkeitsgraph gegeben durch M

1={0,1,1,0} .

Das Schalten der Transition t2führt zum KnotenM

2={1,0,0,1} .

Die Transition t3

kann erst schalten, wenn die Stelle 2 und die Stelle 4 besetztist. Je nach Knoten imErreichbarkeitsgraph muss daher die Transition t

2oder t

1schalten. Beide Transitionen führen dann aber

in denselben KnotenM3={0,1,0,1} . Hier kann die Transition t

3schalten und damit wird der Initialzustand

wieder eingenommen.

Der resultierende Erreichbarkeitsgraph ist in BildSynchronisation durch ein Petrinetz modelliert [Abel1990]dargestellt. Ein weiteres Beispiel für ein Petrinetz mit zugehörigem Erreichbarkeitsgraph ist in BildZugriff auf ein gemeinsames Betriebsmittel [Abel1990]dargestellt.

232


Erreichbarkeitsgraph

100

010 001

Petrinetz

t 1

2

2t

t 3

t 4

t 1 t 32t t 4

1

3

Abbildung 8-6. Zugriff auf ein gemeinsames Betriebsmittel[Abel1990]

Bei der Verklemmung werden die

• totale Verklemmung von der

• partiellen Verklemmung

unterschieden.

EDITORS NOTE: Beispiel mit Verklemmung hinzufügen!

233


234

Kapitel 9. SystementwurfDer systematische Systementwurf ist im Umfeld der Steuerung technischer Systeme notwendiger als inanderen Gebieten. Das Versagen oder Fehlerverhalten der Steuerung kann zu Personenschaden und/oderhohen (Ausfall-) Kosten führen, die sich durch einen systematischen Systementwurf vermeiden ließen.

In diesem Abschnitt wird der allgemeine Systementwurf nicht betrachtet, dieser findet sich in einschlägigenVorlesungen wieder. Hier soll nur auf die besonderen Aspekte im Umfeld der Automatisierungstechnikeingegangen werden.

Zwei wesentliche Aspekte charakterisieren hier den Entwurf:

1. Die ganzheitliche Betrachtung (Hardware/Software Codesign)

2. Host-Target Entwicklung

9.1. Die ganzheitliche BetrachtungWird ein technischer Prozess automatisiert und kann man dazu keine Standardkomponente, wie beispiels-weise eine SPS, einsetzen, muß ein ganzheitlicher Entwurfsprozess verwendet werden. Denn zur Erfüllungsämtlicher Anforderungen, insbesondere bezüglich der zeitlichen Vorgaben und der Kosten, muß der Ent-wurfsprozess sowohl die Entwicklung der Hardware, als auchder Software umfassen. Bei diesem Verfahrenkann während der eigentlichen Entwurfsphase entschieden werden, welche Funktionalität durch Hardwareund welche durch Software realisiert wird. Man spricht von Hardware/Software Codesign.

Abbildung Entwicklungszyklusstellt einen derartigen Entwurfsprozess anhand der verschiedenen Phasendar.

235

Kapitel 9. Systementwurf

− Schaltplan− Layout− Stückliste− VHDL−Code− ASIC− FPGA− Mikrocontroller− ...

− Quellcode− Object−Code− Executable

(Zwischen−) PRODUKTEAKTIONPHASE

HW−SW−CodesignSystementwurf,

SpecificationRequirements−

Implementation

Integration

Test

Umgangssprachliche oderformale Spezifikation

Systemarchitektur/Design

Umgangssprachliche oderformale Design−Spezifikation

Embedded System

Anforderungen:− Funktionalität− Technische Randbedingungen

Partitionierung

Verifikation

HW−Realisierung

ModultestModultest

Integration

Test

Integration

Gesamtsystem−

Test

Gesamtsystem−

SW−Realisierung

Abbildung 9-1. Entwicklungszyklus

Durch die Möglichkeiten, Funktionalität zwischen Hardware und Software auszutauschen, lassensich auch die gegebenen Anfoderungen auf unterschiedlicheArt und Weise erfüllen. TabelleAnfoderungen und Lösungsraumgibt einen Überblick über die verschiedenen Möglichkeiten.

Tabelle 9-1. Anfoderungen und Lösungsraum

Anforderung Hardware Software

Leistungsaufnahme Bausteinauswahl Sleepzustände, "Runtertakten"

Größe Bausteinauswahl/IntegrationsgradVerlagerung von HW in SW

Gewicht Technologie/Bausteinauswahl Verlagerung von HW in SW

Betriebsbedingungen Bausteinauswahl(MIL-Varianten), Kühlung

(proprietäre Maßnahmen)

236


Anforderung Hardware Software

(Verkaufs-) Preis Standard-Komponenten Standard-OS, -Appl., -Protokolle

Betriebskosten Technologie, Bausteinauswahl (Sleepzustände, "Runtertakten")

Realzeitverhalten Verlagerung von SW in HW,Rechenleistung erhöhen (z.B.DSP)

Realzeitsoftware, Algorithmen

Verfügbarkeit Redundanz,Betriebsbedingungen,mechanische Maßnahmen

Redundanz

Sicherheit Redundanz (2 aus 3 System) Redundanz, Diversifikation

Langlebigkeit Bausteinauswahl,Betriebsbedingungen

(Sleepzustände, "Runtertakten")

Wartungsaufwand Modultechnik, Flash Software-Upload

9.2. Host-Target EntwicklungDa die Hardware einer Prozesssteuerung meist

• proprietär oder

• zu leistungsschwach ist, bzw.

• keine geeignete Systemsoftware vorhanden ist,

wird ein eigenes Entwicklungssystem benötigt. Der Entwicklungsrechner wird alsHost bezeichnet, dasSystem, für das entwickelt wird, alsZielsystemoder einfach alsTarget(Host/Target Entwicklung).

− download− debugging

− serielle Schnittstelle− BDM−Interface− Flash− Eprom

− Cross−Compiler− Remote−Debugger

− Target−Betriebssoftware− Target−Libraries

Host

Monitorprogramm

Entwicklungsrechner mit:

Target

Abbildung 9-2. Host/Target Entwicklung

237


Das wesentliche Element der Entwicklungsumgebung auf dem Host ist der Cross-Compiler. Der Cross-Compiler erzeugt aus dem Quellcode ablauffähigen Binärcode für den spezifischen Prozessor bzw. für diespezifische Hardware. Zu der eigentlichen Applikation muß meist das Betriebs- oder Laufzeitsystem - undals Teil von diesem der Bootcode (Startupcode) gebunden werden.

Während der Entwicklung steht zumeist ein “Entwicklungstarget” zur Verfügung. Dieser ermöglicht daseinfache Laden der neuen Software. Dazu ist im (EP)ROM des Target ein sogenannter (Boot-) Monitoreingebunden. Der Monitor ist ein einfaches Systemprogramm, über das Software geladen und gestartetwerden kann. Oftmals bietet das Monitorprogramm auch einfache Debugmöglichkeiten.

Zum Laden der Software bietet sich an, den Code

• über eine serielle Schnittstelle zu laden,

• in einen Baustein (z.B. Eprom) zu brennen,

• eine eventuell vorhandene Flashdisk zu programmieren oder

• vorhandene Schnittstellen (bei Motorola zum Beispiel das BDM-Interface) zu verwenden.

Ist der Code auf dem Target, muß der Code bzw. der Target getestet werden. Ist die reale Prozessperipherienicht verfügbar, müssen dabei eventuelle Prozesssignale simuliert werden.

Werden Fehler festgestellt, muß der Target gedebugged werden. Dazu ist ein Remote-Debugger notwendig.Der Remote-Debugger ermöglicht im Zusammenhang mit dem Monitorprogramm (meist über die serielleSchnittstelle), dass die Applikation angehalten werden kann und dass Speicherzellen ausgelesen werdenkönnen. Controller der Firma Motorola bieten mit dem BDM-Interface auch hier in den Chip integrierteMöglichkeiten der Fehlersuche an.

Ist kein Remote-Debugger verfügbar, muß das Debuggen in derSoftware vorgesehen werden. Dazu mußdie Hardware eine Möglichkeit der Ausgabe besitzen. Im günstigsten Fall kann über eine serielle Schnitt-stelle ein Terminal angeschlossen werden, in der Software existieren einfache Ein-/Ausgabefunktionen. Anmarkanten Stellen innerhalb der Software werden dann Ausgaben vorgenommen (debuggen über printf). Istdie Hardware über ein DP-Ram mit dem Hostsystem verbunden, können einige Speicherzellen als Kommu-nikationsinterface genutzt werden. Beispielsweise können zwei Datenregister (jeweils eins für die Kommu-nikation zum Host bzw. zum Target) und zwei Controlregisterreserviert werden. Die selbst zu schreibendeprintf-Funktion kopiert dann jeweils ein auszugebendes Ascii-Zeichen in das Datenregister und setzt einentsprechendes Flag im Controlregister, so dass der Host das Zeichen abholt. Die Ausgabe wird eventuellauf dem Target als eigene Task und interruptgesteuert realisiert.

Existiert auch diese Möglichkeit nicht, müssen freie Ausgabeleitungen zur Ausgabe verwendet werden.Im primitivsten Fall werden dazu an die Ausgabeleitungen LED’s geschaltet. An den markanten Stellen inder Software werden die LED’s an bzw. ausgeschaltet. Damit bekommt man immerhin die Information, obbestimmte Codeteile durchlaufen wurden oder nicht.

Sehr hilfreich beim Debuggen und insbesondere notwendig ist auch ein Incurcuit Emulator (ICE). Anstelleder CPU wird der ICE ins Board gesetzt. Der ICE verhält sich - auch zeitlich - genau wie die CPU, istaber gleichzeitig in der Lage, alle Prozessorsignale, auchinterne, mitzuprotokollieren. Die Software kannzu jedem (zu definierendem) Zeitpunkt angehalten werden. Damit ein Hochsprachendebugging möglich ist,muß der ICE den Quellcode der ablaufenden Software kennen.

238

Literatur

[Abel90] Petrinetze für Ingenieure, Dirk Abel, Springer Verlag, Berlin 1990.

[Bayer90]Echtzeitverhalten fehlertoleranter Mehrrechnersysteme, Martin Bayer, Dissertation, Fakultät fürElektrotechnik und Informationstechnik, TU-München 1990.

[Bengel2002]Verteilte Systeme, Günther Bengel, 2. Auflage, Braunschweig 2002, Vieweg Verlag.

[GeCa84]Architecture of the Space Shuttle Primary Avionics Software System, Gene D. Carlow, Volume27, Number 9, 926-935, September 1984, Communications of the ACM .

[DIN66201]DIN 66201: Prozeßrechensysteme, Anonym, Beuth Verlag GmbH, Berlin 1981.

[EiMüSch2000]Formale Beschreibungsverfahren der Informatik, Helmut Eirund, Bernd Müller und Ger-linde Schreiber, 1. Auflage, Stuttgart 2000, Teubner Verlag.

[Färber87]Bussysteme, Georg Färber (Hrsg.), 2. Auflage, München 1987, OldenbourgVerlag.

[Färber94]Prozeßrechentechnik, Georg Färber, 3. Auflage, Berlin 1994, Springer Verlag.

[Färber2000]Prozeßrechentechnik, Manuskript zur Vorlesung Prozeßrechentechnik, Georg Färber, StandWintersemester 1999/2000, Lehrstuhl für Realzeit-Computersyteme, TU-München.

[Gresser93]Echtzeitnachweis ereignisgesteuerter Realzeitsysteme, Klaus Gresser, Düsseldorf 1993, VDI-Verlag GmbH.

[HalKona99]Sicherheitsgerichtete Echtzeitsysteme, Wolfgang A. Halang und Rudolf Konakovsky, 1. Au-flage, München 1999, Oldenbourg Verlag.

[HerrHomm89]Kooperation und Konkurrenz: Nebenläufige, verteilte und echtzeitabhängige Programm-systeme, R.G. Herrtwich und G. Hommel, Berlin 1989, Springer Verlag.

[KrHeiTe98] Bustechnologien für die Automation, Werner Kriesel, Tilo Heimbold und Dietmar Telschow,1. Auflage, Heidelberg 1998, Hüthig Verlag.

[Kuhn99]Ein- und Ausgänge im Griff, Bernhard Kuhn, 10/1999, München 1999, Linux-Magazin Verlag.

[Lauber76]Prozeßautomatisierung I, R. Lauber, Berlin 1976, Springer Verlag.

[LanSch94]Verteilte Systeme, Horst Langendörfer und Bettina Schnor, München 1994, Hanser Verlag.

[Otto94]Reiselust: Travelling Salesman - eine neue Strategie für eine alte Aufgabe, Thomas Otto, 1/1994,c’t magazin für computer technik , 188ff..

[Pressman92]Software Engineering: A Parctitioner’s Approach, Roger S. Pressman, 1992, 3. Edition,McGraw-Hill.

[Quade94]Automatische Zustandsmodellgenerierung für die Diagnosetechnischer Prozesse, Jürgen Quade,Düsseldorf 1994, VDI-Verlag GmbH.

[Rieck93]Modell Natur: Naturanaloge Verfahren in der Computersimulation , Christian Rieck, 11/1993,c’t magazin für computer technik , 201ff..

239

Literatur

[SchCaFrJa96]RTP: A Transport Protocol for Real-Time Applications RFC-1889H. Schulzrinne, Casner,Frederick und Jacobson 1. Februar 1996 http://www.ietf.org/rfc/rfc1889.txt

[Schlz94] Issues in designing a transport protocol for audio and videoconferencesand other multiparticipant realt-time applications H. Schulzrinne 1994http://www-users.cs.umn.edu/~zhzhang/cs8299/Readings/draft-ietf-avt-issues-02.ps

[Sedgewick83]Algorithms, Robert Sedgewick, 1983, Addison-Wesley Publishing Company, Inc..

[SpeGif84]The Space Shuttle Primary Computer System, Alfred Spector und David Gifford, Volume 27,Number 9, 874-900, September 1984, Communications of the ACM .

[TimMon97] Windows NT Real-Time Extensions: an Overview, Martin Timmermann und Jean-ChristopheMonfret, 2/1997, Real-Time Magazine.

[Triller94] Verbesserung des Echtzeitverhaltens von Mehrrechnersystemen durch Prozeßmigration,Michael Triller, Düsseldorf 1994, VDI-Verlag GmbH.

[Vogt96] Skript zur Vorlesung "Betriebssysteme", Christian Vogt, FH-München 1996.

[Wirth83] Algorithmen und Datenstrukturen, Niklaus Wirth, Stuttgart 1983, B.G. Teubner Verlag.

[Yodaiken]The RTLinux Manifesto, Victor Yodaiken, Department of Computer Science New Mexico Insti-tute of Technology.

[ZöbAlb95]Echtzeitsysteme: Grundlagen und Techniken, Dieter Zöbel und Wolfgang Albrecht, 1. Auflage,ISBN: 3-8266-0150-5, 1995, Thomson Publishing.

240

Stichwortverzeichnis

Betriebsmittel,??

Übertragung

buffered,??

queued,??

Ablaufsteuerung,??

Abruchkriterium,??

Absolutzeit,??

accept,??

Aktor, ??

Algorithmus

deterministischer-,??

Genetischer-,??

Realzeit-,??

Analogmultiplexer,??

Anforderungsfunktion,??

Asynchronous-IO,??

atomare Operation,??

Auftrittszeitpunkt,??

Ausgangssignal,??

Auslastung,??, ??

durchschnittliche,??

Automat

Mealy-,??

Moore-,??

Automatentafel,??

Backup Flight System,??

BCET,??, ??

BDM-Interface,??

Benefitfunction,??

Best Case Execution Time,??

Betrieb

Diskless-,??

Headless-,??

Betriebsmittel,??

Betriebssystem,??

Bewertungsfunktion,??

BFS,??

bind,??

Bootcode,??

Broadcast,??

buffered

Übertragung-,??

Bus

-Error,??

-Master,??

-Zyklus,??

Adreß-,??

Daten-,??

Kontroll-, ??

Prozessor-,??

Bussystem,??

Busy Loop,??

Busy-Loop,??

Cache,??

Client Server,??

Client/Server Modell,??

close,??

Codesequenz,??

cold standby,??

collision-resolution,??

Confirmation,??

connect,??

Context Switch,??

critical section,??

Cross Compiler,??

Daemon,??

Datenfluß,??

Datenflußdiagramm,??

Datenreduktion

verlustbehaftete-,??

verlustfreie-,??

Datenspeicher,??

Dauerunverfügbarkeit,??

Dauerverfügbarkeit,??

Deadlock,??

Determinismus,??, ??

Diagnose,??

Diagramm

Datenfluß-,??

Diskless-Betrieb,??

distributed command,??

distributed system,??

DMA, ??

Doppelsystem,??

download,??

DP-RAM, ??

Dual Ported Ram,??

Echtzeit

hart,??

weich,??

Echtzeitbedingung

erste,??, ??

Echtzeitnachweis,??, ??

eCommerce,??

Ein/Ausgabebefehl,??

eingebettetes System,??

Embedded NT,??

Embedded System,??

Entscheidungstabellen,??

Ereignis

-funktion,??

241

-Strom,??

-Tupel,??

abhängiges,??

Erreichbarkeitsgraph,??

Event

Software-,??

event triggered,??

Execution-Time,??

Executive,??

Fieldbus Message Specification,??

FIFO

Mailbox, ??

Filesystem,??

FMS,??

Folgeprozess,??

Function Blocks,??

gegenseitiger Ausschluß,??

General Purpose Computer,??

Genetischer Algorithmus,??

Gerätetreiber,??

Gleichzeitigkeit,??

GPC,??

Great Deludge,??

Gütefunktion,??

Hardware-Latenzzeit,??

Hardware/Software Codesign,??

Hardwareinterrupt,??

Hashing,??

Headless-Betrieb,??

High Availability, ??

Hintergrundspeicher,??

Host-Target Entwicklung,??

hot standby,??

Huffman-Coder,??

Hyperperiode,??

ICE, ??

Incircuit Emulator,??

Indication,??

Infrastruktur,??

insmod,??

Inter-Prozess-Kommunikation,??

Interrupt,??

-Betrieb,??

-Latency,??

-Service-Routine,??

-Service-Routine-,??

-Service-Thread,??

Applikations-,??

Hardware-,??

Software-,??

Vektortabelle-,??

Interrupt Service Routine,??

Interrupt-Service-Thread,??

ioctl, ??

IPC,??

ISR,??

innerhalb des BS-Kerns,??

IST, ??

Job,??

jpeg,??

Klimaanlage,??

Kollision, ??

Kommunikation

-azyklisch,??

-modell,??

-Primitive,??

-zyklisch,??

Kompression,??

Kontextswitch,??

Kontextwechsel,??

Kontroll-Fluß,??

Kontrollfluß (Synchronisation),??

Kostenfunktion,??

kritischer Abschnitt,??

Latenzzeiten,??

Laufzeitsystem,??

Leistung

Prozessor-,??

Linux, ??

listen,??

Load,??

Load-Balancer,??

lokales

Maximum,??

Minimum, ??

Lösungsraum,??

Mailbox, ??

Majornumber,??

Management,??

Mars-Pathfinder,??

Master Slave,??

maximale Reaktionszeit,??

Maximum

lokales,??

Mealy-Automat,??

Mehrprozessorsystem,??

Mehrrechnersystem,??

Memory-locking,??

Memory-Management-Unit,??

Memory-Mapped-IO,??

Messages,??

Meßbereichsumschaltung,??

Microsoft,??

Minimum

242

lokales,??

MMS, ??

MMU, ??

Monitorprogramm,??

Moore-Automat,??

MP3,??

MTBF, ??

MTTR, ??

Multicast,??

Multiplex

Analog-,??

Daten-,??

Zeit-, ??

Multitasking,??

mutual exclusion,??

Notfall-Pläne,??

Notfallpläne,??

Notstromaggregat,??

NP-Hart,??

Näherungsverfahren,??

open,??

Optimierungsverfahren,??

overlap-structure,??

p (Verfügbarkeit),??

Paging,??

Parallelschaltung,??

Parallelverarbeitung,??

Partitionierung,??

PCB,??

Peripherie,??

einfache,??

intelligente,??

Petrinetz,??

Pipe,??

poll, ??

Polling,??

Power-fail-Interrupt,??

Preemption,??

Preemption-Delay,??

Priority

Ceiling,??

Inheritance,??

Prioritäten,??

-Vergaberegeln,??

Prioritäts

-inversion,??

-vererbung,??

Process

Management,??

programmgesteuerter Kanal,??

Programmiersprachen,??

Programmierung,??

Prozess

disjunkter-,??

externer,??

konkurrierender-,??

kooperierender-,??

Management,??

Rechen-,??

technischer,??

Prozesse

disjunkte-,??

nebenläufige-,??

nicht disjunkte-,??

Prozesszeit,??

minimale,??

Publisher Subscriber,??

Pünktlichkeit,??, ??

q (Unverfügbarkeit),??

Queue,??

queued

Übertragung-,??

race condition,??, ??

RAID, ??, ??

read,??

non blocking-,??

ReadFile,??

Reaktionszeit,??

maximal zulässige,??

maximale,??

Realtime

hard,??

soft,??

Realzeitkommunikationssystem,??

Rechenarbeit,??

Rechenprozess,??

Rechenzeitanforderung,??, ??

Rechnerkern,??

Rechnerkernbelegung,??

Rechtzeitigkeit,??

Redundanz,??

Regelung,??

Releasetime,??

Remote Debugger,??

Rendevous,??

Reparaturzeit,??

repetitiver timer,??

Request,??

Response,??

Router,??

RT-Linux, ??

Scheduler,??

Scheduling

-Deadline,??

243

Points,??

prioritätengesteuertes-,??

Schnelligkeit,??

Schnittstelle

Gerätetreiber-,??

Segmentation Fault,??

select,??

Semaphore,??, ??

Sensor,??

Sequential Function Charts,??

Serienschaltung,??

Service Description Block (SDB),??

Services,??

Shared-Memory,??

Sicherheit,??, ??

Signal,??

Handler,??

Signale

Strobe-,??

Signals,??

Simulated Annealing,??

single shot timer,??

Skalierbarkeit,??

Skalierung,??

sleep,??

Socket,??

Sockets,??

Soft-Realtime-System,??

Softwareinterrupt,??

Space-Shuttle,??

Speichermanagement,??

Standardbetriebssystem,??

standby

cold,??

hot,??

Standleitung,??

Stellglied,??

Steuerung,??

Strobesignale,??

Stromversorgung,??

Suchverfahren,??

Swapping,??

Synchronisation,??, ??

System

Mehrprozessor-,??

Mehrrechner-,??

verteiltes,??

Systemcall,??

Systemfunktion,??

Target,??

Task-Kontrollblock,??

Task-Latency,??

TBF, ??

Technischer Prozess,??

Time

Execution-,??

time triggered,??

Timer,??

Treshold Accepting,??

TTR, ??

Universal Time,??

Unterbrechbarkeit,??

Unterbrechungsfreie Stromversorgung,??, ??

Unverfügbarkeit,??

USV, ??, ??

UTC, ??

Variable

Prozess-,??

Vektortabelle,??

Verarbeitungszeit,??

Verfügbarkeit,??, ??

Verfügbarkeits

-berechnung,??

-ersatzschaltbild,??

Verklemmung,??, ??

verteiltes System,??

VFD, ??

virtual field device,??

volatile,??

Vorhersagbarkeit,??

Vorhersehbarkeit,??

Voter

elektronischer-,??

hydraulischer-,??

wakeup,??

Wandler,??

Waren-Wirtschafts-System,??

Warteaufruf,??

warten,??

explizites-,??

implizites-,??

Wartezeit,??

WCET,??

Webshop,??

Weckaufrufe,??

Windows

-95,??

-98,??

-CE,??

-NT, ??

-powered,??

Worst Case,??

write, ??

Zeigeber,??

244

Zeit

Prozess-,??

Verarbeitungs-,??

Warte-,??

Zeitgeber,??

Zeitsynchronisierung,??

Zeitzone,??

Zielsystem,??

Zustandsautomat,??

Zuverlässigkeit,??, ??

245

ezs_buch

Documents

Transcript of ezs_buch