7.1 Grundlagen Wiederholung Wertefunktion. Kommunikation. Modell für Echtzeitkommunikation. Echtzeitsysteme. 7. Kapitel Echtzeitkommunikation

Transkript

1 Echtzeitsysteme Sommersemester 2016 Wiederholung Wertefunktion Wert Deadline Wert Deadline Echtzeitsysteme Zeit Zeit 7. Kapitel Echtzeitkommunikation Wert Deadline Wert Deadline Prof. Matthias Werner Professur Betriebssysteme Zeit Zeit Echtzeitsysteme sind Computersysteme, bei denen der Nutzen eines Resultates nicht nur vom Resultat abhängt, sondern auch vom Zeitpunkt der Auslieferung des Resultats. SoSe 2016 M. Werner 2 / 58 osg.informatik.tu-chemnitz.de Kommunikation Modell für Echtzeitkommunikation Echtzeit erfordert, dass Ergebnisse zu einem bestimmten Zeitpunkt vorliegen In einem verteilten System bedeutet dies: Reaktion auf eine Eingabe an einem Knoten produziert Ausgabe an einem anderen Knoten Zeitliche Anforderung ist ebenfalls verteilt: Lokale Tasks auf Knoten Transport auf Netzwerk Bei Kommunikation wird die unmittelbare Einflusssphäre verlassen besonderer Augenmerk auf Fehlertoleranz TPH Transport Protocol Handler Interface zu lokalen Applikationen Bietet einen Nachrichtentransport-Service NACH - Network Access Control Handler Interface zum Netzwerk Bietet TPH Netzwerkzugriff Bietet TPH Nachrichtenübermittlungsservice Vereinfachung: Alles über der Transportschicht wird als Applikation betrachtet SoSe 2016 M. Werner 3 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 4 / 58 osg.informatik.tu-chemnitz.de

2 Pakete Performance-Maße Nachrichten werden für die Übertragung in Pakete einer definierten Größe zerlegt Übertragung eines Paketes ist nicht unterbrechbar Pakete heißen in realen Netzen auch: Frames Segmente Zellen In einem Kommunikationsstack können auf verschiedenen Ebenen verschiedene Paketgrößen genutzt werden Delay oder End-zu-End-Zeiten Verzögerung einer Nachricht von sendender Task zu empfangender Task Bei Steuerungssystemen oft essentiell Bei Multimedia-Systemen oft irrelevant Jitter Schwankungen der End-zu-End-Übertragungsdauer Bei Multimedia-Anwendungen möglichst niedrig Abhilfe gegen Jitter: große Puffer erhöhen aber Delay Durchsatz Anzahl von Nachrichten, die pro Zeiteinheit transportiert werden können Mindestanforderungen an den Durchsatz sind Basis von Scheduling- und Flusssteuerungsalgorithmen SoSe 2016 M. Werner 5 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 6 / 58 osg.informatik.tu-chemnitz.de Performance-Maße (Forts.) Zeitmodell Als zeitliches Modell kann wieder ein zyklisches Verhalten angenommen werden Bei Kommunikation verlässt der Ausführungsstrom den unmittelbaren Einflussbereich Störungen sind möglich und müssen berücksichtigt werden. Raten für Verlust, verpasste Deadlines und beschädigte Nachrichten Anteil am Gesamtnachrichtenaufkommen Anforderung: Einhaltung bestimmter Höchstwerte Dauer von Unterbrechungen, max. Anzahl von aufeinanderfolgenden beschädigten Nachrichten Burst error Jedoch ist ein nichtzyklisches Verhalten häufiger sinnvoll als bei Tasks Z.B.: Status/Fehlermeldungen Einander widersprechende Zielstellungen: Periodische Daten Viel a-priori-wissen (Periode, Nachrichtentypen, Sendezeitpunkte,... ) Ziel: Jitterminimierung Schedule ist vorab berechenbar, hohe Auslastung erzielbar Sporadische Daten Kein Wissen über Perioden und Sendezeitpunkte Nur geringes Vorabwissen über minimal Interarrivial Time Ziel: Geringes Delay SoSe 2016 M. Werner 7 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 8 / 58 osg.informatik.tu-chemnitz.de

