Open search
Advertisement

CAN Newsletter magazine

Smart-bridging CANopen and CANopen FD

This article gives an description on how to smart-bridge classic CANopen and CANopen FD networks.

Connecting classic CANopen to CANopen FD using a smart bridge (Source: Emsa)

This article originally appeared in the September issue of the CAN Newsletter magazine 2019. This is just an excerpt.

The CANopen FD protocol has several advantages over classic CANopen: A much more flexible communication model that includes fully-meshed and broadcast communication with Universal Service Data Objects (USDOs), a higher potential bandwidth and larger messages that through the use of CAN FD also offer the extra space needed for authentication, for example with CANcrypt. However, existing classic CANopen devices cannot be mixed with CANopen FD devices on the same network cable since classic CANopen devices will destroy and generate errors for any CANopen FD communication they detect. So today, when designing new CANopen based networks or adding new functions, features, nodes, or security to an existing CANopen system, you have the following options:

  1. Stay entirely in classic CANopen
  2. Do a complete transition to CANopen FD
  3. Mix classic CANopen and CANopen FD using a smart bridge

Let’s evaluate these options

Stay entirely in classic CANopen: For any development you initiate today, no matter if it is something new from scratch or a complete or a partial redesign of an existing system, ask yourself how long the system needs to last and which future enhancements or requirements may come up. Take firmware updates over classic CANopen for example, which are possible but not particularly fast or secure. Security through authentication and encryption during normal operation also could become a requirement, if not today then a few years from now. Would this be possible with only a firmware update?

Handling SDO / USDO forwarding (Source: Emsa)

Our recommendation is to not lock yourself into classic CANopen for new developments. Any new CANopen device you build today should be at least CANopen FD “ready” so that you can easily add enhanced features, faster updates, and security “at any time”. Do a complete transition to CANopen FD: This option requires that all devices connected are CAN FD capable. This typically requires new hardware designs or replacement of off-the-shelf CANopen with CANopen FD components and is only an option if a new system design or a complete redesign of an existing system is started.

You may think that your system will then be “future proof” as all existing and future CANopen FD functions and services are available. However, most devices that currently exist still only speak classic CANopen and you’d be locking yourself out of using any of these for a considerable period of time. Chances are, you still need an easy migration path from classic CANopen to CANopen FD or vice versa no matter which route you take.

Mix classic CANopen and CANopen FD using a smart bridge: This third option allows you do both: a step-bystep transition from classic CANopen to CANopen FD or to add legacy devices and networks to a new CANopen FD design. The idea is that you use two network branches in your system: a classic CANopen branch with those devices without CANopen FD support and a CANopen FD branch with the newer devices that already have it. Making sure that all node IDs are unique, the two are connected as segments of a single virtual network, using a smart bridge as illustrated in Figure 1.

How does a smart bridge for classic CANopen and CANopen FD work?

Note that while there is no official standard for this type of bridge yet, we at Embedded Systems Academy saw the need for such a device to ease the transition to the emerging CANopen FD protocol and so came up with its concept. By monitoring the CANopen (FD) traffic on both sides of the bridge, the bridge learns which node IDs are on which side and where the NMT Master is located. Once the bridge has the complete picture of the network segments, USDO and SDO requests and responses involving a node ID are forwarded if required, based on the position of the sender and receiver.

If you want to continue reading this article, you can download the PDF of Mr. Olaf Pfeiffer and Mr. Christian Keydel from Embedded Systems Academy. Or you download the full magazine. This is free-of-charge.

cw



Publish date
2019-09-05
Company

Emsa

Breadcrumb
Advertisement
Sontheim Peak