Einschränkungen klassischer CAN-Netzwerke

CAN CC ist für eine robuste Echtzeitkommunikation konzipiert, unterliegt jedoch physikalischen und logischen Beschränkungen. Mit zunehmender Bitrate verringert sich die maximal zulässige Buslänge aufgrund von Signallaufzeiten und Problemen mit der Signalintegrität. Bei 1 Mbit/s liegt die typische Obergrenze bei etwa 40 Metern. In groß angelegten Systemen – wie etwa solchen mit Dutzenden von CAN-Knoten (z. B. 64 Geräte) – verschärfen sich diese Beschränkungen noch weiter. Ein einzelner physikalischer Bus würde hierbei nicht nur die zulässige Länge überschreiten, sondern auch Arbitrierungskonflikte hervorrufen, falls mehrere Geräte gleichzeitig identische Identifier senden. Eine weitere zentrale Herausforderung stellt der begrenzte Identifier-Raum dar: Alle Knoten auf einem CAN-Bus teilen sich denselben ID-Namensraum. Verwenden mehrere Geräte identische CAN-Identifier, kommt es zu Arbitrierungskonflikten oder einer fehlerhaften Dateninterpretation. Dies erweist sich insbesondere in Umgebungen als problematisch, in denen Geräte feste oder fest programmierte CAN-IDs nutzen. Ohne entsprechende Anpassungen ist die Integration solcher Geräte in ein gemeinsames Netzwerk aufgrund unvermeidlicher ID-Kollisionen nicht realisierbar. Darüber hinaus steigt die Systemlast mit zunehmendem Netzwerkverkehr an. Jedes CAN-Frame löst einen Interrupt aus, was die CPU bei hohen Nachrichtenratn erheblich belasten kann.

Tabelle 1: Vergleich Standard CAN vs. CAN-over-UDP

 

CAN-over-Ethernet als architektonischer Ansatz

Um diese Einschränkungen zu überwinden, können CAN-Daten über Ethernet übertragen werden. Einzelne CAN-Frames werden in UDP/IP-Pakete gekapselt und über eine standardmäßige Ethernet-Infrastruktur versendet. Auf diese Weise entsteht ein virtueller CAN-Bus, der nicht mehr durch die physikalischen Beschränkungen des Busses limitiert ist. In einer praktischen Anwendung wird jeder CAN-Knoten mit einem dedizierten CAN-zu-Ethernet-Gateway verbunden. Diese Gateways bilden ein verteiltes System, das über einen Ethernet-Switch vernetzt ist und den einzelnen, gemeinsam genutzten CAN-Bus faktisch durch ein virtuelles, skalierbares Backbone ersetzt. Diese Entkopplung ermöglicht flexible und verteilte Systemarchitekturen.

UDP als Transportprotokoll

Als Transportprotokoll wurde bewusst UDP gewählt. Im Gegensatz zu TCP ist UDP verbindungslos und verzichtet auf Mechanismen wie Handshakes, Flusskontrolle und Neuübertragungen. Dies führt zu einer geringeren Latenz und einem deterministischeren Verhalten – Eigenschaften, die für die zeitkritische CAN-Kommunikation unerlässlich sind. Ein weiterer Vorteil ist die Verarbeitungseffizienz: Mehrere CAN-Frames lassen sich zu einem einzigen UDP-Paket zusammenfassen, wodurch die Anzahl der Interrupts auf dem Empfangssystem reduziert wird. Dies senkt die CPU-Auslastung und verbessert die gesamte Systemleistung.

Multicast zur Nachbildung des CAN-Broadcast-Verhaltens

Ein prägendes Merkmal von CAN ist sein Broadcast-Kommunikationsmodell, bei dem jede Nachricht für alle Knoten sichtbar ist. UDP-Multicast ermöglicht es, dieses Verhalten weitgehend nachzubilden: Ein Sender übermittelt ein einzelnes Paket an eine Multicast-Gruppe, das von allen abonnierten Knoten empfangen wird. Anstatt mehrere Punkt-zu-Punkt-Verbindungen aufzubauen, übernimmt die Netzwerkinfrastruktur die Verteilung der Pakete. Dies reduziert die Last auf dem Sender und ermöglicht eine effiziente Eins-zu-Viele-Kommunikation – ähnlich wie bei einem physischen CAN-Bus. 

Abbildung 1: Broadcast-Kommunikation via UDP-Multicast, bei der jede Nachricht für alle Knoten sichtbar ist.

Mechanismen für Skalierbarkeit und Entkopplung

