Das Ethernet, das üblicherweise zur Verbindung von Bürocomputern verwendet wird, ist ein kollisionsbasiertes Protokoll. Wenn das Netzwerk aufgrund von mehreren gleichzeitigen Übertragungen ausgelastet ist oder irgendein anderer Datenfehler auftritt, würde der Kommunikationsknoten die Übertragung erneut versuchen. Dieses Maß an Unsicherheit ist in vielen Computeranwendungen akzeptabel, jedoch nicht für sicherheitskritische Anforderungen und erfolgreiche Audio-/Video-Kommunikation.
Die bestehenden Ethernet-Definitionen wurden um die Time-Sensitive-Network-Funktion (TSN) erweitert. Diese erlaubt die zeitliche Koordination zwischen mehreren Sendern und Empfängern sowie die Zugangsüberwachung auf ECU-Knoten. Diese Zugangsüberwachung verhindert, dass eine Traffic-Überlastung (Denial of Service oder fehlerhafte Lieferung) den Empfangsknoten oder -Port beeinträchtigt. Sicherheitskritische Anwendungen wie Lenk- und Bremsfunktionen müssen wissen, dass die Übertragungszeit garantiert und das Netzwerk hochzuverlässig ist. TSN beinhaltet das Konzept des „Scheduled Traffic“. Das bedeutet, dass zeitbezogene ECUs für sicherheitskritische Signale einen gemeinsamen Netzwerktakt und autorisierte feste Übertragungsfenster (Time Gates) haben.
Bei automatisierten Fahrzeugen müssen mehrere Sensordaten in Bezug auf synchronisierte Echtzeit gesammelt und verarbeitet werden. Diese Bilder werden zusammengefügt, um eine 360-Grad-Ansicht der lokalen Umgebung wiederzugeben. Daraus können Bildverarbeitungsalgorithmen mögliche Gefahren und bewegliche Objekte rund um das Fahrzeug analysieren. Ein zentraler Takt und bekannte Latenz bei der Nachrichtenübertragung sind wichtig, damit diese Funktionen korrekt arbeiten.
Selbst bei Datenraten von 100 Mbit/s werden relativ lange Ethernet-Nachrichten-Frames in µs über das Netzwerk übertragen. Das bedeutet, dass sehr viele Time Slots zur Verfügung stehen, um die „echten“ physikalischen Reaktionsanforderungen von mechanischen und beweglichen Teilen des Fahrzeugs zu erfüllen.
Ethernet-Nachrichten-Frames variieren hinsichtlich ihrer Größe, von Steuernachrichten mit 84 Byte bis zu Kamera-Bild-Frames mit 1500 Byte oder mehr.
Bei 100 Mbit/s würde die Übertragung eines kurzen Frame 6,72 µs und eines längeren Frame bis zu 122 µs dauern (Studie der TU Braunschweig). Mit dieser Timing Performance erfüllt Ethernet die erforderlichen Reaktionszeiten für derzeitige und zukünftige Sicherheitsstandards.
Um den Anforderungen von deterministischen Antwortzeiten und TSNs gerecht zu werden, wurde der IEEE-802.1-Standard ergänzt. Er beinhaltet nun in 802.1 Qav „Credit-based Shaper“, einen neuen Preemption-Mechanismus in P802.1Qbu, Timing-Standards in 802.1AS, ein Stream-Reservation-Protokoll in 802.1Qat und „Forwarding“ und „Queuing“ für zeitkritische Streams in 802.1 Qav.
Damit störender Traffic sich nicht auf ein Netzwerk auswirkt, müssen Ethernet Switches die Zykluszeiten aller Control Traffics (Klasse-A-Traffic) kennen. Non-Control Traffic wird während der regulären Gates blockiert. So wird sichergestellt, dass der Sende-Port für einen wichtigen Control Stream verfügbar ist, wenn er benötigt wird. Die Verwaltung dieser Time Gates ist in der „Time-Aware Shaper“-Funktion des IEEE 802.1Qbv definiert. Nachrichten befinden sich in einer Warteschlange, während ein Credit aufläuft. Sobald dieser Credit positiv und ein Time Gate verfügbar ist, beginnt die Nachrichtenübertragung. Diese Anordnung wird in Bild 3 gezeigt.
Timing Analyse und Worst-Case Design
In einer komplexen Fahrzeugarchitektur kann es für eine bestimmte Nachricht viele Hops geben, weil sie durch viele verschiedene Domänen-Controller und Netzwerk-Links läuft. Der Ethernet Switch Timing Jitter ist für jedes Segment kumulativ. Er hängt von den Klassen und Prioritäten der Nachricht sowie von den Auswirkungen der Kommunikationswarteschlangen und Shaper ab. Simulations-Tools dienen der Analyse von Worst-Case-Pfaden. Mentor Graphics bietet mit Volcano VSA COM ein Produkt an, mit dem sich das Timing von komplexen Ethernet-Architekturen definieren und analysieren lässt. Das Szenario in Bild 4 definiert einen kleinen Testfall einer Publisher- und einer Receiver-ECU, die über Ethernet kommunizieren.
Neben der Zeit im Switch enthält der Netzwerkpfad in diesem Beispiel auch Vorbereitungszeiten für Nachrichten Time Before Transmission (TBT) und Time After Reception (TAR). In Abhängigkeit von der Nachrichtenklasse, Datennutzlast, Existenz von VLAN-Tags und anderen Parametern kann die Länge der Nachrichten erheblich variieren. Das Timing für jedes Segment wird im Analysewerkzeug definiert, kann von einer zentralen Datenbank ausgelesen und jeder einzelne Pfad dann hinsichtlich der Einhaltung aller Leistungsanforderungen des Fahrzeugnetzwerks kalkuliert und überprüft werden (Bild 5).
AUTOSAR, Netzwerkstandards und Arbeitsgruppen
Der AUTOSAR-Standard bietet für Ethernet-Netzwerke breite Unterstützung und zusätzliche Konzepte, die über Ethernet betrieben werden, zum Beispiel Secure On-Board Communication (SeCOC) und End-to-End-Schutz (E2E-Schutz).
Ethernet unterstützt auch Service-orientierte Protokolle wie SOME/IP. SOME/IP erlaubt Anwendungen die Kommunikation über ein physikalisches Ethernet-Netzwerk, sodass Fahrzeug-ECUs Service-Kommandos in einer Client/Server-Anordnung übermitteln können.
Eine Reihe von Industrieallianzen unterstützt Ethernet im Automobilbereich:
Schlussfolgerung
Ethernet hat sich bereits bei einigen Autoherstellern als Medium für Diagnose- und Multimedia-Anwendungen etabliert. Die Technologie verfügt über das Potenzial für weiteres Wachstum in andere Domänen. Sie wird die Antwortzeiten und Zuverlässigkeitsanforderungen für sicherheitskritische Fahrzeugsteuersysteme erfüllen und das Netzwerk der Wahl für autonome Fahrzeuge werden. Fahrzeugnetzwerke werden noch einige Jahre in einer hybriden Form vorhanden sein und CAN, CAN-FD, FlexRay und Ethernet kombinieren. Bei steigender Komplexität der Designs wird jedoch Ethernet dominieren. Eine neue Generation physikalischer Netzwerktreiber, Embedded-Software und Design-Werkzeugen wird entstehen, um die Anforderungen der Automobilentwickler-Gemeinde zu erfüllen.
Der Autor
| Andrew Patterson |
|---|
| hat einen Abschluss als Master in Elektrotechnik und Elektrowissenschaften von der Universität Cambridge, Großbritannien. Er ist Markt und Business Development Director der Embedded Software Division von Mentor Graphics. A. Patterson entwickelte Demonstrations-/Prototypenlösungen auf der Basis von Genivi-Linux-Umgebungen und Mentors eigenem Nucleus-Echtzeitbetriebssystem auf einer Reihe von Hardware-Plattformen. |