Teil 5: EZ-Kommunikation

Vorlesung Echtzeitsysteme II
Thema 5: Echtzeitfähige Kommunikation
Robert Baumgartl
11. Januar 2016
1 / 49
Literatur
I
Jane W. S. Liu.
Real-Time Systems. Kapitel 11
Prentice Hall, 2000.
2 / 49
Überblick
I
Medienzugriffsverfahren
I
Time Triggered Architecture (TTA)
I
CAN und FlexRay
I
echtzeitfähige Protokolle fürs Internet
3 / 49
Einführung
Def. Echtzeitfähige Kommunikation sind Verfahren,
Mechanismen, Schnittstellen und Protokolle zum
Datenaustausch zwischen Aktivitäten, bei denen Garantien
bezüglich bestimmter Parameter gegeben werden können.
Wiederum kann harte und weiche Echtzeitfähigkeit
unterschieden werden.
Beispiele:
I
Telefonie
I
im Auto: CAN, FlexRay, LIN
Achtung! Fälschlich wird meist die umgangssprachliche
Definition des Begriffes „Echtzeit“ verwendet. („Twitter ist ein
Echtzeit-Kommunikationsdienst“)
4 / 49
Typische Anforderungen an Echtzeitkommunikation
Latenz einer Nachricht: Zeit zwischen Start einer
Datenübertragung in einem Knoten und Empfang der Daten an
einem anderen Knoten
primär (funktional):
I
maximale Latenz beschränkt und klein
I
minimales Jitter (Schwankung) der Latenz
I
Durchsatz garantiert
I
Deadlines von Nachrichten eingehalten
sekundär (nicht-funktional):
I
Flexibilität und Adaptierbarkeit
I
Zuverlässigkeit: Fehlererkennung und -toleranz
5 / 49
Topologie
= Struktur des (physischen) Verbindungsnetzwerkes
I
I
typisch: Bus, Ring, Stern, Baum
nicht so typisch: vollvermascht (byzantinische Generäle!)
Beispiel einer Topologie: Doppelring
Unterbrechung
Host A
Host D
Host B
Host B
Host D
Host A
Host C
Host C
Abbildung: Doppelring mit zwei
separaten Strängen
Abbildung: Umkonfiguration
zum Einfachring (nach
Unterbrechung eines Ringes)
6 / 49
Grundbegriffe
Flusssteuerung
= Regulation der Senderate in Abhängigkeit von
Geschwindigkeit des Empfängers
I
explizit: Empfänger sendet Empfangsbestätigungen
I
implizit: Empfänger und Sender einigen sich a priori auf
Übertragungszeitpunkte
7 / 49
Flusssteuerung
Explizite Flusssteuerung
Beispiel: Positive Acknowledgement and Retransmission
(PAR)1
I
I
I
Sender erhält für jedes Paket Quittung
keine Quittung nach Ablauf einer vordefinierten Zeitspanne
(Timeout) ⇒ Schlussfolgerung: Quittung oder Paket
verloren ⇒ erneuter Versuch
Abbruch, wenn maximale Anzahl Versuche fehlgeschlagen
Diskussion:
I Sender initiiert Kommunikation
I Empfänger kann Sender verzögern (wie?)
I Kommunikationsfehler auf dem Rückweg nur durch Sender
identifizierbar; Empfänger wird nicht informiert
I ineffizient; Sender muss warten, bis Quittung eingetroffen
(→ Window)
1
z. B. genutzt im TCP, HDLC
8 / 49
Flusssteuerung
Implizite Flusssteuerung
I
Empfänger und Sender stimmen über
Übertragungszeitpunkte überein
I
keine Quittungen
I
Empfänger erkennt Fehler in Datenübertragung (fehlendes
Datum zum Übertragungszeitpunkt oder Prüfsumme ergibt
Fehler)
I
Fehlertoleranz durch aktive Redundanz (n statt 1
Nachricht)
I
effizient
I
Verhalten gut determinierbar
I
⇒ gut für Echtzeitsysteme geeignet
9 / 49
Grundbegriffe
Thrashing
Phänomen: Ein bestimmter Güteparameter (Durchsatz, Latenz,
Reaktionszeit . . . ) eines Systems verringert sich abrupt, wenn
die Last einen bestimmten Schwellwert überschreitet.
Durchsatz
Maximum
ideal
Thrashing Point
real, gesteuert
real, ungesteuert
100%
Last
Abbildung: Beispiel für gesteuertes und ungesteuertes Thrashing
10 / 49
Grundbegriffe
Thrashing
darf in Echtzeit-Systemen nicht auftreten; muss also
gemanagt bzw. verhindert werden!
Thrashing-gefährdete Mechanismen:
I
Retry-Mechanismus bei Positive Acknowledgement and
Retransmission (PAR)
I
Medienzugriffsverfahren CSMA/CD
I
dynamisches Scheduling im Betriebssystem
I
Management virtuellen Speichers
I
gegenseitiges Verschmutzen von Cachelines und TLB
I
Locking
Literatur: Peter J. Denning: Thrashing. Januar 2008
http://denninginstitute.com/pjd/PUBS/ENC/thrash08.pdf
11 / 49
Problem des „Babbling Idiot“
I
in Broadcastmedien kann ein einzelner Knoten den
gesamten Datenverkehr stören, in dem er z. B.
ununterbrochen sendet (→ “Babbling Idiot”)
I
Hinzunahme eines zweiten Mediums ungünstig (teuer, was
ist, wenn der fehlerhafte Knoten beide Medien stört?)
Situation muss in echtzeitfähigen Systemen gesteuert
werden; Möglichkeiten:
I
I
I
Erkennung des fehlerhaften Knotens und Ausschluss vom
Datenverkehr
Zuteilung des Mediums durch eine zentrale Instanz
12 / 49
Medienzugriffsverfahren
Kollisionen
Problem: auf das Übertragungsmedium kann i. d. R. zu einem
Zeitpunkt nur ein Knoten schreibend zugreifen → Kollisionen
möglich.
Mögliche Strategien:
I
Vermeidung von Kollisionen durch Steuerung des Zugriffs
(collision avoidance), oder
I
Erkennung und (nachträgliche) Behebung von Kollisionen
(collision detection and resolution)
I
Medium limitiert Länge oder Abstand von Nachrichten
13 / 49
CSMA/CD
= Carrier Sense Multiple Access (with) Collision Detection
Prinzip:
I
jede Station lauscht auf Datenverkehr
I
solange Medium belegt, wird eigener Sendewunsch
verzögert
I
wenn frei und Sendewunsch → schreibender Zugriff auf
Medium
I
während des Sendens wird Medium zur
Kollisionserkennung weiter abgehört
I
Kollision: Senden des sog. Jam-Signals, Abbruch des
Sendevorgangs, zufällige Verzögerung, erneuter
Sendeversuch
I
durch endliche Signallaufzeit sind auch Kollisionen
möglich, wenn Stationen nicht gleichzeitig senden
14 / 49
CSMA/CD
Prinzip
Sendewunsch
n
Medium frei?
j
Senden
Verzögerung
j
Kollision?
n
Maximum?
n
Erfolg
j
Fehler
Abbildung: Prinzip von CSMA/CD
15 / 49
CSMA/CD
Diskussion
I
Verzögerung: Binary Exponential Backoff: n-te Kollision
wird mit einer zufällig aus den Intervall [0 . . . 2n − 1]
gewählten Wartezeit verzögert
I
Abbruch nach Maximalzahl erfolgloser Versuche (z.B. 16)
I
Kollisionsanzahl abhängig von Last (ungünstig)
I
Gefahr von Thrashing
I
Übertragungszeit einer Nachricht schlecht vorhersagbar
I
keine Priorisierung möglich, keine Garantie der
Übertragung
I
schlecht für Echtzeitkommunikation geeignet
I
viele Varianten, die Kollisionswahrscheinlichkeit reduzieren
16 / 49
CSMA/CA
I
. . . Collision Avoidance
I
nach der Erkennung eines freien Kanals wird eine zufällige
Zeitspanne gewartet, bis mit der Übertragung begonnen
wird
17 / 49
CSMA/CR
I
... Collision Resolution
I
in einer so genannten Arbitrierungsphase werden
Kollisionen erkannt und aufgelöst, indem genau 1 Sender
gewinnt und den Sendevorgang fortsetzt
I
verlierende Sender werden zufällig verzögert und
versuchen erneut
I
Beispiel: CAN (Controller Area Network)
18 / 49
CSMA/CR
Beispiel: Busarbitrierung bei CAN
I
Jede Station besitzt eine ID (11 Bit)
I
notwendig: dominanter und rezessiver logischer Zustand
des Kommunikationskanals (hier: 0 – dominant, 1 –
rezessiv)
I
beim Senden wird der Nachricht die ID der Station
vorangestellt
I
Nachricht (d. h. , zunächst Knoten-ID) wird bitweise
beginnend mit dem MSB auf den Bus geschrieben
I
rezessive Bits ‘unterliegen’; Knoten stellt Senden ein,
werden zufällig verzögert
I
es „gewinnt“ der (sendewillige) Knoten mit der kleinsten ID
I
Voraussetzung: Sendeverzögerung der Nachricht ist
kleiner als 1 Bitzeit
19 / 49
CSMA/CR
Beispiel: Busarbitrierung bei CAN
Bit
Knoten 1
Id 59C16
10 9 8
7 6 5 4
3 2 1 0
verliert
Knoten 2
Id 53716
Knoten 3
Id 53916
verliert
Bus
20 / 49
Virtual Time CSMA (VTCSMA)
Voraussetzungen
Idee: Nutzung einer individuellen Deadline zur Priorisierung
von Nachrichten
Voraussetzungen:
I
Uhren aller Knoten sind synchronisiert
I
Abhören des Mediums möglich (Carrier Sensing)
I
Nachrichten M sind durch eine individuelle Deadline DM
charakterisiert (Zeitpunkt, bis zu dem die Nachricht
empfangen sein muss).
Weitere Parameter:
I
I
I
I
τ – maximale Signallaufzeit des Netzes
TM – Zeit für das Senden einer Nachricht M
AM – Zeitpunkt des Eintreffens einer Nachricht M
21 / 49
Virtual Time CSMA (VTCSMA)
Prinzip
I
zwei Uhren auf jedem Knoten: RC, die (globale) Zeit des
Systems (Real Clock) und VC, die so genannte Virtual Clock
I
jeder Knoten hört das Medium ab und implementiert seine VC
nach folgenden Regeln:
I
I
I
wenn Kanal belegt → VC gestoppt
wenn Kanal frei → VC wird mit Wert der RC initialisiert und
läuft mit einer Rate η (eta), die höher ist als die der RC (VC
„geht vor“)
VCs der Knoten sind somit ebenfalls synchronisiert.
22 / 49
Virtual Time CSMA (VTCSMA)
Prinzip, contd.
I
jede Nachricht M besitzt als Prioritätskriterium den
spätestmöglichen Sendezeitpunkt LM , ohne ihre Deadline zu
verletzen (analog zur Slack Time von zu planenden Jobs)
LM = DM − TM − τ
I
Ein Knoten sendet eine Nachricht M, wenn das Medium frei ist
und LM ≤ VC gilt. Sind mehrere Nachrichten sendebereit, so
wird die höchstpriorisierte (kleinstes LM ) gesendet.
I
Da VC um η schneller läuft als die RC (die Realzeit), kann die
Nachricht noch rechtzeitig eintreffen (keine Garantie!).
I
Nachrichten, für die DM < RC gilt, werden verworfen, da sie ihre
Deadline nicht mehr einhalten.
23 / 49
Virtual Time CSMA (VTCSMA)
Kollisionsbehandlung
Da ggf. mehrere Knoten Nachrichten mit gleicher Priorität
versenden wollen, können Kollisionen auftreten.
Reaktion bei Detektion einer Kollision:
I
mit Wahrscheinlichkeit p: sofortiger erneuter Sendeversuch
I
mit Wahrscheinlichkeit 1 − p: Ersetzung der Priorität LM
durch einen Zufallswert aus [RC;LM ] (Priorität wird erhöht)
24 / 49
Virtual Time CSMA (VTCSMA)
Sendewunsch
n
Medium frei?
j
Initialisierung und Start
von VC
Löschen von Nachrichten
mit verpasster Deadline
Gibt es Nachricht(en) M
n
mit L_M<=VC?
j
j
Senden der Nachricht M
mit höchster Priorität
Medium frei?
n
Kollision?
n
Stop der VC
j
Erneute Übertragung oder
Modifikation der PrioritÃ¤t
25 / 49
Virtual Time CSMA (VTCSMA)
Beispiel
In einem Netz mit τ = 1 sollen die folgende 4 Nachrichten
übertragen werden.
M
AM
DM
LM
1
2
3
4
0
10
20
20
32
36
56
72
16
20
40
56
Tabelle: Beispiel zu VTCSMA
Die Übertragungszeit aller Nachrichten beträgt TM = 15. Es
gelte η = 2.
Es gilt z. B. für Nachricht 1:
L1 = D1 − T1 − τ = 32 − 15 − 1 = 16.
26 / 49
Virtual Time CSMA (VTCSMA)
Resultierende RC-VC-Trajektorie für das Beispiel mit η = 2
VC
72
64
M4
56
48
M3
40
32
24
M1
16
8
M2 verworfen!
8
16
24
32
40
48
56
64
72
RC
27 / 49
Virtual Time CSMA (VTCSMA)
Resultierende RC-VC-Trajektorie für das Beispiel mit η = 4
VC
72
64
M4
56
48
M3
40
32
24
M2
M1
16
8
8
16
24
32
40
48
56
64
72
RC
28 / 49
Virtual Time CSMA (VTCSMA)
Beispiel
Auswertung:
I
für η = 2 musste M2 verworfen werden (Ursache: im
Intervall [0;8] wurde gefaulenzt)
I
für η = 4 konnten alle 4 Nachrichten übertragen werden
Je größer Steuerungsparameter η
I
desto schneller läuft die VC im Vergleich zur RC
I
umso eher wird eine wartende Nachricht verschickt
I
umso größer die Chance, trotz Kollision die Nachricht noch
rechtzeitig zu versenden
I
umso weniger Reserve für potentiell eintreffende
Nachrichten mit kurzfristiger Deadline
(und umgekehrt)
29 / 49
Virtual Time CSMA (VTCSMA)
Fazit
I
Nachrichten werden entsprechend ihrer Deadline
priorisiert → besser als CSMA/CD
I
keine Garantie der rechtzeitigen Übertragung
I
kein Schutz gegen Überlast
Weiterführende Literatur:
I
Mart L. Molle, Leonard Kleinrock: Virtual Time CSMA:
Why Two Clocks Are Better than One. IEEE Transactions
on Communications, Vol. 33, No. 9, September 1985,
919–933
I
Wei Zhao, Krithi Ramamritham: Virtual Time CSMA
Protocols for Hard Real-Time Communication. IEEE
Transactions on Software Engineering, Vol. 13, No. 8,
August 1987, S.938–952
30 / 49
Token Passing
Ein Token ist ein exklusives Datum, dessen Besitz zum Senden
einer Nachricht autorisiert.
I
I
I
I
I
I
I
nur ein Token existiert → keine Kollisionen möglich
Token zirkuliert zwischen allen Knoten
deterministisches Zugriffsprotokoll
Besitzer des Tokens darf für eine gewisse Dauer (konstant
oder variabel) Daten übertragen und muss dann das Token
weitergeben
Topologie: gewöhnlich Ring oder Bus
tokenbasierte Protokolle sind stabil bei hoher Last
(unempfindlich gegen Thrashing)
wesentlicher Parameter: Target Token Rotation Time
(TTRT) = angestrebter Wert für einen kompletten Umlaufs
des Tokens (mit Nutzdatenübertragung an jedem Knoten)
Anwendung: Timed Token Protocol (TTP), Profibus
31 / 49
Time Division Multiple Access (TDMA)
Idee: Jeder Knoten erhält reihum
1
n
der Kommunikationszeit.
I
Voraussetzung: globale Zeitbasis
I
Für jeden Knoten ist statisch eine bestimmte Anzahl Slots
reserviert
11
00
0
1
00
11
00
11
00
11
0
1
0
1
0
1
00
11
0
1
00
11
00
11
00
11
0
1
0
1
0
00
11
0
1
00
11
00
11
001
11
01
01
0 ...
1
Slot
t
TDMA Round
I
Problem: Bandbreitenverschwendung wenn Knoten
temporär sendeunwillig
32 / 49
Minislotting
aka Flexible Time Division Multiple Access (FTDMA)
Idee:
I
alle sendewilligen Prozesse warten zunächst eine so
genannte Synchronisation Gap (SG) Stille ab
I
danach wartet jeder Prozess eine weitere (kurze)
Zeitspanne, die von Prozess zu Prozess differiert (Terminal
Gap (TG))
I
je höher priorisiert der Prozess, desto kleiner TG
I
jeder sendewillige Prozess hört gleichzeitig das Medium
ab; wenn nach Ablauf der TG kein (höherpriorisierter)
Prozess sendet, so sendet der betreffende Prozess
I
Während des Sendevorgangs wird ein Watchdog genutzt,
der das Timeout Interval (TI), das längstmögliche
Sendeintervall, eines Prozesses kontrolliert, damit dieser
nicht den Kanal okkupiert.
I
→ keine Kollisionen
33 / 49
Minislotting
Timer
3 Timer pro Prozess nötig:
I
SG – startet, sobald Stille auf dem Bus detektiert wird
I
TGi – startet nach Ablauf der SG, sofern weiterhin Stille
auf dem Bus vorliegt
I
TI – startet, sobald Prozess begonnen hat, zu senden
(d. h., nachdem TGi verstrichen ist)
Es gilt
SG > max(TGi )
und
TI > SG
Anwendungen
I
ARINC 629 (Feldbussystem für Avionik; eingesetzt in der
Boeing 777)
I
dynamisches Segment im FlexRay
34 / 49
Minislotting
Beispiel
SG
P1
P2
TI
TG1
TG2
M1
TI
TG2
M2
t
(nach Hermann Kopetz: Real-Time Systems. Kluwer, 1997,
S. 162)
35 / 49
Feldbusse
I
zur Kommunikation zwischen
I
I
Zentrale(n)
Sensoren und Aktoren
in industrieller Umgebung (mechanische Beanspruchung,
großer Temperaturbereich, Verschmutzung usw.)
I
Standard IEC 61158
I
Motivation: teure Direktverkabelung
I
statt dessen: Bus
I
VT: billiger, skalierbar
I
NT: Reaktionszeit ↑ (Thrashing!), Fehlertoleranz
problematisch
I
ca. 50 verschiedene: Profibus, CAN, LON, FlexRay,
ARINC-629, TTP (Time-Triggered Protocol), EtherCAT,
KNZ
I
Tendenz: zunehmende Basis Ethernet
36 / 49
Controller Area Network (CAN)
I
durch die Robert Bosch GmbH ab 1983 entwickelt, ab
1987 standardisiert (ISO 11898)
I
Motivation: Verringerung Verkabelungsaufwand
I
weit verbreiteter fehlertoleranter Kommunikationsstandard
für Echtzeitsysteme, insbesondere im Automotive-Bereich
I
Multicast-Protokoll, alle Knoten gleichberechtigt
I
Kollisionsvermeidung durch priorisierte bitweise
Busarbitrierung
I
11 Bit großer Identifikator pro Nachricht, der die Station
identifiziert (später: auch 29 Bit)
I
max. Datenübertragungsrate: 1 MBit/s
37 / 49
Controller Area Network (CAN)
Bit Stuffing
I
Synchronisation der Teilnehmer aus Datensignal
I
lange Folgen gleicher Bitwerte stören Synchronisation
Regel: nach 5 Bits gleichen Werts erhält das 6. Bit
(zwangsweise) den dazu inversen Wert.
I
Empfänger muss dieses Stuffing Bit wieder aus dem
Datenstrom entfernen
I
→ 6 gleichwertige Bits hintereinander bedeuten einen
Fehlerzustand (Bit Stuffing Error)
38 / 49
Controller Area Network (CAN)
Aufbau eines Frames
I
I
2 Längen: 11 und 29 Bit langer Identifier
2 Typen
I
I
Data Frame: „normaler“ Datenverkehr
Remote Data Frame: Anforderung an einen speziellen
Knoten, Daten zu senden (Bit RTR gesetzt)
39 / 49
Controller Area Network (CAN)
0
Identifier (11 Bit)
RTR
IDE
Aufbau eines (kurzen) Standard-Frames gemäß CAN 2.0A
r0 DLC (4 Bit)
DATA (0...8 Byte)
CRC
(15 Bit)
ACK EOF+IFS (10 Bit)
SOF
Feld
SOF
ID
RTR
IDE
r0
DLC
DATA
CRC
ACK
EOF+IFS
Länge
1
11
1
1
1
4
0-64
15
2
7+3
Bedeutung
Start of Frame
Kennzeichnung Station und Nachrichteninhalt
Remote Transmission Request
Identifier Extension (hier: 0)
reserved
Länge des Datenfeldes in Byte
Nutzdaten
Cyclic Redundancy Check
Bestätigung der Empfänger
End of Frame/Inter Frame Space
40 / 49
Controller Area Network (CAN)
Mechanismen zur Fehlererkennung
I
CRC im Frame
I
Positive Acknowledgement
I
Fehler in der logischen Framestruktur („Formatfehler“)
I
Bitstuffing-Fehler (mehr als 5 gleichwertige Bits)
I
Sender lauscht gleichzeitig (Monitoring); dadurch
Erkennung von Verfälschungen
41 / 49
FlexRay
Einführung
I
Motivation: größere Datenraten als CAN; mehr
Fehlertoleranz
I
Start: ca. 2000
I
Konsortium: Freescale, Bosch, NXP, BMW, VW, Daimler,
General Motors
I
direkter Konkurrent: TTP (Time-Triggered Protocol)
I
zunächst in Modellen der „Premium“kategorie (BMW X5,
Audi A8, . . . )
42 / 49
FlexRay
Technische Merkmale
I
Kommunikation über 2 physisch getrennte Kanäle á 10
MBit/s (Redundanz, Verdopplung der
Kommunikationsbandbreite)
I
Topologien: Bus, Stern, mehrere Sterne, Kombinationen
I
Austausch von Nachrichten
I
Medienzugriff: Kombination aus TDMA (statisches
Segment) und Minislotting (dynamisches Segment)
I
Stationen sind so genannte Steuergeräte (Electronic
Control Unit (ECU))
I
Bus Guardian verhindert den “Babbling Idiot”
43 / 49
FlexRay
Struktur einer ECU
ECU
µC (Host)
Power Supply
Communication
Controller
Bus
Guardian
Bus
Driver
Bus
Guardian
Bus
Driver
Abbildung: Struktur einer ECU
44 / 49
FlexRay
Kommunikationszyklus
A
B
C
D
E
Kanal 1
Kanal 2
Abbildung: Beispiel einer FlexRay-Topologie
Kanal 1
A0
Kanal 2
A1
0
B0
C0
1
C1
2
A2
D0
3
D1
4
A3
C2
A4
6
C3
7
A5
t
E0
5
statisches Segment
C4
t
dynamisches
Segment
Kommunikationszyklus
45 / 49
FlexRay
Startup frame indicator
Sync frame indicator
Null frame indicator
Payload preamble indicator
reserved
Format eines Frames
durch Header CRC gesichert
Frame ID
Payload
Length
Header CRC
Cycle
Count
11 Bits
7 Bits
11 Bits
6 Bits
Header Segment
Data 0
Data 1
Data 2
0...254 Bytes
Payload Segment
Data n
CRC
CRC
CRC
24 Bit
Trailer Segment
FlexRay-Frame: 5+(0...254)+3 Byte
(nach: FlexRay Consortium: FlexRay Communications System
Protocol Specification. Version 2.1, Revision A, 2005, S. 90)
46 / 49
FlexRay
Anmerkungen zum Frameformat
I
I
Frame ID bestimmt den Slot
Payload Length enthält Anzahl Bytes des Payload
Segmentes, dividiert durch 2
I
I
I
im statischen Segment konstant und gleich für alle Knoten
im dynamischen Segment variabel (für verschiedene
Knoten und Zyklen)
Header (20 Bit) durch extra CRC (11 Bit) geschützt;
Hamming-Distanz von 6
47 / 49
FlexRay
Synchronisation der Uhren
I
ähnlich dezentrale Mittelwertbildung (↑ EZS1)
I
“Fault-Tolerant Midpoint Averaging”
I
Broadcast der lokalen Uhren in regelmäßigen Abständen
(mittels Sync Frame)
I
Elimination der f größten und f kleinsten Uhrenwerte
I
von den verbleibenden Werten wird das arithmetische
Mittel aus Minimum und Maximum gebildet (= fault-tolerant
midpoint)
I
Jennifer Lundelius Welch, Nancy Lynch: A New
Fault-Tolerant Algorithm for Clock Synchronization.
Information and Computation, Nr. 77, 1988, S. 1–36
48 / 49
Zusammenfassung
Was haben wir gelernt?
Vor- und Nachteile von Medienzugriffsverfahren:
I
CSMA/CD
I
VTCSMA
I
Token-basierte Verfahren
I
TDMA
I
Minislotting
2 typische Beispiele für Feldbusse
I
CAN
I
FlexRay
Was fehlt?
I
Echtzeitaspekte des Internet
I
Time-Triggered Architecture (TTA)
49 / 49

Download Report