Choosing between CAN, CAN FD and Ethernet industrial links

This decision gets made badly in two directions. Teams keep classic CAN because “it has always worked” and then spend a year fighting bus-load and 8-byte frames. Or they jump to industrial Ethernet everywhere and discover it costs more per node, needs managed switches, and still does not give them determinism unless they configured it for it.

Here is how the three actually differ, and what each is bad at.

Classic CAN (ISO 11898-1/-2)

What it is: a multi-drop differential bus, up to 1 Mbit/s, 8 data bytes per frame, non-destructive bitwise arbitration by identifier, strong error detection (15-bit CRC, bit monitoring, form/stuff checks) with automatic retransmission.

What it is genuinely good at:

• Cost and ruggedness. A CAN transceiver is cents. The bus is two wires, no switch, no hub, tolerant of ground shift and EMI, and it degrades gracefully — a node dropping off does not take the segment down.
• Event-driven traffic with priority. Arbitration means the lowest-numbered ID always wins the bus with no collisions and no configuration. For “report this alarm now” traffic that is exactly right.
• Determinism at low load. Below roughly 30–40% bus load, worst-case latency for a given priority is calculable and small.
• Ecosystem. CANopen, J1939, and decades of tooling, diagnostics, and engineers who know it.

What it is bad at — state these before choosing it:

• 8 bytes. A 12-axis sensor packet or any structured record needs fragmentation (ISO-TP), which adds latency, state, and failure modes.
• 1 Mbit/s ceiling, and you only reach it on a short bus. At 1 Mbit/s the practical bus length is on the order of 40 m; longer buses force lower rates because arbitration needs the signal to propagate to the far end within a bit.
• Bus load cliff. Above ~50–60% load, low-priority frames see large and hard-to-bound latency, and a chatty node can starve them entirely.
• No native security. No authentication, no encryption; any node can send any ID. Mitigations exist (bus guardians, MACsec-style add-ons, segmentation) but they are bolt-ons.
• A single retransmitting faulty node can dominate the bus until error confinement kicks in.

CAN FD (ISO 11898-1:2015)

What it changes: up to 64 data bytes per frame, and a second, faster bit rate for the data phase (commonly 2–5 Mbit/s, 8 Mbit/s achievable with care) while the arbitration phase stays at the classic rate. Better CRC (17- or 21-bit) for the larger payload.

Why it is often the right upgrade:

• The 8-byte problem disappears without fragmentation. One 64-byte frame instead of eight classic frames means less protocol overhead and less software state.
• Effective throughput rises several-fold for payload-heavy traffic, because both the payload is bigger and the data phase is faster.
• You keep the topology, the transceivers’ ruggedness, the arbitration model, and most of the tooling. It is an incremental change, not a re-architecture.
• CANopen FD and J1939 variants exist to carry the ecosystem forward.

What it is bad at / what to watch:

• The arbitration phase is still limited to the classic bit rate. CAN FD does not raise the number of frames per second you can arbitrate; it raises the bytes per frame. A system that is frame-rate-bound, not payload-bound, gets little from it.
• Signal integrity gets harder. The fast data phase shrinks bit times to hundreds of nanoseconds; ringing, stub length, connector quality, and transceiver loop delay now matter. A messy bus that tolerated 500 kbit/s classic will not tolerate 5 Mbit/s FD without topology work and possibly ring or point-to-point rather than long stubs.
• Mixed classic/FD segments need care. A classic-only node on an FD bus sees FD frames as errors and floods the bus unless partial networking / FD-tolerant transceivers are used. Usually the whole segment must be FD.
• Controller support: older MCUs have classic-only CAN peripherals. Check the silicon, not the datasheet marketing.

Switched industrial Ethernet — PROFINET, EtherCAT, and TSN

Not one thing. “Industrial Ethernet” covers protocols with very different determinism stories, all on 100 Mbit/s or 1 Gbit/s PHYs.

• PROFINET RT — standard switched Ethernet, prioritised frames, cycle times down to ~1 ms; PROFINET IRT adds hardware time-slotting for sub-millisecond, low-jitter cycles but needs IRT-capable switches.
• EtherCAT — a single frame passes through every node, each reading and writing its slice on the fly (“processing on the fly”). Extremely efficient, cycle times to tens of microseconds, but it is a specific master/slave topology with EtherCAT slave controllers in each node, not general IP networking.
• TSN (IEEE 802.1 set — 802.1AS, Qbv, Qci, CB, …) — brings scheduled, bounded-latency traffic to standard Ethernet, letting control traffic and IT traffic share the same infrastructure. It is the direction the industry is moving; it also requires TSN-capable switches and endpoints and non-trivial network engineering (a schedule computed and pushed to every bridge).

What Ethernet buys you:

• Bandwidth: 100–1000 Mbit/s, so video, firmware images, and high-channel- count data are no longer a problem.
• Routable, IT-integratable: TCP/IP, TLS, MQTT/OPC UA to the cloud on the same wire (with segmentation and a firewall).
• Determinism if configured for it: IRT, EtherCAT, or TSN give bounded latency and low jitter — but plain “Ethernet” does not; a standard switch under load has queueing delay and no guarantees.

What it is bad at:

• Cost and complexity per node: a PHY, magnetics or connector, often a managed or special switch, more powerful MCU/SoC, and a stack. Multiples of a CAN node.
• Topology and cabling: star or line with switches, 100 m segment limit per hop, more connectors, more to go wrong mechanically in a vibrating machine.
• Determinism is opt-in and fragile to misconfiguration. A well-meaning IT change, a non-TSN device plugged into a TSN segment, or an unmanaged switch dropped in “temporarily” can quietly break the timing guarantees.
• Security surface: now you are on an IP network, with everything that implies. IEC 62443 becomes your problem.

A decision order that works

1. What is the largest single payload, and how often? ≤ 8 bytes, event-rate → classic CAN is still fine. 8–64 bytes → CAN FD. Kilobytes, or any streaming → Ethernet.
2. What is the tightest cycle time with bounded jitter you must hit? Above 5–10 ms and modest, CAN/CAN FD or PROFINET RT. Around 1 ms, PROFINET IRT or CAN FD on a lightly loaded bus. Under 250 µs with many axes, EtherCAT. Mixed critical and best-effort on one wire, TSN.
3. Node count, cost target, and environment. Dozens of cheap rugged nodes on a harness → bus wins. A cell with a handful of high-value devices and a video feed → Ethernet.
4. Does it need to talk to IT / cloud directly? Yes and at rate → Ethernet. Occasionally → keep the fieldbus and put the IP stack in the gateway.
5. Who maintains it for ten years? A plant electrician can fault-find a CAN bus with a multimeter. A TSN schedule needs someone who understands 802.1Qbv.

The realistic answer is usually “bridge”

Greenfield-everything-Ethernet is rare. The common shape is CAN or CAN FD at the machine edge for sensors and drives, aggregated by a gateway that speaks the fieldbus on one side and OPC UA / MQTT over Ethernet on the other, doing protocol translation, buffering across link outages, and store-and-forward. That gateway is also the right place to put the security boundary, the data-model mapping, and the firmware-update path — rather than pushing all of that cost into every edge node.

Designing that seam well — which data is published at what rate, what is buffered, how backpressure and reconnection behave — is usually more of the engineering effort than picking the physical layer.