Echtzeitkommunikationskanäle für die FAMOUSO-Middleware

Otto-von-Guericke-Universität Magdeburg
Fakultät für Informatik
Institut für Verteilte Systeme
Diplomarbeit
Echtzeitkommunikationskanäle
für die FAMOUSO-Middleware
Verfasser:
Philipp Werner
31. März 2011
Hochschullehrer:
Betreuer:
Prof. Dr. rer. nat. Jörg Kaiser
Dipl.-Inform. Michael Schulze

Werner, Philipp:
Echtzeitkommunikationskanäle für die FAMOUSO-Middleware
Diplomarbeit, Otto-von-Guericke-Universität Magdeburg, 2011.

Danksagung
An dieser Stelle möchte ich allen danken, die mich während der Entstehung dieser Diplomarbeit
unterstützt haben. Dazu gehören insbesondere Michael Schulze, der die Arbeit betreut
hat, meine Frau Diana und meine Tochter Lara, die mir immer wieder neue Kraft
geben konnten, sowie Stephan Lenor, der mir mit sprachlichen und orthographischen Hinweisen
weitergeholfen hat.
Mein besonderer Dank gilt auÿerdem Prof. Jörg Kaiser und Prof. Georg Paul für ihre
Tätigkeit als Gutachter dieser Arbeit.

Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Algorithmenverzeichnis
Abkürzungen, Begrie und Notation
v
vii
ix
xi
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen und verwandte Arbeiten 5
2.1 Echtzeitsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Begri und Klassizierung . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Zeitliche Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.1 Digitale Regelung . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.2 Echtzeitplanung . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4 Verlässlichkeitsanforderungen . . . . . . . . . . . . . . . . . . . . . . 10
2.1.5 Besonderheiten verteilter Echtzeitsysteme . . . . . . . . . . . . . . . 11
2.2 Publish/Subscribe Middleware . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 FAMOUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Existierende echtzeitfähige Middlewares . . . . . . . . . . . . . . . . 14
2.3 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Basisprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Einplanbarkeitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3 Kalender und dynamische Prioritäten . . . . . . . . . . . . . . . . . 18
2.3.4 TTCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.5 FTT-CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.1 Basisprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.2 RETHER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
i

Inhaltsverzeichnis
2.4.3 RT-EP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.4 RTnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.5 FTT-Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.6 Switched Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Echtzeitkommunikationskanäle 25
3.1 Durchsetzung über TDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Wahl des Verfahrens . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Annahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3 TDMA-Zyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.4 Nicht-Echtzeit-Kommunikation . . . . . . . . . . . . . . . . . . . . . 30
3.1.4.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.4.2 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Dynamische Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Planungsproblem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Slotlänge und Übertragungsstartfenster . . . . . . . . . . . . . . . . 39
3.2.2.1 Modellierung der Slots . . . . . . . . . . . . . . . . . . . . . 39
3.2.2.2 Frame-Anzahl und -Nutzdatenmengen . . . . . . . . . . . . 42
3.2.2.3 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.2.4 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.3 Phasenverschiebungsfenster . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.4 Planung des TDMA-Zyklus' . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.4.1 Repräsentation des Plans . . . . . . . . . . . . . . . . . . . 47
3.2.4.2 Reservierung . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.4.3 Freigabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.4.4 Änderung von Anforderungen . . . . . . . . . . . . . . . . 53
3.2.5 Einussfaktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3 Reservierungsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3.1 Announcements und Subscriptions . . . . . . . . . . . . . . . . . . . 56
3.3.2 Reservierungszustände . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.3 Fehlertoleranz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.4 Verzögerung und Umordnung . . . . . . . . . . . . . . . . . . . . . . 62
3.3.5 Leasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.6 Eigenschaften des Protokolls . . . . . . . . . . . . . . . . . . . . . . 64
4 Integration in FAMOUSO 67
4.1 Echtzeitereigniskanäle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1.1 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.1.1 Zeiteigenschaften . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.1.2 Verlässlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . 70
ii

Inhaltsverzeichnis
4.1.2 Verwendung der API . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2 Umsetzung in FAMOUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.1 Echtzeit-Publisher- und Echtzeit-Subscriber-Ereigniskanal . . . . . . 76
4.2.2 Management Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2.3 Planer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2.4 Network Guard und Poll-Master . . . . . . . . . . . . . . . . . . . . 81
4.2.5 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3 Konguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3.1 Middleware-Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3.2 Planer und Poll-Master . . . . . . . . . . . . . . . . . . . . . . . . . 85
5 Evaluierung 87
5.1 Uhrensynchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2 Einplanbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Latenz und Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.1 Kommunikationslatenz und -jitter bei CAN . . . . . . . . . . . . . . 95
5.3.2 Kommunikationslatenz und -jitter bei Ethernet . . . . . . . . . . . . 98
5.3.3 Ende-zu-Ende-Latenz und -Jitter . . . . . . . . . . . . . . . . . . . . 100
5.4 Verlässlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.5 Eignung für eingebettete Systeme . . . . . . . . . . . . . . . . . . . . . . . . 103
6 Zusammenfassung und Ausblick 105
Literaturverzeichnis 109
iii

Abbildungsverzeichnis
2.1 Kontext eines Echtzeit-Computersystems . . . . . . . . . . . . . . . . . . . 7
2.2 Bus- und Sterntopologie: Verzögerungen in Warteschlangen . . . . . . . . . 12
3.1 TDMA-Zyklus und Zeitparameter von Echtzeitslots . . . . . . . . . . . . . . 28
3.2 Versand von Echtzeitnachrichten . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Versand von Nicht-Echtzeitnachrichten bei Ethernet . . . . . . . . . . . . . 33
3.4 Versand von Nachrichten bei CAN . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Synchronisierung von Produzent und Echtzeitkommunikationskanal . . . . . 38
3.6 Modellierung eines Echtzeitslots: Länge und ÜSF . . . . . . . . . . . . . . . 40
3.7 Notwendigkeit der Umplanung für optimale Planerstellung . . . . . . . . . . 47
3.8 Speicherung freier Slots bei der Planung . . . . . . . . . . . . . . . . . . . . 47
3.9 Optimierungspotential beim intuitiven Einplanbarkeitstest . . . . . . . . . . 51
3.10 Reservierungszustände eines Kommunikationskanals . . . . . . . . . . . . . 57
3.11 Reservierungszustände auf Planerseite . . . . . . . . . . . . . . . . . . . . . 60
3.12 Inkonsistenz durch nebenläuges unannounce und announce . . . . . . . . . 62
4.1 Integration in FAMOUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 Beispielkonguration des Middleware-Stacks . . . . . . . . . . . . . . . . . . 84
5.1 Wahrscheinlichkeitsverteilung der Uhrengenauigkeit . . . . . . . . . . . . . . 89
5.2 Testszenario: Knoten und ihre Kommunikationsbeziehungen . . . . . . . . . 90
5.3 Reservierungen: Ausgabe des Netzwerkplaners . . . . . . . . . . . . . . . . . 92
5.4 CPU- und Netzwerknutzung für ein RT-Event . . . . . . . . . . . . . . . . . 93
5.5 Kommunikationslatenzen bei CAN . . . . . . . . . . . . . . . . . . . . . . . 96
5.6 Kommunikationslatenzen bei Ethernet . . . . . . . . . . . . . . . . . . . . . 99
5.7 Fehlererkennung und -behandlung am Beispiel . . . . . . . . . . . . . . . . . 102
v

Tabellenverzeichnis
2.1 Vergleich von Lösungen für harte Echtzeitgarantien bei CAN . . . . . . . . 20
3.1 Zeitparameter bei CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Zeitparameter bei Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1 Testszenario: QoS-Anforderungen an die Kommunikationskanäle . . . . . . 90
5.2 Testszenario: Abstimmung der CPU- und Netzwerkplanung . . . . . . . . . 93
5.3 Kommunikationslatenzen bei CAN . . . . . . . . . . . . . . . . . . . . . . . 96
5.4 Kommunikationslatenzen bei Ethernet . . . . . . . . . . . . . . . . . . . . . 99
5.5 Ende-zu-Ende-Latenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.6 Speicherbedarf der Middleware auf einem Mikrocontroller . . . . . . . . . . 103
vii

Algorithmenverzeichnis
3.1 Einplanbarkeit: Eingrenzung des Suchfensters der Phasenverschiebung . . . . 49
3.2 Einplanbarkeit: Suche gemäÿ First-Fit-Strategie . . . . . . . . . . . . . . . . 50
3.3 Einplanbarkeit: Konikttest für eine Phasenverschiebung . . . . . . . . . . . 50
ix

Abkürzungen, Begrie und Notation
Abkürzungen
Abb. Abbildung
bzw. beziehungsweise
CAN Controller Area Network
CSMA/CD Carrier Sense Multiple Access with Collision Detection (das bei
Ethernet verwendete MAC-Verfahren)
d. h. das heiÿt
evt. eventuell
FTT-CAN Flexible Time-Triggered CAN, Protokoll
FTT-Ethernet Flexible Time-Triggered Ethernet, Protokoll
ggf. gegebenenfalls
MAC Medium Access Control (Oberbegri für Verfahren zur Steuerung des
Zugris auf ein Übertragungsmedium)
NRT Non-Real-Time (engl. für: Nicht-Echtzeit)
PEC Publisher Event Channel (engl. für: Publisher-Ereigniskanal)
QoS Quality of Service (engl. für: Dienstgüte)
RETHER Real-time ETHERnet protocol
RT
Real-Time (engl. für: Echtzeit)
RT-EP Real-Time Ethernet Protocol
SEC Subscriber Event Channel (engl. für: Subscriber-Ereigniskanal)
TDMA Time Division Multiple Access (die Zuteilung der Sendeberechtigung für
ein Übertragungsmedium erfolgt über den Fortschritt der Zeit)
TT-CAN Time-Triggered CAN, Protokoll
ÜSF Übertragungsstartfenster
vgl.
vergleiche
z. B. zum Beispiel
Begrie
Echtzeitkommunikationskanal (Kommunikationskanal) Hiermit ist ein Mechanismus
gemeint, der für die Nachrichtenübertragung zwischen einem sendenden Knoten
xi

Abkürzungen, Begrie und Notation
und beliebig vielen empfangenden Knoten eine beschränkte Latenz und geringen
Jitter garantiert, also zeitlich vorhersagbare Kommunikation zwischen den Knoten
ermöglicht. Einmal vergebene Garantien müssen unabhängig von der Belastung des
Netzwerks eingehalten werden, also auch wenn unterschiedliche Knoten gleichzeitig
viele Nachrichten über das Netzwerk versenden wollen. Abschnitt 2.1.5 beschreibt
die Problematik, Kapitel 3 die in dieser Arbeit entwickelte Lösung.
Ereigniskanal Die Publish/Subscribe-Middleware FAMOUSO liefert von Publishern
veröentlichte Events (engl. für: Ereignis, die Bezeichnung für Nachrichten bei
Publish/Subscribe) an die Subscriber aus, die sich auf dem gleichen und anderen
Knoten benden können. Das Routing bzw. die Filterung von Events basiert primär
auf Subjects und sekundär auf Kontext-Attributen. Jedem Event muss ein Subject
zugewiesen werden, über das die Bedeutung seines Inhalt zugeordnet werden
kann. Auÿerdem können Events mit Kontext-Attributen versehen werden, um für
die Filterung nutzbare Zusatzinformationen mitzuliefern. Ein Ereigniskanal ist ein
Konzept in FAMOUSO, das es erlaubt, QoS-Anforderungen für die Auslieferung
von Events zu stellen. Er stellt auÿerdem die Schnittstelle zur Anwendung dar, über
die Events jeweils eines Subjects veröentlicht oder abonniert werden können.
Echtzeitereigniskanal Ein Echtzeitereigniskanal ist ein Ereigniskanal, für den die Middleware
die Einhaltung von zeitlichen QoS-Anforderungen (Periode, Latenz, Jitter)
garantieren kann. Um diese Zusicherung auch für die Auslieferung von Events an
Subscriber auf anderen Knoten geben zu können, muss bei der Datenübertragung
ein Echtzeitkommunikationskanal verwendet werden.
Netzwerk Der Begri Netzwerk bezeichnet in dieser Arbeit einen Verbund von
Knoten (Computern), die direkt über das Übertragungsmedium kommunizieren
können, ohne dass die Nachrichten (Events) ein FAMOUSO-Gateway passieren
müssen. Letzteres dient zum Verbinden mehrerer Netze, die in dieser Arbeit als
Netzwerkverbund bezeichnet werden. Zur deutlichen Abgrenzung vom Netzwerkverbund
wird ein Netzwerk zum Teil auch als Netzwerksegment oder Subnetzwerk
bezeichnet. Es wird angenommen, dass sich alle an das Netzwerk angeschlossenen
Knoten an die Kommunikationsprotokolle von FAMOUSO halten. Dazu gehören
z. B. das in Kapitel 3 vorgestellte Echtzeitmedienzugrisprotokoll, das Fragmentierungsprotokoll
AFP oder das CAN-Kongurations- und -Bindeprotokoll zur
Vergabe der CAN-IDs.
Task und Thread Der Begri Task (engl. für: Aufgabe) wird hier als Oberbegri für eine
Einheit einer beliebig gearteten Prozessorzeitplanung verwendet. Der Begri Thread
ist hier als spezielle Ausprägung eines Tasks zu verstehen, die durch Unterbrechbarkeit
und einen eigenen Stack gekennzeichnet ist.
xii

Notation
Notation: mathematische Operationen
⌈a⌉
⌈a⌉ b
⌊a⌋
⌊a⌋ b
kgV(a, b)
max{. . . }
min{. . . }
a mod b
a mod + b
Aufrundung von a auf die nächstgröÿere Ganzzahl:
⌈a⌉ = min{x ∈ Z, x ≥ a}
Aufrundung von a auf ein Vielfaches von b: ⌈a⌉ b
= ⌈ a
b
⌉
· b
Abrundung von a auf die nächstkleinere Ganzzahl:
⌊a⌋ = max{x ∈ Z, x ≤ a}
Abrundung von a auf ein Vielfaches von b: ⌊a⌋ b
= ⌊ a
b
⌋
· b
Kleinstes gemeinsames Vielfaches von a und b
Gröÿte Zahl der angegebenen Menge
Kleinstes Zahl der angegebenen Menge
Modulo-Operation. Gibt den Rest bei Ganzzahldivision von a durch b
zurück.
Modulo-Operation mit positivem Ergebnis. Stellt auch bei negativem a
ein positives Ergebnis sicher: a mod + b = ((a mod b) + b) mod b
Notation: Formelzeichen
α Accuracy (engl. für: Genauigkeit) einer Uhr. Siehe Abschnitt 3.1.2.
d j i
Ende des Slots j des Echtzeitkommunikationskanals i (Frist zum
Abschluss der Übertragung). Siehe Abschnitt 3.1.3.
D i Ende des Slot-Rahmenintervalls. Siehe Abschnitt 3.2.1.
f i
g
Länge des Übertragungsstartfensters (ÜSF) der Slots des
Echtzeitkommunikationskanals i. Siehe Abschnitt 3.1.3 und 3.2.2.
Granularität einer Uhr, also der Realzeitabstand zweier
aufeinanderfolgender Ticks. Siehe Abschnitt 3.1.2.
G Planungsgranularität. Siehe Abschnitt 3.2.5.
l i
LB i
p i
Länge der Slots des Echtzeitkommunikationskanals i. Siehe
Abschnitt 3.1.3 und 3.2.2.
Maximale Länge der über den Echtzeitkommunikationskanal i
übertragbaren Nachrichten in Byte. Siehe Abschnitt 3.2.1.
Periode der Slots des Echtzeitkommunikationskanals i. Siehe
Abschnitt 3.1.3.
xiii

Abkürzungen, Begrie und Notation
u j i
Ende des Übertragungsstartfensters (USF) des Slots j des
Echtzeitkommunikationskanals i (Frist zum Beginn einer Übertragung).
Siehe Abschnitt 3.1.3.
v i Phasenverschiebung der Slots des Echtzeitkommunikationskanals i.
Siehe Abschnitt 3.1.3 und 3.2.4.
r j i
Beginn des Slots j des Echtzeitkommunikationskanals i (Bereitzeit des
Mediums). Siehe Abschnitt 3.1.3.
R i Beginn des Slot-Rahmenintervalls. Siehe Abschnitt 3.2.1.
Rep i
Anzahl der Wiederholungen der Nachrichten auf dem
Echtzeitkommunikationskanal i (für CAN: maximale Anzahl). Siehe
Abschnitt 3.2.1.
z k Zeitpunkt eines TDMA-Zyklus-Beginns. Siehe Abschnitt 3.1.3.
Z Länge des TDMA-Zyklus'. Siehe Abschnitt 3.1.3.
xiv

1 Einleitung
1.1 Motivation
Computer sind heute allgegenwärtig, nicht nur auf dem Schreibtisch oder in der Hosentasche,
zum Arbeiten oder als Multimedia-Gerät. In einem aktuellen Auto der Mittelklasse
sind mit seit langem steigender Tendenz mehr als 70 Mikrocontroller verbaut (vgl.
[NL08, S. 1-1]), die über Kommunikationsnetzwerke miteinander verbunden sind. Einige
werden für reine Komfortfunktionen, wie elektrische Fensterheber oder Sitzversteller, eingesetzt.
Neben dem Komfort dienen viele der Verbesserung der Sicherheit. Beispielsweise
löst das Airbag-Steuergerät bei einem Unfall Airbags und Gurtstraer aus, um die Insassen
vor schwereren Verletzungen zu schützen. Andere Systeme sollen bei der Vermeidung
von Unfällen helfen. Einige Assistenzsysteme unterstützen den Fahrer, indem sie ihn
vor möglichen Gefahrensituationen warnen, wie dem ungewollten Verlassen einer Fahrspur.
Andere greifen aktiv in die Fahrzeugdynamik ein, wie das Antiblockiersystem (ABS),
das Elektronische Stabilitäts-Programm (ESP) oder die Abstands- und Geschwindigkeitsregelung
(ACC, Adaptive Cruise Control). Auch zur Steuerung des Motors wird komplexe
Elektronik eingesetzt, um die Ezienz im Interesse von Kraftstoverbrauch und Leistung
zu optimieren.
Die meisten der Funktionen haben Echtzeitanforderungen, das heiÿt es ist nicht nur
entscheidend was sie tun, sondern auch wann sie es tun. Beispielsweise muss das Airbag-
Steuergerät einen kritischen Unfall über seine Sensorik in Sekundenbruchteilen erkennen,
um die Airbags im richtigen Moment auslösen zu können. Sowohl zu frühes als auch zu
spätes Auslösen führen eher zu zusätzlichen Verletzungen, als die Insassen zu schützen.
Die zeitliche Vorhersagbarkeit und Vorherbestimmbarkeit des Systems ist also essentiell,
damit das System seiner Aufgabe gerecht wird. Da das Versagen des Systems katastrophale
Folgen haben kann, ist es auch wichtig, dass es sehr zuverlässig arbeitet. Es darf die
Airbags über mehrere unfallfreie Jahre hinweg nicht fälschlicherweise auslösen und muss
im entscheidenden Sekundenbruchteil voll funktionstüchtig sein.
Echtzeit- und sicherheitskritische Steuerungen und Regelungen nden sich nicht nur im
Automobil. In der Prozessautomatisierung, in Flugzeugen, Schienenfahrzeugen, der Raumfahrt
und der Energietechnik sind sie schon seit langem unverzichtbar. Und auch die meisten
Robotik-Anwendungen sind Echtzeit- und sicherheitskritisch (vgl. [Lun08, S. 23.]).
1

1 Einleitung
Regelungen und Steuerungen werden zunehmend mit digitaler Elektronik realisiert. Zum
Einen liegt das an den schnellen Fortschritten in Leistungsfähigkeit, Robustheit und Zuverlässigkeit
der Hardware bei sinkenden Kosten. Zum Anderen erönet die Programmierbarkeit
der Systeme ganz neue Möglichkeiten gegenüber analogen, mechanischen oder hydraulischen
Systemen. Über die Software können leicht beliebig angepasste Algorithmen
eingesetzt werden. Auÿerdem lassen sich die Komponenten ohne groÿen Verkabelungsaufwand
über Kommunikationsnetzwerke verbinden, um Sensordaten gemeinsam nutzen zu
können oder auf andere Weise zu kooperieren (vgl. [NL08, S. 1-3]).
Ein System aus vernetzten Rechner-Komponenten, die die gewünschte Funktionalität im
Zusammenspiel erbringen, nennt man verteiltes System. Hierbei spielt nicht nur die Kooperation
der Komponenten eine Rolle. Verteilte Systeme bieten auch gute Möglichkeiten,
Mechanismen der Fehlertoleranz einzusetzen, um die Zuverlässigkeit des Systems zu
steigern. Beispielsweise lassen sich durch Replikation von Komponenten Fehler maskieren,
so dass sie nicht zu einem Funktionsausfall des Gesamtsystems führen. Ein weiterer
Vorteil ist die Kapselung von Funktionalität in Komponenten mit klar denierten
Schnittstellen. Dies erleichtert die Entwicklung und fördert die Erweiterbarkeit des Systems
und Wiederverwendbarkeit seiner Bestandteile. Verteilte Systeme bringen jedoch
auch Herausforderungen mit sich, insbesondere im Bereich der Echtzeitsysteme. Durch
die Kommunikation zwischen den Komponenten entstehen zusätzliche Verzögerungen und
neue potentielle Fehlerquellen, wie Zugriskonikte und Stauungen im Kommunikationsnetz.
Jene Fehler müssen verhindert werden, um die Echtzeitfähigkeit des Gesamtsystems
garantieren zu können.
Die Entwicklung von verteilten Echtzeitanwendungen kann deutlich vereinfacht werden,
wenn eine Middleware eingesetzt wird, bei der die Details der Echtzeitkommunikation
hinter einer Schnittstelle gekapselt sind. Die adaptierbare Middleware
FAMOUSO [Sch09, Sch] bietet inhaltsbasierte Publish/Subscribe-Gruppenkommunikation
für verschiedene Netzwerke und Plattformen, unter anderem auch für ressourcenbeschränkte
8-Bit-Mikrocontroller. Die bereitgestellten Dienste sind über eine einheitliche API von
verschiedenen Programmiersprachen und Ingenieurtools aus verwendbar. In der vorliegenden
Arbeit soll diese Middleware um Echtzeitkommunikationskanäle erweitert werden.
1.2 Aufgabenstellung
Die Publish/Subscribe-Middleware FAMOUSO unterstützt bisher ausschlieÿlich Best-
Eort-Kommunikationsverhalten. Um sie auch für die Entwicklung verteilter Echtzeitsysteme
nutzbar zu machen, soll sie in dieser Diplomarbeit um Echtzeitkommunikationskanäle
erweitert werden.
2

1.3 Gliederung
Der Nutzer der Middleware soll für jeden Echtzeitereigniskanal individuelle Dienstgüteanforderungen
gemäÿ der jeweiligen Anwendung spezizieren können. Die zentrale Zielstellung
ist es, Garantien für die Kommunikation gemäÿ der angefragten Dienstgüte (engl.:
Quality of Service, QoS) geben zu können. Auf Basis dieser Zusicherungen soll FAMOUSO
es einfach machen, zuverlässige verteilte Echtzeitsysteme zu entwickeln.
Die Echtzeitkanäle sollen sich nahtlos in FAMOUSO und dessen Konzepte integrieren.
Vorgegeben ist die Verwendung des Publish/Subscribe-Modells, die mit der Unterstützung
von n-zu-m Gruppenkommunikation einher geht. Auÿerdem soll auch im Echtzeitbereich
spontane Kommunikation möglich sein, das heiÿt die Middleware muss die Echtzeitkanäle
autonom zur Laufzeit etablieren können. Nicht reservierte Netzwerkressourcen sollen für
die Best-Eort-Kommunikation genutzt werden. Für die Implementierung ist eine hohe
Kongurierbarkeit zur Compile-Zeit gefragt. Diese dient im Wesentlichen dem Zweck, den
Ressourcenverbrauch für eingebettete Systeme zu minimieren. Es wird angestrebt, die
Echtzeitkanäle auch auf einem 8-Bit-Mikrocontroller einsetzen zu können, beispielsweise
für Smart Sensors.
Die Arbeit konzentriert sich auf die Bereitstellung von Garantien für die Echtzeitkommunikation
über CAN (Controller Area Network [Rob91]) und dediziertes Ethernet [iee08].
Hierzu wird vor allem die Koordination der Netzwerkzugrie behandelt. Die echtzeitfähige
Zuteilung der Rechenzeit auf den einzelnen Knoten wird als gegeben angenommen.
1.3 Gliederung
Im folgenden Kapitel werden Grundlagen und verwandte Arbeiten vorgestellt. Am Beginn
steht dabei ein Überblick zu allgemeinen Aspekten von Echtzeitsystemen. Anschlieÿend
werden Publish/Subscribe-Middlewares sowie CAN und Ethernet thematisiert, wobei vor
allem auf den Kontext der verteilten Echtzeitsysteme eingegangen wird. In Kapitel 3 wird
das erarbeitete Konzept zur Koordination des Medienzugris erläutert. Es umfasst einen
neuen echtzeitfähigen Medienzugrismechanismus, die dafür erforderliche Planung zur
Laufzeit, sowie ein Kommunikationsprotokoll, das den zur dynamischen Planung nötigen
Informationsaustausch regelt. Die Integration des Konzepts in die Middleware FAMOUSO
wird in Kapitel 4 behandelt. Hierbei wird auch auf ausgewählte Aspekte der Implementierung
eingegangen. Es folgt in Kapitel 5 eine Auswertung der Ergebnisse anhand von Messungen,
die mit der Implementierung durchgeführt wurden. Das abschlieÿende Kapitel 6
fasst die Arbeit zusammen. Es gibt auÿerdem einen Ausblick für mögliche weiterführende
Arbeiten.
3

2 Grundlagen und verwandte Arbeiten
Dieses Kapitel gibt zunächst eine Einführung in Echtzeitsysteme und deren für diese
Arbeit relevanten Aspekte. Abschnitt 2.2 behandelt kurz das Thema Publish/Subscribe-
Middlewares. In den Abschnitten 2.3 und 2.4 werden die Netzwerke CAN und Ethernet
vorgestellt, für welche die Echtzeitkanäle realisiert werden sollen. Dabei wird auf existierende
Lösungen zur echtzeitfähigen Kommunikation eingegangen.
2.1 Echtzeitsysteme
2.1.1 Begri und Klassizierung
Ein Echtzeit-Computersystem ist ein Computersystem, bei dem die Korrektheit des
Systemverhaltens nicht nur von der logischen Korrektheit der erbrachten Funktionalität
abhängt, sondern auch von der Einhaltung konkreter zeitlicher Anforderungen (vgl.
[Kop97]).
Oft wird der Begri Echtzeit missbräuchlich verwendet, um zu vermitteln, dass bei einer
Aktivität des Computers keine vom Menschen wahrnehmbaren Verzögerungen auftreten.
Der zentrale Aspekt eines Echtzeitsystems ist hingegen nicht die Schnelligkeit bei der
Erfüllung einer Aufgabe, sondern die Vorhersagbarkeit des Verhaltens. Auch ein System,
das eine halbe Stunde rechnet, bevor auf ein Ereignis reagiert wird, kann ein Echtzeitsystem
sein, wenn die halbe Stunde innerhalb der zeitlichen Anforderungen liegt. Andererseits
muss ein beliebig performantes System nicht unbedingt echtzeitfähig sein, denn die
zeitlichen Anforderungen müssen auch unter hoher Last und beim Auftreten von Fehlern
eingehalten werden.
Die Echtzeitfähigkeit eines Systems lässt sich erst einschätzen, wenn die konkreten
zeitlichen Anforderungen bekannt sind. Auf diese wird in Abschnitt 2.1.3 weiter eingegangen.
Auÿerdem sind Annahmen zur maximalen Last und zu den Fehlern nötig, unter
denen das System seine Aufgabe korrekt erfüllen kann. Die Fehlerannahme im Zusammenhang
mit den Verlässlichkeitsanforderungen wird in Abschnitt 2.1.4 genauer behandelt.
Abschnitt 2.1.2 geht kurz auf typische funktionale Anforderungen von Echtzeitsystemen
ein.
5

2 Grundlagen und verwandte Arbeiten
Gemäÿ der zu erfüllenden Aufgaben lassen sich Echtzeitsysteme in folgende Klassen einteilen:
Harte Echtzeit (engl.: hard real-time): Man spricht von einem harten Echtzeitsystem,
wenn die Verletzung von zeitlichen Anforderungen (Zeitfehler) katastrophale Konsequenzen
haben kann (vgl. [Kop97]). So insbesondere, wenn die Sicherheit von Menschen
gefährdet ist, aber auch wenn andere immense Schäden drohen. Daher müssen
in diesen Systemen Zeitfehler unter allen Umständen vermieden werden.
Beispiele sind der Autopilot eines Flugzeugs, der die Maschine bei einem Fehler zum
Absturz bringen könnte oder die Steuerung eines Roboters, in dessen Arbeitsbereich
sich auch Menschen bewegen. Die meisten klassischen Aufgaben sind Steuerungsund
Regelungsaufgaben.
Weiche Echtzeit (engl.: soft real-time): Kann die Verletzung von zeitlichen Anforderungen
in gewissem Maÿe toleriert werden, handelt es sich um weiche Echtzeitanforderungen.
Durch Zeitfehler wird hier nur die Güte des erbrachten Dienstes
(Quality of Service) reduziert, ohne dass es zu einem kritischen Fehler des
Systems kommt, durch den katastrophale Folgen drohen.
Typisch für diese Kategorie sind Multimediaanwendungen, wie Video-Streaming, bei
denen eine verringerte Qualität bei der Wiedergabe toleriert werden kann.
Nicht-Echtzeit (engl.: non-real-time, abgekürzt NRT): Aufgaben, bei denen die Korrektheit
der Ausführung von keinen zeitlichen Bedingungen abhängt, sind der Klasse
der Nicht-Echtzeit-Aufgaben einzuordnen. Hierzu gehören beispielsweise die meisten
Anwendungen des PC (Personal Computer) im Heim- und Büro-Bereich, wie
Textverarbeitung. Aber auch in Echtzeitsystemen gibt es Aufgaben ohne Echtzeitanforderungen,
die in diese Kategorie fallen, wie Diagnose und Wartung.
Es existieren auch weitergehende und anders akzentuierte Klassizierungen von
Echtzeitaufgaben. Beispielsweise wird in [Coo03, S. 6f.] neben der Kritikalität der Zeitanforderungen
(hart vs. weich) hinsichtlich der Rechenzeiten zwischen schneller und
langsamer Echtzeit unterschieden. Bei langsamen Echtzeitsystemen, deren Fristen über
einer Sekunde liegen, sieht Cooling die Herausforderungen eher bei der Komplexität
der Systeme. Hingegen sind schnelle Echtzeitsysteme meist deutlich kleiner, so dass die
wesentliche Schwierigkeit hier darin liegt, die nötigen Berechnungen innerhalb der sehr
kurzen Fristen abschlieÿen zu können. Bei [KN98] werden die drei oben angegeben Kategorien
um eine weitere ergänzt. In dieser ist die Verletzung der zeitlichen Anforderungen
ebenso kritisch wie bei harter Echtzeit, es ist jedoch tolerierbar, wenn später mit der
Ausführung der Aufgabe begonnen wird.
Diese Arbeit beschäftigt sich zentral mit harten Echtzeitanforderungen, mit und ohne
exibler Startzeit. Daher ist im folgenden Text mit dem Begri Echtzeit immer harte
Echtzeit gemeint, wenn keine genauere Klassizierung auftaucht.
6

2.1 Echtzeitsysteme
Sensoren
Umwelt Computer Mensch
Aktoren
Abbildung 2.1: Kontext eines Echtzeit-Computersystems
2.1.2 Funktionale Anforderungen
Harte Echtzeitsysteme werden in der Regel zur Steuerung 1 , Regelung 2 oder Überwachung 3
von physikalisch ablaufenden Prozessen eingesetzt. Dabei interagieren sie mit der Umwelt.
Die Schnittstelle zur Umwelt wird durch Sensoren und Aktoren hergestellt (siehe Abb. 2.1).
Sensoren (engl.: sensors) liefern Informationen über den Zustand der Umwelt, indem sie
physikalische Gröÿen messen, wie etwa Spannung, Kraft, Temperatur, Konzentration oder
Beschleunigung. Um im Rechner verarbeitet werden zu können, müssen die Signale digitalisiert
und aufbereitet werden. Bei Smart Sensors geschieht das bereits in der Sensorkomponente,
in die ein Mikrocontroller integriert ist. Dieser ist meist über eine standardisierte
Schnittstelle, wie ein Feldbussystem (z. B. CAN), mit dem Computer verbunden. Die Aufbereitung
von Sensordaten umfasst eine Rauschminderung, beispielsweise über Mittelwertbildung,
die Wandlung des Sensor-Signals, z. B. einer Spannung, in einen Messwert mit
einer Standard-Maÿeinheit und eine Plausibilitätsprüfung, um einen Defekt des Sensors
zu erkennen.
Aktoren (engl.: actuators) dienen der gezielten Beeinussung der Umwelt des Rechnersystems,
indem beispielsweise eine Bewegung initiiert, eine Temperatur verändert oder Licht
oder Schall ausgesendet wird. Typische Aktoren sind Elektromotoren, Bimetallaktoren,
Lampen oder Lautsprecher. Die Ansteuerung der Komponenten erfolgt über spezielle
Strom- und Spannungssignale, die im Rechner und der externen Beschaltung erzeugt werden,
beispielsweise über Pulsbreitenmodulation. Smart Actuators erleichtern die Ansteuerung,
indem sie die Eigenarten des Aktors in der Komponente kapseln und wie Smart
Sensors eine einfachere digitale Schnittstelle anbieten.
1
Die Steuerung bezeichnet die gezielte Beeinussung eines Prozesses, ohne den tatsächlichen Zustand zu
beobachten bzw. einzubeziehen.
2
Eine Regelung misst die Abweichung des gemessenen Ist-Werts vom Soll-Wert und beeinusst den Prozess
so, dass der Ist-Wert stehts in Richtung des Soll-Werts führt. Durch die Einbeziehung der Beobachtung
des Prozesses, können Störungen kompensiert werden, die bei einer Steuerung unbemerkt bleiben. Für
Details zur Regelungstechnik siehe z. B. [Sch10a].
3
Die Überwachung dient z. B. zur Meldung von unnormalem Prozessverhalten an einen Anlagenführer,
damit dieser die Ursache der Störung suchen kann.
7

2 Grundlagen und verwandte Arbeiten
Die Verbindung zwischen Sensoren und Aktoren stellt das Rechnersystem her. Es verarbeitet
Informationen über die Umwelt und steuert die Aktoren an, um bestimmte Eekte
in der Umwelt zu erzielen. Da sich die Umwelt über die Zeit verändert, muss das Auslesen
der Sensoren, die Verarbeitung und die Ansteuerung der Aktoren fortlaufend wiederholt
werden.
Oft verfügt das Rechnersystem auch über eine Mensch-Maschine-Schnittstelle, die über
Wartungsfunktionalität hinausgeht. Typisch ist, dass der Mensch Aktionen oder Soll-Werte
vorgibt, Entscheidungen in schwierigen kritischen Situationen trit oder dass ein Log des
Prozessablaufs abgelegt wird, um später Ursachen für Probleme nden zu können. Da die
Echtzeitanforderungen meist unter den menschlichen Reaktionszeiten liegen, müssen die
Systeme jedoch immer zu einen hohen Grad autonom agieren können.
2.1.3 Zeitliche Anforderungen
Für ein Echtzeitsystem ist Rechtzeitigkeit (engl.: timeliness) entscheidend, d. h. alle Aktionen
müssen zur jeweils richtigen Zeit ausgeführt werden. Diese zeitlichen Anforderungen
werden durch die zu erfüllende Aufgabe und deren Dynamik bestimmt. Meist wird
mit einem Echtzeitsystem ein physikalischer Prozess, an dem reale Objekte beteiligt sind,
beobachtet und gezielt beeinusst. Da der Prozess den Naturgesetzen unterworfen ist, gibt
dieser das Tempo vor, dem sich der Computer anpassen muss. Der Zustand der Objekte ändert
sich als Funktion der realen Zeit (Echtzeit). Daher sind vom Computer beobachtete
Zustände nur Momentaufnahmen der Realität, d. h. die Daten haben nur eine zeitlich
begrenzte Gültigkeit. Beispielsweise kann der Beobachtung die Ampel zeigt grün nicht
beliebig lange getraut werden.
Bei einem Ereignis, also einer Änderung des Systemzustands, muss innerhalb einer
beschränkten Zeitspanne die angemessene Reaktion erfolgen. Beim Ereignis die Ampel
springt auf gelb muss in einem Auto entschieden werden, ob gebremst oder die Kreuzung
noch überfahren werden soll. Die Entscheidung und die Reaktion müssen rechtzeitig erfolgen,
damit das Auto noch vor der Kreuzung zum Stehen kommen kann. Wenn nicht
rechtzeitig, also zur richtigen Zeit, reagiert wird, kann dies den gleichen Eekt haben wie
keine oder die falsche Reaktion und zu einem Unfall führen. In einem Echtzeitsystem sind
also die zeitlichen Anforderungen genau so wichtig, wie die funktionalen.
2.1.3.1 Digitale Regelung
In digitalen Regelkreisen ist ein wichtiger zeitlicher Parameter die Abtastperiode P s (engl.:
sampling period). Sie gibt die Zeit zwischen zwei aufeinanderfolgenden Abtastungen der
Regelgröÿe an, also die Zeit zwischen zwei nacheinander zur Regelung verwendeten Sensorwerten.
Wie P s zu wählen ist, hängt von der Dynamik des zu regelnden Prozesses ab.
Während bei einer Temperaturregelung einer Wohnraum-Heizung eine Abtastperiode von
8

2.1 Echtzeitsysteme
mehreren Sekunden bis Minuten ausreichen würde, muss für die Drehzahlregelung eines
Motors etwa jede Millisekunde eine Drehzahlmessung durchgeführt werden, um ein neues
Stellsignal zu berechnen. Nach [Sch10a, S. 98f.] sollte die Abtastfrequenz etwa 6- bis 10-
mal so groÿ sein, wie die höchste im System vorkommende Frequenz. In [Kop97, S. 7]
wird empfohlen, die Abtastperiode kleiner als ein Zehntel der Anstiegszeit der Sprungantwort
des Systems zu wählen. Wird die Abtastperiode zu groÿ gewählt, ist ein schlechtes
Führungsverhalten die Folge, d. h. die Regelung wird ihrer Aufgabe schlecht oder gar nicht
gerecht. Kleinere Perioden erfordern leistungsstärkere Hardware und erhöhen damit die
Kosten des Systems.
Ein weiterer Parameter ist die durch das Computersystem verursachte Verzögerung d comp
zwischen der Beobachtung eines Ereignisses am Sensor und der Veranlassung der Reaktion
am Aktor. Die Dierenz des gröÿten und kleinsten auftretenden Wertes von d comp nennt
man Jitter von d comp . Für die Regelgüte ist es wichtig, dass der Jitter möglichst klein ist,
d. h. d comp muss nach Möglichkeit konstant sein. Der Grund hierfür ist, dass Regelungsalgorithmen
in der Lage sind, eine bekannte Verzögerung auszugleichen. Wenn die Verzögerung
jedoch variiert und nicht genau bekannt ist, entstehen zusätzliche Messfehler im Ist-Wert,
die sich negativ auf die Regelgüte auswirken (vgl. [Kop97, S. 9]).
Um der Forderung nach hoher Verlässlichkeit im Echtzeitsystem gerecht zu werden, ist
es auÿerdem nötig, Defekte so schnell wie möglich zu erkennen, um rechtzeitig darauf
reagieren zu können und Funktionsausfälle zu verhindern. Daher ist auch die Fehlererkennungslatenz
eine wichtige Gröÿe.
2.1.3.2 Echtzeitplanung
In komplexen Echtzeitsystemen fallen in der Regel gleichzeitig verschiedene Regelungsund
Steuerungsaufgaben an. Sobald mehrere Aufgaben (engl.: tasks) auf einem Prozessor
abgearbeitet werden sollen, muss die Vergabe der Rechenzeit geplant werden. Dabei
müssen die zeitlichen Anforderungen der einzelnen Tasks eingehalten werden, um jederzeit
die Echtzeitfähigkeit des Gesamtsystems garantieren zu können.
Ein Task hat folgende Zeitparameter:
• Die Bereitzeit r (engl.: ready time) bezeichnet den frühsten erlaubten Ausführungszeitpunkt.
• Die Frist d (engl.: deadline) gibt den Zeitpunkt an, bis zu dem der Task vollständig
ausgeführt worden sein muss.
• Für periodisch wiederholte Tasks gibt die Periode p (engl.: period) die Zeit zwischen
zwei aufeinanderfolgenden Bereitzeiten an.
• Die tatsächliche Ausführung beginnt zur Startzeit s (engl.: start time).
9

2 Grundlagen und verwandte Arbeiten
• Die Abschlusszeit c (engl.: completion time) gibt an, wann die Ausführung tatsächlich
beendet ist.
• Die Zeitspanne, über die der Task tatsächlich auf dem Rechner ausgeführt wird,
nennt man Ausführungszeit e (engl.: execution time). Sie kann durch Wartezeiten
unterbrochen werden.
Die zeitlichen Anforderungen werden über die Periode, die Bereitzeit, die Frist und die Ausführungszeit
deniert. Ein Echtzeitplanungsalgorithmus muss anhand dieser Kenngröÿen
einen überschneidungsfreien Ausführungsplan festlegen, der für jeden Task in jeder Periode
garantiert, dass r ≤ s und c ≤ d. In [ZA95] oder [Hüs94] werden verschiedene
Echtzeitplanungsverfahren detailliert vorgestellt und verglichen.
Die echtzeitfähige Planung der lokalen Rechenzeit wird in dieser Diplomarbeit als gegeben
angenommen. Die Formalismen der Taskplanung können jedoch auf das Planungsproblem
für ein gemeinsam genutztes Netzwerk übertragen werden.
2.1.4 Verlässlichkeitsanforderungen
Verlässlichkeit (engl.: dependability) bezeichnet die Vertrauenswürdigkeit eines Systems,
also inwieweit das an der Systemschnittstelle beobachtete Verhalten mit der Spezikation
übereinstimmt. Eine Verletzung der Spezikation wird als Funktionsausfall (engl.: failure)
bezeichnet.
Die Verlässlichkeit eines Systems lässt sich über folgende Teilaspekte einschätzen (vgl.
[ALRV00, Kop97]):
• Überlebensfähigkeit (engl.: reliability) bezeichnet die Wahrscheinlichkeit, dass ein
System den Dienst während einer Zeitspanne (t 0 , t) wie speziziert bereitstellt, d. h.
es in der gesamten Zeit keinen Funktionsausfall gibt.
• Betriebssicherheit (engl.: safety) ist die Überlebensfähigkeit bezüglich Funktionsausfällen,
die eine Gefährdung für die Umwelt mit potentiell katastrophalen Folgen
darstellen. Folglich entspricht sie der Wahrscheinlichkeit, dass während einer
Zeitspanne (t 0 , t) kein gefährdender Funktionsausfall passiert.
• Die Wartbarkeit (engl.: maintainability) ist ein Maÿ für die Zeit, die zur Reparatur
oder Modikation eines Systems nötig ist.
• Unter Verfügbarkeit (engl.: availability) versteht man die Wahrscheinlichkeit, das
System zu einem Zeitpunkt funktionsfähig anzutreen.
• Die Informationssicherheit (engl.: security) bezeichnet den Schutz des Systems
vor unberechtigtem Zugri auf Informationen (Vertraulichkeit) sowie vor unberechtigter
Beeinussung des Systems (Integritätssicherung).
10

2.1 Echtzeitsysteme
Je nach Anwendung können die einzelnen Attribute in verschiedenem Maÿe wichtig sein.
In der Fabrikautomatisierung steht beispielsweise die Verfügbarkeit im Mittelpunkt, da
still stehende Produktionsmaschinen keinen Gewinn erwirtschaften können. Ein Roboter,
der auf eine unbemannte Weltraummission geschickt wird, ist hingegen auf die Überlebensfähigkeit
hin optimiert, da Reparaturen am Gerät dort nicht möglich sind. Für sehr viele
Echtzeitsysteme ist die Betriebssicherheit ein sehr wesentlicher Aspekt. Man nennt sie
auch sicherheitskritische (engl.: safety-critical) Systeme. Eine Voraussetzung für hohe Betriebssicherheit,
Überlebensfähigkeit oder Verfügbarkeit ist auch immer der Schutz vor
nicht autorisierter Manipulation der Systeme (Integritätssicherung).
Viele Fehlerursachen (engl.: faults), die zu Funktionsausfällen führen könnten, lassen sich
während der Entwicklung und der Herstellung vermeiden, beispielsweise durch Qualitätskontrolle
(vgl. [ALRV00]). Da sich aber nicht alle Fehlerursachen ausschlieÿen lassen, sind
für verlässliche Systeme Fehlertoleranzmechanismen (engl.: fault tolerance) nötig. Sie ermöglichen
es, Defekte in einem gewissen Umfang zu tolerieren, ohne dass es zu einem
Funktionsausfall kommt. Alle Fehlertoleranzmechanismen basieren auf Redundanz. Man
unterscheidet Informationsredundanz (fehlererkennende oder -korrigierende Codes), Komponentenredundanz
(mehrfaches Vorhandensein von Komponenten gleicher Funktion) oder
Zeitredundanz (mehrfaches Ausführen einer Aktion). Eine Möglichkeit zum Erreichen von
Fehlertoleranz ist die explizite Fehlerbehandlung auf Basis einer Fehlererkennung, beispielsweise
das erneute Versenden eines beschädigten Datenpakets (dynamische Redundanz).
Die Alternative ist die Maskierung von Fehlern mit Hilfe statischer Redundanz, z. B. das
mehrfache Verschicken desselben Pakets. In vielen sicherheitskritischen Systemen ist eine
mögliche Fehlerbehandlung das Einnehmen eines sicheren Zustands, der eine Gefährdung
der Umgebung ausschlieÿt (fail-safe system). Existiert kein sicherer Zustand, muss das
System seinen Dienst auch bei einem Funktionsausfall mit einer gewissen minimalen Güte
aufrecht erhalten (fail-operational system).
Zur Spezikation eines Echtzeitsystems gehört neben funktionalen und zeitlichen Aspekten
auch eine Fehlerhypothese [Kop04]. Diese umfasst die Annahmen zur Art und Anzahl
der Fehler, die das System tolerieren können muss. Sie ist Basis für die Wahl der Fehlertoleranzmechanismen
im Systemdesign und unverzichtbar für die Validierung und eventuell
angestrebte Zertizierung des Systems. Es ist auch wichtig zu überprüfen, inwieweit die
getroenen Annahmen mit der Realität übereinstimmen. Aber auch für Fehlersituationen,
die nicht von der Fehlerhypothese abgedeckt werden, sollte es bei sicherheitskritischen
Systemen eine Behandlungsstrategie (never-give-up strategy) geben.
2.1.5 Besonderheiten verteilter Echtzeitsysteme
Ein verteiltes System besteht aus mehreren vernetzten Computern auch Knoten (engl.:
nodes) genannt die eine gemeinsame Aufgabe im Zusammenspiel erfüllen. Die Computer
tauschen dabei mittels Nachrichten Informationen aus, die über das Netzwerk verschickt
11

2 Grundlagen und verwandte Arbeiten
(a) Bustopologie: Verzögerungen im Sendeknoten
durch Zugriskonikte und evt. daraus
folgender Stauung.
(b) Sterntopologie: Verzögerungen
im Zentrum durch Stauung an der
Verbindung zum Empfänger.
Knoten
Verkabelung
Warteschlange
Vermittlungsknoten
(c) Legende
Abbildung 2.2: Netzwerktopologien. In den abgebildeten Sende-
Warteschlangen kann es zu problematischen Verzögerungen kommen.
werden. Hierbei entstehen zusätzliche Verzögerungen, die bei der Entwicklung von Echtzeitsystemen
eine Rolle spielen.
Wenn, wie im Normalfall, keine Punkt-zu-Punkt-Verbindungen eingesetzt werden, gibt es
gemeinsam genutzte Ressourcen, für die der Zugri geregelt werden muss, um Störungen
der Kommunikation durch Sendekonikte zu vermeiden. Somit verbringt eine Nachricht
gegebenenfalls Zeit in einer Warteschlange, bevor sie versendet werden kann, beispielsweise
wenn im Moment eine Nachricht eines anderen Knotens übertragen wird. Abbildung 2.2
veranschaulicht, wo in typischen Topologien kabelgebundener Netze schwer vorhersagbare
Verzögerungen auftreten. Wenn die maximale Zeit in einer Warteschlange nicht begrenzt
ist, ist die Einhaltung der Echtzeitanforderungen in Gefahr es drohen Zeitfehler. Daher
müssen für Echtzeitsysteme Strategien entwickelt werden, mit denen die Auslieferung von
Nachrichten in beschränkter Zeit garantiert werden kann, auch wenn das Netz stark ausgelastet
ist. Die Abschnitte 2.3 und 2.4 betrachten die Problematik bei CAN und Ethernet.
Verglichen mit rechnerinterner Kommunikation kommt es beim Datentransfer über Netzwerke
auch deutlich häuger zu Störungen, die sich als Wertfehler in den Daten äuÿern.
Über fehlererkennende Codes werden diese auf Auslassungsfehler abgebildet, die im
Echtzeitsystem unbehandelt wiederum zu Zeitfehlern führen.
Eine weitere Eigenschaft von verteilten Systemen ist das Fehlen einer gemeinsamen Zeitbasis,
bzw. die Notwendigkeit der Uhrensynchronisation, wenn eine globale Zeit gebraucht
wird. Ursächlich hierfür sind Unterschiede in den Schwingfrequenzen von Oszillatoren, die
auch initial gleich gestellte Uhren auseinander driften lassen.
12

2.2 Publish/Subscribe Middleware
2.2 Publish/Subscribe Middleware
Bei Publish/Subscribe handelt es sich um ein Kommunikationsparadigma mit folgenden
Eigenschaften:
• Die Kommunikation erfolgt anonym. Die Produzenten, Publisher genannt, veröffentlichen
Informationen in Form von Events (engl. für: Ereignisse), ohne die Konsumenten
(Subscriber) kennen oder adressieren zu müssen. Stattdessen wird jedem
Event ein Betre (engl.: subject) zugeordnet. Über logische Kanäle wird ein veröffentlichtes
Event an die Subscriber weitergeleitet, die das Subject abonniert haben.
Optional lassen sich die Events auch feingranularer auf Basis des Inhalts ltern.
• Gruppenkommunikation wird unterstützt, d. h. es kann jeweils mehrere Publisher
und Subscriber mit demselben Subject geben, sowohl auf einem Rechner als auch
verteilt über mehrere Computer.
• Das Paradigma unterstützt spontane Kommunikation, d. h. die Kommunikationsgruppen
bestimmen sich erst zur Laufzeit, da jederzeit Publisher und Subscriber
hinzukommen und wegfallen können.
In den folgenden Abschnitten werden Middlewares vorgestellt, die dieses Paradigma umsetzen.
Zuerst wird auf die Middleware FAMOUSO eingegangen, in der die Echtzeitkanäle
implementiert werden sollen. Im darauf folgenden Abschnitt 2.2.2 werden kurz einige andere
Middlewares diskutiert, die sich in die Kategorie Echtzeit einordnen.
2.2.1 FAMOUSO
FAMOUSO (Family of Adaptive Middleware for autonomOUs Sentient Objects, [Sch09,
Sch]) ist eine adaptierbare Publish/Subscribe-Middleware. Sie bietet eine einheitliche Programmierschnittstelle,
die in verschiedenen Programmiersprachen und Ingenieurtools verwendbar
ist. Es werden verschiedene Netzwerke und Plattformen unterstützt. FAMOUSO
ist dank seiner Portabilität und umfangreichen Kongurationsmöglichkeiten zur Compile-
Zeit auch auf stark ressourcenbeschränkten eingebetteten Systemen lauähig.
In FAMOUSO können Events neben den reinen Nutzdaten auch optional Attribute enthalten,
die als Metainformationen mit publiziert werden. Sie lassen sich beispielsweise zur
Filterung bei den Subscribern nutzen.
FAMOUSO erlaubt die Spezikation von individuellen Quality-of-Service-Anforderungen
für jeden Publisher und Subscriber. Die Multi-Level Composability Check Architecture
[SL09] testet diese Anforderungen zur Design-, Compile- und Laufzeit gegen die
Möglichkeiten der beteiligten Netzwerke. Für die Überprüfungen zur Laufzeit kommt
ein Management-Kanal zum Einsatz, über den die QoS-Anforderungen publiziert werden,
auch über Netzwerkgrenzen (FAMOUSO-Gateways) hinweg. Dadurch ergibt sich die
13

2 Grundlagen und verwandte Arbeiten
Möglichkeit, QoS-Anforderungen global auf Erfüllbarkeit zu überprüfen und gegebenenfalls
durchzusetzen. Ein Konzept zur Durchsetzung strikter QoS-Anforderungen, wie sie
in harten Echtzeitsystemen vorkommen, wird in Kapitel 3 vorgestellt.
2.2.2 Existierende echtzeitfähige Middlewares
Betrachtet man existierende Middlewares, die sich als echtzeitfähig bezeichnen, ist eine
wesentliche Schwäche festzustellen. Keine der untersuchten Middlewares bietet Garantien
für die Durchsetzung von Echtzeitanforderungen im verteilten System. Es werden zwar
Fragen des lokalen Scheduling von Echtzeitprozessen thematisiert, die in Abschnitt 2.1.5
angesprochene Problematik eines echtzeitfähigen Netzwerkes bleibt jedoch auÿen vor. In
[HLS97, GPS04] werden für den Real-Time CORBA Event bzw. Notication Service ausschlieÿlich
Testergebnisse gezeigt, bei denen keine Datenübertragung über ein Netzwerk
nötig ist. NDDS [PcS94] und Real-Time Publish/Subscribe (RTPS) nach Rajkumar et
al. [RGS95] verwenden jeweils UDP/IP auf Ethernet und setzen eine sehr niedrige Netzwerkauslastung
voraus. Wie in Abschnitt 2.4 genauer beschrieben wird, können bei Zugriskonikten
im Ethernet unvorhersagbare Latenzen auftreten, welche die Echtzeitfähigkeit
gefährden. Da die Verzögerungen stark von der Netzwerklast abhängen, muss auÿerdem
bei jeder Erweiterung des Systems das gesamte Systemverhalten neu evaluiert werden.
Während bei NDDS und Real-Time CORBA zumindest lokale Überprüfungen zur Einhaltung
von Quality-of-Service-Anforderungen möglich sind, erlaubt RTPS nicht einmal die
Spezikation solcher Anforderungen.
Aufgrund der angesprochenen Dezite eignen sich die untersuchten Middlewares bei hohen
Verlässlichkeitsanforderungen allenfalls zur lokalen Inter-Prozess-Kommunikation, jedoch
nicht für verteilte Echtzeitsysteme. In den folgenden Abschnitten wird betrachtet, wie
echtzeitfähige Kommunikation über CAN und Ethernet möglich ist.
2.3 Controller Area Network
Controller Area Network (CAN) bezeichnet ein serielles Kommunikationsprotokoll, das
Flexibilität, gute Verlässlichkeitseigenschaften und einen vorhersagbaren Netzzugri bietet.
Es wird vor allem als Feldbussystem in der Automobil-, Automatisierungs- und Medizintechnik
eingesetzt.
Im folgenden Abschnitt wird zunächst das CAN-Protokoll vorgestellt und seine
Tauglichkeit für harte Echtzeitanforderungen eingeschätzt. Anschlieÿend werden verschiedene
Ansätze diskutiert, die auf dem CAN-Protokoll aufbauen und konkrete zeitliche
Garantien bieten.
14

2.3 Controller Area Network
2.3.1 Basisprotokoll
Das CAN Kommunikationsprotokoll [Rob91] wurde in den 1980er-Jahren von der Robert
Bosch GmbH entwickelt und Anfang der 90er-Jahre als ISO-Norm 11898 standardisiert.
Es umfasst die Denition der physikalischen Schicht und der Datensicherungsschicht nach
dem ISO/OSI-Referenzmodell.
Alle Netzwerkknoten werden bei CAN an einen seriellen Broadcast-Bus angeschlossen, der
je nach Länge mit Datenübertragungsraten bis zu 1 Mbit/s arbeiten kann. Die Kommunikation
erfolgt in Form von Nachrichten, die jeweils 0-8 Byte Nutzdaten transportieren können.
Jede Nachricht wird mit einer ID versehen, die 11 Bit (Standardformat) bzw. 29 Bit (erweitertes
Format) lang ist. Eine ID darf nicht von mehreren Knoten verwendet werden 4 .
Die ID dient zum einen als Nachrichtenpriorität und zum anderen als Kennzeichnung des
Nachrichteninhalts. Die ID kann verwendet werden, um eingehende Nachrichten schon im
CAN-Controller zu ltern und somit den Host-Prozessor zu entlasten. CAN unterscheidet
vier verschiedene Frame-Typen: (1) Data-Frames werden zur Nachrichtenübertragung
verwendet. An ihrem Anfang steht das Arbitrierungsfeld, in dem die Nachrichten-ID übertragen
wird. Es folgen unter anderem die Nachrichten-Nutzlast und ein CRC. (2) Remote-
Transmission-Request-Frames ermöglichen es, das Senden einer Nachricht bei einem anderen
Knoten anzufragen. (3) Error-Frames werden verwendet, um anderen Knoten erkannte
Fehler zu signalisieren. (4) Overload-Frames verzögern die Übertragung und können zur
Flusskontrolle eingesetzt werden. Auf (2) und (4) wird hier nicht weiter eingegangen, da
diese Features in dieser Arbeit nicht verwendet werden.
Physikalische Schicht Die physikalische Schicht ist so gestaltet, dass jedes Bit durch den
gesamten Bus propagiert wird, bevor mit der Übertragung des nächsten Bits begonnen
wird. Die Bits werden durch rezessive (Bitwert 1) und dominante (Bitwert 0) Signalpegel
repräsentiert. Genau dann, wenn mindestens ein Knoten einen dominanten Pegel sendet,
stellen alle Knoten einen dominanten Pegel fest. Folglich hat der Bus nur dann einen
rezessiven Pegel, wenn kein Knoten einen dominanten Pegel sendet. Der Bus wirkt also
wie ein logisches UND-Gatter, bei dem jeder Knoten mit der Sendeeinheit an einen Eingang
und mit der Empfangseinheit an den Ausgang gekoppelt ist, so dass alle Knoten für
jedes Bit eine konsistente Sicht des Buszustandes haben. Diese Eigenschaft wird bei der
Arbitrierung und zur Erkennung und Signalisierung von Fehlern ausgenutzt.
Arbitrierung Die Arbitrierung, also die Zuteilung des Netzzugris, basiert auf dem
Carrier-Sense-Multiple-Access-Prinzip (CSMA). Ein Knoten, der eine Nachricht senden
will, horcht zunächst auf dem Übertragungsmedium, ob gerade ein anderer Knoten sendet.
4
Dies stellt sicher, dass nie zwei Knoten gleichzeitig Nachrichten mit derselben ID aber verschiedenem
Inhalt senden. Letzteres ist nach dem CAN-Standard verboten.
15

2 Grundlagen und verwandte Arbeiten
Wenn das der Fall ist, wartet er bis die laufende Übertragung abgeschlossen ist. Anderenfalls
beginnt er sofort zu senden. Wenn zwei oder mehr Knoten gleichzeitig zu senden
beginnen, kommt es zu einer Kollision. Diese wird während der bitweisen Übertragung
der Nachrichten-IDs aufgelöst. Dazu beobachtet jeder Sender im Arbitrierungsprozess
den Buszustand und vergleicht diesen jeweils mit dem von ihm gesendeten Bit. Wird
ein rezessiver Pegel gesendet und ein dominanter beobachtet, steigt der Knoten aus der
Arbitrierung aus, da mindestens eine Nachricht mit höherer Priorität (niedrigerer Zahlenwert
der ID) sendebereit ist. Da die IDs eindeutig sein müssen, gewinnt die Arbitrierung
immer genau ein Knoten: der mit der höchstprioren Nachricht. Während der restliche
Data-Frame dieser Nachricht übertragen wird, warten die anderen Knoten auf die nächste
Arbitrierungsphase.
Der CAN-Bus bietet auf diese Weise eine sehr eziente, vorhersagbare Netzzuteilung,
die einem verteilten prioritätsbasierten nicht-präemptiven Scheduling gleichkommt. Ohne
weitere Annahmen kann eine beschränkte Latenz jedoch nur für die Nachricht mit der höchsten
Priorität garantiert werden. Da dies nicht ausreicht, sobald mehrere Nachrichten aus
verschiedenen Quellen Echtzeitgarantien benötigen, muss die Versenderate der Nachrichten
eingeschränkt werden. Dann können auch für Nachrichten mit niedrigeren Prioritäten
zeitliche Garantien angegeben werden. Siehe hierzu Abschnitt 2.3.2 bis 2.3.5.
Fehlererkennung und -behandlung Das CAN-Protokoll nutzt die von der physikalischen
Schicht bereitgestellte konsistente Sicht aller Knoten, um eine schnelle Erkennung und
Signalisierung von Fehler zu ermöglichen. So überwacht jeder Sender bei der Übertragung
einer Nachricht, ob der auf dem Bus beobachtete Bitwert dem gesendeten entspricht.
Neben der Ausnutzung im Arbitrierungsmechanismus lassen sich so auch Wertfehler bei
der Datenübertragung schon beim Sender erkennen. Zusätzlich enthält jede Nachricht
einen Cyclic-Redundancy-Check-Code (CRC) über den der Sender falsch empfangene
Nachrichten mit sehr hoher Wahrscheinlichkeit erkennen kann. Wird beim Sender oder
einem Empfänger ein Fehler festgestellt, wird dieser sofort signalisiert, indem ein Error-
Frame gesendet wird. Dieser kann jederzeit von allen Knoten erkannt werden, da er aus
mehr als fünf aufeinanderfolgenden dominanten Signalpegeln besteht, und somit die sonst
geltende Bit-Stung-Regel verletzt. Diese schreibt vor, nach fünf gleichen Pegeln einen
komplementären Signalpegel zu senden. Bei einem Fehler verwerfen alle Empfänger ihren
Empfangspuer und der Sender initiiert automatisch einen erneuten Übertragungsversuch,
ohne Zusatzaufwand für den Host-Prozessor. Fehlerzustände sind auch dann gegeben, wenn
die formale Frame-Struktur verletzt wird oder zu einem Daten-Frame kein positives Acknowledge
gegeben wird, also kein Knoten den Frame richtig empfangen hat.
Durch das synchrone Auslesen der einzelnen Bits an allen Stationen und die konsistente
Fehlersignalisierung und -behandlung wird eine Nachricht in allen intakten Knoten zeitsynchron
ausgeliefert. In seltenen Fehlerfällen kann es hierbei zu Inkonsistenzen kommen.
16

2.3 Controller Area Network
In [KL99] wird jedoch beschrieben, wie auch für diese Fälle ein ezienter atomarer Multicast
garantiert werden kann.
Dauerhaft defekte Knoten werden im CAN-Protokoll über lokale Fehlerzähler erkannt und
vom Bus genommen. Bis dieser Defekt erkannt ist kann der Knoten die Kommunikation
über den Bus jedoch unmöglich machen, z. B. wenn ein Knoten ununterbrochen sendet und
so Kommunikation anderer Knoten komplett unterbindet (Babbling-Idiot-Fehler). Durch
einen Senderfehler kann ein mit 1 Mbit/s betriebener CAN-Bus beispielsweise bis zu 2,4 ms
unbenutzbar sein (vgl. [RV95]).
CAN bietet Dank der umfangreichen Fehlererkennungsmaÿnahmen und der automatischen
Sendewiederholung im Fehlerfall einen sehr verlässlichen Datentransfer. Für harte Echtzeitsysteme
ist Zuverlässigkeit nur so lange nützlich, wie alle wichtigen zeitlichen Anforderungen
garantiert werden können. Beim Entwurf solcher Systeme müssen daher die verschiedenen
Fehlerfälle und die daraus resultierenden Konsequenzen für die Echtzeitkommunikation
und das gesamte System gründlich bedacht werden.
2.3.2 Einplanbarkeitsanalyse
Der im vorigen Abschnitt beschriebene, auf statischen Prioritäten basierende, Arbitrierungsmechanismus
des CAN-Protokolls bietet eine vorhersagbare Auösung von Kollisionen.
Das heiÿt, wenn die Nachrichtenmenge mit ihren Prioritäten und zeitlichen Parametern
bekannt ist, können die Netzzuteilung und die daraus resultierenden maximalen
Verzögerungen analysiert werden, um zu überprüfen, ob die Einhaltung der Echtzeitanforderungen
garantiert werden kann. Um die maximale Latenz auch für niedrige Prioritäten
zu beschränken, muss für alle höher priorisierten Nachrichten eine Periode bzw.
minimale Zeit zwischen dem Auftreten zweier Nachrichten angegeben werden können. Umfangreiche
Ausführungen und Literaturhinweise zu der üblichen Einplanbarkeitsanalyse
ndet man in [DB07]. Diese Arbeit korrigiert einen Fehler in der lange eingesetzten Analyse
nach [Tin94, TB94], durch den einige nicht planbare Systeme als planbar eingestuft
werden. Für harte Echtzeitbedingungen muss bei der Analyse ein angemessenes Fehlermodell
berücksichtigt werden.
Für die Planbarkeit einer Nachrichtenmenge ist die Wahl der Prioritäten von entscheidender
Bedeutung. Bei den meisten Anwendungen müssen Deadlines bzw. Perioden auf
Prioritäten abgebildet werden. Hierbei ist zu beachten, dass eine Prioritätenzuordnung
nach Deadline-Monotonic (je früher die Deadline, um so höher die Priorität) nicht optimal
ist, d. h. insbesondere bei starker Auslastung nicht immer die beste Prioritätszuordnung
liefert. Das liegt daran, dass Deadline-Monotonic nur für präemptive Tasks optimal ist (vgl.
[GVC96]), die einzelnen Nachrichten bei CAN jedoch nicht unterbrechbar übertragen werden.
In [DB07] wird ein Algorithmus angegeben, um eine optimale Prioritätszuordnung zu
nden.
17

2 Grundlagen und verwandte Arbeiten
Die Prioritätszuteilung und Einplanbarkeitsanalyse zur Design-Zeit hat den Vorteil, dass
der Overhead zur Laufzeit minimal ist. Andererseits ist diese Art, Echtzeitgarantien bereitzustellen,
schwer zu überschauen. Der Entwickler muss eine recht komplizierte Analyse
verstehen und anwenden oder ist auf unter Umständen teure Design-Tools angewiesen.
Auÿerdem sind Erweiterungen oder Änderungen im System aufwendig, da die Einplanbarkeitsanalyse
erneut durchgeführt und eventuell Prioritäten geändert werden müssen.
Ein weiterer Nachteil, insbesondere für Regelungsalgorithmen, ist der im Vergleich zu
einem zeitgesteuerten Netzzugri sehr hohe Jitter, da das Versenden einer Nachricht durch
andere Nachrichten stark verzögert werden kann. Mit dem höheren Jitter geht auch eine
höhere Fehlererkennungslatenz einher.
2.3.3 Kalender und dynamische Prioritäten
In [LKJ99, LK98] wird ein Ansatz beschrieben, der auf der Arbitrierung des CAN-
Protokolls aufbaut. Der Entwickler vergibt keine statischen Prioritäten, sondern ordnet
eine Nachricht einer Klasse zu: harte Echtzeit, weiche Echtzeit oder nicht-Echtzeit. Für
harte Echtzeitnachrichten wird die Einplanbarkeit über einen Kalender (TDMA, Time
Division Multiple Access) sichergestellt. Durch die Festlegung der Sendezeitpunkte werden
Konikte mit anderen harten Echtzeitnachrichten ausgeschlossen und sowohl die
Pünktlichkeit als auch ein geringer Jitter garantiert. Der Preis hierfür ist jedoch, dass
durch Uhrensynchronisation eine gemeinsame Zeitbasis etabliert werden muss. Die weichen
Echtzeit-Nachrichten sind niedriger priorisiert und werden ohne zeitliche Garantien
zwischen den harten Echtzeitnachrichten übertragen. Es werden jedoch so viele Deadlines
eingehalten, wie die Datenrate erlaubt, denn für diese Nachrichten wird ein verteiltes
Earliest-Deadline-First-Scheduling durchgesetzt. Dazu wird der Spielraum, also die noch
verbleibende Zeit bis zur Deadline, in der Nachrichtenpriorität codiert. Da sich der Spielraum
über die Zeit verändert, ist eine regelmäÿige Anpassung der Priorität nötig. Nicht-
Echtzeit-Nachrichten haben die niedrigste Priorität und werden somit nur gesendet, wenn
sich weder harte noch weiche Echtzeit-Nachrichten an der Arbitrierung beteiligen.
Das Konzept bietet groÿe Flexibilität. Es liefert Garantien für harte Echtzeit-Nachrichten.
Die ungenutzten Netzressourcen lassen sich auÿerdem ezient für sporadische Nachrichten
mit weichen Echtzeitanforderungen nutzen. Nachteilig ist, dass ein groÿer Overhead zur
Laufzeit anfällt, denn die periodische Aktualisierung der Nachrichten im Sendepuer muss
auf Interrupt-Basis in Software realisiert werden, da die Hardwareunterstützung hierfür
fehlt. Bei der Aktualisierung der Priorität kann es auÿerdem zu einer Verzögerung der
Nachricht kommen, wenn hierbei ein sonst gewonnener Arbitrierungsprozess verpasst wird.
Auÿerdem sind zur Laufzeit keine Änderungen im Kalender für harte Echtzeit-Nachrichten
möglich, da die nebenläuge Reservierung eines Zeitschlitzes durch mehrere Knoten nicht
ausgeschlossen werden kann.
18

2.3 Controller Area Network
2.3.4 TTCAN
TTCAN (Time-Triggered CAN, vgl. [FMD + 00]) erweitert das CAN-Protokoll um die
Möglichkeit zur zeitgesteuerten Kommunikation. Über eine periodisch versendete Referenznachricht
eines replizierbaren Zeit-Masters wird eine globale Zeit etabliert. Sie markiert
auÿerdem jeweils den Anfang eines Basis-Zyklus'. Der Basis-Zyklus ist in Zeitfenster unterteilt,
deren Länge und Verwendung zur Design-Zeit festgelegt werden. Ein Zeitfenster
kann exklusiv einem Knoten für periodische Kommunikation zugeteilt werden. Alternativ
kann es als Arbitrierungsfenster für spontane Nachrichten genutzt werden. Hierbei
greift die prioritätsbasierte Standard-Arbitrierung von CAN. Die Slots können auch über
mehrere aufeinanderfolgende Basis-Zyklen unterschiedlich vergeben werden. Diese Zyklen
bilden dann zusammen einen Matrix-Zyklus. Die Länge der Zeitfenster innerhalb der Basis-
Zyklen lässt sich aber nicht variieren.
TTCAN erlaubt sowohl zeitgesteuerte Kommunikation mit geringem Jitter für harte
Echtzeit, als auch sporadische prioritätsbasierte Nachrichten, die sich für weiche Echtzeit
und Nicht-Echtzeit einsetzen lassen. Die zeitgesteuerte Kommunikation ist jedoch statisch
geplant und nicht zur Laufzeit änderbar.
2.3.5 FTT-CAN
FTT-CAN (Flexible Time-Triggered CAN, vgl. [APF02]) ermöglicht zeitgesteuerte
Echtzeitkommunikation mit dynamischem Scheduling. Die Zeit wird in aufeinanderfolgende
gleichlange Elementarzyklen unterteilt. Diese bestehen aus einem synchronen Zeitfenster
und einem zeitlich isolierten asynchronen Fenster. Der synchrone Teil ist für zeitgesteuerte
periodische Kommunikation gedacht. Ein replizierbarer Master-Knoten kennt
die Menge aller synchronen Nachrichtenströme inklusive ihrer Zeitanforderungen. Auf Basis
dieses Wissens plant er für jeden Elementarzyklus die zu versendenden synchronen
Nachrichten und löst deren Versand mit einer Trigger-Nachricht aus. Diese wird auch zur
Synchronisation verwendet, indem sie den Beginn eines neuen Elementarzyklus' markiert.
Die Zeitanforderungen eines Nachrichtenstroms lassen sich zur Laufzeit ändern. Eine Änderung
wird nur zugelassen, wenn sie ohne Verletzung von zeitlichen Garantien einplanbar
ist. Im asynchronen Teil wird wie bei den Arbitrierungsfenstern in TTCAN auf die prioritätsbasierte
Arbitrierung von CAN gesetzt.
FTT-CAN bietet zeitgesteuerte und prioritätsbasierte Kommunikation, die zur Laufzeit
geplant wird. Jedoch wird die synchrone Kommunikation nicht durch den Fortschritt
der Zeit, sondern durch den Master getriggert. Durch das Verwenden einer gemeinsamen
Trigger-Nachricht für alle Nachrichten eines synchronen Fensters und die Ausnutzung der
prioritätsbasierten Arbitrierung zur Lösung des Zugriskonikts, kommt es zu deutlich
gröÿerem Jitter als bei direkter zeitgesteuerter Kommunikation. Ein weiterer Nachteil ist,
dass die Perioden der synchronen Nachrichten nur als Vielfache der Elementarzykluslänge
gewählt werden können.
19

2 Grundlagen und verwandte Arbeiten
Lösung Prinzip Jitter Planung
(1) Einplanbarkeitsanalyse Prioritäten groÿ statisch
(2) Kalender und dyn. Prio. TDMA gering statisch
(3) TTCAN TDMA gering statisch
(4) FTT-CAN Master/Slave, Prioritäten mittel dynamisch
Tabelle 2.1: Vergleich von Lösungen für harte Echtzeitgarantien bei CAN
2.3.6 Zusammenfassung
Es wird deutlich, dass sich die deterministische Arbitrierung des CAN-Basisprotokolls
gut ausnutzen lässt, um die eziente Durchsetzung verschiedener zeitlicher Anforderungen
garantieren zu können. Jedoch eignet sich keine der untersuchten Lösungen für den
Einsatz in FAMOUSO. Die Tabelle 2.1 vergleicht die Ansätze bezüglich harter Echtzeitgarantien.
Die Ausnutzung der prioritätsbasiertenen Arbitrierung in (1) und (4) führt zu
einem hohen Jitter, der für Regelungsanwendungen unerwünscht ist, und zu einer höheren
Fehlererkennungslatenz. Bei (2) und (3) ist die Etablierung von harten Echtzeitgarantien
zur Laufzeit nicht möglich. Daher wird in Kapitel 3 eine eigene Lösung entwickelt.
2.4 Ethernet
Bei Ethernet handelt es sich um die momentan am weitesten verbreitete Technologie für
lokale Netzwerke. Obwohl es keine zeitlich vorhersagbare Kommunikation bietet, wird
Ethernet nicht selten für Echtzeitaufgaben eingesetzt. Motivation hierfür sind vor allem
die geringen Kosten für die Ethernet-Hardware, die hohen Datenübertragungsraten oder
die leichte Anbindbarkeit an das Internet und andere IT-Infrastrukturen.
Der folgende Abschnitt gibt eine Einführung in das Ethernet-Protokoll. In den darauf
folgenden Abschnitten werden verschiedene existierende Ansätze diskutiert, die Ethernet
echtzeittauglich machen sollen. Dabei werden nur Lösungen betrachtet, die keine modi-
zierte Hardware benötigen, um die Middleware nicht von der Verfügbarkeit spezieller
Hardware abhängig zu machen.
2.4.1 Basisprotokoll
Der Begri Ethernet bezeichnet ein im Standard IEEE 802.3 [iee08] deniertes Kommunikationsprotokoll
in der Datensicherungsschicht nach dem ISO/OSI-Referenzmodell. Die
Spezikation umfasst auÿerdem verschiedene physikalische Schichten mit Übertragungsraten
im Bereich von 1 Mbit/s bis 10 Gbit/s für Twisted-Pair-, Koaxial- und Glasfaserkabel.
Es werden zwei Betriebsmodi unterstützt. Im Halbduplexmodus teilen sich mehrere
Knoten das Übertragungsmedium. Es ergibt sich eine logische Bustopologie, für die der
Medienzugri reguliert werden muss (engl.: Media Access Control, MAC). Hierfür wird
20

2.4 Ethernet
das Verfahren CSMA/CD (Carrier Sense Multiple Access with Collision Detection) eingesetzt.
Der Vollduplexmodus ermöglicht die Kommunikation von jeweils zwei Knoten, ohne
dass Kollisionen auftreten können, so dass hier CSMA/CD nicht gebraucht wird. Er ist
jedoch nicht mit allen Übertragungsmedien möglich. Ein typischer Einsatz von Vollduplex
ist Switched Ethernet, auf das in Abschnitt 2.4.6 eingegangen wird.
Nachrichten werden in Datenframes übertragen, die neben den Nutzdaten unter anderem
einen CRC-Fehlererkennungscode sowie die Empfänger- und Absender-Adresse enthalten.
Die Adressen sind 6 Byte lang und werden auch MAC-Adressen genannt. Jeder Knoten
sollte eine eindeutige Adresse haben. Zur Gruppenkommunikation gibt es auÿerdem eine
Broadcast-Adresse, über die alle Knoten erreicht werden, sowie einen Adressbereich für
Multicast-Adressen. Ein Frame kann bis zu 1.500 Byte Nutzdaten transportieren. Werden
weniger als 46 Byte Nutzdaten versendet, wird das Feld bis zu dieser Länge aufgefüllt. Die
entstehende minimale Framelänge ist nötig, um Kollisionen zuverlässig in allen Stationen
erkennen zu können.
CSMA/CD Im Halbduplexmodus prüft ein sendebereiter Knoten, ob momentan eine
Nachricht eines anderen Knotens empfangen wird (Carrier Sense) und wartet gegebenenfalls
mit dem Senden, bis die Übertragung beendet ist. Zu Kollisionen kommt es, wenn
mehrere Knoten gleichzeitig zu senden beginnen, beispielsweise nachdem zwei sendewillige
Knoten auf das Freiwerden des Mediums gewartet haben. Es ist aber auch möglich, dass ein
Knoten eine bereits laufende Übertragung nicht bemerkt, wenn das Signal ihn noch nicht
erreicht hat, denn anders als bei CAN wird bei der Übertragung nicht gewartet, bis ein
Bit durch die Leitung propagiert wurde. Eine Nachricht erreicht verschiedene Empfänger
somit im Allgemeinen zu unterschiedlichen Zeitpunkten. Damit eine Kollision trotzdem
von allen Stationen einer Kollisionsdomäne erkannt werden kann (Collision Detection),
wurde, wie bereits erwähnt, eine minimale Framelänge eingeführt, die gegebenenfalls automatisch
durch das Einfügen eines Pad-Feldes hinter den Nutzdaten erreicht wird. Bei
einer Kollision überlagern sich die Signale additiv, so dass der Pegel zumindest zeitweise
ungültige Werte annimmt. Erkennt eine Station hierüber eine Kollision, so sendet sie ein
zusätzliches Störsignal, das sicherstellt, dass alle Knoten eine Kollision erkennen und ihre
Empfangspuer verwerfen. Die Wahrscheinlichkeit für Kollisionen steigt mit der Anzahl
der Stationen, deren Sendeaufkommen und der Leitungslänge.
Um eine erneute Kollision zu vermeiden, warten die sendebereiten Knoten für eine zufällige
Zeit, bevor sie einen erneuten Übertragungsversuch nach CSMA/CD starten. Bei wiederholten
Kollisionen werden die Wertebereiche, aus denen die zufälligen Wartezeiten gewählt
werden, exponentiell vergröÿert (Exponential Backo), so dass sich die Wahrscheinlichkeit
zur Auösung des Konikts mit fortschreitender Zeit schnell erhöht. Da die Zeit zur Lösung
von Medienzugriskonikten von Zufallszahlen abhängt, ist sie nicht vorhersagbar
und damit für harte Echtzeitsysteme ungeeignet. Auÿerdem verursacht der Exponential
21

2 Grundlagen und verwandte Arbeiten
Backo einen immensen Jitter und eine sehr hohe maximale Fehlererkennungslatenz in der
Echtzeitanwendung.
Fehlererkennung und -behandlung In Ethernet werden Übertragungsfehler auf
Empfängerseite über einen Cyclic-Redundancy-Check-Code erkannt. Beschädigte Frames
werden verworfen. Anders als bei CAN gibt es keinen netzwerkweiten Konsens bezüglich
des Empfangs von Datenframes. Auÿerdem ist keine Erkennung und Behandlung von
Fehlern der Sende- bzw. Empfangshardware vorgesehen.
2.4.2 RETHER
RETHER (vgl. [CV94]) ist ein Protokoll, das den Aufbau von Echtzeit-Netzwerkverbindungen
erlaubt. Wenn keine Echtzeitverbindung oen ist, wird CSMA/CD verwendet.
Beim Aufbau des ersten Echtzeitkanals wird in den RETHER-Modus gewechselt, in dem
die Sendeberechtigung mittels Token-Passing von Knoten zu Knoten weitergegeben wird.
Jeder Knoten kennt seinen Vorgänger und Nachfolger. Zunächst läuft das Token durch
die Menge der Knoten mit Echtzeitverbindungen. Dabei hat jeder Knoten eine für ihn
reservierte maximale Haltezeit des Tokens, während der er Echtzeitnachrichten versenden
kann. Nach Ablauf der Zeit oder wenn nichts mehr zu übertragen ist, gibt er das Token an
den Nachfolgerknoten weiter. Mit dem Token wird unter anderem die noch verbleibende
Zeit bis zum Ablauf der maximalen Token-Rotationszeit mitgeteilt. Der letzte Knoten der
Menge mit Echtzeitverbindungen verschickt das Token an einen der Nicht-Echtzeit-Knoten.
Dieser überprüft, ob noch genug Zeit zur Übertragung seines Pakets vorhanden ist. Wenn
ja, dann überträgt er sein Paket und reicht das Token an den nächsten Nicht-Echtzeit-
Knoten weiter. Falls die Zeit nicht ausreicht, wird eine neue Runde begonnen, indem der
Token an den ersten Echtzeit-Knoten gesendet wird. Der Nicht-Echtzeit-Teil der Runde
beginnt beim Nachfolger des zuletzt aktiven Nicht-Echtzeitknotens.
RETHER erlaubt den Auf- und Abbau von Echtzeitverbindungen mit reservierten Bandbreiten
zur Laufzeit. Andere QoS-Parameter wie die Periode oder die Ende-zu-Ende-
Latenz lassen sich nicht beeinussen. Auÿerdem entsteht durch die Variation der Token-
Halte- und -Rotationszeiten ein hoher Jitter und eine hohe maximale Fehlererkennungslatenz.
Problematisch ist auch, dass das Token bei einer Verkettung von Fehlern verloren
gehen kann, wodurch die Kommunikation komplett unmöglich wird.
2.4.3 RT-EP
Das Real-Time Ethernet Protocol (RT-EP, vgl. [MHG03]) nutzt Prioritäten zur Zuteilung
der Netzwerkressourcen. Vor der Übertragung eines Nutzdatenpaketes wird hierfür in der
Arbitrierungsphase mittels eines Tokens, das durch den logischen Ring gereicht wird, die
Station mit der am höchsten priorisierten Nachricht ermittelt. Anschlieÿend wird das
22

2.4 Ethernet
Sendetoken an diesen Knoten geschickt. Dieser überträgt seine Nachricht und beginnt
erneut mit der Arbitrierungsphase.
Das prioritätsbasierte Scheduling erfordert eine Einplanbarkeitsanalyse, auf deren
Nachteile bereits in Abschnitt 2.3.2 eingegangen wurde. Gegen das Protokoll spricht
auch der groÿe Overhead bei der Arbitrierung, denn bei N Stationen müssen für jedes
Nutzdatenpaket N + 1 Token-Nachrichten übertragen werden.
2.4.4 RTnet
Bei RTnet (vgl. [KW05]) handelt es sich um einen echtzeitfähigen Netzwerk-Stack. Zu
diesem gehört auch eine Schicht zur Regelung des Medienzugris (RTmac), mit der sich
nicht-deterministische Mechanismen des Medienzugris, wie CSMA/CD, umgehen lassen.
Zu RTnet gehört eine TDMA-basierte Implementierung, bei der ein replizierbarer Master
zu Beginn jeder Runde eine Synchronisationsnachricht verschickt, über die eine globale
Zeit etabliert wird. Eine TDMA-Runde besteht aus einer Reihe statisch kongurierter
Slots mit individuellen Gröÿen. Jeder Knoten hat mindestens einen Zeitschlitz, kann aber
auch mehrere haben. Die Anwendungen können ihre Nachrichten explizit einem speziellen
Slot zuweisen. Auÿerdem können Prioritäten vergeben werden, welche die Reihenfolge
der über einen Slot versendeten Nachrichten festlegen. Es ist auch möglich, Perioden als
Vielfaches der TDMA-Rundenzeit zu wählen und somit einen Zeitschlitz über verschiedene
Phasenverschiebungen mehreren Knoten zuzuteilen.
Das in RTnet implementierte TDMA erlaubt eine sehr exible Slot-Zuteilung, die eine optimale
Bandbreitenausnutzung erlaubt. Weitere Vorteile sind ein geringer Jitter und damit
eine niedrige Fehlererkennungslatenz. Nachteilig ist, dass zur Laufzeit keine Reservierung
von Netzressourcen möglich ist.
2.4.5 FTT-Ethernet
FTT-Ethernet (vgl. [PAG02]) basiert auf dem gleichen Paradigma wie das in Abschnitt
2.3.5 beschriebene FTT-CAN. Die Elementarzyklen bestehen aus einem synchronen
und einem asynchronen Teil. Der Master leitet den synchronen Teil durch eine Trigger-
Nachricht ein. Diese wird zur Uhrensynchronisation und zur Zuteilung des Medienzugris
verwendet. Sie enthält die IDs der zu versendenden Echtzeit-Nachrichten und die jeweilige
Dauer der Übertragung. Die Nachrichtenströme werden beim Master mit QoS-Parametern
angefragt und von ihm eingeplant. Im asynchronen Teil können weiche Echtzeit- und Nicht-
Echtzeit-Nachrichten verschickt werden. Sie werden vom Master gepollt, d. h. der Master
gibt den Knoten nacheinander eine jeweils zeitlich begrenzte Sendeberechtigung.
FTT-Ethernet erlaubt die Etablierung von Echtzeitkanälen zur Laufzeit. Problematisch ist
jedoch, wie bei FTT-CAN, der Jitter durch die Variation der Sendezeitpunkte innerhalb
23

2 Grundlagen und verwandte Arbeiten
des synchronen Zeitfensters. Perioden können nur als Vielfache der Elementarzykluslänge
angegeben werden.
2.4.6 Switched Ethernet
Bei Switched Ethernet wird jeder Knoten mit einer Empfangs- und Sendeeinheit der zentralen
Vermittlerkomponente, dem Switch, verbunden. Es ergibt sich eine Sterntopologie,
in der keine Verzögerungen durch Kollisionen auftreten (vgl. Abschnitt 2.1.5). Trotzdem
ist Switched Ethernet ohne Weiteres nicht echtzeitfähig, denn der Switch sortiert
die empfangenen Pakete zur Weiterleitung in Sendewarteschlangen ein, in denen es zu
Stauungen kommen kann. Folge sind nicht vorhersagbare Verzögerungen und, bei überlaufenden
Warteschlangen, Paketeverlust. Die Problematik tritt verstärkt im Zusammenhang
mit Publish/Subscribe auf, wo zur Gruppenkommunikation Broadcast oder Multicast
verwendet wird. Hierbei werden im Switch alle empfangenen Pakete in alle Sendewarteschlangen
gelegt. Dabei geht der wesentliche Vorteil des Switches, mehrere parallele
Übertragungswege, verloren. Daher werden Echtzeit-Ansätze für Switched Ethernet in
dieser Arbeit nicht weiter betrachtet.
2.4.7 Zusammenfassung
Ethernet ist preisgünstig, erlaubt hohe Datenraten und eine einfache Anbindung
an Standard-IT-Infrastrukturen. Daher existieren viele Lösungen, die das nichtdeterministische
CSMA/CD umgehen, um Echtzeitgarantien auch bei hoher Netzwerklast
zu ermöglichen. Den für den Einsatz in FAMOUSO gestellten Anforderungen wird keiner
der betrachteten Ansätze gerecht, denn keiner bietet sowohl geringen Jitter als auch
Möglichkeiten zur dynamischen Etablierung von Echtzeitkanälen mit konkreten Quality-of-
Service-Garantien. Daher wird keine der vorgestellten Lösungen verwendet. Teilkonzepte
werden jedoch in den eigenen im Kapitel 3 vorgestellten Ansatz übernommen.
24

3 Echtzeitkommunikationskanäle
Um der Middleware FAMOUSO die Durchsetzung von Echtzeitanforderungen zu ermöglichen,
wird eine zusätzliche Softwareschicht geschaen. Diese verhindert nicht vorhersagbare
Verzögerungen beim Zugri auf das Netzwerkmedium, indem sie die Sendezeitpunkte
aller Nachrichten koordiniert.
Der erste Teil des Kapitels befasst sich damit, wie der echtzeitfähige Zugri auf die gemeinsam
genutzten Netzwerkmedien bei CAN und Ethernet garantiert werden soll. Die dafür
nötige Planung zur Vergabe von Medienzeit zur Laufzeit wird im zweiten Teil behandelt.
Beide Konzepte lassen sich auch abseits von Publish/Subscribe einsetzen. Im dritten Teil
wird ein Protokoll vorgestellt, das den zur dynamischen Planung notwendigen Informationsaustausch
regelt. Dieses ist stark auf Publish/Subscribe und FAMOUSO zugeschnitten.
Die in diesem Kapitel erarbeiteten Konzepte werden im Kapitel 4 in FAMOUSO
integriert.
3.1 Durchsetzung über TDMA
Echtzeitanforderungen wie eine maximale Latenz, geringer Jitter oder eine konkrete
Nachrichtenperiode lassen sich auf Netzwerkebene sehr zuverlässig über die Reservierung
von Medienzeit durchsetzen. Für FAMOUSO wurde ein TDMA-basierter Ansatz gewählt.
Alle Knoten eines Netzes verfügen dabei über synchronisierte Uhren und versenden ihre
Nachrichten in für sie reservierten Zeitfenstern.
Im Folgenden wird zunächst auf Gründe für die Wahl des Verfahrens und nötige Annahmen
eingegangen. Abschnitt 3.1.3 präsentiert die Details des verfolgten TDMA. In
Abschnitt 3.1.4 wird die Integration von Nachrichten ohne Echtzeitanforderungen (NRT)
in das TDMA-Schema besprochen.
3.1.1 Wahl des Verfahrens
Steuerungs- und Regelungsaufgaben in verteilten Systemen erfordern typischerweise eine
periodische und vorhersagbare Übertragung der Echtzeitdaten. TDMA ist hierfür aus folgenden
Gründen gut geeignet:
25

3 Echtzeitkommunikationskanäle
• TDMA ist zeitlich vorhersagbar, denn die Zeitpunkte der Nachrichtenübertragung
sind vorgegeben. Im Gegensatz zu anderen Verfahren gibt es für Echtzeitnachrichten
keine unbekannten Wartezeiten beim Medienzugri. Die Latenz ist unabhängig von
der Auslastung des Netzes. So erzeugt TDMA den geringsten möglichen Jitter und
erlaubt damit auch die schnellste Fehlererkennung.
• Da TDMA nicht auf der Ausnutzung von speziellen Netzwerk-Eigenschaften beruht,
kann es für viele Netzwerktypen eingesetzt werden. Es erlaubt eine gemeinsame
Lösung für die Echtzeitfähigkeit von CAN und Ethernet, die auch auf andere Netzwerke
mit gemeinsam genutzten Medien übertragbar ist. Neben kabelgebundenen
Bussystemen ist der Einsatz beispielsweise auch für Single-Hop 1 Funknetze denkbar.
Wenn die Verarbeitungszeit im Vermittlerknoten berücksichtigt wird, lässt sich der
Ansatz auch in Sterntopologien wie Switched Ethernet verwenden.
• TDMA ist sehr ezient für periodische Nachrichtenübertragung. Anders als bei
Token-Passing oder Master/Slave-Protokollen müssen für die Echtzeitfähigkeit nicht
ständig Verwaltungsnachrichten übertragen werden, die den Durchsatz für Nutzdaten
reduzieren.
• Die für TDMA notwendige Uhrensynchronisation liefert den Echtzeitknoten eine
globale Zeit, die sich im verteilten System ausnutzen lässt, um z. B. kooperative
Tasks zu synchronisieren oder den Zeitpunkt eines Ereignisses angeben zu können.
• TDMA eignet sich gut für Systeme mit hohen Anforderungen an die Verlässlichkeit.
Es gibt keinen Single-Point-of-Failure 2 , der den laufenden Echtzeitbetrieb stören
kann. TDMA ist zwar abhängig von der Uhrensynchronisation, diese kann aber über
einen verteilten Algorithmus sehr fehlertolerant ausgelegt werden.
Um auch nicht echtzeitfähige Knoten an ein Echtzeitnetz anbinden zu können, wird
der Medienzugri für Nicht-Echtzeit-Nachrichten (NRT-Nachrichten) nicht über reines
TDMA geregelt. Stattdessen wird ein anderes Verfahren eingesetzt, das mit TDMA harmoniert
und die Garantien für die Echtzeitnachrichten nicht gefährdet. Siehe hierzu Abschnitt
3.1.4.
3.1.2 Annahmen
Grundvoraussetzung für das Funktionieren von TDMA ist ein dediziertes Netz, an das
ausschlieÿlich Knoten angeschlossen sind, die sich an das hier beschriebene Protokoll halten.
Bei Hardwarefehlern wird von einem Fail-Silent-Verhalten ausgegangen, d. h. eine
fehlerhafte Komponente ist passiv und sendet nicht.
1
Alle Empfänger liegen im Einzugsbereich der Sender, so dass keine Weiterleitung über Zwischenstationen
nötig ist.
2
Ein Single-Point-of-Failure ist eine Schwachstelle, an der ein einzelner Fehler zum Ausfall des Gesamtsystems
führen kann. Beispiele sind der unbehandelte Verlust eines Sende-Tokens oder der Ausfall einer
Master-Komponente, die die Kommunikation triggert.
26

3.1 Durchsetzung über TDMA
Auÿerdem wird angenommen, dass in allen Echtzeitknoten eine globale Zeit zur Verfügung
steht. In einem Knoten weicht sie nie mehr als α von einer Referenzzeit ab (Accuracy).
Daraus folgt, dass sich zwei Globalzeituhren nie um mehr als 2α voneinander unterscheiden
(Precision). Daher wird für die Granularität g (Zeit zwischen zwei aufeinanderfolgenden
Ticks) der globalen Zeit ein Wert gröÿer als 2α gewählt. Der Einuss der mit der
Uhrensynchronisation erreichten Genauigkeit α und der danach gewählten Zeitgranularität
g wird in Abschnitt 3.2.5 diskutiert.
3.1.3 TDMA-Zyklus
Die Medienzeit wird in Zyklen unterteilt. Ein Zyklus besteht wiederum aus einer Abfolge
von Zeitschlitzen (Slots). Abb. 3.1 zeigt einen beispielhaften TDMA-Zyklus. Jeder der
Zeitschlitze ist entweder für einen Produzenten von Echtzeitnachrichten reserviert (RT i )
oder frei (NRT). Alle Slots eines Produzenten i haben die gleiche Länge und sind
streng periodisch angeordnet, d. h. ein Slot wiederholt sich jeweils nach der Periode p i .
Während eines Zeitschlitzes RT i hat der Produzent i die alleinige Sendeberechtigung
für das Medium 3 , wodurch Zugriskonikte vermieden werden. Die Länge des TDMA-
Zyklus' Z entspricht dem kleinsten gemeinsamen Vielfachen aller Perioden p i . Freie Slots
werden für Nicht-Echtzeit-Nachrichten verwendet (siehe Abschnitt 3.1.4).
Jeder Produzent zeichnet sich durch eigene QoS-Anforderungen aus. In FAMOUSO übernimmt
somit jeder Publisher-Ereigniskanal, der mit QoS-Anforderungen versehen ist, die
Rolle eines Produzenten. Die QoS-Anforderungen des Produzenten i werden durchgesetzt,
indem die Slots RT i für den Produzenten gemäÿ seiner Anforderungen reserviert werden.
Die Menge dieser Slots wird auch Echtzeitkommunikationskanal des Produzenten i bzw.
Kommunikationskanal i genannt. Auf einem Knoten kann es mehrere Produzenten von
Echtzeitnachrichten und damit auch mehrere Echtzeitkommunikationskanäle geben. Durch
die enge Kopplung des Produzenten i und des passend reservierten Kommunikationskanals
ist beim Versenden kein lokales Scheduling der Nachrichten nötig, was den Rechenaufwand
in den Knoten verringert. Die dafür aufwendigere Planung bei der Reservierung der Medienzeit
wird in einem rechenstarken Master-Knoten durchgeführt (siehe Abschnitt 3.2).
Der Kommunikationskanal i wird über folgende Parameter beschrieben:
• Die Dauer eines Sendeslots wird als Länge l i bezeichnet. Ein Slot wird durch die
Bereitzeit des Mediums r j i
und die Frist zum Abschluss der Datenübertragung d j i
begrenzt. In der Zwischenzeit darf für die Zeit l i = d j i − rj i
ausschlieÿlich von dem
Produzenten i gesendet werden.
3
Kein anderer Produzent von Echtzeitnachrichten darf während des Slots RT i senden. Nach in Abschnitt
3.1.4.2 und 3.3.2 eingeführten Regeln können innerhalb von Echtzeitslots jedoch Nicht-Echtzeit-
Nachrichten verschickt werden, da der Vorrang der Echtzeitnachrichten sichergestellt ist und kritische
Verzögerungen durch Zugriskonikte ausgeschlossen sind.
27

3 Echtzeitkommunikationskanäle
Zeit t
Perioden
p2
p1
Medienzuteilung RT1 RT2 NRT RT2 NRT RT2 NRT RT1 RT2
Zykluslänge
Z = kgV(p1, p2, . . . , pn)
Zyklusparameter:
Z Zykluslänge
z k Beginn des Zyklus' k
Echtzeitslot RT2
v2 l2
Zeit t
z k r j 2 u j 2 d j 2
f2
Slotparameter für Produzent i:
pi Periode
li Länge
vi Phasenverschiebung
fi Übertragungsstartfenster (ÜSF)
r j i
Beginn des Slots j
d j i
Ende des Slots j
u j i
Ende des ÜSF im Slot j
Abbildung 3.1: TDMA-Zyklus und Zeitparameter von Echtzeitslots
28

3.1 Durchsetzung über TDMA
(1) A B C
(2) A B C
t
r j i
u j i
d j i
Abbildung 3.2: Versand von Echtzeitnachrichten im reservierten Slot: (1)
Der Produzent i sendet die Nachrichten A, B und C wie eingeplant. (2) Ein
Zeitfehler verzögert die Übertragung. C wird nicht übertragen, da der Sendebeginn
hinter dem Übertragungsstartfenster liegt. C würde die Slotgrenze
verletzen.
• Die Periode p i ist die Zeitspanne zwischen zwei aufeinander folgenden Sendeslots
des Produzenten i. Beginnt ein Slot zur Zeit r j i
, folgt der nächste Slot also zum
Zeitpunkt r j+1
i
= r j i + p i.
• Die Zeit zwischen dem Beginn eines TDMA-Zyklus' z k und dem ersten Slot des
Produzenten i ist die Phasenverschiebung v i . Sie ist vor allem bei der Planung
des TDMA-Zyklus' relevant. Es gilt: r j i = zk + v i .
• Es muss garantiert sein, dass zum Zeitpunkt d j i
keine Datenübertragung mehr im
Gange ist. Hierfür wird der Produzent verpichtet, das bei der Planung berechnete
Übertragungsstartfenster f i einzuhalten. Es gibt die Zeitspanne nach r j i
an, in
der mit dem Senden begonnen werden darf. Nach dem Zeitpunkt u j i = rj i + f i darf
keine neue Übertragung gestartet werden, da diese sonst die Frist d j i
verletzen würde.
Zur Einhaltung des Protokolls benötigt der Produzent i lediglich die Periode p i , das Übertragungsstartfenster
f i und eine beliebige Bereitzeit r j i
. Aus der Bereitzeit kann durch Additionen
bzw. Subtraktion von Vielfachen der Periode die Menge aller späteren bzw. früheren
Bereitzeiten bestimmt werden. Abb. 3.2 veranschaulicht, wie Echtzeitnachrichten in einem
Slot übertragen werden. Bevor der Produzent zu senden beginnt, wartet er auf die nächste
Bereitzeit. Der Produzent sendet dann maximal die beim Planer reservierte Datenmenge,
für welche die Slotlänge ausgelegt ist. Kommt es bei dem Produzenten zu einem Zeitfehler,
der den Sendebeginn hinauszögert, könnte die Frist d j i
trotz ausreichender Slotlänge verletzt
werden. Das kann verhindert werden, indem vor jedem Sendebeginn überprüft wird,
ob die aktuelle Startzeit noch innerhalb des Übertragungsstartfensters f i liegt (t ≤ u j i ).
Falls dies nicht gegeben ist, darf nicht gesendet werden. Um auch zu frühzeitiges Auslösen
des Sendevorgangs zu erkennen, muss auÿerdem überprüft werden, ob t ≥ r j i .
Sendewiederholung bei CAN Wie bereits im Abschnitt 2.3.1 erwähnt, sieht das CAN-
Protokoll bei Übertragungsfehlern eine automatische Sendewiederholung durch die Hardware
vor. Damit bei CAN auch im Fehlerfall die Grenzen der TDMA-Slots eingehalten
werden, muss diese Sendewiederholung deaktiviert oder die maximale Anzahl der Wiederholungsversuche
eingeschränkt werden. Mit aktueller CAN-Hardware ist dies möglich.
29

3 Echtzeitkommunikationskanäle
Sendewiederholung bei Ethernet Wie in Abschnitt 2.4.1 beschrieben, ndet bei Ethernet
im Falle von Kollisionen eine Sendewiederholung nach dem Exponential-Backo-
Prinzip statt. Kollisionen werden jedoch durch das TDMA-Prinzip und die Planung der
Slots vermieden. Eine automatische Sendewiederholung bei anderen Fehlern sieht die Spezikation
von Ethernet nicht vor.
3.1.4 Nicht-Echtzeit-Kommunikation
Das Medienzugrisverfahren soll in der Lage sein, auch NRT-Nachrichten zu übertragen,
ohne die Garantien für die Echtzeitnachrichten zu gefährden. Denkbar wäre, auch für
NRT-Nachrichten Slots im TDMA-Zyklus zu reservieren, beispielsweise je Knoten. Diese
würden wegen des typischerweise sporadischen Auftretens der Nachrichten jedoch zu einer
schlechten Medienausnutzung führen, denn Knoten können nicht benötigte Slots nicht
an andere Knoten weitergeben, die diese Slots gerade benötigen. Auÿerdem müssten so
auch Knoten ohne Echtzeitaufgaben ihre Uhren synchronisieren. Dieser Aufwand kann
eingespart werden, indem TDMA mit einem anderen Arbitrierungsverfahren kombiniert
wird, beispielsweise einem Master/Slave-Ansatz. Dieser funktioniert zwar in allen Netzen,
erzeugt jedoch einen recht groÿen Nachrichtenoverhead und macht die Kommunikation
von einem Master abhängig. Im Interesse der Ezienz wurde sich daher für eine jeweils
individuelle Lösung der Nicht-Echtzeit-Arbitrierung entschieden.
3.1.4.1 Ethernet
Ethernet baut auf einem nicht-deterministischen MAC-Mechanismus auf, der die Wartezeit
bis zum Erhalten des Medienzugris nicht beschränkt. Die Ausführung des MAC-
Mechanismus' kann auch nicht gezielt unterbrochen werden, um das Medium zeitgesteuert
für einen Echtzeitslot freizumachen. Somit lässt sich der Mechanismus auch im Nicht-
Echtzeit-Bereich nicht ausnutzen.
Daher wird hier ein Master/Slave-Ansatz verfolgt, bei dem der Master innerhalb der freien
und ungenutzen 4 Slots des TDMA-Zyklus' die Sendeberechtigung für NRT-Nachrichten
vergibt. Diese Sendeberechtigung ist zeitlich begrenzt und geht nach dem Ablauf der
Zeit automatisch an den Master zurück. Sie wird in Form einer Poll-Nachricht an einen
konkreten Knoten gesendet.
Die Knoten haben folgende Eigenschaften:
• Jeder Knoten muss individuell adressierbar sein, denn es muss sichergestellt sein,
dass sich nie mehr als ein Knoten von einer Poll-Nachricht angesprochen fühlt. Anderenfalls
kann es zu Kollisionen kommen die wegen CSMA/CD mit Exponential
Backo die Einhaltung der Slotgrenzen gefährden.
4
Das in Abschnitt 3.3 vorgestellte Reservierungsprotokoll erlaubt die Ausweitung des Pollings auf reservierte
Slots, die von den Produzenten nicht zur Versendung von Nachrichten verwendet werden.
30

3.1 Durchsetzung über TDMA
• Der Knoten muss keine mit dem Master synchronisierte Uhr haben. Die Driftrate
5 der Uhren muss jedoch durch eine bekannte Schranke ρ max begrenzt sein.
• Jeder Knoten verwaltet eine Warteschlange von zu übertragenden NRT-
Nachrichten.
Mit der Poll-Nachricht werden die folgenden Informationen verschickt:
• Die Adresse des Knotens, der die Sendeberechtigung erhalten soll.
• Die Dauer der Sendeberechtigung. Da der Knoten keine zum Master synchrone
Uhr haben muss, kann kein absoluter Zeitwert verwendet werden. Stattdessen wird
die Dauer eines Übertragungsstartfensters übermittelt.
Adressierung der Knoten Damit alle Knoten die Gelegenheit zum Senden erhalten, muss
der Master alle im System vorkommenden Knotenadressen kennen, d. h. für dynamische
Systeme, alle Adressen, die im System während des Betriebs vorkommen können. Da die
Sendeberechtigung nach einer denierten Zeit automatisch an den Master zurückgeht, ist
das Pollen von gerade nicht verwendeten Adressen unproblematisch. Es führt lediglich zur
Verschwendung von Medienzeit, da die Sendeberechtigung für einen nicht aktiven Knoten
immer ungenutzt bleibt und sich die für aktive Knoten verfügbare Medienzeit verringert.
Zur Adressierung bietet sich die Verwendung der Ethernet-MAC-Adressen an. Hierdurch
können die Poll-Nachrichten per Unicast versendet werden, was im Vergleich zu Broadcast-
Nachrichten die Prozessoren der nicht angesprochenen Knoten entlastet. Bei der Umsetzung
gibt es zwei Möglichkeiten:
1. Man verwendet die in den Ethernet-Komponenten vorhandenen MAC-Adressen. Der
Adressraum für Unicast-Adressen ist hier mit 47 Bit deutlich zu groÿ, um alle
möglichen Adressen zu pollen. Daher muss dem Master eine Liste der Adressen aller
Knoten vorliegen, die etwas senden wollen. Diese Liste wird dann zyklisch abgearbeitet.
2. Alternativ kann der zu pollende MAC-Adressraum eingeschränkt werden, indem die
Bits der Adresse in einen vorgegebenen und einen variablen Bereich unterteilt werden.
Um beispielsweise 256 Knoten zu erlauben, könnte man die letzten 8 Bit der
Adresse variabel lassen und die ersten 40 Bit vorgeben. Der Master pollt dann alle
256 möglichen Adressen, unabhängig davon, ob die Adressen tatsächlich in Verwendung
sind. Bei dieser Methode ist eine Anpassung der MAC-Adressen aller Knoten
nötig, so dass jeder Knoten eine eindeutige Adresse aus diesem 8 Bit Adressraum
bekommt.
5
Unter der Drift versteht man die Abweichung einer Uhr CLK bezüglich einer Referenzuhr CLK R:
drift = CLK(t 2)−CLK(t 1 )
. Die Driftrate entspricht ρ = |drift − 1|. CLK R (t 2 )−CLK R (t 1 )
31

3 Echtzeitkommunikationskanäle
Der Autor bevorzugt die 1. Variante, da sie keine Anpassung von MAC-Adressen erfordert
und bezüglich der Knotenanzahl exibler ist. Auÿerdem kann bei dieser Variante die Erstellung
der Adressliste in Spezialfällen automatisiert werden:
• Wenn alle Knoten aktiv sind, bevor die erste Reservierung von Echtzeitslots statt-
ndet, kann der Master alle Knoten über eine Broadcast-Nachricht auordern,
ihm ihre MAC-Adressen zu senden. Denn bevor Echtzeitgarantien vergeben werden,
stellt die nicht-deterministische Kollisionsauösung von Ethernet kein Problem
dar. Der Masterknoten wartet nach dem Versenden bis zum Zeitpunkt t end , zu
dem sichergestellt ist, dass alle Knoten auf die Broadcast-Nachricht reagieren konnten.
Er wartet mindestens die maximale Round-Trip-Zeit 6 , so dass initial t end ←
t send + ∆t RT T ist. Wenn nach dieser Zeit keine Antworten angekommen sind, gibt es
keine zu pollenden Knoten im Netzwerk. Wenn eine Antwort eingegangen ist, gibt
es mindestens einen Knoten, der gepollt werden muss. Weitere Antworten könnten
in diesem Fall durch Kollisionen verzögert worden sein, so dass nach einer empfangenen
Antwort mindestens für die maximale Dauer des Exponential Backos (∆t EB )
gewartet werden muss. Für 10 Mbit/s liegt diese beispielsweise bei 366 ms (vgl.
[HJ03]). Somit muss beim Empfangen einer Antwort der Terminierungszeitpunkt
neu gesetzt werden: t end ← max{t end , t receive + ∆t EB }. Wenn der Zeitpunkt t end erreicht
wird, sind dem Poll-Master alle aktiven zu pollenden Knoten bekannt, so dass
mit dem Pollen und der Reservierung von Echtzeitkommunikationskanälen begonnen
werden kann.
• Der Master kann auch während des Echtzeitbetriebs dynamisch neue Knoten in seine
Liste integrieren, wenn durch Wissen der Anwendung garantiert ist, dass sich nie
mehrere Knoten gleichzeitig beim Master anmelden wollen. So beispielsweise, wenn
die Knoten nacheinander gestartet und initialisiert werden. Der Master sendet dann
regelmäÿig in einem freien Slot per Broadcast eine spezielle Poll-Nachricht, die einen
neu gestarteten Knoten auordert, seine Adresse zu übertragen.
Nach den Anforderungen, die FAMOUSO erfüllen soll, sind diese Fälle im Allgemeinen
nicht gegeben. Wenn die Anwendung jedoch einem der Spezialfälle gerecht wird, bringt
die Verwendung der angesprochenen Verfahren deutliche administrative Vereinfachungen
mit sich.
Dauer der Sendeberechtigung Der Poll-Master ist dafür zuständig, die Länge des Übertragungsstartfensters
(ÜSF) so zu bestimmen, dass der gepollte Knoten nur innerhalb
des freien bzw. ungenutzten Slots überträgt, damit die nachfolgenden Echtzeitnachrichten
nicht beeinträchtigt werden. Wenn der zur Verfügung stehende Slot hinreichend lang ist,
6
Die maximale Round-Trip-Zeit setzt sich aus der maximalen lokalen Verzögerung am Master beim
Senden, der maximalen Latenz bei der Übertragung des Broadcast-Pakets, der maximalen lokalen Verarbeitungszeit
beim Slave, der Latenz bei der Übertragung der Antwort sowie der maximalen lokalen
Verzögerung auf dem Master beim Empfangen zusammen.
32

3.1 Durchsetzung über TDMA
Slot beginnt
Poll-Übertragung beginnt
Poll-Übertragung endet
ÜSF beginnt
ÜSF endet
Slot endet
globale Zeit
∆ M
∆ P
∆ K
∆ F
∆ R
t g
Mediennutzung Poll K A B
lokale Zeit in K
τ F
t lK
ÜSF-Timer gestartet
ÜSF-Timer läuft ab
Abbildung 3.3: Versand von NRT-Nachrichten bei Ethernet: In einem freien
oder ungenutzten Slot übergibt der Master dem Knoten K in einer Poll-
Nachricht eine zeitlich begrenzte Sendeberechtigung. K versendet hier die
Nachrichten A und B.
kann der Master ihn in mehrere Teile unterteilen und so nacheinander mehrere Sendeberechtigungen
vergeben. Im Folgenden wird die Dauer des betrachteten Teils bzw. des
gesamten Slots als verfügbare Slotdauer bezeichnet.
Die verfügbare Slotdauer ∆ setzt sich aus mehreren Zeitintervallen zusammen, die in
Abb. 3.3 veranschaulicht sind.
∆ = ∆ M + ∆ P + ∆ K + ∆ F + ∆ R
• ∆ M ist die maximale Verzögerung ab dem Anfang des Slots bis die Übertragung
der Poll-Nachricht des Masters auf dem Medium beginnt. Sie ist von der Hard- und
Software des Masters abhängig.
• ∆ P bezeichnet die Zeit zur Übertragung der Poll-Nachricht an den Knoten K. Sie
wird im Wesentlichen durch die Bitrate und die minimale Ethernet-Framelänge bestimmt.
• ∆ K ist die maximale Verzögerung im Knoten K, bis dieser den Zeitstempel zur
Bemessung des ÜSF nimmt. Sie hängt von der Hard- und Software des Knotens K
ab.
33

3 Echtzeitkommunikationskanäle
• ∆ F ist die gesuchte Länge des ÜSF. Der Knoten K muss vor jedem Sendebeginn
überprüfen, ob der momentane Zeitpunkt noch im ÜSF liegt.
• ∆ R ist die Reservezeit nach dem ÜSF. Sie entspricht mindestens der Summe aus der
Übertragungszeit des längsten erlaubten Frames und der maximalen Verzögerung
zwischen der ÜSF-Überprüfung und dem tatsächlichen Beginn der Übertragung.
Zur Berechnung der gesuchten Variable ∆ F ergibt sich durch Umstellung und Zusammenfassung
der Konstanten:
∆ F = ∆ − (∆ M + ∆ P + ∆ K + ∆ R )
= ∆ − ∆ MP KR
Das hier bestimmte ÜSF garantiert die Einhaltung der Slotgrenze jedoch nur, wenn der
Knoten K über eine synchronisierte Uhr verfügt. Im Allgemeinen ist das jedoch nicht
der Fall. Daher muss dass ÜSF noch gekürzt werden, um die Garantie auch zu erhalten,
wenn die Uhr im Knoten K zu langsam läuft. Denn wenn der ÜSF-Timeout durch eine zu
langsam laufende Uhr bestimmt wird, löst er zu spät aus, so dass der Knoten die Slotgrenze
durch einen zu späten Übertragungsbeginn gefährdet. Die Länge des ÜSF lässt sich mit
Hilfe der maximalen Driftrate der Uhr von Knoten K hinreichend verkürzen:
τ F =
∆ F
ρ max + 1
In der Poll-Nachricht wird τ F als Länge des ÜSF versendet. Im Knoten K muss τ F auf
ein Vielfaches der dortigen Uhrengranularität abgerundet, also auf das nächstkleinere
Vielfache reduziert werden. So ist auch bei einer maximal abdriftenden Uhr im Knoten K
die Einhaltung der Slotgrenzen gesichert.
Erhöhung der Medienausnutzung NRT-Nachrichten werden oft in Bursts versendet, d. h.
die Sendezeitpunkte sind nicht gleichmäÿig über die Zeit verteilt. Stattdessen produziert
ein Knoten innerhalb einer kurzen Zeit sehr viele Nachrichten, die sich in der Warteschlange
stauen. Werden alle Knoten nacheinander gepollt, unabhängig davon wie viele Daten sie
zu versenden haben, so führt das bei ungleich gefüllten Warteschlangen zu hohen Latenzen
und einer schlechten Ausnutzung des Mediums. Dieses Problem lässt sich reduzieren, indem
die gepollten Knoten in einem Headerfeld ihrer NRT-Nachrichten mitschicken, wie viele
NRT-Nachrichten noch in ihrer Warteschlange stehen. Der Master kann diese Information
34

3.1 Durchsetzung über TDMA
NRT A NRT B RT A 1 NRT C RT B 1
RT 2 NRT D NRT E
r j 1 u j 1 d j 1 = rk 2
u k 2 d k 2
Abbildung 3.4: Mediennutzung bei CAN am Beispiel. Es gibt keine
Sendebeschränkungen für NRT-Nachrichten, so dass RT-Nachrichten durch
NRT-Nachrichten verzögert werden können. Wenn RT-Nachrichten kürzer
sind als reserviert, steht die frei werdende Medienzeit für NRT-Nachrichten
zur Verfügung.
t
ausnutzen, um den Knoten mit mehr wartenden Nachrichten häuger die Sendeberechtigung
zu erteilen. Sie darf jedoch nicht einziges Kriterium sein, damit auch Knoten mit
geringem Nachrichtenaufkommen noch senden dürfen.
3.1.4.2 CAN
Bei CAN lässt sich die prioritätsbasierte Arbitrierung des CAN-Protokolls ausnutzen, um
auf einfachem Wege eine sehr eziente Übertragung von NRT-Nachrichten zu ermöglichen.
Der vorgeschlagene verteilte Ansatz ist sehr verlässlich, dynamisch und erfordert keine
speziellen Knoten oder zusätzliche Konguration. Er erlaubt auÿerdem das Versenden von
NRT-Nachrichten ohne synchrone Uhren.
Der Preis für die Vorteile ist eine Lockerung des TDMA-Modells, die mit einer leichten Erhöhung
des Jitters einhergeht. Echtzeitslots werden, wie in Abschnitt 3.1.3 beschrieben, für
einen Produzenten von Echtzeitnachrichten reserviert. Während eines solchen Slots darf
kein anderer Produzent Echtzeitnachrichten senden. Anders als im allgemeinen Fall dürfen
bei CAN NRT-Nachrichten jedoch auch innerhalb von reservierten Slots versendet werden.
Dabei muss sichergestellt werden, dass NRT-Nachrichten immer eine niedrigere Priorität
haben als Echtzeitnachrichten. Bei der Arbitrierung gewinnt dadurch eine Echtzeitnachricht
immer gegen eine NRT-Nachricht.
NRT-Nachrichten können jederzeit gesendet werden. Dadurch kann beim Medienzugri
eine zusätzliche Verzögerung entstehen, die durch die maximale Übertragungsdauer eines
Frames beschränkt ist. Dies muss bei der Planung der Echtzeitslots berücksichtigt werden
(siehe Abschnitt 3.2). Abb. 3.4 veranschaulicht den Medienzugri anhand eines
beispielhaften TDMA-Zyklus-Ausschnitts. Die Nachricht NRT A wird dort während eines
freien Slots gesendet. NRT B ragt in den Echtzeitslot und verzögert so RT1 A . NRT C wird
sendebereit, während RT1 A übertragen wird. Daher erfolgt unmittelbar nach RT1 A eine neue
Arbitrierung. Diese gewinnt NRT C , weil RT1
B noch nicht sendebereit im CAN-Controller
liegt. Die Software triggert die Versendung von RT1
B zwar ohne Zeitfehler vor Ende des
ÜSF, den Medienzugri erhält die CAN-Hardware jedoch erst nach dem Ende der Übertragung
von NRT C , da diese bereits im Gange ist, als RT1
B im CAN-Controller sendebereit
35

3 Echtzeitkommunikationskanäle
wird. Das ÜSF wird entsprechend geplant, dass RT1
B auch ohne die Verletzung der Slotgrenze
verschickt werden kann, wenn eine Arbitrierung verpasst und zwischenzeitlich eine
NRT-Nachricht übertragen wird. RT 2 wird nicht verzögert, hat aber nicht die eingeplante
maximale Länge, so dass sie das Medium vorzeitig freigibt. Die frei werdende Medienzeit
wird bei Bedarf automatisch für NRT-Nachrichten genutzt.
Anders als für Echtzeitnachrichten, muss für NRT-Nachrichten die automatische
Sendewiederholung von CAN nicht deaktiviert oder begrenzt werden, wenn eine zuverlässige
Übertragung gewünscht ist. Die Sendewiederholung ist unproblematisch, da
beim erneuten Senden eine neue Arbitrierung stattndet, die einer ggf. wartenden
Echtzeitnachricht den Vortritt gewährt.
Priorisierung der Nachrichten Die nötige Priorisierung lässt sich realisieren, indem das
höchstwertigste Bit der CAN-ID zur Unterscheidung von Echtzeit- und Nicht-Echtzeit-
Nachrichten verwendet wird. Bei Echtzeitnachrichten steht an dieser Stelle der Bitwert 0,
bei NRT-Nachrichten der Bitwert 1. Damit haben Echtzeitnachrichten immer eine zahlenmäÿig
kleinere ID und somit die höhere Priorität. Um zu garantieren, dass eine ID nicht
doppelt verwendet wird, muss in dem Bitfeld auÿerdem eine Knoten-ID des Absenders
codiert sein.
Es können auch mehrere der höchstwertigen Bits zur Codierung einer Priorität verwendet
werden. Bei Echtzeitnachrichten werden alle diese Bits auf 0 gesetzt. Die restlichen
verfügbaren Prioritätswerte können beliebig verwendet werden. Mit ihnen können z. B.
verschiedene Wichtigkeits- bzw. Dringlichkeitsklassen für NRT-Nachrichten geschaen werden,
beispielsweise um Verwaltungs- und Anwendungsnachrichten unterschiedlich zu priorisieren.
36

3.2 Dynamische Planung
3.2 Dynamische Planung
Wie im ersten Teil des Kapitels ausführlich behandelt, werden die Echtzeitgarantien beim
Medienzugri über ein TDMA-Schema realisiert. Um Echtzeitkommunikationskanäle zur
Laufzeit aufbauen zu können, müssen die Produzenten von Echtzeitnachrichten dem Planer
ihre QoS-Anforderungen übermitteln. Dieser überprüft anschlieÿend die Einplanbarkeit.
Wenn die Einhaltung der Anforderungen garantiert werden kann, reserviert der Planer
die entsprechende Medienzeit als Kommunikationskanal für den Produzenten und teilt
das diesem mit. Falls die Einplanung nicht möglich ist, wird auch dies dem Produzenten
mitgeteilt. Es wird ein zentralisierter Planungsansatz bevorzugt, weil dieser im Vergleich zu
einem verteilten Ansatz mit deutlich geringeren Ressourcen-Anforderungen für die Knoten
einhergeht, da die Planungskomplexität komplett in einen oder mehrere Master-Knoten
verlagert wird. So können auch kleinste eingebettete Systeme wie Smart Sensors an der
dynamischen Medienzeitvergabe partizipieren.
Im Folgenden wird zunächst das Planungsproblem genauer dargestellt. Es folgt in Abschnitt
3.2.2 eine Abhandlung über die Dimensionierung der Slotlängen und der zugehörigen
Übertragungsstartfenster. Der Abschnitt 3.2.4 geht auf die eigentliche Planung
des TDMA-Zyklus' ein. In dieser Arbeit wird nur die Echtzeitplanung für ein Broadcast-
Medium besprochen. Garantien, die über die Grenzen eines Netzwerksegments hinweg
gehen, werden in Abschnitt 3.3.6 für eine auf dieser Diplomarbeit aufbauende, weiterführende
Arbeit vorgeschlagen. Ein Protokoll für die nötige Kommunikation zwischen Produzenten
und dem Planer-Master wird in Abschnitt 3.3 vorgestellt.
3.2.1 Planungsproblem
Ein Echtzeitnachrichten-Produzent i kann seine Anforderungen über folgende Parameter
ausdrücken:
1. Maximale Nachrichtenlänge LB i in Bytes: Es wird davon ausgegangen, dass
je Echtzeitslot eine Nachricht mit der maximalen Länge von LB i Bytes versendet
wird. Diese wird gegebenenfalls in mehrere Fragmente zerlegt, die jeweils als einzelne
Frames übertragen werden. Der Produzent bestimmt aus LB i die Fragmentanzahl
Ni
∗ sowie die Gesamtdatenmenge aller Fragmente LBi ∗ , welche der Summe aus
LB i und der Byteanzahl der zusätzlichen Header-Informationen entspricht, also der
Gesamtdatenmenge der Nutzdaten, die in den Frames übertragen werden. Durch
die Anreicherung der Anforderungen um LBi ∗ und Ni
∗ muss der Planer keine Kenntnisse
über die bei der regulären Datenübertragung verwendeten Protokolle, wie das
Fragmentierungsprotokoll, haben.
2. Wiederholung Rep i (engl.: repetition): Um die Zuverlässigkeit der Datenübertragung
zu erhöhen, kann ein Produzent zusätzliche Medienzeit für zeitredundante
37

3 Echtzeitkommunikationskanäle
(A)
Sensorwert holen
und vorverarbeiten
R 4 D 4
Spielraum zum Versenden
des Sensorwerts
Ansteuerung
eines Aktors
t
(B) RT 2 RT 1 RT 4
RT 2
(C)
Versenden des Sensorwerts
durch die Middleware
Abbildung 3.5: Synchronisierung von Produzent und Kommunikationskanal
mit Hilfe des Slot-Rahmenintervalls am Beispiel: (A) Die lokale Planung der
Prozessorzeit des Knotens sieht nicht verschieb- oder unterbrechbare Aktivitäten
vor. Das verbleibende Zeitfenster, in dem die Daten versendet werden
können und sollen, kann dem Netzwerkplaner über das Slot-Rahmenintervall
mitgeteilt werden. Dieser wählt die Phasenverschiebung des Kommunikationskanals
passend, so dass Medienplanung (B) und Prozessorplanung (C) harmonieren.
Versendung reservieren lassen. Durch die mehrfache Übertragung erhöht sich die
Wahrscheinlichkeit, dass die Daten korrekt empfangen werden. Rep i muss ganzzahlig
und gröÿer oder gleich Null sein und wird als Wiederholungsfaktor für die aus LB i
bestimmten Frames verwendet. Die Angabe von Rep i ist optional. Beim Fehlen einer
expliziten Angabe wird Rep i = 0 angenommen, so dass jeder Frame nur einmal
versendet wird.
3. Periode p i : Die Periode bestimmt die Zeitspanne zwischen zwei aufeinander folgenden
Sendeslots.
4. Slot-Rahmenintervall (R i , D i ): Hierüber kann der Produzent den für die Positionierung
des Slots infrage kommenden Zeitrahmen einschränken. R i ist der früheste
mögliche Zeitpunkt für den Beginn eines Übertragungsslots und D i der letzte erlaubte
Zeitpunkt für das Ende desselben Slots. Bei R i und D i kann es sich auch um
bereits vergangene Zeitpunkte handeln, denn im Zusammenhang mit der Periode p i
ist die Positionierung für alle früheren oder späteren Slots eingegrenzt. Die Parameter
sind optional. Sie lassen sich ausnutzen, um den Echtzeitkommunikationskanal
mit der lokalen Ressourcenplanung des Produzentenknoten zu synchronisieren. Auf
diese Weise lässt sich beispielsweise eine geringe Verzögerung von der Erzeugung
bis zur tatsächlichen Übertragung der Daten erreichen. Auÿerdem kann auf diesem
Wege, wie in Abb. 3.5 illustriert, die Nebenläugkeit von Produktions- und Sende-
Task vermieden werden, so dass ein weniger komplexes System nötig ist, das auch
auf Hardware mit stärkeren Ressourcenbeschränkungen lauähig ist.
38

3.2 Dynamische Planung
Die Periode muss als Vielfaches der Planungsgranularität G angegeben werden. Die Planungsgranularität
entspricht der Uhrengranularität g oder einem Vielfachen dessen. Die
Wahl der Planungsgranularität wird in Abschnitt 3.2.5 diskutiert.
Aufgabe des Planers ist die Überprüfung, ob die Reservierung des Kommunikationskanals
gemäÿ der gegeben Anforderungen im Kontext der bereits vorhandenen Reservierungen
möglich ist. Wenn ja, muss er für die Etablierung des Kommunikationskanals die Startzeit
des ersten zu nutzenden Slots ri
start sowie die Länge des Übertragungsstartfensters f i bestimmen
und an den Produzenten übermitteln. Neben diesen Gröÿen muss auch die Slotdauer,
die Phasenverschiebung und die neue Länge des TDMA-Zyklus' berechnet werden.
Auÿerdem muss der Planer einen eventuell vorhandenen Poll-Master informieren, welche
Slots frei sind und somit für NRT-Nachrichten genutzt werden können.
3.2.2 Slotlänge und Übertragungsstartfenster
Die Länge bzw. Dauer der Echtzeitslots eines Produzenten muss berechnet werden, um eine
überschneidungsfreie Planung des TDMA-Zyklus' zu ermöglichen. Sie muss hinreichend
groÿ gewählt werden, um garantieren zu können, dass bei der Übertragung der Echtzeitnachrichten
die Slotgrenzen eingehalten werden. Das Übertragungsstartfenster (ÜSF) soll
dem Produzenten die Erkennung von Zeitfehlern erleichtern, um den Eekt der Fehler
einzugrenzen. Es gibt die Dauer eines Zeitintervalls ab dem Slotbeginn an, während der
das Senden einer Nachricht zulässig ist. Späteres Senden könnte zur Verletzung der Slotgrenzen
führen, die eine Ausweitung des Zeitfehlers auf das Gesamtsystem, und dadurch
einen Funktionsausfall zur Folge haben kann.
3.2.2.1 Modellierung der Slots
Abb. 3.6 veranschaulicht das für die Berechnungen aufgestellte Modell. Alle Parameter des
Modells sind Worst-Case-Werte, d. h. für Zeiträume wird jeweils die längste mögliche Dauer
herangezogen, denn nur so können die Garantien auch bei der Verkettung von ungünstigen
Umständen eingehalten werden. Wie bereits im vorherigen Abschnitt erwähnt, können
mehrere Frames pro Slot übertragen werden. Jeder der N i Frames hat ein eigenes Worst-
Case-Fenster der Länge ˆδ j i 7 . Ein solches Fenster j setzt sich jeweils wie folgt zusammen:
ˆδ j i
=
⌈
ˆFi + ˆB i + Ŵi + ˆM j i
⌉
1. ˆFi bezeichnet die maximale Zeit zwischen dem Auslösen (engl.: trigger) des Sendevorgangs
eines Frames und der Überprüfung auf Einhaltung des ÜSF. Diese Zeit ist
von Hard- und Software des Produzenten i abhängig.
g
7
Das Dach-Symbol ˆ ist im Folgenden ein Kennzeichen, dass die Gröÿe den maximal vorkommenden Wert
(Worst-Case) beinhaltet.
39

3 Echtzeitkommunikationskanäle
Slot beginnt
Slot endet
li
ˆδ1 ˆδNi
i i A
Worst-Case-Fenster
erster Frame
Worst-Case-Fenster
letzter Frame
t
fi
ˆFi
ˆBi
Ŵi
ˆM
1
i
ˆFi
ˆBi
Ni
Ŵi
ˆM
i
t
Trigger
Überprüfung ÜSF ∗
Hardware sendebereit ∗
Sendebeginn auf Medium ∗
Medium wieder frei ∗
nächster mögl. Trigger ∗
Trigger ∗
Überprüfung ÜSF ∗
letzter positiver ÜSF-Test
Hardware sendebereit ∗
Sendebeginn auf Medium ∗
Medium wieder frei ∗
nächster mögl. Trigger ∗
∗
spätester Zeitpunkt
Abbildung 3.6: Modellierung eines Echtzeitslots des Produzenten i zur Bestimmung der Slotlänge li und des ÜSF fi für Ni Frames
40

3.2 Dynamische Planung
2. ˆBi ist die maximale Zeit, die nach der ÜSF-Überprüfung vergeht, bis die Hardware
zum Versenden des Frames über das Medium bereit ist. Auch diese ist hard- und
softwareabhängig.
3. Ŵ i beinhaltet die maximale Wartezeit der Hardware auf das Erhalten des Medienzugris.
Sie ist vom Netzwerk und Medienzugrisverfahren abhängig. Bei dem in
dieser Arbeit verwendeten Verfahren ist Ŵi = Ŵ für alle Produzenten gleich.
j
4. ˆM
i
ist die maximale Dauer der tatsächlichen Übertragung des Frames über das Medium.
Sie wird vom Beginn der Übertragung bis zum erneuten Sendebereit-Werden des
Mediums gemessen. Diese Gröÿe ist von der maximalen Länge der zu übertragenden
Daten, dem verwendeten Netzwerk und seiner Übertragungsrate abhängig.
5. Für den Fall, dass das Versenden aller Frames in einem Slot zeitgesteuert ausgelöst
wird, muss die Granularität der Uhr bei Bestimmung der Fenstergröÿe berücksichtigt
werden. Das Fenster wird bis zum nächsten möglichen Trigger-Zeitpunkt erweitert,
indem die Summe der oben beschriebenen Zeiten auf ein Vielfaches der Uhrengranularität
aufgerundet wird.
Das ÜSF wird so dimensioniert, dass ein pünktlich triggernder Knoten unter Einhaltung
der zur Berechnung herangezogenen Parameter immer alle seine eingeplanten Frames
senden kann. Zur Bestimmung des ÜSF wird folglich die Zeit vom Beginn des Slots bis
zum spätesten Überprüfungszeitpunkt des ÜSF im letzten Frame herangezogen.
f i =
⎡
⎤
N∑
i −1
ˆδ j i
⎢
+ ˆF i ⎥
j=1
⎥
g
Das ÜSF wird auf ein Vielfaches der Uhrengranularität g aufgerundet, um ein fehlerfreies
Vergleichen mit der aktuellen Zeit zu ermöglichen, die in Schritten der Weite g fortschreitet
8 .
Nach dem ÜSF muss noch hinreichend Zeit bleiben, um die Übertragung des letzten Frames
abzuschlieÿen. Die Summe wird wieder auf ein Vielfaches der Uhrengranularität aufgerundet,
um die eben erwähnten Granularitätsprobleme beim Sende-Trigger des nachfolgenden
Slot zu vermeiden.
l ′ i =
⌈
f i + ˆB i + Ŵi + ˆM
⌉
N i
i
Zur Vervollständigung des Slots muss auÿerdem ein Zeitpuer von A eingeplant sein, um
der Ungenauigkeit der Uhren gerecht zu werden. Im Allgemeinen muss A = 2α gesetzt
8
Zeitpunkte, die innerhalb eines Granularitätsticks liegen, sind nicht unterscheidbar. Zum Beispiel werden
bei g = 10 die Zeitpunkte 11 und 19 gleichermaÿen auf die Zeit 10 abgebildet. Ein Vergleich mit einem
Zeitstempel höherer Granularität, wie 15, bringt falsche Ergebnisse. Der Zeitpunkt 19 wird als früher
eingeordnet, liegt jedoch in Wahrheit später.
g
41

3 Echtzeitkommunikationskanäle
werden, da die Ticks der Uhren verschiedener Knoten nach Annahme bis zu 2α zeitversetzt
liegen können. Wurde der aktuelle Slot α zu spät begonnen, tritt so auch kein Konikt
auf, wenn der nachfolgende Knoten α zu früh beginnt. Wenn in der MAC-Schicht CSMA
zum Einsatz kommt und α > ˆM N i
i
ist, kann A = α gewählt werden. Geht die Uhr eines
Knotens vor, so dass er vor dem Beginn seines Slots senden will, wartet er durch CSMA
auf das Freiwerden des Mediums, also maximal bis zum tatsächlichen Beginn des Slots.
Die zur Planung des TDMA-Zyklus' verwendete Länge l i erhält man durch Aufrundung
auf ein Vielfaches der Planungsgranularität G.
l i = ⌈ l ′ i + A ⌉ G
Während sich die Parameter Ŵ i und ˆM j i
aus den Netzwerkeigenschaften herleiten
lassen (siehe folgende Abschnitte), sind ˆF i und ˆB i schwieriger zu bestimmen. Sie hängen
von der konkret verwendeten Software und Hardware ab. Sind alle verwendeten
Komponenten bekannt, lassen sich die Werte analytisch ermitteln, indem die Worst-
Case-Ausführungszeiten der genutzten Software- und Hardwarefunktionen addiert werden.
Unter Umständen ist auch eine Messung von Ausführungszeiten denkbar. Jedoch
muss beachtet werden, dass Hardware oft auf im Durchschnitt hohe Performance optimiert
ist, z. B. wenn Speicher-Cache zum Einsatz kommt. Hier wird in der Regel ein Wert
gemessen, der weit unter dem Worst-Case liegt. Auÿerdem muss ein groÿes Augenmerk
auf die Genauigkeit der Messmethode gelegt werden.
Besonders wichtig ist eine korrekte, also nicht zu niedrige, Abschätzung von ˆB i . Ein zu
kurzes ˆB i kann zu Zeitfehlern auf dem Medium führen, die sich auf die Funktionsfähigkeit
des Gesamtsystems auswirken können.
Bei der Umsetzung der Slotlängen-Berechnungen in FAMOUSO wird von jeweils einer
gemeinsamen oberen Schranke ˆF bzw. ˆB für alle Produzenten (Publisher) ausgegangen.
3.2.2.2 Frame-Anzahl und -Nutzdatenmengen
Für die Anwendung des Modells aus dem vorherigen Kapitel, müssen noch einige Parameter
bestimmt werden. Grundlegend ist die Anzahl der Frames N i . Sie berechnet sich
aus der Fragmentanzahl Ni
∗ und dem Wiederholungsfaktor Rep i , die als Anforderungen
gegeben sind. Jedes der Ni
∗ Fragmente wird Rep i Mal wiederholt:
N i = N ∗ i + N ∗ i · Rep i
= N ∗ i · (Rep i + 1)
Auÿerdem werden für die Bestimmung der maximale Übertragungsdauer der Frames die
Nutzdatenmengen benötigt, die in den jeweiligen Frames übertragen werden sollen. Zur
42

3.2 Dynamische Planung
Berechnung der Werte werden die Anforderungen Ni
∗ und Rep i sowie LBi ∗ , die Gesamtdatenmenge
aller Fragmente, herangezogen. Es wird davon ausgegangen, dass alle Fragmente
mit Ausnahme des letzten immer die volle MT U 9 ausnutzen, so dass die zugehörigen
Frames LB j i
= MT U Byte Nutzdaten enthalten. Das letzte Fragment transportiert
die nach den vorherigen Fragmenten noch verbleibenden Nutzdaten, so dass
hier LB j i
= LBi ∗ − (Ni ∗ − 1) · MT U gilt. Jedes Fragment wird nach der ersten Übertragung
Rep i Mal wiederholt, so dass jedes Fragment in (Rep i + 1) Frames übertragen
wird. Die Anzahl der Frames, die nicht das letzte Fragment enthalten, ist daher
Ni
MT U = (Ni ∗ − 1) · (Rep i + 1) = N i − (Rep i + 1). Somit ergibt sich die Nutzdatenmenge
des Frames j wie folgt:
LB j i
=
{
MT U
LB ∗ i − (N ∗ i
− 1) · MT U
für 1 ≤ j ≤ Ni
MT U
für N
MT U
+ 1 ≤ j ≤ N i
i
3.2.2.3 CAN
In diesem Abschnitt wird die Bestimmung der Modellparameter Ŵi und ˆM j i
für CAN-
Netze besprochen. Einussfaktoren sind hier die Bitrate, mit welcher der Bus betrieben
wird, und die Länge der zu versendenden Frames. Die Bitrate bestimmt die Zeit τ bit zur
Übertragung eines einzelnen Bits.
τ bit =
1
Bitrate
Die Dauer der Übertragung eines Frames mit der Nutzdatenlänge LB j i
variiert mit dem
Nachrichteninhalt, da gemäÿ der Bit-Stung-Regel zusätzliche Bits eingefügt werden
müssen. Sie ist jedoch durch folgendes Maximum beschränket (vgl. [DB07]):
Ĉ j i
=
(8 · LB j i + 67 + ⌊
= (10 · LB j i + 80) · τ bit
⌋)
8 · LB j i + 54 − 1 · τ bit
4
Es wird von der Verwendung von 29-Bit-Identiern ausgegangen. Neben den 8 · LB j i
Bit
Nutzdaten ist das Medium hier für weitere 67 Bitzeiten belegt, die sich aus Frame-Header-
Feldern und Inter-Frame Space zusammensetzen. Die Bit-Stung-Regel wird auf alle Nutzdatenbits
und auf 54 der Overhead-Bits angewendet. Im Worst-Case wird nach den ersten
5 Bits und im Anschluss nach jeweils 4 Bits ein Stu-Bit eingefügt 10 . Wird das Stung
auf N Bits angewendet, so werden folglich maximal ⌊ ⌋
N−1
4 Bits eingefügt.
9
MTU = Maximum Transmission Unit (maximale Nutzdatenmenge in einem Frame)
10
Auch die Stu-Bits selbst müssen beim Bit-Stung berücksichtigt werden. So wird die Bitfolge
"00000111100001" beispielsweise in "00000111110000011" überführt.
43

3 Echtzeitkommunikationskanäle
Bitrate τ bit
ˆMmin ˆMmax
1 Mbit/s 1 µs 111 µs 191 µs
500 Kbit/s 2 µs 222 µs 382 µs
250 Kbit/s 4 µs 444 µs 764 µs
Tabelle 3.1: Zeitparameter bei CAN. Die Übertragungsdauer für ein Bit
sowie für eine Nachricht mit minimaler und maximaler Nutzdatenmenge für
typische Bitraten bei 29-Bit-IDs
Die maximale Dauer von Inanspruchnahme bis zur erneuten Freigabe des Mediums erhöht
sich bei Beachtung der Mechanismen zur Fehlersignalisierung um weitere 31 Bitzeiten.
ˆM j i
= Ĉj i + 31τ bit
= (10 · LB j i + 111) · τ bit
Die Tab. 3.1 gibt einen Überblick über die Worst-Case Medienbelegungszeiten für Nachrichten
ohne Nutzdaten bzw. mit dem Maximum von 8 Byte Nutzdaten.
Bei CAN können jederzeit NRT-Nachrichten mit beliebiger Nutzdatenmenge versendet
werden. Bei einer Arbitrierung gewinnt jedoch eine Echtzeitnachricht immer gegen eine
NRT-Nachricht. Somit entspricht die maximale Wartezeit auf das Freiwerden des Mediums
Ŵi der maximalen Medienbelegungszeit für die längste mögliche Nachricht.
Ŵ i = ˆM max
= (10 · 8 + 111) · τ bit = 191τ bit
3.2.2.4 Ethernet
Dieser Abschnitt behandelt die Modellparameter Ŵi und ˆM j i
für typische Ethernet-Netze
gemäÿ IEEE 802.3 [iee08]. Wie bei CAN spielt auch hier die Bitrate eine wesentliche Rolle,
denn sie bestimmt die Bitübertragungszeit τ bit .
Jedem übertragenen Frame wird eine Präambel der Länge 8 Byte vorangestellt. Der Frame
besteht aus 18 Byte Headerdaten und bis zu MT U = 1500 Byte Nutzdaten. Er muss
jedoch immer eine minimale Länge von 64 Byte haben und wird falls nötig verlängert. Die
Übertragung eines Frames mit LB j i
Byte Nutzdaten dauert folglich:
C j i = (8 + max{64, 18 + LBj i }) · 8τ bit
44

3.2 Dynamische Planung
Bitrate τ bit
ˆMmin ˆMmax
10 Mbit/s 0,1 µs 67,2 µs 1.230,4 µs
100 Mbit/s 0,01 µs 6,72 µs 123,04 µs
1 Gbit/s 0,001 µs 4,26 µs 12,304 µs
Tabelle 3.2: Zeitparameter bei Ethernet. Die Übertragungsdauer für ein Bit
sowie für eine Nachricht mit minimaler (0 Byte) und maximaler Nutzdatenmenge
(1500 Byte) für typische Bitraten.
Bei Gigabit-Ethernet muss der Frame mindestens 4.096 Bitzeiten lang sein, so dass sich
dort statt einem Minimum von 64 Byte ein Minimum von 512 Byte ergibt:
C j i = (8 + max{512, 18 + LBj i }) · 8τ bit
Hinzu kommt ein Inter-Packet-Gap, also ein minimale Wartezeit nach der Übertragung
eines Pakets. Diese beträgt 96 Bitzeiten.
ˆM j i
= C j i + 96τ bit
Tab. 3.2 gibt einen Überblick zu typischen Zeitparametern von Ethernet nach der aufgestellten
Berechnungsvorschrift. Ethernet ist ein sehr umfangreicher Standard mit zahlreichen
Facetten, deren Betrachtung an dieser Stelle den Rahmen sprengen würde, wie beispielsweise
Envelope-Frames mit erweiterter maximaler Nutzdatenmenge, Packet-Bursting oder
die Möglichkeit zur Verlängerung des Inter-Packet-Gaps. Kommen diese Besonderheiten
zum Einsatz, müssen sie bei der Berechnung der maximalen Medienbelegungszeit berücksichtigt
werden.
Durch das TDMA-Schema, das Nachrichten verschiedener Absender bei Ethernet zeitlich
isoliert, muss vor der Übertragung nicht auf das Freiwerden des Mediums gewartet werden.
Ŵ i = 0
3.2.3 Phasenverschiebungsfenster
Das Slot-Rahmenintervall, welches von einem Produzenten als Anforderung angegeben werden
kann, ist durch absolute globale Zeitwerte gegeben. Für die Planung des TDMA-Zyklus'
werden jedoch Phasenverschiebungswerte relativ zum Zyklusbeginn z k benötigt. Daher
wird das Slot-Rahmenintervall (R i , D i ) in das Phasenverschiebungsfenster (vi
min , vi width )
umgerechnet:
45

3 Echtzeitkommunikationskanäle
v min
i =
(
⌈R i ⌉ G
− z k) mod + p i
v width
i = ⌊D i ⌋ G
− l i − ⌈R i ⌉ G
Die Werte müssen in das durch die Planungsgranularität G vorgegebene Zeitraster passen.
Daher wird R i als frühster erlaubter Zeitpunkt auf das nächsthöhere Vielfache von
G aufgerundet, während D i als spätester erlaubter Zeitpunkt auf ein Vielfaches von
G abgerundet wird. Die Variable z k entspricht dem Zeitpunkt des Beginns vom aktuellen
TDMA-Zyklus. Falls ⌈R i ⌉ G
− z k < 0 ist, stellt die Operation mod + sicher, dass
0 ≤ vi
min < p i gilt.
Nach der Berechnung der bei der Planung gesuchten Phasenverschiebung v i (siehe folgender
Abschnitt), muss ein absoluter Zeitpunkt für den Beginn des ersten Sendeslots
bestimmt werden:
r start
i = z k + v i
Falls der Zeitpunkt ri
start nicht in der Zukunft liegt, wenn er den Produzenten i erreicht,
kann dieser ihn in einen zukünftigen Zeitpunkt überführen, indem er Vielfache der Periode
addiert.
3.2.4 Planung des TDMA-Zyklus'
Das hier beschriebene Planungsverfahren dient der Reservierung von Medienzeit für Produzenten
von Echtzeitnachrichten gemäÿ deren Anforderungen. Eine Zuteilung von Medienzeit
in Form eines Kommunikationskanals aus periodisch wiederholten Slots erfolgt
nur dann, wenn die Anforderungen im Kontext der schon eingeplanten Kanäle erfüllbar
sind, ohne dass sich Slots überschneiden.
Die Anforderungen sind hier in Form einer Periode p i , einer Slotlänge l i und optional
eines Phasenverschiebungsfensters (vi
min , vi
width ) gegeben. Die Slotlänge und das Intervall
wurden in den vorherigen Abschnitten aus anderen Parametern bestimmt. Die Periode
stammt direkt vom Produzenten. Wenn eine Reservierung möglich ist, bestimmt der Planer
die Phasenverschiebung v i der Slots. Aus dieser kann, wie im vorherigen Abschnitt
beschrieben, die Bereitzeit ri
start berechnet werden, zu der dem Produzenten i das Medium
für die erste Datenübertragung zur Verfügung steht. Alle Gröÿen sind hier Vielfache
der Planungsgranularität G, die in Abschnitt 3.2.5 diskutiert wird.
Da die Planung zur Laufzeit stattndet, ist die Menge der Produzenten und ihrer Anforderungen
a-priori unbekannt. Es können jederzeit neue Reservierungsanfragen und Freigabeauorderungen
an den Planer gerichtet werden. Der Planungsalgorithmus ist folglich
46

3.2 Dynamische Planung
p 1 = 4
p 1 = 4
p 3 = 2
(A) RT 1 RT 2 RT 1 RT 2
p 2 = 4
(B) RT 1 RT 3 RT 2 RT 3 RT 1 RT 3 RT 2 RT 3
p 2 = 4
Abbildung 3.7: Ein optimaler Planer muss bereits reservierte Ressourcen
umplanen können. Ein dritter Kanal mit p 3 = 2 kann bei (A) nur reserviert
werden, wenn der bestehende Plan zu (B) geändert wird.
G G G G G . . .
(M) RT 1 NRT RT 2 NRT
(F) 0 1 1 1 0 0 1 1
z k
t
Abbildung 3.8: Medienzuteilung (M) und zugehöriges Feld F ree zur Speicherung
freier Slots (F).
auf das Hinzufügen und Freigeben von Kanälen ausgelegt. Das Finden eines optimalen
Plans 11 wird hingegen in dieser Arbeit nicht behandelt. Mangels Kenntnis der zukünftig
gestellten Anforderungen, wäre hierzu die Umplanung von schon zugesicherten Ressourcen
nötig. Abb. 3.7 veranschaulicht das am Beispiel. Die Schwierigkeit bei der Umplanung ist
die verlässliche systemweite Etablierung des neuen Plans, ohne die existierenden Echtzeitgarantien
zu beeinträchtigen. Sie ist im Allgemeinen nicht ohne aufwendigere Protokolle
und zusätzlichen Ressourcenaufwand in den Knoten und auf dem Medium machbar. Das
hier angesprochen Thema könnte in einer weiterführenden Arbeit behandelt werden.
3.2.4.1 Repräsentation des Plans
Für eine vereinfachte Darstellung des TDMA-Zyklus' wird die Diskretisierung der Zeit
nach der Uhren- bzw. Planungsgranularität ausgenutzt. Hierdurch lässt sich die Länge
von reservierten und freien Slots durch eine endlichen Anzahl von nicht unterteilbaren
Zeitabschnitten beschreiben. Die nicht unterteilbaren Zeitabschnitte werden im Folgenden
atomare Slots genannt. Bei einer Zykluslänge Z setzt sich der TDMA-Zyklus aus
AtomSlotsP erCycle = Z G
atomaren Slots zusammen. Auch die Phasenverschiebung und
die Periode lassen sich in atomaren Slots bemessen. Die Repräsentation des errechneten
Plans enthält daher für jeden Produzent i der N Produzenten mit erfolgreich reserviertem
Kommunikationskanal ein Tupel RT (i), dessen Einträge als Anzahl von atomaren Slots zu
interpretieren sind:
11
Ein optimaler Planer ndet immer einen korrekten Plan, wenn ein solcher existiert.
47

3 Echtzeitkommunikationskanäle
RT (i).p = p i
G
RT (i).l = l i
G
RT (i).v = v i
G
(Periode)
(Slotlänge)
(Phasenverschiebung)
Da p i , l i und v i immer Vielfache von G sind, ist hier keine Rundung nötig. Die Menge von
allen Tupeln {RT (i), 0 ≤ i ≤ N −1} beschreibt den TDMA-Zyklus bereits vollständig. Auf
Basis dieser Informationen ist es jedoch nur mit groÿem Aufwand möglich, einen freien
Slot zu nden bzw. zu überprüfen, ob ein Slot frei ist. Für eine eziente Realisierung
eines Reservierungsalgorithmus' muss aber mindestens eine dieser Aufgaben schnell ausführbar
sein. Daher wird parallel zu den Reservierungsinformationen eine Datenstruktur
zur Speicherung der freien Slots verwaltet. Für jeden dieser atomaren Slots wird in einem
Feld (engl.: array) F ree gespeichert, ob er Teil eines freien Slots ist. Die Reihenfolge der
Feldelemente entspricht der zeitlichen Reihenfolge der atomare Slots innerhalb des TDMA-
Zyklus'. Abb. 3.8 veranschaulicht dies. Das Feld erlaubt einen Zugri auf die Elemente in
der Laufzeit O(1). Somit kann sehr ezient überprüft werden, ob ein Slot frei ist.
Wenn das Versenden von NRT-Nachrichten wie bei Ethernet durch Polling geregelt wird,
muss der Poll-Master immer die momentan freien Slots kennen. Zur Übermittlung dieser
Information kann das eben besprochene Feld übertragen werden. Um Speicher und ggf.
Netzwerkressourcen zu sparen, können die Belegungsinformationen von 8 aufeinanderfolgenden
atomaren Slots in einem Byte des Feldes codiert werden.
Alle Algorithmen in den folgenden Teilabschnitten haben Zugri auf die soeben denierten
Zustandsdaten, die den aktuellen Plan repräsentieren.
3.2.4.2 Reservierung
Zur Etablierung eines Kommunikationskanals schickt ein Produzent eine Reservierungsanfrage
an den Planer. Dieser überprüft zunächst die Einplanbarkeit. Wenn dieser Test positiv
ausgeht, wird die entsprechende Medienzeit für den Produzenten reserviert.
Ein- und Ausgabedaten Da der im Folgenden beschriebene Reservierungsalgorithmus
mit atomaren Slots rechnet, müssen die Anforderungen der Reservierungsanfrage zunächst
umgerechnet werden. Die Anfrage (engl.: request) von Produzent i wird dann durch die
folgenden Variablen beschrieben:
Req.p = p i
G
Req.l = l i
G
Req.vBegin = vmin
i
G
Req.vW idth = vwidth i
G
(Periode)
(Slotlänge)
(minimale Phasenverschiebung)
(Breite des v-Suchfensters)
48

3.2 Dynamische Planung
Eingabe : Reservierungsanfrage Req
Ausgabe : Suchfenster (vsBegin, vsEnd)
1 if v-Fenster in Req angegeben then
2 vsBegin ← Req.vBegin
3 vsEnd ← vsBegin + min {Req.vW idth, Req.p, AtomSlotsP erCycle}
4 else
5 vsBegin ← 0
6 vsEnd ← min {Req.p, AtomSlotsP erCycle}
7 end
Algorithmus 3.1: Eingrenzung des Suchfensters der Phasenverschiebung
Davon sind die letzten beiden Parameter optional. Ausgabedaten sind ein boolescher Wert,
ob eine Reservierung möglich ist, und gegebenenfalls die Phasenverschiebung vResult.
Diese lässt sich im Anschluss über v i = vResult·G in die sonst übliche Form überführen.
Eingrenzung des Suchbereichs möglicher Phasenverschiebungen Bei der Suche nach
vResult lässt sich die strenge Periodizität der reservierten und des zu reservierenden Slots
ausnutzen. Wird ein Kommunikationskanal i nämlich um eine oder mehrere seiner Perioden
p i verschoben, ändert sich nichts am TDMA-Zyklus. Folglich reicht für die Suche der
Phasenverschiebung v i immer ein Bereich der Breite p i aus. Wird innerhalb dieser Breite
kein hinreichender freier Slot gefunden, kann die Periodizität nicht erfüllt werden. Eine Reservierung
ist folglich nicht möglich. Muss der momentane TDMA-Zyklus zur Einplanung
verlängert werden, so wird der bisherige Zyklus durch die Periodizität vervielfacht. Daher
ist die Suche nach passenden freien Slots nur bis zum bisherigen Zyklus-Ende sinnvoll.
Anschlieÿend wiederholen sich nur die bereits geprüften freien Slots in einer zeitversetzten
Kopie.
Algorithmus 3.1 wendet diese Erkenntnisse an, um den Suchbereich einzugrenzen. Wenn
die Phasenverschiebung nicht durch die Anforderungen eingegrenzt ist, wird ab Beginn des
TDMA-Zyklus' gesucht. Falls entsprechende Angaben gemacht wurden, beginnt die Suche
gemäÿ der Anforderungen. Für das Ende wird jedoch nicht pauschal die angegebene Fensterbreite
addiert. Auch hier lässt sich die Periodizität wie oben beschrieben ausnutzen. So
wird ein Fenster, das die Periode oder Zykluslänge überschreitet, entsprechend gekürzt.
Intuitiver Einplanbarkeitstest Zum Testen der Einplanbarkeit muss eine Phasenverschiebung
gefunden werden, bei der es nicht zu Konikten, also Überschneidungen, mit
Slots anderer Produzenten kommt. Da keine Kenntnisse über zukünftige Reservierungsanfragen
vorliegen, die sich zur Optimierung des Plans ausnutzen lieÿen, ist der Algorithmus
auf die Minimierung des momentanen Rechenaufwands ausgelegt. Er verfolgt dazu eine
First-Fit-Strategie, d. h. der Algorithmus bricht ab, sobald er die erste passende Lösung
gefunden hat, ohne nach weiteren möglichen Lösungen zu suchen. In Algorithmus 3.2 wird
die Anwendung der Strategie gezeigt. Die Variable v enthält die jeweils gerade betrachtete
49

3 Echtzeitkommunikationskanäle
Eingabe : Reservierungsanfrage Req, Suchfenster (vsBegin, vsEnd)
Rückgabe : Phasenverschiebung vResult, wenn planbar; -1 sonst
1 v ← vsBegin
2 while v < vsEnd do
3 if Req planbar mit Phasenverschiebung v then // s. Algorithmus 3.3
4 return v
5 end
6 v ← v + 1
7 end
8 return -1
Algorithmus 3.2: Intuitiver Einplanbarkeitstest: Suche nach koniktfreier Phasenverschiebung
gemäÿ First-Fit-Strategie
Eingabe : Reservierungsanfrage Req, Phasenverschiebung v
Rückgabe : Konikt mit anderen Slots?
1 NewAtomSlotsP erCycle ← kgV(AtomSlotsP erCycle, Req.p)
2 vr ← v
3 repeat
4 vl ← vr
5 repeat
6 if F ree(vl mod AtomSlotsP erCycle) ≠ 1 then
7 return Konikt
8 end
9 vl ← vl + 1
10 until vl < vr + Req.l
11 vr ← vr + Req.p
12 until vr < v + NewAtomSlotsP erCycle
13 return kein Konikt
Algorithmus 3.3: Intuitiver Einplanbarkeitstest: Überprüfung einer Phasenverschiebung
auf Koniktfreiheit mit bereits reservierten Kommunikationskanälen
Phasenverschiebung. Sie wird mit dem Beginn des Suchfensters initialisiert. Es wird überprüft,
ob eine koniktfreie Einplanung mit v möglich ist. Wenn ja, wurde eine passende
Lösung gefunden die direkt zurückgegeben wird. Anderenfalls wird v inkrementiert und
wiederum auf Einplanbarkeit überprüft. Wenn v das Ende des Suchfensters erreicht, wurde
keine Lösung gefunden, d. h. der angefragte Kommunikationskanal Req ist nicht reservierbar.
Algorithmus 3.3 konkretisiert den Test einer gegeben Phasenverschiebung auf Konikte
mit den bereits reservierten Kommunikationskanälen, der in Algorithmus 3.2 verwendet
wurde. Bei dem Test werden im Feld F ree alle atomaren Slots überprüft, die der angefragte
Kommunikationskanal bei der Phasenverschiebung v belegen würde. Ist einer der
Slots nicht frei (Zeile 6), kann sofort abgebrochen werden (Zeile 7), denn eine Einplanung
ist mit diesem v nicht möglich. Der restliche Code ist im Wesentlichen dafür zuständig,
die Positionen der zu überprüfenden atomaren Slots zu berechnen. Wenn die momentane
50

3.2 Dynamische Planung
Angefragte Slotlänge Req.l = 20
v = 3 vr
vl
v = 4 vr
20∑
i=1
i = 210 Überprüfungen
vl
. . .
v = 22
vr
frei
belegt
Abbildung 3.9: Optimierungspotential beim intuitiven Einplanbarkeitstest
am Beispiel: Da v bei der First-Fit-Suche inkrementiert wird, werden viele
Abfragen von F ree unnötigerweise mehrfach getätigt.
Zykluslänge nicht ein Vielfaches der angefragten Periode ist, muss der TDMA-Zyklus verlängert
werden. Die eventuell erhöhte Zykluslänge NewAtomSlotsP erCycle wird in Zeile 1
berechnet. In Zeile 2 wird vr initialisiert, das auf den Anfang des momentan untersuchten
Slots zeigt. In der Schleife Zeile 3-12 wird mit Hilfe dieser Variable über alle Slots iteriert,
aus denen sich der Kommunikationskanal in dem neuen TDMA-Zyklus zusammensetzen
würde. Die Variable vl, die innerhalb der Schleife jeweils mit vr initialisiert wird (Zeile 4),
iteriert in der eingeschachtelten Schleife (Zeile 5-10) über die atomaren Slots, aus denen
sich der jeweilige Slot zusammensetzt. Innerhalb dieser Schleife erfolgt die bereits erwähnte
Überprüfung der atomaren Slots, und ggf. der Abbruch des Algorithmus'. Falls die
Schleifen komplett abgearbeitet werden, war keiner der atomaren Slots belegt. Somit gibt
es in diesem Fall keinen Konikt mit anderen Kommunikationskanälen (Zeile 13). In Zeile 6
wird bei der Adressierung innerhalb des Feldes F ree eine Modulo-Operation verwendet.
Diese ist nötig, weil sowohl NewAtomSlotsP erCycle als auch v gröÿer sein kann, als
die aktuelle Zykluslänge AtomSlotsP erCycle, durch die F ree bemessen wird. Auÿerdem
können sich Slots auch über Zyklusgrenzen hinweg erstrecken. Da sich der TDMA-Zyklus
wiederholt, kann durch die Modulo-Operation auch der Belegungszustand von atomaren
Slots hinter dem Zyklusende überprüft werden.
Optimierungen Der intuitive Algorithmus zum Einplanbarkeitstest lässt sich zur Verringerung
der Laufzeit optimieren, jedoch auf Kosten der Lesbarkeit. Daher werden die
angewendeten Optimierungen hier separat beschrieben.
Abb. 3.9 veranschaulicht am Beispiel, dass die Laufzeit der Kombination der Algorithmen
3.2 und 3.3 bei zu kurzen freien Slots unnötig lang ist. Es soll ein Slot der Länge 20
reserviert werden. Bei einem freien Slot der Länge 19 fallen bei der bisherigen Lösung
210 Überprüfungen von atomaren Slots an, da v im First-Fit-Algorithmus inkrementiert
wird, ohne die Erkenntnisse eines erkannten Slot-Konikts auszunutzen. Nachdem in der
ersten Iteration über den freien Slot mit v = 3 kein hinreichend langer Slot gefunden
wurde, ist bereits klar, dass bei v = 4 bis v = 22 auch kein passender Slot gefunden wird;
51

3 Echtzeitkommunikationskanäle
schlieÿlich verändert sich die Belegung der atomaren Slots nicht zwischenzeitlich. Auÿerdem
verkürzt sich der untersuchte freie Slot durch das Vorrücken des Slotbeginns sogar.
Der Aufwand lässt sich deutlich verringern, wenn der Konikttest den nächsten Phasenverschiebungskandidaten
angeben kann. Im Falle eines Konikts erhöht dieser v um vl − vr,
bevor v durch den First-Fit-Algorithmus inkrementiert wird. Dann wird nach v = 3 direkt
auf v = 23 gesprungen, so dass statt 210 nun nur noch 20 Überprüfungen von atomaren
Slots stattnden. Durch diese Verbesserung wird kein atomarer Slot mehrfach überprüft,
so dass sich bei dem Einplanbarkeitstest eine Worst-Case Laufzeitkomplexität von O(M)
ergibt, wobei M der neuen Zykluslänge entspricht.
Die neue Zykluslänge NewAtomSlotsP erCycle muss auÿerdem nicht für jedes v neu
berechnet werden, sondern sollte auÿerhalb aller Schleifen bestimmt werden. Sie ist nämlich
lediglich von Perioden abhängig und damit invariant bezüglich der Schleifen.
Auch könnte die auf einigen Architekturen sehr teure Modulo-Operation in Algorithmus
3.3 (Zeile 6) eingespart werden, indem vor den umgebenden Schleifen überprüft wird,
ob vr bzw. vl gröÿer oder gleich AtomSlotsP erCycle ist. Ggf. muss mit Indizes weitergearbeitet
werden, die auf den erlaubten Wertebereich heruntergebrochenen wurden. D. h. auch,
dass der veränderte Algorithmus die Schleifen wenn nötig in mehrere Teile zerlegen muss.
Freihalten von NRT-Reserven Netzwerke wie Ethernet sind zum Versenden von NRT-
Nachrichten auf freie Slots angewiesen (siehe Abschnitt 3.1.4.1). Daher muss dort bei der
Überprüfung der Einplanbarkeit auch beachtet werden, dass noch hinreichend lange Slots
frei bleiben. Dies kann in einem zusätzlichen Test überprüft werden, der ausgeführt wird,
wenn eine passende Phasenverschiebung gefunden wurde. Falls dieser Test feststellt, dass
bei dem aktuellen Planvorschlag keine hinreichenden NRT-Reserven mehr frei sind, wird
die First-Fit-Suche fortgeführt. Anderenfalls kann der Plan so akzeptiert werden.
Reservierung des Kommunikationskanals Wenn der Einplanbarkeitstest positiv war,
kann der Kommunikationskanal reserviert werden. Dazu wird ein neues Tupel RT (i) mit
den entsprechenden Parametern angelegt und die Anzahl der reservierten Kommunikationskanäle
N inkrementiert. Auÿerdem muss ggf. der TDMA-Zyklus verlängert werden. Dazu
wird die Zykluslänge AtomSlotsP erCycle auf NewAtomSlotsP erCycle gesetzt und das
Feld F ree verlängert. Der neu angelegte Bereich von F ree wird mit Kopien des bisherigen
Inhalts gefüllt. Auÿerdem müssen die vom Kommunikationskanal belegten atomaren
Slots in F ree als belegt markiert werden. Dazu kann eine Abwandlung von Algorithmus 3.3
eingesetzt werden, in der die Zeilen 6-8 durch F ree(vl mod NewAtomSlotsP erCycle) ← 0
ersetzt werden. Auÿerdem entfällt der Rückgabewert.
52

3.2 Dynamische Planung
3.2.4.3 Freigabe
Die Freigabe eines Kommunikationskanals ist seitens des Planers nicht an Bedingungen
geknüpft, so dass die Schritte aus der eben angegeben Reservierung des
Kommunikationskanals lediglich rückgängig gemacht werden müssen. Das Tupel RT (i)
des Kommunikationskanals muss entfernt und die Anzahl N dekrementiert werden. Die
belegten atomaren Slots aus F ree müssen als frei markiert und die TDMA-Zykluslänge
AtomSlotsP erCycle muss gegebenenfalls verringert werden.
3.2.4.4 Änderung von Anforderungen
Die Änderung von Anforderungen eines Kommunikationskanals kann als Verkettung
von Freigabe und anschlieÿender Neureservierung implementiert werden. Falls eine Reservierung
mit den neuen Anforderungen nicht möglich ist, kann der alte Kommunikationskanal
durch eine Reservierung mit den alten Parametern wiederhergestellt werden, wenn
die Ressourcen zwischenzeitlich nicht für einen anderen Kommunikationskanal reserviert
wurden.
3.2.5 Einussfaktoren
Neben den Anforderungen der Reservierungsanfragen und den Netzwerkeigenschaften
haben auch andere, weniger oensichtliche Parameter Einuss auf die Planbarkeit und
Medienausnutzung.
Planungsgranularität Der im letzten Abschnitt angegebene Algorithmus zur Einplanung
von Kommunikationskanälen basiert auf der Diskretisierung der Zeit in atomare Slots der
Dauer G. Bei der Wahl von G besteht ein Zielkonikt zwischen dem Aufwand der Planung
und dem resultierenden nutzbaren Datendurchsatz des Netzwerkes. Der Speicherbedarf
des vom Planungsalgorithmus verwendeten Feldes F ree ist proportional zu Z G
. Auch die
Laufzeitkomplexität der Algorithmen ist als O ( Z
G) von der Dauer der atomaren Slots abhängig.
Die Wahl eines groÿen G ist somit vorteilhaft für die Ressourcen des Planers, weil
dadurch Speicher und Rechenzeit gespart werden. Andererseits führt die Wahl eines groÿen
G auch zu gröÿeren Slotlängen. Diese hängen gemäÿ der Modellierung aus Abschnitt 3.2.2
nicht nur von der maximal zu übertragenden Datenmenge und Netzwerkparametern ab.
Auch hard- und softwarebedingte Verzögerungen beim Senden, die Uhrengranularität und
nicht zuletzt die Planungsgranularität G spielen eine groÿe Rolle. Da die Längen der Slots
für die Planung des TDMA-Zyklus' immer Vielfachen von G entsprechen müssen, ist es
meist nötig, die Slots zu verlängern. Die Folge ist, dass für einen Kommunikationskanal bei
gleichen Anforderungen im Mittel mehr Medienzeit reserviert wird und dadurch weniger
für weitere Reservierungen zur Verfügung steht. Um ein Abwägen der Eekte im Zielkon-
ikt zwischen Netzwerkressourcen und den Ressourcen des Planers zu erlauben, kann G als
53

3 Echtzeitkommunikationskanäle
Systemparameter gewählt werden. Da es sich um die kleinste planbare Slotdauer handelt,
wurde für G der Begri Planungsgranularität gewählt. Die niedrigste mögliche Planungsgranularität
ist die Uhrengranularität g. Höhere G müssen als Vielfaches der Uhrengranularität
gewählt werden, da sonst die errechneten Zeitpunkte nicht genau messbar sind.
Wichtig ist auch, dass die Periode nur als Vielfaches von G gewählt werden darf, weil sonst
die Planung des Kommunikationskanals nicht möglich ist.
Zykluslänge Der zweite Einussfaktor bezüglich des Ressourcenbedarfs im Planer-
Knoten ist die Zykluslänge Z. Diese kann als kleinstes gemeinsames Vielfaches der Perioden
nicht gut vorhergesagt werden. Der Ressourcenbedarf im Planer kann jedoch
beschränkt werden, indem eine maximale Zykluslänge festgelegt wird, deren Überschreitung
zur Ablehnung einer Reservierungsanfrage führt.
Uhrensynchronisation Die Güte der Uhrensynchronisation bestimmt die Genauigkeit α
und die Uhrengranularität g für die globale Zeit des verteilten Systems. Je besser die
Uhrensynchronisation, um so mehr Zeitpunkte können unterschieden werden. Dies erhöht
den maximalen Datendurchsatz, der auf einem Medium für Echtzeitnachrichten genutzt
werden kann, weil zum Versenden nur unterscheidbare Zeitpunkte infrage kommen. Da
g auch die minimale Planungsgranularität ist, bestimmt es auch die minimale Slotlänge
und Periode. Aber auch für Slotlängen über dem Minimum spielen g bzw. α ein Rolle,
denn höhere Werte von α und g führen im Mittel zu längeren Slots und damit zu einer
geringeren Ausnutzung des Mediums. Eine bestmögliche Uhrensynchronisation ist also für
eine eziente Nutzung der Netzwerkressourcen erstrebenswert. Dagegen ist jedoch der
Ressourcenaufwand für die Uhrensynchronisation aufzuwiegen.
Hardware und Software Die Länge der Slots hängt auch von den Worst-Case-
Verzögerungen in der Hard- und Software ab. Die Ermittlung der Gröÿen ist erst bei
genauer Kenntnis der verwendeten Komponenten möglich. Eine zu niedrige Bemessung ist
kritisch, da sie die Echtzeitfähigkeit gefährdet. Eine zu hohe Bemessung führt durch eine
unnötige Verlängerung der Slots zu einer geringeren Medienausnutzung. Bei Multitasking-
Systemen muss dem Scheduling der Tasks groÿe Aufmerksamkeit gewidmet werden, da
hierdurch unter Umständen groÿe und schwer vorhersagbare Verzögerungen entstehen
können.
54

3.3 Reservierungsprotokoll
3.3 Reservierungsprotokoll
Da die im Abschnitt 3.2 besprochene dynamische Planung im Allgemeinen nicht auf dem
Knoten stattndet, auf dem sich auch der Produzent der Echtzeitnachrichten bendet, ist
ein Kommunikationsprotokoll nötig, dass den Informationsaustausch zwischen den Komponenten
regelt. Dabei muss beachtet werden, dass es bei der Kommunikation zu Paketverlusten
und anderen Eekten 12 kommen kann, die zu inkonsistenten Sichten zwischen dem
Planer-Master und seinen Klienten führen. Eine mögliche Konsequenz ist die mehrfache
Vergabe der selben Medienzeit, die sich als Verletzung der Echtzeitgarantien äuÿert. Dies
muss das Protokoll verhindern.
Das vorgeschlagene Reservierungsprotokoll ist auf Publish/Subscribe und FAMOUSO
zugeschnitten. FAMOUSO unterstützt die Nutzung mehrerer Netzwerkanbindungen auf
einem Knoten, so dass mehrere Subnetze auch verschiedenen Typs zu einem zusammenhängenden
FAMOUSO-Netzwerk verbunden werden können. In FAMOUSO kann es somit
nötig sein, dass ein Publisher-Ereigniskanal, über den eine Applikation Echtzeit-Events
veröentlicht, in mehrere Netzwerke publizieren muss. In diesem Fall sind einem Echtzeit-
Publisher-Ereigniskanal mehrere Echtzeitkommunikationskanäle zugeordnet. Der logische
Publisher-Ereigniskanal deniert dabei die QoS-Anforderungen, die für jedes angebundene
Netzwerk durch die Reservierung eines konkreten Kommunikationskanals durchgesetzt werden.
Der Publisher-Ereigniskanal bietet die Schnittstelle für die Anwendung und nimmt die
Events entgegen, die über die Kommunikationskanäle in den jeweiligen Netzen versendet
werden. In den meisten Fällen dient ein Knoten mit mehreren Netzwerkanbindungen als
Gateway, das veröentlichte Events eines Subnetzes selektiv in ein anderes Subnetz weiterleitet,
wenn in diesem Subscriber für dieses Event vorhanden sind. Unter Ausnutzung
dieser vorhandenen Infrastruktur soll es möglich sein, einen Planer-Master gemeinsam für
mehrere Subnetze zu verwenden. In dieser Arbeit werden Echtzeitgarantien nur innerhalb
eines Subnetzes bereitgestellt. Die Verwendung eines Planers für mehrere Subnetze legt
jedoch den Grundstein, um Echtzeitanforderungen auch über mehrere Subnetze hinweg
durchsetzen zu können. Das Protokoll soll es jedoch auch erlauben, für jedes Subnetz
einen eigenen Planer zu verwenden.
Eine wichtige Annahme für das Reservierungsprotokoll ist, dass Wertfehler bei der
Datenübertragung in einer unter dem Protokoll arbeitenden Schicht zu Auslassungen maskiert
werden. Die Annahme ist bei Ethernet und CAN erfüllt. Beide Spezikationen sehen
CRC-Codes zur Erkennung von Übertragungsfehlern vor.
Das Protokoll basiert auf der zyklischen Übertragung von Zustandsinformationen der
Knoten. In Abschnitt 3.3.1 und 3.3.2 werden die Grundlagen des Protokolls erläutert.
Die Abschnitte 3.3.3 und 3.3.4 thematisieren kritische Inkonsistenzen und ihre Vermeidung.
Es folgt eine Betrachtung über den Einsatz von Leasing-Mechanismen für
12
Verzögerungen durch die Verwendung von NRT-Kanälen müssen ebenso beachtet werden, wie die in
einigen Systemen mögliche Umordnung von Nachrichten. Siehe Abschnitt 3.3.4.
55

3 Echtzeitkommunikationskanäle
Echtzeitkanäle (Abschnitt 3.3.5) sowie eine Zusammenfassung der Eigenschaften des Protokolls
(Abschnitt 3.3.6).
3.3.1 Announcements und Subscriptions
Bevor ein Publisher Echtzeitnachrichten veröentlichen kann, muss er der Middleware
seine Existenz und seine QoS-Anforderungen bekannt machen. Dies tut er, indem er einen
Publisher-Ereigniskanal (PEC) erzeugt und für diesen die Middleware-Funktion announce
aufruft. Wenn der Publisher die Dienste der Middleware nicht mehr benötigt, meldet er
den PEC über die Funktion unannounce wieder ab, wodurch dessen Zustand von bekannt
zurück auf unbekannt wechselt.
Die Middleware verwaltet in jedem Knoten eine Liste der bekannten lokalen PECs. Diese
Liste wird samt der zugehörigen QoS-Anforderungen und der Reservierungszustände der
Kommunikationskanäle zyklisch in einem Announcements-Event an den Planer-Master
übertragen. Dieser verwaltet ebenfalls eine Liste der ihm bekannten PECs, die er mit der
empfangenen Liste abgleicht. Unterschiede in den Listen lösen dabei, wie in Abschnitt 3.3.2
beschrieben, Aktionen des Planers aus.
Das Announcements-Event enthält die Knoten-ID des Absenders, einen Block der
Netzwerk-IDs der angebundenen Netze und einen Block, der die PECs beschreibt.
Knoten-ID Die Knoten-ID ist eine im Gesamtsystem eindeutige Kennung des Knotens.
Gemeinsam mit der Netzwerk-ID und der lokalen PEC-ID identiziert sie einen
Kommunikationskanal eindeutig.
Netzwerk-IDs In diesem Block werden die IDs aller Netzwerke aufgezählt, über die der
Knoten mittels FAMOUSO kommuniziert. Eine Netzwerk-ID ist eine eindeutige Kennung
eines Netzes. Sie dient dem Planer-Master, der ggf. für mehrere Netzwerke
zuständig ist, zur Zuordnung zwischen Produzenten und Netz bzw. dessen TDMA-
Zyklus. Der Planer muss über die ID auÿerdem den Netzwerk-Typ und die Netzwerk-
Eigenschaften (z. B. die Übertragungsrate) nachschlagen können. Alternativ ist auch
eine Codierung dieser Informationen in der Netzwerk-ID denkbar.
PEC-Informationen Dieser Block enthält für jeden PEC das Subject, die QoS-
Anforderungen, eine lokal eindeutige PEC-ID, und die momentanen Reservierungszustände.
Ein PEC hat für jeden potentiellen Kommunikationskanal, also für jedes
angebundene Netzwerk, einen eigenen unabhängigen Zustand. Die Reservierungszustände
werden im folgenden Abschnitt vorgestellt. Die für Echtzeit-Publisher
unterstützten QoS-Anforderungen wurden bereits im Abschnitt 3.2.1 behandelt.
Auch die Subscriber müssen sich bei der Middleware anmelden, bevor Events an sie
ausgeliefert werden. Dazu abonniert ein Subscriber durch den Aufruf der Middleware-
Funktion subscribe ein konkretes Subject. Die zugehörige Abmeldung erfolgt über
56

3.3 Reservierungsprotokoll
Deliv
nicht
Res
Start ungenutzt genutzt
reserviert
NoDeliv
Abbildung 3.10: Reservierungszustände eines Kommunikationskanals
unsubscribe. Auch hier werden lokal und im Planer Listen der bekannten Subscriber
verwaltet, die periodisch über ein Subscriptions-Event abgeglichen werden. Dieses enthält
im Wesentlichen die gleichen Informationen wie das Announcements-Event. Für das
hier vorgestellte Protokoll ist jedoch als Subscriber-Informationen nur das Subject relevant.
Auÿerdem gibt es auf der Subscriber-Seite keinen Reservierungzustand oder ähnliches.
3.3.2 Reservierungszustände
Jeder der Middleware bekannte PEC hat für jedes an den Knoten angebundene Netz, also
für jeden potentiellen Kommunikationskanal, einen eigenen Reservierungszustand. Wenn
die Middleware in einem Knoten an N Netze angeschlossen ist, hat jeder PEC folglich N
unabhängige Reservierungszustände, die angeben, ob eine Auslieferung über das jeweilige
Netzwerk möglich und nötig ist. Abb. 3.10 veranschaulicht, welche Reservierungszustände
ein Kommunikationskanal haben kann und wie die Zustandsübergänge erfolgen.
• Kommunikationskanal nicht reserviert: Nachdem ein PEC über announce neu
bekannt gemacht wurde, benden sich alle zugehörigen Kommunikationskanäle im
Zustand nicht reserviert. Der oder die Planer-Master erfahren über das Announcements-Event
von dem PEC und seinen QoS-Anforderungen. Jeder Planer überprüft
anschlieÿend die Einplanbarkeit für alle benötigten Kommunikationskanäle, die auf
den von ihm geplanten Netzwerken etabliert werden sollen.
Geht ein Einplanbarkeitstest positiv aus, reserviert der Planer den Kommunikationskanal
und sendet dem Publisher-Knoten ein Res-Event. Beide setzen den Zustand
des nun etablierten Kommunikationskanals auf ungenutzt. Ist keine Reservierung der
benötigten Ressourcen möglich, vermerkt der Planer dies in seinem Log 13 . Der nicht
reservierbare Kommunikationskanal verbleibt in seinem Zustand. Bei der Freigabe
von Ressourcen (unannounce) wird der Einplanbarkeitstest für alle Kommunikationskanäle
mit diesem Status wiederholt.
Im Zustand nicht reserviert ist keine Auslieferung von publizierten Events möglich.
Um für die Subscriber eine einheitliche Sicht zu schaen, wird ein auf einem PEC
13
Das Log des Planers liefert dem Entwickler an einer zentralen Stelle Informationen über alle reservierten
und nicht reservierbaren Kommunikationskanäle. Es hilft somit bei der Untersuchung von Problemen
und der Einstellung von frei wählbaren Parametern.
57

3 Echtzeitkommunikationskanäle
veröentlichtes Event nur dann an Subscriber ausgeliefert, wenn alle zum PEC gehörigen
Kommunikationskanäle reserviert werden konnten, sich also keiner mehr im Zustand
nicht reserviert bendet. Anderenfalls wird das Event weder an lokale Subscriber
ausgeliefert, noch über einen Kommunikationskanal in das Netzwerk publiziert.
Stattdessen wird die Publisher-Applikation über das Problem informiert.
In FAMOUSO wird dafür beim Veröentlichen eines Events der Ausnahmerückruf
aufgerufen.
• Kommunikationskanal ungenutzt: Dieser Zustand zeigt an, dass der Kommunikationskanal
gemäÿ der QoS-Anforderungen des PECs vorgemerkt ist, aber momentan
keine Auslieferung von Events über diesen Kommunikationskanal nötig ist. Erfährt
der Planer jedoch über ein Subscriptions-Event von einem passenden Subscriber
in dem entsprechenden Netz, wird dies dem PEC über ein Deliv-Event mitgeteilt.
Dieser ändert den Zustand des Kommunikationskanals zu genutzt und beginnt mit
der Auslieferung von Events über diesen Kommunikationskanal.
In einem Publish/Subscribe-System sind Publisher und Subscriber komplett unabhängig.
Es ist nicht a-priori bekannt, wo sich die Subscriber benden oder ob
überhaupt Subscriber vorhanden sind. Wenn in anderen Knoten des Netzwerks
kein Subscriber für das publizierte Subject existiert, dann ist es auch nicht nötig,
die Events über dieses Netzwerk zu versenden. Daher wird in diesem Fall darauf
verzichtet. Hierdurch kann z. B. Energie gespart werden. Auÿerdem lässt sich die
unbenutzte Medienzeit zur Übertragung von NRT-Events ausnutzen. Bei CAN funktioniert
dies durch Ausnutzung der prioritätsbasierten Arbitrierung automatisch.
Wenn NRT-Events wie bei Ethernet im Polling-Betrieb übertragen werden, muss
beim Poll-Master zwischen ungenutzten und genutzten Kommunikationskanälen unterschieden
werden. Freie Slots und die Slots eines ungenutzten Kommunikationskanals
stehen dem Poll-Master zur Verfügung. Es muss jedoch ausgeschlossen sein,
dass ein Kommunikationskanal gleichzeitig vom Poll-Master und zum Versenden von
Echtzeit-Events verwendet wird, da dies zur Verletzung der Echtzeitgarantien führen
würde. In Abschnitt 3.3.3 wird beschrieben, wie das verhindert wird.
Eine Reservierung der Kommunikationskanäle wird immer, unabhängig von der momentanen
Existenz von Subscribern, vorgenommen. Dies verbessert die Orts- und
Migrationstransparenz des Systems, denn ein planbares System bleibt nach der Migration
eines Publishers oder Subscribers auf einen anderen Knoten des Subnetzes
planbar, selbst wenn erst durch die Änderung Kommunikation über das Netz erforderlich
wird. Auch die Erweiterung eines Systems um neue Subscriber kann Echtzeitkommunikation
nötig machen, wo die Events vorher nur lokal ausgeliefert wurden. Da
jedoch immer ein Kommunikationskanal reserviert wird, können neue Subscriber in
einem funktionierenden System immer hinzugefügt werden, ohne Probleme mit der
Netzwerkplanung zu verursachen.
58

3.3 Reservierungsprotokoll
• Kommunikationskanal genutzt: Ein reservierter Kommunikationskanal wird
in diesen Zustand versetzt, wenn es Subscriber des zugehörigen Subjects im
entsprechenden Netz gibt. In diesem Zustand werden veröentlichte Events über
den Kommunikationskanal ausgeliefert, also unter Beachtung des im ersten Teil des
Kapitels denierten Medienzugrisprotokolls.
Wenn ein Subscriber den Status bekannt verlässt, überprüft der Planer, ob noch
andere Subscriber mit dem gleichen Subject in dem gleichen Netz bekannt sind.
Falls kein entsprechender Subscriber mehr vorhanden ist, wird dies allen PECs des
zugehörigen Subjects in diesem Netzwerk über ein NoDeliv-Event mitgeteilt. Die
PECs ändern den Zustand des jeweiligen Kommunikationskanals von genutzt zu
ungenutzt und beenden damit die Auslieferung von Events in diesem Netz.
Aus jedem Zustand ist es möglich, dass der PEC über die unannounce-Funktion
abgemeldet wird. Der Planer erfährt darüber durch das nächste Announcements-Event
und gibt ggf. reservierte Ressourcen frei.
Die Events Res, Deliv und NoDeliv enthalten das zur Identikation des
Kommunikationskanals notwendige Tupel aus Knoten-ID, Netzwerk-ID und lokaler PEC-
ID. In Res werden auÿerdem die für das Medienzugrisprotokoll nötigen Parameter
übertragen, die vom Planer berechnet wurden: der Beginn des ersten Übertragungsslots
ri
start sowie das Übertragungsstartfenster f i . Ist dem Planer bereits ein passender
Subscriber bekannt, wenn er einen neuen Kommunikationskanal reserviert, kann der Zustand
von nicht reserviert über ungenutzt direkt auf genutzt gesetzt werden. Um den
hierbei anfallenden Kommunikationsaufwand von zwei Events auf eines zu reduzieren,
wird ein Event ResDeliv eingeführt. Dieses beinhaltet die Informationen aus Res und
löst einen direkten Zustandswechsel nach genutzt aus.
3.3.3 Fehlertoleranz
Alle in diesem Protokoll versendeten Events enthalten ausschlieÿlich Zustandsinformationen.
Res, Deliv, ResDeliv und NoDeliv werden vom Planer versendet, um im PEC den
Reservierungszustand eines Kommunikationskanals zu setzen. Die Announcements- und
Subscriptions-Events transportieren die Bekanntheitszustände und QoS-Anforderungen
zum Planer. Announcements wird auÿerdem als Rückkanal für die Bestätigung der vom
Planer initiierten Zustandsänderungen genutzt. Auf diesem Weg erfährt der Planer von
einem verloren gegangenen Res, Deliv, ResDeliv oder NoDeliv, weil die erwartete
Zustandsänderung des Kommunikationskanals beim PEC ausbleibt. Der Planer kann den
Verlust des Events durch eine erneute Übertragung des aktuellsten Zustands-Events kompensieren.
Hierbei können Duplikate entstehen, wenn ein verloren geglaubtes Event tatsächlich
noch auf dem Weg zum Empfänger war. Duplikate stellen jedoch kein Problem
dar, da ein erneut eintreendes Event lediglich zum erneuten Setzen eines bereits aktiven
59

3 Echtzeitkommunikationskanäle
PollCycle
Warte auf
Poll-M.
Deliv
nicht
Res
Start ungenutzt genutzt
reserviert
PollCycle
Warte auf
PEC
NoDeliv
Abbildung 3.11: Reservierungszustände eines Kommunikationskanals: Erweiterung
auf Planerseite für Kongurationen mit Poll-Master
Status führt. Auslassungen bei den Announcements und Subscriptions müssen nicht
erkannt und explizit behandelt werden, da die Events ohnehin zyklisch versendet werden,
so dass die Zustandsübermittlung automatisch wiederholt wird.
Auch wenn die Zustände durch die Sendewiederholung früher oder später abgeglichen werden,
können die Inkonsistenzen zwischenzeitlich Probleme bereiten, wenn ein Poll-Master
beteiligt ist. Sie treten auf, wenn der Planer das Nutzungsrecht für Medienzeit entzieht
und es bereits neu vergibt, bevor der alte Besitzer von dem Entzug erfahren hat. Dann gibt
es zwei Knoten, die während eines Slots senden wollen, was zur Verletzung der Echtzeitgarantien
führt. Um das zu verhindern, muss das Zustandsmodell für den Planer erweitert
werden. Diese Erweiterung bleibt vor den PECs versteckt, die weiterhin mit dem einfacheren
Modell arbeiten. Abb. 3.11 zeigt das um zwei Zustände ergänzte Modell.
Der neue Zustand Warte auf Poll-Master fügt sich vor der Versendung des Deliv-Events
ein. Wenn ein Poll-Master für die NRT-Kommunikation auf dem Medium verantwortlich
ist, hat er die Sendeberechtigung für die gesamte Medienzeit, die nicht zur Übertragung von
Echtzeitnachrichten genutzt wird. Dazu gehören alle freien Slots sowie die Slots von Kommunikationskanälen
im Zustand ungenutzt. Soll nun ein Kommunikationskanal zur Auslieferung
von Echtzeit-Events genutzt werden, so muss dem Poll-Master die Sendeberechtigung
für die Slots des Kommunikationskanals entzogen werden. Folglich darf der PEC, für
den der Kommunikationskanal reserviert ist, erst dann zu senden beginnen, wenn der Poll-
Master bestätigt hat, dass er die zugehörige Medienzeit nicht weiter verwendet. Wenn ein
Subscriber für einen ungenutzten Kommunikationskanal bekannt wird und ein Poll-Master
in Verwendung ist, so wird diesem ein PollCycle-Event geschickt. Dieses enthält den letzten
TDMA-Zyklusbeginn z last , das Feld P ollable sowie eine Sequenznummer. Der Zyklusbeginn
dient der initialen Synchronisierung der TDMA-Zyklen von Planer und Poll-Master
60

3.3 Reservierungsprotokoll
mit dem ersten PollCycle-Event. Das Feld P ollable ähnelt dem Feld F ree, markiert
neben den freien Slots jedoch auch die Slots der ungenutzten Kommunikationskanäle.
Es enthält somit die Informationen, welche Slots für das Pollen von NRT-Nachrichten
genutzt werden dürfen, sowie die Länge des TDMA-Zyklus'. Empfängt der Poll-Master
ein PollCycle-Event, passt er sein Polling an und sendet ein PollCycleACK-Event
mit der erhaltenen Sequenznummer. Diese erlaubt dem Planer die Zuordnung von empfangenen
PollCycleACK- zu den gesendeten PollCycle-Events und die Ableitung einer
zeitlichen Ordnung 14 . Ein verschicktes PollCycle-Event wird erneut übertragen, wenn
nach einer gewissen Zeit, die für einen Paketverlust spricht, keine Bestätigung eingegangen
ist. Als Bestätigung gilt ein PollCycleACK mit der gleichen oder einer neueren
Sequenznummer als das zugehörige PollCycle-Event. Eine neuere Sequenznummer ist
auch hinreichend, da sie bestätigt, dass eine spätere PollCycle-Zustandsübertragung
erfolgreich war, die auch alle vorherigen Änderungen enthält, insofern sie noch aktuell
sind. Sobald eine Bestätigung erhalten wurde, kann das Deliv-Event an den PEC verschickt
werden, da diesem in den Slots des Kommunikationskanals nun exklusiver Zugri
auf das Medium garantiert werden kann. Falls kein Poll-Master verwendet wird, entfällt
der Zustand Warte auf Poll-Master, so dass beim bekannt-Werden eines Subscribers sofort
das Deliv-Event veröentlicht werden kann.
Wenn sich alle Subscriber eines Kommunikationskanals abmelden, sind die Rollen
vertauscht. Der Planer entzieht hier dem PEC die Sendeberechtigung für den
Kommunikationskanal und übergibt sie dem Poll-Master. Hierbei muss sichergestellt
sein, dass der PEC den Kommunikationskanal nicht weiter nutzt, bevor die Ressourcen
vom Poll-Master verwendet werden. Dafür wird der Zustand Warte auf PEC eingeführt.
Wenn die Auslieferung der Events über den Kommunikationskanal nicht mehr benötigt
wird, weil keine passenden Subscriber mehr vorhanden sind, so wird das dem PEC
zunächst über das NoDeliv-Event mitgeteilt. Im Anschluss wartet der Planer auf das
nächste Announcements-Event des entsprechenden Knotens. Enthält dieses für den betreenden
Kommunikationskanal noch den Reservierungszustand genutzt, so wird NoDeliv
erneut gesendet. Erst wenn durch den Zustand ungenutzt bestätigt ist, dass der PEC
den Kommunikationskanal nicht mehr verwendet, kann dieser dem Poll-Master über ein
PollCycle-Event zur Verfügung gestellt werden. Der Verlust dieses PollCycle-Events
ist unkritisch, da dieses dem Poll-Master lediglich zusätzliche Medienzeit zur Verfügung
stellt. Das Warten auf ein bestätigendes PollCycleACK-Event und eine eventuelle
erneute Übertragung des PollCycle-Events beim Ausbleiben des PollCycleACK
sind daher optional.
14
Die Sequenznummer wird bei jedem versendeten PollCycle-Event inkrementiert. Da alle PollCycle-
Events aus einer Quelle stammen, lässt sich von der Sequenznummer eine zeitliche Ordnung ableiten.
In der Praxis ist hierbei der Überlauf des Zählers zu beachten.
61

3 Echtzeitkommunikationskanäle
PEC A
announce unannounce announce
ResDeliv
Beginne
Auslieferung?!
t
Announcements Ann. Ann.
Planer
Warte auf
Ressourcen
t
Announcements
ResDeliv
PEC B
announce
Beginne
Auslieferung
t
Abbildung 3.12: Inkonsistenz durch nebenläuges unannounce und
announce. In PEC A muss erkannt werden, dass ResDeliv veraltet ist. Anderenfalls
kommt es zur Verletzung des Medienzugrisprotokolls, da zwei
PECs die selbe Medienzeit für sich beanspruchen.
3.3.4 Verzögerung und Umordnung
Auch durch Verzögerungen bei der Abarbeitung des Reservierungsprotokolls und der
dazu nötigen Kommunikation kann es zu einer Inkonsistenz kommen, durch die Echtzeitgarantien
gefährdet werden. In Abb. 3.12 wird ein solcher Fall gezeigt. Hier ruft ein
Publisher in recht kurzer Zeit announce, unannounce und erneut announce auf. Durch
Verzögerungen im Planer und bei der Kommunikation erreicht das ResDeliv-Event den
Knoten des PEC A erst nach dem zweiten announce. Hier muss verhindert werden, dass
der PEC zu senden beginnt, da das ResDeliv veraltet ist und die Medienzeit, wie im
Beispiel, bereits an einen anderen PEC vergeben sein kann. Anderenfalls kann es hier zur
Verletzung der Echtzeitgarantien kommen. Eine einfache Lösung für das Problem ist es,
die lokale PEC-ID bei einem unannounce verfallen zu lassen und sie beim announce durch
eine neue zu ersetzen. Da ein veraltetes ResDeliv-Event noch die alte PEC-ID enthält,
wird es nach dem zweiten announce mangels Interessent verworfen.
Eine andere Problematik betrit Systeme, in denen die Auslieferungsreihenfolge der Events
von der Reihenfolge der Veröentlichung abweichen kann, also zwischen zwei Knoten
keine FIFO-Ordnung (First-In-First-Out) garantiert wird. So beispielsweise, wenn mehrere
Routen bei der Paketweiterleitung im Netz verwendet werden oder die Events nicht gemäÿ
FIFO auf die Auslieferung warten. Bei der hierbei möglichen Umordnung von Events kann
es beim Reservierungsprotokoll zum temporären Einnehmen von bereits veralteten Zuständen
kommen. Läuft beispielsweise der Planer für das Echtzeit-CAN-Netz eines mobilen
Roboters auf einem Knoten eines Wireless-Mesh-Networks, das über ein Gateway mit
dem CAN-Netz verbunden ist, so kann es durch eine Änderung im Routing des Wireless-
Mesh-Networks zu einer Umordnung von Announcements-Events kommen, so dass ein
62

3.3 Reservierungsprotokoll
neueres Event den Planer früher erreicht als ein älteres. Dies kann z. B. statt zu einer
eigentlich angedachten Reservierung, zu zweimaliger Reservierung mit zwischenzeitlicher
Freigabe führen. Verhindern lässt sich dies, indem jeder Sender einen eigenen Sequenzzähler
verwaltet. Beim Versenden eines Events wird der aktuelle Wert des Sequenzzählers mitgegeben
und inkrementiert. Beim Empfänger wird die neueste erhaltene Sequenznummer
eines Senders gespeichert. So lässt sich überprüfen, ob ein Event einen bereits veralteten
Zustand enthält. Im Normalfall der im Kontext von Echtzeit-FAMOUSO betrachteten
Anwendungen ist jedoch die FIFO-Reihenfolge zwischen zwei Kommunikationspartnern
garantiert.
3.3.5 Leasing
Die zyklische Veröentlichung der Announcements und Subscriptions legt die Verwendung
des Leasing-Prinzips nah. Unter gewissen Annahmen erlaubt dieses die Erkennung
eines Absturzes oder einer nicht kommunizierten Abschaltung eines Knotens. In der Folge
können nicht mehr benötigte Ressourcen freigegeben werden. Ein aktiver Knoten sendet
dem Planer regelmäÿig ein Lebenszeichen. Ist der Knoten nicht mehr aktiv, so bleibt das
Lebenszeichen aus. Um jedoch umgekehrt vom Ausbleiben auf einen inaktiven Knoten zu
schlieÿen, sind Annahmen nötig. Problematisch ist nämlich, dass das Lebenszeichen wie
jede Nachricht verloren gehen kann. Auÿerdem kann die Auslieferung der Events unvorhersagbar
verzögert werden, da das Reservierungsprotokoll über NRT-Kanäle arbeitet. Die
Ausnutzung von RT-Kanälen für das Lebenszeichen behebt zwar das letztere Problem,
erfordert aber noch immer eine Annahme, ab wieviel ausgebliebenen Lebenszeichen die
Inaktivität eines Knotens garantiert ist. Kernproblem ist folglich, nach welcher Zeit ein
Lease abläuft, also bis wann er spätestens erneuert werden muss. Ein abgelaufener Lease
führt zu einem planerseitigen unannounce bzw. unsubscribe. Das unannounce führt zur
Freigabe von reservierter Medienzeit, die im Anschluss erneut vergeben werden kann. Falls
ein Knoten jedoch fälschlicherweise für inaktiv erklärt wurde und seine Medienzeit neu
vergeben wird, kommt es zur Verletzung des TDMA-Schemas, so dass die Echtzeiteigenschaften
des Gesamtsystems nicht mehr garantiert werden können. Um sicherzustellen,
dass das TDMA-Schema eingehalten wird, muss somit sichergestellt sein, dass ein noch
aktiver Echtzeitknoten nie für inaktiv erklärt wird. Eine Alternative wäre, wenn garantiert
werden kann, dass ein fälschlicherweise inaktiv erklärter Knoten aufhört zu senden, indem
man ihn verlässlich über den Entzug der Ressourcen informiert.
Beides ist jedoch nur möglich, wenn die Anzahl der aufeinander folgenden Auslassungen
im Netzwerk beschränkt ist. Letzteres ist daher eine Voraussetzung, um Leasing für
Echtzeitkanäle erlauben zu können. Wenn die Lebenszeichen-Events wie Announcements
und Subscriptions per NRT versendet werden, muss auÿerdem deren Latenz beschränkt
sein, inklusive der Zeit in Warteschlangen. Notwendige Bedingung hierfür ist es, diese
Events höher zu priorisieren, als NRT-Events der Anwendungen, da sich über letztere
63

3 Echtzeitkommunikationskanäle
keine Aussagen machen lassen. Anders als beim Leasing im NRT-Bereich müssen alle hier
getroenen Annahmen eine sehr hohe Assumption-Coverage aufweisen, da eine Verletzung
der Annahmen vergebene Echtzeitgarantien gefährdet. Daher wird die Erweiterung des
Protokolls um Leasing für Echtzeitkanäle für eine weiterführende Arbeit vorgeschlagen.
3.3.6 Eigenschaften des Protokolls
Das vorgestellte Reservierungsprotokoll vereint folgende Eigenschaften:
• Es erlaubt den Auf- und Abbau von Kanälen mit QoS-Anforderungen zur Laufzeit.
Änderungen von QoS-Anforderungen sind möglich, indem der Kanal abgebaut und
anschlieÿend mit den neuen Anforderungen wieder aufgebaut wird. Das Protokoll verwendet
NRT-Events, so dass für die Protokollabarbeitung keine zeitlichen Garantien
gegeben werden können. Der Auf- und Abbau von Echtzeitkanälen ist folglich nur
auÿerhalb des echtzeitkritischen Pfades möglich.
Über eine Erweiterung des Protokolls könnten auch Reservierungen in Echtzeit unterstützt
werden. Dazu müssen die Protokoll-Events über einen Echtzeitkanal versendet
werden. Dieser kann bei Initialisierung des Knotens über die bisherige NRT-Version
des Protokolls aufgebaut werden. Für Reservierungen in Echtzeit ist jedoch auch ein
echtzeitfähiger Planer nötig.
• Echtzeit-Events werden nur über das Netzwerk versendet, wenn es dort Subscriber
für diese Events gibt. Die eingesparte Medienzeit erhöht den Durchsatz für NRT-
Events. Kommunikationskanäle für die Echtzeit-Events werden jedoch immer reserviert,
auch wenn die Kanäle beispielsweise nur zur lokalen Kommunikation verwendet
werden. So bleibt eine planbare Menge von Echtzeit-Publishern auch planbar,
wenn Publisher oder Subscriber auf andere Knoten migriert werden oder neue Subscriber
hinzukommen. Wenn nicht genug Ressourcen für die Reservierung vorhanden
sind, wird der Einplanbarkeitstest automatisch wiederholt, sobald Medienzeit
freigegeben wird.
Das Protokoll lässt sich auch variieren, um Echtzeit-Events unabhängig von der Existenz
eines Subscribers zu versenden. Vorteil ist die Vereinfachung des Protokolls,
da hier nur noch die Events Announcements und ResDeliv, sowie die Zustände
nicht reserviert, genutzt und planerseitig ggf. Warte auf Poll-Master benötigt
werden. Nachteilig ist, dass Echtzeit-Events auch versendet werden, wenn kein Subscriber
vorhanden ist. Dies führt bei fehlender Filterung in der Netzwerk-Hardware
zu einer höheren Prozessorauslastung in allen Knoten des Netzwerks. Auÿerdem kann
die belegte Medienzeit natürlich nicht zur Übertragung von NRT-Events verwendet
werden.
• Das Protokoll ist unempndlich gegen den Verlust von Events und gegen Duplikate.
Announcements und Subscriptions werden automatisch wiederholt. Stimmt der
64

3.3 Reservierungsprotokoll
Reservierungszustand eines Kommunikationskanals nicht mit dem vom Planer erwarteten
Zustand überein, wird ein entsprechendes Event gesendet, um den Zustand
im PEC anzugleichen.
• Wenn ein Knoten (ausgenommen Planer- und Poll-Master) abstürzt und per
Watchdog-Timer neu gestartet wird, so wird der vorherige Zustand im Regelfall
direkt wieder hergestellt, indem die initialen Reservierungszustände durch erneut
gesendete Res- oder ResDeliv-Events an die im Planer liegenden Zustände
angeglichen werden. Wenn dem Knoten bei der Versendung des ersten Announcements-
bzw. Subscriptions-Events noch nicht alle Publisher bzw. Subscriber
bekannt sind, werden die entsprechenden Kanäle vom Planer ab- und später erneut
aufgebaut. Gleiches gilt, wenn die PEC-IDs vor und nach dem Neustart nicht übereinstimmen.
• Das Protokoll harmoniert mit anderen Features von FAMOUSO. Die mit den Announcements
und Subscriptions versendeten Informationen werden auch für
Composability Checks [SL09] und das Forwarding von Events an Gateways genutzt.
• Das Protokoll lässt sich um Leasing-Mechanismen erweitern, welche die Freigabe von
verwaisten Kommunikationskanälen möglich machen.
• Das Protokoll erlaubt Erweiterungen, um die Komponierbarkeit der QoS-
Anforderungen von Publishern und zugehörigen Subscribern zu überprüfen. Durch
Gegenüberstellung der Announcements und Subscriptions könnten z. B. nicht
zueinander passende Perioden oder maximale Event-Längen erkannt und anschlieÿend
gemeldet werden.
• Durch die Verwendung eines zentralen Planers für mehrere Netze lässt sich das Protokoll
auch gut für netzwerkübergreifende Planung ausbauen. So könnte der Planer
bei Kenntnis der Topologie des dedizierten Netzverbundes überwachen, ob in allen
Teilstrecken eines über mehrere Netze reichenden Echtzeit-Pfads eine Reservierung
möglich ist. Denkbar ist auÿerdem, bei der netzwerkübergreifenden Planung auch
Anforderungen wie die maximale Latenz zu beachten, die unter Umständen eine
Abstimmung der TDMA-Zyklen mehrerer Netze nötig machen.
65

4 Integration in FAMOUSO
Die im vorherigen Kapitel erarbeiteten Echtzeitkommunikationskanäle ermöglichen es,
Nachrichten zeitlich vorhersagbar von einem Knoten zu anderen Knoten zu übertragen.
Auÿerdem können die Kanäle zur Laufzeit aufgebaut werden, wobei für jeden Kanal individuelle
QoS-Anforderungen gestellt werden können. Ziel dieses Kapitels ist es, die erarbeiteten
Konzepte in FAMOUSO zu integrieren. Auf diese Weise werden die bisher
vorhandenen Features von FAMOUSO auch für Echtzeitanwendungen nutzbar.
Die von der Middleware angebotenen Publish/Subscribe-Dienste werden durch
Ereigniskanäle bereitgestellt. Daher wird zunächst auf die Besonderheiten der für Echtzeitanwendungen
entworfenen Ereigniskanäle eingegangen. Der zweite Teil des Kapitels
behandelt die Umsetzung der Echtzeitereigniskanäle und die dafür nötigen Erweiterungen
und Anpassungen in FAMOUSO. Im dritten Teil geht es um die Konguration der Middleware.
In diesem Kapitel werden konzeptionellen Sachverhalte in Verbindung mit Aspekten
der Implementierung und der Verwendung der Middleware dargestellt. Auf Details der
Implementierung wird jedoch nicht eingegangen 1 .
4.1 Echtzeitereigniskanäle
In FAMOUSO sind Ereigniskanäle die Programmierschnittstelle, die dem Anwendungsentwickler
Zugri auf die Middleware-Funktionen bietet. Ein Ereigniskanal ist ein Objekt,
dass durch eine Kommunikationsrichtung Publisher oder Subscriber , ein
Subject, eine Menge von QoS-Anforderungen und Anwendungsrückrufe gekennzeichnet
ist. Die Kommunikationsrichtung bestimmt dabei die zur Verfügung stehenden
Middleware-Funktionen (z. B. publish oder subscribe) und Anwendungsrückrufe. Für
einen Subscriber-Ereigniskanal (engl.: Subscriber Event Channel, SEC) kann die Anwendung
einen Notizierungsrückruf (engl.: Notify Callback) angeben. Die Middleware ruft
die als Rückruf gebundene Funktion auf, um ein eingegangenes Event an die Anwendung
auszuliefern. Es gibt auÿerdem einen Ausnahmerückruf (engl.: Exception Callback), der
aufgerufen wird, wenn die spezizierten QoS-Anforderungen nicht eingehalten werden können.
Dieser Rückruf ist bei SECs und Publisher-Ereigniskanälen (engl.: Publisher Event
Channel, PEC) verfügbar.
1
Die Implementierung ist Teil von FAMOUSO. Der Quellcode und dessen Dokumentation kann über die
Projekt-Website http://famouso.sf.net/ abgerufen werden.
67

4 Integration in FAMOUSO
Im Folgenden wird zwischen den bisher vorhanden Best-Eort-Ereigniskanälen und den
neu geschaenen Echtzeitereigniskanälen unterschieden. Anders als bei der Best-Eort-
Kommunikation ist im Echtzeitkontext eine Entkopplung von Applikation und Middleware-
Kern bezüglich Zeit und Programmuss nötig. Auf die Gründe und Eekte der Entkopplung
wird in Abschnitt 4.2.1 eingegangen. Die Best-Eort-Ereigniskanäle stehen weiterhin
mit der bisherigen Semantik zur Verfügung. In den Echtzeitereigniskanälen werden die für
Echtzeitanwendungen vorgesehenen Features realisiert.
Der Entwurf der Echtzeitkanäle orientiert sich an Echtzeitanwendungen zur digitalen
Steuerung und Regelung, bei denen das Einlesen von Sensordaten, die Verarbeitung und
die Ausgabe von Steuersignalen periodisch wiederholt werden. In verteilten Systemen sind
an dieser Kette oft mehrere Komponenten beteiligt, wobei diese periodisch kommunizieren.
Gemäÿ dieser typischen Anforderung wird für die Echtzeitkanäle streng periodische Kommunikation
vorgesehen. Diese Flexibilitätseinschränkung geht mit dem groÿen Vorteil einher,
dass es damit a-priori-Wissen über die Sende- und Empfangszeitpunkte gibt. Dieses
Wissen ist ideal für die Bereitstellung von Echtzeitgarantien beim Medienzugri und für
eine schnelle Fehlererkennung.
Für jeden Echtzeit-PEC muss mittels einer Periode angegeben werden, wie oft er Informationen
in Events veröentlichen will. Die vom Publisher angegebene Periode erlaubt
eine direkte Kopplung mit einem Kommunikationskanal des im Kapitel 3 beschriebenen
echtzeitfähigen Medienzugrisverfahrens. Lokales Scheduling von Echtzeit-Events ist somit
nicht nötig. Auÿerdem wird keine Warteschlange gebraucht, in der sich Echtzeitdaten
stauen und dabei veralten könnten. Eine geringere Ende-zu-Ende-Latenz und geringerer
Jitter sind die Folge. Die Verpichtung, in jeder Periode zu senden, erlaubt auf den Subscribern,
über das Ausbleiben von Events Fehler zu erkennen und angemessen auf das
Fehlen aktueller Informationen zu reagieren, beispielsweise indem ein sicherer Zustand
eingenommen wird. Dies ist eine wichtige Grundlage für die Entwicklung verlässlicher
verteilter Echtzeitsysteme.
4.1.1 Quality of Service
Für jeden Ereigniskanal können individuelle QoS-Anforderungen speziziert werden,
deren Einhaltung in FAMOUSO gemäÿ der Multi-Level-Composability-Check-
Architecture (MLCCA, vgl. [SL09]) überprüft wird. Die entwickelten Echtzeitkommunikationskanäle
ermöglichen darüber hinaus die Durchsetzung von zeitbezogenen QoS-
Anforderungen wie einer Periode, einer maximalen Latenz oder eines maximalen Jitters.
Durch die Koordination der Medienzugrie (siehe Kapitel 3) kann für die Übertragung
von Events innerhalb eines Netzwerks eine beschränkte Latenz mit geringem Jitter
garantiert werden. Eine durch den Netzwerk-Planer gegebene QoS-Garantie bleibt auch
beim Hinzukommen beliebig vieler weiterer Knoten und unabhängig von der Auslastung
des Mediums erhalten. In Kombination mit der für diese Arbeit geltenden Annahme, dass
68

4.1 Echtzeitereigniskanäle
die Software in einer Umgebung läuft, in der die Einhaltung der Fristen von lokalen Tasks
sichergestellt ist 2 , ergibt sich auch eine beschränkte Ende-zu-Ende-Latenz von der Veröffentlichung
durch den Publisher bis zur Benachrichtigung des Subscribers.
Einige der in MLCCA unterstützten QoS-Anforderungen haben für Echtzeitereigniskanäle
eine erweiterte Bedeutung, die über die Composability-Checks hinaus gehen. Diese werden
im Folgenden erläutert.
4.1.1.1 Zeiteigenschaften
Dieser Abschnitt behandelt die Parameter, die zur direkten Beeinussung der Zeiteigenschaften
von Echtzeitereigniskanälen zur Verfügung stehen. Die an einen Echtzeit-PEC
gestellten Anforderungen Periode, maximale Event-Länge und Slot-Rahmenintervall dienen
als Anforderungen für die Reservierung des oder der zugehörigen Kommunikationskanäle.
Die Bedeutung der Anforderungen in diesem Zusammenhang wurde bereits in
Abschnitt 3.2.1 erklärt. Die Anforderungen Periode und maximale Event-Länge sind auch
für Echtzeit-SECs und im Zusammenspiel von Echtzeit-PEC und -SEC relevant. Daher
wird auf diese beiden nochmals eingegangen:
• Periode: Die Echtzeitereigniskanäle funktionieren streng periodisch, so dass bei
diesen die Periode als kennzeichnendes Attribut immer angegeben werden muss. Sie
gibt die Zeit an, die zwischen der Auslieferung von zwei zeitlich aufeinander folgenden
Events liegt. Als Werte sind nur Vielfache der Planungsgranularität G zulässig
(siehe Abschnitt 3.2.5).
Bei PECs bestimmt die Periode, wie oft Events veröentlicht werden können und
müssen. Beim Publizieren von Sensorwerten entspricht sie beispielsweise der Abtastperiode
oder einem Vielfachen dessen, wenn eine Vorverarbeitung über mehrere
Werte stattndet. Der Publisher muss genau einmal pro Periode die Middleware-
Funktion publish aufrufen, um ein Event wenn auch nur ein leeres Event
zu veröentlichen. Abweichendes Verhalten wird als Fehler der Anwendung interpretiert.
Beim SEC entspricht die Periode der gewünschten Periodizität der Weiterverarbeitung,
denn einmal pro angegebener Periode wird der Anwendung über den
Notizierungsrückruf (engl.: Notication Callback) das zu diesem Moment aktuellste
Event ausgeliefert, falls dieses nicht veraltet ist. Wenn doch, wird stattdessen der
Ausnahmerückruf (engl.: Exception Callback) aufgerufen. Details zu den Echtzeit-
PECs und -SECs werden in Abschnitt 4.2.1 besprochen.
2
Hierzu wird ein echtzeitfähiges Task-Scheduling benötigt. Auÿerdem müssen ausreichend Betriebsmittel
vorhanden sein, um die gegebenen Fristen einhalten zu können. Nicht vorhersagbare Verzögerungen,
wie sie beispielsweise beim Swapping im Zusammenhang mit der Verwendung von virtuellem Speicher
auftreten, sind auszuschlieÿen.
69

4 Integration in FAMOUSO
Die Periode kann bei PECs und SECs eines Subjects unterschiedlich gewählt werden.
Damit die geforderte QoS jedoch mit der gebotenen QoS kompatibel ist, muss die
Periode des Subscribers gröÿer oder gleich der des Publishers sein.
Im Zusammenhang mit der maximalen Event-Gröÿe bestimmt die Periode auch den
möglichen Datendurchsatz eines Kanals. Unter der Annahme, dass die beteiligten
lokalen Tasks in den geforderten Zeitschranken ausführbar sind, hat die Periode auch
Einuss auf die Ende-zu-Ende-Latenz. Im Worst-Case liegt diese bei der Summe
aus Publisher-Periode, Netzwerklatenz und Subscriber-Periode. Durch die Abstimmung
der lokalen Task-Planung und der Netzwerkplanung über die Angabe eines
Slot-Rahmenintervalls kann die Ende-zu-Ende-Latenz jedoch auch direkt vorgegeben
werden. Dies wird im Abschnitt 5.3 an einem Beispiel verdeutlicht.
• Maximale Event-Länge: Bei Echtzeit-PECs und -SECs muss eine maximale Event-
Länge (in Byte) angegeben werden, um die zu reservierenden Ressourcen genau
bemessen zu können. Sie dient der Dimensionierung der lokalen Event-Puer und
beeinusst die Slotdauer auf dem Übertragungsmedium. Je geringer die maximale
Event-Gröÿe, desto weniger Ressourcen müssen reserviert werden.
Die maximale Event-Gröÿe sollte für ein Subject in globaler Übereinstimmung
angegeben werden. Bei PECs können nur Events veröentlicht werden, die nicht
gröÿer als die angegebene maximale Event-Länge sind. Bei Subscribern werden ebenso
nur Events angenommen, die kleiner oder gleich der angegebenen maximalen
Gröÿe sind.
Für die Echtzeitkanäle ist auÿerdem das Kontext-Attribut Frist (engl.: Deadline) relevant,
mit dem Events versehen werden können. Das Attribut erlaubt die Angabe eines absoluten
spätesten Zeitpunktes für die Auslieferung des Events an einen Subscriber. Es wird nicht
garantiert, dass das Event innerhalb der angegebenen First ausgeliefert werden kann, denn
die Übertragung des Events erfolgt gemäÿ der QoS-Zusicherungen des zur Veröentlichung
verwendeten PECs. Es wird jedoch sichergestellt, dass das Event nach Ablauf der Frist
verworfen und nicht an Subscriber ausgeliefert wird. Dieses Attribut ist insbesondere bei
der Weiterleitung von Events über Netzwerkgrenzen hinweg relevant. Hier können bisher
keine beschränkten Latenzen garantiert werden. Mithilfe dieses Attribut kann jedoch die
Überschreitung einer maximal erlaubten Latenz erkannt werden.
4.1.1.2 Verlässlichkeit
Durch die Verpichtung der Publisher, einmal pro Periode ein Event zu veröentlichen,
können Zeitfehler und Abstürze von Publisher-Applikationen von der Middleware erkannt
werden. Beide äuÿern sich als Auslassung des erwarteten Events. Durch die Protokollierung
derartiger Fehler kann der Entwickler bei der Diagnose von Problemen unterstützt werden.
Sämtliche Fehler von Publisher-Knoten werden durch Fail-Silent-Verhalten kommuniziert
70

4.1 Echtzeitereigniskanäle
und werden somit über das Ausbleiben von erwarteten Events erkannt. Auch Übertragungsfehler
im Netzwerk werden beim Empfang über CRC-Codes zu Auslassungen maskiert, so
dass diese über den gleichen Mechanismus die Erkennung von Auslassungen durch die
Verletzung der spezizierten Periodizität erkennbar sind.
Erkannte QoS-Verletzungen führen zum Aufruf des Ausnahmerückrufs des jeweiligen
Ereigniskanals. Bei SECs werden nicht nur lokale Fehler erkannt, sondern auch Fehler der
Publisher oder der Übertragung. PECs werden hingegen im Allgemeinen nur über lokale
Fehler informiert. Bei CAN können dem PEC auch Fehler des Netzwerks gemeldet werden,
da diese dem Sender bei CAN signalisiert werden. Eine derart eziente Rückmeldung ist
bei Ethernet nicht möglich.
Für die Verlässlichkeit im Kontext der Echtzeitkommunikationskanäle sind besonders die
durch Störungen des Netzwerks verursachten Auslassungen relevant. Da es sich dabei meist
um kurzzeitige temporäre Störungen handelt, lässt sich die Wahrscheinlichkeit für das korrekte
Empfangen der Daten durch mehrfaches Senden (Zeitredundanz) deutlich erhöhen.
Für die mehrfache Übertragung derselben Daten muss zusätzliche Medienzeit reserviert
werden. Es existiert hier ein Zielkonikt zwischen Verlässlichkeit der Übertragung und der
Menge der zu reservierenden Ressourcen. Um dem Anwendungsentwickler die Möglichkeit
zum Abwägen in diesem Zielkonikt zu geben, kann für jeden PEC über das Attribut Repetition
angegeben werden, wie häug ein Event wiederholt gesendet werden soll. Bei CAN
kann die Repetition als maximale Anzahl der Wiederholungen genutzt werden, da hier bei
Übertragungsfehlern eine sofortige Rückmeldung erfolgt. Somit kommt die Zeitredundanz
dort nur im Fehlerfall zum Einsatz. Bei Ethernet wird jedes Paket mehrfach übertragen,
um die Auslassungen zuverlässig zu maskieren.
Eine Alternative zur Verwendung des Repetition-Attributs ist die Anwendung unterschiedlicher
Perioden bei PEC und SEC. Ist die Periode beim PEC N Mal so groÿ wie
beim SEC, so können innerhalb einer Subscriber-Periode bis zu N − 1 verloren gegangene
Events maskiert werden.
Andererseits gibt es auch den Fall, dass nicht jedes der veröentlichten Events für das
System funktionskritisch ist, so dass eine gewisse Anzahl an Auslassungen lediglich zur
Verringerung der von der Anwendung erbrachten Dienstgüte führt, ohne dass es zu
einem kritischen Funktionsausfall kommt. Hierfür kann bei einem Echtzeit-SEC über das
QoS-Attribut Omission die Anzahl der tolerierbaren aufeinanderfolgenden Auslassungen
deniert werden. Der Wert beeinusst die Gültigkeitsdauer eines beim SEC eingegangenen
Events, falls diese nicht explizit als Kontext-Attribut des Events angegeben wurde. Die
Bestimmung und die Rolle der Gültigkeitsdauer wird in Abschnitt 4.2.1 besprochen.
71

4 Integration in FAMOUSO
4.1.2 Verwendung der API
Dieser Abschnitt gibt einen Überblick, wie die Echtzeitereigniskanäle verwendet werden
können. Das hier vorgestellte Interface ist konzeptionell äquivalent zu den bereits vor Beginn
der Arbeit in FAMOUSO vorhandenen Best-Eort-Ereigniskanälen. Auf die typische
Verwendung des Interfaces in der momentanen Implementierung wird in Abschnitt 4.2.1
gesondert eingegangen.
Spezikation von QoS-Anforderungen QoS-Anforderungen von Ereigniskanälen werden
unter Nutzung des Attribut-Frameworks AFFIX (vgl. [SF11]) in Form einer Attributmenge
angegeben. Attributmengen werden in der Implementierung des Frameworks als
C++-Klassentemplates realisiert. Dies ermöglicht die Composability-Checks zur Compile-
Zeit über Template-Metaprogramme sowie die Optimierung des Programmcodes, der zur
Erstellung der zur Laufzeit verwendeten Binärrepräsentation der Attribute dient.
Im folgenden C++ Codebeispiel werden Anforderungen für einen Echtzeitereigniskanal
deniert:
typedef SetProvider<
Period ,
MaxEventLength
>:: attrSet Req ;
Die Attributmenge Req enthält die Attribute Periode (Period) und maximale
Eventlänge (MaxEventLength). Als Periode wird der Wert 5000 µs angegeben. Die
Eventlänge wird auf maximal 20 Byte beschränkt. Die denierte Attributmenge Req wird
im nachfolgenden Beispiel jeweils einem Echtzeit-PEC (RealTimePublisherEventChannel)
und einem Echtzeit-SEC (RealTimeSubscriberEventChannel) als QoS-Anforderung zugeordnet.
typedef RealTimePublisherEventChannel<
famouso : : config : : PEC ,
Req
> MyRTPEC ;
typedef RealTimeSubscriberEventChannel<
famouso : : config : : SEC ,
Req
> MyRTSEC ;
Sowohl RealTimePublisherEventChannel als auch RealTimeSubscriberEventChannel
sind Klassen-Templates. Als erster Template-Parameter muss der PEC- bzw. SEC-Typ
der verwendeten FAMOUSO-Konguration angegeben werden (siehe Abschnitt 4.3). Der
72

4.1 Echtzeitereigniskanäle
zweite Parameter ist die als QoS-Anforderung zu verwendende Attributmenge. Wenn für
verschiedene Ereigniskanäle unterschiedliche QoS-Anforderungen speziziert werden, wird
das verwendete Template zu verschiedenen Klassen-Typen instanziiert. Zur leichteren Verwendung
wird den resultierenden Echtzeitereigniskanal-Typen hier mittels typedef jeweils
ein kurzer Bezeichner zugeordnet. Der denierte Echtzeit-PEC mit den oben angegebenen
QoS-Anforderungen ist nun als Typ MyRTPEC bekannt. Hinter dem Typ MyRTSEC
verbirgt sich die Klasse für Echtzeit-SEC mit den selben QoS-Anforderungen. Andere
QoS-Anforderungen können anlog zu den Beispielen deniert und an den Ereigniskanälen
angewendet werden.
Verwendung eines Echtzeit-Publisher-Ereigniskanals Um nun tatsächlich einen
Ereigniskanal zu verwenden, muss lediglich der Typ des Kanals instanziiert werden.
Um mehrere Kanäle mit den gleichen Anforderungen zu nutzen, müssen entsprechend
mehrere Instanzen angelegt werden. Hier wird jedoch nur ein Kanal mit dem Bezeichner
pec angelegt:
MyRTPEC pec ( "my subj" ) ;
pec . announce ( ) ;
Bei der Instanziierung muss dem Konstruktor das Subject des Kanals übergeben werden.
Das Subject ist in FAMOUSO genau 8 Byte lang. Hier wurde es als String "my subj"
angegeben. In der zweiten Zeile wird der Kanal der Middleware bekannt gemacht, indem
die Methode announce aufgerufen wird. Diese führt zur asynchronen Abarbeitung des
in Abschnitt 3.3 beschriebenen Reservierungsprotokolls. Es wird folglich aus announce
zurückgekehrt ohne auf Antworten des Planers zu warten. Nach dem announce sollte die
Anwendung einmal pro spezizierter Periode (hier 5000 µs) ein Event veröentlichen:
Event event ( pec . subject ( ) ) ;
event . data = "Payload" ;
event . length = 7;
pec . publish ( event ) ;
Hier wird zunächst ein Event event angelegt und mit dem Subject der Kanals
pec, den Nutzdaten "Payload" sowie der Byteanzahl der Nutzdaten initialisiert. Anschlieÿend
wird das Event über den Aufruf der Methode publish auf dem Kanal
veröentlicht. Ist die Auslieferung des Events nicht gemäÿ der QoS-Anforderungen
möglich, da ein Echtzeitkommunikationskanal (noch) nicht zur Verfügung steht, wird
beim publish der Ausnahmerückruf (engl.: Exception Callback) des PEC aufgerufen,
falls dieser gebunden wurde. Unter der Voraussetzung, dass eine Funktion mit der Signatur
void my_exception_handler() existiert, kann diese auf folgende Weise gebunden
werden:
73

4 Integration in FAMOUSO
pec . exception_callback . bind();
Die unannounce-Methode zum Abbau des Kanals wird implizit beim Löschen des Kanalobjekts
pec aufgerufen.
Verwendung eines Echtzeit-Subscriber-Ereigniskanals Die Instanziierung des Echtzeit-
SECs erfolgt analog zum -PEC. An die Stelle des announce-Aufrufs tritt jedoch hier das
subscribe. Um den Kanal nutzen zu können, muss auÿerdem mindestens einer der Rückrufe
gebunden werden. Im Folgenden Beispiel werden beide, sowohl der Notizierungs- als
auch der Ausnahmerückruf, gebunden.
MyRTSEC sec ( "my subj" ) ;
sec . notify_callback . bind();
sec . exception_callback . bind();
sec . subscribe ( ) ;
Die Signatur des Ausnahmerückrufs stimmt mit der beim PEC erwähnten überein. Die Auslieferung
von Events an die Anwendung geschieht über den Aufruf des Notizierungsrückrufs.
Er erhält das Event als Parameter.
void my_notification_handler ( const Event & event ) {
}
// Verarbeitung des Events . . .
Da pec und sec das gleiche Subject haben und ihre QoS-Anforderungen kompatibel sind,
werden auf pec veröentlichte Events über die Funktion my_notificytion_handler an
die Subscriber-Anwendung ausgeliefert. Ist die Auslieferung gemäÿ der spezizierten QoS
nicht möglich, so wird stattdessen my_exception_handler aufgerufen. Der Abbau von
SECs erfolgt über ein implizites unsubscribe beim Löschen von sec.
4.2 Umsetzung in FAMOUSO
In diesem Abschnitt wird die Integration der Echtzeitkanäle in die bestehende Software-
Architektur von FAMOUSO behandelt. Dafür werden neue Komponenten hinzugefügt
und einige vorhandenen Komponenten um benötigte Funktionalität erweitert. Dabei wird
auf die Kompatibilität der Schnittstellen geachtet, so dass die Middleware auch mit der
Ergänzung vielfältig kongurierbar bleibt.
Abb. 4.1 gibt einen Überblick über die erweiterte Architektur von FAMOUSO. Neu
hinzugefügte Komponenten sind darin grau hinterlegt. Im unteren Teil des Bildes ist
der Stapel der Middleware-Schichten dargestellt, über welche die angebotenen Dienste
bereitgestellt werden. Als Schnittstelle zu den darauf aufbauenden Applikationen dienen
die Ereigniskanäle (engl.: Event Channels, EC). Für Echtzeit-Applikationen wurde
74

4.2 Umsetzung in FAMOUSO
Applikationen
RT-Netz-Planer NRT-Poll-Master ...
Middleware
RT-PEC RT-SEC NRT-PEC NRT-SEC
Management Layer
Event Layer
Event Dispatcher
Abstract Network Layer
Network Guard
Network Layer
Abbildung 4.1: Integration in FAMOUSO. Neu hinzugefügte Komponenten
sind grau hinterlegt.
die Schnittstelle um Echtzeit-Publisher-Ereigniskanäle (RT-PEC) und Echtzeit-Subscriber-
Ereigniskanäle (RT-SEC) erweitert. Anders als die Nicht-Echtzeit-Varianten (NRT-PEC
und NRT-SEC) ndet in diesen eine Entkopplung der Anwendung und des Middleware-
Kerns statt. Die Ereigniskanäle setzen auf dem Event Layer auf, der die eigentliche
Publish/Subscribe-Funktionalität zur Verfügung stellt. Im Rahmen dieser Arbeit wurde er
in zwei Sublayer untergliedert. Die bisherige Funktionalität des Event Layers wird nun vom
Event Dispatcher übernommen. Seine Aufgaben sind im Wesentlichen die Auslieferung von
Events an lokale Subscriber, die Verwaltung von Listen der bekannten lokalen PECs und
SECs sowie unter Verwendung der darunter liegenden Ebenen das Publizieren über
das Netzwerk sowie das Abholen von empfangenen Events. Neu hinzugefügt wurde der
Management Layer, über den die Reservierung von Echtzeitkommunikationskanälen und
andere QoS-Aspekte abgewickelt werden. Unterhalb des Event Layers liegen der Abstract
Network Layer und der Network Layer, zwischen denen sich bei einem Echtzeit-Netzwerk
der Network Guard eingliedert. Im Abstract Network Layer ndet die Fragmentierung
von Nachrichten in Pakete statt, die im Netzwerk übertragbar sind. Der Network Guard
sorgt für die Einhaltung des Echtzeit-Medienzugrisprotokolls. Im Network Layer sind
die Eigenheiten des verwendeten Netzwerk-Typs gekapselt. Für Netzwerk-Typen, die auf
verschiedenen Plattformen unterschiedlich angesprochen werden, ist unterhalb des Network
Layers eine Gerätetreiber-Abstraktion mit einheitlicher Schnittstelle vorgesehen, auf
die in der Abbildung verzichtet wurde. Auf Knoten mit mehreren Netzwerkanbindungen
können Abstract Network Layer, Network Guard und Network Layer für jedes Netzwerk
individuell konguriert werden.
75

4 Integration in FAMOUSO
Für die Echtzeitkanäle werden zwei spezielle, zur Middleware gehörende Applikationen
ergänzt: der Echtzeit-Netzwerk-Planer und der Poll-Master. Auÿerhalb des Middleware-
Kerns sind diese beiden Komponenten sehr leicht austauschbar, so dass die verwendete
Planungs- und Polling-Strategie einfach modiziert werden kann. Die Kommunikation mit
dem Middleware-Kern erfolgt über Ereigniskanäle mit für diesen Zweck reservierten Subjects.
Neben diesen beiden speziellen Echtzeitapplikationen, können beliebig viele weitere
Echtzeit- und Nicht-Echtzeit-Anwendungen existieren.
4.2.1 Echtzeit-Publisher- und Echtzeit-Subscriber-Ereigniskanal
Entkopplung von Anwendungen und Middleware Für die bisher vorhandenen Best-
Eort-Ereigniskanäle kehrt der Aufruf der Middleware-Funktion publish erst nach der
Übertragung des Events in alle eingebundenen Netze sowie der Auslieferung des Events
an alle lokalen Subscriber zurück. Im Kontext einer Echtzeitanwendung ist dieses Verhalten
problematisch, weil hierdurch eine sehr schwer vorhersagbare Verzögerung entsteht. Die
Verzögerung wird auÿerdem sehr groÿ ausfallen, da im Allgemeinen keine Synchronität
zwischen den publish-Aufrufen und den geplanten Sendezeitpunkten (siehe Kapitel 3)
gegeben ist. Somit müsste vor der Rückkehr aus der publish-Funktion für alle angebundenen
Netze auf den jeweils nächsten geplanten Sendezeitpunkt gewartet werden. Als Lösung
für dieses Problem wurde die Entkopplung von Echtzeit-Applikationen und Middleware-
Kern bezüglich Zeit und Programmuss gewählt. Auf diese Weise wird die Laufzeit von
publish unabhängig von anderen Anwendungen, den Interna der Middleware und der
Planung der Echtzeitkommunikationskanäle.
Auch auf Subscriber-Seite ist die Entkopplung von Vorteil. Für Best-Eort-SECs erfolgt
der Aufruf der Notizierungsrückrufe sequentiell aus dem Middleware-Kern. Die Laufzeit
des Anwendungscodes zur Notizierung verzögert so bei mehreren lokalen Subscribern
eines Subjects die Notizierung der anderen Subscriber, so dass zeitliche Vorhersagbarkeit
nicht gegeben ist. Um dieses Problem zu umgehen, werden Events nicht sofort beim Empfang
ausgeliefert, sondern über einen streng periodischen Anwendungstask.
Minimales Multitasking Damit FAMOUSO in der minimalen Konguration für Mikrocontroller
auch ohne Betriebssystem lauähig ist, wurde ein einfaches, nicht-präemptives
und kooperatives Multitasking implementiert. Im umgesetzten Modell besteht jeder Task
aus einer Funktion, einer Startzeit und einer optionalen Periode. Auÿerdem wird zwischen
Echtzeit-Tasks (RT-Tasks) und Nicht-Echtzeit-Tasks (NRT-Tasks) unterschieden.
Für die Ausführung der Tasks ist ein Task-Dispatcher zuständig. Dieser verwaltet eine
nach Startzeit sortierte Liste der angemeldeten Tasks, die der Reihe nach abgearbeitet
wird. Beim Anmelden periodischer Tasks wird der Startzeitpunkt wenn nötig durch
Addition von Vielfachen der Periode in einen zukünftigen Zeitpunkt überführt. Der Dispatcher
arbeitet die Task-Liste nun der Reihe nach ab und ruft jeweils zur angegebenen
76

4.2 Umsetzung in FAMOUSO
Startzeit die Task-Funktion auf. Ein Task ist beendet, wenn seine Funktion zurückkehrt.
Ein NRT-Task kann jedoch zwischenzeitlich kooperativ die Kontrolle an den Dispatcher
übergeben, der nun die Möglichkeit hat, fällige RT-Tasks auszuführen. Es werden hierbei
keine NRT-Tasks ausgeführt, sondern ausschlieÿlich RT-Tasks. Da RT-Tasks die Kontrolle
nicht abgeben dürfen ist somit innerhalb der Aufrufhierarchie eines Dispatchers nur eine
Kontrollabgabe möglich. Dadurch ist ein Deadlock zwischen mehreren NRT-Tasks ausgeschlossen.
Die Abgabe der Kontrolle geschieht beispielsweise bei der Veröentlichung
eines Events auf einem Best-Eort-Kanal über Ethernet, da hier auf die vom Poll-Master
vergebene Sendeberechtigung gewartet werden muss 3 . Die Kontrolle kann in einem NRT-
Task aber auch an beliebiger anderer Stelle abgegeben werden. Ist ein periodischer Task
beendet, wird sein nächster Startzeitpunkt berechnet und er wird für diesen Zeitpunkt
erneut in die Task-Warteschlange einsortiert. Die Perioden und die Startzeiten der Tasks
müssen vom Anwendungsentwickler so gewählt werden, dass sich die Ausführungszeiten
nicht überschneiden 4 .
Das gewählte Task-Modell kommt mit nur einem Funktionsaufruf-Stack aus und ist daher
insbesondere für stark ressourcenbeschränkte eingebettete Systeme interessant. Momentan
wird es jedoch auch für Middleware-Kongurationen eingesetzt, die auf einem Betriebssystem
mit präemptiven Multithreading-Support laufen. Hierbei werden alle Tasks in einem
Dispatcher-Thread abgearbeitet. Eine bessere Ausnutzung des Multithreadings in diesen
Umgebungen wird für eine weiterführende Arbeit vorgeschlagen.
Verwendung des RT-PECs und RT-SECs mit dem Multitasking-Modell Wird das
eben vorgestellte Multitasking-Modell verwendet, so kann es vom Entwickler auch zur
Ausführung der Anwendungstasks eingesetzt werden. Wurde wie in Abschnitt 4.1.2 ein
RT-PEC mit dem Bezeichner pec deniert, so könnte beispielsweise folgender einfacher
Publisher-Task implementiert werden, der ein Event auf dem RT-PEC veröentlicht.
void my_publisher_task_func ( ) {
}
// I n i t i a l i s i e r e Event ( ohne Kontext−A t t r i b u t e )
Event event ( pec . subject ( ) ) ;
event . length = 2;
event . data = get_sensor_value ( ) ;
// P u b l i z i e r e Event
pec . publish ( event ) ;
3
Diese Funktionalität ist als Policy realisiert und kann bei Verwendung von präemptiven Multithreading
durch eine Implementierung ausgetauscht werden, die an einer Semaphore auf die Sendeberechtigung
wartet.
4
Da die Planung von Prozessorzeit nicht Thema dieser Arbeit ist, muss dieser Plan vom Anwendungsentwickler
bereitgestellt werden.
77

4 Integration in FAMOUSO
Um die Task-Funktion periodisch ausführen zu lassen, muss sie nun noch beim Dispatcher
angemeldet werden:
Task publisher_task ( publisher_task_start_time , period ,
Task : : RealTime ) ;
publisher_task . bind();
Dispatcher : : enqueue ( publisher_task ) ;
Hier wird zunächst eine Instanz der Klasse Task angelegt, die mit der Startzeit und der Periode
initialisiert und als Echtzeit-Task markiert wird. Anschlieÿend wird die Task-Funktion
gebunden. In der letzten Zeile wird der Task beim Dispatcher angemeldet. Im Anschluss
ruft der Dispatcher ab dem Zeitpunkt publisher_task_start_time mit der angegebenen
Periodizität (period) die Funktion my_publisher_task_func() auf.
Auf der Subscriber-Seite ist ein Task für den periodischen Aufruf des gebundenen
Notizierungs- bzw. Ausnahmerückrufs zuständig: der Subscriber-Task. Er wird intern
im RT-SEC initialisiert und verwaltet. Optional kann bei der Erstellung des RT-SEC
eine subscriber_task_start_time angegeben werden, um den Task mit anderen Aktivitäten
zu synchronisieren. Sie gibt den Zeitpunkt des ersten Aufrufs des Notication
bzw. Exception Callbacks als globale Zeit an. Damit wird auch die Phasenverschiebung
bezüglich anderer Tasks deniert. Der zwischen publisher_task_start_time
und subscriber_task_start_time bestehende Zeitversatz bestimmt die Ende-zu-
Ende-Latenz vom Veröentlichen des Events bis zur Auslieferung des Events beim
Subscriber. Es wird auÿerdem eine Abstimmung mit der Netzwerkplanung über die
Angabe eines Slot-Rahmenintervalls für den RT-PEC empfohlen. Denn wenn dadurch
sichergestellt ist, dass die Übertragung über das Netzwerk zwischen der publisher- und
subscriber_task_start_time stattndet, kann eine Ende-zu-Ende-Latenz garantiert
werden, die der Dierenz der beiden Zeiten entspricht. Im Zusammenhang mit der
Evaluation (Abschnitt 5.3) wird die Abstimmung von Prozessor- und Netzwerkplanung
illustriert.
Temporal Firewall Da das zur Veröentlichung bestimmte Event beim publish nicht
direkt versendet bzw. an lokale Subscriber ausgeliefert wird, muss es zwischengespeichert
werden. Konzeptionell handelt es sich bei dem Zwischenspeicher um eine Temporal Firewall
(vgl. [KN97]), da sie die Schnittstelle zwischen der Anwendung und der Middleware als
Kommunikationssystem darstellt. Die kommunizierten Echtzeitdaten verfügen über eine
zeitlich beschränkte Gültigkeit, weil sich die zu Grunde liegenden physikalischen Gröÿen
als Funktionen der Zeit ständig ändern können. Die Temporal Firewall verhindert die Verbreitung
veralteter Informationen, die für die Echtzeitsteuerung wertlos sind, oder sogar
schädlich sein können, wenn sie nicht als veraltet identizierbar sind. Daher funktioniert
die Temporal Firewall nicht als Queue, sondern enthält zu jedem Zeitpunkt genau ein
Event, nämlich das zuletzt veröentlichte und damit aktuellste Event. Dieses wird jedoch
78

4.2 Umsetzung in FAMOUSO
nach Ablauf der Gültigkeit verworfen, wenn es nicht bereits zwischenzeitlich durch ein
neueres Event überschrieben wurde.
Funktionsweise RT-PEC Beim RT-PEC schreibt der publish-Aufruf das Event in die
Temporal Firewall. Ist zur Zeit die Einhaltung der QoS nicht garantiert, da (noch) nicht
alle benötigten Echtzeitkommunikationskanäle zur Verfügung stehen, wird beim publish
auÿerdem der Exception Callback aufgerufen. Erfolgt eine Periode lang kein publish,
so verliert das gepuerte Event seine Gültigkeit. Die Auslieferung des Events an lokale
Subscriber und über angebundene Netzwerke erfolgt zeitlich entkoppelt. Für jeden in Verwendung
bendlichen Kommunikationskanal gibt es einen eigenen Deliver-Task, der die
Temporal Firewall liest und das Event über das jeweilige Netzwerk versendet, wenn das
Event noch gültig ist. Auf diese Weise werden Zeitfehler der Anwendung erkannt und die
Verbreitung veralteter Events verhindert. Lokale Subscriber werden im Deliver-Task des
ersten Netzwerks der FAMOUSO-Konguration bedient.
Funktionsweise RT-SEC Auch im RT-SEC wird eine Temporal Firewall eingesetzt. Hier
schreibt FAMOUSO in den Event-Puer, wenn ein auf Subject und Kontextlter passendes
nicht veraltetes Event vom Netzwerk abgeholt oder von einem lokalen Deliver-Task verteilt
wird. Ein Event ist veraltet, falls es eine bereits verstrichene Frist als Kontextattribut
enthält. Liegt eine angegebene Frist in der Zukunft, so wird sie als Gültigkeitsfrist
für das Event verwendet. Wenn das Kontextattribut fehlt, wird die Frist aus den QoS-
Anforderungen des RT-SEC bestimmt:
t expire = t rcv + (n om + 1) · p sub
Dabei entspricht t rcv dem aktuellen Zeitpunkt beim Schreiben der Temporal Firewall, p sub
der Subscriber-Periode und n om der für den RT-SEC spezizierten Anzahl an tolerierbaren
Auslassungen. Falls letztere nicht angegeben wurde, wird n om = 0 angenommen. Der
Subscriber-Task liest das in der Temporal Firewall liegende Event und liefert es über den
Notizierungsrückruf an die Anwendung aus, wenn sein Gültigkeit noch nicht abgelaufen
ist. Anderenfalls wird der Exception Callback aufgerufen, so dass die Anwendung auf den
Fehler reagieren kann, beispielsweise indem sie das Echtzeitsystem in einen sicheren Zustand
bringt. Nach dem Ablauf einer Periode wird der Subscriber-Task erneut ausgeführt.
Wurde für den RT-SEC eine Auslassung n om speziziert, so wird der Exception Callback
erst aufgerufen, nachdem n om + 1 Perioden in Folge kein Event eingegangen ist.
Nebenläugkeit an der Temporal Firewall Beim Puer der Temporal Firewall handelt es
sich um eine gemeinsam genutzte Ressource, die nicht gleichzeitig geschrieben und gelesen
werden darf. Wird beispielsweise ein Task beim Lesen von einem anderen unterbrochen, der
ein neues Event in den Puer schreibt, so hat der lesende Task am Ende eine inkonsistente
79

4 Integration in FAMOUSO
Sicht, da sich das gelesene Event aus Teilen zweier verschiedener Events zusammensetzt. In
der momentanen Implementierung besteht das Problem nur für die Temporal Firewall im
RT-SEC. Beim RT-PEC erfolgt das Lesen und Schreiben nicht nebenläug, da für beides jeweils
ein nicht unterbrechbarer Task gemäÿ des oben beschriebenen Modells vorgesehen ist
und diese vom Task-Dispatcher nur nacheinander ausgeführt werden. Beim RT-SEC wird
der Puer jedoch nebenläug beschrieben, in eingebetteten Systemen ohne Betriebssystem
aus dem Interrupt-Kontext und anderenfalls aus einem separaten Thread. Folglich muss
für die Temporal Firewall im RT-SEC der wechselseitige Ausschluss sichergestellt werden.
Die momentane Implementierung sieht dafür die doppelte Auslegung des Event-Puers
vor. Einer der Puer steht jederzeit zum Lesen bereit, der andere zum Schreiben. Wurde
ein neues Event in letzteren Puer geschrieben, so werden die Aufgaben der Puer (Lese-
Puer und Schreib-Puer) in einem kurzen nicht unterbrechbaren Abschnitt getauscht, so
dass das neu geschriebene Event nun zum Lesen bereitsteht. Anders als bei der Verwendung
von Semaphoren oder anderen Locking-Konzepten entsteht hier beim Zugri auf den
Puer keine Verzögerung und kein Jitter.
In Spezialfällen kann durch die Abstimmung des Slot-Rahmenintervalls mit den Zeitparametern
des Subscriber-Tasks sichergestellt werden, dass es nie zu nebenläugen Zugrien
auf die Temporal Firewall kommt, so dass eine doppelte Auslegung des Puers nicht nötig
ist. Bei einer Erweiterung des Systems könnte diese Eigenschaft jedoch leicht verloren
gehen, wobei ein schwer zu ndender Race-Condition-Bug entsteht. Daher empehlt der
Autor, für RT-SECs immer die sichere doppelt gepuerte Temporal Firewall zu verwenden
5 .
4.2.2 Management Layer
Der Management Layer ist ein Sublayer des Event Layers. Er ist für Protokolle des
Middleware- und QoS-Managements verantwortlich. Für diese Arbeit ist hier das Reservierungsprotokoll
(Abschnitt 3.3) zu nennen. Das Protokoll nutzt die in FAMOUSO
vorhandenen Mechanismen indem es über einen Management-Kanal arbeitet, einen NRT-
Kanal der über ein spezielles reserviertes Subject erreichbar ist. Der Management Layer
übernimmt bei dem Reservierungsprotokoll die Rolle des Slaves. Dazu publiziert er
zyklisch die QoS-Anforderungen der Ereigniskanäle in Announcements- und Subscriptions-Events.
Vom Planer erhält er über den Kanal veröentlichte Events zum Setzen
des Reservierungszustands (z. B. Res). Beim Erhalt eines solchen Events informiert der
Management Layer den angesprochenen RT-PEC.
Die Announcements- und Subscriptions-Events werden auch für die Composability-
Checks zur Laufzeit (vgl. [SL09]) und die selektive Weiterleitung von Events an Gateways
verwendet. Werden weder diese beiden Features noch Echtzeitkanäle benötigt, kann
5
Die zu verwendende Temporal Firewall ist ein Kongurationsparameter der Echtzeitkanäle.
80

4.2 Umsetzung in FAMOUSO
der Management Layer in der FAMOUSO-Konguration abgeschaltet werden, um den
Ressourcenverbrauch in eingebetteten Systemen zu verringern.
4.2.3 Planer
Der Planer ist eine spezielle FAMOUSO-Applikation, die für die Koordination der Medienzugrie
in einem oder mehreren Netzwerken zuständig ist. Dafür wird in der Komponente
das in Abschnitt 3.2 vorgestellte Planungsverfahren eingesetzt. Als FAMOUSO-
Applikation ist der Planer leicht gegen eine andere Implementierung austauschbar, beispielsweise
gegen einen netzwerkübergreifenden Planer oder einen Planer, der einen statischen
vorberechneten Plan an die Knoten verteilt. Die Konguration des im Rahmen
dieser Arbeit implementierten Planers wird in Abschnitt 4.3.2 vorgestellt.
Der Planer abonniert den Management-Kanal und erhält auf diesem Weg die Announcements-
und Subscriptions-Events aller Knoten. Er ltert aus diesen Events all jene
Information, die für von ihm geplante Netze relevant sind. Wenn mehrere Planer aktiv
sind, gilt dies für jeden Planer. Momentan kann jedoch jedes Netz nur von einem Planer
verwaltet werden, so dass der Ausfall eines Planers nicht durch Komponentenredundanz
maskiert werden kann. Hierfür ist eine Erweiterung der Protokolle nötig, die Inkonsistenzen
zwischen replizierten Komponenten ausschlieÿt. Für bereits reservierte und verwendete
Kommunikationskanäle ist der Ausfall des Planers jedoch unkritisch, da dieser nach der
Etablierung der Kanäle nicht mehr benötigt wird.
Die aus den Announcements- und Subscriptions-Events gewonnenen Informationen
werden vom Planer gemäÿ des vorgestellten Reservierungsprotokolls und Planungsalgorithmus'
(siehe Abschnitt 3.3 bzw. 3.2) verarbeitet. Dabei veröentlicht er Events über den
Management-Kanal zum Setzen des Reservierungszustandes der angeforderten Echtzeitkommunikationskanäle.
Wie im Protokoll vorgesehen, kommuniziert er auÿerdem mit dem
Poll-Master, falls ein solcher verwendet wird.
4.2.4 Network Guard und Poll-Master
Für Netzwerke, über die Echtzeitkommunikation laufen soll, muss in die Konguration
des zugehörigen Netzwerk-Stacks ein Network Guard integriert werden. Die Aufgabe des
Network Guards ist es, die Einhaltung des Medienzugrisprotokolls (siehe Abschnitt 3.1)
sicherzustellen. Er ordnet sich unterhalb des für die Fragmentierung verantwortlichen Abstract
Network Layers ein. Die unten aufgeführten Überprüfungen werden somit nicht nur
für jedes Event, sondern für jedes zu versendende Paket durchgeführt 6 .
6
Bei der Fragmentierung werden Events, die nicht in einem Paket übertragbar sind, in mehrere Pakete
zerlegt.
81

4 Integration in FAMOUSO
RT-Kommunikation Bei der Echtzeitkommunikation ist der Network Guard eine Kontrollinstanz,
um das Netzwerkmedium vor der Ausbreitung von Zeitfehlern zu schützen,
wie sie etwa durch Fehler bei der Planung der Prozessornutzung oder durch falsche Dimensionierung
der lokalen Verzögerung ˆF entstehen können. Ein von einem RT-PEC stammendes
Paket wird nur dann zum Versenden an den Network Layer weitergereicht, wenn
der momentane Zeitpunkt innerhalb des Übertragungsstartfensters des Echtzeitkommunikationskanals
liegt (siehe Abschnitt 3.1.3). Das Senden sollte auÿerdem unterbunden
werden, wenn die Genauigkeit der Uhr (globale Zeit) nicht der Annahme gerecht wird, die
bei der Planung verwendet wurde.
NRT-Kommunikation Die zweite Aufgabe des Network Guards ist die zeitliche Einordnung
von NRT-Paketen in das TDMA-Schema des RT-Netzwerks gemäÿ Abschnitt 3.1.4.
Für Ethernet wird hier der Poll-Slave eingesetzt, das Gegenstück zum Poll-Master. Er
abonniert den Polling-Kanal und erhält so die dort vom Poll-Master veröentlichten Sendeberechtigungen.
Wird auf einem Best-Eort-Kanal ein Event veröentlicht, so wird für
jedes zu versendende Paket überprüft ob der Knoten gerade eine NRT-Sendeberechtigung
hat. Wenn ja, wird das Paket sofort an den Network Layer weitergereicht. Falls momentan
keine Sendeberechtigung vorliegt, wartet der Task in einer Schleife auf die Sendeberechtigung.
Dabei gibt er kooperativ die Kontrolle an den Task-Dispatcher ab 7 , der eventuell
fällige RT-Tasks abarbeitet. Kehrt der Aufruf des Task-Dispatchers zurück, so wird erneut
überprüft, ob eine Sendeberechtigung vorliegt.
Für CAN ist eine Implementierung vorgesehen, die NRT-Pakete ohne Warten an den Network
Layer weiterleitet, da NRT hier über die CAN-Prioritäten in das TDMA-Schema
integriert wird. Im Sinne der Erweiterbarkeit kann die zur Einordnung der NRT-Pakete
verwendete Lösung bei der Konguration des Netzwerk-Stacks angegeben werden (siehe
Abschnitt 4.3). So lassen sich auch alternative Strategien leicht in FAMOUSO integrieren.
Beispielsweise könnte Polling auch bei CAN eingesetzt werden, wenn der durch die
prioritätsbasierte Lösung erzeugte Jitter vermieden werden soll. Denkbar wäre auch, die
NRT-Nachrichten über einen für den Knoten reservierten TDMA-Slot abzuwickeln. Beide
Strategien lieÿen sich als Policy implementieren und in der Middleware-Konguration
verwenden, ohne dass Änderungen an bestehenden Komponenten nötig wären.
Poll-Master Der Poll-Master ist eine spezielle FAMOUSO-Anwendung, die den Austausch
von NRT-Nachrichten im Netzwerk koordiniert. In Abschnitt 3.1.4.1 wurde das
Polling-Konzept für Ethernet vorgestellt. Der Poll-Master erhält vom Planer die Information,
welche Slots zum Polling zur Verfügung stehen und vergibt in diesen Slots zeitlich begrenzte
Sendeberechtigungen an die ihm bekannten Knoten. Wie für den Planer wird auch
7
Das Publizieren auf einem Best-Eort-Kanal ist aus einem RT-Task nicht erlaubt, da dies den Task
unvorhersagbar verzögert.
82

4.2 Umsetzung in FAMOUSO
für den Poll-Master fehlerfreies Arbeiten angenommen. Die Erweiterung der Protokolle zur
Unterstützung eines Backup-Masters wird für eine weiterführende Arbeit vorgeschlagen.
4.2.5 Network Layer
Zur Realisierung der Echtzeitkommunikationskanäle sind Anpassungen in den Network
Layern nötig. Das zeitredundante Versenden von Paketen infolge einer bei einem RT-
PEC spezizierten Repetition wird hier implementiert. Hierdurch können spezielle Features
der verschiedenen Netzwerke ausgenutzt werden. Die Fehlersignalisierung bei CAN
kann genutzt werden, um dort nur im Fehlerfall eine erneute Übertragung einzuleiten, bzw.
die Häugkeit der automatischen Sendewiederholung auf Basis des Fehler-Interrupts auf
den entsprechenden Wert einzuschränken. Auf diese Weise steht bei CAN mehr Medienzeit
für NRT-Nachrichten zur Verfügung. Bei Ethernet gibt es keine derart eziente Rückmeldung
über den Erfolg einer Multicast-Nachrichtenübertragung. Daher wird hier das Paket
immer Rep + 1 Mal versendet, wenn Rep als Wiederholungsfaktor angegeben wurde. Um
auf der Empfängerseite die Duplikate zu ltern, werden die Pakete mit Sequenznummern
versehen, wobei wiederholte Pakete die gleiche Sequenznummer erhalten.
Eine weitere Anpassung betrit die Treiber für CAN-Netzwerk-Hardware. In Abschnitt
3.1.4.2 wurde erklärt, wie NRT-Nachrichten unter Ausnutzung der CAN-
Prioritäten in das TDMA-Schema integriert werden können. Hierfür muss jedoch garantiert
sein, dass eine RT-Nachricht lokal nie von einer NRT-Nachricht verzögert wird, auch nicht
auf der Ebene der Hardware. So muss ein RT-Frame auch versendet werden können,
während ein NRT-Frame noch auf seinen Versand wartet. Dies muss der Treiber sicherstellen.
Vom CAN-Network-Layer erhält er dafür jeweils die Information, ob es sich um
einen RT- oder NRT-Frame handelt. Je nach Möglichkeiten der Hardware bzw. der verwendeten
Schnittstelle zur Hardware sind verschiedene Implementierungen denkbar. Wenn in
einem CAN-Controller mehrere Sendepuer zur Verfügung stehen, kann ein Puer für RT-
Frames und einer für NRT-Frames reserviert werden. Ist nur ein Sendepuer vorhanden
und unterstützt die Schnittstelle das Abbrechen eines einmal veranlassten Sendevorgangs,
so kann ein noch nicht abgeschlossener Sendevorgang eines NRT-Frames abgebrochen
werden, um den Sendepuer für den RT-Frame frei zu machen. Nach dem Versenden
des RT-Frames kann der noch ausstehende, woanders zwischengespeicherte, NRT-Frame
erneut in den Sendepuer geschrieben werden. Ist auch dies nicht möglich, können zwei
CAN-Controller verwendet werden, die an das selbe Netz angeschlossen werden. Dabei
werden RT-Frames über den einen und NRT-Frames über den anderen CAN-Controller
versendet. Zum Empfang von Frames wird nur einer der beiden Controller genutzt.
83

4 Integration in FAMOUSO
1 namespace famouso {
2 class config {
3 typedef CAN : : avrCANARY can ;
4 typedef nl : : CAN : : ccp : : Client ccpClient ;
5 typedef nl : : CAN : : etagBP : : Client etagClient ;
6 typedef nl : : CANNL NL ;
7 typedef guard : : NetworkGuard<
8 NL ,
9 guard : : RT_WindowCheck ,
10 guard : : NRT_HandledByNL
11 > NG ;
12 typedef anl : : AbstractNetworkLayer ANL ;
13 public :
14 typedef el : : EventLayer<
15 ANL ,
16 el : : ml : : ManagementLayer
17 > EL ;
18 typedef api : : PublisherEventChannel PEC ;
19 typedef api : : SubscriberEventChannel SEC ;
20 } ;
21 }
4.3 Konguration
Abbildung 4.2: Beispielkonguration des Middleware-Stacks
4.3.1 Middleware-Stack
Der Middleware-Stack von FAMOUSO ist kongurierbar, so dass der Entwickler die Middleware
auf die Bedürfnisse der Anwendung und die genutzte Hardware zuschneiden kann.
Die Konguration erfolgt zur bzw. vor der Compile-Zeit, so dass der generierte Maschinencode
nur die benötigten Komponenten enthält. Dies ist insbesondere für eingebettete
Systeme mit stark beschränkten Ressourcen wichtig.
Der Quellcodeausschnitt in Abb. 4.2 zeigt eine Beispielkonguration. Die Konguration
des Middleware-Stacks erfolgt anhand von aufeinander aufbauenden Typ-Denitionen
in einer Klasse (hier config). Zeile 3 deniert den zu verwendenden CAN-Treiber.
Hier wird avrCANARY eingesetzt, der CAN-Treiber für AVR-Mikrocontroller mit CAN-
Unterstützung. In Zeile 4 und 5 wird die Rolle deniert, die der Knoten bei dem CANspezischen
Binde- bzw. Kongurationsprotokoll einnimmt. In der 6. Zeile wird der mit
den bisher denierten Policy-Klassen parametrisierte CAN-Network-Layer als Network-
Layer-Typ (NL) festgelegt. Auf diesem baut der Network Guard auf, da es sich hier um
84

4.3 Konguration
ein CAN-Netz handelt, über das Echtzeitkommunikation laufen soll. Neben dem Network-
Layer-Typ hat er zwei weitere Template-Parameter über die sich sein Verhalten kongurieren
lässt. In Zeile 9 wird die Policy angegeben, die der Network Guard für die Überprüfung
der Zeiteigenschaften der RT-Pakete verwenden soll. Mögliche Optionen sind
hier RT_WindowCheck und RT_NoWindowCheck. RT_WindowCheck verhält sich wie in Abschnitt
4.2.4 beschrieben, während RT_NoWindowCheck keine Überprüfungen durchführt.
Letzteres ist sinnvoll, um den Ressourcenverbrauch zu reduzieren, wenn ein Knoten an
einen RT-Netzwerk angeschlossen ist, aber selbst keine RT-Events publiziert. In Zeile 10
wird die Policy zur Handhabung von NRT-Paketen angegeben. NRT_HandledByNL bietet
hier das in Abschnitt 4.2.4 beschriebene Verhalten für CAN, NRT_PollSlave das für Ethernet.
An dieser Stelle können auch andere Strategien eingesetzt werden, indem hier eine
entsprechend implementierte Policy-Klasse angegeben wird. Für Netzwerke ohne Echtzeitkommunikationskanäle
ist kein Network Guard nötig. Dort würde bei der Denition des
Abstact Network Layers ANL (Zeile 12) der NL anstelle des Network Guards NG als Template-
Parameter angegeben werden, so dass dort der Abstract Network Layer direkt auf dem
Network Layer aufbauen würde. Die Denition des Event-Layer-Typs EL in Zeile 14 bis 17
komplettiert den Middleware-Stack. Als erster Template-Parameter wird hier, wie in allen
Denitionen, die darunter liegende Schicht angegeben. Der zweite Parameter (Zeile 16)
sorgt hier für das Einbinden des Management Layers. Wenn dieser nicht benötigt wird,
entfällt der zweite Parameter. In Zeile 18 und 19 werden die Typen PEC und SEC deniert,
die als Ereigniskanäle die Schnittstelle zur Anwendung darstellen und bei der Denition
der Echtzeitereigniskanal-Typen (siehe Abschnitt 4.1.2) benötigt werden.
Es ist auch weiterhin möglich, die Middleware komplett ohne die Unterstützung von
Echtzeitkanälen zu kongurieren, indem Network Guard und Management Layer ausgelassen
werden. Da beides neue Komponenten sind, die in früheren Kongurationen nicht
vorkommen, behalten ältere Kongurationen ihre Gültigkeit. Dort entsteht auÿerdem kein
zusätzlicher Ressourcenaufwand durch die Echtzeit-Erweiterungen, da sie bei diesen Kon-
gurationen nicht in den Maschinencode übernommen werden.
4.3.2 Planer und Poll-Master
Der Echtzeit-Netzwerk-Planer und der Poll-Master sind als Klassen-Template implementiert.
Sie erhalten als Template-Parameter die Ereigniskanal-Typen der Middleware-Stack-
Konguration. Diese werden benötigt, da intern der Management-Kanal abonniert wird
und auch darauf publiziert werden muss. Zur Verwendung des Planers muss eine Instanz
der Planer-Template-Klasse RTNetScheduler angelegt werden. Dem Planer müssen anschlieÿend
Netzwerke zugeordnet werden, für deren Echtzeitplanung dieser verantwortlich
sein soll. Dafür muss jeweils eine Instanz der Klasse NetworkSchedule angelegt werden,
die mit der Netzwerk-ID, den Planungsparametern und einem Verweis auf den Planer
initialisiert wird.
85

4 Integration in FAMOUSO
RTNetScheduler<
famouso : : config : : PEC ,
famouso : : config : : SEC> sched ;
NetworkSchedule can (
NetworkID ( 1 ) ,
CanNetworkTimingConfig (
250000 , // Bitrate in Bit pro Sekunde
50 , // Uhrengranularität g in µs
1000 , // Planungsgranularität G in µs
10000 , // ˆF in ns
10000) , // ˆB in ns
sched ) ;
Auf die Zeitparameter wurde in Kapitel 3 bereits ausführlich eingegangen. ˆF und ˆB sind
die maximalen lokalen Verzögerungen vor bzw. nach dem Test auf die Einhaltung des
Übertragungsstartfensters (siehe Abschnitt 3.2.2.1).
Der Poll-Master ist immer für genau ein Netzwerk zuständig. Daher werden die Parameter
des Netzwerks direkt an den Konstruktor der Template-Klasse PollMaster übergeben.
PollMaster<
famouso : : config : : PEC ,
famouso : : config : : SEC
> ethernet_poll_master (
NetworkID ( 2) ,
100 , // Bitrate in MBit pro Sekunde
1000 , // Planungsgranularität G in µs
10000 , // ˆB in ns
100000 , // ∆ M in ns
100000 , // ∆ K in ns
6 ) ; // negativer Exponent der maximalen Driftrate ρ max
// hier: ρ max = 10 −6
Die Master-Verzögerung ∆ M , die Slave-Verzögerung ∆ K und die maximale Driftrate ρ max
wurden bereits in Abschnitt 3.1.4.1 erläutert. Die übrigen Gröÿen müssen mit den beim
Planer für dieses Netzwerk angegebenen Werten übereinstimmen.
86

5 Evaluierung
In diesem Kapitel wird die in FAMOUSO integrierte Implementierung des erarbeiteten
Konzepts anhand einer beispielhaften verteilten Echtzeitanwendung evaluiert. Die in den
Abschnitten 5.1 bis 5.4 dargestellten Ergebnisse wurden anhand von Versuchen ermittelt,
die in einem dedizierten Netzwerk von fünf PCs 1 durchgeführt wurden. Die Rechner wurden
dabei unter Linux/Xenomai 2 betrieben. Abschnitt 5.5 zeigt auÿerdem die Eignung der
Implementierung für ressourcenbeschränkte eingebettete Systeme
5.1 Uhrensynchronisation
Eine wesentliche Voraussetzung für das Funktionieren des umgesetzten TDMA-Schemas
ist, dass den Knoten eine hinreichend genaue globale Zeit zur Verfügung steht. Dies
wird über ein Verfahren zur Uhrensynchronisation sichergestellt, über das jeder Knoten
die Genauigkeit seiner Uhr bezüglich einer Master-Uhr messen kann, um seine Uhr
entsprechend anzugleichen.
Da die Uhrensynchronisation nicht Schwerpunkt dieser Arbeit ist, wurde lediglich ein für
CAN entwickelter Algorithmus realisiert. Dieser wird auch bei der Echtzeitkommunikation
über Ethernet eingesetzt, so dass dort momentan ein zusätzliches CAN-Netzwerk zur
Uhrensynchronisation benötigt wird.
Implementierter Algorithmus Zur Messung der Uhrengenauigkeit wurde der in [GS94]
präsentierte Algorithmus umgesetzt. Dieser nutzt die Eigenschaft, dass das Senden und
Empfangen von CAN-Nachrichten gleichzeitig stattndet, da jedes Bit durch den Bus
propagiert wird, bevor mit dem Senden des nächsten Bits begonnen wird. Somit nden
der Sendeinterrupt und die zugehörigen Empfangsinterrupts auf den anderen Knoten zeitgleich
statt. Alle Knoten nehmen dabei gleichzeitig 3 einen Zeitstempel ihrer lokalen Uhr.
Der Master versendet seinen Zeitstempel in der nächsten Synchronisationsnachricht 4 . Die
1
Intel Core i7 mit 2,93 GHz im Single-Core-Modus, 3,4 GB RAM. Für die Ethernet-Latenzmessungen
wurden andere Rechner verwendet. Siehe hierzu Abschnitt 5.3.
2
Xenomai ist eine Echtzeiterweiterung für den Linux-Kernel. Sie ist auf http://www.xenomai.org/ als
Open-Source-Software erhältlich.
3
Es kann passieren, dass die Zeitstempel leicht zeitversetzt genommen werden. So z. B. wenn unterschiedliche
Hardware verwendet wird oder der Interrupt verzögert auslöst, beispielsweise wegen temporär
deaktivierten oder höher priorisierten Interrupts.
4
Die Zeitstempel werden als 64-Bit-Werte in der Einheit Nanosekunden verschickt.
87

5 Evaluierung
Slaves bestimmen dann die Dierenz zwischen diesem Zeitstempel der Master-Uhr und
dem zwischengespeicherten Zeitstempel ihrer lokalen Uhr, der zur gleichen Zeit aufgenommen
wurde. Sie erhalten so die Genauigkeit ihrer Uhr bezüglich der Master-Uhr, die sie
beim Empfang der vorletzten Synchronisationsnachricht hatten.
Zur Angleichung der Uhren wird in jedem Slave eine Drift-Korrektur durchgeführt. Da
durch die Software keine Frequenzveränderungen an der Hardware-Uhr möglich sind, betreibt
jeder Slave eine Software-Uhr für die globale Zeit. Die Umrechnung zwischen der
lokalen, durch die Hardware-Uhr bestimmten Zeit und der globalen Zeit erfolgt auf Basis
eines Osets sowie eines Drift-Wertes. Letzterer wird anhand der gemessenen Genauigkeiten
durch einen PI-Regler eingestellt. Die Drift-Korrektur hat im Gegensatz zur reinen
Oset-Korrektur den Vorteil, dass die Stetigkeit der Zeit erhalten bleibt, so dass ein Zeitpunkt
nicht mehrfach vorkommen kann. Auÿerdem wird auf Dauer eine sehr stabile Zeit
etabliert, so dass bei gleichen Genauigkeitsanforderungen deutlich weniger Synchronisationsnachrichten
je Zeiteinheit nötig sind. Allerdings braucht der PI-Regler beim Knotenstart
eine gewisse Zeit, bis die gewünschte Uhrengenauigkeit erreicht wird. Erst danach
kann mit der eigentlichen Programmausführung begonnen werden. Bei den in den folgenden
Abschnitten durchgeführten Messungen, bei denen der Master eine Synchronisationsnachricht
je Sekunde versendet, dauerte die initiale Synchronisation bis zum Erreichen
einer Genauigkeit von 10 Mikrosekunden zwischen 19 und 66 Sekunden.
Messung der Genauigkeit Um die Qualität der Uhrensynchronisation unter CPU- und
Netzwerklast einschätzen zu können, wurden die Uhrengenauigkeiten bei den in Abschnitt
5.3 durchgeführten Latenztests aufgezeichnet. Im Folgenden werden die Messergebnisse
vorgestellt, die an einem der Knoten bei einem Versuch mit NRT-Netzwerklast ermittelt
wurden. Die an den anderen Knoten und bei anderen Versuchen bestimmten Zahlenwerte
lagen immer in der gleichen Gröÿenordnung. Bei dem 6 Stunden andauernden Versuch
wurde mehr als 20.000 Mal gemessen, wie stark die Globalzeit-Uhr des Slaves von der
des Masters abweicht. Nach der initialen Sychronisierung bewegten sich alle Messungen im
Bereich zwischen -5.303 und 4.415 Nanosekunden. Damit liegt die schlechteste gemessene
absolute Genauigkeit α bei 5,3 Mikrosekunden. Bei der Planung wurde eine Uhrengranularität
g von 50 Mikrosekunden angenommen. Die gemessene Genauigkeit wird den
Annahmen der Planung folglich gerecht, da g > 2α erfüllt ist.
Die globale Zeit wird auch zur später behandelten Messung der Latenzen genutzt. Um die
dadurch entstehenden Messfehler einschätzen zu können, wurde aus den gemessenen Uhrengenauigkeiten
eine Wahrscheinlichkeitsverteilung angenähert. Entsprechend der linearen
Approximation der globalen Zeit in den Slaves wurde die Genauigkeit für den Zeitraum
zwischen zwei Messungen linear interpoliert. Zwischen zwei Messungen entsteht so eine
Gleichverteilung der Genauigkeiten. Überlagert man die Gleichverteilungen zwischen allen
Messungen, so erhält man eine angenäherte Wahrscheinlichkeitsverteilung der Uhrengenauigkeit.
Dazu wurden die Gleichverteilungen addiert, wobei jede Gleichverteilung mit dem
88

5.2 Einplanbarkeit
6 ·10−2 Genauigkeit in µs
Wahrscheinlichkeit
4
2
0
−2 0 2
Abbildung 5.1: Diskrete Wahrscheinlichkeitsverteilung der Uhrengenauigkeit
(Intervalle von je 50 Nanosekunden wurden zusammengefasst)
Anteil gewichtet wurde, den die Zeitdierenz zwischen den zwei Messungen bezüglich der
Gesamtzeit ausmacht. Zur Berechnung wurden jeweils Genauigkeiten in einem Intervall
von 50 Nanosekunden unter einer Wahrscheinlichkeit zusammengefasst. Die resultierende
diskrete Wahrscheinlichkeitsverteilung ist in Abb. 5.1 zu nden. Der Erwartungswert der
Verteilung liegt bei 2,32 Nanosekunden, die Standardabweichung bei ca. 475 Nanosekunden.
Die gemessen Latenzen übersteigen diese Werte um mehrere Gröÿenordnungen. Daher
hat der Fehler durch die Ungenauigkeit der Uhren nur einen vernachlässigbar kleinen
Einuss auf die ermittelten Wahrscheinlichkeitsverteilungen der Latenzen. Für die Bestimmung
der minimalen und maximalen Latenz ist jedoch jeder einzelne Messwert relevant.
Daher kann bei diesen Gröÿen durch die Ungenauigkeit der Uhrensynchronisation ein für
die Auswertung signikanter Fehler entstehen. Der Betrag des Fehlers entspricht schlimmstenfalls
der erreichten Präzision der Globalzeit, also dem maximal auftauchenden Oset
zweier beliebiger Uhren. Gemäÿ der bereits oben aufgeführten Messungen entspricht dieser
ca. 10.000 Nanosekunden. Da dieser Fehler sowohl bei der Messung der minimalen als auch
der maximalen Latenz entstehen kann, ergibt sich beim Jitter ein theoretischer maximaler
Messfehler von 20.000 Nanosekunden, also von bis zu 20 Mikrosekunden.
5.2 Einplanbarkeit
Vorstellung des Testszenarios Die Evaluierung der erreichten Echtzeitfähigkeit von
FAMOUSO orientiert sich an dem Anwendungsszenario eines autonomen mobilen Roboters
mit mehreren verteilten Komponenten. Sie beschränkt sich jedoch auf die Aspekte der
Kommunikation, ohne tatsächlich einen Roboter zu betreiben. Stattdessen versenden und
empfangen die Testprogramme Events, die einen Zeitstempel oder eine Sequenznummer
enthalten und bis zur gewünschten Gröÿe mit Null-Bytes aufgefüllt sind.
89

5 Evaluierung
Kanal p i in ms LB i in Byte
CAN Ethernet
"Sensor_1" 100 32 3.200
"Motor__1" 20 8 8
"Sensor_2" 10 4 16.000
"Motor__2" 20 8 8
"Not-Aus_" 50 0 0
"TimeSync" 1.000 8 8
Tabelle 5.1: QoS-Anforderungen an die Kommunikationskanäle: Periode p i
und maximale Event-Länge LB i für CAN und Ethernet
"Sensor_1"
"SeMoNode"
"CtrlNode"
"Motor__1"
"MasterNo"
"Sensor_2", "Not-Aus_"
"Oth1Node"
"Oth2Node"
"Motor__2"
Abbildung 5.2: Knoten und ihre Kommunikationsbeziehungen im Testszenario
Das Szenario sieht fünf Echtzeitkanäle vor. Diese haben die Subjects "Sensor_1",
"Sensor_2", "Motor__1", "Motor__2" und "Not-Aus_". Auf den Kanälen "Sensor_1"
und "Sensor_2" könnten Umgebungsinformationen bereitgestellt werden. Eine Steuerung
kann diese verarbeiten und über die Kanäle "Motor__1" und "Motor__2" zwei Aktoren
ansteuern. Über das Subject "Not-Aus_" wird ein Heart-Beat-Signal gesendet, dessen
Ausbleiben zum sofortigen Stoppen der Aktoren führt. Desweiteren ist ein Echtzeitkommunikationskanal
("TimeSync") für die Übertragung der Uhrensynchronisationsnachrichten
vorgesehen. Tabelle 5.1 zeigt die bei den Tests verwendeten QoS-Anforderungen der
Kanäle. Für CAN und Ethernet wurden zum Teil unterschiedliche Event-Gröÿen gewählt,
um trotz der sehr verschiedenen Bitraten eine ähnliche Netzwerklast zu erreichen.
Das Middleware-Konzept erlaubt es, die Publisher und Subscriber der Kanäle beliebig
auf verschiedene Knoten zu verteilen. Für die Evaluierung der Echtzeitkommunikation
wurde eine Zuordnung gewählt, die den Einuss der CPU-Planung minimal hält, da
letztere nicht Thema dieser Arbeit ist. Abb. 5.2 zeigt die Knoten mit ihren verwendeten
Knoten-IDs. Die zwischen den Knoten liegenden gerichteten Kanten veranschaulichen
90

5.2 Einplanbarkeit
die Kommunikationsbeziehung der Knoten. Sie verlaufen jeweils vom Publisher zum Subscriber
des bzw. der in der Kantenbeschriftung angegebenen Subjects. "Sensor_1" und
"Motor__1" werden zur Messung der Latenzen verwendet. Die anderen Kanäle dienen
bei den Latenzmessungen dazu, eine realistische Netzwerklast herzustellen. Um den Ein-
uss der CPU-Planung auf die Latenzmessungen gering zu halten, wurden die zwei Knoten
"SeMoNode" und "CtrlNode" ausschlieÿlich für jene Publisher und Subscriber genutzt, die
an der Latenzmessung beteiligt sind. Auf diese Weise ist sichergestellt, dass dort gemäÿ
der Annahme der Arbeit ausreichend CPU-Ressourcen zur Verfügung stehen. Mit den anderen
Kanälen wird zwischen den Knoten "Oth1Node" und "Oth2Node" kommuniziert. Bei
den Latenztests mit hoher NRT-Last ndet zwischen diesen beiden auch die Übertragung
von NRT-Events statt. Alle Knoten kommunizieren mit dem Knoten "MasterNo", der
die Uhrensynchronisationsnachrichten verschickt und für die Netzwerkplanung zuständig
ist.
Dynamische Planung und die Vergabe von Garantien Die zentrale Zielstellung der
Arbeit ist es, für jeden Echtzeitereigniskanal die Einhaltung von QoS-Anforderungen
garantieren zu können. Um dies zu ermöglichen wird die Nutzung des Netzwerkmediums
zur Laufzeit geplant. Für die Netzwerkplanung bei der Evaluierung wurden die im Quellcodebeispiel
in Abschnitt 4.3.2 angegeben Parameter verwendet. Das CAN-Netz wurde
mit einer Bitrate von 250 Kbit/s betrieben, das Ethernet mit 100 Mbit/s.
Zur Veranschaulichung werden im Folgenden Bildschirmfotos eingesetzt, die die Ausgaben
der Knoten bei den durchgeführten Tests zeigen. Um den Einuss der Ausgaben auf das
Zeitverhalten des Systems zu minimieren, wurde das in FAMOUSO verwendete Logging-
Framework [Sch10b] vom Autor um ein Echtzeit-Logging-Back-End erweitert. Dieses verursacht
im Echtzeitkontext nur minimale Verzögerungen, da die Ausgaben hier lediglich in
einen Ring-Puer kopiert werden. Ein NRT-Thread liest regelmäÿig den Inhalt des Puers
und schreibt ihn auf den Bildschirm oder in eine Datei.
Die in Tabelle 5.1 angegebenen QoS-Anforderungen wurden so gewählt, dass die benötigte
Medienzeit für jeden der Kommunikationskanäle reserviert werden kann. Abb. 5.3 zeigt
jeweils einen verkürzten Log des Planers für die CAN- und Ethernet-Konguration. Er
listet für jeden der angeforderten Echtzeitkommunikationskanäle die Periode und die Länge
der benötigten Slots auf. Auÿerdem wird jeweils ausgegeben, ob eine Reservierung des
Kanals möglich war. Im Erfolgsfall ist auch die Phasenverschiebung im TDMA-Zyklus
aufgeführt. Alle Gröÿen sind wie in Abschnitt 3.2.4 als Anzahl atomarer Slots (aSlots)
angegeben. Sowohl für CAN als auch für Ethernet konnten die Kommunikationskanäle
für die Subjects "TimeSync", "Sensor_1", "Motor__1", "Sensor_2", "Not-Aus_" und
"Motor__2" reserviert werden. Für die zugehörigen Echtzeitereigniskanäle ist folglich die
Einhaltung der angeforderten QoS garantiert.
91

5 Evaluierung
Abbildung 5.3: Reservierungen angeforderter Echtzeitkommunikationskanäle
für CAN (links) und Ethernet (rechts) in einem Ausschnitt des
Netzwerkplaner-Logs.
Für einen hier zusätzlich hinzugefügten Kanal mit dem Subject "Sensor_3" ist keine
Reservierung möglich. Für diesen wurde eine Periode von 5 Millisekunden und eine maximale
Event-Länge von 20 Byte bei CAN bzw. 500 Byte bei Ethernet angefordert. Bei CAN
entspricht die zu reservierende Periode der Länge der benötigten Slots, so dass für den
Kommunikationskanal die gesamte Medienzeit reserviert werden müsste. Da bereits andere
Kanäle etabliert sind, sind die Anforderungen hier nicht erfüllbar. Bei Ethernet ist
die Periode von 5 atomaren Slots das Problem, denn die Kanäle "TimeSync", "Sensor_2",
"Not-Aus_" und "Motor__2" belegen bereits 6 aufeinander folgende atomare Slots mit
den Phasenverschiebungen 0 bis 5. Somit kann die für "Sensor_3" geforderte Periodizität
in diesem Bereich des TDMA-Zyklus' nicht erfüllt werden. Da die Zusicherung der angeforderten
QoS auf beiden Netzen nicht möglich ist, schlagen beide Reservierungen fehl.
In der Folge wird die Kommunikation auf diesen Kanälen komplett unterbunden und die
Anwendung wird über den Fehler informiert.
Damit ist ein Ziel der Arbeit erfüllt, denn die Kommunikation kommt nur dann zustande,
wenn die Einhaltung der QoS-Anforderungen garantiert werden kann. Falls eine Zusicherung
nicht möglich ist, wird dies als Fehler erkannt. Auf diese Weise wird die Software-
Entwicklung erleichtert, da das System mögliche Probleme selbst erkennen und melden
kann. Diese Meldung geht auch an die kommunizierenden Anwendungen, so dass auch
während des regulären Betriebs angemessen auf einen Fehler reagiert werden kann, beispielsweise
durch das Einnehmen eines sicheren Zustands. Dass die zugesicherten QoS-
Anforderungen tatsächlich eingehalten werden, wird im folgenden Abschnitt gezeigt.
92

5.3 Latenz und Jitter
(A)
r pub R i t snd t rcv D i r sub
Pub.-Task
Deliv.-Task
t
(B)
NRT
RT i
(C)
Komm.-Latenz
Ende-zu-Ende-Latenz
Interrupt
Notify
Abbildung 5.4: CPU- und Netzwerknutzung für ein RT-Event: (A) Das
Event wird auf dem Knoten des Publishers im Publisher-Task veröentlicht
und im Deliver-Task versendet. Letzterer ist mit dem Kommunikationskanal
(B) synchronisiert. Der Empfang des übertragenen Events RT i löst beim
Empfänger-Knoten (C) einen Interrupt aus. Bei der nächsten eingeplanten
Notizierung wird das Event an den Subscriber ausgeliefert.
Kanal
Zeitparameter in ms
p i r pub R i D i r sub L E
"Sensor_1" 100 20 20,2 40,1 50 30
"Motor__1" 20 10,1 10,2 20 20,1 10
Tabelle 5.2: Abstimmung der CPU- und Netzwerkplanung: Über die Angabe
der Startzeit des periodischen Publisher-Tasks (r pub ) und der periodischen
Notizierung (r sub ) sowie des Slot-Rahmenintervalls (R i , D i ) lässt sich die
Ende-zu-Ende-Latenz L E vorherbestimmen.
5.3 Latenz und Jitter
Um die geforderte QoS durchsetzen zu können, müssen die Events innerhalb der für die
Kommunikationskanäle reservierten Slots übertragen werden. Dafür muss die durch Kommunikation
entstehende Latenz entsprechend beschränkt sein. Für viele Anwendungen ist
auÿerdem ein minimaler Jitter gewünscht, also eine möglichst geringe Dierenz von der
maximal und der minimal auftretenden Latenz. Zur Einschätzung, inwieweit diese Ziele
erreicht wurden, wurden verschiedene Versuche durchgeführt. Für jeden der Versuche wurden
6 Stunden lang Latenzen gemessen und aufgezeichnet. Für das Subject "Sensor_1"
sind dabei jeweils ca. 215.000 Messwerte entstanden. Für "Motor__1" waren es aufgrund
der niedrigeren Periode etwa 1,08 Millionen Werte.
Es wurden die zwei Gröÿen Kommunikationslatenz und Ende-zu-Ende-Latenz untersucht.
Abb. 5.4 veranschaulicht, wie die Begrie zu verstehen sind. Die Kommunikationslatenz
wird innerhalb der Middleware gemessen. Dafür wird die Startzeit t snd des Deliver-
Tasks mit dem Event versendet. Ohne Zeitfehler entspricht t snd dem Beginn des Slots
93

5 Evaluierung
des Kommunikationskanals. Nach dem Ende der Übertragung des Events wird auf dem
Empfängerknoten ein Empfangsinterrupt ausgelöst. Dieser sorgt dafür, dass ein auf Nachrichten
wartender, hoch priorisierter Echtzeit-Thread weiter läuft und den Zeitstempel
t rcv nimmt. Die Dierenz von t rcv und t snd ist die Kommunikationslatenz L K . Versuchsbedingt
sind in L K auch Verzögerungen enthalten, die durch die Hardware und Software des
Sende- und Empfangsrechners entstehen 5 . Der durch diese lokalen Verzögerungen verursachte
Jitter sollte durch die Verwendung von echtzeitfähiger Systemsoftware gering sein.
Eine exakte Messung dieser Gröÿe ist jedoch sehr aufwendig und konnte daher im zeitlichen
Rahmen dieser Diplomarbeit nicht durchgeführt werden. Somit kann ihr Einuss bei der
Auswertung lediglich abgeschätzt werden. Bei CAN gibt es einen weiteren Aspekt, der
deutlich gröÿeren Einuss auf L K hat. Werden dort NRT-Nachrichten verschickt, so können
diese für RT-Nachrichten das Erhalten des Medienzugris verzögern. Der hierdurch
entstehende Jitter wird weiter unten durch den Vergleich der Ergebnisse verschiedener
Versuche eingeschätzt.
Neben der Kommunikationslatenz wird auch die Ende-zu-Ende-Latenz L E gemessen. Hierbei
handelt es sich um die Zeit, die zwischen der Veröentlichung eines Events durch
den Publisher und dem Aufruf des Notizierungsrückrufs beim Subscriber vergeht. Zur
Bestimmung dieser Gröÿe nimmt der Test-Publisher zu Beginn seines Tasks einen Zeitstempel
und veröentlicht diesen als Teil des Events. Der Subscriber nimmt beim Start
des periodisch aufgerufenen Notizierungsrückrufs ebenfalls einen Zeitstempel und berechnet
die Dierenz zum Wert aus dem erhaltenen Event. Diese Dierenz ist die Ende-zu-
Ende-Latenz. Sie lässt sich a-priori festlegen. Dafür müssen die Startzeitpunkte für den
Publisher-Task (r pub ) und die Notizierung (r sub ) mit dem Slot-Rahmenintervall (R i , D i )
abgestimmt werden. Gilt r pub < R i und D i < r sub , so wird das veröentlichte Event
vor der nächsten Notizierung zum Subscriber-Knoten übertragen. Dann ergibt sich eine
Ende-zu-Ende-Latenz von L E = r sub − r pub . Für Kanäle, die an den Latenzmessungen
beteiligt sind, wurden die Parameter entsprechend abgestimmt. In Tabelle 5.2 sind die
Werte aufgeführt.
Die Latenzmesswerte wurden jeweils mit einer Genauigkeit von einer Mikrosekunde
aufgenommen. Für jeden der Messwerte wurde die absolute Häugkeit des Auftretens
gezählt und gespeichert. Aufgrund der hohen Anzahl an Messwerten lässt sich über die
Verteilung der absoluten Häugkeiten jeweils eine diskrete Wahrscheinlichkeitsverteilung
annähern.
5
Die Middleware, in dessen Kontext die Messungen durchgeführt werden, läuft als Echtzeitanwendung im
User-Space von Linux/Xenomai. Zwar handelt es sich hierbei um ein Echtzeitbetriebssystem, jedoch
entstehen auch in diesem zusätzliche Verzögerungen durch Kontextwechsel und durch Code zur Geräte-
Abstraktion und -Ansteuerung.
94

5.3 Latenz und Jitter
5.3.1 Kommunikationslatenz und -jitter bei CAN
Zur Messung der Kommunikationslatenz L K wurden im CAN-Netzwerk drei Versuche
durchgeführt. Im ersten Versuch wurden ausschlieÿlich RT-Kanäle verwendet, so dass keine
NRT-Last auftritt 6 . Der zweite Versuch misst die Latenzen der Echtzeitkommunikation
bei maximaler NRT-Last. Im Vergleich mit dem ersten Versuch veranschaulicht dieser den
Einuss von NRT-Last auf die Zeiteigenschaften der RT-Kommunikation. Im dritten Versuch
kommunizieren auch alle Kanäle mit Echtzeitanforderungen über NRT-Kanäle. Die
Ergebnisse dieses Versuchs verdeutlichen, wie die Latenzen bei hoher NRT-Last aussehen
können, wenn keine Echtzeitkommunikationskanäle verwendet werden. In Abb. 5.5 sind die
ermittelten Wahrscheinlichkeitsverteilungen für die Latenzen ohne NRT-Last und bei hoher
NRT-Last dargestellt. Die Tabelle 5.3 listet die Ergebnisse aller Versuche in konkreten
Zahlenwerten auf.
Auf dem Kanal "Motor__1" wurden jeweils 8 Byte, also ein CAN-Frame, übertragen. Die
Zeit zur Übertragung eines Frames auf dem Medium lässt sich über die in Abschnitt 3.2.2.3
angegebenen Gleichungen bestimmen. Sie liegt zwischen M j min = (8LBj i + 67)τ bit (kein
Bit-Stung nötig) und M j max = (10LB j i + 111)τ bit (Worst-Case-Bitstung und Fehlersignalisierung).
Mit τ bit = 4 µs ergibt sich somit für "Motor__1" eine Übertragungszeit zwischen
524 µs und 764 µs. Für den Versuch ohne NRT-Last liegen erwartungsgemäÿ alle
gemessenen Latenzen in diesem Bereich. Die maximale Latenz liegt mit 630 µs sogar deutlich
unter dem möglichen Worst-Case, obwohl in der Kommunikationslatenz zusätzlich
auf den Knoten entstandene Verzögerungen enthalten sind. Bei hoher NRT-Last erhöht
sich die maximale Latenz auf ca. zwei mittlere Frame-Längen. Der Grund hierfür ist,
dass der Medienzugri für das Versenden einer RT-Nachricht durch eine laufende NRT-
Übertragung verzögert werden kann. Nach dieser greift jedoch die prioritätsbasierte Arbitrierung,
so dass jede RT-Nachricht maximal um eine Nachrichtenlänge verzögert wird.
Da die minimale Latenz in etwa gleich bleibt, erhöht sich der Jitter durch die NRT-Last
um etwa eine Frame-Länge. Im Versuch ohne NRT ist die entscheidende Einussgröÿe
auf die Latenzverteilung der Jitter, der durch das Bit-Stung bzw. auf den beteiligten
Rechnern entsteht. In Abb. 5.5(c) ist ersichtlich, dass diese nicht mehr die bestimmenden
Gröÿen sind, wenn NRT-Last hinzukommt. Stattdessen wird die Verteilung der Latenzen
dort im Wesentlichen durch die zeitliche Charakteristik der NRT-Last vorgegeben. Im
Versuch wurde ein Knoten allein dafür verwendet, permanent NRT-Events zu versenden.
Hierfür wurde nicht explizit eine Periode gewählt. Dennoch stellt sich durch den Determinismus
der am Netz beteiligten Echtzeit-Rechner eine periodische Netzwerknutzung ein.
Diese äuÿert sich in der abgebildeten Verteilung durch die wellenartigen Strukturen. Die
Frequenz und Amplitude dieser Wellen ist stark abhängig von der Periodizität und der
6
Das Reservierungsprotokoll, das über NRT-Events arbeitet, wurde hier nicht zyklisch ausgeführt, so
dass nur für Planänderungen NRT-Last entsteht. Mit den Messungen wurde erst nach dem initialen
Kanalaufbau begonnen.
95

5 Evaluierung
Wahrscheinlichkeit
6
4
2
Wahrscheinlichkeit
6
4
2
0
0
8 ·10−2 L K in µs
580 590 600 610 620
·10 −2 L K in µs
2.840 2.850 2.860 2.870 2.880
(a) "Motor__1" ohne NRT-Last
(b) "Sensor_1" ohne NRT-Last
·10 −3 L K in µs
·10 −3 L K in µs
4
3
Wahrscheinlichkeit
2
Wahrscheinlichkeit
2
1
0
600 800 1.000
0
3.000 3.200 3.400
(c) "Motor__1" bei hoher NRT-Last
(d) "Sensor_1" bei hoher NRT-Last
Abbildung 5.5: Kommunikationslatenzen bei CAN als diskrete Wahrscheinlichkeitsverteilung
(Intervalle von je 1 µs sind in einer Wahrscheinlichkeit
zusammengefasst)
Kanal Kommunikationslatenzen in µs
(Versuch) min(L K ) max(L K ) Jitter E(L K ) σ(L K )
"Motor__1"
(ohne NRT-Last) 587 630 43 599 6
(hohe NRT-Last) 574 1.175 601 877 164
(als NRT-Kanal) 589 3.413 2.824 1.112 575
"Sensor_1"
(ohne NRT-Last) 2.828 2.882 54 2.852 6
(hohe NRT-Last) 2.835 4.509 1.674 3.130 169
(als NRT-Kanal) 2.872 888.436 885.564 213.070 102.310
Tabelle 5.3: Kommunikationslatenzen bei CAN im Vergleich. Es werden
die minimale und maximale gemessene Latenz, der daraus errechnete Jitter,
sowie der Erwartungswert und die Standardabweichung der Wahrscheinlichkeitsverteilungen
angegeben.
96

5.3 Latenz und Jitter
Phasenverschiebung der NRT-Last. Das aufmodulierte hochfrequente Rauschen entsteht
durch den Jitter, der durch das Bit-Stung und die lokalen Aktivitäten verursacht wird.
Für den Kanal "Sensor_1" sind qualitativ ähnliche Resultate zu verzeichnen, wie
für "Motor__1". Sie unterscheiden sich jedoch deutlich in den Zahlenwerten, da über
"Sensor_1" Events mit einer Länge von 32 Byte versendet werden. Diese werden im
Middleware-Stack unter Verwendung des für FAMOUSO entwickelten Fragmentierungsprotokolls
AFP (vgl. [SWLK11]) in 5 CAN-Nachrichten zerlegt. Sie enthalten neben der
eigentlichen Nutzlast auch Information für das Zusammenfügen der Fragmente beim
Empfänger. Vier der Fragmente haben eine Länge von 8 Byte. In dem 5. Fragment werden
5 Byte transportiert. Unter Anwendung der oben aufgeführten Formeln ergibt sich für die
fünf CAN-Nachrichten des Events eine zu erwartende Übertragungsdauer zwischen 2.524
und 3.700 µs. Ohne NRT-Last liegen alle gemessenen Kommunikationslatenzen in diesem
Bereich und der entstehende Jitter ist ähnlich gering wie bei "Motor__1". Beim Versuch
mit hoher NRT-Last wurde eine maximale Latenz von ca. 4.500 µs gemessen. Auch hier ist
dieser Anstieg dadurch zu erklären, dass RT-Frames durch die bereits laufende Übertragung
eines NRT-Frames verzögert werden können. Dabei kann jeder RT-Frame nur um eine
Frame-Länge verzögert werden. Da hier jedoch fünf Frames übertragen werden, können
bis zu fünf Verzögerungen auftreten. Das hier gemessene Maximum deutet jedoch nur auf
drei verzögerte RT-Frames hin. In der Verteilung in Abbildung 5.5(d) wird deutlich, dass
die überwiegende Anzahl der Messungen Latenzen im Bereich zwischen 2.840 und 3.420 µs
ergeben haben, was für die Verzögerung lediglich eines RT-Frames spricht. Hierbei handelt
es sich in der Regel um den jeweils ersten RT-Frame im Slot, da das Medium zuvor
ungenutzt und somit für den Versand von NRT-Frames oen ist. Dass zwischen mehreren
Fragmenten eines RT-Events ein NRT-Frame versendet wird, ist deutlich unwahrscheinlicher.
Das liegt daran, dass der RT-Sender hierfür nach dem Versenden eines RT-Fragments
eine Arbitrierung verpassen muss. Aufgrund der Leistungsfähigkeit der Versuchsrechner
und der geringen Bitrate von CAN kam dies sehr selten vor.
Der bereits oben ausgewertete Versuch mit hoher NRT-Last wurde zum Vergleich noch
einmal ohne die Verwendung der Echtzeitkommunikationskanäle durchgeführt, also mit
den Best-Eort-Kanälen von FAMOUSO. In Tabelle 5.3 sind die zugehörigen Ergebnisse
unter der Versuchsbezeichnung als NRT-Kanal aufgeführt. Bei den Best-Eort-Kanälen
werden die IDs von CAN nicht zur Priorisierung von Nachrichten verwendet. CAN nutzt
die IDs trotzdem zur Auösung von Zugriskonikten. Somit erfolgt die tatsächliche Priorisierung
nach Kriterien, die eigentlich nicht für diese Aufgabe bestimmt, aber in der
ID codiert sind. Dies ist primär die Information, ob es sich um ein Fragment oder ein
vollständiges Event handelt. Letztere werden bevorzugt. Sekundär hängt die Priorisierung
vom Knoten ab, da in den nächsten niedrigwertigeren Bits der Absender codiert ist. Die
Priorisierung der Knoten wird dabei durch das CAN-Kongurationsprotokoll festgelegt,
wobei in der momentanen Realisierung im Wesentlichen die Startreihenfolge der Knoten
ausschlaggebend ist. Wenn das Fragmentierungsbit und der Absender übereinstimmen,
97

5 Evaluierung
entscheidet das Subject über die Priorisierung. Die entsprechende Codierung in der ID
wird durch das CAN-Bindeprotokoll zugeteilt, wobei hier die Reihenfolge der jeweils ersten
Announcements bzw. Subscriptions der Subjects ausschlaggebend ist. An den Messwerten
wird deutlich, dass der Publisher von "Motor__1" höher priorisiert ist als der von
"Sensor_1". Er ist jedoch nicht der am höchsten priorisierte Publisher, da seine maximale
Latenz deutlich über einer Frame-Länge liegt und er somit Arbitrierungen verloren
haben muss. Während die gemessene Worst-Case-Latenz bei "Motor__1" lediglich beim
etwa dreifachen des Versuchs mit Echtzeitkanälen liegt, beträgt diese beim niedriger priorisierten
"Sensor_1" schon fast 0,9 Sekunden. Theoretisch ist die maximale Latenz jedoch
für beide Kanäle unbeschränkt, wenn das Medium durch den oder die höher priorisierten
Kanäle komplett ausgelastet wird.
Die praktischen Versuche haben deutlich gemacht, dass die implementierten Echtzeitkommunikationskanäle,
anders als Best-Eort-Kanäle, zur Durchsetzung von QoS-
Anforderungen geeignet sind. Sowohl bei "Motor__1" als auch bei "Sensor_1" lagen
alle Latenzen deutlich unter der reservierten Slotlänge. Dies bestätigt, dass die bei der
Planung getroenen Annahmen hinreichend sind. In Kombination mit der Zeitfehlerüberprüfung
durch den Network Guard ist somit sichergestellt, dass die Events innerhalb der
reservierten Slots übertragen werden. Der erreichte Jitter ist bei reiner RT-Last gering.
Um den Jitter bei NRT-Last ebenso niedrig zu halten, könnte wie bei Ethernet ein Polling-
Mechanismus eingesetzt werden, jedoch auf Kosten des möglichen NRT-Durchsatzes.
5.3.2 Kommunikationslatenz und -jitter bei Ethernet
Für die Versuche mit Ethernet wurde RTnet 7 verwendet, ein echtzeitfähiger Netzwerk-
Stack für Linux/Xenomai. Dabei wurde der in Abschnitt 2.4.4 beschriebene interne MAC-
Mechanismus deaktiviert, weil dessen Aufgabe von den Echtzeitkommunikationskanälen
von FAMOUSO übernommen wird, die hier getestet werden sollen. Das für die CAN-
Versuche genutzte, bereits vorhandene Testsystem basiert komplett auf der Ausnutzung
des Ethernet-Netzwerks 8 . Da die Versuche jedoch nur auf einem dedizierten Netzwerk
möglich sind, wurde sämtliche benötigte Software inklusive Betriebssystem auf USB-Sticks
installiert, um die Rechner von diesen zu booten. Es zeigte sich dann jedoch, dass die in den
Rechnern vorhandene Netzwerk-Hardware noch nicht von RTnet unterstützt wird. Letztendlich
wurden für die Ethernet-Versuche andere Rechner verwendet 9 . Der Aufwand für
die Einrichtung der Testsysteme hat sich als deutlich gröÿer herausgestellt, als zunächst
erwartet. Daher waren im vorgegebenen Zeitrahmen nur Versuche mit zwei über Ethernet
kommunizierenden Knoten möglich. Als Uhren-Master und Netzwerkplaner wurde ein
7
RTnet ist unter http://rtnet.org/ als Open-Source-Software verfügbar.
8
Linux/Xenomai wird auf diesen Rechnern über das Netzwerk gebootet und alle Dateizugrie laufen über
NFS (Network File System), wobei jeweils Kommunikation mit einem Server nötig ist.
9
AMD Athlon 64, 1,8 GHz, 1 GB RAM
98

5.3 Latenz und Jitter
0,4
0,3
Wahrscheinlichkeit
0,3
0,2
0,1
Wahrscheinlichkeit
0,2
0,1
0
0
30 40 50 60 70 80
300 310 320 330 340
L K in µs
L K in µs
(a) "Motor__1"
(b) "Sensor_1"
Abbildung 5.6: Kommunikationslatenzen bei Ethernet als diskrete
Wahrscheinlichkeitsverteilung (Intervalle von je 1 µs sind in einer Wahrscheinlichkeit
zusammengefasst)
Kanal Kommunikationslatenzen in µs
min(L K ) max(L K ) Jitter E(L K ) σ(L K )
"Motor__1" 34 81 47 41 4
"Sensor_1" 303 342 39 310 4
Tabelle 5.4: Kommunikationslatenzen bei Ethernet. Es werden die minimale
und maximale gemessene Latenz, der daraus errechnete Jitter, sowie der Erwartungswert
und die Standardabweichung der Wahrscheinlichkeitsverteilungen
angegeben.
dritter Knoten eingesetzt, der über ein zusätzlich angeschlossenes CAN-Netzwerk mit den
anderen verbunden wurde.
Die Ergebnisse eines Versuchs zur Messung der Kommunikationslatenz sind in Abb. 5.6
als diskrete Wahrscheinlichkeitsverteilungen dargestellt. In der Tabelle 5.4 sind die zugehörigen
Zahlenwerte aufgeführt. Die Dauer zum Versenden eines Ethernet-Frames über
das Medium lässt sich über die in Abschnitt 3.2.2.4 gegebenen Formeln berechnen. Mit
τ bit = 0,01 µs liegt sie zwischen 6,72 µs (bei weniger als 47 Byte Nutzdaten) und 123,04 µs
(bei 1.500 Byte Nutzdaten). Für "Motor__1", wo in jedem Event lediglich 8 Byte übertragen
werden, liegt die minimale mögliche Latenz also bei 6,72 µs. Als Kommunikationslatenz
wurden jedoch immer deutlich höhere Werte gemessen, weil diese zusätzlich die lokalen
Verzögerungen im Publisher- und Subscriber-Knoten enthalten. Auch wenn die gemessenen
Latenzen deutlich über 6,72 µs liegen, sind die Echtzeitgarantien nicht gefährdet,
weil die lokalen Verzögerungen bei der Netzwerkplanung berücksichtigt werden. Durch
die lokalen Verzögerungen entsteht auch der Jitter von 47 µs. Der überwiegende Teil der
Messungen liegt jedoch nah am Erwartungswert von ca. 41 µs, wie auch in Abb. 5.6(a)
zu erkennen ist. Die sehr achen lokalen Maxima bei 48, 52 und 59 µs sind durch
zusätzliche lokale Verzögerungen verursacht, die nicht in jeder Periode auftauchen. So
99

5 Evaluierung
hat beispielsweise die Abfolge der ausgeführten Threads, auch der NRT-Threads, Einuss
auf die Invalidierung von Speicher-Cache-Zeilen des x86-Prozessors. So nden bei einigen
Thread-Abfolgen deutlich mehr Cache-Misses statt, wodurch in diesen Fällen die lokale
Latenz ansteigt. Im Versuchsaufbau wurde keine hohe NRT-Prozessorlast erzeugt. Damit
waren vor allem die Echtzeit-Threads und der Xenomai-Kernel aktiv, die periodisch bzw.
zumindest gemäÿ eines zeitlichen Determinismus' ausgeführt wurden. Aus diesem Grund
können sich auch durch die Nutzungseekte von Cache-Speicher, die zeitlich schwer vorhersagbar
sind, Häufungen in der Latenzverteilung entstehen.
Über den Kanal "Sensor_1" werden Events mit 3.200 Byte Nutzdaten übertragen. Diese
werden in jeweils drei Fragmente zerlegt. Das Fragmentierungsprotokoll und das Ethernet-
Protokoll der Middleware belegen je Fragment 17 Byte für Header-Informationen. Für die
ersten zwei Events nutzt AFP die volle MTU von 1.500 Byte aus, so dass in jedem der
beiden Fragmente jeweils 1.483 Byte Nutzdaten übertragen werden. Für das letzte Fragment
bleiben somit noch 234 Byte der Nutzdaten übrig, so dass sich für dieses Fragment
LB j i
= 251 Byte ergibt. Durch Einsetzen in die Gleichung aus Abschnitt 3.2.2.4 erhält man
für das letzte Fragment eine Versendedauer von 23,12 µs. Für die ersten zwei Fragmente
fallen jeweils 123,04 µs an, so dass für das Versenden des Event eine reine Medienbelegungszeit
von 23, 12 + 2 · 123, 04 = 269, 2 µs nötig ist. Auch hier liegen die gemessenen
Kommunikationslatenzen im Mittel 310 µs deutlich über diesem Wert, weil die lokalen
Verzögerungen beim Publisher- und Subscriber-Knoten enthalten sind. Der gemessene Jitter
ist kleiner als bei "Motor__1". Dies überrascht zunächst, da beim Versenden mehrerer
Fragmente, absolut gesehen, mehr lokale Aktivitäten auf den Rechnern nötig sind, die
sich bei Ethernet für den Jitter verantwortlich zeigen. Der Unterschied liegt jedoch im Bereich
der Präzision der Uhren, so dass hier vermutlich ein Messfehler vorliegt. Dieser kann
durch ein zeitweilig hohes Oset der an der Latenzmessung beteiligten Uhren entstehen.
Abgesehen vom Erwartungswert hat die Latenzverteilung von "Sensor_1" eine ähnliche
Charakteristik wie die von "Motor__1". Das lokale Maximum bei 320 µs kann mit lokalen
Aktivitäten begründet werden, die nicht in allen Perioden stattnden.
Da alle gemessenen Latenzen unterhalb der für die Kanäle eingeplanten Slotlänge liegen,
bestätigt der Versuch die Einhaltung der Garantien bei den Echtzeitkommunikationskanälen
für Ethernet.
5.3.3 Ende-zu-Ende-Latenz und -Jitter
Im CAN-Testsetup wurde ein Versuch zur Messung der Ende-zu-Ende-Latenz durchgeführt,
um zu zeigen, inwieweit sich diese, für die Anwendung unmittelbar wichtige Gröÿe,
vorherbestimmen lässt. Die Ergebnisse sind in der Tabelle 5.5 zu nden. Nach der Abstimmung
von Prozessor- und Netzwerkplanung gemäÿ Tabelle 5.2 ist für "Motor__1" eine
Ende-zu-Ende-Latenz von 10.000 µs zu erwarten. Der Mittelwert aller Messungen liegt
mit 10.000,4 µs nahe an diesem Wert. Auch für "Sensor_1" wird im Mittel nahezu die
100

5.4 Verlässlichkeit
Kanal Ende-zu-Ende-Latenzen in µs
min(L E ) max(L E ) Jitter E(L E ) σ(L E )
"Motor__1" 9.972 10.025 53 10.000,4 1,3
"Sensor_1" 29.975 30.021 46 30.000,7 1,3
Tabelle 5.5: Ende-zu-Ende-Latenzen. Es werden die minimale und maximale
gemessene Latenz, der daraus errechnete Jitter, sowie der Erwartungswert und
die Standardabweichung der Wahrscheinlichkeitsverteilungen angegeben.
gewünschte Ende-zu-Ende-Latenz von 30.000 µs erreicht. 10 Der ermittelte Jitter liegt bei
ca. 50 µs. Die Kommunikation hat daran keinen Anteil, da sie zum Zeitpunkt r sub bereits
abgeschlossen ist. Stattdessen ist der Jitter hier komplett auf die Prozessorzuteilung zurückzuführen.
Unter Linux/Xenomai werden die Echtzeit-Threads prioritätsbasiert eingeplant.
Eine hohe Abweichung zwischen dem geplanten und dem tatsächlichen Start- bzw. Fortsetzungszeitpunkt
eines Threads kann zustande kommen, wenn ein höher oder gleich priorisierter
Thread den Prozessor für sich in Anspruch nimmt. Aber selbst für den am höchsten
priorisierten Thread entsteht ein nicht unerheblich Jitter. Auf dem Versuchssystem lieÿ
sich dieser mit dem zu Xenomai gehörenden Testprogramm latency auf ca. 30 µs beziern.
Und auch die Ungenauigkeit der Uhrensynchronisation kann nach den in Abschnitt 5.1 gemessenen
Werten im Worst-Case einen Jitter von ca. 10 µs beitragen. Trotz des relativ
hohen insgesamt gemessenen Jitters von ca. 50 µs liegt der Groÿteil der gemessenen Latenzen
sehr nah am Erwartungswert, wie an der niedrigen Standardabweichung von 1,3 µs zu
erkennen ist.
Der Versuch veranschaulicht, dass die Ende-zu-Ende-Latenz vom Anwendungsentwickler
vorherbestimmt werden kann. Es wird jedoch auch deutlich, dass es stark von der Ausführungsumgebung
und der Uhrensynchronisation abhängt, wie genau dies in der Praxis
eingehalten werden kann.
5.4 Verlässlichkeit
In der Implementierung wurden verschiedene Mechanismen umgesetzt, um Fehler zu erkennen
und zu behandeln bzw. der Anwendung die Möglichkeit zur Behandlung zu geben. Ziel
dabei ist es, Fehler tolerieren zu können, ohne dass es zum Funktionsausfall des Gesamtsystems
kommt. Zur Veranschaulichung einiger Fehlerarten wurde die Testanwendung so
modiziert, dass die Fehler absichtlich herbeigeführt werden. Abbildung 5.7 zeigt die dabei
entstandenen Ausgaben des Publisher- und des Subscriber-Knotens. Bei (1) wird die
Picht verletzt, innerhalb jeder Periode ein Event auf dem Echtzeitkanal zu veröentlichen.
Der Deliver-Task erkennt dies und ruft den Ausnahmerückruf des Publishers auf. Bei (2)
10
Die gemessenen Erwartungswerte liegen jeweils leicht über den geplanten Werten, da beim Subscriber
vor der Messung von r sub geprüft werden muss, ob das vorliegende Event veraltet ist. Eine derartige
Verzögerung ist beim Publisher nicht vorhanden.
101

5 Evaluierung
Abbildung 5.7: Beispiel für die Fehlererkennung und -behandlung auf der
Publisher-Seite (oben) und beim Subscriber (unten).
wird der Publisher-Task nicht zum eigentlich eingeplanten Zeitpunkt gestartet, so dass
das Event 10 ms später publiziert wird. Der Deliver-Task wird hier jedoch rechtzeitig ausgeführt
und ndet wie in (1) kein aktuelles Event vor. Folglich wird kein Event über
das Netzwerk veröentlicht und der Ausnahmerückruf aufgerufen. Bei (3) kommt es zu
einem Middleware-Zeitfehler. Der Deliver-Task verspätet sich um 5 ms. Das Event wird
jedoch nicht versendet, da es zu einer Verletzung der Slotgrenzen des Echtzeitkommunikationskanals
kommen würde. Der Network Guard erkennt vor dem Versenden, dass das
Übertragungsstartfenster verpasst wurde, und verhindert die Ausbreitung des Zeitfehlers
auf das Netzwerkmedium. In diesem Beispiel werden folglich die Events in den Perioden
11, 13 und 15 ausgelassen. Die übrigen Events werden ohne Fehler veröentlicht. Auf der
Subscriber-Seite werden die Auslassungen über die Verletzung der Periodizität erkannt,
so dass die Anwendung nicht nur mit den erhaltenen Events notiziert wird, sondern per
Ausnahmerückruf auch über fehlende Events informiert wird.
102

5.5 Eignung für eingebettete Systeme
Funktion Realisierung Flash RAM
Publisher RT-Kanal 13.698 399
NRT-Kanal 6.440 348
Subscriber RT-Kanal 10.818 399
NRT-Kanal 6.614 348
Tabelle 5.6: Speicherbedarf von einfachen Test-Anwendungen auf einem
AVR-Mikrocontroller (Angaben in Byte)
5.5 Eignung für eingebettete Systeme
Für die Portierung der Middleware sind nur wenige Anpassungen in der Konguration
nötig, da der überwiegende Teil der Middleware plattformunabhängig ist. Der plattformspezische
Code ist in einigen wenigen Policy-Klassen gekapselt. Von den im Rahmen
dieser Arbeit implementierten Komponenten sind lediglich die Anbindung an den lokalen
Zeitgeber und die Temporal Firewall 11 plattformabhängig.
Diese wurden auch für den 8-Bit-AVR-Mikrocontroller AT90CAN128 implementiert, um
die prinzipielle Eignung der Echtzeitkanäle für stark ressourcenbeschränkte eingebettete
Systeme zu zeigen. Der AT90CAN128 arbeitet bei einer Taktfrequenz von bis zu 16 MHz.
Er verfügt über 128 KByte Flash als Programmspeicher sowie 4 KByte internen SRAM.
In Tabelle 5.6 ist der Flash- und der permanente RAM-Bedarf 12 verschiedener Testprogramme
gegenübergestellt. Es wird eine einfache Publisher- und eine einfache Subscriber-
Applikation betrachtet. In einer Version kommunizieren die beiden über die Echtzeitkanäle,
in der anderen komplett ohne QoS-Zusicherungen über Best-Eort-Kanäle. Die Programme
wurden mit dem Compiler avr-g++ 13 (Version 4.3.5) übersetzt 14 . Wie zu erwarten
war, benötigen die Echtzeit-Features von FAMOUSO zusätzliche Speicherressourcen. Beim
Publisher ergeben sich ca. 7.300 Byte, beim Subscriber ca. 4.200 Byte zusätzlicher Flash-
Bedarf. Hiervon entfallen jeweils etwa 1.200 Byte auf die Uhrensynchronisation 15 und den
Task-Dispatcher, die bei der NRT-Version nicht enthalten sind. Die eigentliche Implementierung
der Echtzeitkanäle belegt somit auf der Publisher-Seite ungefähr 4.900 Byte und
auf der Subscriber-Seite rund 1.800 Byte Flash. Der permanente RAM-Bedarf erhöht sich
insgesamt um etwa 50 Byte, wobei die Uhrensynchronisation und der Task-Dispatcher
hier nahezu die Hälfte ausmachen. Alles in allem nutzen die Testprogramme, die mit den
11
Bei der Temporal Firewall muss sichergestellt werden, dass es durch nebenläugen Zugri nicht zu Race-
Conditions kommt. Hierfür bieten verschiedene Plattformen unterschiedliche Mechanismen, die in der
jeweiligen Implementierung ausgenutzt werden.
12
Die Nutzung des Stacks wird hierbei nicht betrachtet.
13 avr-g++ ist ein C++-Compiler für AVR-Mikrocontroller. Er ist Teil der GNU-Compiler-Collection (siehe
http://gcc.gnu.org/).
14
Als Optimierungseinstellung bei der Übersetzung wurde -Os -ffunction-sections -fdata-sections
-Wl,gc-sections verwendet. Zur Ermittlung des Speicherbedarfs wurde der Befehl avr-size -C
mcu=at90can128 eingesetzt.
15
Für den AVR wurde nicht das in Abschnitt 5.1 beschriebene Verfahren verwendet, da dies nur mit
groÿem Aufwand auf den 8-Bit-Mikrocontroller portiert werden kann. Stattdessen wird eine weniger
rechenaufwendige Oset-Korrektur durchgeführt.
103

5 Evaluierung
Echtzeitkanälen arbeiten, nur ungefähr 10% des im Mikrocontroller vorhandenen Speichers.
Die Middleware lässt somit noch hinreichend Platz für komplexere Anwendungen.
Zusätzlich gibt es bei der Ressourcennutzung noch Einsparpotential, das durch Anpassungen
in der Implementierung ausgenutzt werden kann, beispielsweise durch die Verwendung
kleinerer Datentypen für die Knoten-IDs, Netzwerk-IDs und die lokalen PEC-IDs 16 .
In den etwa 400 Byte reservierten RAM ist auÿerdem ein Puer von 255 Byte für das
Zusammensetzen fragmentiert übertragener Events enthalten. Dessen Gröÿe lässt sich als
Kongurationsparameter leicht an die Anforderungen der Anwendung anpassen.
16
Momentan werden für alle IDs 64-Bit-Datentypen verwendet, deren Verarbeitung auf einem 8-Bit-
Prozessor sehr aufwendig ist.
104

6 Zusammenfassung und Ausblick
In der vorliegenden Arbeit wurde die Middleware FAMOUSO um Echtzeitkommunikationskanäle
erweitert. Diese ermöglichen die Durchsetzung von strikten QoS-Anforderungen bei
der Kommunikation mehrerer Knoten in einem Netzwerk.
In Kapitel 2 wurde eine Einführung in Echtzeitsysteme gegeben. Dabei wurde die zentrale
Problemstellung der Arbeit herausgearbeitet: Der Zugri auf das Netzwerk muss reguliert
werden, da es eine Ressource ist, die von mehreren Knoten gemeinsam genutzt wird. Die
Regulierung muss in einer Art und Weise geschehen, die beschränkte Latenzen garantieren
kann auch bei hoher Auslastung des Netzwerks. Existierende Ansätze, mit denen diese
zeitliche Vorhersagbarkeit für CAN und Ethernet erreicht werden kann, wurden den für
FAMOUSO gestellten Anforderungen nicht gerecht.
Daher wurde ein neues Verfahren zur Koordination der Netzwerkmedienzugrie entwickelt,
das in Kapitel 3 vorgestellt wurde. Es basiert auf dem TDMA-Prinzip, d. h. die Medienzeit
ist in Slots unterteilt, die jeweils einem Echtzeitkommunikationskanal zugeordnet sind.
Die Dauer und Periode der Slots werden entsprechend der QoS-Anforderungen dimensioniert,
die von der Anwendung an den Kanal gestellt werden. Das Verfahren garantiert,
dass ein Event, das auf einem Kanal veröentlicht wurde, innerhalb des zugehörigen
Slots übertragen werden kann. Somit ergibt sich eine beschränkte Kommunikationslatenz
mit geringem Jitter, wie sie in verteilten Echtzeitsystem gefordert ist. Um die Echtzeitkommunikationskanäle
zur Laufzeit etablieren zu können, wurde ein Reservierungsprotokoll
erarbeitet. Jeder Knoten kommuniziert die QoS-Anforderungen seiner Kanäle über
einen Management-Kanal. Ein zentraler Netzwerkplaner empfängt über diesen die Anforderungen,
reserviert einen entsprechenden Kanal und sendet dessen Zeitparameter zurück
an den Knoten. Damit ist der Kommunikationskanal etabliert, so dass veröentlichte
Events nun an die Subscriber ausgeliefert werden können. Kann die Einhaltung der QoS-
Anforderungen nicht garantiert werden, erfolgt keine Reservierung und somit keine Kommunikation
über den Kanal. Stattdessen wird der Fehler den Anwendungen gemeldet. Es
wurde ein zentraler Planungsansatz gewählt, weil dieser im Vergleich zu einem verteilten
Ansatz mit deutlich geringeren Ressourcen-Anforderungen für die Knoten einhergeht.
So können die Echtzeitkanäle auch auf sehr limitierten eingebetteten Systemen genutzt
werden. Die Koordination der Medienzugrie wurde für CAN und Ethernet beschrieben,
kann aber auch auf andere Netzwerke übertragen werden. Änderungen sind hierfür bei der
Dimensionierung der Slot-Länge sowie bei der Integration von NRT-Nachrichten in das
105

6 Zusammenfassung und Ausblick
TDMA-Schema nötig. Das Konzept ist unabhängig von der verwendeten Uhrensynchronisation.
Die erreichte Uhrengenauigkeit ist wie die anderen Zeiteigenschaften ein Modellparameter,
der sich in der Konguration des Netzwerkplaners angeben lässt.
Die Echtzeitkommunikationskanäle wurden in FAMOUSO integriert (siehe Kapitel 4). Als
API zur Verwendung der Kommunikationskanäle wurden Echtzeitereigniskanäle bereitgestellt.
Für jeden dieser Ereigniskanäle kann eine individuelle QoS gefordert werden. Diese
wird durchgesetzt, wenn ausreichend Ressourcen verfügbar sind. Wird die geforderte QoS
nicht eingehalten, so wird die Anwendung darüber unverzüglich mittels eines Ausnahmerückrufs
informiert. Es wurde ein einfaches kooperatives Multitasking realisiert, um die
Middleware auf eingebetteten Systemen auch ohne Betriebssystem verwenden zu können.
Zeitfehler, die beispielsweise durch unkooperatives Verhalten von Tasks entstehen können,
werden erkannt und es wird verhindert, dass sich diese auf das Netzwerkmedium ausweiten.
Unterstützt wird auch die Synchronisation von Prozessor- und Netzwerkplanung, über
die sich eine gewünschte Ende-zu-Ende-Latenz einstellen lässt. Die Implementierung ist
portabel und kongurierbar.
In Kapitel 5 wurden die erarbeiteten und in der Implementierung umgesetzten Konzepte
evaluiert. Dazu wurden Langzeit-Versuche zur Messung der Kommunikationslatenz
durchgeführt. Diese haben gezeigt, dass mit den Echtzeitkommunikationskanälen die
zeitliche Vorhersagbarkeit geschaen wurde, die für die geforderten QoS-Garantien nötig
ist. Bei den Versuchen wurde auch die erreichte Uhrengenauigkeit überprüft, um die Messfehler
und die Einhaltung der Genauigkeitsannahme einzuschätzen. Der Versuch zur Endezu-Ende-Latenz
veranschaulicht die zeitliche Vorherbestimmbarkeit des Systems durch
den Anwendungsentwickler. Anhand von Beispielen wurde auÿerdem die Reservierung
und Ablehnung von angeforderten Kommunikationskanälen sowie einige Aspekte der
Fehlererkennung und -behandlung demonstriert. Zusätzlich wurde die prinzipielle Eignung
der Echtzeitkanäle für ressourcenbeschränkte eingebettete Systeme gezeigt, indem
der Ressourcenbedarf einer Beispielanwendung auf dem AVR-Mikrocontroller untersucht
wurde.
Die Evaluierung hat gezeigt, dass FAMOUSO dank der in dieser Arbeit entstandenen
Erweiterungen nun auch gut für die Entwicklung verlässlicher verteilter Echtzeitsysteme
geeignet ist.
Ausblick
Während der Entwicklung der Konzepte und deren praktischer Umsetzung sind verschiedene
Aspekte festgestellt wurden, bei denen weiterführende Arbeiten ansetzen können,
um die Eigenschaften und Einsatzmöglichkeiten von FAMOUSO weiter zu verbessern.
• Die vorliegende Arbeit bietet QoS-Garantien für die Kommunikation innerhalb eines
Netzwerksegments. Für viele Anwendungen sind jedoch netzwerkübergreifende
106

Echtzeitgarantien interessant. So beispielsweise, wenn mehrere Roboter, von denen
jeder selbst ein verteiltes Echtzeitsystem darstellt, kooperativ zusammenarbeiten
sollen. Daher ist eine Erweiterung der Netzwerkplanung wünschenswert, die
Garantien für die Kommunikation über mehrere Netzwerksegmente ermöglicht (vgl.
Abschnitt 3.3.6).
• Momentan ist die Einplanbarkeit von Kommunikationskanälen abhängig von der
Reihenfolge ihrer Anforderung. So kann eine Menge von Kanälen in einem Lauf des
Systems planbar sein, während in einem anderen Lauf nicht alle Kanäle reservierbar
sind. Das Problem lässt sich zwar durch die Angabe von Slot-Rahmenintervallen
lösen, jedoch ist dies ein zusätzlicher Aufwand für den Anwendungsentwickler. Eine
bessere Lösung wäre die Umsetzung eines optimalen Planungsalgorithmus' (vgl.
Abschnitt 3.2.4). Dieser erfordert jedoch die Umplanung von bereits verwendeten
Kommunikationskanälen, was wiederum die Erweiterung des Reservierungsprotokolls
nötig macht. Da hierdurch in allen Knoten zusätzlicher Ressourcenbedarf entsteht,
sollte die optimale Planung als optionales Feature realisiert werden.
• Das Konzept schreibt einen zentralen Netzwerkplaner vor. Zwar läuft die bereits in
Gang gesetzte Echtzeitkommunikation auch weiter, wenn der Planer ausfällt. Es sind
jedoch keine neuen Reservierungen oder Freigaben möglich. Auch der Ausfall des Poll-
Masters kann momentan nicht toleriert werden. Im Interesse der Verlässlichkeit könnte
daher die Unterstützung von Backup-Komponenten realisiert werden, durch
die der Ausfall von Komponenten maskiert werden kann.
• Der implementierte Ethernet Network Layer sendet alle Events als Broadcast, so
dass auch Events nicht abonnierter Subjects in der Middleware empfangen werden.
Über die Verwendung von Multicast MAC-Adressen lieÿe sich die CPU-Belastung
reduzieren, weil die Filterung so schon auf Hardware-Ebene oder zumindest im Betriebssystem
stattnden kann. Zur Unterstützung muss ein entsprechendes Bindeprotokoll
für Ethernet entwickelt werden.
107

Literaturverzeichnis
[ALRV00] Avizienis, Algirdas ; Laprie, Jean-Claude ; Randell, Brian ; Vytautas:
Fundamental Concepts of Dependability. (2000). http://citeseerx.ist.
psu.edu/viewdoc/summary?doi=10.1.1.24.1400
[APF02]
[Coo03]
[CV94]
[DB07]
Almeida, L. ; Pedreiras, P. ; Fonseca, J.A.G.: The FTT-CAN protocol:
why and how. In: Industrial Electronics, IEEE Transactions on 49 (2002),
Dezember, Nr. 6, S. 1189 1201. ISSN 02780046
Cooling, Jim: Software Engineering for Real-Time Systems. Addison-Wesley,
2003. ISBN 0201596202
Chiueh, Tzi cker ; Venkatramani, Chitra: Supporting Real-Time Trac on
Ethernet. In: in Proc. of Real-Time Systems Symposium, 1994, S. 282286
Davis, Robert I. ; Burns, Alan: Controller Area Network (CAN) Schedulability
Analysis: Refuted, Revisited and Revised. In: Refuted, Revisited and
Revised. Real-Time Systems 35 (2007), S. 239272
[FMD + 00] Führer, Thomas ; Müller, Bernd ; Dieterle, Werner ; Hartwich, Florian
; Hugel, Robert ; Walther, Michael: Time Triggered Communication on
CAN / Robert Bosch GmbH. 2000. Forschungsbericht
[GPS04]
[GS94]
[GVC96]
[HJ03]
Gore, Pradeep ; Pyarali, Irfan ; Schmidt, Douglas C.: The Design and Performance
of a Real-Time Notication Service. In: Proceedings of the 10th IEEE
Real-Time and Embedded Technology and Applications Symposium, IEEE Computer
Society, 2004, S. 112
Gergeleit, M. ; Streich, H.: Implementing a distributed high-resolution
real-time clock using the CAN-Bus. In: Proceedings of the 1st International
CAN-Conference. Mainz, Germany, 1994
George, Laurent ; Voluceau, Domaine D. ; Cedex, Bp Le C.: Preemptive
and Non-Preemptive Real-Time Uni-Processor Scheduling. 1996. Technical
Report 2966, Institut National de Recherche et Informatique et en Automatique
(INRIA), France
Hanssen, Ferdy ; Jansen, Pierre G.: Real-Time Communication Protocols:
An Overview. 2003. Forschungsbericht
109

Literaturverzeichnis
[HLS97]
[Hüs94]
[iee08]
Harrison, Timothy ; Levine, David L. ; Schmidt, Douglas C.: The Design
and Performance of a Real-time CORBA Event Service. In: Proceedings of
OOPSLA '97, (Atlanta, GA), ACM, ACM, 1997, S. 184199
Hüsener, Thomas: Entwurf komplexer Echtzeitsysteme State of the Art.
BI-Wissenschaftsverlag, 1994. ISBN 3411164417
IEEE Standard for Information TechnologyTelecommunications and Information
Exchange Between SystemsLocal and Metropolitan Area Networks
Specic Requirements Part 3: Carrier Sense Multiple Access With Collision
Detection (CSMA/CD) Access Method and Physical Layer Specications
- Section One. In: IEEE Std 802.3-2008 (Revision of IEEE Std 802.3-
2005) (2008). http://dx.doi.org/10.1109/IEEESTD.2008.4726971. DOI
10.1109/IEEESTD.2008.4726971
[KL99] Kaiser, Jörg ; Livani, Mohammad A.: Achieving Fault-Tolerant Ordered
Broadcasts in CAN. In: Proc. of the 3rd European Dependable Computing
Conference, 1999, S. 351363
[KN97]
[KN98]
[Kop97]
[Kop04]
[KW05]
[LK98]
[LKJ99]
Kopetz, H. ; Nossal, R.: Temporal rewalls in large distributed real-time
systems. In: Distributed Computing Systems, 1997., Proceedings of the Sixth
IEEE Computer Society Workshop on Future Trends of, 1997. ISSN 1071
0485, S. 310 315
Kaiser, Jörg ; Nett, Edgar: Echtzeitverhalten in dynamischen, verteilten
Systemen. In: Informatik Spektrum 21 (1998), Nr. 6, S. 356365
Kopetz, Hermann: Real-Time Systems: Design Principles for Distributed Embedded
Applications. 1st. Norwell, MA, USA : Kluwer Academic Publishers,
1997. ISBN 0792398947
Kopetz, Hermann: On the Fault Hypothesis for a Safety-Critical Real-Time
System. In: Workshop on Future Generation Software Architectures in the
Automotive Domain (2004)
Kiszka, Jan ; Wagner, Bernardo: RTnet - A Flexible Hard Real-Time Networking
Framework. In: In 10th IEEE International Conference on Emerging
Technologies and Factory Automation, 2005
Livani, Mohammad A. ; Kaiser, Jörg: EDF Consensus on CAN Bus Access
for Dynamic Real-Time Applications. In: in José Rolim (Ed.): Lecture Notes
in Computer Science, Springer, 1998, S. 10881097
Livani, Mohammad A. ; Kaiser, Jörg ; Jia, Weijia: Scheduling Hard and Soft
Real-Time Communication in a Controller Area Network. In: in Controller
Area Network (CAN), 23RD IFAC/IFIP Workshop On Real Time Programming,
1999
110

Literaturverzeichnis
[Lun08]
Lunze, Jan: Regelungstechnik 1. 7. neu bearbeitete Auage. Springer, 2008.
ISBN 9783540689072
[MHG03] Martínez, José M. ; Harbour, Michael G. ; Gutiérrez, J. J.: RT-EP:
Real-Time Ethernet Protocol for Analyzable Distributed Applications on a
Minimum Real-Time POSIX Kernel. In: Proceedings of the 2nd International
Workshop on Real-Time LANs in the Internet Age, RTLIA 2003, 2003
[NL08]
[PAG02]
[PcS94]
[RGS95]
[Rob91]
[RV95]
Navet Nicolas (Hrsg.) ; Lion Françoise Simonot (Hrsg.): The Automotive
Embedded Systems Handbook. Taylor & Francis / CRC Press, 2008 (Industrial
Information Technology Series). 488 S. ISBN 9780849380266
Pedreiras, Paulo ; Almeida, Luís ; Gai, Paolo: The FTT-Ethernet Protocol:
Merging Flexibility,Timeliness and Eciency. In: Proceedings of the 14th
Euromicro Conference on Real-Time Systems. Washington, DC, USA : IEEE
Computer Society, 2002. ISBN 0769516653, 152
Pardo-castellote, Gerardo ; Schneider, Stan: The Network Data Delivery
Service: Real-Time Data Connectivity for Distributed Control Applications. In:
Proc. IEEE Int. Conf, 1994, S. 28702876
Rajkumar, Ragunathan ; Gagliardi, Mike ; Sha, Lui: The Real-Time Publisher/Subscriber
Inter-Process Communication Model for Distributed Real-
Time Systems: Design and Implementation. In: Proceedings of the IEEE Realtime
Technology and Applications Symposium, 1995, S. 6675
Robert Bosch GmbH: CAN Specication Version 2.0. Robert Bosch GmbH,
1991
Rufino, José ; Veríssimo, Paulo: A Study on the Inaccessability Characteristics
of the Controller Area Network. In: Proc. of the 2nd International CAN
Conference, CiA, 1995, S. 712
[Sch] Schulze, Michael: FAMOUSO Project Website. http://famouso.
sourceforge.net
[Sch09]
[Sch10a]
[Sch10b]
[SF11]
Schulze, Michael: FAMOUSO Eine adaptierbare Publish/ Subscribe Middleware
für ressourcenbeschränkte Systeme. In: Electronic Communications of
the EASST (ISSN: 1863-2122) 17 (2009). ISSN 18632122
Schulz, Gerd: Regelungstechnik 1 - Lineare und Nichtlineare Regelung, Rechnergestützter
Reglerentwurf. 4. Oldenbourg Wissenschaftsverlag GmbH, 2010
Schulze, Michael: A Highly Congurable Logging Framework In C++. In:
Dr. Dobb's (2010), June 18. http://www.drdobbs.com/cpp/225700666
Schulze, Michael ; Förster, Marcus: Ressourcengewahres Framework für
Kontextinformationen in eingebetteten verteilten System. In: Electronic Communications
of the EASST (ISSN: 1863-2122) 37 (2011), S. 12. Proceedings
111

Literaturverzeichnis
of the Workshops der wissenschaftlichen Konferenz Kommunikation in Verteilten
Systemen 2011 (WowKiVS 2011)
[SL09] Schulze, Michael ; Lukas, Georg: MLCCA Multi-Level Composability
Check Architecture for Dependable Communication over Heterogeneous Networks.
In: Procedings of 14th International Conference on Emerging Technologies
and Factory Automation. Mallorca, Spain : IEEE, 2009
[SWLK11] Schulze, Michael ; Werner, Philipp ; Lukas, Georg ; Kaiser, Jörg: AFP
an Adaptive Fragmentation Protocol for Supporting Large Datagram Transmissions.
In: Journal of Communications (2011). eingereicht 10. Februar,
angenommen 23. März
[TB94]
[Tin94]
[ZA95]
[ZS95]
Tindell, Ken ; Burns, Alan: Guaranteeing Message Latencies On Control
Network (CAN). In: Proceedings of the 1st International CAN Conference,
CiA, 1994, S. 12
Tindell, K.W.: Analysing Real-Time Communications: Controller Area Network
(CAN). 1994
Zöbel, Dieter ; Albrecht, Wolfgang: Echtzeitsysteme-Grundlagen und Techniken.
1. Attenkirchen : International Thomson Publishing, 1995. ISBN
3826601505
Zuberi, Khawar M. ; Shin, Kang G.: Non-Preemptive Scheduling of Messages
on Controller Area Network for Real-Time Control Applications. In: IEEE
Transactions On Robotics And Automation, 1995, S. 240249
112

Selbstständigkeitserklärung
Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbstständig und nur unter
Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe, sowie alle Zitate
entsprechend kenntlich gemacht habe.
Magdeburg, 31. März 2011
Philipp Werner