CAN · Ethernet

UDP Multicast for CAN-over-Ethernet: scalable networking beyond physical limits

CAN data can be efficiently tunneled over Ethernet using UDP Multicast, preserving CAN characteristics while overcoming its physical and logical limitations.

The limits of classic CAN networks

Classic CAN is designed for robust, real-time communication, but it remains bounded by physical and logical constraints. As the bit rate increases, the allowable bus length decreases, due to propagation delays and signal integrity: at 1 Mbit/s, the typical limit is about 40 meters. In large deployments — dozens of nodes, for example 64 devices — these constraints become critical. A single physical bus would not only exceed the allowable length but would also introduce arbitration conflicts if several devices simultaneously transmitted identical identifiers.

Another challenge: the limited identifier space. All nodes share the same ID namespace. If several devices use identical CAN identifiers, arbitration conflicts or misinterpretations occur — especially problematic with fixed or hard-coded IDs. Finally, system load grows with traffic: every CAN frame generates an interrupt, which can heavily burden the CPU at high message rates.

CAN-over-Ethernet as an architectural approach

To overcome these limitations, CAN data can be transported over Ethernet. Individual CAN frames are encapsulated in UDP/IP packets and transmitted via a standard Ethernet infrastructure. This creates a virtual CAN bus free of the physical bus's limitations. In practice, each CAN node is connected to a dedicated CAN-Ethernet gateway; these gateways form a distributed system connected by an Ethernet switch, replacing the single shared CAN bus with a scalable virtual backbone.

UDP as transport protocol

UDP is chosen deliberately. Unlike TCP, it is connectionless and avoids handshakes, flow control, and retransmissions, resulting in lower latency and more deterministic behavior, essential for real-time CAN communication. Another advantage is processing efficiency: several CAN frames can be aggregated into a single UDP packet, reducing the number of interrupts on the receiver side, and thus the CPU load.

Multicast to replicate CAN broadcast

A characteristic feature of CAN is its broadcast model: every message is visible to all nodes. UDP Multicast faithfully replicates this behavior: a sender transmits a single packet to a multicast group, received by all subscribed nodes. The network infrastructure handles distribution, relieving the sender and enabling efficient one-to-many communication, similar to a physical CAN bus.

Scalability and decoupling mechanisms

Key element: the separation of local and global identifier spaces. Locally reused CAN identifiers can be made globally unique through mapping. In practice, a unique device identifier is embedded in the transmitted frame, or the standard 11-bit identifiers are translated into unique 29-bit extended identifiers for the Ethernet backbone. Communication remains collision-free even if all nodes internally use identical IDs, for example 0x100.

Distribution is also selective: instead of transmitting everything to every node, only relevant frames are sent, via filtering and subscription ("interest") tables within the gateway. Each node only receives the subset of messages it actually needs. Finally, aggregating several CAN frames into a single UDP packet minimizes processing overhead and optimizes network resource usage.

Preserve CAN characteristics

It is essential to preserve the protocol's key properties. Message prioritization, determined by the identifier during CAN arbitration, can be mapped to QoS mechanisms or IP priority fields. Timing behavior is reconstructed using high-resolution timestamps embedded in UDP packets, which minimizes jitter. Data integrity is ensured through layered protection: the CAN CRC is supplemented by the UDP checksum during Ethernet transmission.

Conclusion