3 Ausführungsmodell Externe Kontrolle: Senden einer Nachricht wird von der Anwendung gesteuert und ist für das Kommunikationssystem ein externes Ereignis Pushing + Flexibilität + Einfache Schnittstelle zwischen Anwendung und Kommunikationssystem + Trennung zwischen Anwendungslogik und Steuerung des Kommunikationssystems - Fehlerhafte Anwendungen können Kommunikationssystem mit Nachrichten überfluten - Überlast durch gleichzeitiges Senden vieler Anwendungen Interne Kontrolle: Kommunikationssystem legt den Zeitpunkt einer Sendung fest und fordert Daten von Anwendung Polling + Laststeuerung vollkommen unter Kontrolle des Kommunikationssystems + Fluten nicht möglich + Anwendungen und Kommunikationssystem können separat getestet werden - Kommunikationssteuerung ist in Anwendungslogik involviert (unflexibel) - Schnittstelle komplizierter, da zeitliche Aspekte berücksichtigt werden müssen 7.2 Fehler 7.2 Fehler Wie diskutiert, ist das Auftreten von Fehlern bei Kommunikation wahrscheinlicher als bisher muss im Design berücksichtigt werden (Haupt)Aufgabe: Fehler erkennen Fehler tolerieren Auswirkungen beheben Alle drei brauchen Redundanz, häufig auch in der Zeit Auswirkung auf das Zeitverhalten Hier nur eine kurze Diskussion weniger Aspekte mehr in LV Verlässliche Systeme SoSe 2016 M. Werner 9 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 10 / 58 osg.informatik.tu-chemnitz.de 7.2 Fehler Fehlererkennung 7.2 Fehler Flexibilität vs. Fehlererkennung Zwei typische Fehlermodelle: Paketverlust Erkennung durch Timeout oder Sequenznummer Verfälschung der Paketdaten Erkennung durch Kodierung (Checksummen) Bei der Kodierung wird am häufigsten Cyclic Redundancy Code (CRC) verwendet Effiziente Implementierung möglich Polynom k-ten Grades erkennt mindestens jeden Burst-Fehler der Länge k Annahme: System ohne Replikation Je weniger a-priori über ein System bekannt ist, desto schwerer ist die Erkennung von Fehlern Wenn Vorwissen existiert (z.b. Knoten sendet ein alive in regelmässigen Abständen), ist Fehlererkennung einfacher Einführung von a-priori-wissen geht immer auf Kosten der Flexibilität Annahme: System mit Replikation Fehler sind durch Redundanz einfach zu erkennen Rekonfiguration ist unflexibel (Vermeidung von single points of failure) SoSe 2016 M. Werner 11 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 12 / 58 osg.informatik.tu-chemnitz.de

