CAN FD light - Lightweight CAN FD data link layer
CAN FD light is intended for use in deeply embedded, price-sensitive sensor/actuator networks. The necessity for a lightweight CAN FD network became evident during the development of systems for modern car lights. The connected LED clusters (responder nodes) are controlled individually by one commander node. Further potential applications may be any control system, where a central host controller manages several simple end-devices with limited resources. Typical examples are heating, ventilation, and air-conditioning (HVAC) systems.
Originally, CAN FD light was specified in the CiA 604-1 series but has been withdrawn by CiA to be standardized in the upcoming ISO 11898-1:2024. This international standard specifies the communication between commander and responder nodes. The communication follows a commander/responder schema. The responder nodes do not support network arbitration. They only transmit CAN FD data frames on request of the CAN FD light commander. Thus, an accurate clock source at each node is not required. Single monolithic devices without crystal oscillators can be used. This lowers costs and improves the implementation reliability, as crystal oscillators are sensitive to vibration and temperature.
The CAN FD light responder nodes transmit CAN FD data frames that comply with ISO 11898-1 and provide payloads of up to 64 byte. They support only the base frame format (11-bit identifier). As no bit-rate switching is supported, the same bit rate is used in the arbitration phase and data transmission phase, and the control field bits in the frames are fixed. Currently, the maximum bit rate is 1 Mbit/s, which is fast enough for the intended applications.
Some protocol details
Responder nodes receive and transmit CAN data frames in FD base frame format (FBFF). They provide acceptance filtering and do not support automatic retransmission of data frames. Additionally, they do not support remote frames (RF), overload frames (OF), and error frames (EF).
Responder nodes send the acknowledge (ACK) bit after error-free reception of a data frame from the commander node. Optionally, the sending of the ACK bit can be disabled by the node configuration, which is not compliant to ISO 11898-1:2024. In this case, the CAN FD light commander node needs to support this configuration.
Error detection and signaling
The responder nodes support some error detection and handling mechanisms as specified in ISO 11898-1:2024. These include stuff-rule check, stuff-count check, and circular redundancy check (CRC). Additionally, they check the CAN FD frame format. Accordingly, the supported error types include stuff error, CRC error, and form error. The latter is detected when a recessive IDE (identifier extension) bit, a dominant FD format (FDF) bit, or a recessive bit rate switch (BRS) bit is received. As exception, responder nodes shall accept any value of the error state indicator (ESI) bit, if the CRC value is correct. Responder nodes do not detect bit errors and ACK errors.
The responder nodes do not detect overload conditions, support no overload signaling via overload frames, and do not signal errors via error frames. This means that the responder node does not send error frames (EF(s)) and overload frame (OF(s)). An error counter is not implemented. In case of error conditions, the responder node triggers the protocol exception event. On this event, the responder node sends recessive bits and enters the bus integration state.
Network wide data consistency is not supported. Data consistency between commander node and responder node is achieved by the commander and responder communication schema. Error handling is possible only on higher OSI layers, for example detecting that no response is received.