Vorlesung Echtzeitsysteme - Thema 1: Einführung

Transcription

Vorlesung Echtzeitsysteme - Thema 1: Einführung
Vorlesung Echtzeitsysteme
Thema 1: Einführung
Robert Baumgartl
17. März 2015
1 / 35
Organisatorisches
I
wahlobligatorisches Modul im Hauptstudium
I
2/0/2, d. h., 90’ Vorlesung und 90’ Praktikum pro Woche
I
Vorlesung mittwochs, 7:30 Uhr, S 529 (Keuch!)
Lehrender: Prof. Robert Baumgartl
I
I
I
I
I
I
Praktikum im Labor Z 136c
I
I
I
[email protected]
dem Subject bitte „[EZS]“ voranstellen
Tel. 462 2510
Raum Z 126
mittwochs nach der Vorlesung, 9:20 Uhr
Start: 2 Semesterwoche
Prüfung
I
I
keine Prüfungsvorleistung (PVL)
wie immer (90’ ohne Hilfsmittel)
2 / 35
Ressourcen
Folien, Bücher
I
Vorlesungsfolien (im PDF), Hausaufgaben, aktuelle
Informationen erscheinen im Laufe des Semesters unter
http://www.htw-dresden.de/~robge/ezs/ezs.html
I
Jane W. S. Liu. Real-Time Systems. Prentice Hall, 2000
I
Alan Burns und Andy Wellings. Real-Time Systems and
Programming Languages. 3. Aufl. Addison-Wesley, 2001
I
Dieter Zöbel: Echtzeitsysteme. Springer, 2008. ISBN
978-3540763956, 29.95 e
I
Jim Cooling. Software Engineering for Real-Time Systems.
1. Aufl. Addison-Wesley, 2003
3 / 35
Ressourcen
WWW
I
Kompendium; aus meinen bisherigen Veranstaltungen
kompiliert
I
Doug Jensens Site: http://www.real-time.org/
I
Computer-Related Incidents with Commercial Aircraft:
http://www.rvs.unibielefeld.de/publications/compendium/index.html
I
news:comp.realtime
I
GI-Fachgruppe Echtzeitsysteme: http://www.real-time.de/
I
Vorsicht - die deutsche Wikipedia taugt (bislang) nicht
besonders zur Erklärung des Fachgebiets
I
Beispiel: Erklärung zur Prioritätsgrenze
4 / 35
Was machen wir hier eigentlich?
Die Webseite besagt:
„Die LV Echtzeitsysteme ist eine einsemestrige
Einführung in Theorie und Praxis von
Rechensystemen, die zur Lösung zeitkritischer
Probleme eingesetzt werden.“
= Kennenlernen von Verfahren und Methoden zur/zum
I
Entwurf,
I
Realisierung und
I
Analyse
von (Rechen-)systemen, die zeitliche Garantien geben
können.
5 / 35
Thematische Übersicht
Prinzip: Anwendung des Echtzeitgedankens auf alle möglichen
Aspekte/Komponenten herkömmlicher Rechensysteme.
Beispiele:
I
Echtzeit-Scheduling
I
echtzeitfähige Ressourcenverwaltung
I
Echtzeit-Kommunikation
I
Echtzeit-Betriebssysteme
I
Programmiersprachen für Echtzeitsysteme
I
Verifikation von Echtzeitsystemen
Allerdings gibt es auch noch einige originäre Themen:
I
Zeit
I
Fehlertoleranz
6 / 35
Verwandte Diskursbereiche
I
Eingebettete Systeme
I
Rechnernetze und Betriebssysteme
I
Schedulingtheorie (Mathematik!)
I
Rechnerarchitektur
7 / 35
Voraussetzungen
I
Grundlagen Programmierungstechnik (Zeigerkonzept,
Listen, Bäume)
I
Rechner- bzw. Prozessorarchitektur: Caches, Pipelines,
Busse etc.
I
Programmbeispiele in C, kaum Assembler
I
Grundlagen Betriebssysteme (z.B. Scheduling,
Semaphore, Deadlock, Virtueller Speicher)
Am allerwichtigsten ist jedoch Interesse!
8 / 35
Was bedeutet „(in) Echtzeit“ ?
umgangssprachlich: Transformation der Eingangsdaten erfolgt
mit der Geschwindigkeit ihres Empfangs. ( „xy läuft in Echtzeit“;
xy ∈ {MP3-Encoder, Renderer, . . . })
Hermann Kopetz: “A real-time computer system is a computer
system in which the correctness of the system behaviour
depends not only on the logical results of the computations, but
also on the physical instant at which these results are
produced.” 1
Jane Liu: “. . . a real-time system is required to complete its
work and deliver its services on a timely basis.” 2
1
Hermann Kopetz. Real-Time Systems. 3. Norwell, MA: Kluwer Academic Publishers, 1999, , S. 2.
2
Jane W. S. Liu. Real-Time Systems. Prentice Hall, 2000, , S. 1.
9 / 35
Was bedeutet „(in) Echtzeit“ ?
DIN 44300: „Echtzeitbetrieb ist ein Betrieb eines
Rechensystems, bei dem Programme zur Verarbeitung
anfallender Daten ständig betriebsbereit sind derart, daß die
Verarbeitungsergebnisse innerhalb einer vorgegebenen
Zeitspanne verfügbar sind.“
dt. Wikipedia: „Von Echtzeitsystemen [...] spricht man, wenn ein
System ein Ergebnis innerhalb eines vorher fest definierten
Zeitintervalles garantiert berechnet, also bevor eine bestimmte
Zeitschranke erreicht ist. Die Größe des Zeitintervalles spielt
dabei keine Rolle [...].“
10 / 35
Schlussfolgerung
Das bedeutet:
I
sowohl die Korrektheit,
I
als auch die Dauer der Ermittlung
der Ergebnisse wird garantiert.
In Nicht-Echtzeit-Systemen wird i. a. nur die Korrektheit
garantiert.
Vereinfachung: Eine bestimmte zeitliche Schranke (Deadline)
wird nicht überschritten.
Verhalten eigentlich auch in „normalen“ Systemen erwünscht,
z.B. bei der Reaktion auf Benutzereingaben (Problem:
Aufwand).
11 / 35
Nochmals . . .
Was bedeutet „die Dauer der Operation wird garantiert“?
Ganz einfach: eine Spezifikation legt fest, wie lange die
Operation maximal dauern darf, und das Echtzeitsystem
garantiert, dass diese maximale Dauer niemals überschritten
wird, was immer auch
I
innerhalb des Systems und
I
in der Umwelt
passieren mag.
Die Maximaldauer nennen wir (relative) Deadline (der
Operation).
12 / 35
Häufige Mißverständnisse und Fehlannahmen
I
Echtzeitsysteme sind sehr schnelle Rechner.
→ Widerspruch: Prozessoren in Echtzeitsystemen sind häufig
niedriggetaktete Mikrocontroller.
I
Präemptive Prozessorvergabe ermöglicht prinzipiell ein
Echtzeitsystem.
→ reicht nicht aus; Windows Vista ist kein Echtzeitsystem
I
Moore’s Law bewirkt, daß Echtzeitsysteme überflüssig
werden.
→ Falsche Annahme, dass „Echtzeit“ schnell bedeutet
I
Es kann sowieso keine Garantie der Funktionsfähigkeit
eines Rechners gegeben werden, daher sind
Echtzeitsysteme nicht notwendig.
I
Echtzeitsysteme werden in Assembler programmiert.
13 / 35
Häufige Mißverständnisse und Fehlannahmen
I
Echtzeitsysteme sind sehr schnelle Rechner.
→ Widerspruch: Prozessoren in Echtzeitsystemen sind häufig
niedriggetaktete Mikrocontroller.
I
Präemptive Prozessorvergabe ermöglicht prinzipiell ein
Echtzeitsystem.
→ reicht nicht aus; Windows Vista ist kein Echtzeitsystem
I
Moore’s Law bewirkt, daß Echtzeitsysteme überflüssig
werden.
→ Falsche Annahme, dass „Echtzeit“ schnell bedeutet
I
Es kann sowieso keine Garantie der Funktionsfähigkeit
eines Rechners gegeben werden, daher sind
Echtzeitsysteme nicht notwendig.
I
Echtzeitsysteme werden in Assembler programmiert.
14 / 35
Häufige Mißverständnisse und Fehlannahmen
I
Echtzeitsysteme sind sehr schnelle Rechner.
→ Widerspruch: Prozessoren in Echtzeitsystemen sind häufig
niedriggetaktete Mikrocontroller.
I
Präemptive Prozessorvergabe ermöglicht prinzipiell ein
Echtzeitsystem.
→ reicht nicht aus; Windows Vista ist kein Echtzeitsystem
I
Moore’s Law bewirkt, daß Echtzeitsysteme überflüssig
werden.
→ Falsche Annahme, dass „Echtzeit“ schnell bedeutet
I
Es kann sowieso keine Garantie der Funktionsfähigkeit
eines Rechners gegeben werden, daher sind
Echtzeitsysteme nicht notwendig.
I
Echtzeitsysteme werden in Assembler programmiert.
15 / 35
Häufige Mißverständnisse und Fehlannahmen
I
Echtzeitsysteme sind sehr schnelle Rechner.
→ Widerspruch: Prozessoren in Echtzeitsystemen sind häufig
niedriggetaktete Mikrocontroller.
I
Präemptive Prozessorvergabe ermöglicht prinzipiell ein
Echtzeitsystem.
→ reicht nicht aus; Windows Vista ist kein Echtzeitsystem
I
Moore’s Law bewirkt, daß Echtzeitsysteme überflüssig
werden.
→ Falsche Annahme, dass „Echtzeit“ schnell bedeutet
I
Es kann sowieso keine Garantie der Funktionsfähigkeit
eines Rechners gegeben werden, daher sind
Echtzeitsysteme nicht notwendig.
I
Echtzeitsysteme werden in Assembler programmiert.
16 / 35
Häufige Mißverständnisse und Fehlannahmen
I
Echtzeitsysteme sind sehr schnelle Rechner.
→ Widerspruch: Prozessoren in Echtzeitsystemen sind häufig
niedriggetaktete Mikrocontroller.
I
Präemptive Prozessorvergabe ermöglicht prinzipiell ein
Echtzeitsystem.
→ reicht nicht aus; Windows Vista ist kein Echtzeitsystem
I
Moore’s Law bewirkt, daß Echtzeitsysteme überflüssig
werden.
→ Falsche Annahme, dass „Echtzeit“ schnell bedeutet
I
Es kann sowieso keine Garantie der Funktionsfähigkeit
eines Rechners gegeben werden, daher sind
Echtzeitsysteme nicht notwendig.
I
Echtzeitsysteme werden in Assembler programmiert.
17 / 35
Häufige Mißverständnisse und Fehlannahmen
I
Echtzeitsysteme sind sehr schnelle Rechner.
→ Widerspruch: Prozessoren in Echtzeitsystemen sind häufig
niedriggetaktete Mikrocontroller.
I
Präemptive Prozessorvergabe ermöglicht prinzipiell ein
Echtzeitsystem.
→ reicht nicht aus; Windows Vista ist kein Echtzeitsystem
I
Moore’s Law bewirkt, daß Echtzeitsysteme überflüssig
werden.
→ Falsche Annahme, dass „Echtzeit“ schnell bedeutet
I
Es kann sowieso keine Garantie der Funktionsfähigkeit
eines Rechners gegeben werden, daher sind
Echtzeitsysteme nicht notwendig.
I
Echtzeitsysteme werden in Assembler programmiert.
18 / 35
Häufige Mißverständnisse und Fehlannahmen
I
Echtzeitsysteme sind sehr schnelle Rechner.
→ Widerspruch: Prozessoren in Echtzeitsystemen sind häufig
niedriggetaktete Mikrocontroller.
I
Präemptive Prozessorvergabe ermöglicht prinzipiell ein
Echtzeitsystem.
→ reicht nicht aus; Windows Vista ist kein Echtzeitsystem
I
Moore’s Law bewirkt, daß Echtzeitsysteme überflüssig
werden.
→ Falsche Annahme, dass „Echtzeit“ schnell bedeutet
I
Es kann sowieso keine Garantie der Funktionsfähigkeit
eines Rechners gegeben werden, daher sind
Echtzeitsysteme nicht notwendig.
I
Echtzeitsysteme werden in Assembler programmiert.
19 / 35
Häufige Mißverständnisse und Fehlannahmen
I
Echtzeitsysteme sind sehr schnelle Rechner.
→ Widerspruch: Prozessoren in Echtzeitsystemen sind häufig
niedriggetaktete Mikrocontroller.
I
Präemptive Prozessorvergabe ermöglicht prinzipiell ein
Echtzeitsystem.
→ reicht nicht aus; Windows Vista ist kein Echtzeitsystem
I
Moore’s Law bewirkt, daß Echtzeitsysteme überflüssig
werden.
→ Falsche Annahme, dass „Echtzeit“ schnell bedeutet
I
Es kann sowieso keine Garantie der Funktionsfähigkeit
eines Rechners gegeben werden, daher sind
Echtzeitsysteme nicht notwendig.
I
Echtzeitsysteme werden in Assembler programmiert.
20 / 35
Sekundäre Anforderungen an Echtzeitsysteme
I
hohe Arbeitsgeschwindigkeit
I
Fehlertoleranz
Kosteneffizienz
I
I
I
niedriger Energiebedarf
hohe Ressourcenauslastung (Prozessor, Speicher)
−→ Kompromiss je nach Einsatzfall nötig!
21 / 35
Härte eines Echtzeitsystems
a) hartes EZ-System: Verletzung einer Deadline hat
katastrophale Konsequenzen für das System bzw. die
Umwelt.
b) weiches EZ-System: Verletzung einer Deadline führt zum
Absinken des Wertes des Ergebnisses, Einfluß auf die
„Güte“ des Dienstes, Systemleistung sinkt mit der Anzahl
verletzter Deadlines.
c) „mittelhartes“ EZ-System: Nach Überschreiten der
Deadline ist das Ergebnis wertlos, jedoch keine
Katastrophe (sog. “firm deadline”)
22 / 35
Härte eines Echtzeitsystems
Was passiert bei Verletzung einer Deadline?
3 Möglichkeiten, je nach „Wert“ des Ergebnisses nach
Überschreitung der Deadline td :
Wert des
Ergebnisses
0
0
td
t
0
td
t
td
t
sehr grosz
Abbildung: Hartes, weiches und „mittelhartes“ Echtzeitsystem
23 / 35
Härte eines Echtzeitsystems
Anmerkungen
I
Unterscheidung zwischen harten und weichen
EZ-Systemen nicht immer trivial, insbesondere der
Übergang zwischen weichen und Nicht-Echtzeit-Systemen
ist oftmals fließend.
I
Fehlertoleranz bei harten EZ-Systemen meist
ausgeprägter
I
Idee der “Flexible Computations”: Aktivität wird geteilt in
eine essentielle und eine wahlfreie Phase. Die essentielle
Phase muß unbedingt bis zur Deadline abgeschlossen
sein. Wahlfreie Phase erhöht die Güte des Resultats.
Beispiel: Ermittlung der Raumkoordinaten einer
Raumsonde.
I
Komplettierung vor Deadline oftmals unerwünscht
24 / 35
Klassifizierungsmerkmale von Echtzeitsystemen
1. „Härte“ der Deadline
2. Zuverlässigkeit und Fehlertoleranz (Sicherheit,
Fehlererkennung)
3. Verteilung: zentralisiertes oder verteiltes Echtzeitsystem
4. zeitgesteuertes oder ereignisgesteuertes System
5. interaktives oder autonomes System
6. hierarchisches oder Einzelsystem
7. zyklische oder/und asynchrone Aktivitäten
25 / 35
Eingebettete Systeme
Echtzeitsysteme konstituieren häufig Eingebettete Systeme
(embedded systems):
“Embedded computers are defined to be those where
the computer is used as a component within a system:
not as a computing engine in its own right. [...]” 3
d.h. der Computer ist Teil eines Geräts (und das Gerät ist kein
Computer im klassischen Sinne).
3
Jim Cooling. Software Engineering for Real-Time Systems. 1. Aufl. Addison-Wesley, 2003, , S. 12.
26 / 35
Eingebettete Systeme
Merkmale
I
komplexe Interaktion mit Umwelt und anderen
eingebetteten Systemen
I
werden häufig autonom betrieben
I
hohe Anforderungen an Zuverlässigkeit
I
ersetzen zunehmend mechanische Systeme
I
Hard- und Software werden gemeinsam entworfen
(HW/SW-Codesign).
I
Einsatz eines Prozessors „von außen“ häufig nicht
erkennbar
I
arbeiten häufig unter Echtzeit-Bedingungen
I
Kosten für Reparatur übersteigen (häufig) Kosten des
Systems.
27 / 35
Beispiele für Echtzeitsysteme
Herzschrittmacher:
I
1 Prozessor, 500 000 Lines of Code (LoC)
Abbildung: Größenvergleich Herzschrittmacher vs. 50-Pence-Stück
28 / 35
Beispiele für Echtzeitsysteme
Boeing 777:
I
ca. 1200 Prozessoren, 4 Milliarden LoC
Abbildung: Boeing 777 – ein etwas größeres Echtzeitsystem
29 / 35
Beispiele für Echtzeitsysteme, cont’d
Digitaler Video-Recorder für HDTV
I
Fernsehbild HDTV: 1920x1080 Punkte, 24 Bit Farbtiefe
(maximal)
I
d.h. ein unkomprimiertes Bild benötigt
1920 · 1080 · 3 Byte = 6075 KiB.
I
I
Wiedergaberate: (bis zu) 60 Hz (Bilder pro Sekunde)
1
in t =
s = 16.6 ms muss das Bild abgespeichert sein
60
=
ˆ End-zu-End-Transferrate von ≈ 356 MiB/s
I
sehr gute Festplatten erreichen ca. 100 MiB/s
I
→ Kompressionsverfahren erforderlich
I
30 / 35
Beispiele für Echtzeitsysteme, cont’d
Beispiel: Digitale Schiedsrichterassistenz im Fußball
I
Sender im Ball und den Schienbeinschonern der Spieler
I
extreme Anforderungen: Ball (bis 160 km/h) trifft auf
Pfosten, Nässe, Vibrationen. . .
I
Auflösung: Zentimeterbereich
I
→ Positionsbestimmung in Echtzeit (WITRACK-System
des Fraunhofer IIS)
I
Goal Line Technology System der Cairos AG:
http://www.cairos.com/unternehmen/gltsystem.php
31 / 35
Weitere Einsatzfelder
I
Luft- und Raumfahrt: Flugkontrollsystem, Steuerung von
Raketenmotoren, Satelliten
I
Digitale Steuerungen: Proportional Integral Derivative
Controller, Robotersteuerungen, Computertomograph
I
Automotive-Bereich: ABS, ESP, Airbag-Steuerung,
Navigationssysteme, Motormanagement, CAN-und
FlexRay-Bus
I
Signalverarbeitung: RADAR, Verfolgung (Tracking) von
Objekten, Bilderkennung, Unterhaltungselektronik
I
Multimedia-Systeme: En- und Dekodierung von
Audio/Video-Strömen, Klang- und Sprachsynthese, VoIP,
Video Storage Server
I
Echtzeit-Datenbanken
32 / 35
Aktuelle Forschungsgebiete (→ Diplomthemen?!)
I
Multiprozessor-Scheduling
I
Worst Case Execution Timing
I
Verifikation von echtzeitfähigen Systemen
I
Synchrone Programmiersprachen
I
Echtzeitabstraktionen für Betriebssysteme
33 / 35
Zusammenfassung: Was haben wir gelernt?
1. Echtzeitsysteme sichern die Rechtzeitigkeit aller
relevanten Operationen.
2. harte vs. weiche vs. „mittelharte“ Echtzeitsysteme
3. Begriffe: Deadline, eingebettetes System
4. Wenn etwas (umgspr.) in Echtzeit läuft, dann ist die
Eingangsdatenrate gleich der Ausgangsdatenrate.
(Beispiel: Echtzeit-3D-Darstellung)
5. Echtzeitsysteme sind außerordentlich interessant.
34 / 35
Vertiefende Literatur
Die hier aufgeführten Texte sind Lesevorschläge. Da diese dem
Urheberrecht unterliegen (die Texte, nicht die Vorschläge),
kann ich sie nicht einfach ins Netz stellen, sondern stelle sie
Ihnen auf Anfrage zur Verfügung.
I
John A. Stankovic. “Strategic Directions in Real-Time and
Embedded Systems”. In: ACM Computing Surveys 28.4
(Dez. 1996), S. 751–763
I
John Stankovic. “Misconceptions About Real-Time
Computing”. In: IEEE Computer 21.10 (Okt. 1988),
S. 10–19
35 / 35