4 7.2 Fehler Explizite vs. implizite Flusssteuerung Flusssteuerung: Steuerung der Übertragungsgeschwindigkeit zwischen Sender und Empfänger um Überlaufverluste zu verhindern Explizite Flusssteuerung: Empfänger bestätigt Pakete des Senders Nächstes Paket wird erst nach Bestätigung gesendet Nichtbestätigte Pakete werden wiederholt Voraussetzung: Sender muss vom Empfänger erreichbar sein Erhöhter Jitter Implizite Flusssteuerung: Sender und Empfänger einigen sich a-priori auf Sendezeitpunkte Empfänger erkennt Fehler Einfache Realisierung von Redundanz Nicht geeignet für Nachrichten ohne Vorabwissen Voraussetzung: Synchronisation 7.2 Fehler Zentrale Steuerung vs. Dezentrale Fehlertoleranz Zentrale Steuerung vereinfacht Zugriffsverfahren (z.b. Central Master oder auch Token-Verfahren) Zentrale Steuerung ist ein single point of failure : Ausfall bedeutet Notwendigkeit der Rekonfiguration Verletzung zeitlicher Eigenschaften Erkennung des Ausfalls kostet Zeit Festlegung einer neuen Kontrollinstanz erfordert zusätzliche Kommunikation SoSe 2016 M. Werner 13 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 14 / 58 osg.informatik.tu-chemnitz.de 7.2 Fehler Das Babbling-Idiot -Problem 7.3 Medienzugriffsverfahren (MAC) Scheduling-Policy Broadcast-Netze: einzelner Knoten kann durch Verletzung des Kommunikationsprotokolls sämtlichen Verkehr stören Babbling Idiot Repliziertes Medium hilft nur bedingt: Wenn Problem in der Anwendung liegt, werden alle Medien gestört Besser: Mechanismus im Kommunikationssystem Möglichkeiten: Kommunikationssystem weiß, wann gesendet werden darf und lässt es nur zu diesen Zeiten zu ( TTP) Kommunikationssystem setzt Obergrenzen für Sendungslängen oder Mindestabstände zwischen Sendungen ( ARINC-620) Erkennung von fehlerhaften Knoten und Sperrung ( CAN) Zeitverhalten wird vor allem dadurch bestimmt, wer wann auf das Medium zugreifen darf Medienzugriffssteuerung (media access control, MAC) Zeitverhalten ist prinzipiell auf Scheduling-Probleme ( Kapitel 4) abbildbar Job = Paket CPU = Medium Übliche Verfahren (RMS, EDF) werden teilweise eingesetzt Besonderheiten: Pakete i.d.r. gleichlang Keine Preemption von Paketen (sonst Verlust) Jitter häufig wichtiges Kriterium SoSe 2016 M. Werner 15 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 16 / 58 osg.informatik.tu-chemnitz.de

5 Physikalische Probleme Physikalische Nachrichtenübertragung nicht beliebig schnell Damit: Gleichzeitigkeit hängt von Auflösung der benutzten Uhren und physikalischer Entfernung zwischen den Knoten ab Problem kann vernachlässigt werden, wenn Laufzeit klein gegen Dauer der Übertragung eines Bits ( Bitzeit ) Anderenfalls: Propagationdelay Zeit, die ein Signal benötigt, um alle Teilnehmer zu erreichen Beispiel: 100 MBit/s Datenrate, 200 m Kabellänge Bitzeit: 10 ns Propagationdelay: 1000 ns (Ausbreitungsgeschwindigkeit: 2 c) 3 Kanal speichert 100 Bit Kollisionen erst nach Ablauf des Propagationdelay erkannt CSMA/CD Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Prinzip Jede Station lauscht auf Datenverkehr Solange Medium belegt, wird eigener Sendewunsch verzögert Wenn frei und Sendewunsch schreibender Zugriff auf Medium Während des Sendes wird Medium zur Kollisionserkennung weiter abgehört Kollision: Senden des Jam-Signals, Abbruch des Sendevorgangs, zufällige Verzögerung, erneuter Sendeversuch Abbruch nach Maximalzahl erfolgloser Versuche Beispiele Ethernet LON (Local Operating Network) Feldbus für Gebäudeautomatisierung SoSe 2016 M. Werner 17 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 18 / 58 osg.informatik.tu-chemnitz.de CSMA/CD (Forts.) Sendewunsch CSMA/CD Randomisierung Medium frei? n Um einen Lifelock zu verhindern erfolgt Randomisierung j Senden Verzögerung Beispiel Ethernet: Binary Exponential Backoff: nach n-ter Kollision wird mit einer zufällig aus den Intervall [ n 1] gewählten Wartezeit verzögert In dieser Form nicht für (harte) Echtzeitkommunikation geeignet: Kollision? n Erfolg j Maximum? j n Zufällige Komponente verletzt Vorhersagbarkeit Keine Priorisierung möglich Keine garantierbare obere Schranke für Delay Fehler SoSe 2016 M. Werner 19 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 20 / 58 osg.informatik.tu-chemnitz.de

