Diesen Artikel herunterladen - HANSER automotive
Diesen Artikel herunterladen - HANSER automotive
Diesen Artikel herunterladen - HANSER automotive
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
ETHERNET<br />
Ethernet bringt kommunikationsintensive Funktionen (Audio- und<br />
Videosysteme, Fahrerassistenzsysteme und paralleles Flashen) mit<br />
einem oft hohen, kundenerfahrbaren Mehrwert ins Fahrzeug. Zukünftig<br />
winken zusätzliche Einsparungen durch die Übertragung von Daten<br />
verschiedener Domänen über dasselbe Netzwerk. Damit das zuverlässig<br />
funktioniert, sind auch für Ethernet verständliche Echtzeit-Bewertungen<br />
notwendig, wie sie heute für CAN und FlexRay üblich sind.<br />
Echtzeit-Bewertung von<br />
Ethernet-Konfigurationen<br />
Echtzeit-Bewertungen liefern qualifizierte<br />
Antworten auf Fragen wie:<br />
Wie konfiguriert man das Ethernet-<br />
Netzwerk (im Verbund mit den anderen<br />
Bus-Segmenten) optimal, um eine gute<br />
Auslastung und Erfüllung der unterschiedlichen<br />
Zeitanforderungen zu gewährleisten?<br />
Wo liegen Engpässe und<br />
wie können diese behoben werden?<br />
Wie überlagern sich Audio- und Video-<br />
Ströme mit regelungstechnisch relevante<br />
Daten und welche Kommunikations-<br />
Latenzen werden sich einstellen? Welche<br />
„Timing-Güte“ haben die einzelnen<br />
Nachrichten? Zur Beantwortung dieser<br />
Fragen benötigt man aussagekräftige<br />
Metriken zur Bewertung des Echtzeitverhaltens<br />
(oder auch der „Timing-<br />
Güte“) von Ethernet- und E/E Systemkonfigurationen.<br />
Klassische Echtzeit-<br />
Metriken<br />
Die bekannteste Echtzeit-Metrik ist die<br />
Buslast. Bei CAN ergibt sich die Buslast<br />
beispielsweise aus den Größen und Zykluszeiten<br />
aller über den Bus versendeten<br />
Nachrichten (Frames) und gibt an,<br />
wie hoch ein Bus wirksam ausgelastet<br />
ist. Die Buslast dient vordringlich einer<br />
ersten Orientierung, belastbare Aussagen<br />
bezüglich der Timing-Güte einzelner<br />
Nachrichten sind nicht möglich.<br />
Beispielsweise sind auch bei geringer<br />
Buslast Zykluszeitverletzungen möglich,<br />
z. B. aufgrund von sporadischen<br />
Frames. Auch spiegeln sich elementare<br />
Konfigurationsparameter wie die CAN-<br />
ID nicht in der Buslast wider. Daher<br />
werden seit einigen Jahren standardmäßig<br />
so genannte Latenz-Analysen<br />
durchgeführt, um die konkreten Verzögerungen<br />
einzelner Nachrichten zu bestimmen<br />
und mit zuvor definierten An-<br />
© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-<strong>automotive</strong>.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern<br />
Aufmacher: 123rf © James Thew; weitere Bilder: Symtavision<br />
6 <strong>HANSER</strong> <strong>automotive</strong> networks / Special 2013<br />
© Carl Hanser Verlag, München
forderungen zu vergleichen. Die Latenz-<br />
Metrik liefert also detaillierte Informationen<br />
zur „Timing-Güte“ auf Nachrichten-Ebene.<br />
Diese beiden Metriken (Last und Latenz)<br />
bilden heute die Grundlage für<br />
umfassende Echtzeit-Bewertungen von<br />
CAN-Bus-Systemen; ähnliches gilt für<br />
FlexRay und LIN. Für Ethernet lassen<br />
sich diese Ansätze weiterhin nutzen,<br />
müssen dabei aber einige Ethernet-spezifische<br />
Eigenschaften berücksichtigen.<br />
Ethernet-Last<br />
Im Vergleich zu CAN ist die Buslast-Metrik<br />
bei Ethernet komplexer, denn ein typisches<br />
Ethernet-Netzwerk besteht aus<br />
mehreren Verbindungen (Links) und<br />
Switches, die jeweils unterschiedliche<br />
Lasten aufweisen. Zur Bestimmung dieser<br />
Lasten benötigen man die Datenraten<br />
der einzelnen Datenströme, die Topologie<br />
des Systems inklusive der Link-Geschwindigkeiten<br />
(10, 100, 1000 Mbit/s)<br />
Bild 1: Aggregierte Punkt-zu-Punkt-Datenraten für ein Ethernet-System<br />
bestehend aus 14 ECUs.<br />
Bild 2: Relative Latenz der 64 Nachrichten des Beispielsystems.<br />
»<br />
ETHERNET<br />
Auch für Ethernet ist eine dedizierte Timing-<br />
Bewertung für Echtzeitdaten notwendig, um<br />
Integrationsprobleme oder Konfigurationsfehler<br />
zuverlässig aufzudecken.<br />
Dr. Kai Richter, CTO Symtavision<br />
und Routing-Informationen darüber, welcher<br />
Datenstrom welchen Link passiert.<br />
Nun lassen sich folgende Metriken nutzen:<br />
Ein Datenstrom entspricht einer logischen<br />
Datenverbindung. So bekommt<br />
man einen ersten Überblick über die<br />
„Verursacher“ der Lasten auf Funktionsebene.<br />
Kommt es zu Engpässen, sollte<br />
eine Optimierung bei den datenintensiven<br />
Funktionen ansetzen.<br />
Die aggregierte Punkt-zu-Punkt-Datenrate<br />
entspricht der Menge an ausgetauschten<br />
Daten zwischen den beteiligten<br />
ECUs. Diese Betrachtung ist wichtig<br />
für die grundsätzliche Wahl einer Topologie<br />
und der Anbindung an die Switches<br />
(oder andere Netzwerksegmente).<br />
Im Beispiel von Bild 1 sieht man,<br />
dass die Kameras (CAM 1, 2, 3, 4) die<br />
meisten Daten in das Netz einspeisen,<br />
einige Broadcast-Nachrichten von einem<br />
zentralen Gateway versendet werden<br />
und weiterer heterogener Datenverkehr<br />
zwischen einer kleineren Anzahl<br />
von ECUs ausgetauscht wird.<br />
Schließlich können wir die Topologie<br />
und die Link-Geschwindigkeiten berücksichtigen,<br />
um von den Datenraten<br />
auf echte Lasten zu kommen. Diese<br />
Port-Last gibt die prozentuale Auslastung<br />
an. Dies gilt für ECU-Ports ebenso<br />
wie für Switch-Ports. Man bekommt<br />
ein Gesamtbild über die Auslastung aller<br />
Links im System, sieht die Hot-Spots<br />
(besonders stark ausgelastete Links),<br />
aber auch die Reserven für eventuelle<br />
Funktionserweiterungen.<br />
Ethernet Nachrichten-<br />
Latenzen<br />
Die Latenz-Metrik erfasst nun die<br />
Timing-Güte aller Nachrichten bzw.<br />
Datenströme im Detail. Die „Ende-zu-<br />
Ende“-Latenz entspricht der Verzögerung<br />
zwischen dem Senden einer Nachricht<br />
und deren Empfang. Diese Latenz<br />
© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-<strong>automotive</strong>.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern<br />
»<br />
www.hanser-<strong>automotive</strong>.de<br />
<strong>HANSER</strong> <strong>automotive</strong> networks / Special 2013<br />
7
ETHERNET<br />
Bild 3: Histogramm-Darstellung der relativen Latenzen.<br />
Bild 4: Relatives Latenzhistogramm.<br />
beinhaltet alle Netzwerk-Verzögerungen<br />
in den beteiligten Ethernet-Ports<br />
und -Switches; daher der Name „Endezu-Ende“.<br />
Diese Latenzen können unmittelbar<br />
mit vorhandenen Vorgaben<br />
(Deadlines) verglichen werden und liefern<br />
konkrete Informationen zur<br />
„Timing-Güte“ auf Funktionsebene.<br />
Die sogenannte Relative Latenz (relative<br />
latency) liefert dieselbe Information<br />
in Relation zur jeweiligen Deadline<br />
der Nachricht. So hat beispielsweise<br />
eine Nachricht mit einer Latenz von<br />
3 ms und einer Deadline von 100 ms<br />
eine relative Latenz von 3%. Dieselbe<br />
Nachricht hätte bei einer Deadline von<br />
nur 5 ms eine relative Latenz von 60%<br />
und wäre deutlich kritischer einzustufen.<br />
Eine zweite vergleichende Darstellung<br />
liefert der sogenannte Slack<br />
(Schlupf), das ist die Differenz zwischen<br />
Deadline und Latenz. Ein kleiner oder<br />
sogar negativer Slack bedeutet, dass<br />
die Nachricht Gefahr läuft, nicht rechtzeitig<br />
übertragen zu werden.<br />
Bild 2 zeigt die relativen Latenzen<br />
für das Beispielsystem. Die relative Latenz<br />
der markierten Nachricht ist größer<br />
als 100% (1.0). Die Nachricht kann also<br />
nicht zuverlässig übertragen werden.<br />
Diese Darstellung gewinnt zunehmend<br />
an Bedeutung, da sie auf einen Blick<br />
zeigt, welche Nachrichten kritisch sind<br />
und welche nicht. Noch kompakter ist<br />
eine zusammenfassende Histogramm-<br />
Darstellung (Bild 3). Diese zeigt zunächst<br />
auf, ob und wie viele Nachrichten<br />
kritische Latenzwerte aufweisen.<br />
Optimierung<br />
Während Last-Metriken nur einen groben<br />
Überblick über das Systemverhalten<br />
und die zeitlichen Reserven ermög-<br />
lichen, liefern die Latenz-Metriken konkrete<br />
Informationen zur Timing-Güte aller<br />
Nachrichten. Damit lassen sich kritische<br />
Nachrichten identifizieren, die ggf.<br />
verändert werden müssen. Mit modellbasierten<br />
Werkzeugen kann diese Information<br />
schnell modelliert oder aus bestehenden<br />
Konfigurationen (insbesondere<br />
via AUTOSAR oder FIBEX) eingelesen<br />
werden. Mehr noch, die Metriken<br />
liefern konkrete Anhaltspunkte, mit welchen<br />
Maßnahmen man die Latenzen<br />
verbessern kann.<br />
Aus den Beispieldaten lässt sich ablesen,<br />
dass eine Nachricht Gefahr läuft<br />
ihre Deadline zu verletzen. Eine angemessene<br />
Maßnahme ist nun, die Latenz<br />
der kritischen Nachricht zu optimieren.<br />
Im vorliegenden Beispiel wurde<br />
das Problem dadurch behoben, dass<br />
der kritischen Nachricht eine höhere<br />
Priorität nach 802.1q (VLAN) vergeben<br />
wurde. Nun wird sie in den Switches<br />
prioritisiert behandelt und durch die lokalen<br />
Lasten nicht so stark beeinflusst.<br />
Diese Optimierung wird im relativen Latenzhistogramm<br />
sichtbar (Bild 4).<br />
Zusammenfassung<br />
Auch wenn Ethernet über eine scheinbar<br />
unerschöpfliche Bandbreite verfügt,<br />
ist eine dedizierte Timing-Bewertung<br />
für Echtzeitdaten notwendig, um<br />
Integrationsprobleme oder Konfigurationsfehler<br />
zuverlässig aufzudecken und<br />
zu vermeiden. Entsprechende Metriken<br />
werden von modernen Echtzeit-Werkzeugen<br />
unterstützt. So lassen sich modellbasiert<br />
und schnell verschiedene<br />
Szenarien evaluieren und Antworten<br />
auf die eingangs formulierten Fragen<br />
finden. Mittels der vorgestellten Metriken<br />
ist eine belastbare Gegenüberstellung<br />
verschiedener Protokolle, Netzwerk-Topologien<br />
und Konfigurationen<br />
genauso möglich wie das Fine-Tuning<br />
der Echtzeit-Fähigkeit einzelner Nachrichten.<br />
W (oe)<br />
» www.symtavision.com<br />
Dr. Simon Schliecker, Jonas Diemer,<br />
Dr. Kai Richter<br />
Symtavision GmbH.<br />
© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-<strong>automotive</strong>.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern<br />
8 <strong>HANSER</strong> <strong>automotive</strong> networks / Special 2013<br />
© Carl Hanser Verlag, München