CAN Newsletter magazine
The history of CANopen has not been written, yet. CANopen is still evolving. CAN in Automation (CiA) and its members are always maintaining and enhancing the set of CAN and CANopen specifications. Here’s an update and a look into the future.
About 25 years ago, CANopen had been developed for embedded machine control in modular machines. But CANopen is not limited to this application field. In the meantime, CANopen has propagated to many applications including medical devices, building automation, energy management, construction machines and off-highway vehicles as well as maritime electronics. CANopen is an attractive candidate for open and embedded networks, because it is scalable, flexible, robust, reliable, and available from different sources. Additionally, there exists the CAN in Automation independent users’ and manufacturers’ group, which provides support and advice, in case of any CAN-based challenges. To keep CANopen also in future an attractive networking technology, CiA members are ongoing to enhance CANopen, so that CANopen is able to meet the requirements of embedded networking today and tomorrow.
CiA is maintaining and extending the series of CANopen device and application profiles, to increase the plug-and-play capability of CANopen devices and to reduce the effort of system designers. In times of climate change and increasing costs for energy, applications are in the focus of CiA specification activities that need to do some energy management, in order to keep the energy consumption low.
Applications such as service robots, AGVs (automated guided vehicles), and light electric vehicles buffer a limited amount of energy in a battery. By means of a sophisticated energy management, they attempt to provide the availability of the system, for a maximum duration. CiA assists system designers and maintainers of such applications by specifying harmonized application data. For example, the CANopen profiles for batteries and chargers (CiA 418 respectively CiA 419) are currently under systematic review. In many of the aforementioned applications, the end user respectively owner of the system has to modify the application (just by adding or changing some batteries, for example). But this end user has typically no or only limited knowledge about (CANopen) embedded networking. Many tricky issues such as self-configuration, cybersecurity, reliability, or firmware updates have to be handled dynamically, by the embedded control systems themselves.
CiA assist also in this regard todays and tomorrows CANopen users. Dynamically changing systems are rather easy to handle, in case the network participants have the ability to check, who is available in a given system configuration. The CANopen heartbeat services as well as com- plex SDO connectivity allow this already in classic CANopen. A central host controller could monitor the system configuration, and could report on system changes, to all other devices. The new CANopen FD provides enough bandwidth as well as enhanced cross-communication capabilities, so that all the devices in the network could analyze by themselves, whether there has been a new device added to the system and whether they need to establish communication coherences to this new device. As a consequence, the central host controller would be unburdened from such tasks. In a dynamically modified system, the host controller would just use the updated, CAN FD based LSS FD (specified in CiA 1305), to assign the CANopen (FD) node-ID (and CANopen FD network-ID). Recommendations and specifications on CANopen FD and the improved way of CANopen network management are discussed in the CiA interest group (IG) CANopen FD and all of its sub-groups.
News and reports