Major tasks in future embedded networking are the integration of embedded networks in Cloud-applications, providing lots of “nice to have data” to “big data applications”, meeting increasing security requirements, etc. CANopen FD was designed to meet the requirements of future embedded networking. The communication flexibility, thanks to the USDO, enables e.g., a CANopen FD / IIoT gateway access to any data, provided in the embedded CANopen FD network. Additionally to transfer of any size of data in the local network, CANopen FD’s inherent routing capability also allows accessing CANopen FD devices connected to a remote network.

CANopen FD keeps the CANopen object dictionary almost unchanged. Therefore, CANopen FD can make use of the harmonized application data, specified in more than 20 000 pages of existing and widespread implemented CANopen device and application profiles. This way, CANopen FD devices can support a high degree of plug-and-play capability and cloud-based applications can save processing power as formatting the data is simplified.

The increased payload provided by CANopen FD allows supporting advanced concepts for security as well as functional safety.

CANopen FD provides several communication objects (COBs), which enable device designers to implement desired network behavior into a device. The communication objects include PDO (process data object), USDO, SYNC (synchronization), TIME (time-stamp), EMCY (emergency), NMT (network management), and error control protocols. These communication objects allow CANopen FD devices to communicate configuration and process data in broadcast and unicast, indicate device-internal error conditions, or influence and control the network behavior. CANopen FD functions enable a simple management of dynamically changing network setups. The CANopen FD internal device structure is identical to that as defined in CANopen CC. CANopen users can therefore reuse lot of their CANopen CC knowledge in case they use CANopen FD.

CANopen FD demands a physical layer implementation according to ISO 11898-2, capable to support bit rates of up to 5 Mbit/s. Implementations according to the ISO 11898-2 standard may support a low-power mode as well as the selective wake-up capability. Therefore CANopen FD is enabled to support sophisticated power-saving concepts. Regarding the setup, cabling, and topology, CANopen FD refers to the CiA 6xx specification series. For example, the CiA 601-6 specifies mechanical and electrical parameters for cables to be used in CAN-FD based networks.

The bit timing for CANopen FD is provided in the CiA 1301. For CAN clocks with a frequency of 40 MHz, CANopen FD specifies bit rates for arbitration and data phase. Those given bit rates can be easily combined, because all defined bit rates are based on the same time quantum. For being future-proof, CANopen FD supports bit rates up to 10 Mbit/s in the data phase, however today's CAN FD implementations are designed to support bit rates up to 2 Mbit/s or 5 Mbit/s.

The CANopen FD data link layer is based on ISO 11898-1 and utilizes the CAN FD frame format for all communication protocols. CANopen FD does not differentiate whether the data is communicated in CAN FD frames with or without bit rate switching. In contrast to CANopen CC, CANopen FD does not support CAN remote frames.

A CANopen FD device consists of three logical parts. The CANopen FD protocol stack handles the communication via the CAN FD network. The application software provides the internal control functionality as well as the interface to the process hardware interfaces. The CANopen FD object dictionary interfaces the protocol as well as the application software. It contains references (indices) for all used data types and stores all communication and application parameters.

The CANopen FD object dictionary is most important for CANopen FD device configuration and diagnostics. As device-internal reference, a 16-bit index, which is given as 4-digit hexadecimal value, is used. The index range 1000_h to 1FFF_h provides references to all parameters that determine the communication behavior of the CANopen FD device. The index range 2000_h to 9FFF_h provides the references to all application-related parameters. CANopen FD distinguishes between proprietary parameters (index range 2000_h to 5FFF_h) and standardized parameters (index range 6000_h to 9FFF_h).

A CANopen FD protocol stack controls the CAN FD communication of a CANopen FD device. The CANopen FD protocol stack provides several CANopen FD COBs for configuration, diagnosis, and control purposes. Therefore, a CANopen FD user is enabled to transfer control information, to react to certain error conditions, or to influence and control the network behavior. CANopen FD is very scalable and the CANopen FD protocol stack can be tailored to the required functionality and to the available resources on the micro-controller. The capabilities supported by a CANopen FD device can be evaluated by checking the existence of the related object dictionary entries that describe the communication behavior.