RSS Feed

Embedded Systems Blog

Potential risk warning for CiA 443 sub-sea systems supporting a bit rate change via Layer Setting Services

April 22nd, 2013 2 comments

Although ESAcademy is not an active member of the CiA 443 group, we have several customers and business partners using CiA 443 and came across a potential reliability issue in regards to bit rate changes.

It is our understanding that the reliability requirements for CiA 443 sub-sea applications are very high. Bootloaders are written and tested in a way that even power failures at any time or severe communication errors can not break the system. In worst case, an application is not programmed and a device remains in bootloader mode and is simply re-programmed again.

However, allowing the CAN bit rate to change with the currently specified mechanisms bears the risk of one or multiple devices failing. If in a CAN network devices are not configured to use the same bit rate, communication fails at a very low level. Devices will recognize that there are errors on the bus and potentially take themselves offline (bus off). If the devices are configured to use these different bit rates, then this error state can not be resolved.

How could such a situation occur?

The Layer Setting Services (LSS, see CiA 305) allow the setup of a bit rate, if all devices connected to a network support these services. Although the method of when exactly to do the bit rate change is very well specified and synchronized, the actual storing of this information (nodes copying this information to their local non-volatile memory) is not. It happens “one-by-one” and as no timings specified, this could be within seconds or even minutes. If there are severe bus communication errors during this time or even a power failure, then all devices will not have the same bit rate configured.

Possible solutions:

1.) Do not use switching of CAN bit rates by LSS, only use it for node ID assignments

2.) Use a power-on default bit rate. Any change to the bit rates is not stored in non-volatile memory, it is only temporary. With each reset or power cycle all devices fall back to their initial default bit rate.

3.) Use auto detect. Note: this only works if not all nodes are doing it, there must be at least one node communicating for the others to be able to do an auto detection. This feature is not available with all CAN controllers (requires passive listen-only mode).

4.) Check with CiA 305 group what else can be done to make the bit rate switch safer, for example by not only synchronizing the time of the physical switch, but also the time when this information is stored into non-volatile memory.

Until this is solved we recommend all existing systems to not make use of the bit rate switching by LSS.

Categories: CANopen Tags: , , ,
Both comments and pings are currently closed.

2 responses to “Potential risk warning for CiA 443 sub-sea systems supporting a bit rate change via Layer Setting Services”

  1. Uwe Koppe says:

    From my experience I would like to vote for solutions 1 and 3. In most applications there is absolutely no need to switch the bitrate after the CAN nodes are installed. For IP66 (and higher) rated modules the automatic bitrate detection is the first choice. It is included in our CAN drivers and supported by the CANopen stack.

  2. The SIIS CiA443 plugfest in September 2012 was for me the first time to join the group. On this occasion I have already tried to point out that bit rate switching via LSS in a running system might be a very critical issue. Therefore I recommended to change CiA443 in a way that bit rate switching via LSS is no longer recommended and that a system designer should act according to the suggestions 1) and 3).
    Just for giving some background information. According to my information, the current use case for LSS bit rate switching is in the laboratory, e.g. for accelerating the update of new firmware. As soon as the entire “Christmas tree” is operating in the deep sea, the bit rate may not be changed.