Embedded systems are becoming more distributed even when the control architecture is becoming more centralised. A machine, vehicle subsystem, HVAC unit, instrument panel or smart actuator may contain dozens of low-cost sensors, indicators and small controllers, yet giving every node a full-featured network controller can add cost and complexity that the end device does not need.
That is the engineering problem behind CAN FD Light. The technology retains CAN FD framing and physical-layer robustness, but simplifies the responder nodes by moving network control to a commander. In 2026, the ecosystem has moved further: CAN in Automation (CiA) released CiA 604-4 version 1.0.0 as a draft specification proposal for a high-bit-rate mode supporting CAN FD Light operation at up to 8 Mbit/s.
I would only use CAN FD Light where the system is genuinely commander/responder. If the end nodes need to talk independently or arbitrate for the bus, full CAN FD is usually the cleaner choice.
What CAN FD Light actually changes
CAN FD Light is intended for deeply embedded, price-sensitive sensor and actuator networks. The basic communication approach is standardised in ISO 11898-1:2024 and described by CiA.
A normal CAN or CAN FD node participates in bus arbitration and can transmit when the network rules permit. A CAN FD Light responder is deliberately simpler: it does not arbitrate for the bus and transmits only when requested by the commander. That reduces the protocol burden at the responder and can support lower-cost end nodes.
The CAN FD data-frame format is retained, including payloads of up to 64 bytes. This is one reason CAN FD Light can fit naturally into engineering environments that already use CAN FD development concepts and diagnostic tooling.
What changed in 2026: high-bit-rate mode
CiA released CiA 604-4 version 1.0.0 on 12 May 2026. The document specifies additional CAN FD Light functions and a high-bit-rate mode for commander and responder nodes at bit rates up to 8 Mbit/s. CiA notes that the improved approach uses CAN SIC transceivers for higher bit rates.
At the same time, system-design guidance remains important. CiA 604-3 is still a work in progress, and the CAN FD Light conformance-test plan is being incorporated into the next ISO 16845-1 edition. In other words, the technology is real and standardised at its core, but an engineering team should still verify controller, transceiver, timing and test-tool support for the exact implementation it intends to deploy.
Where CAN FD Light fits well
CiA identifies applications such as modern lighting systems and HVAC, where one central controller manages many comparatively simple end devices. The same architectural idea can be useful beyond automotive applications.
- Smart lighting and indicators: multiple LED or display modules controlled by one supervisory unit.
- HVAC subassemblies: dampers, valves, temperature sensors, fan modules and local actuators under a central HVAC controller.
- Seat, door and cabin subsystems: many small devices with predictable command/response traffic.
- Machine sensor clusters: several low-cost sensors or actuators connected to one local embedded controller.
- Modular equipment: a main controller communicating with replaceable intelligent modules where the traffic pattern is centrally scheduled.
The common characteristic is more important than the industry: the end nodes do not need to compete independently for bus access.
CAN FD Light is not a cheaper CAN FD for every application
The simplified responder model is also its principal limitation. If several nodes must initiate urgent asynchronous messages independently, perform peer-to-peer coordination, or participate as equals in a distributed control system, full CAN FD is normally a better fit.
Similarly, the availability of an 8 Mbit/s mode does not mean every harness should be designed for 8 Mbit/s. Signal integrity, network length, stubs, connectors, transceivers, EMC environment and timing margins become increasingly important as the bit rate rises.
For industrial equipment, the network choice also has to consider maintenance. A technically elegant embedded bus can become expensive over the product lifecycle if service engineers cannot diagnose it easily or if replacement devices require a proprietary commissioning procedure.
CAN FD Light vs CAN FD vs LIN vs RS-485
| Engineering factor | CAN FD Light | CAN FD | LIN | RS-485 / Modbus RTU |
|---|---|---|---|---|
| Architecture | Commander / responder | Multi-node arbitration | Master / slave scheduling | Protocol-dependent master/client model |
| Responder complexity | Low by design | Full CAN FD controller behaviour | Low | Low to moderate |
| Payload per frame | Up to 64 bytes | Up to 64 bytes | Up to 8 data bytes | Protocol-dependent |
| Bit rate | CiA 604-4 high-bit-rate mode up to 8 Mbit/s | Higher data-phase rate than CAN CC; practical limit depends on physical layer | Low-speed network, typically up to 20 kbit/s | Depends strongly on distance, transceiver and protocol |
| Spontaneous node transmission | No; responder transmits when commanded | Yes, subject to arbitration | Normally scheduled by master | Depends on protocol design |
| Physical-layer robustness | CAN FD physical layer; CAN SIC for high-bit-rate mode | Strong CAN ecosystem and EMC behaviour | Good for short, low-cost subnets | Strong industrial multi-drop option when engineered correctly |
| Best fit | Central controller with many simple end nodes | Distributed embedded control and higher-performance networks | Very low-cost, low-speed local devices | Industrial devices, instruments and legacy multi-drop integration |
Six design questions before choosing CAN FD Light
- Who owns the timing? If one controller can deterministically schedule nearly all traffic, CAN FD Light is a strong candidate. If nodes must initiate important messages independently, use full CAN FD or another distributed architecture.
- What is the real bandwidth requirement? Do not select 8 Mbit/s simply because it is available. Calculate payload, update rate, protocol overhead, diagnostic traffic and future margin.
- What does the physical network look like? Cable length, stub length, connectors, grounding, shielding and EMC environment determine whether the desired bit rate is realistic.
- Does the semiconductor chain support it? Verify the exact MCU/controller implementation, CAN FD Light responder capability, CAN SIC transceiver and clocking requirements.
- How will the product be tested? Confirm that the analyser, interface, oscilloscope setup and production test equipment can operate at the chosen nominal/data timing and understand the traffic model.
- How will it be serviced ten years later? Define firmware update, node replacement, diagnostics, fault logging and backwards-compatibility strategy before the network is frozen into hardware.
A sensible machine architecture
For many products, CAN FD Light should be considered as a local embedded subnet, not automatically as the machine-wide backbone.
A practical architecture could be:
Simple sensors / actuators → CAN FD Light local subnet → embedded commander / gateway → CAN FD, CANopen, J1939, Ethernet or industrial control network.
This keeps the low-cost end nodes simple while allowing the gateway or main controller to handle diagnostics, cybersecurity, data aggregation and integration with the wider machine.
That separation is particularly useful when operational data later needs to reach SCADA, MES, predictive-maintenance software or an industrial intelligence platform without exposing every deeply embedded device directly to higher-level networks.
Development and diagnostic tooling
CAN FD Light deliberately reuses the CAN FD frame format, which reduces the need for an entirely separate engineering toolchain. However, teams should distinguish between being able to see a CAN FD-format frame and having complete support for a particular CAN FD Light controller, timing mode and high-speed physical layer.
Kvaser emphasises that higher CAN FD bit rates place greater demands on physical-layer quality and bit timing. Kvaser has also described CAN FD Light as compatible with the broader CAN FD tool concept. HMS Networks now lists CAN FD Light among the network technologies covered by its PEAK engineering-tool portfolio.
For CANS projects, tool selection should therefore be made against the actual network specification. Kvaser CAN/CAN FD interfaces, HMS/Ixxat connectivity products and Warwick X-Analyser can form part of the engineering and diagnostic environment where their controller, transceiver and bit-timing capabilities match the target system.
CAN FD Light is interesting because it solves a real cost problem: a very simple end node does not always need a full controller. But I would not choose it simply because 8 Mbit/s is available. The communication pattern comes first; the headline bit rate comes later.
CAN Technology Watch — 5 September 2026
The latest CAN Community News No. 11, dated 21 August 2026, shows that the wider CAN ecosystem is moving on several fronts at once. CiA reports that the CiA 1302-1 and 1302-2 additional CANopen FD application-layer documents have been finalised and entered its internal quality process. The CiA 404 measuring-device work is also being updated for both CANopen CC and CANopen FD, with expert input requested by 21 September.
CiA also says J1939-21 and J1939-22 transport-layer terminology will be harmonised in future issues, ISO 25200 for CAN-based commercial-vehicle body-builder networks has passed the DIS ballot, and a new series of CAN XL webinars is being prepared. Its September CAN Newsletter issue is focused on CAN FD. For machine builders, the direction is clear: CAN CC is not disappearing, but new products should be designed with CAN FD, CANopen FD and eventual CAN XL coexistence in mind.
What CANS can help with
The network should be selected as part of the embedded architecture, not after the PCB has already been designed. CANS can support protocol selection, MCU and transceiver architecture, CAN/CAN FD firmware, gateway design, diagnostics, test tooling and integration from the embedded network into higher-level industrial systems.
For teams planning a new CAN-based product, review our earlier CAN FD to CAN XL migration guidance, see Kvaser CAN interfaces available through CANS, or contact CANS to discuss the network architecture before hardware is frozen.
Recent Comments