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