Ein zentrales Element der Architektur ist die Trennung von lokalen und globalen Identifier-Räumen. CAN-Identifier, die lokal wiederverwendet werden, können mithilfe von Mapping-Mechanismen global eindeutig gemacht werden. Eingehende CAN-Frames werden erweitert oder übersetzt, um eine eindeutige Identifizierung über das gesamte System hinweg zu gewährleisten. In der Praxis lässt sich dies realisieren, indem ein eindeutiger Geräte-Identifier in den übertragenen Frame eingebettet wird oder indem standardmäßige 11-Bit-Identifier für das Ethernet-Backbone in eindeutige, erweiterte 29-Bit-Identifier übersetzt werden. Dies stellt eine kollisionsfreie Kommunikation sicher – selbst dann, wenn alle Knoten intern identische CAN-IDs, wie beispielsweise 0x100, verwenden.

Gleichzeitig wird die Datenverteilung selektiv gesteuert. Anstatt alle verfügbaren Nachrichten an jeden Knoten weiterzuleiten, werden lediglich die relevanten Frames übertragen. Dies wird durch konfigurierbare Filtermechanismen erreicht, die eine Überlastung der lokalen CAN-Segmente verhindern. In realen Systemen erfolgt die Umsetzung hierfür mittels Abonnement- oder „Interessen“-Tabellen innerhalb des Gateways. Jeder Knoten empfängt lediglich jene Teilmenge an Nachrichten, die er tatsächlich benötigt; hierdurch wird eine unnötige Belastung der lokalen CAN-Schnittstelle vermieden. Ein weiterer wichtiger Aspekt ist die Lastreduktion durch Paketaggregation. Durch das Bündeln mehrerer CAN-Frames in einem einzigen UDP-Paket wird der Verarbeitungs-Overhead minimiert und eine effizientere Nutzung der Netzwerkressourcen ermöglicht.

Abbildung 2: Eingehende CAN-Frames werden erweitert oder übersetzt, um eine eindeutige Identifizierung über das gesamte System hinweg sicherzustellen.

Bewahrung der CAN-Eigenschaften

Bei der Übertragung von CAN-Daten über Ethernet ist es unerlässlich, die wesentlichen Merkmale des Protokolls beizubehalten. Ein entscheidender Aspekt ist dabei die Nachrichtenpriorisierung. Im CAN-Protokoll wird die Priorität während der Arbitration durch den Identifier bestimmt. Im Ethernet lässt sich dies auf QoS-Mechanismen oder IP-Prioritätsfelder abbilden, um sicherzustellen, dass Nachrichten mit hoher Priorität entsprechend verarbeitet werden. Ebenso wichtig ist das zeitliche Verhalten. Durch das Einbetten hochauflösender Zeitstempel in UDP-Pakete lassen sich die ursprünglichen zeitlichen Zusammenhänge der CAN-Frames auf Empfängerseite rekonstruieren. Dies trägt dazu bei, Jitter zu minimieren und ein deterministisches Systemverhalten zu gewährleisten. Die Datenintegrität wird durch einen mehrschichtigen Schutzmechanismus sichergestellt. Ergänzend zum CRC-Mechanismus des CAN-Protokolls bietet die UDP-Prüfsumme eine zusätzliche Ebene zur Fehlererkennung während der Ethernet-Übertragung.

Abbildung 3: Vernetzung verteilter CAN-Knoten mittels eines CAN-zu-Ethernet-Gateways und eines zentralen Ethernet-Switches. 

Fazit

Die Kombination aus UDP und Multicast ermöglicht eine effiziente Erweiterung klassischer CAN-Netzwerke über Ethernet. Physische Beschränkungen werden aufgehoben, die Skalierbarkeit wird signifikant verbessert und die wesentlichen Merkmale der CAN-Kommunikation bleiben erhalten. Dieser Ansatz bildet ein solides Fundament für moderne verteilte Systemarchitekturen in Industrie- und Automotive-Umgebungen.

Für die praktische Umsetzung stehen dedizierte Gateway-Lösungen zur Verfügung, die diese Mechanismen integrieren und eine nahtlose Vernetzung zwischen CAN- und Ethernet-Netzwerken ermöglichen. 

Wenn Sie diese Funktionalität nutzen möchten, werfen Sie bitte einen Blick auf das Ixxat CAN@net basic Gateway oder das PCAN-Ethernet Gateway DR:
 

CAN@net basic Gateway        PCAN-Ethernet Gateway DR