6 CSMA/CR Arbitrierung bei CAN Carrier Sense Multiple Access with Collision Resolution (CSMA/CR) Idee: Arbitrierung und damit Auflösung von Kollisionen Prinzip: Sender senden in Konkurenz In Abritrierungsphase setzt sich ein Sender durch (z.b. Priorität) Für Rest der Nachricht hat Sender Exklusivzugriff Voraussetzung: Propagationdelay klein gegen Bitzeit Häufig auch als CSMA/CA (... Consistent Arbitration) bezeichnet, jedoch ist diese Bezeichnung als (... Collision Avoidance) durch IEEE anders 1 definiert Beispiel: CAN (Controller Area Network) 1 Etwas irreführend, da Kollisionen nicht vermieden werden. SoSe 2016 M. Werner 21 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 22 / 58 osg.informatik.tu-chemnitz.de Token Bus / Token Ring Idee: Spezielle Steuernachricht beinhaltet das Recht zum Senden Token Prinzip: Token wird in definierter Reihenfolge weitergegeben Zeitliche Vorhersagbarkeit durch Festlegung der Zeit, die der Token bei einem Knoten verweilen darf Nicht-Echtzeit-Nachrichten können gesendet werden, wenn der Token zu früh ankommt Problem: Tokenverlust erzeugt Stillstand bis zum Erzeugen eines neuen Tokens Beispiel: IBM Token Ring (IEEE 802.5) Übertragungszeiten Tokenverfahren Entspricht Round Robin mit begrenzter Last Annahme: Token wird durch Bit im letzten Paket versendet n: Anzahl Teilnehmer p M : Pakete in Nachricht Übertragungszeit, günstigster Fall Nur ein Sender, Sendewunsch bei Tokenankunft Übertragungszeit, ungünstigster Fall t p: Dauer einer Paketübertragung s p: max. erlaubte Anzahl Pakete pro Sender+Runde t T,min = (p M + p M s p (n 1)) t p Alle senden maximal, Sendewunsch nach Tokensenden t T,max = (p M + p M s p (n 1) s p) t p SoSe 2016 M. Werner 23 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 24 / 58 osg.informatik.tu-chemnitz.de

7 Minislotting Minislotting (Forts.) Idee: Prioritäten werden auf Minislots abgebildet, die eine Nachricht vor dem Senden zu warten hat P1 SG TGI M1 TI Prinzip: Sender wartet auf Synchronization Gap Prioritätsabhängige Wartezeit abwarten Nachricht senden Timer verhindert weitere Sendungen für einen gewissen Zeitraum verhindert Blockade des Mediums durch einen Knoten Unterschiedliche Prioritäten unterschiedliche Wartezeit keine Kollisionen P2 SG TG2 TG2 M2 Beispiele: ARINC 620 (in Boeing 777) SG synchronization gap, TGx Verzögerung für x, T1 Sperrzeit Zeit SoSe 2016 M. Werner 25 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 26 / 58 osg.informatik.tu-chemnitz.de Zentraler Master TDMA Idee: Zentraler Master steuert Zugriffe auf Bus Ausfall des Master: Anderer Knoten übernimmt Rolle Funktion: Beim Systemstart wird eine statische Liste zu sendender Nachrichten generiert Enthält Namen und Perioden Im Betrieb sendet der Master periodisch Namen von Nachrichten (Polling) Knoten, der Nachricht zu senden hat, sendet diese Freie Zeit kann für sporadische Daten benutzt werden Beispiel: FIP (Factory Instrumentation Protocol) Time Division Multiple Access Idee: Zur Verfügung stehende Zeit wird statisch auf die Knoten aufgeteilt Jeder Knoten kann im eigenen Zeit-Slot senden (einmal pro Runde) Wenn keine Daten zu senden: Leeres Paket wird gesendet (damit andere Teilnehmer erkennen, dass der Knoten noch arbeitet) Problem: Genaue Uhrensynchronisation erforderlich Beispiel: TTP-A Mögliche Modifikation: Statt statischer Liste adaptiert der Master entsprechend beobachteten Bedarf SoSe 2016 M. Werner 27 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 28 / 58 osg.informatik.tu-chemnitz.de

