Here is a copy-pasta from today’s CiA newsletter:
“We are not going to support CAN FD; we are waiting for CAN XL.” I heard this statement several times and was surprised. CAN FD and CAN XL are not in competition. They address different use-cases. CAN FD is designed for embedded real-time control systems providing more bandwidth than Classical CAN and a larger payload (up to 64 byte). Using CAN SIC transceivers as specified in CiA 601-4 allows dataphase bit-rates of up to 8 Mbit/s depending on the physical layer design (e.g. topology, cable and connector impedance).
CAN XL features very large payloads (about 2048 byte in maximum). It provides a lot of features to be used for higher-layer protocols similar to Ethernet. In opposite to 10-Mbit/s Ethernet, CAN XL is more reliable and robust as well as more cost-effective. CAN XL is suitable for backbone applications in complex network architectures. The maximum dataphase bit-rate is 10 Mbit/s and perhaps a little bit more.
One of the key advantages of CAN XL is its scalability. The payload can be byte-wise extended from 1 byte to 2048 byte. CAN XL networks can be based on CAN high-speed transceivers (ISO 11898-2:2016), CAN SIC transceivers (CiA 601-4), and CAN XL SIC transceivers (CiA 610-3). This scalability gives the network designers as much freedom as possible.
The 8-bit service data unit (SDU) type in the CAN XL data frame indicates the used higher-layer communication service (e.g. the network layer). CiA assigns these types, they are specified in CiA 611-1 (under development). The SDU type is similar to the Ethertype in Ethernet data frames. Additionally, the CAN XL data frame provides the 8-bit virtual CAN network identifier (VCID). It allows running multiple network applications with the same SDU type on a single network. In the past, this was also possible, but the CAN-IDs needed to be assigned uniquely by the system designer.
To summarize: CAN FD and CAN XL address different use cases. Do not wait for CAN XL, if your application is real-time control. Of course, you can use CAN XL also for such control purposes, but the bandwidth increase is not that high compared to CAN FD. Standardized higher-layer protocols based on CAN FD are already available (CANopen FD as specified in CiA 1301) or will be released soon (SAE J1939-22).
This reminded me that I was going to make a brief position post on this forum to announce that supporting CAN XL in UAVCAN/CAN is of interest and is something that may be worked on after UAVCAN v1.0 is out.
Since the UAVCAN project is a paying CiA member, we should get in touch with the CiA 611-1 SIG to request reservation of a single SDU value for UAVCAN/CAN over CAN XL.
Supporting CAN XL is not going to be exactly trivial because CAN XL does not support extended CAN identifiers (not sure why though), so part of the session-identifier will have to be relocated from CAN ID into the payload for CAN XL only. Also, CAN XL may be incompatible with some hard real-time systems because of the worst-case frame preemption implications introduced by its extremely long (compared to CAN FD) payloads while using the same low bit rate as in CAN FD (compared to, say, GbE+ switched networks).