Industrial and mobile-machine designers are being presented with three increasingly relevant CAN choices: Classical CAN, CAN FD and CAN XL. The engineering mistake is to treat this as a simple protocol-upgrade exercise. In practice, the right decision depends on where bandwidth is actually limiting the system, how many legacy nodes must remain, how the machine is diagnosed and maintained, and whether multiple CAN-based subsystems will eventually need a higher-capacity backbone.
For Malaysian machine builders, system integrators and plant engineering teams, the sensible 2026 position is straightforward: use CAN FD where it solves a real problem today, preserve compatibility with the installed CAN base, and stop creating architectures that will make CAN XL unnecessarily difficult to introduce later.
What has changed in 2026
CAN in Automation (CiA) reported in June that CAN FD installations are ramping up, with automakers already migrating parts of in-vehicle networks and non-automotive sectors following. The related higher-layer ecosystem is also maturing: CiA 1301 and CiA 1305 define key CANopen FD functions, while SAE J1939-17 and J1939-22 address J1939 operation over CAN FD.
The latest CiA CAN Community News of 21 August 2026 adds another useful signal. CiA reported that the CiA 1302-1 and CiA 1302-2 CANopen FD application-layer documents have been finalised internally, and that a new series of CAN XL webinars is being planned. CiA is also discussing next-generation CAN use in rolling-stock systems, where CAN and CANopen continue to move deeper into embedded subsystems such as HVAC, braking and cab equipment.
CAN XL is important because it is more than a faster CAN frame. CiA has highlighted its role as a possible backbone for heterogeneous CAN-based subsystems. Its additional fields, including the Service Data Unit Type and Virtual CAN Network Identifier, are intended to help distinguish higher-layer protocols and logical networks. Kvaser describes CAN XL as supporting payloads up to 2048 bytes and data rates above 10 Mbit/s, while retaining a migration relationship with CAN FD and Classical CAN. Kvaser also states that it is developing its own CAN XL IP core.
Do not replace a working CAN network simply because CAN XL exists
CAN XL should not be used as an excuse for premature hardware replacement. Many industrial networks are not bandwidth-limited. A properly designed Classical CAN or CAN FD network can remain entirely appropriate for deterministic control, distributed I/O, drives, sensors and machine subsystems.
The stronger reason to review the architecture is when one or more of these conditions appear:
- Firmware, calibration or diagnostic data has become too large for comfortable transfer over the existing network.
- Multiple CAN, CANopen or J1939 networks must be integrated through a common backbone.
- The system requires more structured separation of logical networks or higher-layer protocols.
- Cybersecurity controls, secure diagnostics or richer device-management data are increasing payload overhead.
- A new machine platform is expected to remain in production for many years and should not be designed into a protocol dead end.
Where CAN FD fits now
For most current migration projects, CAN FD is the practical intermediate step. It increases payload capacity from 8 bytes in Classical CAN to as much as 64 bytes and allows a faster data phase while retaining familiar CAN arbitration concepts. More importantly, it already has a usable engineering ecosystem.
Current CAN/CAN FD PC interfaces from suppliers such as Kvaser and Ixxat are suitable for development, commissioning, diagnostics, maintenance and data acquisition. The value is not merely the interface hardware. A good migration project also verifies bit timing, termination, cabling, error behaviour, application-layer compatibility and the software tools used by maintenance personnel.
CAN FD Light is also worth watching for deeply embedded, price-sensitive sensor and actuator networks. CiA describes it as a commander/responder approach for applications where responder nodes should remain inexpensive, while retaining the robustness of the CAN FD physical layer. CiA 604-4 adds a high-bit-rate mode supporting operation up to 8 Mbit/s.
Where CAN XL fits later
CAN XL becomes more compelling when the network architecture starts to resemble a set of automation islands rather than one simple fieldbus. In a mobile machine, production system or complex vehicle, there may already be separate CANopen, J1939 and proprietary CAN subsystems. A future backbone must move more data without discarding the deterministic and fault-tolerant behaviour engineers value in CAN.
This is where CAN XL deserves design attention now, even if it is not yet the hardware selected for the current project. The migration task is therefore architectural: keep gateway boundaries clear, avoid unnecessary proprietary data encapsulation, define network identities consistently, and separate application data from transport-specific implementation wherever practical.
A practical decision matrix
| Engineering situation | Practical direction |
|---|---|
| Existing CAN network is stable and bandwidth is adequate | Keep it. Improve diagnostics, documentation and maintainability rather than changing protocol for its own sake. |
| New controller or machine needs larger messages and faster diagnostics | Use CAN FD where the controller, transceiver, wiring and higher-layer protocol support it. |
| Large number of low-cost embedded sensors or actuators | Evaluate CAN FD Light where its commander/responder model matches the application. |
| Several CAN/CANopen/J1939 islands require a common backbone | Design the gateway and data architecture for future CAN XL or heterogeneous Ethernet/CAN operation; do not lock the system into an unnecessary proprietary tunnel. |
| Long-life platform being designed now | Select controllers, software boundaries and diagnostic tools with an explicit migration path instead of assuming today’s bus will remain unchanged for the next decade. |
Dr Tang’s View
My view is that the right 2026 decision is not “move everything to CAN XL”. It is to stop creating new architectural dead ends. Use CAN FD where it already solves the bandwidth or diagnostic problem, maintain good physical-layer engineering, and design the gateways and data model so that CAN XL can be introduced later without rewriting the whole machine.
What CANS can support
CANS supports CAN and CAN FD engineering from interface selection through commissioning and diagnostic workflow. The current portfolio includes Kvaser CAN interfaces, Ixxat CAN/CAN FD interfaces and gateways, and Warwick Control Technologies X-Analyser for network analysis. For migration projects, the more important work is often system-level: protocol mapping, gateway design, test strategy, maintainability and planning the transition without disrupting a working installed base.
For a CAN, CAN FD, J1939, CANopen or future CAN XL migration review, contact CANS through cans.com.my.
CAN Technology Watch — 29 August 2026
- CiA’s 21 August update says CANopen FD additional application-layer documents CiA 1302-1 and CiA 1302-2 have been finalised internally.
- CiA plans a new CAN XL webinar series and continues to position CAN FD and CAN XL as next-generation technologies for sectors including rolling stock.
- CiA continues work on CAN FD Light, including the CiA 604-4 high-bit-rate mode.
- Kvaser states that CAN XL is standardised in ISO 11898-1:2024 and that it is developing its own CAN XL IP core; this is a technology-development signal, not a reason to assume immediate mass availability of CAN XL interfaces.
Recent Comments