8 FTDMA 7.4 Fallbeispiele für Echtzeitkommunikation Flexible Time Division Multiple Access Ähnlich zu TDMA Aber: Wenn ein Sender schweigt, verfällt seine Sendezeit Bei gegebener kleiner Rundendauer ist Übertragung nur für die ersten (hochprioren) Sender garantiert Man beachte: Im Unterschied zum Minislotting startet die Wartezeit nicht bei jeder höherprioren Nachricht neu, sondern wird unterbrochen Beispiele: ByteFlight, FlexRay Ein gutes Beispiel für Echtzeitkommunikation sind Feldbusse Meist in konkreten Anwendungsdomänen: Industrieprozessautomatisierung Flugzeuge Automobile Heimautomatisierung... Häufig genutzt um Aktuatoren und Sensoren mit Echtzeitrechner zu verbinden SoSe 2016 M. Werner 29 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 30 / 58 osg.informatik.tu-chemnitz.de Typische Architektur Beispiel: Feldbusse im Kraftfahrzeug Standard Netzwerk Knoten Knoten Gateway Echtzeitkommunikation Gateway Knoten Multimedia MOST D2B Karosserie CAN LIN Gateway/ Firewall Navigation Mobiltelefon Audio/Video Licht Klimaregelung Türen Schloss Spiegel Gateway Feldbusse mit Sensoren und Aktuatoren Antrieb CAN TT-CAN Fahrdynamik TT-CAN Gateway HFM Lambda Motorsteuerung Getriebesteuerung ByteFlight FlexRay ESP Brake-by- Wire Steer-by-Wire SoSe 2016 M. Werner 31 / 58 osg.informatik.tu-chemnitz.de Betrachten: CAN, TTP, ByteFlight und FlexRay Da Funktionsweise auch woanders diskutiert wird, Fokus auf Zeitverhalten SoSe 2016 M. Werner 32 / 58 osg.informatik.tu-chemnitz.de

