CANopen safeguards to reduce errors

Transferring data over CANopen networks is extremely reliable, but CANopen offers additional safeguards to decrease the effect of residual errors. This is part 1 of 2.

By Dr. Heikki Saha May 16, 2015

Understanding application level safeguard details and fundamental CANopen services can decrease the chance of protocol level residual errors without introducing additional lifecycle costs. For those unfamiliar with CANopen, it is a communication protocol and device profile specification for embedded systems used in automation. Reviews make sense, because most of the presented concepts have already been not only standardized, but also implemented in most of the devices on the market and are just waiting to be used.

In many applications, complex safety add-ons have been designed on top of existing control systems, which has led to significantly increased complexity and costs. The most significant increase of the performance level can be achieved by replacing all analog signal paths with digital communication. As long as an error can be detected and a control system can perform a reliable reaction, the error cannot cause any harm. When typical failures of systems are analyzed, it is obvious that analog signal paths are the weakest point of any control system.

Due to the fact that safety standards cover the entire lifecycle of target systems, the design of modern control systems not only requires new technological solutions, but also an updated mind-set. In addition to the design of theoretically safe systems, production and service processes must be updated to be able to reach the designed performance level (PL) and maintain it throughout the systems’ lifecycle, as required by the standards. 

Device profiles

Traditionally, each system integrator implements its own low-level controls and management of analog sensors and actuators into programmable logic controllers (PLCs) in addition to the application logic. This approach leads to some major drawbacks:

  • Proprietary software components are not well specified because each company uses its own. Using software components only internally gives users a wrong feeling of their "flexibility," leading to unmanaged customizations from project to project. There are numerous components that are almost similar, leading to a need for tests and the certification of each of them individually.
  • A proprietary software component is often optimized for one company, one department, or one application, and only for current applications. Such components are maintained reactively when they are close to becoming obsolete and thus are continuously under development.
  • The quality assurance of a software component requires a lot of testing and typically some kind of certification(s). If each company tests similar components on its own, the work overlaps and a large number of items have to be tested. CANopen device profiles generally define a generic architecture of device categories and thus offer a common set of basic I/O, measurement, and drive functions. From a safety point of view, the most important consequence of relying on device profile conformant devices is that each basic function has been designed, implemented, tested, and certified once by the device vendor.
  • When a standardized, CANopen-compliant component is used, there is always a globally harmonized system integration interface enabling the intrinsic reusability of basic functions without a need for project-specific retesting and recertification.
  • Many companies are involved in the development and maintenance of each CANopen device profile. Contrary to proprietary functions, device profiles are more generic and provide a solid basis for various applications.
  • By using standardized functions and components, the device vendor performs unit tests for a single device and the cost is shared by all customers. In the long run, the quality of the functions can be improved faster because each device in each application provides test results to the device vendor.

Network management state-machine

Analog sensors and actuators start full operation immediately after power-up without any self-tests and consistency check procedures. In case of a fatal internal failure, there is no service available that informs the rest of the system about the internal initial condition or prevents a faulty operation. The network management (NMT) state-machine provides a basic mechanism for safe and manageable behavior. During start-up each device enters into a preoperational state.

During this time, the system structure can be checked and optional correct parameter values can be set. In case of a fatal internal failure, each CANopen device can automatically enter into a defined—preferably stopped—state to minimize further failures on the system level. 

Device state-machines

Analog sensors and actuators are stateless, enabling the transmitting or receiving of only continuous-time signals. This means that analog actuators cannot provide any local safeguards against problems such as cabling failures, which are common and typically lead to wrong behavior. Furthermore, analog actuators cannot enter into the stable error state and safely go back to normal operation when requested.

Some device profiles, like those for I/O- and measurement devices, have a simple fault mode for outputs, enabling the use of a safe value when setpoint signals are not updated.

Drive profiles for electric and hydraulic drives have comprehensive device state-machines that are controlled by an additional signal pair. The state-machine controls the operation of the entire drive. The use of a state-machine decreases the significance of a single communication failure or a communication failure in one signal. One major benefit of the device state-machine is that error recovery can be accurately controlled and accidental recoveries can be avoided.

Another benefit of the device state-machine is that, together with the primary setpoint signal, the additional state control and status signals provide dual-channel control for drives. The most common safe state is "stopped," which can be triggered in two ways:

  1. The main control application can set the setpoint value to neutral or the control word to a different value than "device mode active."
  2. The monitoring application can force the control word value to a different value than "device mode active."

It has been proven that in an optimum case the main control application sends the setpoint(s) directly to the drive to minimize the control path latency. The control word may be routed through the monitoring application, because it is used only in the initialization and recovery phases. It is a question of the dependability of the controller devices and if single or dual applications and/or PLCs are needed. The status word and actual values may be used by both applications. 

Actuators to drives

Traditional analog actuators are just actuating components, typically without any internal intelligence and sensing. Additional analog sensors may be installed into analog actuators, but they are not used internally. Such sensors are considered additional sensors and therefore increase the number of components and amount of cabling.

Modern drives can have internal measurements and control loops. Bi-directional communication interfaces makes it easy to access the internal signals. Actual values of drives (S) may be used as a redundant and diverse feedback for controlled axes, enabling the plausibility checking of the primary axis sensor value (P) instead of additional sensors. The system complexity is not increased because neither additional components nor additional cabling are required. 

Membership monitoring

Analog sensors and actuators cannot provide identification. As a consequence, unintentional/unmanaged device installations or changes cannot be detected by the rest of the system. This may lead to degraded performance or even dangerous misbehavior of the entire system.

Because CANopen is an integration framework and not just a set of protocol services, it includes comprehensive diagnostic services. Managed network start-up, in conjunction with NMT state machine, provides a simple, efficient, and standardized mechanism for a detailed checking of the system structure identification before full operation during the system power-up. Optional checks may cover the full functionality of each device, including the application software version and device configurations.

After the start-up phase, a lightweight online membership monitoring provides a continuous monitoring of structural changes. It enables the state monitoring of each device, which can also be used as an information source for the monitoring of received signals. Heartbeat is a point-to-multipoint protocol, enabling system consistency monitoring by an unlimited number of devices.

Part 2, linked at the bottom of this file, discusses process data objects mapping and how the CANOpen protocol allows for fewer errors in traditional analog instrumentation.

– Dr. Heikki Saha, M. Sc Automation, Dr. Tech. Electronics, is chief technology officer, TK Engineering, Oy; edited by Anisa Samarxhiu, digital project manager, Control Engineering, asamarxhiu@cfemedia.com

Key concepts

  • In case of a fatal internal failure, each CANopen device can automatically enter into a defined-preferably stopped-state to minimize further failures on the system level. 
  • Analog sensors and actuators are stateless, enabling the transmitting or receiving of only continuous-time signals.
  • Managed network start-up provides an efficient and standardized mechanism for a detailed checking of the system structure identification before full operation.

Consider this

What kind of safeguards do you look for when it comes to data transfers?

ONLINE extra

Learn more from the CAN in Automation organization and from other CiA articles linked below.