Limitations of Classical CAN Networks

CAN CC is designed for robust and real-time communication, but it is bound by physical and logical constraints. As the bitrate increases, the maximum allowable bus length decreases due to propagation delays and signal integrity issues. At 1 Mbit/s, the typical limit is around 40 meters. In large-scale setups, such as systems with dozens of CAN nodes (e. g., 64 devices), these constraints become even more severe. A single physical bus would not only exceed the allowable length but also introduce arbitration conflicts if multiple devices transmit identical identifiers simultaneously. Another key challenge is the restricted identifier space. All nodes on a CAN bus share the same ID namespace. If multiple devices use identical CAN identifiers, arbitration conflicts or incorrect data interpretation occur. This becomes particularly problematic in environments where devices use fixed or hardcoded CAN IDs. Without modification, integrating such devices into a shared network is not feasible due to unavoidable ID collisions. In addition, system load increases with network traffic. Each CAN frame generates an interrupt, which can significantly burden the CPU at high message rates.

Table 1: Comparison CAN Standard vs. CAN-over-UDP

 

CAN-over-Ethernet as an Architectural Approach

To overcome these limitations, CAN data can be transported over Ethernet. Individual CAN frames are encapsulated into UDP/IP packets and transmitted via a standard Ethernet infrastructure. This creates a virtual CAN bus that is no longer constrained by physical bus limitations. In a practical deployment, each CAN node is connected to a dedicated CAN-to-Ethernet gateway. These gateways form a distributed system connected via an Ethernet switch, effectively replacing the single shared CAN bus with a virtual, scalable backbone. This decoupling enables flexible and distributed system designs.

UDP as Transport Protocol

UDP is intentionally chosen as the transport protocol. Unlike TCP, UDP is connectionless and avoids mechanisms such as handshakes, flow control, and retransmissions. This results in lower latency and more deterministic behavior, which is essential for time-critical CAN communication. Another advantage is processing efficiency. Multiple CAN frames can be aggregated into a single UDP packet, reducing the number of interrupts on the receiving system. This lowers CPU load and improves overall system performance.

Multicast to Replicate CAN Broadcast Behavior

A defining characteristic of CAN is its broadcast communication model, where every message is visible to all nodes. UDP Multicast allows this behavior to be closely replicated. A sender transmits a single packet to a multicast group, which is received by all subscribed nodes. Instead of establishing multiple point-to-point connections, the network infrastructure handles packet distribution. This reduces the load on the sender and enables efficient one-to-many communication, similar to a physical CAN bus. 

Image 1: Broadcast communication via UDP Multicast, where every message is visible to all nodes.

Mechanisms for Scalability and Decoupling

A key element of the architecture is the separation of local and global identifier spaces. CAN identifiers that are reused locally can be made globally unique through mapping mechanisms. Incoming CAN frames are extended or translated to ensure unique identification across the entire system. Practically, this can be implemented by embedding a unique device identifier into the transmitted frame or by translating standard 11-bit identifiers into unique 29-bit extended identifiers for the Ethernet backbone. This ensures collision-free communication even when all nodes internally use identical CAN IDs such as 0x100.

At the same time, data distribution is controlled selectively. Instead of forwarding all available messages to every node, only relevant frames are transmitted. This is achieved through configurable filtering mechanisms, preventing overload on local CAN segments. In real-world systems, this is implemented via subscription or “interest” tables within the gateway. Each node only receives the subset of messages it actually requires, avoiding unnecessary load on the local CAN interface. Another important aspect is load reduction through packet aggregation. By bundling multiple CAN frames into a single UDP packet, processing overhead is minimized and network resources are used more efficiently.

Image 2: Incoming CAN frames are extended or translated to ensure unique identification across the entire system.

Preserving CAN Characteristics

When transmitting CAN data over Ethernet, it is essential to maintain the protocol’s key characteristics. One critical aspect is message prioritization. In CAN, priority is determined by the identifier during arbitration. In Ethernet, this can be mapped to QoS mechanisms or IP priority fields to ensure that high-priority messages are handled accordingly. Timing behavior is equally important. By embedding high-resolution timestamps into UDP packets, the original timing relationships of CAN frames can be reconstructed at the receiver. This helps to minimize jitter and maintain deterministic system behavior. Data integrity is ensured through layered protection. In addition to the CRC mechanism of CAN, the UDP checksum provides an extra layer of error detection during Ethernet transmission.

Image 3: Linking of distributed CAN nodes using a CAN-to-Ethernet gateway and a central Ethernet switch. 

Conclusion

The combination of UDP and Multicast enables an efficient extension of classical CAN networks over Ethernet. Physical limitations are removed, scalability is significantly improved, and the essential characteristics of CAN communication are preserved. This approach provides a solid foundation for modern distributed system architectures in industrial and automotive environments.
For practical implementation, dedicated gateway solutions are available that integrate these mechanisms and enable seamless connectivity between CAN and Ethernet networks. 

If you want to use this functionality, please have a look at the Ixxat CAN@net basic Gateway or the PCAN-Ethernet Gateway DR:
 

CAN@net basic Gateway        PCAN-Ethernet Gateway DR