9 Controller Area Network Entwickelt von Bosch Ende der 80er für Automobil-Industrie Benutzt in vielen, vorwiegend europäischen Autos VAG-Fahrzeuge (VW, Audi, Seat, Skoda) Volvo, Saab, Ford, GM Verschiedene Varianten und Erweiterungen Asynchroner, serieller Multimaster-Bus Topologie: Linienstruktur, Stichleitungen möglich. Datenrate: 1 MBit/s (maximal), abhängig von Buslänge Kleine Nachrichten ( Byte) Relativ hoher Overhead: 47 Bits (Standardformat) oder 67 Bits (erweitertes Format), zuzüglich Bitstuffing-Bits %./.0+!.12 Priorisierung! XR-.4.W?4$()4-8$V:+$ A-8G-.$=>+$K+Y9W8?-. Ein Identifier bestimmt neben dem Typ der Botschaft auch ihre Priorität. Niedriger Binärwert des Typs hohe Priorität Erweitertes Format Identifier ist 11 Bit, erlaubt 2048 verschiedene Nachrichtentypen. Erweitertes Format: 29 Bit Identifier ( Typen) Unterscheidung durch IDE-Bit (672 ) * + N ()4)@I.)+-, ( % " %! 7G-84*9*-. - % (H/ ()4) I*-,G /J/ & # & KLI 7BM, & ' $ ' NN$D*42 N N N E$D*42 &@O$$D14-2 N'$D*42 N N N F$D*42 P$D*42 Q.R*4.)4*:8@I*-,G /:84.:,@I*-,G ()4)@I*-,G /J/@I*-,G Q/<@I*-,G SoSe 2016 M. Werner 33 / 58 osg.informatik.tu-chemnitz.de Wer darf wann senden? Synchronisation Synchronisationsphase vor jedem Frame Fallende Flanke des SOF-Bits erlaubt Synchronisation Arbitrierung CSMA/CR Auf dem physikalischen Medium setzt sich stets logisch 0 durch (Logisch-AND) Nach SOF folgen Bits des Nachrichtentyps Während der Sendung des Typs lesen Sender den Bus Wenn ein Knoten eine 1 sendet, aber eine 0 empfängt, wird Sendung abgebrochen (Binary Countdown)!"#$%&&'$()*+,-./0.12,-.$!3-..45*"06$789:.+)4*:824-"08*;$*+$<.)949)0.=->?$@ AA$%&&'$@ BC$D-.,*8# D*424>99*8?@D-.-*"0 )*+ A4).4$L9$I.)+-6$A18"0.:8*2)4*:82=-*"0-8$!G:+*8)84#,-, J-+:4- B.)82+*22*:8$J-S>-246$C84-.2"0-*G>8?$()4)@ SoSe 2016 M. Werner >8G$J-+:4-@I.)+- 34 / 58 osg.informatik.tu-chemnitz.de (%& 7G-84*9*-. KT4-82*:86$C84-.2"0-*G>8?$=5*2"0-8$NN@D*4@ >8G$%U@D*4@7G-84*9*-.! J-2-.V- %'# ()4) H-8?40 /:G-6$Q8=)0,$()4-8R14-2$*+$()4)@I*-,G #,# /1",*" J-G>8G)8"1 /0-";2>+6$J)0+-82*"0-.>8?25:.4$=>.$I-0,-.-.;-88>8? %&' /J/@(-,*+*4-.!.-=-22*V# "#$ Q";8:5,-G?-+-846$D-24W4*?>8? %&' Q/<@(-,*+*4-.!.-=-22*V# &*+ K8G$L9$I.)+-6$K8G-=-*"0-8!F$.-=-22*V-$D*42# ( *22*:8$I*-,G Bitstuffing!P$.-=-22*V-$D*42# Problem: Stille!"#$%&'() auf dem Medium muss unterscheidbar sein Mangelnde Bitflanken erschweren Synchronisation Mehr als 5 mal 0 in Folge wird als Errorframe Bitstuffing: Wechsel nach 5 gleichen Bits *%(#%& S:.$J-+$D*424>99*8? +,-./'0 8)"0$J-+$D*424>99*8? 12345()%&! G:8@H-4>.8@B:@I-.:@<:J*-.>8?!GHI#K$JL0L$8*"04$M-J-2$D*4$N-2*4=4$-*8-$O,)8;-! (>."0$GHI@<:J*-.>8? >LCL$;-*8-$O,)8;-8$=>.$A18"0.:8*2)4*:8$"D*4$A4>99*8? 2-8J-8J-$D*49:,?-?-2-8J-4-$D*49:,?- -+T9)8?-8-$D*49:,?- 8)"0$J-+$(-24>99*8? P % P % Q E ' R P % P P % Q E ' P % P % P % Q E ' P P % P P % Q E ' P % A4>99N*4 A4>99N*4 P % P % Q E ' R P % P P % Q E ' P % Bitstuffing beeinflusst die tatsächlich Kommunikationsdauer! EF!"#$%&&'$()*+,-./0.12,-.$!3-..45*"06$789:.+)4*:824-"08*;$*+$<.)949)0.=->?$@ AA$%&&'$@ BC$D-.,*8# EF SoSe 2016 M. Werner 35 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 36 / 58 osg.informatik.tu-chemnitz.de

10 Kritik an CAN Wiederholung: Fixed Priority Scheduling Periodische Tasks Am CAN-Konzept wurden eine Reihe von Kritiken geäußert: Als ereignisgetriebener Bus nicht echtzeitfähig? Keine Redundanz bei Fehler des Mediums Protokoll und Fehlerbehandlung geben u.u. fehlerhaften Knoten erweiterte Störmöglichkeit Zu langsam für moderne Systeme Berechnung der Antwortzeit R i = C i + B i + C i Ausführungszeit einer Task j hp(i) R i T j C j B i Blocking Time (Zeit, die die Task durch niederpriore Tasks blockiert werden kann)... Zeit, die die Task durch höherpriore Tasks unterbrochen werden kann SoSe 2016 M. Werner 37 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 38 / 58 osg.informatik.tu-chemnitz.de Scheduling Längste Übertragungszeiten Berechnung von Worst Case Frame Latencies Deadlines werden relativ zur Zeit der Erzeugung eines Frames gemessen Periode ist der kürzeste Abstand zwischen der Erzeugung zweier Frames gleichen Typs Typ des Frames entspricht der Priorität Unterschied zu normalem Scheduling: Übertragung von Frames ist nicht-preemptiv Übertragungszeit ist abhängig von der Größe des Frames ( Datenbytes) Framegröße: 47 Bit Header + 8 Datenbytes + Stuffbits C i = (47 + 8s i + 8s i + 34 ) T bit 4 T bit Zeit zum Übertragen eines Bits (1 µs bei 1 MBit/s) s i Anzahl der Datenbytes SoSe 2016 M. Werner 39 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 40 / 58 osg.informatik.tu-chemnitz.de

11 Längste Wartezeit (Queuing Time) Blocking Time Wie lange dauert es, bis ein Frame die Arbitrierung gewinnen kann? Frame wird behindert durch: Gerade übertragenen Frame mit niedrigerer Priorität (Blockierung, da Senden nonpreemptiv ist) Alle Frames mit höherer Priorität (Preemption im Sinne des Scheduling-Modells) B i ist die Zeit, die der größtmögliche Frame niedrigerer Priorität zur Übertragung benötigt Nie mehr als 135 Bitzeiten B i = max (C i) 135 T bit k lp(i) SoSe 2016 M. Werner 41 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 42 / 58 osg.informatik.tu-chemnitz.de Längste Queuing Time und Latency Echtzeit: Beispiel Längste Queuing Time q i = B i + q i wird durch Iteration berechnet j hp(i) q i + T bit C j T j Frame ID Period Size WCET A ms ms B ms ms C ms ms Latenz R i = q i + C i SoSe 2016 M. Werner 43 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 44 / 58 osg.informatik.tu-chemnitz.de

12 Echtzeit: Beispiel (Forts.) Time Triggered Architecture (TTA) q B = C A + q B + T bit C C T C q (0) B = 0 q (1) B q (2) B q (3) B = T bit 1.35 = = T bit 1.35 = = T bit 1.35 = Time Triggered Architecture (TTA) Entwickelt an der TU Wien in der Gruppe von Prof. KOPETZ (früher TU Berlin). Später kommerziell verwertet von TTTech Ziel: Komponierbare Architektur für verteilte Echtzeitsysteme in sicherheitskritischen Applikationen brake-by-wire steer-by-wire... Eigenschaften: Datenrate: 25 MBit/s (Labor: 1 GBit/s) Topologie: Bus oder Stern R B = q B + C B = = 4.8 SoSe 2016 M. Werner 45 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 46 / 58 osg.informatik.tu-chemnitz.de Time Triggered Protocol Zwei Busvarianten: TTP/C: Sicherer Bus für gleichberechtigte Steuergeräte TTP/A: Abgerüstete Variante für Sensor/Aktor-Kopplung TDMA TDMA ( Folie 28) Verfügbare Zeit wird in Slots für Nachrichten eingeteilt Nachrichten fest und a priori zugeordnet Zuordnung durch MEDL (Message Descriptor List). Identische Kopie der gültigen MEDL in jedem Kommunikationscontroller Gewisse Flexibilität durch Mode-Changes SoSe 2016 M. Werner 47 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 48 / 58 osg.informatik.tu-chemnitz.de

13 Vermeidung von Babbling Idiot Robustheit Problem: Fehlerhafter Knoten sendet ständig Nachrichten und stört damit die Kommunikation Idee: Bus Guardian überwacht elektrischen Buszugriff des Knotens Funktion: Bus Guardian erlaubt Sendungen nur im Slot, der für den Knoten reserviert ist Zeit-Domäne: Uhren-Synchronisation Verstoß gegen MEDL Fehlerflag Wert-Domäne: Echtzeit-Mitgliedschaftsdienst Master-Shadow CRC-Check SoSe 2016 M. Werner 49 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 50 / 58 osg.informatik.tu-chemnitz.de Diskussion Vorteile Zeitgesteuerte Verfahren haben sich als robust herausgestellt und werden übernommen z.b. TT-CAN Kritik Braucht viel Vorherwissen Mangelnde Flexibilität ByteFlight und FlexRay Entwicklung von ByteFlight Entwicklung von BMW und Motorola ab 1996 Stern-Topologie FTDMA mit zentralen Synchronisations-Master Garantierte Latenz für definierte Anzahl hochpriorer Nachrichten Flexibler Zugriff für alle übrigen Nachrichten (asynchron) Separater logischer Kanal für Alarmmeldungen Eingegangen in FlexRay FlexRay FlexRay-Konsortium 1999 von BMW, DaimlerChrysler, Motorola und Philips gegründet. (Redundante) Bus-, Stern- oder Multi-Stern-Topologie Design-Ziel: Flexibilität SoSe 2016 M. Werner 51 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 52 / 58 osg.informatik.tu-chemnitz.de

14 75 FTDMA in ByteFlight Buszugriff: FTDMA Logisches Token wird von ID zu ID weitergegeben nach Wartezeit t wx = t 0 + t (ID x ID curr) Wartezeit ist abhängig von der Priorität der Nachricht Kombination von Vorteilen synchroner und asynchroner Protokolle Garantierte Latenz für definierte Anzahl hochpriorer Nachrichten Flexibler Zugriff für alle übrigen Nachrichten (asynchron) Separater logischer Kanal für Alarmmeldungen FlexRay Kombination aus TTP/C und ByteFlight Fehlertolerante Uhrensynchronisation (ähnlich TTP) Entkopplung des Kommunikationskontrollers (ähnlich TTP) Kommunikationszyklus besteht aus zwei Teilen: Statischer Lehrstuhl Teil: für Datenverarbeitung TDMA Dynamischer Teil: ByteFlight FTDMA Reserved NM indication Null Frame Indication 1111 Sync Bit Frame ID FlexRay Nachrichtenformat Header CRC Covered Area Length Header CRC Cycle Message ID Data 12 bits 7 bits 11 bits 6 bits 16 bits Data Bytes FlexRay Frame 5 + ( ) + 3 Bytes Data CRC CRC 24 bits Header Segment Payload Segment Trailer Segment NM Data Kombination von TDMA und Byteflight CRC SoSe 2016 M. Werner 53 / 58 osg.informatik.tu-chemnitz.de FlexRay - Datenübertragung Lehrstuhl für Datenverarbeitung Zyklus Zugriffsverfahren: mit statischen und Time dynamischen Division Multiple Segment Access (TDMA) SoSe 2016 M. Werner 54 / 58 osg.informatik.tu-chemnitz.de Diskussion TECHNISCHE UNIVERSITÄT MÜNCHEN Folie 20 Auch FlexRay wird diskutiert (insbesondere von den TTA-Verfechtern): Kein Membership-Protokoll formale Korrektheit des Synchronisationsprotokolls fragwürdig Kein spezifiziertes Fehlermodell Zu kleines Lastdatenfeld SoSeTECHNISCHE 2016 M. Werner UNIVERSITÄT 55 / 58 osg.informatik.tu-chemnitz.de MÜNCHEN Folie 21 SoSe 2016 M. Werner 56 / 58 osg.informatik.tu-chemnitz.de

15 Vergleich Anhang A: Literatur Anhang A: Literatur Eigenschaft CAN TTP-C ByteFlight FlexRay Identifizierung Msg ID Time Slot Slot Counter Time Slots & Slot Counter + Msg ID Verfahren CSMA/CA TDMA FTDMA TDMA & FTDMA Redundanz nein ja ja ja Synchronisation Sender verteilt zentral verteilt Rate 1 MBit/s 25 MBit/s 10 MBit/s 10 MBit/s Flexibilität beliebige Nachrichten eine Nachricht pro Runde und Knoten Flexible Bandbreite für Knoten Flexible Bandbreite für Knoten Topologie Bus Bus & Stern Stern Bus, Stern & Multi- Stern [Kop97] Hermann Kopetz. Real-Time Systems Design Principles for Distributed Embedded Applications. Kluver Academic, 1997, Kapitel 7 und 8 [Lui00] Jane W. S. Lui. Real-Time Systems. Prentice Hall, 2000, Kapitel 11 SoSe 2016 M. Werner 57 / 58 osg.informatik.tu-chemnitz.de SoSe 2016 M. Werner 58 / 58 osg.informatik.tu-chemnitz.de