Bus- und Netzwerksysteme sind komplexe Bereiche mit einer Vielzahl von Protokollen, Architekturen und Algorithmen, die zur Entwicklung, zum Testen und zur Validierung der Bus- und Netzwerkkommunikation verwendet werden. Lernen Sie alles kennen, von grundlegenden Konzepten bis hin zu den neuesten Fortschritten bei Bus- und Netzwerktechnologien – von CAN und LIN bis hin zu Automotive Ethernet mit SOME/IP und DDS.
Warum die Kommunikation im Fahrzeug wichtig ist
Heutige Fahrzeuge sind komplexe Systeme aus miteinander verbundenen Steuergeräten, die von grundlegenden Funktionen bis hin zu anspruchsvoller Fahrerunterstützung und autonomem Fahren alles steuern. Diese Systeme sind auf robuste fahrzeuginterne Kommunikationsnetze angewiesen, um Daten zuverlässig, sicher und in Echtzeit auszutauschen. Im Laufe der Jahre haben sich die Busprotokolle von einfachen Lösungen mit geringer Bandbreite wie LIN oder CAN zu Hochleistungstechnologien wie Automotive Ethernet entwickelt. Dieser Wandel wurde durch die wachsenden Anforderungen an Bandbreite, Sicherheit und Effizienz vorangetrieben – insbesondere, da die Fahrzeuge immer softwaredefinierter und funktionsreicher werden.
Auch die Architekturen haben sich verändert: Die traditionellen domänenbasierten Designs weichen zonalen Architekturen, die den Verdrahtungsaufwand verringern und modulare Fahrzeugplattformen unterstützen. Diese zonalen Architekturen stellen eine wesentliche Veränderung in der Art und Weise dar, wie Fahrzeuge entworfen und gebaut werden. Anstatt die Steuergeräte im gesamten Fahrzeug zu verteilen oder sie nach Funktionen zu gruppieren, unterteilen Zonenkonzepte das Fahrzeug in physische Zonen. Jede Zone wird von einem zonalen Steuergerät verwaltet, das mit zentralen Hochleistungsrecheneinheiten (HPCs) kommuniziert, die den Großteil der Software-Logik des Fahrzeugs verarbeiten. Trotz dieser Konsolidierung innerhalb der zonalen Architekturen variieren die Kommunikationsanforderungen je nach Fahrzeugtyp – Elektrofahrzeuge, kommerzielle Flotten und Off-Highway-Maschinen stellen jeweils eigene Anforderungen. Das Verständnis dieser Protokolle und Architekturen ist für den Aufbau zuverlässiger, skalierbarer Kfz-Systeme unerlässlich.
CAN – Das Rückgrat der eingebetteten automatischen Kommunikation
Das Controller Area Network (CAN) ist eines der etabliertesten und am weitesten verbreiteten Kommunikationsprotokolle in der Automobilindustrie. CAN wurde ursprünglich von Bosch in den 1980er Jahren entwickelt, um eine robuste Echtzeitkommunikation zwischen elektronischen Steuergeräten (ECUs) zu ermöglichen, ohne dass ein zentraler Host-Computer erforderlich ist. Seitdem hat es sich nicht nur in Personenkraftwagen, sondern auch in Off-Highway-Maschinen, landwirtschaftlichen Geräten, Luft- und Raumfahrtsystemen und in der industriellen Automatisierung zu einem weltweiten Standard entwickelt. Es ermöglicht den Austausch von Mess- und Steuersignalen und bietet eine hohe Fehlertoleranz durch eingebaute Mechanismen zur Fehlererkennung und -behandlung.
Die physikalische Implementierung von CAN erfordert einen CAN Controller, einen Transceiver sowie einen Mikroprozessor. CAN ist ein nachrichtenorientiertes Kommunikationsprotokoll, das ein Rundrufsystem verwendet, bei dem Nachrichten durch so genannte "Message Identifier" identifiziert werden. Die Empfänger entscheiden anhand des Identifikators, ob sie eine Nachricht annehmen. Die Kennungen bestimmen auch die Priorität der Nachrichten bei der Busarbitrierung nach dem CSMA/CR-Verfahren (Carrier Sense Multiple Access mit Kollisionsauflösung). Jedes Steuergerät kann mit der Übertragung beginnen, wenn der Bus nach einer Pause von drei Bitzeiten im Leerlauf ist. Wenn es zu einer Kollision kommt, gewinnt die Nachricht mit der höheren Priorität. Die Priorität wird durch den Nachrichtenidentifikator bestimmt (eine niedrigere Zahl bedeutet eine höhere Priorität). Die Nachricht mit der höchsten Priorität wird dann ohne Verzögerung fortgesetzt, während die anderen zurückgehen und es erneut versuchen, sobald der Bus frei ist.
Protokollschichten und Varianten
Das klassische CAN wird durch die Norm ISO 11898 definiert. Es gibt drei wichtige CAN-Standards, die den Bus definieren:
- ISO 11898-1 definiert die Datenverbindungsschicht entsprechend der ursprünglichen CAN-2.0A- und CAN-2.0B-Spezifikation. Um neueren Bandbreitenanforderungen gerecht zu werden, erweitern Varianten wie CAN FD (Flexible Data Rate) oder CAN XL (eXtended Layer) diesen Standard um größere Nutzdatenmengen und deutlich höhere Datenraten.
- ISO 11898-2 (High-Speed) und ISO 11898-3 (Low-Speed/Fehlertoleranz) decken die physikalische Schicht des OSI-Modells ab. Sie unterstützen Datenraten von bis zu 1 Mbit/s (hohe Geschwindigkeit) und 125 kbit/s (niedrige Geschwindigkeit).
- ISO 11898-4 stellt eine Erweiterung der Datenübertragungsschicht für die deterministische Kommunikation sicherheitskritischer Nachrichten dar, die als "Time Triggered CAN" bezeichnet wird.
Im Gegensatz zu anderen Bussen deckt die ursprüngliche Spezifikation nur die beiden unteren Ebenen des ISO/OSI-Modells ab. Während CAN selbst keine Anwendungsschicht definiert, haben sich mehrere Protokolle auf höherer Ebene entwickelt, um diese Lücke zu schließen, darunter SAE J1939 für Nutzfahrzeuge, CANopen für die industrielle Automatisierung und ISOBUS für landwirtschaftliche Anwendungen. Die ISO-11898-Standards sehen keine Sicherheitsmechanismen vor. Schutzmaßnahmen wie Authentifizierung, Integrität und Vertraulichkeit werden in höheren Protokollschichten implementiert.
CAN Frame-Format
CAN-Nachrichten werden in strukturierten Frames übertragen, die Header-, Payload- und Trailer-Elemente enthalten. Die beiden Haupttypen sind:
- Basis-Frame-Format: 11-Bit-Bezeichner
- Erweitertes Frame-Format: 29-Bit-Bezeichner
Standard-Frames (11-Bit-Identifier) und erweiterte Frames (29-Bit-Identifier) können im selben CAN-Netzwerk nebeneinander bestehen. Zusätzlich zu den Daten-Frames unterstützt CAN auch Error-Frames und Overload-Frames, die bei der Verwaltung der Kommunikationsintegrität und des Timings helfen.
Jede Nachricht beginnt mit einem Startbit, gefolgt von der Kennung. Da eine Nachricht bei klassischem CAN eine variable Nutzlastlänge von bis zu acht Byte haben kann, wird die genaue Länge in den "Steuerbits" festgelegt. Auf die Nutzdaten folgen eine "zyklische Redundanzprüfung" zur Fehlererkennung sowie eine variable Anzahl von Stuffbits zur Synchronisation. Schließlich geben alle an den Bus angeschlossenen Steuergeräte entweder eine positive Bestätigung in den Feldern Acknowledge (ACK) und End of Frame (EOF) oder ein Error Frame (EF) führt dazu, dass alle Empfänger die empfangenen Daten ignorieren. Dadurch wird die Datenkonsistenz innerhalb des Netzes gewährleistet.
Netzwerktopologie
CAN-Netzwerke verwenden in der Regel eine Bustopologie, bei der alle Knoten parallel an eine Zweidraht-Differenzleitung (CAN_H und CAN_L) angeschlossen sind. Der Bus muss an beiden Enden mit dem Wellenwiderstand der Zweidrahtleitung, typischerweise 120 Ω, abgeschlossen werden. Der Signalhub des differentiellen Spannungspegels beträgt etwa 2 V. Obwohl alternative Topologien wie Stern oder Baum technisch machbar sind, bietet der lineare Bus optimale Leistung und Signalintegrität.
LIN – Leichtgewichtige Netzwerke für kostensensitive Anwendungen
Das Local Interconnect Network (LIN) wurde als kostengünstige Alternative zu CAN eingeführt und speziell für Anwendungen entwickelt, die keine hohe Bandbreite oder Echtzeitleistung erfordern. In der Automobilindustrie wird es häufig zur Steuerung einfacher Aktoren und Sensoren eingesetzt, z. B. für Fensterheber, Sitzverstellungen, Klimaanlagen und Innenbeleuchtung. Durch seine Einfachheit und seine geringen Kosten ist es ideal für diese unkritischen Anwendungen.
Die physische Implementierung verwendet einen einadrigen, seriellen Bus in einem Broadcast-Netzwerk, das einem Master-Slave-Kommunikationsmodell folgt, bei dem ein Master-Knoten bis zu 15 Slave-Knoten steuert. Der Master leitet die gesamte Kommunikation ein, indem er periodische Nachrichten-Header gemäß einer statisch definierten LIN-Zeitplantabelle sendet. Slave-ECUs antworten nur, wenn sie angesprochen werden. Dieser deterministische Zeitplan macht komplexe Schlichtungsmechanismen überflüssig. Genau wie bei CAN kennzeichnet der LIN Identifier den Inhalt jeder Nachricht, und die Empfänger entscheiden anhand des Identifiers, ob sie eine Nachricht akzeptieren. Das Master-Steuergerät fungiert oft als Gateway zu übergeordneten Netzwerken wie CAN oder Automotive Ethernet.
Protokollschichten und Merkmale
LIN arbeitet auf der physikalischen, der Datenverbindungs- und der Anwendungsschicht des ISO/OSI-Modells. Im Gegensatz zu CAN, das komplexere Hardware erfordert, verwendet LIN Standard-UART/SCI-Hardware mit 8N1-Framing und einer festen Baudrate von bis zu 19,2 kbit/s. Typische Buslängen können bis zu 40 Meter betragen. Ursprünglich vom LIN-Konsortium entwickelt, ist LIN jetzt unter ISO 17987 genormt. Die Fehlerbehandlung beschränkt sich auf einfache Mechanismen, wie Paritätsbits im Bezeichner und Prüfsummen im Datenfeld. Es gibt keine eingebauten Übertragungs- oder Korrekturverfahren. Daher muss die Fehlerbehebung auf der Ebene der Anwendung erfolgen.
Rahmenstruktur
Ein LIN-Frame besteht aus zwei Teilen:
- Kopfzeile des Masters: Nachdem der Bus im Leerlauf war, sendet das Master-Steuergerät ein Sync Break (mindestens 13 dominante Bits gefolgt von einem rezessiven Bit). Diese Bitfolge ist das einzige Zeichen, das nicht dem UART-Standard entspricht und daher von jedem Empfänger eindeutig als Beginn einer Nachricht erkannt werden kann. Es folgen ein Sync-Byte, das zur Synchronisation des Empfängertaktes dient, und der LIN-Identifier, der die Datennachricht bestimmt, mit der die Slaves antworten sollen.
- Antwort des Slaves: Genau ein Slave-Steuergerät antwortet mit 2-8 Datenbytes und einem Prüfsummenbyte. LIN unterstützt zwei Arten von Prüfsummen: Classic (nur Daten) und Enhanced (Daten + Kennung).
LIN unterstützt mehrere Frame-Typen, darunter:
- Unbeschränkte Rahmen: Sie werden, wie oben beschrieben, für den Standarddatenaustausch verwendet.
- Ereignisgesteuerte Rahmen : Sie werden für asynchrone Updates verwendet und ermöglichen es mehreren Slave-ECUs, auf dieselbe Nachricht zu antworten. In der Praxis werden nur Steuergeräte antworten, bei denen sich der angeforderte Wert geändert hat. Wenn mehrere Slaves gleichzeitig antworten, kann es zu Kollisionen kommen, die LIN nicht auflösen kann. Daher muss jedes Steuergerät auch einen eindeutigen Identifikator für dieselbe Nachricht haben.
- Sporadische Frames : Mehrere Nachrichten können sich denselben Zeitslot teilen, wobei statische Prioritäten bestimmen, welche Nachricht gesendet wird.
- Diagnostische und benutzerdefinierte Frames : Für Konfiguration und Sonderfunktionen.
- Diese Flexibilität ermöglicht es LIN, sowohl periodische als auch ereignisgesteuerte Kommunikation effizient zu handhaben.
Netzwerktopologie
LIN-Netzwerke verwenden in der Regel eine Bus- oder Daisy-Chain-Topologie, bei der alle Knoten an eine einzige Leitung angeschlossen sind. Der Master-Knoten sorgt für das Timing und die Synchronisierung, so dass eine Arbitrierung nicht erforderlich ist. Die Terminierung erfolgt in der Regel über Pull-up-Widerstände zur Batteriespannung.
Automotive Ethernet – skalierbare Netzwerke mit hoher Bandbreite für das softwaredefinierte Fahrzeug
Da sich Fahrzeuge zu komplexen, softwaredefinierten Systemen entwickeln, stoßen traditionelle Bustechnologien wie CAN und LIN an ihre Grenzen, was Bandbreite, Skalierbarkeit und Flexibilität angeht. Automotive Ethernet hat sich als Backbone der nächsten Generation für die Kommunikation im Fahrzeug etabliert. Es bietet hohe Datenraten, IP-basierte Kommunikation und eine nahtlose Integration in moderne Softwarearchitekturen. Sie ermöglicht anspruchsvolle Funktionen wie Over-the-Air-Updates (OTA), hochauflösende Sensorfusion für ADAS und Echtzeitdatenaustausch für autonomes Fahren.
Die physikalische Implementierung verwendet ein geschaltetes Ethernet-Netzwerk, das je nach Standard der physikalischen Schicht einer Punkt-zu-Punkt- oder Multi-Drop-Topologie folgt. Im Gegensatz zu CAN oder LIN ist die Ethernet-Kommunikation vollduplex und stützt sich auf Ethernet-Switches, die den Verkehr verwalten und Kollisionen verhindern. Jedes Steuergerät ist mit einem Ethernet-Controller (MAC), einem PHY-Transceiver und einem Mikroprozessor ausgestattet. Die Kommunikation basiert auf Standard-Ethernet-Frames, und die Adressierung erfolgt über MAC- und IP-Adressen und nicht über Nachrichtenkennungen. Switches ermöglichen Segmentierung, VLAN-basierte Isolierung und Quality of Service (QoS) für gemischt-kritischen Datenverkehr. In zonalen Architekturen dient Ethernet häufig als Backbone, das zonale Gateways mit Hochleistungsrecheneinheiten verbindet. Diese Gateways ermöglichen auch die Protokollübersetzung in ältere Netze wie CAN oder LIN. Um eine deterministische Kommunikation für sicherheitskritische Anwendungen zu gewährleisten, ermöglicht Ethernet zeitabhängige Netzwerkerweiterungen (Time-Sensitive Networking, TSN), die Zeitsynchronisation, Verkehrsgestaltung und begrenzte Latenzzeiten bieten.
Protokollschichten und physikalische Standards
Ethernet, ursprünglich für Standard-IT-Netzwerke entwickelt, wurde an die strengen Anforderungen des Automobilbereichs angepasst – wie elektromagnetische Verträglichkeit, Robustheit und Kosteneffizienz. Diese Anpassungen haben zur Entwicklung mehrerer automobilspezifischer Normen geführt, die verschiedene Schichten des ISO/OSI-Modells spezifizieren:
Physikalische Schicht |
Es gibt eine Reihe verschiedener Normen, die die Physical Coding Sublayer (PCS), das Physical Medium Attachment (PMA), das Physical Medium Dependent (PMD) und das Medium Dependent Interface (MDI) von Automotive Ethernet spezifizieren. Diese Standards reichen von einer relativ geringen bis zu einer hohen Bandbreite und weisen jeweils unterschiedliche Merkmale auf. Die Bitübertragungsschicht verwendet eine Kombination aus Pulsamplitudenmodulation, Vorwärtsfehlerkorrektur und Echokompensation, um die erforderliche Datenrate über Kabel in Automobilqualität zu erreichen. Verschiedene PHYs verwenden immer komplexere Techniken. Sie geben an, wie die Daten auf dem physikalischen Medium übertragen werden. Die wichtigsten davon sind:
|
Datenübertragungsschicht |
Alle verschiedenen PHYs in Kombination mit Automotive Ethernet verwenden in der Regel die MAC-Schicht (Media Access Control), um den gemeinsamen Zugriff der Geräte auf das physikalische Übertragungsmedium zu verwalten und eine zuverlässige Datenübertragung innerhalb eines lokalen Netzsegments zu gewährleisten. Zu seinen Hauptfunktionen gehören das Einrahmen von Daten mit Quell- und Ziel-MAC-Adressen, die Kontrolle des Zugangs zum Medium, die Erkennung von Übertragungsfehlern über die Frame Check Sequence (FCS) und die Unterstützung der Flusskontrolle zur Vermeidung von Staus. Die MAC-Schicht ist in zwei Teilschichten unterteilt: die LLC-Schicht (Logical Link Control), die eine Schnittstelle zur Netzwerkschicht bildet und für die Protokollidentifizierung, Fehlerprüfung und Flusskontrolle zuständig ist, und die MAC-Schicht, die Rahmen einkapselt, die Adressierung verwaltet und die Medienzugriffsregeln durchsetzt. |
Netzwerkschicht |
Sie verwendet Ethernet zusammen mit dem Internet-Protokoll (IP), um die Kommunikation über lokale Netze hinaus zu ermöglichen. Die standardisierte Übertragung wird durch IP-Pakete erreicht, die eine globale Adressierung der Knoten ermöglichen. Es gibt zwei IP-Versionen: IPv4, das 32-Bit-Adressen in punktierter Dezimalschreibweise verwendet und private Adressbereiche zulässt, und IPv6, das zur Überwindung der IPv4-Beschränkungen entwickelt wurde und Adressen im Hexadezimalformat, getrennt durch Doppelpunkte, darstellt. Zusätzliche Protokolle wie DHCP unterstützen IP durch die automatische Zuweisung von Adressen und die Einbindung neuer Geräte in bestehende Netzwerke. |
Transportschicht |
Die vierte Schicht des OSI-Modells umfasst zwei Transportprotokolle: TCP und UDP. TCP bietet eine verbindungsorientierte Übertragung, während UDP einen verbindungslosen Ansatz bietet. Beide Protokolle teilen die Daten zur effizienten Übertragung in kleinere Einheiten auf, die bei TCP als Segmente und bei UDP als Datagramme bezeichnet werden. TCP ist ein verbindungsorientiertes Protokoll, das mit Hilfe eines Drei-Wege-Handshakes eine zuverlässige Verbindung zwischen zwei Knoten herstellt und durch Neuübertragung und Integritätsprüfungen eine fehlerfreie Datenübertragung gewährleistet. Im Gegensatz dazu ist UDP verbindungslos und bietet eine einfache und schnelle Übertragung von Datagrammen ohne Garantien für die Zustellung oder Fehlerkorrektur. Zu den Vorteilen von UDP gehören die geringe Latenzzeit, da keine Bestätigungen erforderlich sind, und die Unterstützung von Multicast und Broadcast, was es effizient macht, Daten an mehrere Empfänger zu senden. TCP unterstützt jedoch weder Multicast noch Broadcast und wird verwendet, wenn Zuverlässigkeit und geordnete Zustellung wichtig sind. |
Sitzungs-, Präsentations- und Anwendungsschicht |
Die unteren Schichten ermöglichen eine adressierbare, routingfähige Kommunikation zwischen Steuergeräten und externen Systemen. Um Ethernet jedoch für Echtzeit- und sicherheitskritische Anwendungsfälle im Automobilbereich geeignet zu machen, ist eine spezielle Middleware erforderlich. Diese Middleware-Schichten bieten Dienstabstraktion, Nachrichtenserialisierung und Kommunikationsmanagement. Gängige Beispiele:
Diese Technologien ermöglichen dienstorientierte Kommunikation, Publish-Subscribe-Muster und eine effiziente Datenverteilung – wichtige Voraussetzungen für autonomes Fahren, Over-the-Air-Updates und zentralisierte Datenverarbeitung. Automotive Ethernet führt IP-basierte Angriffsflächen ein. Zu den Sicherheitsmaßnahmen gehören MACsec für die Verschlüsselung der Datenübertragungsschicht, IPsec für den Schutz der Netzwerkschicht und TLS für die Sicherheit der Transportschicht. |
Frame-Struktur
Die Grundeinheit der Kommunikation ist der Ethernet-Frame, der die Nutzdaten und Steuerinformationen für die Übertragung über das physikalische Medium kapselt. Das Paket beginnt mit einer Präambel und dem Start Frame Delimiter. Diese wurden ursprünglich eingeführt, um eingehende Daten zu synchronisieren, als Ethernet noch im CSMA/CD-Betrieb verwendet wurde. Bei modernen Standards wird eine komplexere Signalcodierung verwendet, die den Einsatz spezieller Symbole zur Erkennung von Anfang und Ende eines Pakets ermöglicht. Um abwärtskompatibel zu bleiben, sind die Felder Präambel und SFD immer noch Teil des Frames. Jedem Ethernet-Knoten wird eine eindeutige 48-Bit-Seriennummer zugewiesen, die oft als MAC-Adresse bezeichnet wird. Nach der Präambel enthält jedes Paket Informationen darüber, wohin das Paket gesendet werden soll und woher das Paket mit diesen MAC-Adressen kommt. Zunächst wird nur die Zieladresse ausgewertet, um festzustellen, ob ein Paket für diesen Knoten bestimmt ist. Wenn die Zieladresse des Pakets übereinstimmt, wird das Paket vollständig gelesen; wenn nicht, wird es ignoriert. Das nächste Feld gibt entweder die Länge des Pakets oder den EtherType an. Der EtherType gibt an, welche Art von Daten in Bezug auf die höheren Schichten zu erwarten ist. Da Ethernet als Container für jede Art von Daten konzipiert wurde, haben mehrere Ethernet-Varianten ihren eigenen EtherType, z. B. Profinet, EtherCat. Die Nutzlast hat eine Mindestgröße von 46 Byte. Sind die Daten kürzer als die Mindestnutzlast, werden die verbleibenden Bytes mit Füllmaterial aufgefüllt. Die maximale Länge beträgt 1500 Bytes. Das Paket wird mit einer zyklischen Redundanzprüfung (CRC) abgeschlossen, um die Integrität verschiedener Bits des Pakets zu überprüfen.
Netzwerktopologie
Automotive Ethernet verwendet in der Regel eine Punkt-zu-Punkt-Topologie, wobei Switches ein beliebiges Netzwerklayout bilden. Beliebte Optionen sind bspw. ein Stern- oder ein Daisy-Chain-Netzwerk. In zonalen Architekturen kann Ethernet auch in Multi-Drop-Konfigurationen, z. B. mit 10BASE-T1S, verwendet werden, um den Verdrahtungsaufwand zu reduzieren.
FlexRay – Deterministische Kommunikation für sicherheitskritische Systeme
Als Automobilsysteme immer höhere Anforderungen an Zuverlässigkeit, Fehlertoleranz und Echtzeitleistung stellten, entwickelte sich FlexRay zu einer robusten Lösung. Besonders in sicherheitskritischen Bereichen wie X-by-wire-Anwendungen (X = Bremsen, Lenken ...) bot es Vorteile. FlexRay wurde von einem Konsortium führender Automobilhersteller und -zulieferer entwickelt, um die Einschränkungen von CAN und LIN zu überwinden, indem es eine deterministische Hochgeschwindigkeitskommunikation mit eingebauter Redundanz bietet.
Die physische Implementierung besteht aus einem FlexRay-Controller, einem Transceiver und einem Mikroprozessor. Ein optionaler Buswächter sorgt für die Einhaltung des Kommunikationsplans und verhindert, dass fehlerhafte Knoten das Netz stören. FlexRay unterstützt Einkanal- oder Zweikanal-Konfigurationen. Der zweite Kanal kann zur Redundanz in sicherheitskritischen Systemen oder zur Bandbreitenaggregation genutzt werden. Der zweikanalige Betrieb und der Buswächter erhöhen die Zuverlässigkeit. Im Gegensatz zu ereignisgesteuerten Protokollen verwendet FlexRay ein deterministisches TDMA-Verfahren (Time Division Multiple Access). Übertragungsrechte und Nachrichten werden festen Zeitslots innerhalb eines Kommunikationszyklus zugewiesen. Das statische Segment verwendet Slots fester Länge für zeitkritische Nachrichten, während das dynamische Segment Mini-Slots und positionsbasierte Arbitrierung für ereignisgesteuerte Nachrichten einsetzt. Dieser hybride Ansatz gewährleistet eine vorhersehbare Zeitplanung und bietet gleichzeitig Flexibilität für weniger kritische Daten.
Protokollschichten und Merkmale
FlexRay arbeitet auf der physikalischen und der Datenübertragungsschicht des ISO/OSI-Modells. Sie ist in der Norm ISO 17458 festgelegt, wobei die Teile 2 und 3 die Datenübertragungsschicht und die Teile 4 und 5 die physikalische Schicht abdecken. Mit dem FlexRay Transport Protocol (FrTp) aus dem AUTOSAR-Standard deckt es auch die Transportschicht ab. FlexRay unterstützt Datenraten von bis zu 10 Mbit/s pro Kanal. Bei Verwendung der beiden Kanäle zur Bandbreitenaggregation verdoppelt sich die Datenrate. Das Protokoll bietet eine globale Zeitsynchronisation über alle Knoten hinweg, die in Kommunikationszyklen und Makrozyklen organisiert ist und eine deterministische Ausführung in allen Steuergeräten gewährleistet. FlexRay bietet keine native Verschlüsselung oder Authentifizierung. Sicherheitsmaßnahmen wie AUTOSAR SecOC oder gatewaybasierte Filterung sind erforderlich.
Frame-Struktur
FlexRay unterstützt statische Segmente (für zeitgesteuerte Nachrichten) und dynamische Segmente (für ereignisgesteuerte Kommunikation) und bietet damit einen hybriden Ansatz, der Determinismus und Flexibilität in Einklang bringt. Die Gesamtzahl der Slots für die statischen und dynamischen Teile ist auf 2047 begrenzt.
- Das statische Segment : Verwendet eine vordefinierte Anzahl von Slots, wobei jeder Slot lang genug ist, um eine vollständige FlexRay-Nachricht zu übertragen. Die Nachrichten innerhalb des statischen Segments werden für beide Kanäle synchronisiert. Um Kollisionen zu vermeiden, werden die Übertragungsrechte jeweils an ein einzelnes Steuergerät vergeben. Jedes Steuergerät zählt den Slot eines jeden Kommunikationszyklus. Der Slot-Zähler zeigt an, welches Steuergerät gerade den Buszugriff hat.
- Die dynamischen Slots : Auch hier werden vordefinierte Slots verwendet, die jedoch in Minislots aufgeteilt sind, die kürzer sind als die Slots im dynamischen Segment. Während dieser Slots darf genau ein Steuergerät auf jedem Kanal unabhängig voneinander senden. Die Länge der Nachrichten kann variieren (bis zu 254 Byte), aber die Gesamtlänge des dynamischen Segments ist fest. In diesem Fall gibt der Slot-Zähler die Priorität der Nachricht an. Wenn eine Nachricht mit einem hohen Slotzähler während eines Kommunikationszyklus nicht übertragen werden kann, wird sie auf den nächsten Zyklus verschoben.
Eine FlexRay-Nachricht beginnt mit einem Header. Dieser Header wird durch fünf Steuerbits initialisiert und enthält die Frame-ID, die Nutzdatenlänge, einen designierten Header-CRC und den Cycle Count. Die Frame-ID ist die Nummer des aktuellen Zeitslots. Die Länge der Nutzlast wird als Anzahl der 16-Bit-Datenwörter übertragen. Der Header-CRC schützt vor Übertragungsfehlern, und der endgültige Zykluszähler übermittelt die Anzahl der Kommunikationszyklen, die das Netz seit seiner Initialisierung inkrementiert hat. Es folgen die eigentlichen Nutzdaten sowie ein Trailer-CRC zur Nutzdatenfehlererkennung.
Netzwerktopologie
FlexRay-Netzwerke verwenden in der Regel eine zweikanalige Leitungstopologie, wobei der zweite Kanal für erhöhte Redundanz in sicherheitskritischen Systemen verwendet wird. Abschlusswiderstände sind an den Enden des Busses bzw. an den dort befindlichen Steuergeräten erforderlich. Der maximale Abstand zwischen zwei Steuergeräten beträgt normalerweise 24 Meter. Die Verwendung mit einer einkanaligen Sterntopologie ist möglich, aber eher unüblich.
Vergleichstabelle
Kriterium |
CAN |
LIN |
FlexRay |
Automotive Ethernet |
Primärer Zweck |
Robuste Echtzeikommunikation für Steuergeräte | Kostengünstige Kommunikation für einfache Aktoren/Sensoren | Deterministische Kommunikation für sicherheitskritische Systeme | Skalierbare Kommunikation mit hoher Bandbreite für softwaredefinierte Fahrzeuge |
Typische Anwendungen |
Antriebsstrang, Fahrwerk, Karosseriekontrolle, Diagnose | Komfortfunktionen (Fenster, Klima, Sitze) | X-by-Wire (Bremsen, Lenkung), Sicherheitsdomänen | ADAS, Infotainment, Sensorfusion, OTA-Updates, Kommunikations-Backbone |
Topologie |
Bus (2-Draht-Differential) | Bus/Daisy-Chain (Einzelader) | Stern oder Linie (Einzel- oder Doppeldrahtverwendung möglich) | Punkt-zu-Punkt (geschalteter Stern), Multi-Drop (10BASE-T1S) |
Determinismus |
Ereignisgesteuert (prioritätsbasiert) | Master-Slave mit einem statischen Zeitplan | Zeitgesteuert (TDMA, statische + dynamische Segmente) | Deterministisch mit TSN (Time-Sensitive Networking) |
Bandbreite |
Bis zu 1 Mbit/s (Classic), bis zu 8 Mbit/s (CAN FD), >10 Mbit/s (CAN XL) | Bis zu 19,2 kbit/s | 10 Mbit/s pro Kanal (20 Mbit/s aggregiert) | 10 Mbit/s - 10 Gbit/s (10BASE-T1S bis MultiGBASE-T1) |
Nutzlast |
8 Bytes (Classic), 64 Bytes (CAN FD), >64 Bytes (CAN XL) | 2-8 Bytes | Bis zu 254 Bytes | Bis zu 1500 Bytes (Standard Frame) |
Fehlerbehandlung |
CRC, Bit-Überwachung, Fehlereinschränkung | Paritätsbit, Prüfsumme, keine Korrektur | CRC, Bus Guardian, zweikanalige Redundanz |
CRC, FEC (für hohe Geschwindigkeiten), VLAN/QoS zur Isolierung des Datenverkehrs |
Sicherheit |
Schutz auf höherer Ebene (z. B. SecOC) | Keine native Sicherheit | Schutz auf höherer Ebene (z. B. SecOC) | MACsec, IPsec, TLS oder SecOC erforderlich |
Standardisierung |
ISO 11898 | ISO 17987 | ISO 17458 | IEEE 802.3 + TSN (IEEE 802.1) |
Kosten und Komplexität |
gering | Sehr gering | hoch | Mittel bis hoch |
Ausblick |
Bleibt relevant für lokale Steuergeräte | Bleibt relevant für Komfortfunktionen | Rückläufig; Ethernet ersetzt | Zentrale Rolle in zonalen Architekturen |
Overview Automotive Ethernet SOME/IP
This poster gives an introduction into Automotive Ethernet SOME/IP which is the foundation for service-oriented communication in modern E/E architectures. (download below)
PDF, 82.2 KB
1. Warum ist die bordeigene Kommunikation wichtig?
2. Was sind die wichtigsten Arten von Busprotokollen, die in Fahrzeugen verwendet werden?
Zu den gängigsten Protokollen gehören:
- CAN (Controller Area Network) – Fehlertolerante Kommunikation in Echtzeit für Steuergeräte.
- LIN (Local Interconnect Network) – Kostengünstiges Protokoll für einfache Aktoren und Sensoren.
- FlexRay – Deterministische Hochgeschwindigkeitskommunikation für sicherheitskritische Systeme.
- Automotive Ethernet – Skalierbares Netzwerk mit hoher Bandbreite für softwaredefinierte Fahrzeuge.
3. Was ist der Unterschied zwischen domänenbasierten und zonalen Architekturen?
4. Wie behandelt das CAN-Protokoll Nachrichtenpriorität und Kollisionen?
5. Was sind die wichtigsten Neuerungen bei CAN-Varianten wie CAN FD und CAN XL?
CAN FD erweitert das traditionelle CAN-Protokoll, indem es sowohl die Größe der Nutzlast als auch die Datenrate erhöht und damit eine schnellere und effizientere Datenübertragung ermöglicht. Darauf aufbauend erweitert CAN XL die verfügbare Bandbreite und ist darauf ausgelegt, komplexere und anspruchsvollere Anwendungen zu unterstützen.
6. Wofür ist das LIN-Protokoll am besten geeignet?
7. Wie unterscheidet sich Automotive Ethernet von herkömmlichen Bussystemen?
8. Was sind SOME/IP und DDS im Zusammenhang mit Ethernet?
9. Welche Sicherheitsmaßnahmen werden bei Automotive Ethernet eingesetzt?
10. Was ist FlexRay und wo wird es eingesetzt?
11. Können verschiedene Busprotokolle in einem Fahrzeug koexistieren?
12. Welche Werkzeuge bietet dSPACE für die Entwicklung und den Test der Buskommunikation an?
dSPACE bietet eine umfassende Werkzeugkette:
- Buskonfigurationswerkzeuge wie Bus Manager für die Modellierung und Bearbeitung der CAN/LIN/Ethernet/FlexRay-Kommunikation
- SCALEXIO für Signalabbildung und Simulation
- SystemDesk und VEOS für die Erstellung und den Test von V-ECUs
- Adaptive-AUTOSAR-Schulungsmaterialien zum Verständnis serviceorientierter Architekturen
